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.
SuperFX GSU-1/GSU-2 pinout
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: SuperFX GSU-1/GSU-2 pinout
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:
For the Blob, the mirroring is rather messy:
The Speed Test results are:
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:
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 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 I/O mirrors for GSU2 are quite straight:
Code: Select all
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
Code: Select all
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
Code: Select all
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 ;/
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: Select all
Writes to 3000h-301Eh (even addresses) do set LATCH=data.
Writes to 3001h-301Fh (odd addresses) do apply LSB=LATCH and MSB=data.
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 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.
-
qwertymodo
- Posts: 775
- Joined: Mon Jul 02, 2012 7:46 am
Re: SuperFX GSU-1/GSU-2 pinout
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.
Re: SuperFX GSU-1/GSU-2 pinout
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.
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.
Re: SuperFX GSU-1/GSU-2 pinout
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.
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.
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.
Re: SuperFX GSU-1/GSU-2 pinout
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.
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.
-
qwertymodo
- Posts: 775
- Joined: Mon Jul 02, 2012 7:46 am
Re: SuperFX GSU-1/GSU-2 pinout
If you're interested in the difference between the 2 versions of Star Fox, I just uploaded PCB pics: http://imgur.com/a/U0LXy
Re: SuperFX GSU-1/GSU-2 pinout
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:
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).
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.
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 - 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).
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: Select all
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)
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: Select all
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
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: Select all
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
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 - 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).
Re: SuperFX GSU-1/GSU-2 pinout
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.
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.
Re: SuperFX GSU-1/GSU-2 pinout
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:
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).
Code: Select all
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 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).
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.byuu wrote:my mapper skips probing 00-3f,80-bf:0000-5fff; because writing to I/O regs could affect other things.
Re: SuperFX GSU-1/GSU-2 pinout
> 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.
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.
Re: SuperFX GSU-1/GSU-2 pinout
> 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 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? 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 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.
Re: SuperFX GSU-1/GSU-2 pinout
> 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.
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.
Re: SuperFX GSU-1/GSU-2 pinout
I just added a lot of new SuperFX revisions to the database.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/vie ... E6MQ#gid=0
and view the gathered data at: https://docs.google.com/spreadsheet/ccc ... U0zSDJ4OUE
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.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
Here's an another update 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.
Re: SuperFX GSU-1/GSU-2 pinout
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).
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).