SuperFX GSU-1/GSU-2 pinout

[magno]

No, I meant, going by the YYWW date codes, GSU-1A is older than GSU-1. That's strange, but I would tend to trust on the date codes there.

Ah, ok. It's strange indeed that GSU-1A is older than GSU-1.

Btw. just for curiosity, do you know if there are differences in the pinouts (between the 100pin MC1, GSU1, GSU1A variants, or between the 112pin GSU2, GSU2-SP1 variants)?
The GSU2-SP1 does of course have oddly arranged pins (with pin1 being the SECOND pin and so); but I guess that was done to maintain the same pin numbers as for GSU2.

MARIO Chip, GSU-1 and GSU-1A all share the same pinout and they all are the same zsize package; well, in fact MC1 package is 19.75mm long and 13.75 mm width and GSU-1 and GSU-1A package are 19.5mm long and 13.5mm width. Anyway, the pin pitch, size and position are the same in all three packages.

GSU-2 and GSU-2-SP1 share the same pinout altough pin layout is not the same as you said.

[magno]

Well, I just finished measure the GSU-1A and MARIO Chip and added it to qwertymodo's EAGLE library. The pin pitch is 0.65mm and pin width 0.35mm. The dimensions are:



I will compare this size with GSU-1 but my feeling is that all three chips have the same package, pin pitch, pin width and even height (0.3mm, so is not a Thin-QFP, but an standard rectangular QFP100). BTW, if somebody is planning to make its own developing board, this adapter could be the most suitable for soldering the SuperFX and placing it in a standard through-hole board:

http://www.ace4parts.com/Products/QFP-- ... 10-01.aspx

This could be useful to for testing the SuperFX without having it soldered to a board.

[hyarion]

I created a google doc survey that can be used to keep track of date codes and other chip information, that way it will be easier to maintain the list (and create statistic plots if enough data is gathered)

So feel free to add new data at: https://docs.google.com/spreadsheet/vie ... E6MQ#gid=0
and view the gathered data at: https://docs.google.com/spreadsheet/ccc ... U0zSDJ4OUE

[qwertymodo]

I added my 3 carts to the list. After doing so, I realized maybe it might be useful to provide PCB ID's, but I can't edit my entries. Maybe you should add PCB ID and region fields to the table. Might be useful information, and it doesn't hurt. Anyway, I'll give you the info here:

Star Fox (epoxy blob): USA, SHVC-1C0N
Star Fox (QFP): USA, SHVC-1CON5S-01
Stunt Race FX: USA, SHVC-1CA6B-01

[hyarion]

I added my 3 carts to the list. After doing so, I realized maybe it might be useful to provide PCB ID's, but I can't edit my entries. Maybe you should add PCB ID and region fields to the table. Might be useful information, and it doesn't hurt. Anyway, I'll give you the info here:

Star Fox (epoxy blob): USA, SHVC-1C0N
Star Fox (QFP): USA, SHVC-1CON5S-01
Stunt Race FX: USA, SHVC-1CA6B-01

Added the new fields in the form and added your additional information

[nocash]

Here's a small GSU test program:

Gsu-test.zip

(8.25 KiB) Downloaded 280 times

The thing has three test screens:
1) showing all GSU I/O ports, including the GSU version register, and unused/writeonly/undocumented ports.
2) showing results of a simple RUN-STOP test (with things like the program counter after stop)
3) showing timings for different CPU and Multiply speeds with & without code cache enabled.

Easiest way to run the test program would be to boot the test program from cartridge, and then replace the test cartridge by a gsu cartridge (you'd only need to bypass the anti-eject mechanics).
Booting via my "xboo cable" should be also working, at least with some small modifications (namely deactivating /RD in similar fashion as /ROMSEL).
And finally replacing the GSU ROM by Test EPROM should also work, but that'd be a LOT of work, especially when doing it for all MC1/GSU1/GSU1A/GSU2/GSU2-SP1 variants.

The included source code contains some Argonaut RISC code, which can be assembled with current (still unreleased) no$sns version. Don't know when I'll get around to release it, but I can upload a beta version of the assembler in case somebody wants to modify the source code.

Currently I've tested the test program only in my emulator - test results on real GSUs would be interesting! Both to see how the GSUs work in general, and to see differences between the 5 chip versions.

If somebody would donate a GSU cartridge for research purposes - that would be pretty motivating to add more tests the test program (like testing memory mirrors, open bus things, timings, unused opcodes, unused pins, etc.) doing that tests would be nice, but isn't too much fun without having real hardware :-/

[qwertymodo]

I have 2 Star Fox carts (1 MARIO QFP and 1 glop-top), and a Stunt Race FX (GSU-1A) you could borrow, though I'm in the USA, so shipping might be a lot, and you'd need a USA-capable console...

[nocash]

Thanks. Well, borrowing... no, better not. If I get one, I'll probably cut it apart, wire stuff to it, and prefer to keep it (for cases when I should happen to do more tests). And yes, shipping from US may be slow or expensive or both (I am located in germany).

[hyarion]

Even though it might be for a good cause, I don't really feel like sending a cartridge to you for slaughter, you could borrow one (or many) but I would want them back some day, in more or less working condition...

Anyway, I guess it would just be easiest if you just bought a used copy of vortex. They are usually for sale for under 5euro on ebay.de and amazon.de (think that's actually less than the shipping from sweden to germany).
http://www.ebay.de/itm/SNES-Spiel-VORTE ... 53ef15064e <-- that one is actually only 3.45 (free shipping in germany)

But if you think that's too much I guess I could order it myself with your address as destination address, transfere that money to you somehow, or something similar; send me a PM if that would be the case.

[qwertymodo]

Well, if you're at all interested in the results of your current tests, I could run them on my carts. I'm just not sure what all is involved in disabling the eject so that I can hot-swap carts. I you could elaborate on that, I'd be willing to modify one of my SNESes for science...

[Near]

I can help you with that part.

Ground pin 4 of the SNES CIC (the one inside the console itself.) I have had success on three consoles by just lifting the pin (leaving it in an open state), but obviously the proper way is to ground it.

By doing this, you will no longer be able to play SA-1 or S-DD1 games on that console. So if possible, see if you can make it a switch. The pins are insanely tiny, the onboard CIC is surface mount, and about the tiniest of any pins I've ever encountered.

The way it works is +5V on this pin means it acts like a lock, and GND acts like a key. When two keys see each other, both chips give up and disable. But this doesn't engage /RESET, so you are then free to swap carts, which you obviously need to do with the lid off so the eject lock doesn't get in your way. Obviously, the SA-1 and S-DD1 will not unlock their ROMs until they are speaking to a master, and you still need a valid CIC on the cart to make the SNES CIC disable itself.

The much nicer way would be to install the SuperCIC with ikari's modifications to allow hot-swapping, then you can even do it with SA-1 cartridges. He has custom code to put onto a PIC (or PIF maybe? Not sure ...) that emulates the CIC. I think the PIC he was using has been discontinued, but someone here has ported it to a different chip.

As for running custom code on the SuperFX, you can execute it out of RAM, but getting ROM-based timings won't be possible. Doesn't matter for a whole lot, just means you can't test things like the ROM buffer cache (which is probably similar to the RAM buffer cache) and such.

Not sure what all there is to glean. I've pretty much gotten all the timings down for that chip, even down to the 16-byte stripe filling of the 256-byte instruction cache. The differences between multiplication speeds and such between GSU-1 and GSU-2 are well documented.

The only mystery to me at this point is what happens when the secondary pixel cache is filled, the primary pixel cache needs to dump its data, and code is executing out of RAM ... does it stall the code execution to the program (most likely), or does it interleave program code and secondary pixel cache dumping (crazy), or does it glitch out and lose the contents of the secondary pixel cache (horrifying)?

[magno]

Not sure what all there is to glean. I've pretty much gotten all the timings down for that chip, even down to the 16-byte stripe filling of the 256-byte instruction cache. The differences between multiplication speeds and such between GSU-1 and GSU-2 are well documented.

And where is all those documentation, if I may ask? I can't find it anywhere...

[nocash]

The anti-eject mechanics is a lever that goes into a notch on the front of the cartridge, preventing to eject the cartridge when power is on. Just remove that lever then you can eject with power on. Not sure if the later cost-down SNES versions do have that mechanics too.

Oh, yes, deactivating the lockout chip via CIC pin 4 would be needed too, else the console's lockout chip would complain about the missing CIC when ejecting the cartridge. Eventually you could bypass both lockout problem and eject mechanics by using a multiregion adaptor, only problem might be that the CIC pins might get bad contact for a moment when (un-)plugging the gsu cartridge.

Not sure what all there is to glean. I've pretty much gotten all the timings down for that chip, even down to the 16-byte stripe filling of the 256-byte instruction cache. The differences between multiplication speeds and such between GSU-1 and GSU-2 are well documented.

Where is that documented? Are there any gsu docs other than book2? For GSU1/GSU2 differences I am only aware of the different pinouts. Though maybe that's actually all about it and there aren't any further differences, and even the VCR register returns the same version number for either chip?
In bsnes_v091-source code, I've found this folder "bsnes\processor\gsu" containing some GSU info, though I haven't spotted any timing or version related things there. The risc opcode emulation looks similar as in no$sns. The problem (in my emulation) is that I've just guessed the mirroring for undefined opcodes; don't know if you've guessed that stuff too, or if it was tested on real hardware.
Multiply speed is more or less documented, I don't know if fast multiply works on all chip versions, and don't know what happens in the "invalid" combination (fast cpu speed plus fast multiply speed enabled together).

[tepples]

The anti-eject mechanics is a lever that goes into a notch on the front of the cartridge, preventing to eject the cartridge when power is on. Just remove that lever then you can eject with power on.

This notch starting around the release of Mario Is Missing! havs a different shape to thwart the Game Genie, which had relied on the notch to hold it in place.

Not sure if the later cost-down SNES versions do have that mechanics too.

Wikipedia says the SNS-101 only makes the first and last code entry lines available for some reason.

[Near]

First time I have heard that the front shell change was to thwart the Game Genie.

Others have said it was because people were damaging their SNES units trying to forcefully eject the cartridges without using the eject button. Sadly, I can believe people were stupid enough to try that. But it would take a monstrous amount of force to damage the deck that way, and it wouldn't stop the problem with the 30% of games still using the old style.