7

According to the C64 wiki, asserting G̅A̅M̅E̅ on the cartridge port (and not asserting E̅X̅R̅O̅M̅) of the C64 leaves three blocks of the C64 address space "unmapped": 28 KB @ $1000 (otherwise RAM), 8 KB @ $A000 (otherwise BASIC ROM or, in some modes, ROMH on the cartridge) and 4 KB @ $C000 (otherwise RAM).

Is it safe for the cartridge to respond to read and write requests to these areas? (Say, because the cartridge wanted to have I/O in that area or—for some reason I can't currently fathom—its own RAM.) I assume here that the cartridge would have its own address decoding to handle this, and that the hardware would be kept off the bus until software had set up the C64 memory map properly to unmap these areas before enabling the cartridge to respond to them.

I ask because I know that even when certain onboard devices (in this case, RAM) are not mapped in, they still respond to write requests. (I have verified that writing to KERNAL ROM will of course not change the ROM, but still write to the RAM at the same addresses.)

If this is possible, are there any cartridges out there that actually use this technique?

Improve this question

2 Answers 2

Reset to default
4

asserting /GAME on the cartridge port of the C64 leaves three blocks of the C64 address space "unmapped"

No, at least not alone. /EXROM also needs to be high. Otherwise standard RAM/ROM configuration prevails.

Is it safe for the cartridge to respond to read and write requests to these areas?

Yes.

I assume here that the cartridge would have its own address decoding to handle this,

As usual, as there are no select lines beyond /ROMLOW and /ROMHIGH, selecting 8 KiB each at $8000/$E000.

and that the hardware would be kept off the bus until software had set up the C64 memory map properly to unmap these areas before enabling the cartridge to respond to them.

No, that's not necessary, as the mapping is done in hardware. With /EXROM=High; /GAME=Low all CPU side memory mapping (HIRAM, LORAM, CHAREN) is simply disabled. Attention to the CPU port signals is only required if the cartridge 'decides' to change the /EXROM;/GAME setting.

I ask because I know that even when certain onboard devices (in this case, RAM) are not mapped in, they still respond to write requests.

Yes, but that's not for 'certain' devices, only the RAM. Its handling and timing is entirely controlled by the 82S100 PLA. THe very same chip doing the EXROM/GAME decoding. So the effect is either on purpose or more plausible simply due not caring. It generates RAS/CAS signalling for each and every access, no matter what address is used (*1).

If this is possible, are there any cartridges out there that actually use this technique?

I bet some did.

*1 - That way, even the RAM behind the build in port at 0000/0001 gets writen each - also great for external (debugging) hardware to help follow up on it's state

Improve this answer
3
  • So to clarify, the RAM chips' write enable (W̅) is asserted for every write cycle in the C64 regardless of what other devices are also enabled? Asserting just R̅A̅S̅ and C̅A̅S̅ is not enough for the RAM to do a write.
    – cjs
    Sep 20, 2019 at 14:58
  • @CurtJ.Sampson Right, WE is the signal indicating that a write is to be made. A RAS/CAS cycle only defines a read - with the extended CAS signal as well used for read enable. One issue with the C64 design is that OE is grounded.
    – Raffzahn
    Sep 20, 2019 at 18:36
  • Acutally, according to this answer writes to $0000 and $0001 do not write through to RAM.
    – cjs
    Sep 21, 2019 at 17:39
2

To add to user Raffzahn's answer - this

It generates RAS/CAS signalling for each and every access, no matter what address is used (*1).

would imply that - talking about a system without any cartridges inserted - when a Program writes to the I/O area, for example some VIC or CIA hardware register, RAM memory in the $Dxxx area gets clobbered. Unless I'm quite mistaken this is not the case - I've used this memory back in the day, must have been around 1989/1990, to "hide" code when modifying a game that otherwise didn't use it (the game was called Die Dunkle Dimension, kind of a German Ultima IV clone), to put fastloader code there - in addition to a small stub elsewhere that disables interrupts, enables all of RAM and then jumps to $D000. The code there would swap part of the contents of $Dxxx with e.g. $Cxxx and then jump there. The code there would re-enable I/O, do the actual fastloading, then at the end disable I/O again, jump into the $Dxxx area, code there would swap things back and return to the stub, which would re-enable I/O and return to the actual game. The details are quite foggy after such a long time, but none of this could have worked if writing to the I/O area had modified RAM at $Dxxx.

Before anybody asks, I gave away all my old C64 disks a few years later, so no, I don't have this modified version of DDD around any more.

Improve this answer
1
  • It might be helpful to keep in mind, that the above question is about EXROM/GAME setting, not I/O mapping, which comes in addition?
    – Raffzahn
    Oct 21, 2019 at 15:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .