Handling of GAME and EXROM lines of C64 cartridges is wrong

[pdaehne]

OSCR firmware version

all versions affected

OSCR hardware version

HW5 Rev6

Attach OSCR_LOG.txt file here

No response

System used

all/none/doesn't matter

Describe the issue.

The handling of GAME and EXROM lines of C64 cartridges is wrong (in C64.ino). The code configures the lines as output (going from the cartreader to the cartridge), and pulls the lines up or down. Actually, these lines are inputs, going from the cartridge to the cartreader. They are pulled to GND on the cartridge or left open to tell the C64 which memory configuration the cartridge uses (8k cartridge, 16k cartridge, Ultimax cartridge, C128 cartridge). See the schematics in the following link for more information (blog post "Making a C64 Cartridge" on "World of Jani"):

http://blog.worldofjani.com/?p=879

So currently, when the cartridge pulls these lines to GND and the code tries to pull them high, a direct short is created. I do not know how robust the output pins of the Mega 2560 are, but this does not seem to be a good idea.

I'm willing to create a pull request which removes the whole GAME/EXROM code from C64.ino, but I would like to get a "go" first before I put some effort into this.

BTW, I cannot select "C64" in the "System used" drop down of this issue, the template needs to be extended.

[sakman55]

I've made the changes to the handling of the GAME and EXROM lines.

I still have to test the modified code with Normal and Ultimax carts.

If everything works as expected, I'll update the sketch in the repository.

Thanks for posting the info on the issue!

[pdaehne]

Thanks for working on this issue @sakman55.

Unfortunately, there is an even worse problem with the adapter PCB. The C64 cartridge line PHI2 (pin E) is crucial for more complex cartridges that use bank mapping. PHI2 is a delayed copy of the CPU clock, but more importantly it tells external components when the CPU address and data lines as well as R/W and other signal lines are stable/valid (namely at the falling edge of PHI2). PHI2 is not needed for simple 8K/16K cartridges that can only be read from, but needed when writing to a cartridge, e.g. when setting bank registers.

Currently, pin E of the cartridge is connected to pin 57 of the SNES connector, which in turn is connected to CLK1 of the SI5351 clock generator. Since a few days there is a commit 4c8f826 by @smesgr9000 which initializes the clock generator, but what is the point of a clock signal which is completely out sync with all the other lines controlled by the Atmega? In my opinion, the adapter PCB needs to be changed to connect PHI2 to a regular Atmega output, and the code needs to toggle that output after setting the address and R/W lines.

[sakman55]

Control of the CPU clock line depends on the HW version. Older HW versions included a switch that allowed manual control of the clock line. For newer HW versions, users have been able to configure the clock generator to provide the necessary signals needed by other systems.

[smesgr9000]

yeah I'm also not happy with the clock gen stuff. I have the gut feeling this messes up dumping with other systems too. Couldn't proof it yet. But what to do? Without the code dumping of bank switch games does not work on HW5.

[sakman55]

One thing to keep in mind is that we don't need cycle accurate emulation of the clock. For the most part, the clock just needs to be close enough to get the cart to respond.

For instance, I'm currently working on the Atari 8-bit carts and the XE bankswitch only needs a single clock pulse to latch the bank. Another system that I worked on recently was the TI-99 that only needs a short sequence of pulses to latch the GROM address. For these systems, the manual clock signal is only called when needed.

A recommendation that I would make for the HW versions that don't have the manual CPUCLK switch is to disable the clock generator line and only enable it for the routines that need it. This could also prevent random effects due to the clock running out of sync where it isn't needed.

The change to the dedicated clock generator connection is not something that I would have adopted since we lose the ability to finely control the clock pulses. I mainly worry about breaking support for serial EEPROMs.

A solution might be to adjust the clock frequency to where an enable/disable cycle equates to a single clock pulse. If it could be timed right, then an enable/disable cycle can be invoked when we need a clock pulse (basically acting like a manual pulse).

[sakman55]

I redumped all of my C64 carts (Normal, Ultimax, Ocean) and they all dump properly with the new code.

I'll update the C64.ino later today.

The c64cart.txt for the SD card will also need to be replaced since we eliminate the port state from the file.

[smesgr9000]

I can confirm my few cards are working to. (NORMAL, Magic Desk)

[pdaehne]

@sakman55: Why did you remove the information about the EXROM/GAME lines from the database? That's valueable information which could be used to filter the cartridges in the selection menu...

[sakman55]

It wasn't needed anymore since we read the port state from the cart.

There's no stopping someone from adding the info back if they write code to filter the cart list by port state.

I can't see an overall benefit with saving a little time scrolling the cart list versus adding code to do the filtering.

As an alternative, you could probably achieve similar results by filtering by mapper.