Allow save games in nestang core

[siffland]

This works in the snestang core, can it be ported to the nestang core to allow for saves to be enabled.

[fjpolo]

It's already enabled. You need r0.10 and to allow it from the options. I tested it on Kirby's Adventure (Germany).nes

Edit: after a power cycle, saves are gone ⚠

[siffland]

It creates the snestang.ini (even on the nestang core it is named snestang.ini) and when i load the snestang core it saves everything perfectly fine in the saves directory, but the functionality is not there on the nestang core (to survive the power cycle).

[nand2mario]

RAM backups are not implemented yet. It requires some changes to sdram_nes.v to allow RV to access CPU/PPU memory.

[fjpolo]

RAM backups are not implemented yet. It requires some changes to sdram_nes.v to allow RV to access CPU/PPU memory.

What exactly are the necessary changes?

I was trying to work on this one and then I realised exactly that, RV doesn't have access to NES RAM. I thought about backing up 0x6000-0x8000 in a local bram block inside sdram_nes.v but I also realised that rv_addr[22:0] is not wired completely to sdram instances, only rv_addr[20:2] but being used inside sdram as rv_addr[20:1] so I don't completely follow the address range of rv_addr so it can access NES' 0x6000-0x8000.

My idea was that, when RV was reading from 0x6000-0x8000, then sdram module would output the info saved in the BRAM block. If RV is writing into that range (load from sd card) then add some logic for the NES part of sdram controller to allow it

[nand2mario]

BSRAM backup in snestang is easy because both RV and BSRAM uses the same memory bank (bank 1), with BSRAM access from CPU taking precedence:

        if (bsram_req ^ bsram_req_ack) begin
		next_port[0] = PORT_BSRAM;
		next_addr[0] = { 5'b01_111, bsram_addr };       // BSRAM at start of 7MB bank 1
		next_din[0] = { bsram_din, bsram_din };
		next_ds[0] = {bsram_addr[0], ~bsram_addr[0]};
		next_we[0] = bsram_we;
		next_oe[0] = ~bsram_we;
	end else if (rv_req ^ rv_req_ack) begin             // RV uses bank 1 and has lowest priority
		next_port[0] = PORT_RV;
		next_addr[0] = { 2'b01, rv_addr, 1'b0 };
		next_we[0] = rv_we;
		next_oe[0] = ~rv_we;
		next_din[0] = rv_din;
		next_ds[0] = rv_ds;
	end 

So BSRAM automatically maps to 0x700000 in RV memory (or 0x100000 on the nano with 2MB banks). In firmware.c, bsram is simply a hardcoded pointer:

    uint8_t *bsram = (uint8_t *)0x700000;			// directly maps to BSRAM

The nice thing about this design is that as RV already has lower-priority than CPU, its access never conflicts with the CPU. So backup/restore is done silently in the background.

Nestang's sdram_nes.v currently puts CPU and PPU memory in a single large 4MB space, using bank 0 and 1. BSRAM is some where in it, depending on the mapper (I haven't really looked at the details yet). RV is using bank 2. So RV does not have access to BSRAM now, without stopping the CPU first.

There are multiple ways we can do this. But one would be to separate out BSRAM from the 4MB block, and put it in the RV bank (bank 2). Then adds logic to make RV access lower priority, similar to snestang's memory controller. Then we can probably reuse the firmware logic to save and restore the bsram.

[nand2mario]

Another way (probably easier if performance turns out ok), is to let the memory layout stay the same, then simply make RV access lower priority than CPU (thus making the memory controller single-channel). This way, whenever RV is accessing memory, the CPU is not. Then we are free to change the address lines for RV to directly access the BSRAM content.

[fjpolo]

So I actually tried to have CPU/PPU and RISC-V in the same bank: Bank0/1. I did the changes in fjpolo/WRAM branch but I wasn't able to boot RV yet, there's no menu booting up, so I might be missing something in the logic, or in the Fw (I didn't change anything in the Fw). Would you mind taking a look? There's no actual rush, so only if you've got some spare time :)