I want to make (some day in the future) a hardware version of SuperFX chip developed on a FPGA. To achieve this, I gathered as much information about it as I could (most of it from SNES developers book), but couldn't find the pinout, neither for GSU-1 nor for GSU-2.
I used my multimeter to match each pin on the StuntRace FX cartridge's edge with each pin of SuperFX, and finally I completed the pinout (I hope I will have spare time to do a schematic in order to post it). I discovered some weird thing: pin 31 of LH538 Mask-ROM was grounded!! If the LH538 datasheet I have is the right one, that pin is A18; LH538 is a 1Mx8 mask-ROM, so... how comes that ROM file is 1MByte, mask-ROM is 1Mbyte but A18 is grounded (19 address pins are used -> 512Kbytes addresseables)??
Maybe my datasheet is wrong?
Where may I find LH538 and LH537 datasheets? I couldn't find the latter anywhere. It is the mask-ROM used on Yoshi's Island (2Mx8).
Could somebody check if this is right?
All this is result of my guessing about the function of each pin, so maybe there is something wrong.
Anyway, I am still confused about my first question:
why ROM A18 grounded on StuntRaceFX cartridge?
It can be seen with the naked eye on this PCB photo:
http://www.snescentral.com/0/0/5/0059/SHVC-CQ-1-front-1.jpg
Nintendo uses maskroms that don't have JEDEC pinouts. Several pins are swapped.
Pin 1 - A17
Pin 2 - A18
Pin 24 - A16
Pin 30 - A19
Pin 31 - /OE (GND for GSU-1 boards)
shadowkn55 wrote:
Nintendo uses maskroms that don't have JEDEC pinouts. Several pins are swapped.
Pin 1 - A17
Pin 2 - A18
Pin 24 - A16
Pin 30 - A19
Pin 31 - /OE (GND for GSU-1 boards)
That's just what I was looking for
THANKS!!
Is there any datasheet or maybe you gueesed that?
phazmatis wrote:
http://www.caitsith2.com/snes/flashcart/cart-chip-pinouts.html
I have that information since some years ago, but I always thought it was referring to DIP Mask-EPROMs. LH538 isn't and furthermore, it has its own datasheet (manufactured by Sharp), so I took it as valid, but obviously it wasn't
Thanks!
Hmm... that number sounds familiar...
Ah yes, gameboy ROMs:
http://www.reinerziegler.de/lh538.gif
phazmatis wrote:
Hmm... that number sounds familiar...
Ah yes, gameboy ROMs:
http://www.reinerziegler.de/lh538.gif
That is the wrong pinout I was using... for some strange reason, the part number is the same than GB ROMs, but it hasn't the same pinout: if it were right, then A18 would be grounded, so StuntRaceFX would be 512Kbytes, not 1M.
shadowkn55 was right: those pins are swapped, so the correct pinout is the one in
http://www.caitsith2.com/snes/flashcart/cart-chip-pinouts.html.
I should correct the GSU-1 pinout...
Ok, i updated the pinout and it makes a lot more sense now!! Address bus is contiguous, but there's no chip enable, chip select or output enable signal from GSU-1 to ROM: the ROM is always enabled, and is the GSU that selects which data is to appear in the SNES bus: from SRAM, from ROM or from internal registers...
Thanks for your help!!
GSU-2 maskroms also follow the standard 36 pin diagram. A21 and A22 are grounded since GSU-2 only supports up to 16mbit. The /CE and /OE signals aren't tied to ground either, they connect directly to the chip.
shadowkn55 wrote:
GSU-2 maskroms also follow the standard 36 pin diagram. A21 and A22 are grounded since GSU-2 only supports up to 16mbit. The /CE and /OE signals aren't tied to ground either, they connect directly to the chip.
Yoshi's Island's maskrom has 40 pins, and it is a GSU-2 cartridge...
You're right. I forgot about that. This should have the correct pin out. It's the one on the bottom.
http://nintendoallstars.w.interia.pl/ro ... esroms.htm
shadowkn55 wrote:
You're right. I forgot about that. This should have the correct pin out. It's the one on the bottom.
http://nintendoallstars.w.interia.pl/ro ... esroms.htm
Thanks! I have just finished doing the pinout over the PCB and I figured out it was that way. MROM /OE is grounded too but /CE is connected to GSU-2 as you said.
I will begin now to create the OrCAD schematic and will post it here for anybody who may want it.
Sorry to refloat this old thread, but I think it is interesting to put all SuperFX related info together.
I'm making my own EagleCAD library SuperFX device and I'm trying to guess all pin functions. This schematics (done by hand) it's the first approaching to the design:
As you can see, almost all pins are labelled with the proper function, but I have some doubts:
* There aren't any SuperFX board with two mask ROMs, is there? So I guess there is no need for two different pins for /ROM_LO and /ROM_HI like in the MAD-1. But don't you think probably Nintendo ingenieers would have foreseen this situation? It looks like pin 21 in GSU-2 is a great candidate for this.
* SRAM chips are always selected on SuperFX boards; I mean, /CE is always low except for stand-by mode (when in data retention mode). This is achieved by MM1026AF chip but SuperFX was designed to use onboard RAM, which was not battery backed-up in all cases. This makes me think that there should be some pin dedicated to /SRAM_CE and the best candidate is GSU2's pin 106. Could somebody who onws a Doom cartridge please check this?
Did you draw the schematics with EagleCAD? No, just joking, they are looking great! Better than many CAD based schematics that I've seen!
What are the X1 frequencies? For GSU-1, I think, it should be 21.4Mhz. And GSU-2, the same? Or is externally doubled?
nocash wrote:
Did you draw the schematics with EagleCAD? No, just joking, they are looking great! Better than many CAD based schematics that I've seen!?
No, not EagleCAD, it's MagnoCAD... don't you know it? XD Seriously, I'm adding SuperFX GSU-1 and GSU-2 to qwertymodo's EagleCAD library, that's why I'm asking about it
nocash wrote:
What are the X1 frequencies? For GSU-1, I think, it should be 21.4Mhz. And GSU-2, the same? Or is externally doubled?
I must check with my oscilloscope, but I'll do when I get some other SuperFX games to compare boards. As for GSU-2, it doesn't look like frequency from crystal oscillator is doubled: it passes through 2 inverters acting like buffers to "adequate" the clock, I guess.
> As for GSU-2, it doesn't look like frequency from crystal oscillator is doubled
No, not that way doubled (sorry the question was confusing).
I did mean this: Is the GSU-2 using something like a 42MHz oscillator?
> I must check with my oscilloscope
Better just look at the X1 part numbers (asking because the usual top-view PCB photos aren't showing that part numbers.
I've compared the GSU specs with the schematics...
GSU-2 can address 128Kbytes SRAM, so there should be SRAM.A16 somewhere (probably on GSU2.Pin106). This could be verified on the SHVC-1CB0N7S-01 board (used by Doom, the game has only 64K installed, but the PCB could be also fitted with 128K, so the SRAM.A16 connection should be there).
GSU-1 can probably address only max 64Kbytes SRAM (it looks like so in your schematic); which would imply that the RAM bank register (303Ch - RAMBR) does exist on GSU-2 chips only (it's somewhat located at the end of the I/O map, which is also hinting that it's a later invention). Btw. are there any docs for pre-GSU-2 chips? (for figuring out differences between GSU-2 and older GSU chips)
Then there is the 3033h - BRAMR register for protecting "back-up RAM" at 780000h-79FFFFh. The "back-up RAM" would be RAM connected to the SNES bus (not the usual RAM connected to GSU's SRAM-bus). This "back-up" stuff isn't used by any existing cartridges. I am just mentioning the feature because one or more of the NC pins are probably "back-up /CS, or CS, or /RD, or /WR signals". It may be difficult to find out on which pins that unused feature is hiding (and probably not really worth doing it).
On GSU-1, ROM is always enabled (both /CE and /CS wired to GND).
And on GSU-2, ROM./CE is GSU.Pin20... that looks as if GSU2.Pin21 might be another ROM./CE signal, for a second ROM chip. With 21bit ROM address bus and two ROM chipselects, it could access 4MByte ROM (which does match up with the GSU specs).
And GSU-2, ROM./OE on GSU2.Pin111... I don't understand that part of your schematic... It looks more like a GNDed pin (not like an /OE signal)...?
---
And, not related to the schematic, there's the 303Bh - VCR version code register. Did anybody ever read that register? Or byuu, can you do that with your hardware setup?
There are least 5 different GSU chip versions (MarioChip1, GSU1, GSU1A, GSU2, GSU2-SP1), which may or may not return different version codes in 303Bh.
I am writing quickly from my mobile phone, just about to play a paddle match, but I couldn't resist to ask you... where in the hell did you find a reliable GSU2 specs document?
And yes, you are right, /ROM_OE in pin 111 of GSU2 is an errata.
My own GSU specs are here,
http://nocash.emubase.de/fullsnes.htm#s ... hip10gamesMost of the info was extracted from "book2.pdf" from 1995 which contains 190 pages with GSU info, including memory map and width of the ROM/RAM bank registers. It doesn't explicitely say if it's describing a GSU-1 or GSU-2, but some of the features are hinting at GSU-2 (bigger memory size, and higher cpu speed). Don't know if there are other GSU docs (?) especially older GSU-1 specifc versions would be interesting.
According to MotZilla the increased CPU speed (or rather high speed mode fix) was actually added in the GSU-1 revision.
nocash wrote:
My own GSU specs are here,
http://nocash.emubase.de/fullsnes.htm#s ... hip10gamesMost of the info was extracted from "book2.pdf" from 1995 which contains 190 pages with GSU info, including memory map and width of the ROM/RAM bank registers. It doesn't explicitely say if it's describing a GSU-1 or GSU-2, but some of the features are hinting at GSU-2 (bigger memory size, and higher cpu speed). Don't know if there are other GSU docs (?) especially older GSU-1 specifc versions would be interesting.
Ah, ok. I already read all that information in FullSNES and Book2 of Nintendo's documentation, but never read a reference to GSU-1 or GSU-2 in the latter. I suppose all unused pins should be discovered by RE.
hyarion wrote:
According to MotZilla the increased CPU speed (or rather high speed mode fix) was actually added in the GSU-1 revision.
That's interesting. I was going by the wikipedia article
http://en.wikipedia.org/wiki/List_of_Su ... ment_chips which says that high speed mode exists on GSU-2 only. Hmmm, the wikipedia article also says that GSU2-SP1 stands for Service Pack 1. That sounds, well, strange.
Is there more info on different GSU versions known? What is a "high speed mode fix"? Did the old MarioChip1 have bugged high speed support, too?
nocash wrote:
That's interesting. I was going by the wikipedia article
http://en.wikipedia.org/wiki/List_of_Su ... ment_chips which says that high speed mode exists on GSU-2 only. Hmmm, the wikipedia article also says that GSU2-SP1 stands for Service Pack 1. That sounds, well, strange.
Is there more info on different GSU versions known? What is a "high speed mode fix"? Did the old MarioChip1 have bugged high speed support, too?
Don't trust wikipedia.
MARIO CHIP 1
9306,
9321 Starfox
GSU-1A
9403 Powerslide (prototype), 9404 (stunt race fx)
GSU-1
9406 Stunt Race Fx (prototype),
9417 Dirt Racer?/Vortex?
GSU-2
9444 Yoshi's Island (prototype),
9537 Yoshi's Island,
9543 Doom
GSU-2-SP1
9538 Yoshi's Island
From what i've read MARIO CHIP 1 didn't support 21MHz mode, only 10.5MHz. There is a register where you can switch between these two modes but from what I've heard it doesn't do anything on the MARIO CHIP 1. MotZilla sais GSU-1 works at both 10.5MHz _and_ 21MHz. So it seems like they fixed it at some time between 9321 and 9406.
As I haven't heard that anything else differs between MARIO CHIP 1 and GSU-1, the GSU-1A could be either a renamed MARIO CHIP 1 or a prereleased GSU-1?, hard to tell without doing some tests.
It looks like they produced both GSU-2 and GSU-2-SP1 in the same timespan which could indicate that the to CPU's might not be fully compatibile (why produce two versions otherwise? needs to be verified)
One obvious change is the address bus though
So it seems like there where 5 revisions, MARIO CHIP 1 -[renaming (and highspeed mode?)]-> GSU-1A -[highspeed mode(if it wasn't done in GSU-1A)]-> GSU-1 -[increased address bus]-> GSU-2 -[reduced package size (and perhaps something more)]-> GSU-2-SP1
Hyarion and me are keeping a very interesting conversation about SuperFX by email, maybe we could keep talking about it here.
As I told him, I think GSU2 and GSU2-SP1 have some more differences than those related to the package. My guess is:
* Not much sense in starting a new fabrication process to change only the package.
* Yoshi's Island boards use GSU2 and GSU2-SP1 and each of them has a source code revision... I mean, there are at least two ROM versions (3 in Japan) which means 2 different codes; it looks like they were programmed for GSU2 and GSU2-SP1 respectively.
* "SP1" suggests "Service Pack 1" so it could be pointing at some change in the SuperFX microcode. Altough it also could stand for "Small Package" or whatever (but then the number doesn't make sense).
AS for GSU-1A, my chip is
9404, so if the number tell us the revision, there should be several of them for each SuperFX version. My GSU-1 revision number is
9422.
Quote:
So it seems like there where 5 revisions, MARIO CHIP 1 -[renaming (and highspeed mode?)]-> GSU-1A -[highspeed mode(if it wasn't done in GSU-1A)]-> GSU-1 -[increased address bus]-> GSU-2 -[reduced package size (and perhaps something more)]-> GSU-2-SP1
I would say 5 versions; this way, the number in the chip would be the revision number.
Do you think GSU-1 and GSU-2 differences are only related to package? It doesn't seem a serious concern to build another chip...
Microcode changes are likely. In fact, one thing Argonaut liked to do was
customize the instruction set for each application.
tepples wrote:
Microcode changes are likely. In fact, one thing Argonaut liked to do was
customize the instruction set for each application.
I can't remember where I read it, but I'm pretty sure some opcode was faulty under certain conditions and that was fixed in some revision.
hyarion wrote:
MARIO CHIP 1
9306,
9321 Starfox
GSU-1A
9403 Powerslide (prototype), 9404 (stunt race fx)
GSU-1
9406 Stunt Race Fx (prototype),
9417 Dirt Racer?/Vortex?
GSU-2
9444 Yoshi's Island (prototype),
9537 Yoshi's Island,
9543 Doom
GSU-2-SP1
9538 Yoshi's Island
Cool, that's a nice list showing which game uses which chip.
A sixth variant would be the
black-blob MarioChip1 (used by Star Fox, too).
Wikipedia is linking to this
interview, telling that MarioChip was Argonaut's original codename for the project, and Nintendo later changed it to SuperFX/GSU, maybe there isn't much more difference than the name change between MC1 and GSU1A.
One small difference is that MC1 is using the SNES master clock, and the GSUs are having their own oscillators on the cartridge PCB. The clock input should be 21.4MHz (?) in either case, but maybe there's a small difference on the clock voltages.
magno wrote:
Yoshi's Island boards use GSU2 and GSU2-SP1 and each of them has a source code revision...
"SP1" suggests "Service Pack 1" ... Altough it also could stand for "Small Package" or whatever
My GSU-1 revision number is
9422.
The 93xx,94xx,95xx numbers are looking a lot like normal YYWW date codes, they do also (more or less) match up with the YYWW date codes on the ROM and CIC chips, the YYWW stuff usually doesn't indicate a revision, just the date in year:week format. Btw. funny that the GSU1A is apparently older than GSU1.
I thought the term "Service Pack" was coined by Microsoft for WinXP software updates, which doesn't make sense here :-) for hardware revisions "Small or Slim Package" would make more sense, or it may have some completely different meaning.
Didn't knew that there are differences for GSU2 and GSU2-SP1 program code, good to know! Are there some obivous changes (like new I/O ports), or compatibility problems (like when running a GSU2-SP1 rom-image on a GSU2 chip)?
tepples wrote:
Microcode changes are likely. In fact, one thing Argonaut liked to do was
customize the instruction set for each application.
What do you mean? The part about
"Extensions can include for example, an MMU, a fast multiplier–accumulator, a USB Host, a viterbi path decoder, etc. etc."? That isn't too uncommon, and I guess such extensions would be accessed via coprocessor opcodes, or as built-in I/O ports (but without changing the overall instruction set).
magno wrote:
I can't remember where I read it, but I'm pretty sure some opcode was faulty under certain conditions and that was fixed in some revision.
Would be interesting to know more. Btw. is anybody having modded GSU boards with ROM replaced by EPROM sockets?
I don't have any GSU cartridges at home, but I could eventually write some GSU diagnostics program. Before going into that, it'd be nice to know if somebody is able to run such test programs (and if it was already done by somebody else).
nocash wrote:
One small difference is that MC1 is using the SNES master clock, and the GSUs are having their own oscillators on the cartridge PCB. The clock input should be 21.4MHz (?) in either case, but maybe there's a small difference on the clock voltages.).
Yes, I just checked that a few minutes ago; GSU-1A board has a 21.44MHz and Mario chip gets the clock from the SNES master clock through an inductor (labeled as L1 on the board) in series.
nocash wrote:
The 93xx,94xx,95xx numbers are looking a lot like normal YYWW date codes, they do also (more or less) match up with the YYWW date codes on the ROM and CIC chips, the YYWW stuff usually doesn't indicate a revision, just the date in year:week format. Btw. funny that the GSU1A is apparently older than GSU1.).
You are probably right, and GSU-1 is the next step after MARIO Chip and not GSU-1A. Besides, it makes sense to name GSU-1A as a later revision of GSU-1, not as a previous one. I have a 1992 SHVC-1C0N5S-02 board and MARIO Chip has the code 9309 on it.
nocash wrote:
Would be interesting to know more. Btw. is anybody having modded GSU boards with ROM replaced by EPROM sockets?
I don't have any GSU cartridges at home, but I could eventually write some GSU diagnostics program. Before going into that, it'd be nice to know if somebody is able to run such test programs (and if it was already done by somebody else).
I would like to build muy own Super FX board with DIP socket for ROMs so they can be exchanged easily.
magno wrote:
You are probably right, and GSU-1 is the next step after MARIO Chip and not GSU-1A. Besides, it makes sense to name GSU-1A as a later revision of GSU-1, not as a previous one.
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.
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.
nocash wrote:
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.
nocash wrote:
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.
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--100-Pins-065mm-Pitch----2-X-2-Grid__201-0010-01.aspxThis could be useful to for testing the SuperFX without having it soldered to a board.
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/viewform?formkey=dHYxRW1kd0tWLWlIRlVvdU0zSDJ4OUE6MQ#gid=0and view the gathered data at:
https://docs.google.com/spreadsheet/ccc?key=0Am_qc4idMT-1dHYxRW1kd0tWLWlIRlVvdU0zSDJ4OUE
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
qwertymodo wrote:
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
Here's a small GSU test program:
Attachment:
Gsu-test.zip [8.25 KiB]
Downloaded 109 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 :-/
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...
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).
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.
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...
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)?
byuu wrote:
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...
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.
byuu wrote:
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).
nocash wrote:
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.
Quote:
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.
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.
Actually, the newer notches are Nintendo's sinister plan to throw the competing Amiga 500 out of the market. You know: The player fiddling with a 3.5" floppy disk and a snes cartridge, not expecting anything harmful, but then the disk gets into the notch, and - zack - the disk is broken. The older notch shape combined destroying 5.25" disks and Atari cartridges.
If somebody is telling you that the square-edged notches would prevent SRAM corruption, don't trust that! The notches are what they are: Very evil cyber weapons.
I've got two GSU cartridges (big thanks to Alexis). One Star Fox cartridge with black blobs, and LR0G1801 marking (this should be the oldest variant). And Doom with GSU2. VCR version code register returns 01h for the blob, and 04h for GSU2.
The I/O mirrors for GSU2 are quite straight:
Code:
3000h..301Fh 20h R0-R15
3020h..302Fh 10h mirror of 3030h..303Fh
3030h..303Fh 10h status regs (unused or write-only ones return 00h)
3040h..30FFh C0h mirrors of 3000h..303Fh
3100h..32FFh 200h cache
3300h..34FFh 200h mirrors of 3000h..303Fh
3500h..3FFFh B00h open-bus
For the Blob, the mirroring is rather messy:
Code:
3000h..301Fh 20h R0-R15
3020h..302Fh 10h open bus
3030h..3031h 2 status reg
3032h..303Fh 0Eh mirrors of status reg (except 303Bh=01h=VCR)
3040h..305Fh 20h mirror of R0-R15
3060h..307Fh 20h mirrors of status reg (except 307Bh=01h=VCR)
3080h..30FFh 80h open bus
3100h..32FFh 200h cache
3300h..332Fh 30h open bus
3330h..333Fh 10h mirrors of status reg (except 333Bh=01h=VCR)
3340h..335Fh 20h mirror of R0-R15
3360h..337Fh 20h mirrors of status reg (except 337Bh=01h=VCR)
3380h..33FFh 80h open bus
3400h..342Fh 30h open bus
3430h..343Fh 10h mirrors of status reg (except 343Bh=01h=VCR)
3440h..345Fh 20h mirror of R0-R15
3460h..347Fh 20h mirrors of status reg (except 347Bh=01h=VCR)
3480h..3FFFh B80h open bus
The Speed Test results are:
Code:
CFGR=80, CLSR=00 GSU2 Blob
NOP+CACHE 0006FB 00150F ;\
NOP 0014EC 00150F ; both slow
MUL+CACHE 001E39 001E6C ;
MUL 003C6D 001E6B ;/
CFGR=A0, CLSR=00
NOP+CACHE 0006FB 00150F ;\
NOP 0014EC 00150F ; fast multiply
MUL+CACHE 0014ED 001E6C ;
MUL 003321 001E6B ;/
CFGR=80, CLSR=01
NOP+CACHE 00037E 00118D ;\
NOP 00116F 00118D ; fast cpu clock
MUL+CACHE 000F1D 000F36 ;
MUL 002AFF 000F36 ;/
CFGR=A0, CLSR=01
NOP+CACHE 00037D 00118D ;\
NOP 00116F 00118D ; both fast (illegal)
MUL+CACHE 000A77 000F36 ;
MUL 002659 000F36 ;/
The small differences like 14ECh vs 150Fh are caused by different clock inputs (GSU2=21.44MHz oscillator, Blob=21.2813700MHz/PAL Master Clock).
GSU2 can have various different speeds, with slow/fast cpu or multiply clocks, the "illegal both fast" is also working (at least in so far the test runs extra-fast, but maybe the multply results are truncated or unstable, haven't tested that yet).
The Blob can have slow/fast cpu clock (don't know if it's actually working/stable, or if it's really bugged), the Blob's multiply speed is always "slow". And the Blob's cache... that doesn't work as expected... normally cache should loaded/enabled by "cache" opcode, and unloaded/disabled by writing GO=0 vis SNES I/O ports (this is working fine on GSU2), but the Blob is more or less ignoring it, the "NOP" test is always executed with cache OFF, and the "MUL" test always with cache ON. Don't know what is causing that effect, maybe the NOP test is somehow loading the cache, but without activating it until running the MUL test.
Writing to the R0..R15 registers works as so:
Code:
Writes to 3000h-301Eh (even addresses) do set LATCH=data.
Writes to 3001h-301Fh (odd addresses) do apply LSB=LATCH and MSB=data.
Ie. for the even addresses, it doesn't matter if one writes to 3000h or 3002h .. or 301Eh.
GSU2.pin106 is actually SRAM.A16 (on the Doom PCB, it's wired to SRAM.pin2).
And, here's an updated version of the test program
Attachment:
Gsu-test.zip [9.73 KiB]
Downloaded 109 times
it's fixing some bugs, and contains new "General Tests" which do verify the above mirroring/openbus schemes for the Blob and GSU2. One of them should always FAIL (depending on which GSU chip you don't have), the other one might pass OK (depending on which chip you do have).
Would be interesting if the SMD-MC1,GSU1, GSU1A, and GSU2-SP1 do also pass OK on one of the two mirroring schemes.
And of course the speed test would be also interesing on other chips, to find out when fast-multiply and normal-cache behaviour have been invented.
Btw. the stuff about anti-eject has been rather nonsense: You could as well remove the cartridge shell instead of removing the lever (without opening the cartridge you wouldn't know what you are testing anyways). When using the plain cartridge PCB be sure to use the correct orientation:
SMD CHIPs should be facing to REAR side.
BLOCK BLOBs should be facing to FRONT side.
The epoxy blob Star Fox carts are actually newer than the QFP ones. They must've run out of the QFP chips and cheaped out on the next batch.
Wow, some interesting stuff here after all.
Always thought epoxy was the earliest version, and that the IO range was well known to be 3000-32ff.
Really weird that the mirroring doesn't repeat up to 37ff or 3fff. The address decoder logic must be pretty insane for what you're seeing.
GSU2 as revision 4 is also fascinating. I figured there were three revisions between them: Mario Chip, GSU1, GSU2, with the -SP1 just being process revisions. Guess not. I better sequester all my SFX carts and check their versions.
Yup, the mapping is strange. Maybe it's some optimized trickery for best performance :-) although things like cache at 3100-32FF don't look too optimized, 3200-33FF would appear easier and faster. The used range is 3000h-34FFh (higher addresses up to 3FFFh are decoded and rejected, ie. open bus).
The blob's mapping is pretty odd, but should be correct as so (since the test proggy throws out "OK" for it). Ah, and the Blob is really allowing to read only two registers (2byte SFR, and 1byte VCR) in the 3030h-303Fh space. Of course at least some of the other registers (like PBR) do exist too, but they are write-only on the Blob.
hyarion wrote:
MARIO CHIP 1
9306,
9321 Starfox
For the Blobs, my PCB is marked "
9308 3", and the pic at snescentral shows
9304 7. If that are Year-Week-(day?) datecodes then the Blobs have been produced alongsides with the SMD chips. That's odd. The PCB datecode isn't neccessarily same as the chip production date... maybe the "blob" chips have been produced earlier (like late 9250..9305 or so) and have been installed on PCBs at a time when the SMD chip production started.
Some more details: When hitting a STOP opcode at address $+0, the GSU does apparently prefetch one more opcode byte at $+1 (but without executing it), and does then stop with R15=$+2 (after the unused/prefetched byte), SFR.GO=0 and SFR.IRQ=1 (the IRQ flag is always set on STOP, no matter if IRQ is enabled in CFGR).
The 16bit SFR register is marked "R/W" in book2, but, actually, only bit1-5 are "R/W". And the other bits are... don't know... either "R"... or maybe "W". After a STOP opcode, bit0 and bit5-14 seem to be always zero.
If you're interested in the difference between the 2 versions of Star Fox, I just uploaded PCB pics:
http://imgur.com/a/U0LXy
Nice and very detailed pics! Both versions are patched with a 1.2 ohm resistor (inserted in the master clock line). So far it looks to me as if both are "the oldest version", ie. looks as if nintento has produced both Blob and SMD versions at the same time.
The later LR0G1807 (Blob) doesn't seem to have that resistor (or it's installed as normal SMD resistor instead of as patch). The later SHVC-1CON5S-02 (SMD) is still having the patch, confusing.
The different Star Fox boards that I've spotted here and there are:
Code:
Type Mario Chip Board ROM
Blob LR0G1801 9307 6 SHVC-1CON (01) SNS-FO-0
Blob LR0G1807 9324 4 noname (02) SNS-FO-2
SMD LR38173 9306 3D SHVC-1C0N5S-01 SNS-FO-0
SMD LR38173 9309 5D SHVC-1C0N5S-02 SHVC-FO-0
SMD LR38173 9321 1E SNSP-1C0N5S-01 SFRG-FO-0 (PAL)
SMD LR38173 9415 7E GS 0871-102 SHVC-FO-1 (SFC-Box multi-cart)
After the I/O maps, I've now also checked the overall memory maps (on SNES side):
GSU Memory Map (at SNES Side)This is more or less as already known. The 8K at xx:6000h-xx:7FFFh is always mirroring to 700000h-701FFFh (no matter if the "xx" bank is 00h..3Fh or 80h..BFh).
Code:
00-3F:3000-34FF GSU I/O Ports
00-3F:6000-7FFF Mirror of 70:0000-1FFF (ie. FIRST 8K of Game Pak RAM)
00-3F:8000-FFFF Game Pak ROM in LoRom mapping (2Mbyte max)
40-5F:0000-FFFF Game Pak ROM in HiRom mapping (mirror of above 2Mbyte)
70-71:0000-FFFF Game Pak RAM (128Kbyte max, usually 32K or 64K)
78-79:0000-FFFF Additional "Backup" RAM (128Kbyte max, usually none)
80-BF:3000-32FF Mirror of GSU I/O Ports
80-BF:6000-7FFF Mirror of 70:0000-1FFF (ie. FIRST 8K of Game Pak RAM)
80-BF:8000-FFFF Additional "CPU" ROM LoROM (2Mbyte max, usually none)
C0-FF:0000-FFFF Additional "CPU" ROM HiROM (4Mbyte max, usually none)
Other Addresses Open Bus
The above "Additional" areas aren't installed on existing boards (=are seen as open bus). Maybe some of the unused pins on the GSU2 are chipselect signals for that areas.
MC1/Blob Memory Map (at SNES Side)This is totally different as GSU2, but it's very simple. There is no HiROM support, and no 8K RAM mirror at 6000h-7FFFh, and no "Additional" areas.
Code:
00-3F/80-BF:3000-34FF GSU I/O Ports
00-1F/80-9F:8000-FFFF Game Pak ROM in LoRom mapping (1Mbyte max)
60-7D/E0-FF:0000-FFFF Game Pak RAM with mirrors (64Kbyte max?, usually 32K)
Other Addresses Open Bus
Additional "Backup" RAM can't be there since that area contains normal RAM, and Additional "CPU" ROM LoROM can't be there since that area constains normal LoROM, and Additional "CPU" ROM HiROM... well, that could be there since bank C0-DF are open bus, but I'd doubt that the Blob contains provisions for decoding that area.
The test program contains a new test for checking the memory map, and a bug-fix for doing cartridge swaps - which didn't work properly in older version, although it seems to that nobody is running the test proggy anyways :-/ so, at least, the bug wasn't much of a problem :-)
Anyways, here's the updated version
Attachment:
Gsu-test.zip [12.55 KiB]
Downloaded 121 times
- the new stuff in the "general test" section is quite slow (takes about 10 seconds before it shows the results, if you try it, please be patient).
nocash, the SuperFX maps differ significantly between each board. See my database for specifics.
I still need to add the new I/O stuff, my mapper skips probing 00-3f,80-bf:0000-5fff; because writing to I/O regs could affect other things.
You already have those in the database, too? Good to know...
http://byuu.org/snes/database/ okay, there are six "type=1Cxx" boards in there... MC1 mapping is same as what I've found out. And revision=2 means GSU1+GSU1A, right? The missing "size=0x2000" for Vortex is having no special meaning (or is that an important variant)? Then GSU1 mapping should be so:
Code:
00-3F/80-BF:3000-34FF GSU I/O Ports
00-3F/80-BF:6000-7FFF Mirror of 70:0000-1FFF (ie. FIRST 8K of Game Pak RAM)
00-3F/80-BF:8000-FFFF Game Pak ROM in LoRom mapping (1Mbyte max?)
40-5F/C0-DF:0000-FFFF Game Pak ROM in HiRom mapping (1Mbyte max?)
70-71/F0-F1:0000-FFFF Game Pak RAM with mirrors (64Kbyte max?, usually 32K)
78-7x/F8-Fx:0000-FFFF Unknown (maybe Additional "Backup" RAM like GSU2)
Other Addresses Open Bus
The "Additional" LoROM/HiROM can't exist here (as that areas contain normal LoROM/HiROM). Game Pak RAM is mapped to bank 70-71 only, which implies that bank 78-79 (or so) might be intended to contain "Additional Backup RAM" (as in GSU2).
The ROM/RAM mapping is a strange: Concerning pinouts, the GSU1 should support max 1Mbyte ROM and max 64Kbyte RAM. But according to the above memory map it does seem to support twice as much ROM and RAM internally (as implemented in GSU2).
byuu wrote:
my mapper skips probing 00-3f,80-bf:0000-5fff; because writing to I/O regs could affect other things.
Writing yes, but you couldn't you do normal Open Bus checks by reading? And throw out a warning if it isn't open bus. That way you would have discovered the GSU I/O mirrors at 3300h-34FFh, as well as whatever secret hardware contained in other cartridges.
> And revision=2 means GSU1+GSU1A, right?
Don't rely on revision= tags yet. I was basing them on chip names.
MARIO = 1, GSU1 = 2, GSU2 = 3. But you found it goes 1-4, so I need to retest all my SFX carts and read the version reg directly.
> The missing "size=0x2000" for Vortex is having no special meaning
Good catch, looks like I missed that. Star Fox is an interesting board in that it only has the 70-71 RAM.
> as well as whatever secret hardware contained in other cartridges.
Reading -can- interfere with hardware, unlikely but I figured why risk it? I would have to mask out the SNES internal I/O regs and WRAM still. And my ROM vs RAM test requires writing, so I could only flag it as "not open bus", which isn't as nice.
Anyway, it's not a big deal. The only boards with I/O regs in 0000-5fff are:
SuperFX, which you just found out about
SA-1 which as far as I know is 2200-23ff firm
SPC7110 which I just found out was a lot more interesting
SDD1 which we currently believe to be eight regs [needs to be tested though]
SGB which d4s documented mirrors to
SRTC which we believe to be two regs [needs to be tested though]
If there were any mystery ICs on any boards, I would obviously have flagged them for later review. So we aren't missing any secret data there
All the same, I'm not redumping 720 carts; but I'll add an open bus tester before I dump the 1400 Japanese carts (after getting them, of course.)
...
Something I don't understand, but maybe you do. Stunt Race FX is 1CA6B. Vortex is 1CA0N5S.
Now traditionally, we know that:
1CA = GSU1
6B = board has RAM, and uses non-MAD chips to switch between ROM and RAM
0N = board has no RAM and no MAD chip as a result
5S = SuperFX board with RAM
So why does Stunt Race put the RAM size first, and Vortex put it after?
My crazy theory at the moment is that Stunt Race's RAM is only visible to the SNES CPU, and is on its bus directly. And Vortex's RAM is connected behind the SuperFX, so that it can be selected.
> But you found it goes 1-4, so I need to retest all my SFX carts
How are chances that you could run my test proggy on them? I guess you do have hardware to run ROM-images... I guess you'll dislike the ".bin" extension :-) but you can rename it to ".sfc" or what you please. The "wait_keyboard_input" function executes at 4300h, so you can do cart swaps any time you want (unless during running tests; ie. when screen is all black).
Here's an another update
Attachment:
Gsu-test.zip [13.05 KiB]
Downloaded 120 times
it's now also checking the GSU1 memory map from your database. If I got it right, then the GSU1 map test should pass OK. For the I/O map test it'd be interesting they pass on GSU1, or that has different I/O map, which would need more research. Timing tests would be still interesting too (to me, at least). I think it'd be nice to know if the GSU1 did support fast multiply or not.
And knowing the different VCR version codes would be neat, too (before somebody asks, yes, the test program can show them, too). At the moment only two versions are known: 01 and 04. Quite possible that 02 and 03 do also exist, or maybe they don't exist. And maybe 05 exists, too.
> Reading -can- interfere with hardware, unlikely but I figured why risk it?
If you want to reduce risks: You could first read the normal memory areas, and then read the "risky" I/O areas. Of course, making test programs that handle all (im-)possible special cases may be a 10 years project :-)
> I could only flag it as "not open bus", which isn't as nice.
In most carts stuff below address 6000h is open bus, so that test would be just perfect for such carts (to trap warnings on unexpected stuff).
> SGB which d4s documented mirrors to
SGB has mirrors below 6000h ???
> If there were any mystery ICs on any boards, I would obviously have flagged them for later review.
For the GBA, Nintendo has made cartridges with ROM.
Yeah, so what? The ROMs did have an on-chip 4bit parallel I/O port.
I'd rather doubt that SNES cartridges contain such hidden features, but you never now.
> Stunt Race FX is 1CA6B. Vortex is 1CA0N5S.
The main difference is the "B" for Battery (also so in Yoshi's Island). With the normal GSU-notation it should be something like "0B6S" or "0N6B". Don't know why Nintendo have called it "6B" instead, must have been a "mood of the day decision". The games do access RAM from GSU side, so it must be wired to the GSU as usually. I haven't checked, but you should also see the wiring on PCB photos. Else the thing would be pretty useless: without RAM it couldn't do any rendering/plotting, at it's best it could transform parameters passed through the R0..R14 registers.
> How are chances that you could run my test proggy on them?
Possibly, but very unlikely. I'm sorry but my setup is very unique.
I run a script that assembles source written in bass, and uploads it into WRAM to execute. It then returns any data through the serial port. I don't even have my SNES connected to a video display at the moment.
I don't have the ability to execute a normal program with a cart swapped in.
I'll get back to you after I sequester all my SFX carts and test them.
> SGB has mirrors below 6000h ???
No, just meaning its mirrors have been mapped out by d4s. They vary from SGB1 and SGB2.
People can't just leave hardware the fuck alone, I swear :P
> Don't know why Nintendo have called it "6B" instead, must have been a "mood of the day decision".
Ugh, that's annoying. But yeah, no PLOT would make SFX fairly pointless. So ... I guess it's just arbitrary then.
hyarion wrote:
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/viewform?formkey=dHYxRW1kd0tWLWlIRlVvdU0zSDJ4OUE6MQ#gid=0and view the gathered data at:
https://docs.google.com/spreadsheet/ccc?key=0Am_qc4idMT-1dHYxRW1kd0tWLWlIRlVvdU0zSDJ4OUEI just added a lot of new SuperFX revisions to the database.
nocash wrote:
> But you found it goes 1-4, so I need to retest all my SFX carts
How are chances that you could run my test proggy on them? I guess you do have hardware to run ROM-images... I guess you'll dislike the ".bin" extension
but you can rename it to ".sfc" or what you please. The "wait_keyboard_input" function executes at 4300h, so you can do cart swaps any time you want (unless during running tests; ie. when screen is all black).
Here's an another update
Attachment:
Gsu-test.zip
it's now also checking the GSU1 memory map from your database. If I got it right, then the GSU1 map test should pass OK. For the I/O map test it'd be interesting they pass on GSU1, or that has different I/O map, which would need more research. Timing tests would be still interesting too (to me, at least). I think it'd be nice to know if the GSU1 did support fast multiply or not.
And knowing the different VCR version codes would be neat, too (before somebody asks, yes, the test program can show them, too). At the moment only two versions are known: 01 and 04. Quite possible that 02 and 03 do also exist, or maybe they don't exist. And maybe 05 exists, too.
> Reading -can- interfere with hardware, unlikely but I figured why risk it?
If you want to reduce risks: You could first read the normal memory areas, and then read the "risky" I/O areas. Of course, making test programs that handle all (im-)possible special cases may be a 10 years project
> I could only flag it as "not open bus", which isn't as nice.
In most carts stuff below address 6000h is open bus, so that test would be just perfect for such carts (to trap warnings on unexpected stuff).
> SGB which d4s documented mirrors to
SGB has mirrors below 6000h ???
> If there were any mystery ICs on any boards, I would obviously have flagged them for later review.
For the GBA, Nintendo has made cartridges with ROM.
Yeah, so what? The ROMs did have an on-chip 4bit parallel I/O port.
I'd rather doubt that SNES cartridges contain such hidden features, but you never now.
> Stunt Race FX is 1CA6B. Vortex is 1CA0N5S.
The main difference is the "B" for Battery (also so in Yoshi's Island). With the normal GSU-notation it should be something like "0B6S" or "0N6B". Don't know why Nintendo have called it "6B" instead, must have been a "mood of the day decision". The games do access RAM from GSU side, so it must be wired to the GSU as usually. I haven't checked, but you should also see the wiring on PCB photos. Else the thing would be pretty useless: without RAM it couldn't do any rendering/plotting, at it's best it could transform parameters passed through the R0..R14 registers.
Just a silly question... how do you upload new code to the board to make such tests? Do you compile a program, burn it on an EPROM and then put that EPROM on the SuperFX board? I find it really hard, since no DIP adaptor can be soldered to the board.
The .bin file is a ready-for-use ROM-image (the .a22/.inc source code files are included only for curiosity, you don't need them).
There are dozens of ways how to start the ROM-image: Anything you have to run code on the SNES should work: Easiest way would be Flashcards/Copiers.
Other ways (more difficult/with soldering) would be my xboo cable, or yes, replacing the ROM on the GSU cartridge would work too, but isn't required.
The program is executing in RAM, once when it is started you can eject the boot-cartridge, and replace it by the GSU cartridge. For doing such cartridge swaps: You'll need to get around the anti-eject lever mechanics, and as byuu has pointed out: you'll need to disable the CIC lock-out in the console (if you haven't done that already).
---
While doing a few more tests, I've spotted a hardware glitch on the MC1: Executing a STOP opcode shortly after a store-to-RAM opcode does somehow hang (GO flag isn't going to zero). Must be related to the write buffer. Maybe STOP is waiting for the write-buffer to become empty, and simultanously stopping write-operations (thereby preventing itself from completion).
GSU2 doesn't have that glitch. And on MC1, inserting two NOPs (or some other opcode with 2 or more memory cycles) between store and STOP is avoiding the problem; maybe there are cases where it needs more NOPs (depending on caching and current CPU speed, and on executing code in ROM or RAM).
nocash wrote:
The program is executing in RAM, once when it is started you can eject the boot-cartridge, and replace it by the GSU cartridge. For doing such cartridge swaps: You'll need to get around the anti-eject lever mechanics, and as byuu has pointed out: you'll need to disable the CIC lock-out in the console (if you haven't done that already).
I get it! I'll try to do this with my GameDoctor7; I already did the CIC mod and only need to figure how to avoid the anti-eject lever...
BTW, I just finished the GSU-1 and GSU-2 EAGLE library for those who may need it to make their own cartridges
Tested all my SFX carts.
All return VCR=4, except for Star Fox, which returns VCR=1.
All of the VCR=4 boards map 3000-34ff, and Star Fox maps 3000-347f, with sporadic open bus throughout.
I'm just going to treat them all as 3000-34ff, and special-case 3480-34ff to return the MDR on VCR=1.
In fact, my bet is that the chip actually gets 3000-37ff, and just always ignores 3500-37ff.
I don't know where VCR=2, VCR=3 are at. They're not in the US games I have.
It doesn't seem that VCR has any correlation to "Mario Chip 1", "GSU-1", "GSU-2", "GSU-2-SP1"
Good to know! And pretty unexpected... I was assuming that VCR=2..3 would exist too.
Which chips did you test exactly?
The four "Mario Chip 1", "GSU-1", "GSU-2", "GSU-2-SP1" that you've mentioned above?
So the only unknown VCR code would be for "GSU-1A"?
I tested all US SNES SuperFX games:
Dirt Trax FX -> GSU-1 -> VCR=4
Doom -> GSU-2 -> VCR=4
Star Fox -> MARIO CHIP 1 -> VCR=1 (not the epoxy blob version, I could see the writing on the chip)
Stunt Race FX -> GSU-1 -> VCR=4
Super Mario World 2: Yoshi's Island -> GSU-2-SP1 -> VCR=4
Vortex -> GSU-1 -> VCR=4
It is indeed very strange to me that I only encountered two VCR codes.
The MARIO CHIP 1 in Star Fox appears to be a Beta version, so I guess the other VCR must be VHS.
(
ducks)