Support for Retro Replay (32k RAM)

[lubber-de]

Description

The readme says "only" the original Action Replays 4/5/6 are supported. Those had 8kb extra RAM
The Retro Replay, while backward compatible , had (and uses) 32kb RAM

Will KungFu Flash support full Retro Replay compatibility in the future? Or did i misunderstood the compatibility ?

[KimJorgensen]

You are correct that Retro Replay (CRT type 36) is not supported at the moment and I'll label this issue as an enhancement.

[SvOlli]

There seems to be a bit more to it. I did a quick-hack implementation of the Retro Replay on the current master implementing the following features:

• using the AR code to run the RR image
• implementing the extra bit of the ROM selection (RR uses 64kb images instead of AR's 32k)
• the selection of the four 8k ram already seems to be implemented

What I didn't implement was the $DE01 register (see: http://wiki.icomp.de/wiki/Retro_Replay#.24de01_write)

For this I had two test cases:

• an 64k expanded Action Replay
• rr38p-tmp12, Retro Replay with Turbo Macro Pro assembler (https://csdb.dk/release/?id=197306)

I could dump all banks from my "AR+" cartridge, so banking seems to work, but the rr38p-tmp12 does not work, so there still is work that needs to be done. I'm not sure, if I will pursue further development.

P.S.: Kim, it's awesome, how easy it was to add my expansion. Thanks for that.
And also a question on how to progress, if I do so:

• Should the RR emulation should be integrated into the AR code (since RR claims to be fully AR compatible), or should I create a new file for RR emulation?
• Should I create a pull request for a partial working implementation?

[KimJorgensen]

@SvOlli Thank you for the offer, but I'm not really keen on adding quick hacks or partial working solutions to the repository. This will make the maintenance of the code harder, and potentially generate bug reports and annoy users.

I'm not opposed to extending the Action Replay emulation to 64kb if it is compatible and there is a real use case. But I think it is a bad idea to allow emulation of Retro Replay images before emulation is reasonable complete.

[SvOlli]

I read a bit deeper into the documentation, and there are quite some features that lead me to the following conclusions:

• it doesn't make sense to integrate anything only half-done
• the RR is much more complex than the AR, even though it maintains compatibility
• trying an integration might be fun, let's see if I can spare enough time for this
• therefore I'll move development to a separate source code file, this way I've always a working AR emulation on my KFF, no matter how bad I messed up the RR code. Once I've got something that might be useful, we can still discuss if that code replaces AR or will be integrated on its own.

And I also noticed something: the timing of the KFF in AR mode is very delicate. I tried it on the following systems (all PAL machines):

• C128D (1st, non CR)
• C64 Reloaded MK1
• C64 Reloaded MK2
• Ultimate 64

On those the AR emulation was only stable on the C128D, on all "retro machines" the system crashed with the following "symptoms" (result differs from machine to machine, as well as from try to try):

• screen turned blue, but crashing during output of startup menu (sometimes with a "broken charset")
• normal reset with 30719 basic bytes free
• startup menu works, but selecting "F7 - install fastload" crashes the system with "broken charset" like mentioned above

[KimJorgensen]

@SvOlli I have regular tested AR on 5 different Commodore produced C64s and a C128 and do not have the problems you describe. Not that there are no timing variations between these old computers, there are, but based on what you are seeing it seems that the Reloaded and Ultimate has slightly different timing requirements than a "real" C64.

It is true that for the AR emulation the timing is tight and there is very little headroom for adding more functionality.

[SvOlli]

Thanks for verifying this. From what I can tell, problems got less when my 3D printed case was finally completed, and I wasn't working with a bare PCB any more.

About the timing being tight in the AR emulation: I noticed that, when trying to implement Atomic Power, which is Action Replay with one extra config. The problem there was, that I could not tell, if I was breaking the system with bad code or timing. I'll give it another try soon. The idea for progressing is right now: from AR to Atomic Power to Retro Replay.

[KimJorgensen]

If you had problems with the board then you should check that the connector is nice and clean. I had a board that sometimes would crash the C64 by pressing down on it. After cleaning the connector they problem went away.

[SvOlli]

I did some tries in implementing Retro Replay, or as an interim step Atomic Power, which is just Action Replay with a special addressing, allowing the ROM to stay at $8000 and map the RAM to $A000.

Correct me if I'm wrong, but it looks like even adding an additional if statement to figure out if it's running in that special mode results in the data sometimes being written too late to the bus, so it's not accurate all of the time. I noticed once the "CBM80" identification changed to "KBM80" which would indicate just one out of 40 bits being pulled low too late.