It is currently Wed Oct 17, 2018 7:58 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Sat Aug 25, 2018 3:14 pm 
Offline

Joined: Thu Jun 30, 2016 7:46 pm
Posts: 6
Hi =^-^= I make the practice ROMs for the SNES Rockman X games. They add features like giving you the appropriate items for the route when selecting stages, and importantly, adding saved states.

With X2 and X3, the practice ROM can of course only run flash carts that have a way to support Cx4 games. SD2SNES supports up to 256 kilobytes of SRAM, which is enough to store a SNES saved state.

X2 and X3 put their NMI handlers into WRAM instead of ROM. Is this because the Cx4 locks out the 65816 from ROM access sometimes?

I need to add a considerable amount of code to the NMI handler for the saved state system. If the Cx4 locks out ROM, can I put my extra NMI code into SRAM instead? Because there are no native Cx4 games with SRAM, whether SRAM gets locked out while the Cx4 is locking out ROM is entirely defined by the SD2SNES, as the only cartridge that supports Cx4 with SRAM. I don't know how to determine whether the SD2SNES locks out SRAM like this, though.

Finally, how could I save and restore the state of the Cx4 in my saved state system?


Top
 Profile  
 
PostPosted: Sat Aug 25, 2018 4:09 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 421
Location: FL
The Cx4 locks out both ROM and SRAM whenever it's accessing either of them. Most of the time it's either running code from its internal cache or not running at all, but otherwise it claims the cartridge bus when caching a new code page, performing DMA, or reading/writing individual ROM/RAM addresses.

ikari_01 put a bunch of relatively recent Cx4 documentation here, though basically none of it is currently implemented in the sd2snes, so the current firmware shouldn't be considered an accurate reference implementation at this point. I've been implementing as much as possible of it in bsnes-plus, but I can't claim 100% accuracy with that either, but those notes are based on actual hardware behavior.

Some of the Cx4's state is available via memory-mapped registers, though there are some important parts (particularly the cache status) which I don't think are externally accessible, so I'm not sure that saving/restoring its state via the SNES CPU is actually meaningfully possible.


Top
 Profile  
 
PostPosted: Sat Aug 25, 2018 8:10 pm 
Offline

Joined: Thu Jun 30, 2016 7:46 pm
Posts: 6
Revenant wrote:
The Cx4 locks out both ROM and SRAM whenever it's accessing either of them. Most of the time it's either running code from its internal cache or not running at all, but otherwise it claims the cartridge bus when caching a new code page, performing DMA, or reading/writing individual ROM/RAM addresses.


Is the 65816 halted during this? If it's halted, why is the NMI handler in WRAM instead of ROM?

How is it known that the Cx4 locks out SRAM, since X2 and X3 don't have SRAM?

Thanks!


Top
 Profile  
 
PostPosted: Sat Aug 25, 2018 10:11 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7657
Location: Seattle
Nothing can stop the SNES's CPU other than its own DMA unit; it has to wait for the CX4 to be done.

The CX4 has a 32 bytes of RAM that replace all of the SNES's vectors while the CX4 is hogging the ROM. The game has to use this to point to an alternative vector in the SNES's own WRAM.


Top
 Profile  
 
PostPosted: Sat Aug 25, 2018 11:32 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 421
Location: FL
Myria wrote:
How is it known that the Cx4 locks out SRAM, since X2 and X3 don't have SRAM?

RAM areas read back all zeroes whenever there's none available (or when the Cx4 is accessing the bus).


Top
 Profile  
 
PostPosted: Sun Aug 26, 2018 11:50 pm 
Offline

Joined: Thu Jun 30, 2016 7:46 pm
Posts: 6
lidnariq wrote:
The CX4 has a 32 bytes of RAM that replace all of the SNES's vectors while the CX4 is hogging the ROM. The game has to use this to point to an alternative vector in the SNES's own WRAM.


Looking at X2, I don't see anything on the 65816 side writing to 7F60. The NMI and IRQ handler addresses in the ROM header point to WRAM.

Revenant wrote:
RAM areas read back all zeroes whenever there's none available (or when the Cx4 is accessing the bus).


That sounds very bad to me, because it means that I need to find a place to store several kilobytes of extra code in WRAM. I can't use ROM because the Cx4 locks it out (same reason NMI handler is in WRAM), but it sounds like I can't use SRAM, either, because that's locked out too.


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 6:48 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 651
Myria wrote:
That sounds very bad to me, because it means that I need to find a place to store several kilobytes of extra code in WRAM. I can't use ROM because the Cx4 locks it out (same reason NMI handler is in WRAM), but it sounds like I can't use SRAM, either, because that's locked out too.

Depends on when you need to access SRAM. The CX4 seems to be used mainly for executing "small math functions", and it stops running after each such function call (not to mention that you could also manually pause/unpause the CX4 if needed).
Just hook the original code so that your own code gets executed when none of that CX4 functions is being executed - then you have full access to SRAM (and ROM).

Myria wrote:
Looking at X2, I don't see anything on the 65816 side writing to 7F60. The NMI and IRQ handler addresses in the ROM header point to WRAM.

Look again ; ) 7F6xh is written in the very first function being called after reset/entrypoint at 0:8000h.
Also mind that the ROM vectors MUST point to the same addresses as the 7F6xh vectors (see the warning about possible problems in fullsnes.htm) (and the thread with ikari's newer CX4 findings has later confirmed that the ROM vectors really cannot be disabled when CX4 gets paused).

Btw. the reason why ROM+SRAM are both disabled when CX4 is running is seen in the CX4 pinout: It's having two address/data busses, one for "SNES" and one for "ROM/SRAM". So if CX4 is accessing ROM or SRAM, then SNES accesses cannot be forwarded to the ROM/SRAM bus (if you are wondering if the SRAM was really supposed to be wired to the ROM/SRAM bus: it must be so because ikari mentioned that CX4 can do DMA to/from SRAM, which won't work if SRAM were wired to SNES bus).


Top
 Profile  
 
PostPosted: Tue Aug 28, 2018 9:08 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1389
Quote:
and the thread with ikari's newer CX4 findings has later confirmed that the ROM vectors really cannot be disabled when CX4 gets paused


Wait ... so the Cx4 always overrides the ROM vectors, no matter what?

So in that case, it's not possible to dump the actual values in the mask ROM chips through the SNES cartridge bus, and instead you get whatever the Cx4 initializes those registers to, yes? Not a real problem in context, but ... very interesting.


Top
 Profile  
 
PostPosted: Tue Aug 28, 2018 11:38 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 651
No, I meant this:
CX4 running --> use 7F6xh vectors (from I/O ports)
CX4 paused --> use FFExh vectors (from ROM)
CX4 just changing between run/pause state --> possibly use a mixup of low-byte and high-byte from ROM and I/O vectors


Top
 Profile  
 
PostPosted: Sun Sep 02, 2018 10:03 pm 
Offline

Joined: Thu Jun 30, 2016 7:46 pm
Posts: 6
Is there a way to know whether the Cx4 is currently locking out ROM and SRAM? Also, will the Cx4 take control of ROM/SRAM suddenly, or does it have to be triggered by something on the 65816?


Top
 Profile  
 
PostPosted: Sun Sep 02, 2018 11:15 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7657
Location: Seattle
Lower level details in ikari_01's post and some programmer's details in nocash's documentation.

Direct answers:
[$007F53] & 128 indicates if the CX4 is hogging the bus

If the CX4 is still executing code, it can steal the bus at any time. This could either be loading a new 512b cache line, or just using its own "access ROM/RAM" opcode. The CX4 can choose to stop itself. The SNES can tell the CX4 to stop indefinitely or for a predetermined short number of cycles.


Top
 Profile  
 
PostPosted: Wed Sep 05, 2018 8:18 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 421
Location: FL
As for being able to make the SNES save the state of the Cx4, I suppose you could modify the $7fxx writes to also keep track of them somewhere else in RAM to be able to read/reapply them later, or possibly use the status flags to determine whether or not attempting to restore the entire Cx4 state is even necessary at a given point (i.e. if it's not currently running, you probably only need to save/restore its internal RAM and maybe preload cache pages again without having to actually rerun any Cx4 code).

There are a lot of features of the chip that neither game actually uses, and I don't think any of the Cx4 routines in either game ever cross over to adjacent pages, so you could probably at least assume that whichever pages are precached/directly referenced by the game will still be valid if the Cx4 is still running when a state is saved. Unfortunately when loading the state you'd probably have to basically restart whatever routine was being executed without some specific state information, which would likely lead to some minor sync issues (but at least it should be consistent when repeatedly reloading the same state?)


Top
 Profile  
 
PostPosted: Wed Sep 05, 2018 7:03 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1389
Adding fuel to the speculation fire that MMX3 is just a ROM hack of MMX2 ... the Cx4 programs on both carts are identical save for a single byte (not even sure what the one byte change was for.)

Also, there's a command to suspend the Cx4 indefinitely from the CPU side, then you can just unpause it when you're ready.

It's lucky for emudevs, but unlucky for hackers, that the SuperFX and Cx4 don't bother with bus contention handling like the SA-1.


Top
 Profile  
 
PostPosted: Thu Sep 06, 2018 8:43 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 651
byuu wrote:
Adding fuel to the speculation fire that MMX3 is just a ROM hack of MMX2 ... the Cx4 programs on both carts are identical save for a single byte (not even sure what the one byte change was for.)

That's like arguing that Super Mario Kart is just a ROM hack of Pilotwings... because they are using the exact same DSP-1 code! ; )
The (two) changed bytes in the CX4 code are described in "SNES Cart Capcom CX4 - Functions" chapter in fullsnes.htm.
It's quite unlikely that average amateur graphics ROM hackers would know how to patch that two bytes.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group