So I'm working on a Vic20 emulator right now and am at a point where pretty much everything but sound is working; all single-step tests etc are passing. Yay.

But I noticed something after adding some additional checks in the "memory"...there are a whole bunch of attempted writes to ROM. For the most part, they're writing back the value already there, but a couple would actually change the data. Attempted writes are to 0x8000 and 0xFD6D onwards (the latter probably even within range of the CAUSE of one of the writes)

Working from a disassembly, it appears to be the two STA's from LAB_FD64 / LAB_FE91:

.txt

I have also tried the same kind of crude trapping in a few other simple Vic20 emulators and they appear to do the same to some degree, and at first glance it seems it's the same culprits.

So I'm wondering if these kinds of things are actual legit actions these old systems took? Or from those who have built emulators (particularly the Vic20) - is it more indicative of something wrong in the emulation, the ROMs, etc? I vaguely remember something similar in the Spectrum 48k I made but that was a good few years ago..

So I'm working on a Vic20 emulator right now and am at a point where pretty much everything but sound is working; all single-step tests etc are passing. Yay.

But I noticed something after adding some additional checks in the "memory"...there are a whole bunch of attempted writes to ROM. For the most part, they're writing back the value already there, but a couple would actually change the data. Attempted writes are to 0x8000 and 0xFD6D onwards (the latter probably even within range of the CAUSE of one of the writes)

Working from a disassembly, it appears to be the two STA's from LAB_FD64 / LAB_FE91:

https://www.mdawson/vic20chrome/vic20/docs/kernel_disassembly.txt

I have also tried the same kind of crude trapping in a few other simple Vic20 emulators and they appear to do the same to some degree, and at first glance it seems it's the same culprits.

So I'm wondering if these kinds of things are actual legit actions these old systems took? Or from those who have built emulators (particularly the Vic20) - is it more indicative of something wrong in the emulation, the ROMs, etc? I vaguely remember something similar in the Spectrum 48k I made but that was a good few years ago..

• emulation
• rom
• 6502
• device-emulation

• I pretty sure they will try to do a write cycle if that is what has been coded. ISTR there were aftermarket static RAM with battery backup and write protect switch that were pin compatible with spare ROM slots on some 6502 based machines. – Martin Brown Commented Mar 6 at 17:09
• 1 There are valid reasons for writing to a "ROM" address. The most obvious is detecting whether a location (or more usually bank) is in fact ROM or RAM. Another is where a device (for example a "No Slot Clock" chip) can intercept accesses to a ROM area. And in some systems (e.g. Apple II) banking can be set to read ROM but write to RAM at the same address. – Nick Westgate Commented Mar 7 at 2:23
• The ROM chip do not have a write signal, but the processor tries to write anyway and doesn't care if it was successful or not. I don't remember the memory map of the Vic20, but it was a common technique to share a write-only control register behind a ROM address. – some Commented Mar 22 at 0:29

2 Answers 2

There's nothing* wrong with either the ROM or the emulation here. The code as written will attempt to write to ROM addresses, and the emulation should trap that and prevent the write from happening, just as it is physically impossible to write to those addresses in real hardware - usually.

I say 'usually' because there are some instances where writing to an address 'normally' expected to be ROM might actually be permissible - for example Block 5 ($A000-$BFFF) is commonly described as the 'Cartridge ROM Area' and (when a cartridge is plugged-in) will typically contain ROM which would often be a game or programmers utility tool, etc. But there's nothing stopping you from plugging in a suitably-configured RAM pack there, giving you an additional 8K to play with (though it's not visible to BASIC). That's why VICE lets you configure Block 5 as RAM, and will then allow writes to that address range.

*The code does attempt to write to ROM but this is a side-effect of the way the routine works, not an intentional act. Arguably it's sloppy code that's taking advantage of the fact that it's running in ROM, not bothering to check whether the target address is RAM and instead relying on the physical restriction of the hardware to prevent rogue writes.

I don't know about the VIC-20 but on the Commodore 64, RAM and ROM are mapped to the same addresses in the 64 KB address space.

For example, the BASIC ROM of the C64 is at addresses $A000 - $BFFF. But there is also RAM at those addresses, which you normally cannot read because the BASIC ROM is in the way.

However, one thing you could do on the C64 was this: write a loop that reads from $A000 - $BFFF and writes back to the same addresses. What would happen is that you copy the ROM to the underlying RAM (because the CPU is reading from the ROM, but writing to the RAM at the same addresses).

Then you could set some CPU control bits by writing to addresses $0000 or $0001 (I don't remember exactly), which would switch off the BASIC ROM and now BASIC would be running from the RAM at $A000 - $BFFF.

The fun thing about that is that you can now modify what's in the BASIC ROM, for example to add your own BASIC commands or other features. This was my first serious programming project on the Commodore 64 in 1986 or so...