First of all, WS1+WS2 should probably be referred to as just "waitstates" or "extra clocks per cycle". The two games set these to 4, and as a result the Cx4 accesses ROM at 4MHz. (20MHz / 5).
The power-on default is 3 for both, thus it would access ROM and RAM at 5MHz. I can take logic analyzer traces of all that if required (which is what I did in the first place to determine waitstates, measure instruction times, etc... but I did not save the traces so I'd need to record them again.)
The DMA transfers work as described by nocash (simultaneous for independent buses, sequential for same bus).
DMA would usually take place between cartridge ROM and internal RAM, or internal RAM and cartridge RAM.
Small discourse that might deserve a thread on its own:
SNES DMA actually also works the way nocash described
Source and destination addresses are put on their respective buses simultaneously and RD+PAWR or PARD+WR are asserted depending on DMA direction.
For a memory write cycle, data usually only has to be valid a short period of time before and during the rising edge (i.e. end) of the write strobe (like 30ns or so). Thus the source has plenty of time during the active period of the cycle to put its data on the bus before it is required at the destination.
There seems to be an extra cycle before every DMA block (usually with a bogus address on the buses, and with no read or write control signals asserted) but I don't know what that's for.
So far I cannot confirm an extra cycle of overhead per HDMA channel, usually I'm just seeing one extra cycle before all HDMA channels fire in a row. Of course it would need to pause to fetch a new pointer from an indirect table, or a new count value, but as long as that isn't happening there don't seem to be any extra cycles.
Then there's the seemingly arbitrary prolongation of the previous CPU cycle, which actually just pads out to the next multiple of 8 master clocks since reset. I overlaid the RGB signal with PAWR so the B bus writes actually became visible, and HDMA is always nicely lined up in a vertical row, surrounded by regular CPU cycles jittering about around it. It recently turned out that it's important to keep phase relationship between DMA access and dot clock but that's a different topic... (maybe anybody saw the Chrono Trigger frog glitch in the demo roll, or flickering pixels around sprites in Star Ocean or Kirby Super Star... https://github.com/RedGuyyyy/sd2snes/issues/6)
Anyway, back to topic:
Just re-checked, the following regions are open bus:byuu wrote: Is it confirmed in LoROM mode that the Cx4 bus can't see ROM at $c0-ff:0000-ffff?
70:8000-77:FFFF (70:0000-77:7FFF is cartridge RAM)
A bad DMA transfer just seems to keep the CPU stalled in memory access ($7f53 bits 7 and 6 are set). Writing to $7f53 clears those bits and you can talk to the Cx4 again.byuu wrote: Does writing to $7f53 get the Cx4 out of a lockup from a bad DMA transfer as well?
It simply ignores DMA or cache page triggers as long as $7f53.6 is set. It does not execute them afterwards. It does accept all the register values though, so you could prepare everything, then just trigger DMA or cache page as soon as the Cx4 becomes idle.byuu wrote: What happens if I start a DMA or cache page operation while the Cx4 is active? Will it take priority over the Cx4 instruction processing, stay pending until the Cx4 instructions are halted, or just do nothing?
Gotta catch some sleep now