One wacky quirk of the 6502 was the dummy reads/writes. Commodore 64 coders took advantage of them by, counterintuitively, using DEC $D019 to quickly _rewrite_ the 1 in the least significant bit of the interrupt acknowledge control.
Kinda blows my mind that anyone discovered that. The dummy reads/writes weren’t documented in MOS’s 6502 programmers manual, only the hardware one, which I wouldn’t have imagined many games coders would have had.
Ah yes I’m familiar with those — back at the start of the pandemic I kept myself busy by writing a Commodore 64 emulator, and had to put support for them in. I didn’t think I’d need to, but at least one mainstream game I found wouldn’t function with only the documented opcodes supported.
The game in question was PacLand, and the illegal code hit right at the start of the first scroll. For the longest time I was convinced there must be some bug in my 6502 emulator and that there can’t really be a quasi-op there (as I recall them being called back in the day in some circles). But I then implemented it and the game worked. Part of me wonders if its purpose was to confuse people trying to hack the game, to make it look like the code they were looking at wasn’t really code.
But the dummy writes thing really threw me: an instruction where I thought I knew what it did, but in the context of MMIO, I didn’t fully.
Navigating the memory address bug must have been hellish. Did every amateur user have to discover the big and find a solution, or was the chip basically functional and only failed in certain instances? How would you even come across the solution, clubs, hobby periodicals?
The indirect JMP one? It's really not a very impactful bug. Indirect jumps are rare in any code and are usually located in Zero Page, which many instructions wrap around in (e.g. indirect,X addressing. Also programmers will usually instinctively make the first byte be at an even address which makes page crossing or wrapping irrelevant.
Many other CPUs have memory addressing that wraps around within the page or segment, ranging from the PDP-8 to the PIC microcontroller to the SC/MP microprocessor to the 8086.
Hi Russell, That's a really good point and has got me thinking. I've done a scan of one of the most popular 6502 books 'Programming the 6502' by Rodney Zaks and couldn't find a mention. I'll do some more investigating. Might be a topic for a future post! Very best wishes.
One wacky quirk of the 6502 was the dummy reads/writes. Commodore 64 coders took advantage of them by, counterintuitively, using DEC $D019 to quickly _rewrite_ the 1 in the least significant bit of the interrupt acknowledge control.
Kinda blows my mind that anyone discovered that. The dummy reads/writes weren’t documented in MOS’s 6502 programmers manual, only the hardware one, which I wouldn’t have imagined many games coders would have had.
Thanks Mike. I'd missed that one. There is a whole range of 'illegal' opcodes of course that did (possibly useful) things on various 6502 variants.
https://www.masswerk.at/nowgobang/2021/6502-illegal-opcodes
Ah yes I’m familiar with those — back at the start of the pandemic I kept myself busy by writing a Commodore 64 emulator, and had to put support for them in. I didn’t think I’d need to, but at least one mainstream game I found wouldn’t function with only the documented opcodes supported.
Very interesting. I always thought that using illegal opcodes gave an extra aura of pushing performance to the max - whether they really did or not!
Have you shared the emulator and your experience anywhere?
Well I gave a little tech talk at work at the time just for funsies. Otherwise, no presentation but you can check out the finished work here:
https://github.com/luxocrates/viciious
The game in question was PacLand, and the illegal code hit right at the start of the first scroll. For the longest time I was convinced there must be some bug in my 6502 emulator and that there can’t really be a quasi-op there (as I recall them being called back in the day in some circles). But I then implemented it and the game worked. Part of me wonders if its purpose was to confuse people trying to hack the game, to make it look like the code they were looking at wasn’t really code.
But the dummy writes thing really threw me: an instruction where I thought I knew what it did, but in the context of MMIO, I didn’t fully.
That's fantastic, thanks for sharing. I might do a 6502 resources post in the near future. Would you mind if I included this?
Oh sure, let me know if I can help at all!
One wacky thing about the emulator is it assembles its own ROMs from sources on boot. Blew my mind that the execution overhead of that was so minimal.
Navigating the memory address bug must have been hellish. Did every amateur user have to discover the big and find a solution, or was the chip basically functional and only failed in certain instances? How would you even come across the solution, clubs, hobby periodicals?
The indirect JMP one? It's really not a very impactful bug. Indirect jumps are rare in any code and are usually located in Zero Page, which many instructions wrap around in (e.g. indirect,X addressing. Also programmers will usually instinctively make the first byte be at an even address which makes page crossing or wrapping irrelevant.
Many other CPUs have memory addressing that wraps around within the page or segment, ranging from the PDP-8 to the PIC microcontroller to the SC/MP microprocessor to the 8086.
Hi Russell, That's a really good point and has got me thinking. I've done a scan of one of the most popular 6502 books 'Programming the 6502' by Rodney Zaks and couldn't find a mention. I'll do some more investigating. Might be a topic for a future post! Very best wishes.