Handling of GAME and EXROM lines of C64 cartridges is wrong about cartreader HOT 9 CLOSED

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!

from cartreader.

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.

from cartreader.

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.

from cartreader.

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.

from cartreader.

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).

from cartreader.

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.

from cartreader.

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

from cartreader.

@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...

from cartreader.

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.

from cartreader.