Wednesday 3 January 2018

[M]Ultimax and other Cartridges on the MEGA65

Now that we have one cartridge working on the MEGA65, I thought I would go through my collection of cartridges, and see which ones work, and try to get non-working ones to be working ones.

The bulk of the cartridges I have are the official Commodore released ones, plus a few odds and sods. Most had been sitting in my shed or someone else's shed (and in one case, it looks like in their sand dune) for some time.  So the first test of them all was not particularly successful, as the contacts were all so dirty that most of them didn't work.  15 minutes with some isopropyl alcohol and some cotton swabs fixed that problem, however.

So the current status of the cartridges is as follows:

Radar Rat Race (x2):  These cartridges use the Ultimax (or is it Multimax?) mode of the C64. This means that the KERNAL ROM is replaced by the cartridge ROM, and that most memory is not available. It also means that the cartridge ROM needs to be visible to the VIC-II at $3000,$7000,$B000 and $F000, so that it can be used to contain character sets etc for games.  This is a bit of a problem for the MEGA65, because the VIC-IV can't even talk to the cartridge port, and its pixel clock is 100x faster than the cartridge clock (although we can increase that on the MEGA65, but that's for a future post).  However, we have an easy work around: Kickstart can copy the 4KB of ROM into those locations in RAM from the Hypervisor, before exiting to Ultimax mode where those portions of RAM are no longer visible to the CPU (actually, they are currently still visible on the MEGA65, but this will get fixed in time).  In the process of testing this, and trying these cartridges I also found a few bugs in the memory mapping for Ultimax mode, which didn't surprise me, as it hadn't been previously tested.  However, after all that, the cartridge happily loads.



Number Nabber Shape Grabber



Wizard of Wor, which I remember being one of the most popular in our circle when I was young.

Pinball Spectacular, which we all complained bitterly was hardly a pin ball game when you controlled it with paddles, and that it was more like a breakout/arkanoid with spectacularly average graphics, but anyway.



Dragonsden, which I had never heard of before, but looks like it has the potential to be a bit of fun for the kids.




International Soccer, which we already know works:




The cartridges that don't currently work:

KINDERCOMP from Spinnaker Software (because it is too big to fit in the hole in my current prototype case. I will file the hole out bigger later.

Epyx Fastload. This one just doesn't seem to do anything. It might be that I have some signalling wrong.

Action Replay VI.  This signals that it has ROMs, but I think it is presenting it's onboard 8KB RAM instead of the ROM at $8000.  The IO area does decode correctly, however, which is nice. The main problem is that the ROM doesn't appear at $E000. Again, this might be a problem of me not having the various signals set correctly, or the timing being wrong in some way.

Super Games.  This one seems to still have a problem, as it doesn't start, and the area where the signature byte should be doesn't reliably read. Here is the sort of thing I am seeing with it when I repeatedly read it:

m7018000
 :7018000 4C 4C 0A 4C C3 4C CD 38 4C 00 4C 80 4C 4C 85 4C
.m7018000                                                      
 :7018000 4C 4C 4C 80 4C 4C CD 4C 4C 00 4C 4C A0 4C 4C FB
.m7018000                                                      
 :7018000 0A 80 4C 80 C3 4C CD 4C 30 4C 4C 80 4C 00 4C FB
.m7018000                                                      
 :7018000 0A 4C 4C 80 4C 4C CD 4C 30 4C A9 80 4C 00 85 4C
.m7018000                                                      
 :7018000 4C 80 0A 4C C3 C2 4C 38 30 4C A9 4C A0 4C 4C FB
.m7018000                                                      
 :7018000 0A 80 4C 80 4C C2 4C 38 4C 00 4C 80 4C 00 4C FB
.m7018000                                                      
 :7018000 4C 4C 0A 4C 4C C2 4C 4C 30 4C 4C 80 4C 4C 85 4C
.m7018000                                                      
 :7018000 4C 80 0A 4C C3 C2 4C 38 4C 00 4C 4C A0 4C 85 4C
.m7018000                                                      
 :7018000 0A 4C 4C 80 4C 4C CD 4C 4C 00 4C 4C A0 4C 4C FB
.m7018000                                                      
 :7018000 0A 80 4C 80 4C C2 4C 38 4C 00 4C 80 4C 00 4C FB

It might be a timing thing, or it might be a crusty old cartridge thing. This one does tellingly have some masking tape wrapped around it, suggesting it has been in for surgery in the past:

[ Picture of taped up cartridge]


Opening it up, it has two ROMs and a couple of glue logic chips to select which ROM is visible.  Even though it contains International Soccer as one of the three games, it isn't an Ultimax-mode cartridge. Instead, it just maps 8KB at $8000, but has the means to bank between, presumably, four different banks in the two ROMs using the 74LS175 (quad flip-flop) and 74LS139 (2 to 4 line de-multiplexor).  I am guessing that the function here is to latch some of the bits written to $DFxx (via /IO2 feeding the flip-flop) to use for the upper address bit on the ROMs, and use the 2-4 decoder to select the correct ROM chip's output-enable line. All very nice and simple. However, something is unstable, which I need to investigate. 

Part of me suspects that it is a faulty 74LS chip, and the other part of me wonders if it isn't a timing issue on the cartridge port, although given how sloppy the C64's timing was originally, and how I am switching all signals within 20ns of one another, I am not convinced that this is that likely. That said, when I stuck the oscilloscope on all the pins of the 74LS chips, nothing was unstable. What was interesting, is that the 1MHz clock appears to be one of the inputs to the de-multiplexor. This does have implications, because currently my expansion port controller tries to cheat a bit, and will make accesses on both sides of the clock, instead of just on the "CPU" side.  However, it seems that this is a bad idea, after all, which on reflection, I should have realised at the time. So I will need to fix that.  Tellingly about half of the bytes read in the unstable reads are identical ($4C), suggesting that something is wrong 1/2 of the time.  This fix might also help the fast loader cartridges, although I suspect there is more to their problems, especially for the Action Replay.

So, the current summary is not too surprising: Almost all the Commodore issued cartridges work, with the exception of one that has revealed a clock problem that will be easy to fix.  The two fast load cartridges also have problems, which I am not over surprised about, as they are more complex. But those problems should be fixable.  Finally, there is one that just doesn't physically fit at the moment. I'll file the hole in my make-shift "case" to make room for it, and retest it.

4 comments:

  1. Freezer cartridges like the Action Replay, FC3, Power Cartridge and so on implement a register that does dynamic cartridge mode switching (and usually also ROM bank switching). What I think is going on is that the AR by default boots in 8K or 16K cartridge mode, because a freezer cartrdige wants the KERNAL to do its normal initalization, booting in Ultimax mode is not a good idea, they usually take control using the CBM80 signature.

    But if the cartridge wants ROM to appear at $E000, it needs to reconfigure the C64 into Ultimax mode. Dynamic cartridge mode switching seems to be mutually exlusive with copying catridge ROM into RAM to me, so I think this cannot work.

    ReplyDelete
    Replies
    1. Yes, I agree. However, the strange thing is that I am not seeing anything sensible from the AR when it boots: It seems to be presenting its 8KB RAM at $E000. It might be expecting a functional reset line or similar. I will investigate when I have time.

      Delete
    2. That might very well be the case, since these cartridges implement their switching register often with a 74xx flip-flop that gets restored to the default value by the reset line. If the flip-flop powers up in a state that matches Ultimax mode and then doesn't get initialized with the right value by the reset line, this could explain the behaviour.

      Another theory is that perhaps the freezing circuit gets activated. If the cartridge wants to freeze it, it activates Ultimax mode and then triggers an NMI. Allthough I expect that the cartridge itself should initiate the freeze process, perhaps there is some interaction with the NMI line or another line that would trigger the freeze circuit, which could explain why the cartridge presents itself in Ultimax mode.

      Delete
    3. These are quite probable theories. I will look into this once I get a few other things finished.

      Paul.

      Delete