Sorry, I was just being lazy and using the SRAM chip timings from my copier.
SlowROM = 8 clocks at 21.477MHz, FastROM = 6 clocks at 21.477MHz.
Every time I divide by such large differences I get 1.NNe results, bleh.
Watching a bit of Star Ocean I saw that after some seconds the CPU clock (not the 21MHz system clock) is regularly held low for a short time once per line, in addition to the refresh pause.
Do you have the ability to run oscilliscopes on these lines? If so, could I ask you a huge favor? Could you please check the frequencies of the S-CPU and S-SMP clocks? We know the S-SMP typically runs a little faster than spec (~24606720hz instead of 24576000hz stock.) I'd like to know if the S-CPU is similarly off by any significant margin. Would need to know your region too, eg NTSC or PAL.
As for Star Ocean, I'd have to know what the CPU pin did exactly to have any idea why it's doing it. I don't think anyone fully understands how that chip works. Probably a lot of onboard logic to "detect" DMA starts (eg suddenly the read address changes significantly after it sees a $420b write on the bus.)
What I'm trying to figure out (to decide which SNES pins I actually have to connect to the FPGA) is how the SA-1 manages to halt/suspend the S-CPU during concurrent access of the same memory area (e.g. both SA-1 and S-CPU access the ROM).
Not possible. What happens is the SA-1 stalls its own CPU whenever the S-CPU tries to access the same logical device (I-RAM, BW-RAM or ROM.) It's actually quite complex the way it interleaves memory accesses. Very difficult to emulate.
The SuperFX doesn't have this problem since they cannot share ROM / RAM at the same time. There's a bit setting that tells you which chip can access it. If the GSU/SFX has control, the S-CPU gets back pre-determined "dummy" results:
Code: Select all
uint8 SuperFXCPUROM::read(unsigned addr) {
if(superfx.regs.sfr.g && superfx.regs.scmr.ron) {
static const uint8_t data[16] = {
0x00, 0x01, 0x00, 0x01, 0x04, 0x01, 0x00, 0x01,
0x00, 0x01, 0x08, 0x01, 0x00, 0x01, 0x0c, 0x01,
};
return data[addr & 15];
}
return memory::cartrom.read(addr);
}
... used to fake interrupt vector fetching to point it at WRAM locations.
If the S-CPU has control and the GSU tries to access ROM / RAM, it will lock the chip until the S-CPU gives control back.
Much nicer to emulate.
Nothing? I don't believe any carts contain PSRAM.
The BS-X Satellaview base cart has PSRAM. I don't know if any carts make use of the /REFRESH signal or not, though. I'm more of a software guy ...