Reading SRAM from SA-1 cart

[qwertymodo]

I've built myself a cart reader interface similar to the Retrode or Kazzo, but the one thing I've been trying (unsuccessfully) to do is to dump SA-1 games, mostly just to back up the SRAM from SMRPG, but I can't get any data from the cart. All I get is 0xFF for the entire 16MB address space. I'm assuming this has to do with the fact that the SA-1 both requires a clock signal and enforces the CIC handshake. I've wired up both, but I'm still not getting anything out. I'm currently clocking it using a 21.4772MHz crystal, but SMwiki states that it is clocked at 10.74MHz (i.e. 21.4772/2), so the next thing I'm going to try is to add a clock divider, but is there anything else I might be missing? I'm using a D411 for the CIC lock, and I've already confirmed that it should work. Maybe are there registers I need to be writing to in order to access ROM/SRAM from the cart edge?

[Ziggy587]

I remember reading (maybe a year or more ago) that they couldn't get SA-1 carts to work with the Retrode. I haven't kept up with the progress (if any) of that. Have you tried looking on the Retrode forums?

[Near]

Wish I could tell you what to do to fix it. I sent an SNES console to ikari, and he installed one of his SuperCIC chips on it.

When I hotswap a bootloader cart with an SA-1 cart, I am able to read them.

So I am not sure why the independent dumpers (yours and Matthias' Retrode) are unable to do so.

I can at least say that the SA-1 should allow you to read SRAM just fine always. The control registers are for write-protections.

[qwertymodo]

Well, for one thing I really do need to hook up an oscilloscope to confirm the clock speed info, as well as to check that my oscillator circuit is even actually working right... beyond that, it's entirely possible that the CIC lock is missing a connection, like maybe a clock signal or something, I'm not sure. Actually, having looked at the schematics posted here, I'm almost positive I don't have anything connected to the CIC pin labeled CL1, which looks like it's receiving a clock signal out of the S-DSP (3.072MHz according to the accompanying documentation, which is really close to 21.4772/7, but divide-by-7 kinda sucks). So that's probably a start...

[tepples]

The DSP side of the system contains a separate oscillator specified as 24.576 MHz, but the ratio between the CPU/PPU and SPC/DSP oscillators varies from machine to machine.

[qwertymodo]

Since I'm only talking between a microcontroller directly to the cart and I don't actually care about any other system timing, I'll bet I can get away with tweaking the clock speeds to something simpler. If the SA-1 can be slightly overclocked to 24MHz, then I could use a simple 3-bit counter to divide by 8 and get 3MHz for the CIC. That would make my life a lot easier, especially if I wanted to reproduce my design down the road. Additionally, if I ever get around to switching my design to use a PIC18F45K50, that'll be running off a 48MHz system clock, which I could then divide down to 24HMz and 3MHz, respectively, and I wouldn't even need an external crystal at all.

Edit: Despite the info I've found stating the SA-1 runs at 10.74MHz, it's connected directly to cart pin #1, which is the 21.4772MHz master clock signal, so that's what I'm referring to when I'm considering OC to 24MHz. If it divides the clock inside the chip or elsewhere on the board (which it doesn't seem to), that's irrelevant... basically I'm looking at running the SA-1 as though the SNES master clock was OC'd to 24MHz. Worth a shot to drastically simplify my hardware requirements.

[qwertymodo]

Ok, so I opened up the cart again to double check before I start wiring things up, and the only 2 pins on the expansion tabs that are actually connected to anything are pin 1 and pin 33. According to nocash's fullsnes docs, as well as others I've seen, pin 1 should be receiving the 21.4772MHz system clock signal, and pin 33 is the WRAM refresh signal. I can't find much info on the refresh signal, other than the fullsnes docs that indicate "four HIGH pulses every 60us (every scanline)". Does anybody know if that's a constant 50% duty cycle square wave at 66.667kHz, or is it 4 shorter pulses at some point during the 60uS period? I'm not even sure if that signal will be necessary for reading the ROM/SRAM, but I'm wanting to get as much information as I can before I really dig into this. Ideally, I should just solder in some flywires to those pins and then take it down to the university EE lab and hook it up to an oscilloscope, but right now I really don't have the time.

In any case, this does pretty well narrow down the potential issues to those 2 signals and the CIC clock signal, and once I get the right hardware together, I should be able to wire it up pretty easily.

[lidnariq]

The CPU is paused for 40 master cycles (per 1364 cycle scanline) for memory REFRESH purposes, effectively making the CPU around 3% slower. The CPU is also paused when using DMA/HDMA transfers.

So 10 master clock cycles (465ns) per pulse.

[Near]

I asked someone look at the WRAM refresh with an oscilloscope. I can't be sure it was accurate, but this is what he said:

The 40-cycle pulse is 5 cycles high, 3 cycles low; repeated five times. Then it stays low for another 1324 cycles before repeating again. So I guess you could technically say it's low for 1327 cycles though.

This didn't really make a lot of sense to me as it's very evident the CPU is deadlocked for exactly 40 cycles. But if we broke it down, WRAM access takes eight cycles, so it's probably pretty likely it's refreshing five cells per refresh.

If you do test and find something different, let me know :D

[qwertymodo]

Thanks for the info, that should be enough to roughly emulate the signal. Again, since this is a self-contained cart reader, I'm not constrained by synchronization to any of the other SNES systems, so I should have a pretty decent amount of flexibility when it comes to the clock signals as long as I stay within the hardware specs. However, I suppose it's worth asking, is there really any reason the refresh signal would in any way affect my ability to dump the cart? Should it even be necessary? If it is, I should be able to generate something close to that waveform on the 48MHz PIC I'll be using (4 cycles per instruction comes out to 83ns, so that'll get me close to 4 high/4 low). If not, it'd be nice to omit it entirely...

Anyway, the real test is going to be just sitting down and wiring it up, so hopefully I'll have time to do that in the next week or so.

[Near]

> is there really any reason the refresh signal would in any way affect my ability to dump the cart?

I would be shocked if it was involved in any way. The only possible use case I can find for the SA1 checking that signal is so that its memory controller can stop blocking the SA1 from the shared ROM/RAM bus, presuming the CPU was otherwise pegging it.