FX GSU1/2 question

I looked up the FX pinout on the NoCash web site and pin 34 (on GSU1) and pin 35 (GSU2) are "/RESET". Someone correct me if my thinking is wrong here please.... If this line is grounded, does this place the GSU chip inactive? Similar to the /CE on a EPROM but inverted?

I want to reprogram my flash rom while still mounted to the FX cartridge but it won't program due to conflicts with the GSU chip.

Thanks for any help!

Moderator: Is this posted in the correct forum?

Edit: here's the link... http://problemkaputt.de/fullsnes.htm#sn ... tsgsuchips

I don't think anyone will know the answer. You might just have to experiment and find out.

The SNES 5A22 CPU itself definitely does not tristate its address lines on reset. That was a real bummer for me.

Do you have something simple like a logic probe to put on an address line while holding it in reset?

If you don't have that, since we're talking push-pull logic (push to 5V, pull down to GND 0V) you can do the following while in reset with an LED:


Find an LED and series resistor combination that runs at about 10 mA from 5V. Don't be afraid to ask google how to calculate a resistor for an LED if you don't know.

Connect the LED through series resistor to GND (0V). Get a wire for the other end, touch that wire to 5V, does it light up? (make sure it is the correct polarity, normal LEDs only light in one direction) Now you're set up to detect for a logic high. touch this wire to the address lines as needed while holding the chip in reset to see if they are sourcing.

After that, disassemble and do the opposite test: Connect the LED through series resistor to 5V. Get a wire for the other end of the LED, briefly touch that wire to 0V, does it light up? (make sure it is the correct polarity) Now you're set up to detect for a logic low. touch this wire to the address lines as needed while holding the chip in reset to see if they are sinking.

If you get no result (no light) they are in high resistance state, neither high nor low. If there is a dimly lit LED on a few address lines there might be a pullup or pulldown resistor for those.

Thanks for spelling it put like that. Nice and easy to understand.

I do have a logic probe. I did a quick trial of holding the FX cart reset line high and low and tried to program a flash rom attached. The result was not a tri-stated GSU chip unfortunately -- at least it seems that way. I did isolate the rom OE line (because it connected directly to ground) and the CE line is also grounded but it doesn't need to be isolated. I also had the WE line available. So with the control lines available and isolated, it still wouldn't program. In fact, it failed on the first byte of programming. It's my belief that the GSU is maybe holding the rom address lines high but I need to confirm this with the logic probe next time I'm at the workbench.

A while back I build a pcb that had a bus switch on it that isolated the address line and that worked pretty good on re-programming in circuit..... But the IC was/is expensive and I have moved on from that design. Anyway, I was wondering/hoping that the GSU tri-stated its pins but I don't think so.

Thanks for the input!

Hummm..... Not sure why the double post happened.....

Mod edit: I (koitsu) deleted the second post for ya.

I haven't tried the GSU, but I would have thought it worked like the Cx4 in that regard, since it sits between the cart and the ROM/SRAM like the Cx4 does, right? In that case, you don't *want* the GSU to tri-state, you want it to pass the address and data lines through, which would require that it NOT be in reset. IIRC, the main issues I had with the Cx4 were that 1)Nintendo likes to switch the /CE and /OE signals on their ROMs for some reason, and 2)they also often ground one or the other entirely. It's possible that the GSU doesn't assert the address/data lines for writes mapped to the ROM space, but the Cx4 wasn't that smart, which worked to my advantage.

Edit: wait, you're not talking about programming from the cart edge... so my comment probably isn't helpful. Cart edge would probably work though.

if a rom data output is active when both /CE and /OE are asserted, what difference was it to the person designing the circuit board? Then it just comes down to what has less vias. You used to pay by the number of vias back in ye olden days. But as I've heard, the testing department comes in and adds a bunch of their own crazy stuff for the test stands, negating that prospect.

And ohhh yes CE and OE swapped has screwed me up too just one more of those learning curve things, where you can feel good finally getting past such an obstacle and learn something along the way. and yes /CE is the long route to enabling everything in the chip, /OE (internally NORed with /CE) is for enabling the line drivers at the data pins.

/CE is more about saying valid address, /OE is about saying this is a read operation and it's your turn to drive the data bus.

Random thought: if a ROM only responds when both lines are asserted and they don't do anything else individually, why are they separate lines in the first place? (with chips you can both read and write the situation is different, of course) Am I missing something?

For MaskROM it doesn't matter, which is why you don't see any ill effects from such design decisions as switching the two signals or grounding one or the other, but for writable chips such as SRAM or FlashROM/EEPROM, /CE selects which chip you're accessing (so, by definition, memory mapper chips generate 1 or more /CE signals, not /OE), then /OE and /WE select between read and write, and can (and usually should) be globally shared between all chips.

/CE high disables more circuitry than /OE high, causing the ROM to draw less power when /CE is high. But the ROM can respond to /OE faster than to /CE because less circuitry needs to be reenabled.

I was attempting to program to the rom itself and not through the cart edge. I didn't realize with the special chip carts you could program through the edge connector. My flash rom "adapters" have a 40 pin DIL header (2mm) on the pcb that I use to program the flash roms before mounting the pcb to the cart. So I was attempting to reprogram the rom in circuit, but that failed. I'm certain it's because of address contentions due to the GSU.
I'll have to build an edge connector adapter for my programmer now. :/. Try to go through the GSU this time.

Thanks for everyone's input!! Much appreciated.


EDIT/UPDATE: I tried to program through the cart edge. It was unsuccessful. I wired up the address lines and data lines to the cart edge of the FX cart (stunt race) and externally, I connected the WE, CE, and OE lines with no connection to the GSU buss. Next, I tired wiring the Data lines directly from my programmer (so they were not connected to the FX cart data lines). Still no-go. I tried with the reset line tied high and tried with reset tied low also.... still a no-go. In the past, I have tried programming the rom with the data lines connected to the GSU buss but the address lines were not connected to the buss (address lines connected externally). TO be clear, the data lines were connected but I didn't connect the data line to the cart edge. So the address and data lines were externally connected but the address lines had no buss connection but the data line did. It DID program. But my question was if the GSU would pass my programming information though the GSU to the ROM. Unless I'm missing something, I don't think it does.