It is currently Sat Sep 22, 2018 10:10 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 90 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Mon Jul 16, 2018 1:14 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 632
Okay, there is a serial number under the satellaview...
Is that the same thing as the barcode on this picture: https://static.giantbomb.com/uploads/or ... view1.jpeg ?
Well, that isn't under the satellaview, but maybe they've plastered it with the same barcode everywhere.
I am afraid nobody has ever photographed the bottom side of the satellaview. Only found a photo of the SNES's bottom: http://www.nintendoworldreport.com/media/27664/4/2.jpg which is also having a similar barcode. My own PAL/SNES has barcode "UPnnnnnnnn"
So, those barcodes seem to be two letters and eight digits, the last digit probably being a barcode checksum - and when removing that last digit - the remaining seven digits are your "???????" string in ASCII, then followed by a non-ASCII byte with value A4h, and the rest of the eeprom is filled with FFh bytes?

Wished I would have a satellaview, so I could check myself, I've only the BIOS cartridge, but not the base unit.

Getting E00000h from 2199h might be some sort of data, or garbage... if the "E" is in the first some bits, then it might come from some floating pin that drops to low during reading for whatever reason, if it's so then you might get values like F80000h or C00000h when outputting the serial CLK at different speeds.


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 2:19 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 632
Getting E00000h shouldn't happen, at least not when sending the usual 2199h init sequence (and then repeatedly reading the 24bit data).
Itoi wants the MSB (first bit) to be zero. If it doesn't get that after repeated reading, then it does do some timeout and disables the Satellaview option in the game main menu.

Either there is hardware in the console (and it does output another value than E00000h at some point).
Or, Itoi is trying to detect add-on hardware (and passes okay if the open-bus pin drops to zero at some point).

EDIT: Also, compared to the 24bit read BIOS function, Itoi is writing chip select, clock and data.out at least slightly differently, so BIOS might be bugged?

EDIT: Speaking of bugs, the "send_16bit_to_port_2199" (1059B0h) function works only if DB points to a low rom bank (for accessing DB:2199h), one of the BIOS patches in SRAM is fixing that.


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 7:29 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 420
Location: FL
nocash wrote:
EDIT: Also, compared to the 24bit read BIOS function, Itoi is writing chip select, clock and data.out at least slightly differently, so BIOS might be bugged?

I'm at work right now so can't check either version, but I seem to remember the BIOS reading $2199 on the opposite clock edge as when reading $2198 - is that changed in the Itoi version?


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 12:49 pm 
Offline
User avatar

Joined: Thu Jul 29, 2010 2:24 pm
Posts: 56
nocash wrote:
Okay, there is a serial number under the satellaview...
Is that the same thing as the barcode on this picture: https://static.giantbomb.com/uploads/or ... view1.jpeg ?
Well, that isn't under the satellaview, but maybe they've plastered it with the same barcode everywhere.
I am afraid nobody has ever photographed the bottom side of the satellaview. Only found a photo of the SNES's bottom: http://www.nintendoworldreport.com/media/27664/4/2.jpg which is also having a similar barcode. My own PAL/SNES has barcode "UPnnnnnnnn"

Then let me solve this problem myself: https://imgur.com/a/hdHKqwf
I've put all the photos that I took of my Satellaview unit, with a photo of the bottom of mine that I took just now.

nocash wrote:
So, those barcodes seem to be two letters and eight digits, the last digit probably being a barcode checksum - and when removing that last digit - the remaining seven digits are your "???????" string in ASCII, then followed by a non-ASCII byte with value A4h, and the rest of the eeprom is filled with FFh bytes?

Yes. That's exactly right.

nocash wrote:
Getting E00000h from 2199h might be some sort of data, or garbage... if the "E" is in the first some bits, then it might come from some floating pin that drops to low during reading for whatever reason, if it's so then you might get values like F80000h or C00000h when outputting the serial CLK at different speeds.

To be honest, I had a different reaction before but it was because my tester was programmed a little sloppily, but it does use the BS-X BIOS' functions.

nocash wrote:
EDIT: Also, compared to the 24bit read BIOS function, Itoi is writing chip select, clock and data.out at least slightly differently, so BIOS might be bugged?

EDIT: Speaking of bugs, the "send_16bit_to_port_2199" (1059B0h) function works only if DB points to a low rom bank (for accessing DB:2199h), one of the BIOS patches in SRAM is fixing that.

I guess I didn't actually think of that patch when I tested it. I should try again. Though since sd2snes got a new firmware and everything and I don't feel like switching, I'll rewrite my Memory Pack to see about that, and change the SRAM for the sake of having updates.


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 9:54 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1388
nocash wrote:
Getting E00000h shouldn't happen, at least not when sending the usual 2199h init sequence (and then repeatedly reading the 24bit data).
Itoi wants the MSB (first bit) to be zero. If it doesn't get that after repeated reading, then it does do some timeout and disables the Satellaview option in the game main menu.


Oh wow, so the option doesn't show up without the base unit attached ...

I wonder if SD Gundam G Next has a similar limitation. I've never been able to actually observe a difference using the data pack no matter how I emulated it. My base unit emulation is junk at the moment. Only really emulate the town cart registers well so far, and basic channel data for the flashable paks (disabled for mask ROM paks.) Well, that and SA1 SuperMMC banks 4-7 rerouting to the BS memory pack.

Also curious if any released Satellaview images actually need these SRAM patches to be playable. That'll pose a tricky problem for emulation. Only thing that immediately comes to mind is bundling BS-X Town SRAM files into BS Memory Pack gamepaks (ZIP archives.) Probably not legal to ship SRAM files with copyrighted code with emulators.


Top
 Profile  
 
PostPosted: Tue Jul 17, 2018 1:11 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 632
Here are my findings on the EEPROM functions... read_multiple has X=num_words, read_word returns data in X (the dataword is also in A, but that's unintended, and A is in 8bit mode at that time), write_all does fill the memory by the dataword value (said so in datasheet), verify_multiple checks if the upper half of memory is filled by value X, used after write_all and erase_all, but that verify is bugged (the POP opcode smashes the zeroflag from preceeding CMP opcode) (verifying only the upper is probably related to /PROTECT pin, which might write protect the lower half... depending on how it's wired).
Code:
  1059B8 eeprom_read_multiple             ;in: A=addr6bit, X=num_words, DB:Y=dest, out: [DB:0000h+Y+(0..X*2-1)]=data    ;DB must be a lorom bank
  1059BC eeprom_read_word                 ;in: A=addr6bit, out: X=word (and A=word, too, M is in 8bit mode though)      ;DB must be a lorom bank
  1059C0 eeprom_write_multiple            ;in: A=addr6bit, X=num_words, D+Y=src, out: cy=1=error
  1059C4 eeprom_write_word                ;in: A=addr6bit, X=word, out: cy=1=error
  1059C8 eeprom_internal_write_word       ;in: A=addr6bit, X=word      (internal subfunction for write) (without program_enable and without verify)
  1059CC eeprom_write_all                 ;in: X=word/fillvalue, out: cy=1=always (bugged, should be cy=1=error)
  1059D0 eeprom_erase_word                ;in: A=addr6bit, out: cy=1=error                  ;note: erase is NOT needed before writing
  1059D4 eeprom_erase_all                 ;out: cy=1=always (bugged, should be cy=1=error)  ;note: erase is NOT needed before writing
  1059D8 eeprom_internal_verify_multiple  ;in: X=expected_fill_value_for_upper_half_of_eeprom, out: cy=1=always (bugged, should be cy=1=error)     ;BUGGED
  1059DC eeprom_internal_verify_word      ;in: A=addr6bit, X=expected_word, out: cy=1=error  (internal subfunction for write/erase)
  1059E0 eeprom_internal_program_enable   ;in/out: nothing, A,Y=unchanged       (internal subfunction for write/erase)
  1059E4 eeprom_internal_program_disable  ;in/out: nothing, A,Y,P=unchanged     (internal subfunction for write/erase)
  1059E8 eeprom_internal_send_byte        ;in: A=byte      (internal subfunction for sending commands)
  1059EC eeprom_internal_wait_busy        ;in/out: nothing (internal subfunction for write/erase)


As far as I know the only two cartridges that use ports 21xxh for the satellaview base unit are Derby96 and Itoi, ie. SD Gundam G-Next shouldn't be affected by having or not having the base unit.

For 2199h, during transfer, the select pin is same in Itoi and BIOS. The transfer starts up a bit differently, and the data.out pin is inverted (but it might be just a dummy value when reading). I would think it goes to the CCS, CCK, CTLI, CTLO pins shown here viewtopic.php?f=12&t=14493&start=30#p204015 the MN88831 datasheet uses the same names (except that it lacks CTLO, which might exist only on the bigger MN88821 chip).

EDIT: The EEPROM Content, using the barcode from the photo... gives a checksum byte
Code:
  00h 5   ASCII "BSA00"                                         ;="BSA00"
  05h 7   ASCII "nnnnnnn" (from "BSnnnnnnnx" barcode/sticker)   ;="1076682"
  0Ch 1   Checksum byte (all ASCII bytes added together)        ;=A4h
  0Ch 33h Empty (FFh-filled)                                    ;=FFh's


Top
 Profile  
 
PostPosted: Tue Jul 17, 2018 4:27 am 
Offline
User avatar

Joined: Thu Jul 29, 2010 2:24 pm
Posts: 56
I just tried Itoi Bass Fishing on my SFC + Satellaview setup: The Satellaview option is not selectable. So I suspect my tool actually works just fine.
EDIT: Made sure if Itoi was reading $2196 or not. It doesn't so I'm guessing it only cares about that $2199 and $2194.

EDIT2: For some reason, I never checked if there was any more Satellaview registers... and I did find something new:
Code:
$219A always returns 10h
$219B to $219F always returns 00h
$21A0 to $21FF is open bus.

EDIT3:
I rocked out the multimeter and tried to find the pinout of each chip, this is what I have so far:
https://docs.google.com/spreadsheets/d/ ... cTcRQ/edit
EDIT4: seems I got the full pinout of the Satellaview EXT port... and seemingly it's directly connected to the SNES EXT port bus, and some pins of the DCD-BSA chip.
So what I thought of $2199 is most likely wrong. $2199 is most likely MN88821 serial access.
Maybe $218A is EXT port serial port? Maybe $2195? And then there are a few direct EXT port access (which only PA0, PA1 and PA2 is directly connected to it for some reason).


Top
 Profile  
 
PostPosted: Thu Jul 19, 2018 1:48 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 632
You have made a tool that makes the Satellaview option non-selectable in Itoi?

Hmmm google docs, this link works slightly better with browsers https://docs.google.com/spreadsheets/d/ ... /htmlview# but it's showing only U1 pinouts, the links to U2, U3, etc. show up, but clicking them doesn't do anything. Or well, I can see them on an android toy computer. For CN2, you seem to have missed EXT.pin23 = IRQ, see viewtopic.php?f=12&t=14493&start=30#p203608

Of the five unknown EXT port pins, one should be a select signal for the 8-byte PA0-PA2 space somewhere at 21A0h-21FFh, and one should be the LED signal shown in the patent, the other three might be whatever, my best guess would be some CLK signals, I don't remember anything hinting on a serial port on the EXT connector.

Okay, so the SPR-BSA EEPROM has VCC/GND same as the "DIP" pinout in Seiko/Seeq datasheet (as opposed to the "SMD" pinouts). That, despite of SPR-BSA being a SMD chip, so the chip is at least slightly customized concerning pinout/package. The pins other than VCC/GND might be following the "DIP" pinout, too, if /PROTECT is not connected (or GNDed) then the lower half of the EEPROM should be write-protected (going by datasheet).

The extra features for SD Gundam G-NEXT with extra ROM PAK are hidden among the standard features, this page shows what to look for https://satellaview.org/1996/sd-gundam- ... -pack-2-15 (requires some paranoid https revision). The ROM PAK works okay in no$sns, it seems to be mapped via port [2223h]=84h, ie. pad the 1.5MB cart ROM to 4MB size, then append the ROM PAK at the end of the file.


Top
 Profile  
 
PostPosted: Thu Jul 19, 2018 2:19 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3606
Location: Mountain View, CA
nocash wrote:
Hmmm google docs, this link works slightly better with browsers https://docs.google.com/spreadsheets/d/ ... /htmlview# but it's showing only U1 pinouts, the links to U2, U3, etc. show up, but clicking them doesn't do anything.

Crappy browser, or crappy JavaScript somewhere. All of these tabs/pages (both in the original link and the htmlview'd link, work fine in Google Chrome on Windows and OS X -- I tested 'em).


Top
 Profile  
 
PostPosted: Thu Jul 19, 2018 3:12 am 
Offline
User avatar

Joined: Thu Jul 29, 2010 2:24 pm
Posts: 56
nocash wrote:
You have made a tool that makes the Satellaview option non-selectable in Itoi?

No, I meant that the tool reads registers and serial registers, so while E00000h may seem weird, and uses the BS-X BIOS functions, Itoi does seem to have a similar output since the Satellaview option isn't selectable.

Yeah sorry I use Google Docs because it's faster for me to make something and share quickly.
I'd say the SPR-BSA chip is customized since it does say SPR on it and the ID on it does not correspond to a known EEPROM, at least in my case.

Also while I made this Google Sheet, I don't want to pretend I'm good at this (and I did try to find /IRQ, but I guess I didn't get to the right inverter? The PCB is really really small).
I guess I somehow missed the posts about the EXT port here.

EDIT:
Just tested SPR-BSA EEPROM writing. The first half does not do anything but I've successfully written and erased a byte for the second half.


Top
 Profile  
 
PostPosted: Sat Aug 11, 2018 1:57 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 420
Location: FL
More register findings using my recently purchased Satellaview:

  • CN2 pin 29 (U5 pin 75) goes low when accessing $xxA0 through $xxA7
  • CN2 pin 30 (U5 pin 74) goes low when accessing $xxA8 through $xxAF
  • CN2 pins 33 and 34 (U5 pins 82 and 83) are respectively latched from writing bits 1 and 0 of $2197 (both high on powerup)
  • CN2 pin 31 (U5 pin 72) is EXLED, $2194 bits 2-3 control behavior (active high, active low or ignored)

Essentially, combined with A2:0, /PARD and /PAWR, these signals map $21Ax and part of $2197 to the Satellaview EXT port.

Edit: added other pins

Edit 2: added (hopefully final) EXLED behavior


Last edited by Revenant on Sat Aug 18, 2018 10:11 am, edited 5 times in total.

Top
 Profile  
 
PostPosted: Mon Aug 13, 2018 6:24 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 632
Cool, that's solving most of the remaining pins. Interesting that there are two 8-byte areas instead of only one 8-byte area.
What do you mean by "high->low when accessing $xxA0 through $xxA7"? That sounds as if it's LOW by default (eg. when accessing xxFFh), and goes HIGH for a short moment when accessing xxA0-A7? Ie. it's a active high SELECT, rather than active low /SELECT? Just asking because the latter would be more common. But then, the external IRQ pin is active high, too.

The "xx" in xxA0-xxA7 and xxA8-xxAF is unexpected, I would have thought that it triggers only on 21A0-21A7 or the like.
Hmmm, maybe that's a dirt effect that occurs when NOT using the 21xxh space; ie. the CPU might then output the same address bits to A0-A7 and also to PA0-PA7 (?)
On the other hand, for cases like DMA from ROM to WRAM, A0-A7 and PA0-PA7 would output different addresses (and in that case the satellaview base unit should see the PA0-PA7 address (as it doesn't connect to A0-A7 at all).

For EXLED, I would have assumed the CPU can switch that LED on and off... maybe via some bit in port 2194h... and maybe that works only when also setting 2194h.bit0=1 (to "power on" something)?
Or, as pin33 and pin34 are working as general purpose outputs... maybe one of that bits was supposed to be used as EXLED output?

Or maybe EXLED was meant to be an input... allowing external hardware to inject some signal that blinks the ACCESS LED in the base unit? Yeah, that would make sense for an internal HDD drive (if the drive doesn't have its own LED, but outputs a signal for LED on the front panel). Do you think it'd be risky to try to inject a high/low level to the pin and check if it affects the LED (or if it blows the chip; to avoid that, maybe insert a 1K resistor instead of directly wiring it to GND or VCC)? When testing that, it might be also worth checking if the injected high/low level affects some bit in the 2188h-219Fh registers.


Top
 Profile  
 
PostPosted: Mon Aug 13, 2018 10:50 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 420
Location: FL
nocash wrote:
Cool, that's solving most of the remaining pins. Interesting that there are two 8-byte areas instead of only one 8-byte area.

Yeah, that's strange. It seems like just including PA3 would have been easier for mapping the same 16-byte region.

nocash wrote:
What do you mean by "high->low when accessing $xxA0 through $xxA7"? That sounds as if it's LOW by default (eg. when accessing xxFFh), and goes HIGH for a short moment when accessing xxA0-A7? Ie. it's a active high SELECT, rather than active low /SELECT? Just asking because the latter would be more common. But then, the external IRQ pin is active high, too.

No, it's active low/default high (i.e. transitions high->low->high when the access occurs).

nocash wrote:
The "xx" in xxA0-xxA7 and xxA8-xxAF is unexpected, I would have thought that it triggers only on 21A0-21A7 or the like.
Hmmm, maybe that's a dirt effect that occurs when NOT using the 21xxh space; ie. the CPU might then output the same address bits to A0-A7 and also to PA0-PA7 (?)

A7:0 and PA7:0 are indeed the same when only using Bus A (this is how defparam's 21fx hijacks the reset vector, for example). I did specifically confirm that accessing e.g. $80Ax also outputs those signals, though you also don't get /PARD or /PAWR when doing that.

nocash wrote:
For EXLED, I would have assumed the CPU can switch that LED on and off... maybe via some bit in port 2194h... and maybe that works only when also setting 2194h.bit0=1 (to "power on" something)?
Or, as pin33 and pin34 are working as general purpose outputs... maybe one of that bits was supposed to be used as EXLED output?

Or maybe EXLED was meant to be an input... allowing external hardware to inject some signal that blinks the ACCESS LED in the base unit? Yeah, that would make sense for an internal HDD drive (if the drive doesn't have its own LED, but outputs a signal for LED on the front panel). Do you think it'd be risky to try to inject a high/low level to the pin and check if it affects the LED (or if it blows the chip; to avoid that, maybe insert a 1K resistor instead of directly wiring it to GND or VCC)? When testing that, it might be also worth checking if the injected high/low level affects some bit in the 2188h-219Fh registers.

The CPU can control the LED with $2194, but I don't know if it requires the streams to also be enabled with bit 0 or not (but I think the only time BS-X enables the LED is when it's also downloading something).

I'm pretty sure EXLED is supposed to just be an input (see this block diagram from the patents which has EXLED coming into the data decoder chip from the expansion port with another signal going out to the actual LED). I haven't tried wiring it up directly yet, though.

I haven't tried any tests specifically involving the other registers either, but I'd like to try playing around with the unknown ones at $2195 and $219A-9F somehow. Also, pins 33/34 are both high at first even though (according to LuigiBlood) reading $2197 initially returns 0x80, so I'm not sure if those pins are just latched separately from the actual register value when a write occurs or something.


Top
 Profile  
 
PostPosted: Tue Aug 14, 2018 5:17 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 632
Good to know that the select lines are active low. Yup, also noticed that they could have used PA3 instead of the second select line, guess they have planned some hardware consisting of two chips, thus needed two select lines.

Interesting that PA0-7 and A0-7 are actually same on A-Bus-only access. Hmmm, in this case (when adding your findings to BSX info in fullsnes.htm)... maybe I could mention it in the pinout chapter... but I'd rather omit it in the overall I/O description, saying "Port FFA0h and the like ARE ALSO part of the BSX I/O map - but they WON'T DO anything because they doesn't trigger /PARD and /PAWR !!!" would be a bit pointless in that place ; )

You are right, the blurry lines/arrows in the block diagram are looking as if EXLED is meant to be an input. If you test if the LED reacts to dragging the suspected EXTLED pin Low (or High) would be cool! Apropos (hope I didn't already asked that elsewhere): The Power LED and Access LED, are normal 2-pin LEDs; with only one color each? And the Power LED, is there a way to switch it on/off, or is it simply wired to VCC+GND+resistor?

If it's really initially [2197h]=80h, and if that doesn't match up with the two output pins being initially high: Maybe there are some more bits used in the same register (or in another register) for changing the pin-direction (ie. the "output=high" might be actually "input=highZ").


Top
 Profile  
 
PostPosted: Wed Aug 15, 2018 10:28 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 420
Location: FL
The power LED is controlled directly by the power supply just like the one on the actual SFC (you can see as such in one of the other patent diagrams), and the access LED is powered by one of the outputs from DCD-BSA, but they're both basically regular single-color LEDs.

Anyway, I did a quick test with pulling the pin both high and low and neither one seemed to actually affect the LED. It could be that some other register setting is required first or possibly that the pin is actually just a regular input (probably active low, it seems to be pulled up normally) readable in some register.

I'm going to do more register testing in software but first I'll have to either:
  • get a new(-ish) sd2snes firmware that doesn't emulate the same registers on its own, or
  • figure out why my Super UFO crashes only when trying to boot into DRAM on my Japanese SFC with the BS-X cart attached (unless I can test the same registers without having the BS-X cart attached to provide the EXPAND signal). I was going to email sanmaiwashi to see if he had any suggestions there.

edit: Register state on reset without BS-X cart present: (reading each register once in a row)
Code:
$2188: 00
$2189: 00
$218A: 00
$218B: 9F
$218C: 00
$218D: 9F

$218E: 00
$218F: 00
$2190: 00
$2191: 9F
$2192: 00
$2193: 9F

$2194: 00
$2195: 00
$2196: 02
$2197: FF

$2198: 80
$2199: 01
$219A: 00
$219B: 00
$219C: 00
$219D: 00
$219E: 00
$219F: 00


BS-X does manually set $2197 to #$80 on startup, though. (edit: misremembered; it only sets bit 7)


Last edited by Revenant on Sat Aug 18, 2018 10:13 am, edited 1 time in total.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 90 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group