I wrote a 6502 emulator in Lua https://github.com/willtobyte/MOS6502
I wrote a whole Atari 8-bit emulator in TypeScript (Github only has the CPU for now, I’ll push the whole thing when I find time to clean up): https://sfotty.cyco130.com
Dirty tricks 6502 programmers use (2019)
31–40 of 68 posts
Re: Dirty tricks 6502 programmers use (2019)
#32My VIC-20 coding trick as a 14 year old was to use the 828 byte cassette buffer for storage in my games because it took me forever to save up for the 6.5k RAM expansion.
Re: Dirty tricks 6502 programmers use (2019)
#33My VIC-20 coding trick as a 14 year old was to use the 828 byte cassette buffer for storage in my games because it took me forever to save up for the 6.5k RAM expansion.
That’s a lot of bytes to leave unused.
Re: Dirty tricks 6502 programmers use (2019)
#34I remember the annoyance a lot of people had with the non-sequential layout of text/graphics memory on the Apple ][ (thanks to Woz’s clever hacks to reduce chip count), but when writing assembly code to access screen locations, it turned out that it was actually easier to deal with the somewhat weird arrangement of bytes than it would have if everything were sequentially arranged in memory. Those little 8-byte gaps e…
The best 8-bitter video memory layout (for pixel data) I have seen is in the little known KC85/4: The display is 320x256 pixels, organized into 40x256 bytes for pixels (8 pixels per byte) and another 40x256 bytes for Speccy-like color attribute bytes (the color blocks are just 8x1 instead of 8x8 pixels), the start address for video memory is 0x8000 with the pixels and colors in different memory banks. Now the twist:…
Vertical layout is awesome for 8 bitters. We tended to use it a lot on the C-64, too.
The c64 had a very awkward native memory layout for bitmaps (8 bytes vertical corresponding to a 8x8 or 4x8 pixel block, then jumps back up, next 8 bytes again vertical but to the right of the first 8x8 pixel block!). Super annoying and the worst of all worlds for coordinate to memory address calculations.
So for demo effects we often used a purely vertical layout by abusing customizable character sets, which are allowed to have 256 fully custom 8x8 pixel characters: arranging the characters in, for example, an 16x16 character grid = a 128 x 128 pixel grid, such that the memory for the character set will effectively result in a vertically oriented mini bitmap.
This also has nice advantages for example for fast pixel filling: if you unrolled an EOR $address; STA $address; EOR $address+1, STA $address+1, etc. etc. loop, you had a pretty fast, almost constant time filler for a bitmap where you only painted top and bottom lines of the area you wanted to have filled - one line to switch on filling, bottom line to switch off again.
Re: Dirty tricks 6502 programmers use (2019)
#35I remember the annoyance a lot of people had with the non-sequential layout of text/graphics memory on the Apple ][ (thanks to Woz’s clever hacks to reduce chip count), but when writing assembly code to access screen locations, it turned out that it was actually easier to deal with the somewhat weird arrangement of bytes than it would have if everything were sequentially arranged in memory. Those little 8-byte gaps e…
haha as someone who has spent a lot of time recently doing Apple II graphics coding, both for games, sizecoding, and the demoscene, let me tell you that the weird layout in fact is not easier to deal with. You have to waste a lot of space on lookup tables, or else complex calculations. And don't get me started on the "screen holes" you aren't allowed to write to in the lo-res address space making it exciting if you'r…
Hmm, I don’t remember there being anything special about those little 8-byte holes in the lo-res/text memory.
Re: Dirty tricks 6502 programmers use (2019)
#36Earlier quoted context omitted.
haha as someone who has spent a lot of time recently doing Apple II graphics coding, both for games, sizecoding, and the demoscene, let me tell you that the weird layout in fact is not easier to deal with. You have to waste a lot of space on lookup tables, or else complex calculations. And don't get me started on the "screen holes" you aren't allowed to write to in the lo-res address space making it exciting if you'r…
Hmm, I don’t remember there being anything special about those little 8-byte holes in the lo-res/text memory.
There are 8 screen hole bytes in the bottom 8 text rows (64 bytes total) and 8 expansions slots, so the screen hole byte at offset "N" was often used to store up to 8 bytes of data[1] (one byte in each of the rows' screen hole area) by the expansion card's firmware in Slot "N". Overwriting those bytes could result in system crashes and hardware hangs.
Re: Dirty tricks 6502 programmers use (2019)
#37[flagged]
Re: Dirty tricks 6502 programmers use (2019)
#38it breaks my heart that 6502 got so little traction in professional circles until those atari video editing platforms
wordstar was the key and the commodore people missed out entirely
Re: Dirty tricks 6502 programmers use (2019)
#39My VIC-20 coding trick as a 14 year old was to use the 828 byte cassette buffer for storage in my games because it took me forever to save up for the 6.5k RAM expansion.
When programming assembly, it was common to just indiscriminately use all RAM, not matter what the kernal[1]/basic used it for.
When programming basic, it was common to use memory regions that were meant for something else for yourself if you don’t need it, like you did, knowing that you won’t use the cassette routines.
On the C64, there were some common “autorun” tricks that loaded the program into a buffer overlapping with the keyboard/command buffer, so that after loading completed, the program would magically start without having to type “RUN” or “SYS” with some arcane address.
[1] Not a typo, Commodore called it “KERNAL” with an “A”.
Re: Dirty tricks 6502 programmers use (2019)
#40My VIC-20 coding trick as a 14 year old was to use the 828 byte cassette buffer for storage in my games because it took me forever to save up for the 6.5k RAM expansion.
When programming assembly, it was common to just indiscriminately use all RAM, not matter what the kernal[1]/basic used it for. When programming basic, it was common to use memory regions that were meant for something else for yourself if you don’t need it, like you did, knowing that you won’t use the cassette routines. On the C64, there were some common “autorun” tricks that loaded the program into a buffer overlapp…
800/3.5k, a giant amount indeed!