Feature Request: Expose the memory of the core to the main framework

[radon0303]

I'm not sure if this is possible for every core, I'm mainly asking from the standpoint of the SNES. It would be nice if the memory of the core was exposed to the main framework so that the core's memory can be output through USB so it can be read by a PC. Currently this works on original hardware when using an SD2SNES. You can output what's currently stored in memory over USB to your PC so that what's in memory can be used by things like livesplit or multiworld games. For example, certain games have autosplitter functionality in livesplit if you install the addon. The SD2SNES sends what's in memory to livesplit and if livesplit sees the correct values in memory it automatically splits for you.

[sorgelig]

there is no such switch which you turn on and memory will be visible. Accessing to core memory requires additional channel and bandwidth to SDRAM which in most cases absent as core uses whole possible bandwidth. Different cores use different kind of memories for different purposes, SDRAM, BRAM, DDR3. There is no common blob of memory which should be accessed from HPS. So every single core will require additional specific only to this core module. So, in other words, it's technically unreasonable restriction for cores.

[radon0303]

That's understandable that it wouldn't be a forced requirement for all cores as they are all different. Would much work need to be done to the mister OS to output that info if it was something done on a core by core basis?

[sorgelig]

Speaking about SNES specifically it's very unlikely as SDRAM is very busy there so it required additional tricks to shave cycles to fit into system requirements.

[paulb-nl]

I don't know how it works exactly with a SD2SNES but it also can't have free access to the memory of the SNES while a game is running.

Some possibilities are the game has extra code in Vblank that allows the SD2SNES to access the memory or the SD2SNES uses a "hook" to take over in Vblank which will reduce the Vblank time for the game.

[radon0303]

The SD2SNES can read the memory because the cart observes the bus and creates its own copy of the WRAM that can then be freely accessed. It's also possible to write the WRAM, but not directly. This would be difficult to implement on the SNES core because there would need to be enough room in BRAM to create a copy then, correct?

[paulb-nl]

I think the most difficult part is getting the data to the PC. On the SD2SNES there is a dedicated USB port for the FPGA which the DE10-nano doesn't have. So this just leaves communication through the network (which leaves less time for USB controller polling) or connecting a device to the User port which handles communication to a PC. (Arduino?)

The latter won't require changes to MiSTer main so I think it is the preferred way.

[radon0303]

The Arduino route sounds promising! What kind of work would that entail and would it be possible to keep SNAC functionality while reading the data through the Arduino somehow? I assume not, right?

[paulb-nl]

It would require:

• Core: Some way to freely read RAM
• Core: Communication through the User port (i2s/UART)
• Arduino or other: Communication with core & PC

i2s & UART both use only 2 wires to transfer data so it would still be possible for a standard controller to work with SNAC but that would require some creative cabling.

[dagit]

What about once a frame copying the contents of SNES WRAM (128k) to DDR memory? I believe that would allow a program running in the linux host to pull the values out of /dev/mem and then send them to the PC using whatever communication ports are available there.

[sorgelig]

it won't work. DDR cannot mirror WRAM. It will require copy from and then to WRAM which will require time and won't reflect immediate values. Also copying content will require some bandwidth which is not available.

[sorgelig]

I close this request as NOT POSSIBLE. Discussion leads to nowhere as it's technically impossible.