SIMCRT: ActionReplay does not work properly

[sy2002]

Starting the FREEZER menu crashes the core
https://github.com/MJoergen/C64MEGA65/assets/6825267/6c5ae563-e6aa-4bee-9ed3-e2a55684cb95

Installing the fastloader does not work
https://github.com/MJoergen/C64MEGA65/assets/6825267/bb47a6a1-ce5b-4cc3-85af-5c9c0af52bf4

[MJoergen]

Just some notes for myself: So far, I'm concentrating on the fastloader, since that seems the easiest to debug.

Observations

This CRT file (and the fastloader) works fine in VICE.

1. After startup, the core is in 8k game mode.
2. When pressing the F7 button the core copies code from $8580- into $0400- and jumps there.
3. Then it writes $23 to $DE00. This switches the core into Ultimax mode.
4. Then it copies from $FF00- into $9F00- and jumps to $9FB7.
5. Then it writes $00 to $DE00. This switches the core back into 8k game mode.
6. Then it jumps to $DFDE and writes $08 to $DE00. This switches to bank 1.

Analysis

My guess at the moment is that the problem is in step 3.

The CRT file contains just 4 banks, all with load address of $8000 and length $2000, and numbered from 0 to 3.

The file crt_cacher.vhd presumably only maps into the LORAM and not the HIRAM needed for Ultimax mode.

One fix would be to load chip contents into both LORAM and HIRAM. This will work as long as we are not overwriting anything in HIRAM.

[MJoergen]

To be specific, the fix I'm contemplating is the following:

diff --git a/CORE/vhdl/crt_cacher.vhd b/CORE/vhdl/crt_cacher.vhd
index f02801a..61ab019 100644
--- a/CORE/vhdl/crt_cacher.vhd
+++ b/CORE/vhdl/crt_cacher.vhd
@@ -145,6 +145,7 @@ begin
       if rising_edge(clk_i) then
          if cart_bank_wr_i = '1' then
             if cart_bank_laddr_i <= X"8000" then
+               hibanks(to_integer(cart_bank_num_i(5 downto 0))) <= cart_bank_raddr_i(22 downto 0);
                lobanks(to_integer(cart_bank_num_i(5 downto 0))) <= cart_bank_raddr_i(22 downto 0);
                if cart_bank_size_i > X"2000" then
                   hibanks(to_integer(cart_bank_num_i(5 downto 0))) <= cart_bank_raddr_i(22 downto 0)+ ("000" & X"02000");

[sy2002]

@MJoergen Is this a dangerous fix and could it affect other cartridges? If so, I propose to make this a "V6 or later" thing. Too many people already tested too many CRTs as you might have seen in the #c64 core channel on Discord. They won't retest everything for the release.... ...which is why I start entering "Paranoid Mode"(tm) :-)

[MJoergen]

I'm having the same reservations. I would like to try the fix in a local debug build, in order to test the hypothesis. If this fix works, thus confirming the above analysis, then indeed we should postpone it. The reason is that crt_cacher.vhd is common for all cartridges, and the assumption "This will work as long as we are not overwriting anything in HIRAM." is not easily verified.

If the proposed fix does not solve the current issue, then more debugging is needed.

[MJoergen]

Ok, the one-line fix does not fully solve the issue. With the change, the fast-loader does start up, but no READY prompt appears, and the core resets after a few seconds.

I conclude that the initial hypothesis (failure in step 3) is correct, but not sufficient to solve this issue.

[MJoergen]

Problem has been reproduced in simulation!

With the above-mentioned fix (implemented in commit ad8ab5d) the CPU encounters an unintended BRK instruction at $DF11:

CPU: DF0C : A9 LDA : F56FDFF7
CPU: DF0E : 8D STA : 206FDFF7
Write 0x20 to 0xDE00
CPU: DF11 : 00 BRK : 206FDFF7

The same sequence in VICE shows a different result:

.DF0C 264 035    3574403  A9 20       LDA #$20   f56fdff7
.DF0E 264 037    3574405  8D 00 DE    STA $DE00  206fdff7
.DF11 264 041    3574409  A5 01       LDA $01    206fdff7   

The behavior of VICE is correct, and the address $DF11 should be a mirror of address $9F11 in the cartridge.

[MJoergen]

Apparently, in VICE, values written to $9F11 is also written to $DF11, at least when bit 5 of $DE00 is set. This seems to be confirmed by the schematic at https://www.zimmers.net/anonftp/pub/cbm/schematics/cartridges/c64/freezer/MK.gif :
The PLA input is "10101001" and the output is "0101" indicating access to RAM.

[MJoergen]

More debugging shows that the same happens during read: When bit 5 of $DE00 is set, reads from CART ROM LO (i.e. $8000 - $9FFF) actually read from the cartridge RAM, not the cartridge ROM.