Page 3 of 8

Re: BS-X Satellaview Datapak's

Posted: Wed Sep 21, 2016 8:57 am
by LuigiBlood
nocash wrote:Apropos Sound: Did anybody ever verify if the BS-X receiver unit does really connect to the external audio inputs on the SNES expansion port? It probably does so, but there's still at a small chance that the "soundlink" feature was implemented by streaming data to the APU instead of using the external audio inputs.
Well I would love to know, but I would be surprised if it didn't. There's a PCM decoder in the Satellaview base unit, I doubt it's for nothing.

I'm annoyed though, there's still no high quality pics of the PCB on both sides.

EDIT: Here are some names and specs coming from the White Satellaview manual:
-Satellaview
DCD (Data Channel Decoder)
PCM Decoder
Data Receiver Speed: 668 kbps

-BS-X
MCC (Memory Map Controller and Security Chip) [Yes, I swear, that's the actual name]

EDIT2: I may found the key to understand how the Satellaview works.
Apparently, Hi-Vision Laserdiscs COULD work on the Satellaview for the audio. And I'm not even joking.
I found out that BS Tuners are usually what is used to decode them.

Re: BS-X Satellaview Datapak's

Posted: Mon Aug 28, 2017 6:21 pm
by DaveyPocket
nocash wrote:Apropos Sound: Did anybody ever verify if the BS-X receiver unit does really connect to the external audio inputs on the SNES expansion port? It probably does so, but there's still at a small chance that the "soundlink" feature was implemented by streaming data to the APU instead of using the external audio inputs.
Might be a little late for this post.... We are referring to the Satellaview base unit, correct? The expansion port audio pins do connect to an op-amp (U9 - LM324) on the PCB. Left channel (Expansion port 27) is connected to pin 14 of U9 through some RC-type circuit. Right channel (Expansion port 28) is on pin 1 of U9 in a similar fashion. Both op-amps configured as buffers. Haven't traced where inputs of op-amps go to yet.

Re: BS-X Satellaview Datapak's

Posted: Tue Aug 29, 2017 6:37 am
by nocash
Cool, that's still interesting & good to have it confirmed that there's really a connection to the expansion/audio pins! Did you comapre the LM324 wiring to SNES mainboard schematic? It's having LM324, too (with each channel having two opamp's in series, in lack of knowing a better name, I've called them "pre-amp" and "post-amp").

The opamp wired "as buffer" means that it has OUT and IN- shortcut with each other? That would be same as for the "pre-amp" on the mainboard (and makes sense since that satellaview "pre-amp" signal is then mixed with the snes "pre-amp" signal; and then passed to the "post-amp" on the snes mainboard).

On the SNES, the pre-amp's IN+ pin is wired via three 22K resistors (=66K) to the DAC's audio output. In the satellaview unit it's probably wired to the 64pin or 100pin chip. Ah, and/or... it might also go to one of the six "???" pins on the 38pin CN2 connector.

PS. just curious, as the LM324 is a quad opamp, and needing only two opamp's for the stereo audo... are the other two opamp's used for something, too?

Re: BS-X Satellaview Datapak's

Posted: Tue Aug 29, 2017 6:34 pm
by DaveyPocket
The opamp wired "as buffer" means that it has OUT and IN- shortcut with each other?
Yes. The gain should ideally be 1:1.
Did you comapre the LM324 wiring to SNES mainboard schematic? It's having LM324, too (with each channel having two opamp's in series, in lack of knowing a better name, I've called them "pre-amp" and "post-amp").
Yes, they have similar configurations - One "pre-amp" (the buffer stage) with some RC filters and the "post-amp" (the gain stage) that has connections for mixing three separate inputs with an added transistor for muting the output. There are some differences.

I should draw up a schematic...
PS. just curious, as the LM324 is a quad opamp, and needing only two opamp's for the stereo audo... are the other two opamp's used for something, too?
After doing some quick probing the op-amp setup appears to be almost the reverse of what the SNES has - being that the gain stage ("post-amp") with the muting signal (I am going to assume it is a muting signal) comes prior to the buffer ("pre-amp"), the buffer ("pre-amp") then connects to expansion port.
In the satellaview unit it's probably wired to the 64pin or 100pin chip. Ah, and/or... it might also go to one of the six "???" pins on the 38pin CN2 connector.
Decided to probe those out.

Code: Select all

EXT_port --- Chip.Pin

23 --- Q5.Base (Collector of Q5 to /IRQ on SNES Expansion port, Emitter to GND)
29 --- U5.75
30 --- U5.74
31 --- U5.72
33 --- U5.82
34 --- U5.83

Re: BS-X Satellaview Datapak's

Posted: Tue Aug 29, 2017 7:30 pm
by nocash
Okay, then EXT.pin23 should be an "active high IRQ input, inverted via Q5, and then passed to active low SNES /IRQ", right?
I wonder if there's another IRQ source in the base unit? Going by the BSX BIOS disassembly there isn't anything hinting on IRQs from the base unit (however, the BSX BIOS cart itself can throw Datapak IRQs).

The other five pins going to the custom DCD-BSA chip (U5) could be anything... but nice to know that they do connect to U5.

If you feel like doing more probing, there's this (yet unconfirmed) sentence in fullsnes.htm: "The U3 transceiver is probably passing databus to/from SNES, the U1/U2 drivers are maybe passing some address/control signals from SNES."

Re: BS-X Satellaview Datapak's

Posted: Wed Aug 30, 2017 7:39 pm
by DaveyPocket
nocash wrote:Okay, then EXT.pin23 should be an "active high IRQ input, inverted via Q5, and then passed to active low SNES /IRQ", right? I wonder if there's another IRQ source in the base unit? Going by the BSX BIOS disassembly there isn't anything hinting on IRQs from the base unit (however, the BSX BIOS cart itself can throw Datapak IRQs).
Yes. The output is of the inverter should be considered open-collector. The input (base) is pulled low by 4.7kOhm resistor. I cannot seem to find any other source of IRQ except the EXT port on the Satellaview receiver unit.
If you feel like doing more probing, there's this (yet unconfirmed) sentence in fullsnes.htm: "The U3 transceiver is probably passing databus to/from SNES, the U1/U2 drivers are maybe passing some address/control signals from SNES."
Good observation! U1 is for PA address bus. U3 is for data bus. U2 is for control.

Code: Select all

SNES expansion port - Resistor - IC.pin

Address bus
PA0 - 110ohm - U1.9
PA1 - 110ohm - U1.8
PA2 - 110ohm - U1.7
PA3 - 110ohm - U1.6
PA4 - 110ohm - U1.5
PA5 - 110ohm - U1.4
PA6 - 110ohm - U1.3
PA7 - 110ohm - U1.2

Data bus
D0 - 20ohm - U3.9
D1 - 20ohm - U3.8
D2 - 20ohm - U3.7
D3 - 20ohm - U3.6
D4 - 20ohm - U3.5
D5 - 20ohm - U3.4
D6 - 20ohm - U3.3
D7 - 20ohm - U3.2

Control
/PAWR - 75ohm - U2.9
/PARD - 75ohm - U2.8
EXPAND - 0ohm - U2.7 (yes, 0 ohm resistor)
/RESET - 75ohm - U2.6

other...
All "/OE" type pins on U1, U2, U3 are connected to GND. Meaning the buffers are always active, they can never be in a hi-z output state.
Pin 20 on IC U5 controls data bus direction (U3.1)

Re: BS-X Satellaview Datapak's

Posted: Thu Aug 31, 2017 11:59 am
by nocash
Many thanks! Then, putting it together, the connector pin-out should be as so (in left column (with the old info from byuu & your new in info in right two columns)):

Code: Select all

BSX-EXT-Port Pinouts
  1  = +5V
  2  = +5V
  3  = +5V
  4  = +5V
  5  = GND
  6  = GND
  7  = GND
  8  = GND        <----byuu----------->        <--Davey--->
  9  = GND
  10 = GND
  11 = D6         U3.pin17 (74LS245 B2)     -- U3.pin3 (A2)  ;\
  12 = D7         U3.pin18 (74LS245 B1)     -- U3.pin2 (A1)  ;
  13 = D4         U3.pin15 (74LS245 B4)     -- U3.pin5 (A4)  ; transceiver
  14 = D5         U3.pin16 (74LS245 B3)     -- U3.pin4 (A3)  ;
  15 = D2         U3.pin13 (74LS245 B6)     -- U3.pin7 (A6)  ;
  16 = D3         U3.pin14 (74LS245 B5)     -- U3.pin6 (A5)  ;
  17 = D0         U3.pin11 (74LS245 B8)     -- U3.pin9 (A8)  ;
  18 = D1         U3.pin12 (74LS245 B7)     -- U3.pin8 (A7)  ;/
  19 = /PAWR      U2.pin11 (2nd 74LS541 Y8) -- U2.pin9 (A8)
  20 = GND
  21 = /PARD      U2.pin12 (2nd 74LS541 Y7) -- U2.pin8 (A7)
  22 = GND
  23 = IRQ                       (inverted via Q5, then passed to SNES /IRQ)
  24 = GND
  25 = PA1        U1.pin12 (1st 74LS541 Y7) -- U1.pin8 (A7)
  26 = GND
  27 = PA0        U1.pin11 (1st 74LS541 Y8) -- U1.pin9 (A8)
  28 = PA2        U1.pin13 (1st 74LS541 Y6) -- U1.pin7 (A6)
  29 = ?                                       U5.pin75 (DCD-BSA)
  30 = ?                                       U5.pin74 (DCD-BSA)
  31 = ?                                       U5.pin72 (DCD-BSA)
  32 = /RESET     U2.pin14 (2nd 74LS541 Y5) -- U2.pin6 (A5)
  33 = ?                                       U5.pin82 (DCD-BSA)
  34 = ?                                       U5.pin83 (DCD-BSA)
  35 = GND
  36 = GND
  37 = GND
  38 = GND
The PA0..PA2 address lines alone aren't useful, but there's probably a "select" signal on one of the five DCD-BSA chip pins (getting triggered when the upper bits in PA3..PA7 have a certain value, ie. for eight bytes somewhere in the Port 21A0h..21BFh area).

Hmmmm, and the other four DCD-BSA pins might be a SPI bus with /CS,CLK,DTA.IN,DTA.OUT (assuming that Port 2198h might go to some external serial-bus hardware).

EXPAND isn't forwarded to the connector. NB. in general, EXPAND can be a "general purpose signal from the cartridge", but, with satellaview cartridges it's having a fixed purpose: EXPAND is always wired to SYSCK via 100 ohm (as so in BSX BIOS cart, and BSX carts like Itoi/Derby, and also in Nintendo Power flashcarts (making them theoretically BSX-compatible)).

Re: BS-X Satellaview Datapak's

Posted: Thu Aug 31, 2017 7:32 pm
by DaveyPocket
EXPAND isn't forwarded to the connector. NB. in general, EXPAND can be a "general purpose signal from the cartridge", but, with satellaview cartridges it's having a fixed purpose: EXPAND is always wired to SYSCK via 100 ohm (as so in BSX BIOS cart, and BSX carts like Itoi/Derby, and also in Nintendo Power flashcarts (making them theoretically BSX-compatible)).
That is interesting. Assuming SYSCK is an abbreviation of "System Clock"?

The only other source of a clock signal is from the 18.432 MHz oscillator paired with the VCO (Voltage Controlled Oscillator U7). This frequency appears to be a common frequency from doing a quick search.
According to Wikipedia:

Code: Select all

UART clock (10×1.8432 MHz); allows integer division to all common baud rates. Also allows integer division to 48 kHz (384×48 kHz), 96 kHz, and 192 kHz sample rates used in high-end digital audio.

Re: BS-X Satellaview Datapak's

Posted: Thu Aug 31, 2017 8:43 pm
by nocash
DaveyPocket wrote:That is interesting. Assuming SYSCK is an abbreviation of "System Clock"?
The only other source of a clock signal is from the 18.432 MHz oscillator paired with the VCO (Voltage Controlled Oscillator U7). This frequency appears to be a common frequency from doing a quick search.
Yes, SYSCK should be short for "System Clock". Though "Memory Access Clock" might be a better name (as far as I know, that "clock" signal varies for slow/fast memory accesses, during the "/PAxx" accesses it should be clocked at 3.58MHz).
The 18.432 MHz might be whatever needed to tick the receiver hardware, probably matched to the satellite's bitrate.
LuigiBlood wrote:Data Receiver Speed: 668 kbps
MCC (Memory Map Controller and Security Chip) [Yes, I swear, that's the actual name]
That 668kbps doesn't match too well to 18.432MHz though. But maybe it's meant to be 668kbps "excluding packet headers" (or "excluding error correction info", if there's been such a thing used).
If "bps" stands for bits per second for all data+audio channels then... that seems a bit slow (not really suitable for uncompressed audio broadcasts).
MMC being something like "Memory Controller & Cicurity" sounds just right (it does memory mapping, and has a CIC in it).

Re: BS-X Satellaview Datapak's

Posted: Fri Sep 01, 2017 3:27 pm
by LuigiBlood
nocash wrote:
LuigiBlood wrote:Data Receiver Speed: 668 kbps
MCC (Memory Map Controller and Security Chip) [Yes, I swear, that's the actual name]
That 668kbps doesn't match too well to 18.432MHz though. But maybe it's meant to be 668kbps "excluding packet headers" (or "excluding error correction info", if there's been such a thing used).
If "bps" stands for bits per second for all data+audio channels then... that seems a bit slow (not really suitable for uncompressed audio broadcasts).
MMC being something like "Memory Controller & Cicurity" sounds just right (it does memory mapping, and has a CIC in it).
Honestly something's not right but I think 668kbps is just data and does not count the rest but it's really weird.
It's the manual saying it though. But it doesn't fit how it works via Digital NTSC subcarrier data speed...

EDIT: Also, this may be worth reading: http://forum.lddb.com/viewtopic.php?f=25&t=6569
Putting aside my own ignorance on how things kind of work...

Re: BS-X Satellaview Datapak's

Posted: Fri Sep 01, 2017 8:27 pm
by DaveyPocket
EDIT: Also, this may be worth reading: http://forum.lddb.com/viewtopic.php?f=25&t=6569
I stumbled across this when looking for anything related to the MN88821: Screenshot of diagram

It was in an application note document of reference designs of other Panasonic devices. That forum thread you linked, it appears the conclusion is that the data going into the Satellaview base unit from the BS tuner is simply 1s and 0s (as far as the physical characteristics of the signal). My original concern was that the signal going into the Satellaview receiver was not demodulated entirely (being that the tuner would bring the signal down to some intermediate frequency, then pass this to other devices). I came to this conclusion as I noticed the Satellaview had a voltage controlled oscillator, something that is often used in a PLL circuit in radio receivers (I have limited knowledge on the subject, just remember from DSP and Telecomm. theory courses I took at one point).

Speaking of the 668kbps bit rate, it seems that this is nearly half of the bit rate used in the audio signal transmission (1.35 Mbps / 2 = 675 kbps). Not sure if there is any relation, just thought I would state an observation.

Re: BS-X Satellaview Datapak's

Posted: Wed Sep 06, 2017 3:17 am
by LuigiBlood
Also, as a reminder, japanese Satellaview patents describes the process of the whole thing very very well.
Image

More translated pictures here: http://imgur.com/a/Nq35L
They're from this patent: https://astamuse.com/ja/published/JP/No/1995007481

I also have a list of patents on https://bsxproj.superfamicom.org/links.htm

Basically, MN88821 seems like it gets the RAW data and only takes the PCM audio, and sends the data portions to the DCD-BSA chip managing the data decoding.

Re: BS-X Satellaview Datapak's

Posted: Wed Sep 20, 2017 2:48 pm
by LuigiBlood
Double posting, just to give an update about Satellaview register $2197.

Since we got a new dump, which is Wario's Woods Event Version 2, something was up.
You could set the radio ON or OFF. The kind of stuff that's very explicit how it is done.

Radio ON: Clear bit7 of $2197
Radio OFF: Set bit7 of $2197

It was already figured out, but it's nice to have some confirmation like this. It literally does nothing else.

Re: BS-X Satellaview Datapak's

Posted: Wed Sep 20, 2017 4:32 pm
by DaveyPocket
LuigiBlood wrote:Double posting, just to give an update about Satellaview register $2197.

Since we got a new dump, which is Wario's Woods Event Version 2, something was up.
You could set the radio ON or OFF. The kind of stuff that's very explicit how it is done.

Radio ON: Clear bit7 of $2197
Radio OFF: Set bit7 of $2197

It was already figured out, but it's nice to have some confirmation like this. It literally does nothing else.
This register bit might enable/disable the two transistors in the audio-amp section of the receiver unit (if this has not already been discovered) to disable the sound going into the SNES. I will verify.

Re: BS-X Satellaview Datapak's

Posted: Wed Sep 20, 2017 11:50 pm
by LuigiBlood
DaveyPocket wrote:This register bit might enable/disable the two transistors in the audio-amp section of the receiver unit (if this has not already been discovered) to disable the sound going into the SNES. I will verify.
Considering you can write also to every other bit and returns them just fine, I don't know what's the point of the others.