The Super NES / Famicom to NSS - Nintendo Super System Arcade Adapter

One of the first arcades I'm buying that caught my attention was the NSS, Nintendo Super System. I'm going to be going over a lot of information this post so feel free to freely skim through it.


First of all.. the arcade cabinet in question is a Nintendo Super System or 'NSS' for short. The NSS is an arcade system used to preview Super NES games in the United States. It is essentially the Super NES hardware with a menu interface that—similar to Nintendo's PlayChoice-10 hardware for NES games—allows players to play select Super NES games for a certain amount of time, depending on how many game credits they insert.

Game cartridges available for this cabinet include (but limited to 3 at once)...

• ActRaiser
• The Addams Family
• Contra III: The Alien Wars
• David Crane's Amazing Tennis
• F-Zero
• Lethal Weapon
• NCAA Basketball
• Robocop 3
• The Irem Skins Game
• Super Mario World
• Super Soccer
• Super Tennis

I forget what all was advertised on the cabinet I'm picking up.. but I'm pretty sure it was sports games.. 2 tennis and 1 soccer if I remember correctly.

+++++++++++++++++++++++++

Here's a flyer I found for it at The Arcade Flyer Archive located at http://flyers.arcade-museum.com/ = )

+++++++++++++++++++++++++

So you're probably thinking... "does it play regular Super Nintendo games?" Well, no and yes.

Awhile back a fan-made creation known as the "SNES/SFC to Nintendo Super System Adapter" showed up. He ended up producing a few models of it but has since then stopped developing the adapter. I've been looking for a used copy but they are quite rare and I'd imagine those who do own one, don't want to easily give it up.

So I've gone on a quest to learn as much about them as I can to possibly have my own or get someone else to develop a few again (I need at least 5 myself).

Here's photos of the .pdf file that came with the original adapter...

+++++++++++++++++++++++++

I found all these details at http://problemkaputt.de/fullsnes.htm under 'SNES Hotel Boxes and Arcade Machines.'

Nintendo Super System (NSS) (USA) (1991)
Arcade Cabinet. Contains up to three special cartridges (with one game each).
001- NSS Memory and I/O Maps
002- NSS I/O Ports - Control Registers
003- NSS I/O Ports - Button Inputs and Coin Control
004- NSS I/O Ports - RTC and OSD
005- NSS I/O Ports - EEPROM and PROM
006- NSS BIOS and INST ROM Maps
007- NSS Interpreter Tokens
008- NSS Controls
009- NSS Games, BIOSes and ROM-Images
010- NSS Component Lists
011- NSS On-Screen Controller (OSD)
012- SNES Pinouts NSS Connectors
013- Z80 CPU Specifications

001- NSS Memory and I/O MapsZ80 Memory Map

0000h-7FFFh : 32K BIOS 8000h-9FFFh : 8K RAM (upper 4K with write-protect) A000h : EEPROM Input (R) C000h-DFFFh : Upper 8K of 32K Instruction EPROM (in Cartridge) (INST-ROM) E000h : EEPROM Output (W) Exxxh : PROM Input AND Output AND Program Code (RST opcodes) (R/W/EXEC)

Note: For some reason, Nintendo has stored the 8K INST-ROM in 32K EPROMs - the first 24K of that EPROMs are unused (usually 00h-filled or FFh-filled, and EPROM pins A13 and A14 are wired to VCC, so there is no way to access the unused 24K area).

Z80 IN-Ports

Port 00h.R - IC46/74LS540 - Joypad Buttons and Vsync Flag Port 01h.R - IC38/74LS540 - Front-Panel Buttons & Game Over Flag Port 02h.R - IC32/74LS540 - Coin and Service Buttons Inputs Port 03h.R - IC31/74HC367 - Real-Time Clock (RTC) Input Port 04h.R - Returns FFh (unused) Port 05h.R - Returns FFh (unused) Port 06h.R - Returns FFh (unused) Port 07h.R - Returns FFh (same effect as write-any-value to Port 07h.W)

Port 0008h..FFFFh are mirrors of above ports (whereof, mirrors at xx00h..xx03h are often used).

Z80 OUT-Ports

Port 00h/80h.W - IC40/74HC161 - NMI Control and RAM-Protect Port 01h/81h.W - IC39/74HC377 - Unknown and Slot Select Port 02h/82h/72h/EAh.W - IC45/74HC377 - RTC and OSD Port 03h/83h.W - IC47/74HC377 - Unknown and LED control Port 84h.W - IC25/74HC161 - Coin Counter Outputs Port 05h.W - Unused (bug: written by mistake) Port 06h.W - Unused Port 07h.W - IC23/74HC109 - SNES Watchdog: Acknowledge SNES Joypad Read Flag

These ports seem to be decoded by A0..A2 only (upper address bits are sometimes set to this or that value, but seem to have no meaning).

SNES Memory Map
Normal SNES memory map, plus some special registers:

  4100h/Read.Bit0-7  - DIP-Switches (contained in some NSS cartridges)
  4016h/Write.Bit0   - Joypad Strobe (probably clears the SNES Watchdog flag?)
                          (OR, maybe that occurs not on 4016h-writes,
                          but rather on 4016h/4017h-reads, OR elsewhere?)
  4016h/Write.Bit2   - Joypad OUT2 indicates Game Over (in Skill Mode games)
  4016h/4017h/4218h..421Bh - Joypad Inputs (can be disabled)


002- NSS I/O Ports - Control Registers

Port WHERE.W
Somewhere, following OUTPUT signals should be found:

SNES Reset Signal (maybe separate CPU/PPU resets, and stop, as on PC10) SNES Joypad Disable SNES Power Supply Enable (SNES VCC switched via Q1 transistor) Maybe support for sending data from Z80 to SNES (eg. to 4016h/4017h/4213h)?

Port 00h/80h.W - NMI Control and RAM-Protect (IC40/74HC161)

7-4 Unknown/unused (should be always 0) 3 Maybe SNES CPU/PPU reset (usually same as Port 01h.W.Bit1) 2 RAM at 9000h-9FFFh (0=Disable/Protect, 1=Enable/Unlock) 1 Looks like maybe somehow NMI Related ? ;\or one of these is PC10-style 0 Looks like NMI Enable ;/hardware-watchdog reload?

Usually accessed as "Port 80h", sometimes as "Port 00h".

Port 01h/81h.W - Unknown and Slot Select (IC39/74HC377)

7 Maybe SNES Joypad Enable? (0=Disable/Demo, 1=Enable/Game) 6 Unknown/unused (should be always 0) 5 SNES Sound Mute (0=Normal, 1=Mute) (for optional mute in demo mode) 4 Player 2 Controls (0=CN4 Connector, 1=Normal/Joypad 2) (INST ROM Flags.0) 3-2 Slot Select (0..2=1st..3rd Slot, 3=None) (mapping to both SNES and Z80) 1 Maybe SNES CPU pause? (cleared on deposit coin to continue) (1=Run) 0 Maybe SNES CPU/PPU reset? (0=Reset, 1=Run)

Sometimes accessed as "Port 81h", sometimes as "Port 01h".

Port 03h/83h.W - Unknown and LED control (IC47/74HC377)

7 Layer SNES Enable? (used by token proc, see 7A46h) SNES? 6 Layer OSD Enable? 5-4 Unknown/unused (should be always 0) 3 LED Instructions (0=Off, 1=On) ;-glows in demo (prompt for INST button) 2 LED Game 3 (0=Off, 1=On) ;\ 1 LED Game 2 (0=Off, 1=On) ; blinked when enough credits inserted 0 LED Game 1 (0=Off, 1=On) ;/

Usually accessed as "Port 83h", sometimes as "Port 03h".

Port 05h.W - Unused/Bug

7-0 Unknown

Accessed only as "Port 05h" (via "outd" opcode executed 5 times; but that seems to be just a bugged attempt to access Port 04h downto 00h).

Port 07h.W - SNES Watchdog: Acknowledge SNES Joypad Read Flag (IC23/74HC109)

7-0 Unknown/unused (write any dummy value)

Accessed only as "Port 07h". Writing any value seems to switch Port 00h.R.Bit7 back to "1". That bit is used for the SNES Watchdog feature; the SNES must read joypads at least once every some frames (the exact limit can be set in INST ROM).
If the watchdog expires more than once, then the game is removed from the cartridge list, and used credits are returned to the user (then allowing to play other games; as long as there are any other games installed).
Note: Judging from hardware tests, there seem to be other ways to acknowledge the flag (probably via Port 07h.R, or maybe even via Port 00h.R itself).

NMI
The NMI source is unknown. Maybe Vblank/Vsync, maybe from SNES or OSD, or some other timer signal.

Game/Demo-Mode Detection
The original NSS games seem to be unable to detect if a coin is inserted (ie. if they should enter game or demo mode). However, it's possible to do that kind of detection:
Joypad Disable does work much like disconnecting the joypad, so one can check the 17th joypad bit to check if the joypad is connected/enabled (aka if money is inserted). The Magic Floor game is using that trick to switch between game and demo mode (this has been tested by DogP and works on real hardware, ie. the NSS does really disable the whole joypad bitstream, unlike the PC10 which seems to disable only certain buttons).

003- NSS I/O Ports - Button Inputs and Coin Control Port 00h.R - Joypad Buttons (IC46/74LS540)

7 SNES Watchdog (0=SNES did read Joypads, 1=Didn't do so) (ack via 07h.W) 6 Vsync (from OSD or SNES ?) (0=Vsync, 1=No) (zero for ca. 3 scanlines) 5 Button "Joypad Button B?" (0=Released, 1=Pressed) 4 Button "Joypad Button A" (0=Released, 1=Pressed) 3 Button "Joypad Down" (0=Released, 1=Pressed) 2 Button "Joypad Up" (0=Released, 1=Pressed) 1 Button "Joypad Left" (0=Released, 1=Pressed) 0 Button "Joypad Right" (0=Released, 1=Pressed)

Port 01h.R - Front-Panel Buttons & Game Over Flag (IC38/74LS540)

7 From SNES Port 4016h.W.Bit2 (0=Game Over Flag, 1=Normal) (Inverted!) 6 Button "Restart" (0=Released, 1=Pressed) ;-also resets SNES? 5 Button "Page Up" (0=Released, 1=Pressed) 4 Button "Page Down" (0=Released, 1=Pressed) 3 Button "Instructions" (0=Released, 1=Pressed) 2 Button "Game 3" (0=Released, 1=Pressed) ;\if present (single 1 Button "Game 2" (0=Released, 1=Pressed) ; cartridge mode does 0 Button "Game 1" (0=Released, 1=Pressed) ;/work without them)

Port 02h.R - Coin and Service Buttons Inputs (IC32/74LS540)

7-3 External 5bit input (usually CN5 isn't connected: always 0=High) 2 Service Button (1=Pressed: Add Credit; with INST button: Config) 1 Coin Input 2 (1=Coin inserted in coin-slot 2) 0 Coin Input 1 (1=Coin inserted in coin-slot 1)

Port 84h.W - Coin Counter Outputs (IC25/74HC161)

7-4 Unknown/unused (should be always 0) (probably not connected anywhere) 3-2 Unknown/unused (should be always 0) (probably wired to 74HC161) 1 Coin Counter 2 (0=No change, 1=Increment external counter) 0 Coin Counter 1 (0=No change, 1=Increment external counter)

Accessed only as "Port 84h". To increase a counter, the bit should be set for around 4 frames, and cleared for at least 3 frames (before sending a second pulse).

004- NSS I/O Ports - RTC and OSD Real-Time Clock (RTC) and On-Screen Display (OSD) Registers

Port 03h.R - Real-Time Clock (RTC) Input (IC31/74HC367)

7-1 Unknown/unused (seems to be always 7Eh, ie. all seven bits set) 0 RTC Data In (0=Low=Zero, 1=High=One)

Port 02h/82h/72h/EAh.W - RTC and OSD (IC45/74HC377)

7 OSD Clock ? (usually same as Bit6) ;\Chip Select when Bit6=Bit7 ? 6 OSD Clock ? (usually same as Bit7) ;/ 5 OSD Data Out (0=Low=Zero, 1=High=One) 4 OSD Special (?) ... or just /CS ? (or software index DC3F/DD3F?) 3 RTC /CLK (0=Low=Clock, 1=High=Idle) ;S-3520 2 RTC Data Out (0=Low=Zero, 1=High=One) 1 RTC Direction (0=Low=Write, 1=High=Read) 0 RTC /CS (0=Low/Select, 1=High/No)

RTC is accessed via "Port 82h", OSD via "Port 02h/72h/EAh". For OSD access, the BIOS toggles a LOT of data (and address) lines; not quite clear which of those lines are OSD CLK and OSD Chip Select.

RTC Real-Time Clock (S-3520)
The NSS-BIOS supports year 1900..2099 (century 00h=19xx, FFh=20xx is stored in RAM at 8F8Dh/978Dh/9F8Dh; in the two version "03" BIOSes). The current time is shown when pressing Restart in the Bookkeeping screen.

Seiko/Epson S-3520CF Serial 4bit Real-Time Clock (RTC)
Contains the usual Time/Date registers, plus 120bit battery-backed RAM (aka 15 bytes) (organized in 2 pages of 15 x 4bits).
This chip is used in both Nintendo Super System (NSS), and in Super Famicom Box.

Seiko/Epson S-3520CF Register Table

Index Bit3 Bit2 Bit1 Bit0 ;Expl. ___Registers in Mode 0_____________ ______________ 0 Sec3 Sec2 Sec1 Sec0 ;Seconds, Low ;\ 1 0 Sec6 Sec5 Sec4 ;Seconds, High ; 2 Min3 Min2 Min1 Min0 ;Minutes, Low ; Read/Increment-able 3 0 Min6 Min5 Min4 ;Minutes, High ; 4 Hour3 Hour2 Hour1 Hour0 ;Hours, Low ; (reading returns the 5 PM/AM 0 Hour5 Hour4 ;Hours, High ; counter value) 6 0 Week2 Week1 Week0 ;Day of Week ; 7 Day3 Day2 Day0 Day0 ;Day, Low ; (writing any dummy 8 0 0 Day5 Day4 ;Day, High ; value does increment 9 Mon3 Mon2 Mon1 Mon0 ;Month, Low ; counter value by 1) A 0 0 0 Mon4 ;Month, High ; B Year3 Year2 Year1 Year0 ;Year, Low ; C Year7 Year6 Year5 Year4 ;Year, High ;/ D TPS 30ADJ CNTR 24/12 ;Control Register ;-Read/Write-able E STA LOST 0 0 ;Status Register ;-Read only ___Registers in Mode 1_____________ ________________ 0-E x x x x ;Reserved ;-Don't use ___Registers in Mode 2_____________ ________________ 0-E SRAM SRAM SRAM SRAM ;SRAM Page 0 ;-Read/Write-able ___Registers in Mode 3_____________ ________________ 0-E SRAM SRAM SRAM SRAM ;SRAM Page 1 ;-Read/Write-able ___Mode Register (in Mode 0..3)____ ________________ F SYSR TEST Mode1 Mode0 ;Mode Register ;-Read/Write-able

Whereas, the meaning of the various bits is:

Sec Seconds (BCD, 00h..59h) Min Minutes (BCD, 00h..59h) Hour Hours (BCD, 00h..23h or 01h..12h) Day Day (BCD, 01h..31h) Month Month (BCD, 01h..12h) Year Year (BCD, 00h..99h) Week Day of Week (0..6) (SFC-Box: Unknown assignment) (NSS: 0=Sunday) PM/AM Set for PM, cleared for AM (this is done even when in 24-hour mode) 24/12 24-Hour Mode (0=12, 1=24) (Time/Date may get corrupted when changed?) TPS Select Reference Waveform for output on Pin8 (0=1024Hz, 1=1Hz) 30ADJ Set seconds to zero, and, if seconds was>=30, increase minutes CNTR Reset Counters (0=Normal, 1=Reset) SYSR Reset Counters and Control/Status/Mode Registers (0=Normal, 1=Reset) LOST Time Lost (0=Okay, 1=Lost/Battery failure) (can be reset... how?) STA Time Stable (0=Stable/Sec won't change in next 3.9ms, 1=Unstable) Mode Mode for Register 0-E (0=RTC, 1=Reserved, 2=SramPage0, 3=SramPage1)

If STA=0 then it's safe to read the time (counters won't change within next 3.9ms aka 1/256 seconds). If STA=1 then one should wait until STA=0 before reading the time (else one may miss counter-carry-outs).

Serial Access
Set /CLK and /CS to HIGH as default level. Set /WR to desired direction (before dragging /CS low). Then set /CS to LOW to invoke transfer. Then transfer index/data/garbage (usually 8 clks for WRITES, and 16 clks for READS). Then set /CS back HIGH.
Index/Data/Garbage Nibbles are 4bit each (transferred LSB first). Bits should be output (to DataIn) on falling CLK edge (note: the NSS is doing that properly, the SFC-Box actually outputs data shortly after falling CLK), and can be read (from DataOut) at-or-after raising CLK edge. The separate nibbles are:

Nibble To RTC From RTC 1st Index I Garbage (old index or so) 2nd Data I (or dummy) Garbage (data from old index or so) 3rd Index II (or dummy) Garbage (index I or so) 4th Data II (or dummy) Data I 5th Index III (or dummy) Garbage (index II or so) 6th Data III (or dummy) Data II

For Writes, one needs to send only 2 nibbles (of which, 2nd nibble is used only for Control & SRAM writes, for Counter-Increment writes it's only a dummy value).
For Reads, one needs to send/receive at least 4 nibbles (though most of them are dummies/garbage; actually used are 1st-To-RTC, and 4th-From-RTC). If desired, one can read two or more registers by reading/writing 6 or more nibbles (the NSS BIOS does so).

Pin-Outs
SNES Pinouts RTC Chips 
Sharp S-RTC Pin-Outs (used by Dai Kaiju Monogatari 2)

1-24 Unknown (should have an address decoder and 4bit data bus or so)

24pin chip. Still unknown which & how many address/data lines are connected, and if there are "specials" like /IRQs (?)

Epson/Seiko RTC-4513 Pin-Outs (for Far East of Eden Zero) (via SPC7110 chip)

1 NC 2 DATA 3 STD.P 4 NC 5 NC 6 VCC 7 NC 8 NC 9 GND 10 NC 11 NC 12 CE 13 CLK 14 NC

Seiko/Epson S-3520CF Pin-Outs (used in SFC-Box and NSS)

1 Xin 2 NC 3 Xout 4 /CLK 5 DataIn 6 /WR 7 GND 8 /TPOUT 9 DataOut 10 PDW 11 /CS 12 Capacitor 13 NC 14 VCC

Crystal = 32.768kHz (see datasheet page 13)

OSD On-Screen Display (M50458-001SP)On-Screen Display Controller M50458-001SP (Mitsubishi Microcomputers)

OSD Addresses
The OSD Address is transferred as first word (after chip select):

0000h..011Fh Character RAM (24x12 tiles, aka 288 tiles, aka 120h tiles) 0120h..0127h Configuration Registers (8 registers)

Further words are then written to the specified address (which is auto-incremented after each word).

Character Codes (for OSD Address 000h..011Fh)

0-6 Character Number (non-ASCII) 7 Unused (zero) 8-10 Text Color (on NSS: 3bit RGB) (Bit0=Red, Bit1=Green, Bit2=Blue) 11 Blinking flag (0=Normal, 1=Blink) 12 Underline flag (0=Normal, 1=Underline) 13-15 Unused (zero) (on NSS: used as hidden PROM check flags by NSS BIOS)

The M50458-001SP charset has been dumped by DogP, letters & punctuation marks are:

Character <---00h..0Fh---><---10h..1Fh---><---20h..2Fh---><---30h..3Fh---> 00h..3Fh "0123456789-:/.,'ABCDEFGHIJKLMNOPQRSTUVWXYZ[]();?| " 40h..7Fh "_abcdefghijklmnopqrstuvwxyz+*=# "

All characters are 12x18 pixels in size.

OSD M50458 Register 0 - Port Output Control

0 P0 Usage (0=Manual Control, 1=YM; Luminance) 1 P1 Usage (0=Manual Control, 1=BLNK; Blanking) 2 P2 Usage (0=Manual Control, 1=B; Blue) 3 P3 Usage (0=Manual Control, 1=G; Green) 4 P4 Usage (0=Manual Control, 1=R; Red) 5 P5 Usage (0=Manual Control, 1=CSYN; Composite Sync) 6-11 Manual P0-P5 Output Level (0=Low, 1=High) 12 Synchronize Port Output with Vsync (0=No, 1=Yes) 13-15 Unused (zero)

NSS uses values 003Fh (whatever/maybe SNES as backdrop), and 00BDh (maybe solid backdrop).

OSD M50458 Register 1 - Horizontal Display Start/Zoom

0-5 Horizontal Display Start in 4-pixel (?) units 6-7 Horizontal Character Size in Line 1 (0..3 = 1,2,3,4 pixels/dot) 8-9 Horizontal Character Size in Line 2..11 (0..3 = 1,2,3,4 pixels/dot) 10-11 Horizontal Character Size in Line 12 (0..3 = 1,2,3,4 pixels/dot) 12 PAL: Interlace Lines (0=625 Lines, 1=627 Lines) NTSC: Unused (zero) 13-15 Unused (zero)

NSS uses 0018h (normal centered display) and 011Bh (fine-adjusted position in intro screen).

OSD M50458 Register 2 - Vertical Display Start/Zoom

0-5 Vertical Display Start in 4-scanline (?) units 6-7 Vertical Character Size in Line 1 (0..3 = 1,2,3,4 pixels/dot) 8-9 Vertical Character Size in Line 2..11 (0..3 = 1,2,3,4 pixels/dot) 10-11 Vertical Character Size in Line 12 (0..3 = 1,2,3,4 pixels/dot) 12 Halftone in Superimpose Display (0=Halftone Off, Halftone On) 13-15 Unused (zero)

NSS uses 0009h (normal centered display) and 0107h (fine-adjusted position in intro screen).

OSD M50458 Register 3 - Character Size

0-4 Vertical Scroll Dot Offset (within char) (0..17) (18..31=Reserved) 5-6 Vertical Space between Line 1 and 2 (0..3 = 0,18,36,54 scanlines) 7 Control RS,CB Terminals (0=Both Off, 1=Both On) 8-11 Vertical Scroll Char Offset (0=No Scroll, 1..11=Line 2-12, 12..15=Res.) 12 PAL: Revise 25Hz Vsync (0=No, 1=Yes/Revice) NTSC: Unused 13-15 Unused (zero)

NSS uses 0000h (normal 1x1 pix size) and 082Ah (large 2x2 pix "NINTENDO" in intro), 0y20h (in-demo: instructions with double-height headline? and y-scroll on 2nd..10th line), 0y00h (in-game: instructions without headline and fullscreen scroll).
Verical Scroll OFF: Show 12 lines
Verical Scroll ON: Show 11 lines (1st line fixed, 10 lines scrolled)
(in scroll mode only 11 lines are shown)
(allowing to update the hidden 12th line without disturbing the display)

OSD M50458 Register 4 - Display Mode

0-11 Display Mode Flags for Line 1..12 (0=Via BLK0,BLK1, 1=Via Different) 12 LINEU - Underline Display (0=Off, 1=On) "depends on above bit0-bit11" 13-15 Unused (zero)

NSS uses 0000h.

OSD M50458 Register 5 - Blinking and so on

0-1 Blink Duty (0=Off, 1=25%, 2=50%, 3=75%) (WHAT color during WHAT time?) 2 Blink Cycle (0=64 Frames, 1=32 Frames) 3 Horizontal Border Size (0..1 = 1,2 dots) 4-5 Blink/Inverse Mode (0=Cursor, 1=ReverseChr, 2=ReverseBlink, 3=AltBlink) aka EXP0,EXP1 (see details below) 6 Horizontal Display Range when all chars are in matrix-outline (0..1=?) 7 OSCIN frequency (0=4*fsec, 1=2*fsec) (for NTSC only) 8 Color Burst Width (0=Standard, 1=Altered) 9 Vsync Signal separated from Composite Sync (0=No, 1=Separated Circut) 10-12 Test Register "Exception video RAM display mode" (should be zero) 13-15 Unused (zero)

NSS uses 0240h, 0241h, 0247h.

OSD M50458 Register 6 - Raster Color

0-2 Raster Color (on NSS: 3bit RGB) (Bit0=Red, Bit1=Green, Bit2=Blue) (aka Backdrop color?) 3 Composite Signal BIAS (0=Internal BIAS Off, 1=Internal BIAS On) 4-6 Character Background Color (Bit0=Red, Bit1=Green, Bit2=Blue) 7 Blanking Level (0=White, 1=Black) 8-10 Cursor and Underline Display Color (Bit0=Red, Bit1=Green, Bit2=Blue) 11 Cursor/Underline Color for Dot 1 (0=From VRAM, 1=From above bit8-10) 12 Cursor/Underline Color for Dot 18 (0=From VRAM, 1=From above bit8-10) 13-15 Unused (zero)

NSS uses 1804h, 1880h, 1882h, 1884h.

OSD M50458 Register 7 - Control Display

0 Raster (backdrop?) blanking (0=By Mode;bit2-3?, 1=Whole TV full raster) 1 Background Color Brightness for RGB (0=Normal, 1=Variable) huh? 2-3 Mode (0=Blanking OFF, 1=Chr Size, 2=Border Size, 3=Matrix-outline Size) aka special meanings in conjunction with register 4 (?) 4 Mode (0=External Sync, 1=Internal Sync) 5 Erase RAM (0=No, 1=Erase RAM) (=clear screen?) 6 Display Output Enable for Composite Signal (0=Off, 1=On) 7 Display Output Enable for RGB Signal (0=Off, 1=On) 8 Stop OSCIN/OSCOUT (0=Oscillate, 1=Stop) (for sync signals) 9 Stop OSC1/OSC2 (0=Oscillate, 1=Stop) (for display) 10 Exchange External C by Internal C in Y-C Mode (0=Normal, 1=Exchange) 11 Video Signal (0=Composite, 1=Y-C output) 12 Interlace Enable (0=Enable, 1=Disable) (only in Internal Sync mode) 13-15 Unused (zero)

NSS uses 1289h, 12A9h and 12B9h.

NSS OSD Dotclock
The OSD chip is having an unknown dotclock (somewhat higher than the SNES dotclock: 12 pixels on OSD are having roughly the same width as 8 pixels on SNES).

Blink/Underline

  <Register> <VramAttr> Shape
  EXP1 EXP0  EXP BLINK
  x    x     0   0      " A "             Normal
  x    x     0   1      " A " <--> "   "  Character is blinking
  0    0     1   0      "_A_"             Underlined
  0    0     1   1      "_A_" <--> " A "  Underline is blinking
  0    1     1   0      "[A]"             Inverted Character
  0    1     1   1      "[A]" <--> " A "  Inversion is blinking
  1    0     1   0      "[A]"             Inverted Character
  1    0     1   1      "[A]" <--> " A "  Inversion is blinking
  1    1     1   0      "   " <--> " A "  Character is blinking, duty swapped
  1    1     1   1      " A " <--> "_ _"  Character and Underline alternating

005- NSS I/O Ports - EEPROM and PROMMemory A000h.R - EEPROM Input

7 EEPROM Data In (0=Low=Zero, 1=High=One) 6 EEPROM Ready (0=Low=Busy, 1=High=Ready) 5-0 Unknown/unused

Memory E000h.W - EEPROM Output

7 Unknown/set (should be always 1) 6-5 Unknown/unused (should be always 0) 4 EEPROM Clock (0=Low=Clock, 1=High=Idle) ;(Data In/Out must be stable 3 EEPROM Data Out (0=Low=Zero, 1=High=One) ;on raising CLK edge) 2-1 Unknown/unused (should be always 0) ;(and updated on falling edge) 0 EEPROM Select (0=High=No, 1=Low=Select)

Note
E000h (W) and Exxxh (W) are probably mirrors of each other. If so, some care should be taken not to conflict PROM and EEPROM accesses.

Memory Exxxh.R.W.EXEC - Ricoh RP5H01 serial 72bit PROM (Decryption Key)
Data Write:

7-5 Unknown/unused 4 PROM Test Mode (0=Low=6bit Address, 1=High=7bit Address) 3 PROM Clock (0=Low, 1=High) ;increment address on 1-to-0 transition 2-1 Unknown/unused 0 PROM Address Reset (0=High=Reset Address to zero, 1=Low=No Change)

Data Read and Opcode Fetch:

7-5 Always set (MSBs of RST Opcode) 4 PROM Counter Out (0=High=One, 1=Low=Zero) ;PROM Address Bit5 3 PROM Data Out (0=High=One, 1=Low=Zero) 2-0 Always set (LSBs of RST Opcode)

The BIOS accesses the PROM in two places:

1st PROM check: Accessed via E37Fh, this part decrypts the 32h-byte area. the first data bit is read at a time when PROM reset is still high, and reset is then released after reading that data bit. At this point, there's a critical glitch: If the data bit was 1=Low, then the decryption code chooses to issue a 1-to-0 CLK transition at SAME time as when releasing reset - the PROM must ignore this CLK edge (otherwise half of the games won't work). 2nd PROM check: Accessed via EB27h, this part decrypts the double-encrypted title (from within the 32h-byte area) and displays on the OSD layer, alongsides it does verify a checksum at DC3Fh. Note: The program code hides in the OSD write string function, and gets executed when passing invalid VRAM addresses to it; this is usually done via Token 06h. This is initially done shortly after the 1st PROM check (at that point just for testing DC3Fh, with "invisible" black-on-black color attributes).

And, there are two more (unused/bugged) places:

3rd PROM check: Accessed via FB37h, this part is similar to 2nd PROM check, but sends garbage to OSD screen, and is just meant to verify checksum at DD3Fh. However, this part seems to be bugged (passing FB37h to the RST handler will hang the BIOS). The stuff would be invoked via Token 4Eh, but (fortunately) the BIOS is never doing that. 4th PROM check: Accessed via ExExh, this part is comparing the 1st eight bytes of the PROM with a slightly encrypted copy in INST ROM. However, in F-Zero, the required pointer at [2Eh-2Fh] in the 32h-byte area is misaligned, thus causing the check to fail. The stuff would be invoked from inside of NMI handler (when [80ECh] nonzero), but (fortunately) the BIOS is never doing that.

Note: All (used) PROM reading functions use RST vectors which are executing Z80 code in INST ROM. Accordingly, the code in INST ROM can be programmed so that it works with PROM-less cartridges.

PROM Dumps
Theoretically, dumping serial PROMs is ways easier than dumping parallel ROMs/EPROMs - but, as by now, nobody does ever seem to have done this. Anyways, with a brute-force program, it's possible to find matching PROM values for decrypting known title strings.

Title PROM content ActRaiser B9,4B,F5,72,E4,9E,25,FF,F2,F2,00,00,F2,F2,00,00 AMAZING TENNIS 2D,EB,21,3B,9A,81,86,93,57,57,00,00,57,57,00,00 F-ZERO 49,63,FA,03,B5,DF,F6,17,B7,B7,00,00,B7,B7,00,00 LETHAL WEAPON 7F,9B,42,99,D4,C2,A9,0A,CB,CB,00,00,CB,CB,00,00 NCAA Basketball DB,35,54,07,A0,EF,A2,72,F8,F8,00,00,F8,F8,00,00 New Game 1 [Contra 3] 3A,BC,E6,47,10,DD,45,AF,FC,FC,00,00,FC,FC,00,00 ROBOCOP 3 6A,06,DC,99,5F,3A,5C,D1,5D,5D,00,00,5D,5D,00,00 Super Mario World AE,D4,A8,1C,EC,DA,8D,EA,7D,7D,00,00,7D,7D,00,00 SUPER SOCCER 6C,57,7E,3C,8F,1F,AB,F2,3D,3D,00,00,3D,3D,00,00 Super Tennis 86,B7,8E,BD,74,A3,6E,56,9F,9F,00,00,9F,9F,00,00 The Addams Family C1,70,F2,7F,3A,EC,D3,02,67,67,00,00,67,67,00,00 The Irem Skins Game D7,3F,FE,6A,B7,3A,18,AA,D6,D6,00,00,D6,D6,00,00

Mitsubishi M6M80011 64x16 Serial EEPROM Protocol
All values transferred LSB first.

Write Enable: Send C5h,xxh Write Disable: Send 05h,xxh Write Word: Send 25h,addr, Send lsb,msb Read Word: Send 15h,addr, Read lsb,msb Read Status: Send 95h,mode, Read stat... (mode: 0=Busy, 1=WriteEnable, 2=ECC Flag) (stat: endless repeated bits, 0=Busy/WriteEnable/ECC_Correct) ( 1=Ready/WriteDisable/ECC_Incorrect)

M6M80011 Pin-Out (2x4pin version)

1=/CS, 2=/CLK, 3=DTA.IN, 4=DTA.OUT, 5=GND, 6=RESET, 7=RDY/BUSY, 8=VCC

NSS EEPROM Format (Coinage Settings)
00h-3Bh Fifteen 4-byte chunks (unused entry when 1st byte = 00h) Byte0: Upper Nibble: Checksum (all other 7 nibbles added together) Byte0: Lower Nibble: Price (Number of credits for this game, 1..9) Byte1: GameID Byte2: Time Minutes (BCD) (time limit per game) Byte3: Time Seconds (BCD) (time limit per game) 3Ch Right Coinage and Unused (bit7-4=Unused, but must be 1..9) 3Dh Left Coinage and Flags (bit7=Music, bit6=Freeplay, bit5-4=Unused) 3Eh-3Fh Checksum (all bytes at [00h..3Dh] added together) 40h-7Fh Backup Copy of 00h..3Fh

006- NSS BIOS and INST ROM MapsNSS BIOS and INST ROM Maps
NSS BIOS ROM (32K mapped to 0000h-7FFFh)

0000h Reset Vector 0008h RST Handlers (internally used by PROM checks) 0066h NMI Handler (unknown source, probably Vblank or Vsync or so) 3FFDh Hardcoded Token Address (used by F-Zero INST ROM) 5F30h Hardcoded Return-Address from 2nd PROM check in INST ROM

NSS INST ROM (8K mapped to C000h-DFFFh)

[C034h]+00h..31h Encrypted Data (to be decrypted via PROM data) [C034h]+32h..33h Chksum on above 32h bytes (all BYTEs added together) [C67Fh]+C600h RST 38h for 1st PROM check ;\ [C67Fh]*100h+7Fh RST 28h for 1st PROM check ; for decrypting the [C77Fh]+C700h RST 20h for 1st PROM check ; 32h-byte area [C77Fh]*100h+7Fh RST 30h for 1st PROM check ;/ [D627h]+D600h RST 38h for 2nd PROM check ;\for decrypting the [D627h]*100h+27h RST 28h for 2nd PROM check ; 21-byte title (and [D727h]+D700h RST 20h for 2nd PROM check ; verifying [DC3Fh]) [D727h]*100h+27h RST 30h for 2nd PROM check ;/ [(where are?)] RST's for 3rd PROM check ;-this part looks bugged [DC15h+00h..29h] Spaces,FFh,"-credit play" (with underline attr) (for Menu) [DC3Fh] 8bit chksum for 2nd PROM security check [DD3Fh] 8bit chksum for 3rd PROM security check [DEF1h..DEFFh] Title (for Bookkeeping) (in 8bit OSD characters) [DF00h..DF02h] Token Entrypoint 1 (Goto token) [DF05h..DF07h] Token Entrypoint 2 (Goto token) (overlaps below DF06h!) [[DF06h]+6] Title Xloc+Odd MSBs (for title-centering via token 66h) [NNNNh] Further locations accessed via pointers in 32h-byte area [C032h] 16bit Ptr to inst.chksum.lsb ;\all WORDs at C000..DFFF [DFFEh] 16bit Ptr to inst.chksum.msb ;/added together

32h-Byte Area at [C034h]+00h..31h (encrypted via PROM data)

00h Flags Bit0 Player 2 Controls (0=CN4 Connector, 1=Normal/Joypad 2) Bit1 Unused (should be 0) Bit2 Unused (should be 0) Bit3 Continue Type (0=Normal/Resume Game, 1=Reset Game) Bit4 Continue (1=Prompt "Insert Coin to Continue" in Skill Mode) Bit5 Used entry (must be 1) (otherwise treated as empty slot) Bit6 Checksum Type ([2Ah,2Bh] and num "0" bits in chk[2Eh-2Fh]) Bit7 Skill Mode (0=Time-Limit Mode, 1=Skill Mode) 01h GameID (must be a unique value; BIOS rejects carts with same IDs) 02h-16h Title (21 OSD chars) (needs second PROM decryption pass) 17h-18h Attraction/Demo Time (in "NMI" units) ("You Are Now Viewing...") 19h-1Ah VRAM Addr for Inserted Credits string (during game play) 1Bh-1Ch Ptr to List of Encrypted Instruction Text Lines (len byte, followed by len+1 pointers to 24-word text strings) 1Dh Default Price (number of credits per game) (LSB must be 01h..09h) 1Eh Time Minutes (BCD) ;\(TIME mode: MUST be 01:00 .. 30:00 and LSB 1Fh Time Seconds (BCD) ;/MUST be 0 or 5) (In SKILL mode: [1Eh]=0Dh, some Continue delay used when Flags.4=1) 20h-21h VRAM Addr for Remaining Time value (unused in Skill Mode) 22h SNES Watchdog (SNES must read joypads every N frames; 00h=Disable) 23h ??? Byte... (jump enable for token 60h) (allow money-back?) 24h ???Byte, alternate for [25h]? 25h ???Byte, time-limit related; combined with [1Eh..1Fh,26h..27h]? 26h-27h ???Word (unused for GameID 00-02; these use 00C0h/0140h) 28h-29h Unused (0000h) 2Ah-2Bh Checksum adjust (optional XOR value for [30h-31h], when Flags.6=1) 2Ch-2Dh Encrypted.ptr to 4th check xfer.order.XOR.byte (eg.byte 07h=reverse) 2Eh-2Fh Encrypted.ptr to 4th check 8-byte key (sometimes depends [01h]) 30h-31h Checksum accross [00h..2Fh], eventually XORed with [2Ah]:[2Bh]

Note: After decryption, the above 32h-bytes are stored at 8s00h..8s31h (with s=0..2 for slot 1-3).
Note: Instructions can be viewed by pressing Instructions Button, either during game, or in demo mode.

Skill Mode Notes
There are some variants (unknown how exactly to select which variant):

Game RESTARTS after Game Over (if one still has credits) Game CONTINUES after Game Over (if one still has credits)

And, if one does NOT have credits remaining:

Game PROMPTS insert coin to CONTINUE (eg. ActRaiser) Game ABORTS and goes to Game Menu

And, for supporting Skill Mode, the DF00h function must contain a Poke(8060h,00h) token.

GameID Notes
Known values used by original games are 00h..09h, FDh, and FFh. The homebrew Magic Floor game is using ID 3Fh. The no$sns/a22i tool assigns IDs 40h..BFh based on the game Title checksum (that assignment does more or less reduce risk that different homebrew games could conflict with each other).

Tools
The a22i assembler (in no$sns debugger, v1.3 and up) allows to create INST ROM files with title, instructions, checksums, time/skill settings, and special PROM-less RST handlers. For details see the "magicnss.a22" sample source code in the "magicsns.zip" package.

007- NSS Interpreter TokensTokens

00h Reboot_Bios() 02h Osd_Wrstr_Direct(Len8,VramAddr16,Data16[Len], ... ,FFh,Sleep0) 04h Osd_Wrstr_Encrypted_Txt_Line(Yloc*12,Sleep0) 06h Osd_Wrstr_Prom_Title_Slot_80C0h(Len8-1,VramAddr+2000h*N,Sleep0) ? 08h Osd_Wrstr_Prom_Title(Slot+80h,Len8-1,VramAddr+2000h*N,Sleep0) ? 0Ah Port_00h_W_Set_Bits(OrValue) 0Ch Port_01h_W_Set_Bits(OrValue) 0Eh Port_03h_W_Set_Bits(OrValue) 10h Port_00h_W_Mask_Bits(AndValue) 12h Port_01h_W_Mask_Bits(AndValue) 14h Port_03h_W_Mask_Bits(AndValue) 16h Set_80C2h_To_Immediate(Imm8) 18h Set_80C3h_To_Immediate(Imm8) 1Ah Set_80C4h_To_Immediate(Imm8) 1Ch Set_80C5h_To_Immediate(Imm8) 1Eh Compare_And_Goto_If_Equal(Addr16,Imm8,Target) ;\ 20h Compare_And_Goto_If_Not_Equal(Addr16,Imm8,Target) ; unsigned 22h Compare_And_Goto_If_Below_or_Equal(Addr16,Imm8,Target) ; cmp [addr],imm 24h Compare_And_Goto_If_Above(Addr16,Imm8,Target) ;/ 26h Decrement_And_Goto_If_Nonzero(Addr16,Target) 28h Poke_Immediate(Addr16,Imm8) 2Ah Sleep_Long(Sleep16) 2Ch Disable_Interpreter_and_Reset_Gosub_Stack() 2Eh Osd_Display_Num_Credit_Play(Slot*4,VramAddr16,Sleep0) 30h Test_And_Goto_If_Nonzero(Addr16,Imm8,Target) 32h Test_And_Goto_If_Zero(Addr16,Imm8,Target) 34h Osd_Wrstr_Indirect(Addr16,Sleep0) 36h Gosub_To_Subroutine(Target) ;\max 3 nesting levels 38h Return_From_Subroutine() ;/ 3Ah Goto(Target) 3Ch _xxx() ... init some values 3Eh _xxx() ... init more, based on inst rom 40h Wait_Vblank() ;or so (waits for Port[00h].bit6) 42h Osd_Wrstr_Indexed(index8,Sleep0) 44h Reload_Attraction_Timer() 46h _xxx() ... advance to next instruction page ... or so 48h Handle_PageUpDown_For_Multipage_Instructions() 4Ah Reload_SNES_Watchdog() 4Ch Decrease_SNES_Watchdog_and_Goto_if_Expired(Target) 4Eh _xxx_osd_SPECIAL...(Slot+80h,Len8-1,VramAddr+2000h*N,Sleep0) ? bugged? 50h _copy_cart_flag_bit0_to_port_01_w_bit4() ... joypad2 vs CN4 52h Map_Slot_80C0h() 54h Osd_Wrstr_Indirect_Encrypted(Addr16,Sleep0)

Below exist in BIOS version "03" only:

56h Osd_Wrstr_Num_Credit_Play(VramAddr16,Sleep0) 58h Map_Slot_804Ch() 5Ah _xxx() ;two lines: SubtractVramAddrBy1Ah_and_Strip_Underline ? 5Ch Osd_Wrstr_Prom_Title_Slot_804Ch_unless_Slot1_Empty(Len8,VramAddr,Sleep0) 5Eh Copy_8s19h_To_81E9h() ;=VRAM Addr for Credits String 60h Goto_If_8s23h_Nonzero(Target) 62h _xxx(Target) ;load timer from 8s24h or 8s25h goto if zero 64h Goto_If_GameID_is_00h_or_01h_or_02h(Target) 66h Create_Centered_Osd_Wrstr_Title_Function_at_84C0h(yloc*24) 68h _xxx() ;... 8s25h, 8s26h, and MM:SS time-limit related ?

And, some general token values:

56h..7Eh Unused_Lockup() ;unused version "02" tokens ;\jump to an 6Ah..7Eh Unused_Lockup() ;unused version "03" tokens ;/endless loop 01h..7Fh Crash() ;odd token numbers jump to garbage addresses 80h..FFh Sleep_Short(Sleep7) ;00h..7Fh (in LSBs of Token)

Sleep0 is an optional 00h-byte that can be appended after the Wrstr(Params) commands. If the 00h-byte is NOT there, then a Sleep occurs for 1 frame. If the 00h-byte is there, then token execution continues (after skipping the 00h) without Sleeping.

Note
INST ROM contains two interpreter functions (invoked via Gosub DF00h and Gosub DF05h).

DF00h - Custom code (quite simple in F-Zero, very bizarre in ActRaiser) DF05h - Display centered & underlined Title in first line

Available stack depth is unknown (at least one stack level is used, so there are max two free levels, or maybe less) (the DF00h function CAN use at least one stack level).
The DF05h function is used for displaying the instructions headline (when viewing instructions in Demo mode). The purpose/usage of the DF00h function is unknown; essentially, everything works fine even if it just contains a Return token; for Skill Mode games it also seems to require a Poke(8060h,00h) token.

008- NSS ControlsFront Panel

.---------------------------------------------------------------------------. | _________________ _________________ _________________ | | | | | | | | | | | game 1 logo | | game 2 logo | | game 3 logo | | | | | | | | | | | | | | | | | | | |_________________| |_________________| |_________________| | | ( ) ( ) ( ) | | GAME 1 GAME 2 GAME 3 | |---------------------------------------------------------------------------| | PAGE PAGE RESTART | | INSTRUCTIONS UP DOWN GAME | | __ __ ( ) ( ) ( ) __ ( ) __ | | / '''---...__ __...---''' \ / '''---...__ __...---''' \ | || _ ''' | | _ ''' || || _| |_ ( ) | | _| |_ ( ) || |' |_ _| ( ) ( ) ' ' |_ _| ( ) ( ) '| | | |_| ( ) ( ) ( ) | | |_| ( ) ( ) ( ) | | | '...........................' '...........................' | \ / '-----------------------------------------------------------------------'

Unlike normal cabinets, the NSS doesn't have arcade joysticks. Instead, there are two huge SNES joypads firmly mounted on the front-plate (about twice as big as normal SNES joypads). L/R symbols are depicted on the joypad "surface" (although the actual L/R buttons seem to be on "rear" shoulders as usually).

GAME 1..3 and INSTRUCTION buttons are fitted with LEDs
For single-cartridge use, there may be a different front-panel without GAME 1-3 buttons (there is no Game Menu, and the Config screen is joypad controlled in single-cart mode).

Plus, TEST Button, SERVICE Button
Plus, TWO Coin input/switches
Plus, DIP-Switches in Cartridge

009- NSS Games, BIOSes and ROM-ImagesNintendo Super System BIOS (Nintendo)
The BIOS is stored in a 32Kx8 EPROM on the mainboard. There are at least three BIOS versions (the version number, "02" for oldest version, and "03" for the two newer versions, is shown at the top of the Selftest result screen). The "02" version is incompatible with newer games (works only with the 3 oldest titles).

NSS-v02.bin aka NSS-C.DAT ;CRC32: A8E202B3 (version "02" oldest) NSS-v03a.bin aka NSS-IC14.02 ;CRC32: E06CB58F (version "03" older) NSS-v03b.bin aka NSS-V3.ROM ;CRC32: AC385B53 (version "03" newer/patch)

NSS Cartridge ROM-Images
ROM-Images should consist of following components in following order:

1. PRG-ROM (the SNES game) (usually 512Kbytes or 1024Kbytes) 2. INST-ROM (the Z80 title & instructions) (32Kbytes) 3. PROM (decryption key) (16 bytes)

Note: For the Type B/C PCBs, the PROM is 16 bytes in size. The Type A PCBs seem to be somehow different - details are still unknown; the ROM-image format may need to be changed in case that those details are discovered.
The existing cartridges don't contain any coprocessors - if somebody should make such cartridges, please insert the coprocessor ROM (eg. DSP1) between PRG-ROM and INST-ROM.

NSS Games

PCB Title C Act Raiser (NSS) 1992 Enix (Two EPROMs+DIPSW) C Addams Family, The (NSS) 1992 Ocean (Two EPROMs+DIPSW) C Contra 3: The Alien Wars (NSS) 1992 Konami (Two EPROMs+SRAM+DIPSW) C David Crane's Amazing Tennis (NSS) 1992 Abs.Ent.Inc. (Two EPROMs+DIPSW) B F-Zero (NSS) 1991 Nintendo (ROM+SRAM) C Irem Skins Game, The (NSS) 1992 Irem (Two EPROMs+DIPSW) C Lethal Weapon (NSS) 1992 Ocean (Two EPROMs+DIPSW) - Magic Floor (NSS) 2012 nocash (EPROM+DIPSW, works without PROM) C NCAA Basketball (NSS) 1992 Sculptured Software Inc. (Two EPROMs+DIPSW) C Robocop 3 (NSS) 1992 Ocean (Two EPROMs+DIPSW) A Super Mario World (NSS) 1991 Nintendo (ROM) A Super Soccer (NSS) 1992 Human Inc. (EPROM) A Super Tennis (NSS) 1991 Nintendo (ROM)

Additionally, Ocean has announced Push-Over (unknown if that was ever released). And, there seems to have been a Super Copa cartridge in Mexico. And, there is somebody owning a NHL Stanley Cup prototype cartridge.
Contra 3 also appears to exist as prototype only (its INST-ROM title/instructions are just saying "New Game 1" and "To be announced").

010- NSS Component ListsCartridge PCB "NSS-01-ROM-A" (1991 Nintendo)

IC1 32pin PRG ROM (LH534J ROM or TC574000 EPROM) (512Kx8 LoROM) IC2 16pin 74HC367 (2bit + 4bit drivers) (unknown purpose... for PROM?) IC3 28pin INST-ROM (27C256) (32Kx8 EPROM) IC4 8pin Key-Chip (RP5H01 serial 72bit PROM) CL/SL 2pin Jumpers (see notes) CN? 100pin Cartridge connector (2x50pin)

Used by Super Mario World (ROM), Super Tennis (ROM), and Super Soccer (EPROM).
For ROM: Short CL1-CL5, Open SL1-SL5. For EPROM: Short SL1-SL5, Open CL1-CL5.

Cartridge PCB "NSS-01-ROM-B" (1991 Nintendo)

IC1 28pin SRAM (LH5168FB-10L) IC2 32pin PRG ROM (LH534J ROM) (512Kx8 LoROM) IC3 16pin 74LS139 (demultiplexer) (for ROM vs SRAM mapping) IC4 16pin 74HC367 (2bit + 4bit drivers) (unknown purpose... for PROM?) IC5 14pin 74HC27 (3x3 NOR) (for SW1) (not installed on the F-Zero board) IC6 14pin 74HC10 (3x3 NAND)(for SW1) (not installed on the F-Zero board) IC7 20pin 74HC540 (inv.drv)(for SW1) (not installed on the F-Zero board) IC8 28pin INST-ROM (27C256) (32Kx8 EPROM) IC9 8pin Key-Chip (RP5H01 serial 72bit PROM) SW1 16pin DIP-Switch (8 switches) (not installed on the F-Zero board) AR1 9pin Resistor network (for SW1) (not installed on the F-Zero board) BAT1 2pin Battery (CR2032 3V coin) (with socket) CL/SL 2pin Jumpers (see notes) CN? 100pin Cartridge connector (2x50pin)

Used only by F-Zero. For that game: Short CL1-CL7, Open SL1-SL7. Other settings might allow to use EPROM instead ROM, or to change ROM/SRAM capacity.

Cartridge PCB "NSS-01-ROM-C" (1992 Nintendo)
Judging from low-res photos, the PCB is basically same as NSS-01-ROM-B, but with two PRG ROM chips (for double capactity). Exact components are unknown, except for a few ones:

IC1 28pin SRAM (6116, 2Kx8) (DIP24 in 28pin socket?) (Contra III only) IC2 32pin PRG-ROM-1 (TC574000 EPROM) (512Kx8 LoROM, upper half) IC3 32pin PRG-ROM-0 (TC574000 EPROM) (512Kx8 LoROM, lower half) IC4 16pin 74LS139 (demultiplexer) (for ROM vs SRAM mapping) IC5 16pin 74HC367 (2bit + 4bit drivers) (unknown purpose... for PROM?) IC6 14pin 74HC27 (3x3 NOR) (for SW1) IC7 14pin 74HC10 (3x3 NAND)(for SW1) IC8 28pin INST ROM (27C256) (32Kx8 EPROM) IC9 20pin 74HC540 (inv.drv)(for SW1) IC10 8pin Key-Chip (RP5H01 serial 72bit PROM) SW1? 16pin DIP-Switch (8 switches) (installed) AR1 9pin Resistor network for SW1 (installed) BAT1? 2pin Battery (CR2032 3V coin) (with socket) (Contra III only) CL/SL 2pin Jumpers (see notes) CN? 100pin Cartridge connector (2x50pin)

Used by ActRaiser, Addams Family, Amazing Tennis, Irem Skins Game, Lethal Weapon, NCAA Basketball, Robocop 3 (all without SRAM), and, by Contra III (with SRAM). Default (for all those games) is reportedly: Short CL2-CL6,CL12-CL13,CL15,CL17-CL19, Open SL1,SL7-SL12,SL14,SL16,SL20-SL22.
DIP Switches are usually/always installed. Battery/SRAM is usually NOT installed, except on the Contra III cartridge (which has "NSS-01-ROM-C" PCB rebadged as "NSS-X1-ROM-C" with a sticker).

Mainboard NSS-01-CPU MADE IN JAPAN (C) 1991 Nintendo
Below lists only the main chipset (not the logic chips; which are mostly located on the bottom side of the PCB).
Standard SNES Chipset

S-CPU 5A22-02 (QFP100) S-PPU1 5C77-01 (QFP100) S-PPU2 5C78-01 (QFP100) S-WRAM LH68120 (SOP64) 128Kx8 DRAM with sequential access feature (SNES WRAM) Fujitsu MB84256-10L 32Kx8 SRAM (SOP28) (SNES VRAM LSBs) Fujitsu MB84256-10L 32Kx8 SRAM (SOP28) (SNES VRAM MSBs)

NSS/Z80 Specific Components

Zilog Z84C0006FEC Z80 CPU, clock input 4.000MHz (QFP44) 27C256 32Kx8 EPROM "NSS-C_IC14_02" (DIP28) (Z80 BIOS) Sharp LH5168N-10L 8Kx8 SRAM (SOP28) (Z80 WRAM) Mitsubishi M50458-001SP On-Screen Display (OSD) Chip (NDIP32) Mitsubishi M6M80011 64x16 Serial EEPROM (DIP8) (Pinout: 1=CS, 2=CLK, 3=DATA IN, 4=DATA OUT, 5=VSS, 6=RESET, 7=RDY, 8=VCC) Seiko Epson S-3520 Real Time Clock (SOIC14)

Amplifiers/Converters/Battery and so

Sharp IR3P32A (chroma/luma to RGB converter... what is that for???) (NDIP30) Hitachi HA13001 Dual 5.5W Power Amplifier IC Matsushita AN5836 DC Volume and Tone Control IC (SIL12) Mitsumi Monolithic MM1026BF Battery Controller (SOIC8) (on PCB bottom side) 5.5V - 5.5 volt supercap

Oscillators

21.47724MHz SNES NTSC Master Clock <-- not 21.47727MHz, unlike NTSC (?) 14.31818MHz (unknown purpose, maybe for OSD chip or RGB converter or so) 4.000MHz for Z80 CPU 32.678kHz for RTC <unknown clock source> for OSD Dotclock

Connectors

CN1 - 2x28 pin connector - "JAMMA" - Audio/Video/Supply/Coin/Joypad CN2 - 10 pin connector - 10P Connector (Extra Joypad Buttons) CN3 - 13 pin connector - 13P Connector (Front Panel LEDs/Buttons) CN4 - 8 pin connector - alternate player 2 controller (eg. lightgun) (unused) CN5 - 7 pin connector - external 5bit input (Port 02h.R.bit3-7) (unused) CN6 - 24 pin connector (to APU daughterboard) CN11/12/13 - 2x50 pin connectors for game cartridges

Jumpers

SL1/SL2/SL3/CL1/CL2 - Mono/stero mode (for details see PCB text layer) SL4 - Use Audio+ (pin 11 on edge connector) SL5 - Unknown purpose TB1 - Z80 Watchdog Disable

APU Daughterboard (shielded unit, plugged into CN6 on mainboard)

  Nintendo S-SMP (M) SONY (C) Nintendo '89' (QFP80) (SNES SPC700 CPU)
  Nintendo S-DSP (M) (C) SONY '89' (QFP80) (SNES sound chip)
  Toshiba TC51832FL-12 32Kx8 SRAM (SOP28) (1st half of APU RAM)
  Toshiba TC51832FL-12 32Kx8 SRAM (SOP28) (2nd half of APU RAM)
  Japan Radio Co. JRC2904 Dual Low Power Op Amp (SOIC8)
  NEC D6376 Audio 2-Channel 16-Bit D/A Converter (SOIC16)
  CN1 - 24 pin connector (to CN6 on mainboard)
  <unknown clock source> for APU (probably SNES/APU standard 24.576MHz)

011- NSS On-Screen Controller (OSD)
On-Screen Display Controller M50458-001SP (Mitsubishi Microcomputers)



OSD Addresses

The OSD Address is transferred as first word (after chip select):

0000h..011Fh Character RAM (24x12 tiles, aka 288 tiles, aka 120h tiles) 0120h..0127h Configuration Registers (8 registers)

Further words are then written to the specified address (which is auto-incremented after each word).

Character Codes (for OSD Address 000h..011Fh)

0-6 Character Number (non-ASCII) 7 Unused (zero) 8-10 Text Color (on NSS: 3bit RGB) (Bit0=Red, Bit1=Green, Bit2=Blue) 11 Blinking flag (0=Normal, 1=Blink) 12 Underline flag (0=Normal, 1=Underline) 13-15 Unused (zero) (on NSS: used as hidden PROM check flags by NSS BIOS)

The M50458-001SP charset has been dumped by DogP, letters & punctuation marks are:

Character <---00h..0Fh---><---10h..1Fh---><---20h..2Fh---><---30h..3Fh---> 00h..3Fh "0123456789-:/.,'ABCDEFGHIJKLMNOPQRSTUVWXYZ[]();?| " 40h..7Fh "_abcdefghijklmnopqrstuvwxyz+*=# "

All characters are 12x18 pixels in size.

OSD M50458 Register 0 - Port Output Control

0 P0 Usage (0=Manual Control, 1=YM; Luminance) 1 P1 Usage (0=Manual Control, 1=BLNK; Blanking) 2 P2 Usage (0=Manual Control, 1=B; Blue) 3 P3 Usage (0=Manual Control, 1=G; Green) 4 P4 Usage (0=Manual Control, 1=R; Red) 5 P5 Usage (0=Manual Control, 1=CSYN; Composite Sync) 6-11 Manual P0-P5 Output Level (0=Low, 1=High) 12 Synchronize Port Output with Vsync (0=No, 1=Yes) 13-15 Unused (zero)

NSS uses values 003Fh (whatever/maybe SNES as backdrop), and 00BDh (maybe solid backdrop).

OSD M50458 Register 1 - Horizontal Display Start/Zoom

0-5 Horizontal Display Start in 4-pixel (?) units 6-7 Horizontal Character Size in Line 1 (0..3 = 1,2,3,4 pixels/dot) 8-9 Horizontal Character Size in Line 2..11 (0..3 = 1,2,3,4 pixels/dot) 10-11 Horizontal Character Size in Line 12 (0..3 = 1,2,3,4 pixels/dot) 12 PAL: Interlace Lines (0=625 Lines, 1=627 Lines) NTSC: Unused (zero) 13-15 Unused (zero)

NSS uses 0018h (normal centered display) and 011Bh (fine-adjusted position in intro screen).

OSD M50458 Register 2 - Vertical Display Start/Zoom

0-5 Vertical Display Start in 4-scanline (?) units 6-7 Vertical Character Size in Line 1 (0..3 = 1,2,3,4 pixels/dot) 8-9 Vertical Character Size in Line 2..11 (0..3 = 1,2,3,4 pixels/dot) 10-11 Vertical Character Size in Line 12 (0..3 = 1,2,3,4 pixels/dot) 12 Halftone in Superimpose Display (0=Halftone Off, Halftone On) 13-15 Unused (zero)

NSS uses 0009h (normal centered display) and 0107h (fine-adjusted position in intro screen).

OSD M50458 Register 3 - Character Size

0-4 Vertical Scroll Dot Offset (within char) (0..17) (18..31=Reserved) 5-6 Vertical Space between Line 1 and 2 (0..3 = 0,18,36,54 scanlines) 7 Control RS,CB Terminals (0=Both Off, 1=Both On) 8-11 Vertical Scroll Char Offset (0=No Scroll, 1..11=Line 2-12, 12..15=Res.) 12 PAL: Revise 25Hz Vsync (0=No, 1=Yes/Revice) NTSC: Unused 13-15 Unused (zero)

NSS uses 0000h (normal 1x1 pix size) and 082Ah (large 2x2 pix "NINTENDO" in intro), 0y20h (in-demo: instructions with double-height headline? and y-scroll on 2nd..10th line), 0y00h (in-game: instructions without headline and fullscreen scroll).
Verical Scroll OFF: Show 12 lines
Verical Scroll ON: Show 11 lines (1st line fixed, 10 lines scrolled)
(in scroll mode only 11 lines are shown)
(allowing to update the hidden 12th line without disturbing the display)

OSD M50458 Register 4 - Display Mode

0-11 Display Mode Flags for Line 1..12 (0=Via BLK0,BLK1, 1=Via Different) 12 LINEU - Underline Display (0=Off, 1=On) "depends on above bit0-bit11" 13-15 Unused (zero)

NSS uses 0000h.

OSD M50458 Register 5 - Blinking and so on

0-1 Blink Duty (0=Off, 1=25%, 2=50%, 3=75%) (WHAT color during WHAT time?) 2 Blink Cycle (0=64 Frames, 1=32 Frames) 3 Horizontal Border Size (0..1 = 1,2 dots) 4-5 Blink/Inverse Mode (0=Cursor, 1=ReverseChr, 2=ReverseBlink, 3=AltBlink) aka EXP0,EXP1 (see details below) 6 Horizontal Display Range when all chars are in matrix-outline (0..1=?) 7 OSCIN frequency (0=4*fsec, 1=2*fsec) (for NTSC only) 8 Color Burst Width (0=Standard, 1=Altered) 9 Vsync Signal separated from Composite Sync (0=No, 1=Separated Circut) 10-12 Test Register "Exception video RAM display mode" (should be zero) 13-15 Unused (zero)

NSS uses 0240h, 0241h, 0247h.

OSD M50458 Register 6 - Raster Color

0-2 Raster Color (on NSS: 3bit RGB) (Bit0=Red, Bit1=Green, Bit2=Blue) (aka Backdrop color?) 3 Composite Signal BIAS (0=Internal BIAS Off, 1=Internal BIAS On) 4-6 Character Background Color (Bit0=Red, Bit1=Green, Bit2=Blue) 7 Blanking Level (0=White, 1=Black) 8-10 Cursor and Underline Display Color (Bit0=Red, Bit1=Green, Bit2=Blue) 11 Cursor/Underline Color for Dot 1 (0=From VRAM, 1=From above bit8-10) 12 Cursor/Underline Color for Dot 18 (0=From VRAM, 1=From above bit8-10) 13-15 Unused (zero)

NSS uses 1804h, 1880h, 1882h, 1884h.

OSD M50458 Register 7 - Control Display

0 Raster (backdrop?) blanking (0=By Mode;bit2-3?, 1=Whole TV full raster) 1 Background Color Brightness for RGB (0=Normal, 1=Variable) huh? 2-3 Mode (0=Blanking OFF, 1=Chr Size, 2=Border Size, 3=Matrix-outline Size) aka special meanings in conjunction with register 4 (?) 4 Mode (0=External Sync, 1=Internal Sync) 5 Erase RAM (0=No, 1=Erase RAM) (=clear screen?) 6 Display Output Enable for Composite Signal (0=Off, 1=On) 7 Display Output Enable for RGB Signal (0=Off, 1=On) 8 Stop OSCIN/OSCOUT (0=Oscillate, 1=Stop) (for sync signals) 9 Stop OSC1/OSC2 (0=Oscillate, 1=Stop) (for display) 10 Exchange External C by Internal C in Y-C Mode (0=Normal, 1=Exchange) 11 Video Signal (0=Composite, 1=Y-C output) 12 Interlace Enable (0=Enable, 1=Disable) (only in Internal Sync mode) 13-15 Unused (zero)

NSS uses 1289h, 12A9h and 12B9h.

NSS OSD Dotclock
The OSD chip is having an unknown dotclock (somewhat higher than the SNES dotclock: 12 pixels on OSD are having roughly the same width as 8 pixels on SNES).

Blink/Underline
<Register> <VramAttr> Shape EXP1 EXP0 EXP BLINK x x 0 0 " A " Normal x x 0 1 " A " <--> " " Character is blinking 0 0 1 0 "_A_" Underlined 0 0 1 1 "_A_" <--> " A " Underline is blinking 0 1 1 0 "[A]" Inverted Character 0 1 1 1 "[A]" <--> " A " Inversion is blinking 1 0 1 0 "[A]" Inverted Character 1 0 1 1 "[A]" <--> " A " Inversion is blinking 1 1 1 0 " " <--> " A " Character is blinking, duty swapped 1 1 1 1 " A " <--> "_ _" Character and Underline alternating

012- SNES Pinouts NSS Connectors
NSS - CN11/12/13 - Cartridge Slots (3 slots, 2x50pin each)

Solder side Component side A B WRAM.64 GND - 1 - VCC2 INST.28 ;\ WRAM.64 GND - 2 - VCC2 INST.28 ; PROM PROM.7-R3 PROM.RES - 3 - PROM.CLK PROM.6 ; (and SNES PROM.5-R2 PROM.TST - 4 - PROM.CNT PROM.8 ; select) /SNES_# - 5 - PROM.DTA PROM.1 ;/ INST.15 D3 - 6 - D4 INST.16 ;\ INST.13 D2 - 7 - D5 INST.17 ; INST.12 D1 - 8 - D6 INST.18 ; INST.11 D0 - 9 - D7 INST.19 ; INST.10 A0 - 10 - /CE_# INST.20 ; INST.9 A1 - 11 - A10 INST.21 ; INST ROM INST.8 A2 - 12 - /OE INST.22 ; INST.7 A3 - 13 - A11 INST.23 ; INST.6 A4 - 14 - A9 INST.24 ; INST.5 A5 - 15 - A8 INST.25 ; INST.4 A6 - 16 - A7 INST.3 ; INST.2 A12 - 17 - GND WRAM.64 ; WRAM.64 GND - 18 - VCC2 INST.28 ; WRAM.64 _______ GND - 19 - VCC2 ______ INST.28 ;/ WRAM.64 GND - 20 - VCC WRAM.1 ;\ WRAM.64 GND - 21 - VCC WRAM.1 ; WRAM.56 /PARD - 22 - /PAWR WRAM.58 ; WRAM.47 PA6 - 23 - PA7 WRAM.50 ; WRAM.45 PA4 - 24 - PA5 WRAM.46 ; WRAM.43 PA2 - 25 - PA3 WRAM.44 ; SNES Bus WRAM.53 PA0 - 26 - PA1 WRAM.54 ; (and PROM WRAM.57 /RD - 27 - /WR WRAM.59 ; select) WRAM.63 D3 - 28 - D4 WRAM.2 ;\D4..D7 in ; WRAM.62 D2 - 29 - D5 WRAM.3 ; opposite ; WRAM.61 D1 - 30 - D6 WRAM.4 ; order as ; WRAM.60 D0 - 31 - D7 WRAM.5 ;/on SNES ; CPU.46 /IRQ - 32 - /ROMSEL CPU.77 ; CPU.93 A0 - 33 - A23 CPU.17 ; CPU.94 A1 - 34 - A22 CPU.16 ; CPU.95 A2 - 35 - A21 CPU.15 ; CPU.96 A3 - 36 - A20 CPU.14 ; CPU.97 A4 - 37 - A19 CPU.13 ; CPU.98 A5 - 38 - A18 CPU.12 ; CPU.99 A6 - 39 - A17 CPU.11 ; CPU.100 A7 - 40 - A16 CPU.10 ; CPU.2 A8 - 41 - A15 CPU.9 ; CPU.3 A9 - 42 - A14 CPU.8 ; CPU.4 A10 - 43 - A13 CPU.7 ; CPU.5 A11 - 44 - A12 CPU.6 ; WRAM.7 REFRESH - 45 - /WRAMSEL WRAM.15 ; AUDIO_L - 46 - AUDIO_R ; PROM.2 PROM./CE_# - 47 - SYSCLK WRAM.6 ; CPU.48 MCK 21M - 48 - /RESET WRAM.8 ; WRAM.64 GND - 49 - VCC WRAM.1 ; WRAM.64 GND - 50 - VCC WRAM.1 ;/

The NSS motherboard uses female Matsushita AXD100271 connectors, and the NSS cartridges have male Matsushita AXD200251 connectors. Both are obsolete as of a few years ago, but they're just shrouded 0.1" headers.

RICOH RP5H01 PROM Pinout (Decryption Key PROM on NSS Cartridges)

1 DATA.OUT 2 /CE (VPP) 3 VCC 4 GND 5 TEST 6 DATA.CLK 7 RESET 8 COUNTER.OUT

NSS - CN1 - Big Edge Connector "JAMMA" - 2x28 pin

1 GND (from Power Supply) A GND (from Power Supply) 2 GND (NC) B GND (from Power Supply) 3 +5V (from Power Supply) C +5V (to joypads; and NC there) 4 +5V (from Power Supply) D +5V (from Power Supply) 5 NC (NC) E -5V (from Power Supply) 6 +12V (to Coin Lamps and Coin Counter) F +12V (from Power Supply) 7 KEY H KEY 8 Coin Counter 1 J Coin Counter 2 9 NC K NC 10 SPEAKER (Right) L SPEAKER (Left) 11 AUDIO (+) (NC) M AUDIO GND 12 VIDEO RED N VIDEO GREEN 13 VIDEO BLUE P VIDEO SYNC 14 VIDEO GND R SERVICE SW 15 TEST SW S NC 16 COIN SW 1 T COIN SW 2 17 1P START U 2P START 18 1P UP V 2P UP 19 1P DOWN W 2P DOWN 20 1P LEFT 2P LEFT 21 1P RIGHT 2P RIGHT 22 1P A 2P A 23 1P B 2P B 24 1P SELECT 2P SELECT 25 VOLUME ? (POT Center Pin) VOLUME ? (POT Outer Pin) 26 VOLUME GND (POT Outer Pin) NC 27 GND GND 28 GND GND

NSS - CN2 - 10P Connector (Extra Joypad Buttons)

1 GND 2 2P TR 3 2P TL 4 2P Y 5 2P X 6 1P TR 7 1P TL 8 1P Y 9 1P X 10 GND

NSS - CN3 - 13P Connector (Front Panel LEDs/Buttons)

1 GND (for Buttons) 2 Button Restart 3 Button Page Down 4 Button Page Up 5 Button Instructions 6 Button Game #3 7 Button Game #2 8 Button Game #1 9 LED Instructions 10 LED Game #3 11 LED Game #2 12 LED Game #1 13 +5V or so (for LEDs)

NSS - CN4

1 GND (to SNES Controller pin 7) 2 /EXT_CTRL2 (Low=External CN4 controller, High=Internal Joypad2 selected) 3 JPIO7 (to SNES Controller pin 6) ;\ 4 JPSTR (to SNES Controller pin 3) ; always connected 5 JPCLK2 (to SNES Controller pin 2) ;/ 6 4017.D1 (to SNES Controller pin 5) ;\only when CN4 selected 7 4017.D0 (to SNES Controller pin 4) ;/ 8 SNES +5V (to SNES Controller pin 1)

The external input is enabled when setting INST ROM Flags Bit0=0 (that bit is copied to Port 01h.W bit4).

NSS - CN5

1 GND 2 IC32/74LS540 pin 9 (Port 02h.R bit 7) 3 IC32/74LS540 pin 8 (Port 02h.R bit 6) 4 IC32/74LS540 pin 7 (Port 02h.R bit 5) 5 IC32/74LS540 pin 6 (Port 02h.R bit 4) 6 IC32/74LS540 pin 5 (Port 02h.R bit 3) 7 +5V

NSS Repair (Blank Screen / Washed out colors)
There seems to be a fairly common hardware problem that causes the NSS to show a picture with washed out colors or a completely blank screen; in some cases the problem appears or disappears when the unit has warmed up.
The problem is related to the power supply of the IR3P32A chip: The supply should be around 9V, and video glitches appear when it drops below 8V. For deriving the "9V", Nintendo has strapped the IR3P32A to the 12V line via a 100 ohm resistor; which is rather crude and unreliable.
As workaround one could add a second resistor in parallel with the 100 ohms (which is equally crude, though it should help temporarily), a more reliable solution should be to replace the 100 ohms by a 7809 voltage regulator (and eventually some capacitors as far as needed).
The actual reason for the problem is unknown - apparently some odd aging effect on the IR3P32A chip and/or other components connected to it. No info if the problem occurs both with original monitor and power supply as well as with third-party hardware.

NSS-to-SNES-cartridge adaptor (signal quality)
Using SNES cartridges with coprocessors (eg. DSP1 carts) on NSS requires some fine tuning:
DogP's older solution: The /RD and /WR pins seem to have high slew rates and overshoot badly (by around 3V, for just a few ns)... a regular Mario Kart cartridge works perfectly with LPFs added to those pins. The PowerPak seems to still have some issues though.
DogP's newer solution: I actually ended up just adding small resistors in series with the data bus, which helped reduce the overshoot/ringing. This also fixed the PowerPak issues.

NSS-to-SNES-cartridge adaptor (CIC)
A fully functional NSS-to-SNES-cartridge adaptor would also require a CIC chip (as a few SNES cartridges with special protections won't work if the 'console' doesn't output the correct CIC signals).
Accordingly, the adaptor would also need something that generates the 3.072MHz CIC clock signal (on a real SNES that would be 24.576MHz/8 coming from APU) (on the NSS adaptor it would require a separate oscillator, or if accuracy doesn't matter, then one might get away with 21.xxxMHz PAL/NTSC master clock divided by 7 (or dirtier: divided by 8)).
Unless there should be another way to get those protected cartridges to work (maybe by simply wiring CIC clock to VCC or GND, or by feeding it only a few dozen of CIC clks after reset, so it could initialize itself, but would never reach the point where the protection could do something harmful).

013- Z80 CPU Specifications Z80 Register Set
Register Summary

16bit Hi Lo Name/Function --------------------------------------- AF A - Accumulator & Flags BC B C BC DE D E DE HL H L HL AF' - - Second AF BC' - - Second BC DE' - - Second DE HL' - - Second HL IX IXH IXL Index register 1 IY IYH IYL Index register 2 SP - - Stack Pointer PC - - Program Counter/Pointer - I R Interrupt & Refresh

Normal 8bit and 16bit Registers
The Accumulator (A) is the allround register for 8bit operations. Registers B, C, D, E, H, L are normal 8bit registers, which can be also accessed as 16bit register pairs BC, DE, HL.
The HL register pair is used as allround register for 16bit operations. B and BC are sometimes used as counters. DE is used as DEstination pointer in block transfer commands.

Second Register Set
The Z80 includes a second register set (AF',BC',DE',HL') these registers cannot be accessed directly, but can be exchanged with the normal registers by using the EX AF,AF and EXX instructions.

Refresh Register
The lower 7 bits of the Refresh Register (R) are incremented with every instruction. Instructions with at least one prefix-byte (CB,DD,ED,FD, or DDCB,FDCB) will increment the register twice. Bit 7 can be used by programmer to store data. Permanent writing to this register will suppress memory refresh signals, causing Dynamic RAM to lose data.

Interrupt Register
The Interrupt Register (I) is used in interrupt mode 2 only (see command "im 2"). In other modes it can be used as simple 8bit data register.

IX and IY Registers
IX and IY are able to manage almost all the things that HL is able to do. When used as memory pointers they are additionally including a signed index byte (IX+d). The disadvantage is that the opcodes occupy more memory bytes, and that they are less fast than HL-instructions.

Undocumented 8bit Registers
IXH, IXL, IYH, IYL are undocumented 8bit registers which can be used to access high and low bytes of the IX and IY registers (much like H and L for HL). Even though these registers do not officially exist, they seem to be available in all Z80 CPUs, and are quite commonly used by various software.

Z80 Flags

Flag Summary
The Flags are located in the lower eight bits of the AF register pair.

Bit Name Set Clr Expl. 0 C C NC Carry Flag 1 N - - Add/Sub-Flag (BCD) 2 P/V PE PO Parity/Overflow-Flag 3 - - - Undocumented 4 H - - Half-Carry Flag (BCD) 5 - - - Undocumented 6 Z Z NZ Zero-Flag 7 S M P Sign-Flag

Carry Flag (C)
This flag signalizes if the result of an arithmetic operation exceeded the maximum range of 8 or 16 bits, ie. the flag is set if the result was less than Zero, or greater than 255 (8bit) or 65535 (16bit). After rotate/shift operations the bit that has been 'shifted out' is stored in the carry flag.

Zero Flag (Z)
Signalizes if the result of an operation has been zero (Z) or not zero (NZ). Note that the flag is set (1) if the result was zero (0).

Sign Flag (S)
Signalizes if the result of an operation is negative (M) or positive (P), the sign flag is just a copy of the most significant bit of the result.

Parity/Overflow Flag (P/V)
This flag is used as Parity Flag, or as Overflow Flag, or for other purposes, depending on the instruction.
Parity: Bit7 XOR Bit6 XOR Bit5 ... XOR Bit0 XOR 1.
8bit Overflow: Indicates if the result was greater/less than +127/-128.
HL Overflow: Indicates if the result was greater/less than +32767/-32768.
After LD A,I or LD A,R: Contains current state of IFF2.
After LDI,LDD,CPI,CPD,CPIR,CPDR: Set if BC<>0 at end of operation.

BCD Flags (H,N)
These bits are solely supposed to be used by the DAA instruction. The N flag signalizes if the previous operation has be an addition or substraction. The H flag indicates if the lower 4 bits exceeded the range from 0-0Fh. (For 16bit instructions: H indicates if the lower 12 bits exceeded the range from 0-0FFFh.)
After adding/subtracting two 8bit BCD values (0-99h) the DAA instruction can be used to convert the hexadecimal result in the A register (0-FFh) back to BCD format (0-99h). Note that DAA also requires the carry flag to be set correctly, and thus should not be used after INC A or DEC A.

Undocumented Flags (Bit 3,5)
The content of these undocumented bits is filled by garbage by all instructions that affect one or more of the normal flags (for more info read the chapter Garbage in Flag Register), the only way to read out these flags would be to copy the flags register onto the stack by using the PUSH AF instruction.
However, the existence of these bits makes the AF register a full 16bit register, so that for example the code sequence PUSH DE, POP AF, PUSH AF, POP HL would set HL=DE with all 16bits intact.

Z80 Instruction Format

Commands and Parameters
Each instruction consists of a command, and optionally one or two parameters. Usually the leftmost parameter is modified by the operation when two parameters are specified.

Parameter Placeholders
The following placeholders are used in the following chapters:

r 8bit register A,B,C,D,E,H,L rr 16bit register BC, DE, HL/IX/IY, AF/SP (as described) i 8bit register A,B,C,D,E,IXH/IYH,IXL/IYL ii 16bit register IX,IY n 8bit immediate 00-FFh (unless described else) nn 16bit immediate 0000-FFFFh d 8bit signed offset -128..+127 f flag condition nz,z,nc,c AND/OR po,pe,p,m (as described) (..) 16bit pointer to byte/word in memory

Opcode Bytes
Each command (including parameters) consists of 1-4 bytes. The respective bytes are described in the following chapters. In some cases the register number or other parameters are encoded into some bits of the opcode, in that case the opcode is specified as "xx". Opcode prefix bytes "DD" (IX) and "FD" (IY) are abbreviated as "pD".

Clock Cycles
The clock cycle values in the following chapters specify the execution time of the instruction. For example, an 8-cycle instruction would take 2 microseconds on a CPU which is operated at 4MHz (8/4 ms). For conditional instructions two values are specified, for example, 17;10 means 17 cycles if condition true, and 10 cycles if false.
Note that in case that WAIT signals are sent to the CPU by the hardware then the execution may take longer.

Affected Flags
The instruction tables below are including a six character wide field for the six flags: Sign, Zero, Halfcarry, Parity/Overflow, N-Flag, and Carry (in that order). The meaning of the separate characters is:

s Indicates Signed result z Indicates Zero h Indicates Halfcarry o Indicates Overflow p Indicates Parity c Indicates Carry - Flag is not affected 0 Flag is cleared 1 Flag is set x Flag is destroyed (unspecified) i State of IFF2 e Indicates BC<>0 for LDX(R) and CPX(R), or B=0 for INX(R) and OUTX(R)

Z80 Load Commands

8bit Load Commands

Instruction Opcode Cycles Flags Notes ld r,r xx 4 ------ r=r ld i,i pD xx 8 ------ i=i ld r,n xx nn 7 ------ r=n ld i,n pD xx nn 11 ------ i=n ld r,(HL) xx 7 ------ r=(HL) ld r,(ii+d) pD xx dd 19 ------ r=(ii+d) ld (HL),r 7x 7 ------ (HL)=r ld (ii+d),r pD 7x dd 19 ------ ld (HL),n 36 nn 10 ------ ld (ii+d),n pD 36 dd nn 19 ------ ld A,(BC) 0A 7 ------ ld A,(DE) 1A 7 ------ ld A,(nn) 3A nn nn 13 ------ ld (BC),A 02 7 ------ ld (DE),A 12 7 ------ ld (nn),A 32 nn nn 13 ------ ld A,I ED 57 9 sz0i0- A=I ;Interrupt Register ld A,R ED 5F 9 sz0i0- A=R ;Refresh Register ld I,A ED 47 9 ------ ld R,A ED 4F 9 ------

16bit Load Commands

Instruction Opcode Cycles Flags Notes ld rr,nn x1 nn nn 10 ------ rr=nn ;rr may be BC,DE,HL or SP ld ii,nn pD 21 nn nn 13 ------ ii=nn ld HL,(nn) 2A nn nn 16 ------ HL=(nn) ld ii,(nn) pD 2A nn nn 20 ------ ii=(nn) ld rr,(nn) ED xB nn nn 20 ------ rr=(nn) ;rr may be BC,DE,HL or SP ld (nn),HL 22 nn nn 16 ------ (nn)=HL ld (nn),ii pD 22 nn nn 20 ------ (nn)=ii ld (nn),rr ED x3 nn nn 20 ------ (nn)=rr ;rr may be BC,DE,HL or SP ld SP,HL F9 6 ------ SP=HL ld SP,ii pD F9 10 ------ SP=ii push rr x5 11 ------ SP=SP-2, (SP)=rr ;rr may be BC,DE,HL,AF push ii pD E5 15 ------ SP=SP-2, (SP)=ii pop rr x1 10 (-AF-) rr=(SP), SP=SP+2 ;rr may be BC,DE,HL,AF pop ii pD E1 14 ------ ii=(SP), SP=SP+2 ex DE,HL EB 4 ------ exchange DE <--> HL ex AF,AF 08 4 xxxxxx exchange AF <--> AF' exx D9 4 ------ exchange BC,DE,HL <--> BC',DE',HL' ex (SP),HL E3 19 ------ exchange (SP) <--> HL ex (SP),ii pD E3 23 ------ exchange (SP) <--> ii

Blocktransfer

Instruction Opcode Cycles Flags Notes ldi ED A0 16 --0e0- (DE)=(HL), HL=HL+1, DE=DE+1, BC=BC-1 ldd ED A8 16 --0e0- (DE)=(HL), HL=HL-1, DE=DE-1, BC=BC-1 ldir ED B0 bc*21-5 --0?0- ldi-repeat until BC=0 lddr ED B8 bc*21-5 --0?0- ldd-repeat until BC=0

Z80 Arithmetic/Logical Commands

8bit Arithmetic/Logical Commands

Instruction Opcode Cycles Flags Notes daa 27 4 szxp-x decimal adjust akku cpl 2F 4 --1-1- A = A xor FF neg ED 44 8 szho1c A = 00-A <arit> r xx 4 szhonc see below <arit> i pD xx 8 szhonc see below, UNDOCUMENTED <arit> n xx nn 7 szhonc see below <arit> (HL) xx 7 szhonc see below <arit> (ii+d) pD xx dd 19 szhonc see below <cnt> r xx 4 szhon- see below <cnt> i pD xx 8 szhon- see below, UNDOCUMENTED <cnt> (HL) xx 11 szhon- see below <cnt> (ii+d) pD xx dd 23 szhon- see below <logi> r xx 4 szhp00 see below <logi> i pD xx 8 szhp00 see below, UNDOCUMENTED <logi> n xx nn 7 szhp00 see below <logi> (HL) xx 7 szhp00 see below <logi> (ii+d) pD xx dd 19 szhp00 see below

Arithmetic <arit> commands:

add A,op see above 4-19 szho0c A=A+op adc A,op see above 4-19 szho0c A=A+op+cy sub op see above 4-19 szho1c A=A-op sbc A,op see above 4-19 szho1c A=A-op-cy cp op see above 4-19 szho1c compare, ie. VOID=A-op

Increment/Decrement <cnt> commands:

inc op see above 4-23 szho0- op=op+1 dec op see above 4-23 szho1- op=op-1

Logical <logi> commands:

and op see above 4-19 sz1p00 A=A & op xor op see above 4-19 sz0p00 A=A XOR op or op see above 4-19 sz0p00 A=A | op

16bit Arithmetic Commands

Instruction Opcode Cycles Flags Notes add HL,rr x9 11 --h-0c HL = HL+rr ;rr may be BC,DE,HL,SP add ii,rr pD x9 15 --h-0c ii = ii+rr ;rr may be BC,DE,ii,SP (!) adc HL,rr ED xA 15 szho0c HL = HL+rr+cy ;rr may be BC,DE,HL,SP sbc HL,rr ED x2 15 szho1c HL = HL-rr-cy ;rr may be BC,DE,HL,SP inc rr x3 6 ------ rr = rr+1 ;rr may be BC,DE,HL,SP inc ii pD 23 10 ------ ii = ii+1 dec rr xB 6 ------ rr = rr-1 ;rr may be BC,DE,HL,SP dec ii pD 2B 10 ------ ii = ii-1

Searchcommands

Instruction Opcode Cycles Flags Notes cpi ED A1 16 szhe1- compare A-(HL), HL=HL+1, DE=DE+1, BC=BC-1 cpd ED A9 16 szhe1- compare A-(HL), HL=HL-1, DE=DE-1, BC=BC-1 cpir ED B1 x*21-5 szhe1- cpi-repeat until BC=0 or compare fits cpdr ED B9 x*21-5 szhe1- cpd-repeat until BC=0 or compare fits

Z80 Rotate/Shift and Singlebit Operations

Rotate and Shift Commands

Instruction Opcode Cycles Flags Notes rlca 07 4 --0-0c rotate akku left rla 17 4 --0-0c rotate akku left through carry rrca 0F 4 --0-0c rotate akku right rra 1F 4 --0-0c rotate akku right through carry rld ED 6F 18 sz0p0- rotate left low digit of A through (HL) rrd ED 67 18 sz0p0- rotate right low digit of A through (HL) <cmd> r CB xx 8 sz0p0c see below <cmd> (HL) CB xx 15 sz0p0c see below <cmd> (ii+d) pD CB dd xx 23 sz0p0c see below <cmd> r,(ii+d) pD CB dd xx 23 sz0p0c see below, UNDOCUMENTED modify and load

Whereas <cmd> may be:

rlc rotate left rl rotate left through carry rrc rotate right rr rotate right through carry sla shift left arithmetic (b0=0) sll UNDOCUMENTED shift left (b0=1) sra shift right arithmetic (b7=b7) srl shift right logical (b7=0)

Singlebit Operations

Instruction Opcode Cycles Flags Notes bit n,r CB xx 8 xz1x0- test bit n ;n=0..7 bit n,(HL) CB xx 12 xz1x0- bit n,(ii+d) pD CB dd xx 20 xz1x0- set n,r CB xx 8 ------ set bit n ;n=0..7 set n,(HL) CB xx 15 ------ set n,(ii+d) pD CB dd xx 23 ------ set r,n,(ii+d) pD CB dd xx 23 ------ UNDOCUMENTED set n,(ii+d) and ld r,(ii+d) res n,r CB xx 8 ------ reset bit n ;n=0..7 res n,(HL) CB xx 15 ------ res n,(ii+d) pD CB dd xx 23 ------ res r,n,(ii+d) pD CB dd xx 23 ------ UNDOCUMENTED res n,(ii+d) and ld r,(ii+d) ccf 3F 4 --h-0c h=cy, cy=cy xor 1 scf 37 4 --0-01 cy=1

Z80 Jumpcommands & Interrupts

General Jump Commands

Instruction Opcode Cycles Flags Notes jp nn C3 nn nn 10 ------ jump to nn, ie. PC=nn jp HL E9 4 ------ jump to HL, ie. PC=HL jp ii pD E9 8 ------ jump to ii, ie. PC=ii jp f,nn xx nn nn 10;10 ------ jump to nn if nz,z,nc,c,po,pe,p,m jr nn 18 dd 12 ------ relative jump to nn, ie. PC=PC+d jr f,nn xx dd 12;7 ------ relative jump to nn if nz,z,nc,c djnz nn 10 dd 13;8 ------ B=B-1 and relative jump to nn if B<>0 call nn CD nn nn 17 ------ call nn ie. SP=SP-2, (SP)=PC, PC=nn call f,nn xx nn nn 17;10 ------ call nn if nz,z,nc,c,po,pe,p,m ret C9 10 ------ pop PC ie. PC=(SP), SP=SP+2 ret f xx 11;5 ------ pop PC if nz,z,nc,c,po,pe,p,m rst n xx 11 ------ call n ;n=00,08,10,18,20,28,30,38 nop 00 4 ------ no operation

Interrupt Related Commands

Instruction Opcode Cycles Flags Notes di F3 4 ------ IFF1=0, IFF2=0 ;disable interrupts ei FB 4 ------ IFF1=1, IFF2=1 ;enable interrupts im 0 ED 46 8 ------ read opcode from databus on interrupt im 1 ED 56 8 ------ execute call 0038h on interrupt im 2 ED 5E 8 ------ execute call (i*100h+databus) on int. halt 76 N*4 ------ repeat until interrupt occurs reti ED 4D 14 ------ pop PC, IFF1=IFF2, ACK (ret from INT) retn ED 45 14 ------ pop PC, IFF1=IFF2 (ret from NMI) </INT=LOW,IM=0,IFF1=1> 1+var ------ IFF1=0,IFF2=0, exec opcode from databus </INT=LOW,IM=1,IFF1=1> 12 ------ IFF1=0,IFF2=0, CALL 0038h </INT=LOW,IM=2,IFF1=1> 18 ------ IFF1=0,IFF2=0, CALL [I*100h+databus] </NMI=falling_edge> ? ------ IFF1=0, CALL 0066h

Z80 I/O Commands

Instruction Opcode Cycles Flags Notes in A,(n) DB nn 11 ------ A=PORT(A*100h+n) in r,(C) ED xx 12 sz0p0- r=PORT(BC) in (C) ED 70 12 sz0p0- **undoc/illegal** VOID=PORT(BC) out (n),A D3 nn 11 ------ PORT(A*100h+n)=A out (C),r ED xx 12 ------ PORT(BC)=r out (C),0 ED 71 12 ------ **undoc/illegal** PORT(BC)=00 ini ED A2 16 xexxxx MEM(HL)=PORT(BC), HL=HL+1, B=B-1 ind ED AA 16 xexxxx MEM(HL)=PORT(BC), HL=HL-1, B=B-1 outi ED A3 16 xexxxx B=B-1, PORT(BC)=MEM(HL), HL=HL+1 outd ED AB 16 xexxxx B=B-1, PORT(BC)=MEM(HL), HL=HL-1 inir ED B2 b*21-5 x1xxxx same than ini, repeat until b=0 indr ED BA b*21-5 x1xxxx same than ind, repeat until b=0 otir ED B3 b*21-5 x1xxxx same than outi, repeat until b=0 otdr ED BB b*21-5 x1xxxx same than outd, repeat until b=0

Z80 Interrupts

Interrupt Flip-Flop (IFF1,IFF2)
The IFF1 flag is used to enable/disable INTs (maskable interrupts).
In a raw INT-based system, IFF2 is always having the same state than IFF1. However, in a NMI-based system the IFF2 flag is used to backup the recent IFF1 state prior to NMI execution, and may be used to restore IFF1 upon NMI completion by RETN opcode.
Beside for the above 'backup' function, IFF2 itself is having no effect. Neither IFF1 nor IFF2 affect NMIs which are always enabled.
The following opcodes/events are modifying IFF1 and/or IFF2:

EI IFF1=1, IFF2=1 DI IFF1=0, IFF2=0 <INT> IFF1=0, IFF2=0 <NMI> IFF1=0 RETI IFF1=IFF2 RETN IFF1=IFF2

When using the EI instruction, the new IFF state isn't applied until the next instruction has completed (this ensures that an interrupt handler which is using the sequence "EI, RET" may return to the main program before the next interrupt is executed).
Interrupts can be disabled by the DI instruction (IFF=0), and are additionally automatically each time when an interrupt is executed.

Interrupt Execution
An interrupt is executed when an interrupt is requested by the hardware, and IFF is set. Whenever both conditions are true, the interrupt is executed after the completion of the current opcode.
Note that repeated block commands (such like LDIR) can be interrupted also, the interrupt return address on the stack then points to the interrupted opcode, so that the instruction may continue as normal once the interrupt handler returns.

Interrupt Modes (IM 0,1,2)
The Z80 supports three interrupt modes which can be selected by IM 0, IM 1, and IM 2 instructions. The table below describes the respective operation and execution time in each mode.

Mode Cycles Refresh Operation 0 1+var 0+var IFF1=0,IFF2=0, read and execute opcode from databus 1 12 1 IFF1=0,IFF2=0, CALL 0038h 2 18 1 IFF1=0,IFF2=0, CALL [I*100h+databus]

Mode 0 requires an opcode to be output to the databus by external hardware, in case that no byte is output, and provided that the 'empty' databus is free of garbage, then the CPU might tend to read a value of FFh (opcode RST 38h, 11 cycles, 1 refresh) - the clock cycles (11+1), refresh cycles (1), and executed operation are then fully identical as in Mode 1.
Mode 1 interrupts always perform a CALL 0038h operation. The downside is that many systems may have ROM located at this address, making it impossible to hook the interrupt handler directly.

Mode 2 calls to a 16bit address which is read from a table in memory, the table pointer is calculated from the "I" register (initialized by LD I,A instruction) multiplied by 100h, plus an index byte which is read from the databus. The following trick may be used to gain stable results in Mode 2 even if no index byte is supplied on the databus: For example, set I=40h the origin of the table will be then at 4000h in memory. Now fill the entire area from 4000h to 4100h (101h bytes, including 4100h) by the value 41h. The CPU will then perform a CALL 4141h upon interrupt execution - regardless of whether the randomized index byte is an even or odd number.

Non-Maskable Interrupts (NMIs)
Unlike INTs, NMIs cannot be disabled by the CPU, ie. DI and EI instructions and the state of IFF1 and IFF2 do not have effect on NMIs. The NMI handler address is fixed at 0066h, regardless of the interrupt mode (IM). Upon NMI execution, IFF1 is cleared (disabeling maskable INTs - NMIs remain enabled, which may result in nested execution if the handler does not return before next NMI is requested). IFF2 remains unchanged, thus containing the most recent state of IFF1, which may be used to restore IFF1 if the NMI handler returns by RETN instruction.
Execution time for NMIs is unknown (?).

RETN (return from NMI and restore IFF1)
Intended to return from NMI and to restore the old IFF1 state (assuming the old state was IFF1/IFF2 both set or both cleared).

RETI (return from INT with external acknowledge)
Intended to return from INT and to notify peripherals about completion of the INT handler, the Z80 itself doesn't send any such acknowledge signal (instead, peripherals like Z80-PIO or Z80-SIO must decode the databus during /M1 cycles, and identify the opcode sequence EDh,4Fh as RETI). Aside from such external handling, internally, RETI is exactly same as RETN, and, like RETN it does set IFF1=IFF2 (though in case of RETI this is a dirt effect without practical use; within INT handlers IFF1 and IFF2 are always both zero, or when EI was used both set). Recommended methods to return from INT are: EI+RETI (when needing the external acknowledge), or EI+RET (faster).

Z80 Meaningless and Duplicated Opcodes

Mirrored Instructions
NEG (ED44) is mirrored to ED4C,54,5C,64,6C,74,7C.
RETN (ED45) is mirrored to ED55,65,75.
RETI (ED4D) is mirrored to ED5D,6D,7D.

Mirrored IM Instructions
IM 0,X,1,2 (ED46,4E,56,5E) are mirrored to ED66,6E,76,7E.
Whereas IM X is an undocumented mirrored instruction itself which appears to be identical to either IM 0 or IM 1 instruction (?).

Duplicated LD HL Instructions
LD (nn),HL (opcode 22NNNN) is mirrored to ED63NNNN.
LD HL,(nn) (opcode 2ANNNN) is mirrored to ED6BNNNN.
Unlike the other instructions in this chapter, these two opcodes are officially documented. The clock/refresh cycles for the mirrored instructions are then 20/2 instead of 16/1 as for the native 8080 instructions.

Mirrored BIT N,(ii+d) Instructions
Unlike as for RES and SET, the BIT instruction does not support a third operand, ie. DD or FD prefixes cannot be used on a BIT N,r instruction in order to produce a BIT r,N,(ii+d) instruction. When attempting this, the 'r' operand is ignored, and the resulting instruction is identical to BIT N,(ii+d).
Except that, not tested yet, maybe undocumented flags are then read from 'r' instead of from ii+d(?).

Non-Functional Opcodes
The following opcodes behave much like the NOP instruction.
ED00-3F, ED77, ED7F, ED80-9F, EDA4-A7, EDAC-AF, EDB4-B7, EDBC-BF, EDC0-FF.
The execution time for these opcodes is 8 clock cycles, 2 refresh cycles.
Note that some of these opcodes appear to be used for additional instructions by the R800 CPU in newer turbo R (MSX) models.

Ignored DD and FD Prefixes
In some cases, DD-prefixes (IX) and FD-prefixes (IY) may be ignored by the CPU. This happens when using one (or more) of the above prefixes prior to instructions that already contain an ED, DD, or FD prefix, or prior to any instructions that do not support IX, IY, IXL, IXH, IYL, IYH operands. In such cases, 4 clock cycles and 1 refresh cycle are counted for each ignored prefix byte.

Z80 Garbage in Flag Register

Nocash Z80-flags description
This chapter describes the undocumented Z80 flags (bit 3 and 5 of the Flags Register), these flags are affected by ALL instructions that modify one or more of the normal flags - all OTHER instructions do NOT affect the undocumented flags.

For some instructions, the content of some flags has been officially documented as 'destroyed', indicating that the flags contain garbage, the exact garbage calculation for these instructions will be described here also.

All information below just for curiosity. Keep in mind that Z80 compatible CPUs (or emulators) may not supply identical results, so that it wouldn't be a good idea to use these flags in any programs (not that they could be very useful anyways).

Normal Behaviour for Undocumented Flags
In most cases, undocumented flags are copied from the Bit 3 and Bit 5 of the result byte. That is "A AND 28h" for:

RLD; CPL; RLCA; RLA; LD A,I; ADD OP; ADC OP; XOR OP; AND OP; RRD; NEG; RRCA; RRA; LD A,R; SUB OP; SBC OP; OR OP ; DAA.

When other operands than A may be modified, "OP AND 28h" for:

RLC OP; RL OP; SLA OP; SLL OP; INC OP; IN OP,(C); RRC OP; RR OP; SRA OP; SRL OP; DEC OP

For 16bit instructions flags are calculated as "RR AND 2800h":

ADD RR,XX; ADC RR,XX; SBC RR,XX.

Slightly Special Undocumented Flags
For 'CP OP' flags are calculated as "OP AND 28h", that is the unmodified operand, and NOT the internally calculated result of the comparision.
For 'SCF' and 'CCF' flags are calculated as "(A OR F) AND 28h", ie. the flags remain set if they have been previously set.
For 'BIT N,R' flags are calculated as "OP AND 28h", additionally the P-Flag is set to the same value than the Z-Flag (ie. the Parity of "OP AND MASK"), and the S-flag is set to "OP AND MASK AND 80h".

Fatal MEMPTR Undocumented Flags
For 'BIT N,(HL)' the P- and S-flags are set as for BIT N,R, but the undocumented flags are calculated as "MEMPTR AND 2800h", for more info about MEMPTR read on below.
The same applies to 'BIT N,(ii+d)', but the result is less unpredictable because the instruction sets MEMPTR=ii+d, so that undocumented flags are "<ii+d> AND 2800h".

Memory Block Command Undocumented Flags
For LDI, LDD, LDIR, LDDR, undocumented flags are "((A+DATA) AND 08h) + ((A+DATA) AND 02h)*10h".
For CPI, CPD, CPIR, CPDR, undocumented flags are "((A-DATA-FLG_H) AND 08h) + ((A-DATA-FLG_H) AND 02h)*10h", whereas the CPU first calculates A-DATA, and then internally subtracts the resulting H-flag from the result.

Chaotic I/O Block Command Flags
The INI, IND, INIR, INDR, OUTI, OUTD, OTIR, OTDR instructions are doing a lot of obscure things, to simplify the description a placeholder called DUMMY is used in the formulas.

DUMMY = "REG_C+DATA+1" ;for INI/INIR DUMMY = "REG_C+DATA-1" ;for IND/INDR DUMMY = "REG_L+DATA" ;for OUTI,OUTD,OTIR,OTDR FLG_C = Carry of above "DUMMY" calculation FLG_H = Carry of above "DUMMY" calculation (same as FLG_C) FLG_N = Sign of "DATA" FLG_P = Parity of "REG_B XOR (DUMMY AND 07h)" FLG_S = Sign of "REG_B" UNDOC = Bit3,5 of "REG_B AND 28h"

The above registers L and B are meant to contain the new values which are already incremented/decremented by the instruction.
Note that the official docs mis-described the N-Flag as set, and the C-Flag as not affected.

DAA Flags
Addition (if N was 0):

FLG_H = (OLD_A AND 0Fh) > 09h FLG_C = Carry of result

Subtraction (if N was 1):

FLG_H = (NEW_A AND 0Fh) > 09h FLG_C = OLD_CARRY OR (OLD_A>99h)

For both addition and subtraction, N remains unmodified, and S, Z, P contain "Sign", Zero, and Parity of result (A). Undocumented flags are set to (A AND 28h) as normal.

Mis-documented Flags
For all XOR/OR: H=N=C=0, and for all AND: H=1, N=C=0, unlike described else in Z80 docs. Also note C,N flag description bug for I/O block commands (see above).

Internal MEMPTR Register
This is an internal Z80 register, modified by some instructions, and usually completely hidden to the user, except that Bit 11 and Bit 13 can be read out at a later time by BIT N,(HL) instructions.
The following list specifies the resulting content of the MEMPTR register caused by the respective instructions.

Content Instruction A*100h LD (xx),A ;xx=BC,DE,nn xx+1 LD A,(xx) ;xx=BC,DE,nn nn+1 LD (nn),rr; LD rr,(nn) ;rr=BC,DE,HL,IX,IY rr EX (SP),rr ;rr=HL,IX,IY (MEMPTR=new value of rr) rr+1 ADD/ADC/SBC rr,xx ;rr=HL,IX,IY (MEMPTR=old value of rr+1) HL+1 RLD and RRD dest JP nn; CALL nn; JR nn ;dest=nn dest JP f,nn; CALL f,nn ;regardless of condition true/false dest RET; RETI; RETN ;dest=value read from (sp) dest RET f; JR f,nn; DJNZ nn ;only if condition=true 00XX RST n adr+1 IN A,(n) ;adr=A*100h+n, memptr=A*100h+n+1 bc+1 IN r,(BC); OUT (BC),r ;adr=bc ii+d All instructions with operand (ii+d)

Also the following might or might not affect MEMPTR, not tested yet:

OUT (N),A and block commands LDXX, CPXX, INXX, OUTXX and probably interrupts in IM 0, 1, 2

All other commands do not affect the MEMPTR register - this includes all instructions with operand (HL), all PUSH and POP instructions, not executed conditionals JR f,d, DJNZ d, RET f (ie. with condition=false), and the JP HL/IX/IY jump instructions.

Z80 Compatibility

The Z80 CPU is (almost) fully backwards compatible to older 8080 and 8085 CPUs.

Instruction Format
The Z80 syntax simplifies the chaotic 8080/8085 syntax. For example, Z80 uses the command "LD" for all load instructions, 8080/8085 used various different commands depending on whether the operands are 8bit registers, 16bit registers, memory pointers, and/or an immediates. However, these changes apply to the source code only - the generated binary code is identical for both CPUs.

Parity/Overflow Flag
The Z80 CPU uses Bit 2 of the flag register as Overflow flag for arithmetic instructions, and as Parity flag for other instructions. 8080/8085 CPUs are always using this bit as Parity flag for both arithmetic and non-arithmetic instructions.

Z80 Specific Instructions
The following instructions are available for Z80 CPUs only, but not for older 8080/8085 CPUs:
All CB-prefixed opcodes (most Shift/Rotate, all BIT/SET/RES commands).
All ED-prefixed opcodes (various instructions, and all block commands).
All DD/FD-prefixed opcodes (registers IX and IY).
As well as DJNZ nn; JR nn; JR f,nn; EX AF,AF; and EXX.

8085 Specific Instructions
The 8085 instruction set includes two specific opcodes in addition to the 8080 instruction set, used to control 8085-specifc interrupts and SID and SOD input/output signals. These opcodes, RIM (20h) and SIM (30h), are not supported by Z80/8080 CPUs.

Z80 vs Z80A
Both Z80 and Z80A are including the same instruction set, the only difference is the supported clock frequency (Z80 = max 2.5MHz, Z80A = max 4MHz).

NEC-780 vs Zilog-Z80
These CPUs are apparently fully compatible to each other, including for undocumented flags and undocumented opcodes.

Z80 Pin-Outs

_____ _____ | |_| | A11 |1 40| A10 A12 |2 39| A9 A13 |3 38| A8 A14 |4 37| A7 A15 |5 36| A6 CLK |6 35| A5 D4 |7 34| A4 D3 |8 33| A3 D5 |9 32| A2 D6 |10 Z80 31| A1 VCC |11 CPU 30| A0 D2 |12 29| GND D7 |13 28| /RFSH D0 |14 27| /M1 D1 |15 26| /RST /INT |16 25| /BUSRQ /NMI |17 24| /WAIT /HALT |18 23| /BUSAK /MREQ |19 22| /WR /IORQ |20 21| /RD |_____________|

++++++++++++++++++++++++


The following was taken off http://www.projectvb.com/nss/snes_adapter.htm

I finally have my SNES to Nintendo Super System cartridge adapter working to my satisfaction. This does exactly what you expect... lets you play your SNES cartridges on your Nintendo Super System arcade game. You can also play original Super System games from an SNES flash cartridge (as well as your SNES games of course).

 In most cases, you'll want to play in "Timed" mode (get X amount of time per credit), though this adapter also has a switch for "Skill" mode, which was used on several Super System games to let you play until you die, rather than for a set amount of time.

Based on feedback that I've gotten, it sounds like some people want a "good enough" adapter for cheap, while others want the "perfect" adapter. I personally wanted mine to be as perfect as possible... but to satisfy both types (or for those looking to buy more than one adapter, that can get away with one or two basic adapters), I decided to offer two models.

Breakdown of options

Basic - This adapter will let you play most SNES/SFC games on the NSS.
Deluxe - This is the same as the basic, but also has a CIC lockout clone installed, and has a plastic cartridge support bracket, which will prevent you from inserting your SNES cart backwards. The CIC is needed for 25 or so games (mostly games with the SA1 co-processor), which includes Super Mario RPG, Kirby's Dream Land 3, Kirby Super Star, etc.

Additions

The cartridge has a socketed Instruction ROM, which has the name of the cartridge, as well as on-screen instructions if you press the "Instructions" button. By default, these will be labeled "SNES Cart", with generic instructions. If you have an EPROM programmer, you can reprogram the flash chip yourself as well.

A new BIOS isn't required, though I recommend V3 (which is the newest) for its various nice features.

Pictures

These are the support brackets that are included with the Deluxe version. These will provide a little bit of extra support to the SNES cartridge, and prevent you from inserting it backwards. There is a seperate piece for SNES and Super Famicom cartridges.

These pictures are of the cartridges in the 
system. With this adapter, you need to install the SNES cartridges with 
the tray in, and remove them before pulling the tray out. Honestly, 
swapping cartridges without pulling the tray is easier... the reach to 
get to the cartridge is the same as the reach to undo the latches that 
let the tray slide out, and the Timed/Skill switch is facing the front. 
There is plenty of room inside the cabinet... the last picture shows an 
SNES cart in a Game Genie with room to spare.

Q&A:

Which games work with the adapter?

Every game that can play on a 60 Hz SNES/SFC should work properly. This 
includes games with co-processors (Super FX, DSP-1, SA1, etc), Super 
Gameboy, Flash Carts, etc.



Which games DON'T work with the adapter?

The only known games that don't work are a small subset of PAL (European
 region) games, which are software locked to 50 Hz. These read the PPU 
to determine whether they're running at 50 Hz or 60 Hz, and if they 
detect 60 Hz, they show a message saying "THIS GAME PAK IS NOT DESIGNED 
FOR YOUR SUPER FAMICOM OR SUPER NES". The NSS runs at 60 Hz, so without a
 hardware modification, these games will not work. There are VERY few 
games that have this region lockout, and a flash cart like the SD2SNES 
performs automatic region patching, which should take care of that 
problem.



How about Super Scope 6, Mario Paint, or other games that use special controllers?

Okay... fine, they don't work either, simply because the Super System 
motherboard doesn't have controller ports to plug the special 
controllers into.



Do flash carts work?

The SNES PowerPak works out of the box. The SD2SNES requires a 
modification to the motherboard for the reset circuit.  I don't have an 
Everdrive, and I'm not sure that anyone has tested it... but it should 
work, though possibly requiring the same reset modification as the 
SD2SNES.



Do I need a new BIOS?

No, this works with any stock BIOS, though the V3 BIOS has some nice 
features (like being able to reset to the main menu while in the middle 
of a game).



What's the difference between the Basic and Deluxe models?

The Basic model will let you play most SNES games. The Deluxe model 
includes the CIC lockout circuit, which increases compatibility to near 
100%. The Deluxe model also includes a plastic support bracket, which 
prevents you from inserting an SNES cartridge backwards. The Basic model
 will be perfectly fine for most games, especially if you're planning to
 simply install one game and leave it (like those that just want Super 
Mario Kart or Legend of Zelda in their cabinet).



Which games require the CIC?

All SA1 games (Super Mario RPG, Kirby Super Star, Kirby's Dream Land 3, 
and others) will require the CIC. I'm not aware of any, but there may 
also be others that require either the CIC, or one or more of the CIC 
signals as well. A list of SNES games and their enhancement chips can be
 found here: ... The SNES PowerPak does not require the CIC, though I'm not sure about the Everdrive or SD2SNES.

Can I slide the tray in and out with the cartridges in?

With this adapter, you need to install the SNES cartridges with the tray
 in, and remove them before pulling the tray out. Honestly, swapping 
cartridges without pulling the tray is easier... the reach to get to the
 cartridge is the same as the reach to undo the latches that let the 
tray slide out, and the Timed/Skill switch is facing the front, so you 
can easily toggle back and forth. There is plenty of room for the 
cartridges inside the cabinet. If you really want to slide the tray in 
and out, some SNES cartridge PCBs are short enough that they will slide 
in and out if you remove them from their cartridge shell.



Which Super System games support "skill" mode?

ActRaiser, Addams Family, Lethal Weapon, Robocop 3, and Magic Floor (homebrew by nocash).



What about Super System games with DIP switches?

There is no hardware DIP switch support, but I have created an 
application (for Windows) which allows you to patch the ROMs with your 
desired DIP switch settings, here: http://retro-repairs.netai.net/nintendo_super_system/nss_dips.rar [264KB].  The same games which support "skill" mode also support DIP switches.





Thanks to:

Martin Korth (nocash) for reverse engineering the Instruction ROM, 
removing the need for the security PROM... plus general SNES/NSS related
 information.

Maximilian Rehkopf (ikari_01) for creating the SuperCIC CIC clone.

MAME Team 

+++++++++++++++++++++++++

Another question: Can you load more than 3 games at once?

Answer: No and yes, again.

When loading actual NSS-made games, you can only have 3 titles running off the board 

at once. However, if I'm able to get a SNES to NSS adapter going... I can fit literally 

hundreds upon hundreds of titles on 1 cartridge! How you might ask? By adding another 

adapter to the adapter known as the 'SD2SNES.'

 Description
 

The SD2SNES is a flashcart, which loads the ROMs in the console itself. The handling of the flashcart is very simple. Just put your back-up game ROM files on your SD card. Plug your SD card into your SD2SNES and your SD2SNES into the cart slot of your system.

Features

• SD/SDHC/SDXC support (tested up to 64GB; no exFAT support so SDXC cards must be reformatted using FAT32).
• High quality push to push memory card slot.
• Fast ROM loading (~9MB/s).
• Fast menu navigation.
• Directories are sorted automatically, no need for FAT sorting tools.
• High resolution menu (512×224) for adequate display of long file names.
• Real Time Clock.
• Supports ROM size up to 128Mbit (96Mbit actually implemented).
• Automatic near-time SRAM saving to SD Card (while the game is running). Some limitations apply:
• Near-time saving is switched to periodic saving when a game is found to use the SRAM as work RAM.
• Automatic saving is disabled when MSU1 is used. SRAM is saved on reset.
• Enhancement chip support (see below for implementation status).
• SuperCIC key (SNES CIC clone):
• Enables operation on unmodified consoles of all regions.
• Supports software 50/60Hz switching on SuperCIC enhanced consoles only (to be performed by SD2SNES firmware, not       yet implemented there).
• Auto region patching: Eliminates “This Game Pack is not designed…” messages regardless of 50/60Hz setting.

ENHANCEMENT CHIPS:
Each supported enhancement chip can be used in conjunction with MSU1.

IMPLEMENTED:
BS-X memory map / Satellaview base unit registers (clock)
DSP1 / 1b
DSP2
DSP3
DSP4
ST-010
Cx4
MSU1
S-RTC

Cartridge uses custom made multi region shell. It fits in both American, Europe and Japan systems.


Downloads:
-Firmware Downloads-
http://retro-repairs.netai.net/sd2snes/sd2snes_firmware_v0.1.1_to_0.1.7b.rar

Instructions:

Download the zip file and extract to your SD card. Make sure the directory structure from the zip file is preserved, so you end up with a ‘sd2snes’ directory in the root of your SD card.
Insert the card into your sd2snes and turn on the SNES. sd2snes will update its firmware from the card and boot.
After updating you may delete the ‘firmware.img’ file. You may not delete any other files from the sd2snes directory.

Important:

The ‘sd2snes’ directory is considered a system folder and ignored by the file browser. Do not put any ROMs there as they will not show up :)
The headerless BS-X BIOS is required for running BS games. Rename it as ‘bsxbios.bin’ and put it in the sd2snes directory.
For DSPx / ST0010 support you need the DSP ROM dumps:

http://retro-repairs.netai.net/sd2snes/sd2snes_bios.rar

SD2SNES

Developed by: ikari_01
Manufactured by: Krikzz
Worldwide sales by: DragonBox.de, emere.es, Stone Age Gamer, RetroGate
Additional sales by: Various
Also Known As: -
Review by Qtis – Completed 26/09/14

Introduction

The Super Nintendo Entertainment System, more commonly known as the SNES, was released around the world in the early 90's and ended up being the most successful console of its generation. It fought alongside the Sega Genesis/Megadrive, but managed to beat the other large console maker at the time. The SNES also brought forth new game series with games such as F-Zero, Pilotwings, Super Mario Kart and Super Mario RPG. The same games, which have been fan favorites and have seen new releases on even the latest generation of consoles. For the modern gamer, the problem of relatively small sales of niche games at the time have made quite a few games hard to find unless you're ready to pay an arm and a leg for a working copy. Emulation for the SNES is widely available, but has had its problems with supporting special chips and creating the genuine feeling of using original hardware.
When the 21st century started rolling along, electronics started going down in price in terms of powerful chips and hardware. Old consoles began seeing development projects, such as the sd2iec for the Commodore 64, making the old devices work with modern storage options, mainly CF/SD cards. Add to this the interest for the SNES by many developers and modders for enabling region free mods by digging into the SNES CIC among other things (SNES CIC reverse engineering, 50/60Hz switching) as well as making more memory available for the games (Media Streaming Unit-1 or MSU1 (alternative mirror as byuu changes hosts)). At the same time the idea of creating a complete all in one solution for the SNES with most if not all special chips supported in one cart began forming in the heads of a few people around the SNES developers forums. As always with these kinds of projects for old hardware, open source was the way to go. Finally the last ingredient needed for making something special for the SNES was ikari_01, who began work on the prototype of a new solution for the SNES in 2009.
Thus, the Project SD2SNES was born.
Important GBAtemp Information:
GBAtemp has opened all reviews for user comment. Please remember that the comments must adhere to our strict guidelines. We ask that you do not post congratulatory comments or comments speculative in nature, negative in nature, or the like, that have nothing to do with the review or the review’s contents. Please consider posting only well researched comments that further the overall effect of the review and nothing more.
Special Thanks:
​A special thanks must go out to ikari_01 for the support during the review as well as to Krikzz and Retrogate for providing the review sample. Retrogate is the officially licensed store for all Krikzz Flash Kit products and also handles sales of the SD2SNES. Their customer service, e-mail support, and inclusion of a tracking number make it easy to recommend them.

Product Information

The product information is from the SD2SNES project page retrieved during the reviewing of the cart. The software features may change as new versions of the operating system are released, but the hardware specifications are final.
Features:

• SD/SDHC/SDXC support (tested up to 64GB; no exFAT support so SDXC cards must be reformatted using FAT32)
• High quality push-push memory card slot
• Fast ROM loading (~9MB/s)
• Fast menu navigation
• Directories are sorted automatically, no need for FAT sorting tools
• High resolution menu (512×224) for adequate display of long file names
• Real Time Clock
• Supports ROM size up to 128MBit (96Mbit actually implemented as there are no larger known memory maps)
• Automatic near-time SRAM saving to SD Card (while the game runs). Some limitations apply:
  • Near-time saving is switched to periodic saving when a game is found to use the SRAM as work RAM.
  • Automatic saving is disabled when MSU1 is used. SRAM is saved on reset.
• Enhancement chip support (see below for implementation status)
• SuperCIC key (SNES CIC clone):
  • Enables operation on unmodified consoles of all regions
  • Supports software 50/60Hz switching on SuperCIC enhanced consoles only (to be performed by sd2snes firmware, not yet implemented there)
• Auto region patching: eliminates “This Game Pak is not designed…” messages regardless of 50/60Hz setting
• Supports up to 16000 files per directory / roughly 50000 files per card

Implemented Enhancement Chips (usable with MSU1):

• BS-X memory map / Satellaview base unit registers (clock)
• DSP1 / 1b
• DSP2
• DSP3
• DSP4
• ST-010
• Cx4
• MSU1
• S-RTC
• OBC1

The SD2SNES differs from quite a large part of Flash Kits made for retro consoles in a few ways. The main difference is the usage of a large FPGA chip for adding special chip support on the cart. This removes the need for soldering special chips from original SNES donor carts into the device itself, which saves both the original carts as well as removes the possibility of the user frying the SD2SNES with soldering. The other major feature of the FPGA chip is the possibility  of adding support in future operating system/firmware releases for new special chips, which were not present in the original firmware. As such the hardware is very future proof with new features being released and all code available in the Github for the SD2SNES. The board itself also has all the bells and whistles pre-installed, so a potential buyer will not need to ponder wether to buy or not to buy a USB port or have some kind of special chip installed with the cart. As such, while the SD2SNES is a bit more expensive compared to other available options for the SNES, it makes up for it with the massive feature set as well as the magic made possible by the massive FPGA.
The SD2SNES is not produced by ikari_01 anymore, but do not worry. Krikzz, known for the Everdrive series of Flash Kits, has taken over the production and distribution of the cart. This means that the cart is available in almost all stores selling the Everdrives and the build quality will be similar to Everdrive series.

Contents, Packaging, Design & Impressions

Contents:

• 1x SD2SNES Flash Kit inside a universal SNES shell

Packaging & Design:
The SD2SNES supplied by RetroGate follows the same packaging system as used by other carts produced by Krikzz. The shipment was shipped inside a bubble wrap envelope and the cart itself was inside a white cardboard box with a label Everdrive - Krikzz.com on top. The SD2SNES itself was loose inside the box with extra supporting bubble wrap . The good packaging made sure that the review unit arrived in one piece without any damage to the case.

The SD2SNES board itself was already inserted inside a brand new universal shell, which meant it was ready to be used straight out of the box. The universal shell is similar in design to the NTSC/J and PAL region carts, so it can look a bit out of place in a US SNES console. The shell's dimensions are identical to a PAL SNES cart, though the material of the shell is a bit different in terms of coloring. In other words, the shell is otherwise similar to the cart mentioned in the Super Everdrive v2 review, but with different positions for the SD card slot and the added USB slot. On the front of the cart is a label with the text SD2SNES in a large font as well as www.krikzz.com and www.sd2snes.de below it in a smaller font. The label is of good quality similar to the Everdrive series, but does pale in comparison to original Nintendo carts' label quality when observed at close range. In case you want a NTSC/U version of the SD2SNES shell, checking the various resellers can result in a SD2SNES in a NTSC/U shell.

Setup & Usage

The SD2SNES, as its name suggests, requires a SD card to function. The SD2SNES also supports microSD/miniSD cards via SD card adapters. At the time of writing, SD, SDHC and SDXC cards are supported up to 64GB, though larger cards need to be formatted with FAT32 as exFAT isn't supported (yet). The operating system is available for download from the developer's home page and the downloaded zip file includes an image for preparing the SD card for the cart: drag and drop the sd2snes folder to the root of the SD card and you're done. At the time of writing the latest OS version is v0.1.6, though v0.1.7 is right around the corner with additional features including cheat support.
The device loads the OS and games from a single SD card placed in the spring-loaded SD card slot on the top of the cart. Since the sd2snes folder is hidden by the SD2SNES firmware on boot, all homebrew and games will need to be placed somewhere else on the SD card. In case you want to remove the need to cycle through a load of folders, you can just dump all your games on the root of your SD card. The SD2SNES supports up to 16000 files per directory, but I'd personally recommend using some kind of folder system instead of placing the whole romset on the root of the SD card. Once you boot your SNES with the SD2SNES inserted, you will be presented with a list of your SD card's root without the sd2snes folder. 

The GUI for the SD2SNES is very simplistic and requires little beforehand reading on what different buttons do. The SD2SNES' menu with the SNES controller is designed to be very intuitive and in case of problems the buttons and their functions are displayed on the bottom of the screen. The up and down buttons on the dpad are used to select a file on the current page, while the left and right buttons are used to change pages. The A button acts as an OK button and the B button is CANCEL. The X button is used for the menu, which is used to set the clock as well as checking the system information. In case you're wondering whether your SD card is top notch and usable with MSU1, the SD card's average and maximum access times are shown here (more of this in the compatibility area). A nice addition to the mix of functions is the menu of the last 10 games played accessible via START button.

In case you're interested in some additional hardware modding of your SNES, the SD2SNES has some neat features available to you. Based on the SNES CIC reverse engineering project mentioned earlier, ikari_01 has made and implemented the SuperCIC and In Game Reset (IGR) for the SNES. This may seem like a moot thing for the average user, but it does remove a lot of the problems relating to region and 50/60 Hz differences between the NTSC and PAL regions. All you need in order to make these work is a few PIC16F630 microcontrollers (and a programmer), a few wires and soldering skills. In case you're not up to the programming part of the PIC chips, you can buy them pre-made from around the web from places like ASSEMblergames. Once the modifications have been done, you can reset your SNES with the controller and play any region games on the console without worrying about region locks (especially SA-1 games can cause problems on non-modded consoles).
Saving with the SD2SNES is as simple as it gets. In most games, the save is transferred to the SD card immediately as you save. As the SRAM is battery-based, you can be guaranteed that the save is kept on the cart even in the extreme case that a power outage interrupts your gaming. In case the game uses the SRAM as work RAM (as in needs the extra RAM to run), the saving will be changed to periodic saving. Here the save is routinely transferred to the SD, but may not be immediate as the SRAM is used for more than just saving. Unfortunately save states are impossible to make with the SNES in general, since the APU state cannot be snapshot after it has code running (mentioned by ikari_01 here).
MSU1 is a tricky thing in terms of real time saving, since the custom chip system doesn't support flow control. This has been explained by ikari_01 in the comment section of SD2SNES.de, but isn't a problem as long as you remember to reset the console. Since MSU1 is a relatively new thing, not many hacks or games use it to the fullest and/or are completely finished. As the SNES scene and especially the SD2SNES have shown, this will probably not be the situation in the future. MSU1's 4GB of space for a SNES game with CD quality audio can be considered a revolution for the SNES. Byuu has shown SNES games such as Chrono Trigger with the PlayStation version's FMVs included via MSU1 support. It's amazing to see such options made available on original hardware and without any modifications to the console itself. And who said old consoles couldn't innovate?

Compatibility

Compatibility of a cart like the SD2SNES is the number one thing on many a buyer's checklist. This is why I paid extra attention to special chip support and how games reacted to the cart if a special chip was used. The testing hardware was a PAL SNES with 50/60Hz and Region Free modifications, though both mods were set to standard 50 Hz and PAL region for testing purposes. All testing was done with clean ROMs from the GoodSNES set without any region patches or hacks unless otherwise specified (such as translations or the SDD-1 patch for Star Ocean). If a game uses a special chip, the chip is mentioned after the verdict.

As mentioned previously, not all special chips are supported yet. The unsupported special chip games from the incompatibility list at SD2SNES.de are not included in the review, since all games using the unsupported chips would result in an automatic FAIL verdict. Using a T-connector with the SD2SNES will not help with the compatibility, since a pass-through adapter is only usable with DSP series chips (DSP1-4, ST-010), which are already supported by the SD2SNES natively. In any case I prefer to include the list here, since the special chips themselves may not be descriptive enough for some people reading only this review. Still, I recommend checking the official incompatibility list if a new OS release has added new chip support (and thus removed a game or more from the following list).

Unsupported Games list:
Carts with BS memory pack slots, other than BS-X BIOS (e.g. Derby Stallion 96, any Tsukuuru). They may run but cannot use memory pack related features.
Sufami Turbo games:

• Car Ranger
• Crayon Shin Chan
• Gegege No Kitarou
• Gekisou Sentai Carranger: Zenkai Racer Senshi
• Poi Poi Ninja
• Sailor Moon Stars Panic 2
• SD Gundam Generations: part 1
• SD Gundam Generations: part 2
• SD Gundam Generations: part 3
• SD Gundam Generations: part 4
• SD Gundam Generations: part 5
• SD Gundam Generations: part 6
• SD Ultra Battle: Seven Legend
• SD Ultra Battle: Ultraman Legend
• Sufami Turbo hardware
• Tetris 2+ Bombliss

SuperFX games:

• Dirt Racer
• Dirt Trax FX
• Doom
• Star Fox 2
• Star Fox / Starwing
• Stunt Race FX / Wild Trax
• Super Mario World 2: Yoshi’s Island
• Vortex
• Winter Gold / FX Skiing

SA-1 games:

• Daisenryaku Expert WWII: War in Europe
• Derby Jockey 2
• Dragon Ball Z: Hyper Dimension
• Habu Meijin no Omoshiro Shogi
• Itoi Shigesato no Bass Tsuri No. 1
• Jikkyou Oshaberi Parodius
• J.League ’96 Dream Stadium
• Jumpin’ Derby
• Kakinoki Shogi
• Kirby’s Dream Land 3
• Kirby Super Star
• Marvelous: Mouhitotsu no Takarajima
• Masters New: Haruka Naru Augusta 3
• Mini 4WD Shining Scorpion Let’s & Go!!
• Pebble Beach no Hotou: New Tournament Edition
• PGA European Tour
• PGA Tour ’96
• Power Rangers Zeo: Battle Racers
• SD F-1 Grand Prix
• SD Gundam G NEXT
• Shin Shogi Club
• Shogi Saikyou
• Shogi Saikyou 2
• Super Bomberman Panic Bomber World
• Super Mario RPG: Legend of the Seven Stars
• Super Robot Taisen Gaiden: Maso Kishin – The Lord Of Elemental

S-DD1 games:

• Star Ocean (unhacked version)
• Street Fighter Alpha 2 / Zero 2

ST-011 games:

• Hayazashi Nidan Morita Shougi

ST-018 games:

• Hayazashi Nidan Morita Shougi 2

SPC7110 games:

• Far East of Eden Zero
• Momotaro Dentetsu Happy
• Super Power League 4

Testing the SD2SNES was done with a 16GB SanDisk Ultra Class 10 UHS-1 card. In order to remove any problems with the file system or corruption, the card was formatted to FAT32 with the Windows Formatter. All cards should work with the device and offer the same compatibility, but MSU1 compatibility requires an access time of around up to 1 ms. The access time requirement is needed due to the simultanious streaming of audio and data on MSU1 games. Fast transfer speeds do not automatically mean fast access times, so keep this in mind if you plan to take advantage of MSU1 support.

The results are color-coded. Green is for a game which works without issues, yellow is for a game with issues and red is for a game which won't run. For the games which failed, multiple versions were tested to ensure that it wasn't a case of a bad ROM or unsupported version.
Super Nintendo Entertainment System:

• Actraiser [PAL] - PASS
• Aladdin [PAL] - PASS
• Another World [PAL] - PASS
• Bahamut Lagoon [NTSC/J] (w/ DeJap English Translation) - PASS
• Breath of Fire [NTSC/U] - PASS
• Castlevania - Vampire's Kiss [PAL] - PASS
• Chrono Trigger [NTSC/U] - PASS
• Clock Tower [NTSC/J] (w/ Aeon Genesis English Translation) - PASS
• Dai Kaiju Monogatari 2 [NTSC/J] - PASS [S-RTC]
• Donkey Kong Country - PASS
• Dragon Ball Z Super Saiya Densetsu [NTSC/J] (w/ Klepto Software English Translation) - PASS
• Dragon Quest V Tenkuu no Hanayome [NTSC/J] (w/ DeJap English Translation) - PASS
• Dungeon Master [NTSC/U] - PASS [DSP-2]
• Earthworm Jim [PAL] - PASS
• Earthbound [NTSC/U] - PASS
• F1 ROC II: Race of Champions [NTSC/U] - PASS [ST-010]
• F-Zero [PAL] - PASS
• Famicom Tantei Club Part II (w/ Neo Demiforce English Translation) - PASS
• Final Fantasy III [NTSC/U] - PASS
• Final Fantasy V [NTSC/J] (w/RPGe patch) - PASS
• The Flintsones [PAL] - PASS
• Gradius III [NTSC/U] - PASS
• Harvest Moon [PAL] - PASS
• Illusion of Time [PAL] - PASS
• Joe and Mac 3 - Lost in the Tropics [PAL] - PASS
• JoJo no Kimyou na Bouken [NTSC/J] (w/ Aeon Genesis English Translation) - PASS
• Killer Instinct [PAL] - PASS
• Kirby's Ghost Trap [PAL] - PASS
• Legend of Zelda, The - A Link to the Past [PAL] - PASS
• Live-a-Live [NTSC/J] - PASS
• Megaman 7 [PAL] - PASS
• Megaman X [PAL] - PASS
• Megaman X2 [PAL] - PASS [Cx4]
• Megaman X3 [PAL] - PASS [Cx4]
• Metal Combat: Falcon's Revenge [PAL] - PASS [OBC-1]
• Might & Magic 3: Isles of Terra [U] - PASS
• Mortal Kombat 3 [PAL] - PASS
• Ninja Gaiden Trilogy [NTSC/U] - PASS
• Ninjawarriors - The New Generation [PAL] - PASS
• Ogre Battle - The March of The Dark Queen [NTSC/U] - PASS
• Phalanx [PAL] - PASS
• Pilotwings [NTSC/U] - PASS [DSP-1]
• Rockman & Forte [NTSC/J] - PASS
• Romancing Sa-Ga 3 [NTSC/J] (w/ Mana Sword English Translation) - PASS
• SD Gundam GX [NTSC/J] - PASS [DSP-3]
• Secret of Evermore [PAL] - PASS
• Secret of Mana [PAL] - PASS
• Seiken Densutsu 3 [NTSC/J] - PASS
• Shin Megami Tensei [NTSC/U] (w/ Aeon Genesis English Translation) - PASS
• Star Ocean [NTSC/J] SDD-1 Hack - PASS [SDD-1]
• Super Ghouls 'n Ghosts [PAL] - PASS
• Super Mario All-Stars + Super Mario World [PAL] - PASS
• Super Mario Kart [PAL] - PASS [DSP-1/1B]
• Super Metroid [PAL] - PASS
• Super Street Fighter II [PAL] - PASS
• Tales of Phantasia [NTSC/J] (w/ DeJap English Translation) - PASS
• Terranigma [PAL] - PASS
• Top Gear 3000 [PAL] - PASS [DSP-4]
• Treasure Hunter G [NTSC/J] (w/ Metalhawk English Translation) - PASS
• Ultima - The False Prophet [NTSC/U] - PASS
• Wonder Project J - Kikai no Shounen Pino [NTSC/J] (w/ WakdHacks English Translation) - PASS
• Zombies (PAL) - PASS

Satellaview [NTSC/J only]:
Note: Satellaview games are unique games for the Satellaview modem add-on.

• As mentioned before, Bokujou Monogatari - Dai-2-wa - PASS
• BS Fire Emblem - Akaneia Senki Hen - Dai-1-wa - Palace Kanraku - PASS
• BS F-Zero Grand Prix - Dai-1-shuu - Knight League - ISSUES (Game freezes after entering game specific area)
• BS Super Mario USA - Power Challenge - Dai-1-kai - PASS
• Chrono Trigger - Jet Bike Special - PASS
• Chrono Trigger - Music Library - PASS
• Excitebike - Bunbun Mario Battle - Stadium 1 - PASS (Demo intro runs for a few minutes before you can play.)
• Kirby no Omochabako - Hoshi Kuzushi - ISSUES (Problems with proceeding while loading game parts)
• Mario Paint - BS Ban - PASS
• Panel de Pon - Event '98 - PASS
• Yoshi no Panepon - BS Ban - PASS

Homebrew and MSU1:

• Astrohawk -  FAIL (Black screen on boot)
• Airwolf - PASS (Garbled graphics also happen on emulator)
• Bio Worm - PASS
• BLT - ISSUES (Garbled graphics in the lower left area on the screen)
• Classic Kong - PASS
• Hong Kong 97 - PASS
• N-Warp Daisakusen (v 1.1) - PASS
• Skipp and Friends - PASS
• Super Mario Odyssey - PASS [MSU1]
• Uwol - Quest for Money - PASS

Conclusions

Many people have asked again and again why someone would spend money on a Flash Kit for a console released almost 25 years ago and which has highly compatible emulators such as bsnes available. The fight between original hardware and emulation will never end, but devices such as the SD2SNES make it hard to not recommend the original over the new wave. Just looking at the features and the nice row of green PASS verdicts should be enough for anyone sceptical of the execution of the SD2SNES. As new features and support for more special chips are developed by ikari_01 and the community, you can expect more use out of your device. 
The SD2SNES was not designed to be the cheapest option available and it shows. Paying a bit extra adds functions not available to cheaper options. Speical chip support for games like Mario Kart (DSP) and Megaman X2 (Cx4) are clear indicators that the SD2SNES can do much more than just play normal SNES games. The hardware can be seen as the ultimate solution for the SNES with little trade-offs. Still, there are a few caveats including the lack of GSU1/2 (SuperFX) and SA-1 support. These games are only a few percent of the total library of games for the SNES, but include some of the most iconic games ever released for the SNES. I would still not be let down by the current situation, since development has brought support for new chips even this year (2014)!
And as some people will prefer this:
TL;DR: The SD2SNES has been and still is at the time of writing the best Flash Kit available for the SNES. If you want the best out of the best and are willing to pay a little extra for the additional features and support, you won't be disappointed. 

Verdict

Pros + Easy to use (drag and drop to SD card) + Hardware build quality and universal shell design + Special chip support beats all other options available + Fantastic compatibility for ROMs, Homebrew, Satellaview and MSU1 + Support from developer is very good + New features added with new OS releases + Open source and well documented operating system + SRAM backup of saves are instant + SuperCIC and In-game reset compatibility with a hardware mod + File limit per directory (16000 per folder)

Cons - GSU1/2 (SuperFX), SA-1 and a few other special chips are yet to be supported. - Cheat support (to be released in v0.1.7)

9.7 out of 10

Overall Easily the best Flash Kit available for the SNES. If you're interested in the best overall compatibility as well as on-going support to add even more features, you can't go wrong. The device itself is easy to use and offers fantastic features to both untouched as well as modded consoles. A few unsupported special chips drop the score a few points, but as the software and hardware are as stellar as they are, I can't justify a lower score. Krikzz's hardware quality as well as ikari_01's and the community's software updates will guarantee you many hours of fun on your SNES with even more functions than ever seen before.

 +++++++++++++++++++++++++

I also found this forum topic on the NSS here.. http://forums.nesdev.com/viewtopic.php?f=12&t=9065

nocash

	Post subject: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Mon Jul 02, 2012 4:21 pm
Joined: Fri Feb 24, 2012 12:09 pm Posts: 487	Does somebody have a Nintendo Super System at home? --- The NSS is an arcade cabinet that can hold up to three slightly customized SNES games. The SNES part is quite simple: A game over flag at port 4016h.W.bit2 (used in "skill mode"), and a DIP-Switch input at 4200h.R for changing difficulty (on cartridges that DO have DIP-switches). Then there's a Z80 CPU for handling coin input and such things (similar as in NES Playcoice 10 and SNES SFC-Box). The Z80 BIOS is very unstructured and messy. After 2-3 days, I've basically figured out most of the I/O ports. For the button input, I am still unsure about which-bit-is-which-button in some cases. Serial OSD chip access is (maybe intentionally) programmed in confusing fashion with mirrored I/O addresses and plenty nonsense bits. Apart from that, it's using a straight address + character/attribute transmission. Character numbers for A-Z, a-z, 0-9, # and space are quite obvious (though non-ASCII). Underline and (I think) 3bit RGB color are looking simple. There should be special commands for character size and BG color and maybe other features. And for dumping the full charset with all symbols and punctuation marks, it'd be nice to run a Test-EPROM on real hardware sooner or later. RTC and EEPROM are also serially accessed, but that part looks simple. Finally, there's some sort of 8pin "CIC" chip in the cartridges - it seems to be accessed by Writing-and-Reading-and-Jumping-To address E37Fh. I've no clue how THAT is working. And, for making own games, understanding the format of the Instruction ROM (32K EPROM) would be also important. Title is at DEF1h. Checksum LSB and MSB are unconventionally found via pointers at C032h and DFFEh. The 32h-byte "CIC" key seems to be found at [C034h]. And somehere, there must be some kind of entrypoint. --- Anyways, does somebody have a NSS at home? At the moment, I am having some basic questions: Is it possible to light more than one of the three game LEDs? Or to disable ALL LEDs? If not, then the LEDs might be just bound to the slot-selection bits (and then, it'd be ridiculous to search for separate LED enable bits). What are the Test and Credit buttons doing? I guess one (which?) adds a credit? And the other one shows up the Bookkeeping/Coinage/Selftest menu? And can somebody verify the part number of the OSD chip? According to http://mamedev.org/source/src/mame/drivers/nss.c.html it's a "Mitsubishi M50458-001SP" chip. But then... that nss.c file is wrong on almost every possible detail concerning Memory and I/O, and even the pin-number of the 100pin slot is wrong. Alltogther, the file seems to be more aiming at a good laugh than actually emulating the NSS hardware. Wouldn't be too surprised if the M50458-001SP part number is wrong, too. Seems to be quite impossible to find a datasheet for that chip. But, it DOES seem exist. There are a few non-NSS pages mentioning it, including pinouts, schematics, and even some sample-code.
Top

byuu	Post subject: Posted: Mon Jul 02, 2012 4:47 pm
Joined: Mon Mar 27, 2006 5:23 pm Posts: 1147	As always, I am in awe that you're willing to take on such obscure hardware unrelated to the actual games. Since you are focusing on it, would you be willing to help with another part of the NSS? I'd like to know the DIP switch settings for all NSS carts. For instance, here is ActRaiser: Code:     <setting name="Difficulty">       <option value="0x0000" name="Easy"/>       <option value="0x0001" name="Normal"/>       <option value="0x0002" name="Hard"/>       <option value="0x0003" name="Expert"/>     </setting>     <setting name="Lives">       <option value="0x0000" name="5 lives"/>       <option value="0x0004" name="4 lives"/>       <option value="0x0008" name="3 lives"/>       <option value="0x000c" name="2 lives"/>     </setting>     <setting name="Minute Speed">       <option value="0x0000" name="60 seconds"/>       <option value="0x0010" name="54 seconds"/>       <option value="0x0020" name="48 seconds"/>       <option value="0x0030" name="42 seconds"/>     </setting> (You OR all the options and that's what $4200-4201 returns when read.) I believe the MESS team has told me that some of the NSS dumps are "suspect", and may just be forgeries of regular games. Although some likely really don't have DIP switch settings at all. So it would be great if we could redump and reverify all the NSS games. The arcade machines are a very rare find though. And they're freaking huge :/ Also ... can you explain the game over flag in a bit more detail? How does one go about triggering that? What is skill mode? When I put ActRaiser into expert mode, I get game over normally when I run out of lives. I'd love to see a video of it triggered, too. Like the SFC Box, I don't intend to simulate the non-SNES overlay hardware, but it would be good to do a rough simulation of this feature.
Top

nocash	Post subject: Posted: Mon Jul 02, 2012 5:47 pm
Joined: Fri Feb 24, 2012 12:09 pm Posts: 487	Quote: As always, I am in awe that you're willing to take on such obscure hardware Obscure stuff is interesting. I guess most people never heard of that thing - at least, I never ever heard of it, until doing some NES playchoice 10 research last week. Quote: I'd like to know the DIP switch settings for all NSS carts. Okay, but now, that is TOO obscure. I'll try to add a DIP-switch option somewhere in the no$sns gui, so one can try what happens. Or otherwise, even without emulating it, one could just look at the opcodes that read 4200h. Quote: (You OR all the options and that's what $4200-4201 returns when read.) Yup, Act Raiser is doing a 16bit read there (but uses only the lower some bits)... I would guess that 4201h..42FFh are just mirrors of 4200h. Quote: I believe the MESS team has told me that some of the NSS dumps are "suspect", and may just be forgeries of regular games. I think the BIOS and INST-ROM are suspect by themselves. There are a lot of unused regions that are filled with unused code fragments (such like 50 opcodes from a "used" region, copied into an "unused" region). It's pretty hard to separate between meaningful code/data and garbage - on the other hand that's making it difficult to create own games or bootlegs - so far, if the dumps contain working PRG-ROMs and INST-ROMs, then they are probably original NSS games. Quote: Although some likely really don't have DIP switch settings at all. So it would be great if we could redump and reverify all the NSS games. There seem to be 3 different cartridge PCBs, type A without SRAM and without DIP switches. Type B with SRAM and optional DIP switches. And Type C is same as B, but with bigger ROM (on two ROM chips). In practice, the DIPs seem to be installed only on Type C boards. Quote: Also ... can you explain the game over flag in a bit more detail? How does one go about triggering that? 4016h.W.Bit2 is just a normally unused joypad output. Act Raiser sets that bit upon game over. Actually it seems to toggle the bit twice (don't know why twice). On the Z80 side that signal should probably show up in one of the I/O ports, and the Z80 could then reset the SNES and display some insert coin message. I haven't got that far yet to see what happens exactly. Quote: What is skill mode? When I put ActRaiser into expert mode, I get game over normally when I run out of lives. I haven't emulated the configuration menu yet, but there seem to be two modes: In Skill Mode the game does probably end when you lost all lives. And in the other mode one can set a Minute:Second time limit per credit, and the game should then end when you run out of time/money. Judging from photos, there seem to be 1-credit games and 2-credit games. Which probably means that one needs more money for the latter ones. Don't know if that can be configured in the Coinage screen, or if it's preset in the INST ROMs or "CIC" chip.
Top

byuu	Post subject: Posted: Mon Jul 02, 2012 6:13 pm
Joined: Mon Mar 27, 2006 5:23 pm Posts: 1147	Oh, one additional bit of info. There's apparently two firmware versions of the NSS board itself. You apparently need the newer one to play the later released games. I don't know which chip in particular, saw it on a video about the hardware. > Okay, but now, that is TOO obscure. I dunno, I thought it was really cool. I understand it's a pain to do so, but I generate the GUI based on the XML when you first load the cart, so you can set how you want it to play. For ActRaiser more than any other game, it's really nice. The real ActRaiser requires you to beat the game before you can play a limited "arcade" mode that's every -other- level. The NSS game lets you skip story mode, play -every- level, and the DIP settings give you lots of skill settings. To me, the DIP settings are much more interesting than the insert coin and game selection overlays. I am still happy you are researching the latter of course. Everything that can be preserved should be. > Yup, Act Raiser is doing a 16bit read there (but uses only the lower some bits)... I would guess that 4201h..42FFh are just mirrors of 4200h. I got that impression when AR only used 6-bits. It would be great to confirm whether 4201-42FF are open bus or mirrors of 4200. I just let you control both bytes just in case, until we verify all games' DIP settings. > on the other hand that's making it difficult to create own games or bootlegs Unfortunately there are two bootlegs on eBay now =( http://www.ebay.com/itm/Nintendo-super- ... 231f14d0f5 http://www.ebay.com/itm/Nintendo-super- ... 231f14f657 This page lists Super Copa on the display, which AFAIK was not an NSS game. It's also an insanely rare commercial cart from Mexico/Brazil only: http://distritofederal.quebarato.com.mx ... 731AC.html Hopefully the real ones come on mask ROMs, so you can easily spot fakes before dumping. The non-standard connector won't make dumping easy, either. Nor will the scarcity. EDIT: they are apparently all EEPROMs, shit :( That makes absolute verification from one board impossible. > In practice, the DIPs seem to be installed only on Type C boards. Ah, neat. So there were 14 games total. Do we know the type of each of the 14 games? Or even better, do we have PCB scans of all 14 somewhere? Knowing a game were type A or B to skip testing for DIP settings would be nice. Heh, here I thought the DIPs were software-based, and accessible in the arcade operator's menu. I sure hope there's at least a manual or something for arcade operators to know how the DIPs work. > 4016h.W.Bit2 is just a normally unused joypad output. Oh, are you saying "Bit1-Bit8", or "Bit0-Bit7"? If the former, that's a fairly obvious choice to use controller Data2 line. If the latter, then that's pretty darn neat since the stock SNES doesn't use the third bit at all. FWIW, I always start from zero when indexing bits with bytes. > I haven't got that far yet to see what happens exactly. Ah, so untested for now. Okay then, I won't support it for now. I look forward to more research :D
Top

tepples	Post subject: Posted: Mon Jul 02, 2012 6:42 pm
Joined: Sun Sep 19, 2004 11:12 pm Posts: 16838 Location: NE Indiana, USA (NTSC)	About toggling twice, I seem to remember an old article in Nintendo Power claiming that inserting coins bought extra lives. Perhaps the extra toggle was to see whether a coin had been inserted.
Top

nocash	Post subject: Posted: Mon Jul 02, 2012 7:49 pm
Joined: Fri Feb 24, 2012 12:09 pm Posts: 487	Quote: Oh, are you saying "Bit1-Bit8", or "Bit0-Bit7"? If the former, that's a fairly obvious choice to use controller Data2 line. You mean like the 2nd bit in the 2-bit joypad INPUT register? No, I meant the 3rd bit in the 3-bit joypad OUTPUT register. The register is always 3-bit wide, nothing new there, though, in normal SNES consoles, the pins for bit1-2 are left unconnected.
Top

byuu	Post subject: Posted: Tue Jul 03, 2012 5:08 am
Joined: Mon Mar 27, 2006 5:23 pm Posts: 1147	> You mean like the 2nd bit in the 2-bit joypad INPUT register? Oops, yeah, my mistake. > No, I meant the 3rd bit in the 3-bit joypad OUTPUT register. That's even more surprising to me. I was under the impression the register was 1-bit wide, and was connected to LATCH for both joypads. > The register is always 3-bit wide, nothing new there, though, in normal SNES consoles, the pins for bit1-2 are left unconnected. Do you know where the pins are in the SNES? I use bit0 for sending serial data to my PC from the SNES. If I could solder two extra wires to send three bits at a time, I could send a byte on three writes instead of eight. And now I have to wonder what $4016w.d1 is for on the NSS :P
Top

tepples	Post subject: Posted: Tue Jul 03, 2012 6:09 am
Joined: Sun Sep 19, 2004 11:12 pm Posts: 16838 Location: NE Indiana, USA (NTSC)	There is a second pin that can be used as an output: the I/O Bit. The multitap, for example, uses it as an output, and it uses both D1 and D0 as inputs if I remember correctly.
Top

byuu	Post subject: Posted: Tue Jul 03, 2012 12:30 pm
Joined: Mon Mar 27, 2006 5:23 pm Posts: 1147	Since they are not on the same register, that really doesn't do us any good. I use IObit to toggle between serial and joypad passthru though. But that's getting off-topic now.
Top

nocash	Post subject: Posted: Tue Jul 03, 2012 3:01 pm
Joined: Fri Feb 24, 2012 12:09 pm Posts: 487	There are a lot of unused external I/O ports in the controller registers, and in APU registers, too. See the fullsnes.htm doc for details on bits and pins. The fastest possible transfer should be injecting data to WRAM, as done by the "xboo" circuit in fullsnes.htm, that'd theoretically offer "DMA speed", though waitstates on the PC side are slowing it down. But it's still very fast for doing things like 64Kbyte test-program uploads. ---- Okay, but back to the NSS - first, some questions about the 8pin protection chip: Did somebody ever manage to dump one of that chips (assuming that it DOES contain memory)? Did somebody ever identify the chip? The part number is reportedly scratched off (or at least hidden under the sticker). Probably it's a serial PROM, same or similar as the RP5H01 chips used on Playchoice 10 cartridges. Did somebody ever identify the pinouts? At least GND and VCC should be VERY simple to identify; and even that info would help to find out if it's a RP5H01 or not, and if it's wired to TEST mode or not. ---- On the Z80 side, I've figured out how the protection chip is accessed. The jumps to the memory mapped I/O port at E37Fh are apparently causing RST opcodes to be executed. Obviously not RST 0 (reset), but two of the other seven RST opcodes (one for receiving "0" bits from PROM, and one for "1" bits). The RST handler are then doing some confusing address indirections, and do finally end up at two small procedures in INST ROM, which do then return the PROM bit in CY flag. And alongsides, the PROM data is XORed with other rotated values. After that reading/xoring/rotations, one does have 32h bytes data: The number of "0" bits in the checksum for that region indicates how to handle the checksum of another region (which is addressed by the last two bytes of the 32h-byte data, and a bit from 2nd byte). Aside from being used as address, the last 2 bytes are also containing the expected checksum; eventually XORed by other bytes; depending on the number of "0" bits. Confusing, eh? Might be getting difficult to get that well-described, or to produce homebrew games for the NSS. The 2nd byte does also contain a 8bit GameID, if there's already a cartridge with same ID in one of the other slots, then the NSS won't show the cartridge in the game menu. That 8bit ID might have caused problems in case there would have been more than 256 games relesed. Don't know yet what the other bytes in the 32h-byte area are used for. I am afraid that they might contain important stuff like entrypoints to INST ROM - so, without also having dumped the protection chips, the INST ROM dumps might turn out to be totally useless.
Top

nocash	Post subject: Posted: Thu Jul 12, 2012 3:50 am
Joined: Fri Feb 24, 2012 12:09 pm Posts: 487	Got it! The protection chip is the same RP5H01 serial 9-byte PROM as used in Playchoice 10, and contains a decryption key. It's first used to decrypt the 32h-byte block. And then used to decrypt the game title, in a second decryption pass (from the previously decrypted 32h-byte block). As long as the exact spelling of the title is known, one can write a brute-force program to find the correct decryption key. That is, yes, a very stupid idea, I wasted some days until I got it working, but I didn't have the real PROM chips, and thus couldn't dump them the normal way. Currently, the brute-force approach takes around a minute to find the key (it needs to brute on the first 24bit (16 million combinations) to be able to decrypt only the 1st byte of the title). But, eight of the 9-key bytes seem to be also stored in (almost) unencrypted form somewhere in the INST ROM. The only problem is that the location of that data is encrypted via the PROM. Anyways, there only 8192 bytes of the ROM used, so feeding key bytes from all possible ROM addresses should be around 2000 times faster than the current 16 million times bruting. The BIOS is quite some beast. At first glance it looks totally amateurish: For example, it doesn't have ONE menu function that shows the currently selected menu item. No, it has FOUR menu functions (one separate function, depending on which if the four menu items is selected). Even stranger, it never uses that four functions, but uses a fifth menu function (that cannot show the current selection at all). But aside from the GUI, there are some evil hacks. Like here - three overlapping procedures that share the same opcodes: Code: 0000:65DA FD 21 F1 64  ld   iy,64F1 ;token_goto_if_zero 0000:65DE 18 (EA)      jr   65CA                       ;------------------                       ;*** below opcode EAh does OVERLAP with above EAh!                       ;------------------                       cryptic_osd_callback:                        ;this is used on the hidden protection checks                        ;in the OSD write string function 0000:65DF (EA) 3F 5F   jp   pe,5F3F ;cryptic_osd_callback_even 0000:65E2 E2 (D9 5E)   jp   po,5ED9 ;cryptic_osd_callback_odd                       ;------------------                       ;*** below opcodes D9h,5Eh do OVERLAP with above D9h,5Eh!                       ;------------------                       token_34_osd_wrstr_indirect: 0000:65E3 D9           exx 0000:65E4 5E           ld   e,[hl]      ;\ 0000:65E5 23           inc  hl          ; get string address 0000:65E6 56           ld   d,[hl]      ;/ As seen above, there's a token interpreter, I think the INST ROM also contains some tokens, not only text/data for the instructions. And the title decryption is also funny: It's hidden in the OSD write string function (and automatically displays & decrypts the title when passing an invalid VRAM address to that function. The instructions are a bit disappointing. In ActRaiser, there's only one page, telling what controller buttons to use. There is really no story-mode there. Maybe there's a bit more text in other games. ActRaiser seems to have pre-allocated space for 10 pages (which would occupy 5K of used 8K area of the 32K INST ROM).
Top

nocash	Post subject: Posted: Thu Jul 19, 2012 7:26 pm
Joined: Fri Feb 24, 2012 12:09 pm Posts: 487	Quote: Do we know the type of each of the 14 games? Or even better, do we have PCB scans of all 14 somewhere? What 14 games did you mean? I know only 12 games: Code:   PCB Title   C   Act Raiser (NSS) 1992 Enix (Two EPROMs+DIPSW)   C   Addams Family, The (NSS) 1992 Ocean (Two EPROMs+DIPSW)   C?  Contra 3: The Alien Wars (NSS) 1992 Konami (Two EPROMs+SRAM+DIPSW)   C   David Crane's Amazing Tennis (NSS) 1992 Abs.Ent.Inc. (Two EPROMs+DIPSW)   B   F-Zero (NSS) 1991 Nintendo (ROM+SRAM)   C   Irem Skins Game, The (NSS) 1992 Irem (Two EPROMs+DIPSW)   C   Lethal Weapon (NSS) 1992 Ocean (Two EPROMs+DIPSW)   C   NCAA Basketball (NSS) 1992 Sculptured Software Inc. (Two EPROMs+DIPSW)   C?  Robocop 3 (NSS) 1992 Ocean (Two EPROMs+DIPSW)   A   Super Mario World (NSS) 1991 Nintendo (ROM)   A   Super Soccer (NSS) 1992 Human Inc. (EPROM)   A   Super Tennis (NSS) 1991 Nintendo (ROM) Plus, there has been an advert announcing Push-Over, but I don't know if that game was actually released. And PCB scans, the "nss.c" file describes which game uses which PCB. According to that file, there are only 3 PCB versions (A,B,C). For A and B I've found good pictures of the component sides (but none of the solder side; which would have been really helpful). And Type C seems to be quite rare - I've found only one low-res photo of that PCB. The one thing visible there is that it has only 8 DIP-switches, so Port 4101h is definitely containing some kind of garbage, no additional switches. With the brute force proggy, I've managed to get decryption keys for 7 of the 12 games. The missing ones are: All three Type A games - the title/spelling there is fully known, so the brute force stuff should have worked without problems. My current guess is that the PROM chip is wired differently on the Type A boards. I've found somebody who owns Type A carts, and hope to get pics of the solder side soon. And, keys for Robocop 3 and Contra 3 are also missing. Maybe they use different PCBs, too. Or it's just a spelling problem... though I've tried most possible combinations for Robocop/RoboCop/ROBCOP 3 or III. Well, and "Contra 3: The Alien Wars" must be somehow squeezed to 21 characters, which gives near endless possibilites... not to mention that some people are referring to the NSS version as "Super Contra" or "Alien Attack"; and... in the bookkeeping screen it does even identify itself as "New Game 1". Not too much chance to get that working, not without at least seeing a screenshot of the Game Menu showing the title. But I suspect Contra 3 has been some rare semi-official prototype (with INST ROM instructions "to be announced"), so it might be impossible to find somebody who actually owns the real cartridge. Aside from Contra 3, the other 11 games are having fully-featured INST ROMs and are looking like authentic original games to me. Amazing Tennis is a bit odd as it has GameID FFh (the others are numbered 00h and up). Making unlicensed games or bootlegs with real working INST ROMs should be more or less impossible. Well, almost impossible - next no$sns update will include a tool for doing that; but it took me 3 weeks to get there. It'll be working without decryption PROMs - so it should be still easy to separate between original and homebrew cartridges.
Top

Memblers	Post subject: Posted: Thu Jul 19, 2012 9:25 pm
Site Admin Joined: Mon Sep 20, 2004 6:04 am Posts: 3273 Location: Indianapolis	I had a chance to get an NSS cabinet (with no boards tho) for cheap, kinda kicking myself for passing on that deal. But I've been thinking of finding an NSS board eventually, since it is standard JAMMA. I would be interested in making a game board for it, so your research really helps towards that. Sorry I don't have anything to contribute as far as NSS info, but I am curious how similar/different this is to the Playchoice instructions/protection, if you've looked into it much. I've finished the layout for a Playchoice board, substituting the RP5H01 with a CPLD. I've disassembled the system ROM a little bit, but being a total Z80 newb and examining obfuscated code is a little weird. If you ever look into it sometime, I could use any tips on how it works.
Top

byuu	Post subject: Posted: Thu Jul 19, 2012 11:36 pm
Joined: Mon Mar 27, 2006 5:23 pm Posts: 1147	Here are DIP settings for Addams Family. I wish we had these for all type C games ... doesn't seem anyone else is interested in making the DIP settings easy to configure though, MESS doesn't seem to care either :/ To me, it's the only cool part about the system. The rest is no more exciting than multi-game Nintendo Power cartridges. http://arcarc.xmission.com/Arcade%20by% ... ttings.jpg > What 14 games did you mean? I know only 12 games: Push-Over is advertised as existing here: http://arcarc.xmission.com/Arcade%20by% ... ame-ad.JPG ... but it seems nobody has ever actually seen it? On the screenshot near the bottom, this person is playing Super Copa: http://distritofederal.quebarato.com.mx ... 731AC.html It seems that there are likely 12 games in the US. There are also international releases of games. I have seen a French copy of Super Soccer, complete with a French marquee insert for the cabinet. The ROM itself may be the English version though, I don't know. Not paying what the seller wants for it. > And Type C seems to be quite rare - I've found only one low-res photo of that PCB. Here is NCAA Basketball: http://i.imgur.com/VvjYq.jpg The DIP switches are quite hard to toggle, but there's definitely eight of them. > The one thing visible there is that it has only 8 DIP-switches, so Port 4101h is definitely containing some kind of garbage, no additional switches. I've left it as open bus for now, ActRaiser still plays fine. It's either a mirror of $4100 or nothing at all. I'm more interested now in what happens if you write #$02 to $4016. It seems odd for them to use lines 1 & 3 and not line 2. Random guess: gives extra credit for achieving some goal (eg certain score.) > But I suspect Contra 3 has been some rare semi-official prototype (with INST ROM instructions "to be announced"), so it might be impossible to find somebody who actually owns the real cartridge. I'm wondering about a lot of these games actually. The only ones I've ever actually heard of anyone owning are: Super Mario World Super Tennis F-Zero Super Soccer NCAA Basketball ActRaiser > Well, almost impossible - next no$sns update will include a tool for doing that; but it took me 3 weeks to get there. Great. We can look forward to bootlegs of the harder to find cartridges now, advertised as if they were authentic :P People have already sold bootleg Push-Over carts using the Super Mario World INST ROM.
Top

nocash

Post subject: Posted: Fri Jul 20, 2012 6:36 am

Joined: Fri Feb 24, 2012 12:09 pm Posts: 487

Thanks for the NCCA Basketball PCB picture! That's better resolution than pic I had found. For Push-Over, I've only seen that advert, too. Aside from that, there seems to be nothing hinting that the game does really exist... no photos, no dumps, and nobody claiming to own it. When did you last check the Super Copa link? I only get "Invalid address" whenever clicking there. Playchoice relation would be interesting. I haven't yet looked too deep into the PC10 BIOS. It looks like being made by the same programmer, and the RP5H01 part is quite the same as in NSS - using RST opcodes, and even using the same databits in the E000h-EFFFh R/W area, and spitting out the same 16-byte data (9 bytes plus mirrors/padding). Don't know what the PROM is used for at software side on PC10s... There seems to be a homebrew replacement BIOS that works without PROMs - but I don't know if that BIOS can actually decrypt original games without the PROM ? (Assuming that the PC10 PROMs are containing decryption keys, too). Quote: I've finished the layout for a Playchoice board, substituting the RP5H01 with a CPLD. That sounds interesting. Is that only a layout - or do you already have a RP5H01 clone tested & working on real PC10 hardware? I am wondering what comes out exactly from the DATA and COUNTER OUT pins: COUNTER OUT should output address bit 5. According to the RP5H01 datasheet, the address starts at zero. So I'd expect the pin to output 32 "null" bits, then 32 "ones", and so on. But, the signal arriving at the PC10/NSS I/O ports is exactly vice-versa: Starts with 32 "ones", then 32 "nulls". Do you know if that inversion takes place in the RP5H01 chip? Or is it inverted on the PC10 mainboard? DATA arrives at the PC10/NSS I/O ports as how it is stored in the pc10/mame "security.prm" files (aside from the wrong bit-order; storing bit0 (the first bit) in bit7 of the first byte of the file is total nonsense - it doesn't match up with the datasheet, nor with the BIOS functions, nor with the text/letters contained in the PROM). Anyways, what I wanted to say was: The "null" bits in the .prm file arrive as "null" bits in the I/O ports. But I am wondering if that is really correct (inverted COUNTER OUT and un-inverted DATA looks like a odd combination). Do you know if the security.prm files are containing bits exactly as seen on the DATA pin? Ie. the "padding bytes" are FFh? Or could it be vice-versa, padding 00h? PAGE 2:: Author Message nocash wrote: Don't know what the PROM is used for at software side on PC10s... There seems to be a homebrew replacement BIOS that works without PROMs - but I don't know if that BIOS can actually decrypt original games without the PROM ? (Assuming that the PC10 PROMs are containing decryption keys, too). It can't, the replacement BIOS does one of 2 things - reads the game name in plain ASCII out of the instruction ROM (generated with a Windows program) - or if the instruction ROM isn't present, the user can manually edit the name with the Playchoice, and that gets stored into book-keeping RAM (not battery backed, but is backed up with a big fat capacitor). I actually was hoping to maybe create a BIOS hack myself, it's not as big of a priority though as getting my game boards to work with the stock code though. I hoped to make it so there is still an attract mode while it's in freeplay, and also so it can display name/instructions regardless of the PROM (of course with a customized instruction ROM per game), while hopefully still being able to read original boards as usual. Quote: Quote: I've finished the layout for a Playchoice board, substituting the RP5H01 with a CPLD. That sounds interesting. Is that only a layout - or do you already have a RP5H01 clone tested & working on real PC10 hardware? I am wondering what comes out exactly from the DATA and COUNTER OUT pins: Just a layout right now, I'm about to order proto boards this weekend, and the Verilog is done (in theory). I just looked at the PC10 schematics (on sheet F), I didn't notice this before, but sure enough, the DATA and COUNTER OUT pins are both inverted on the PC10 mainboard. Top     byuu  Post subject: Posted: Fri Jul 20, 2012 9:43 pm  Joined: Mon Mar 27, 2006 5:23 pm Posts: 1147 nocash wrote: When did you last check the Super Copa link? I only get "Invalid address" whenever clicking there. It's your ISP. Probably doesn't recognize the .mx TLD. (the board on the left isn't the one connected to the TV, the page has a real NSS board pictured.) You can definitely tell it's in Mexico from the cross reflected on the TV :P Either someone else also cracked the INST ROM encryption, or there are more carts out there from other regions. Top     nocash  Post subject: Posted: Sat Jul 21, 2012 6:20 am  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 I get the page header and footer of the mexican page. In the page body it's saying invalid address and sth about trying to access googleads with flash9 - which maybe means needing windows xp to view that page. Moment, just tried via a remote desktop virtual winxp machine - now I see it! That's a funny hardware config, the small PCB is a SNES to NSS adaptor, without games on it, but apparently with PROM and INST-ROM ripped from that "Super Copa" game. That, just to satisfy the BIOS (which won't boot the SNES/PRG ROM if it can't decrypt the INST-ROM). If Super Copa is dubious, then that hack is double-dubious. But, http://www.snescentral.com/article.php?id=0791 sounds as if Super Copa was a legit localized game - from same company as the NSS basketball game. Quite possible that Super Copa for NSS did also exist as licensed title. Quote: I just looked at the PC10 schematics (on sheet F), I didn't notice this before, but sure enough, the DATA and COUNTER OUT pins are both inverted on the PC10 mainboard. There is a PC10 schematic? Good that you mention that! Ah, yes, found it. Will be very useful if I do something with the PC10, and may be also useful for getting an idea how the NSS works. Yup, the DATA and COUNTER pins are inverted and then passed straight to the Z80 databus. Then the "security.prm" files are both bit-reversed and bit-inverted. Ie. the .prm files contain 0 and 1 as seen by the Z80, but not as how they are actually stored in the PROM (aka, in your CPLD PROM-clone). Top     nocash  Post subject: Posted: Mon Jul 23, 2012 2:07 pm  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 Got the test program finished - http://nocash.emubase.de/nss-test.zip - if I got the I/O ports initialized okay, thne the test menu should show up right after just removing the BIOS from mainboard and replacing it by the test program. Though I am afraid that chances to find a NSS owner with EPROM burner are near zero - if you have that hardware, or know somebody who does, please give it a try. Screenshots/photos of the test results would be great! The test features are viewing the whole OSD charset, the OSD color attributes, X/Y display start offsets, measuring timings, testing joypad & front panel inputs, dumping I/O ports, viewing INST ROM titles and checksums, and dumping outputs from the PROM chips. The latter feature should also reveal why the 5 games aren't working. My current theory is that those 5 carts don't use RP5H01 chips, but some other slightly different chips; with 2bit databus, or counter out mapped to another address line, or some other simple trivial detail... but without seeing the test results, it's beating me, I am giving up on that 5 games. Top     nocash  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Tue Aug 14, 2012 3:51 pm  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 Got the NSS specs finished as far as possible: http://nocash.emubase.de/fullsnes.htm (in the Hotel Boxes and Arcade Machines chapter). The NSS is also emulated in no$sns v1.3. Some basic notes on the required BIOS and Cartridge ROM-Image format are here: http://nocash.emubase.de/snsnotes.htm#emulationfiles the required PROM keys can be found here http://nocash.emubase.de/nss-keys.zip (still only for 7 of 12 games) the PRG ROMs and INST ROMs can be dumped with standard EPROM burners and can be eventually found on "MAME" webpages - but careful: The PRG ROMs should be 512Kbytes (per chip). If they are 256K or 1024K then they under/overdumped. The character set that I am currently using for the OSD layer emulation looks as crap - the tool for dumping the real character set is still here http://nocash.emubase.de/nss-test.zip waiting for somebody to give it a try. PS. And here's a NSS version of Magic Floor - should be the first homebrew NSS game released ever. The graphics are very minimalistic - but the thing includes a full INST ROM with title, instructions, skill mode, and dip switches. Source code is also included (the .nss_directives are supported by the built-in assembler in no$sns 1.3). Top     DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Wed Oct 17, 2012 8:34 pm  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 I just came across this thread... nice work! I looked into a lot of the technical details on the NSS a couple years ago, but got sidetracked. I wrote an app for a microcontroller to dump the security PROMs of the carts I have. I also cut the traces to the OSD chip and programmed the microcontroller to dump the character set of the OSD chip. I had a conversation with Kale over at the bannister.org forums, and sent him this stuff... I think they were supposed to get rolled into the MAME/MESS stuff, but I dunno whether they ever did. I also built an adapter to run an SNES cart on the NSS, but ran into a problem that caused DSP-1 games to have goofy Mode 7 graphics. I hope to get back to this project one of these days. Anyway, I've probably forgotten half of what I knew, but from my notes, here are the keys that I dumped from Super Tennis, F-Zero, and Super Mario World. Super Tennis: 61ED71BD2EC5766A F-Zero: 92C65FC0ADFB6FE8 Super Mario World: 752B1538375BB157 I see my F-Zero is different than what you got... I watched mine on a logic analyzer as the game ran, and then verified by dumping with the MCU. Is it possible that some other operation gets done do this data before it gets used? Also, why are your keys 128 bits? I'm almost certain they should be 64 bits... the RP5H01 is 64 bits, and 64 bits go on the wire (read a couple times IIRC). >Though I am afraid that chances to find a NSS owner with EPROM burner are near zero Definitely non-zero. If I get a chance, I'll try the ROM in the next couple days and let you know how it goes. A zip of the font is attached... there's a text and binary version. Basically, each 2 bytes is one 12 pixel line with 4 bits of padding (because making it 12 bit aligned would be goofy). The font is 18 pixels tall, so the first 18*2 bytes is the first character, and so on. DogP Attachments: font.zip [2.74 KiB] Downloaded 116 times Top     nocash  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Sat Oct 20, 2012 12:10 pm  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 Hi, DogP Glad to hear from you! Tried to contact you about the NSS via email a while ago (but comcast spam filter is rejecting any emails from freemail providers). Quote: Super Tennis: 61ED71BD2EC5766A F-Zero: 92C65FC0ADFB6FE8 Super Mario World: 752B1538375BB157 Cool. I'll check the two new keys later tonight, maybe I'll figure out how to get the games working. The F-Zero key looks same as mine (you've the bit-order opposite as in the datasheet, and opposite as how the NSS BIOS reads) (ie. bit7 <--> bit0 swapped). The RP5H01 is 64bit plus 8bit = 72bit in total. According to the datasheet the extra 8bit is for testing. But it can be also used as general purpose storage; the NSS bios is using that extra 8bit, so that value is very important, too. During reading (when test mode is on), the datastream repeats the extra 8bit value a bunch of time (and inserts some 00h bytes), which is what you can see in the 128bit dumps (and after 128bits it restarts from the begin). When test mode is off, it restarts after 64bits. Quote: A zip of the font is attached... there's a text and binary version. Basically, each 2 bytes is one 12 pixel line with 4 bits of padding Yipieh! And it's even digitally dumped directly from the OSD pins? I was only hoping to get hold of a screenshot someday, and then to try to extract the bits from the picture. With the character-zoom feature that might have worked, but it'd have been complicated and not the best approach. Direct dump is much better! I'll try it in my emu later tonight, too. Basically I'll need to rename "font.bin" the "nss-char.bin", and, swap each two bytes - then it should be working. Quote: If I get a chance, I'll try the ROM in the next couple days and let you know how it goes. That would be wonderful! For the font-dumping it seems to be no longer needed. But it's also containing a bunch of other tests, for the OSD attributes and I/O bits and such things; seeing the results would be interesting. I hope the test will work on real hardware. Quote: I also built an adapter to run an SNES cart on the NSS, but ran into a problem that caused DSP-1 games to have goofy Mode 7 graphics. Odd effect. That problem happens only when using BOTH mode-7 AND dsp-1? If it's a general dsp-1 problem (not mode7 related), maybe there too many components connected to the bus, or the dsp-1 chipselect isn't okay, maybe unplugging the other 2 game cartridges may help... just some ideas. Cu, Martin Top     DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Sat Oct 20, 2012 6:21 pm  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 nocash wrote: Hi, DogP Glad to hear from you! Tried to contact you about the NSS via email a while ago (but comcast spam filter is rejecting any emails from freemail providers). Oops, I don't have Comcast anymore, so I probably have one (or lots) of links that point to the wrong email. nocash wrote: Cool. I'll check the two new keys later tonight, maybe I'll figure out how to get the games working. The F-Zero key looks same as mine (you've the bit-order opposite as in the datasheet, and opposite as how the NSS BIOS reads) (ie. bit7 <--> bit0 swapped). Ah, I see that now. Not that it really matters, but I'm not sure that I've got it different than the RP5H01 datasheet though. "The first bit can be read out by adding reset pulse after /CE/Vpp=VIL. The 2nd bit ~ 64th bit can be sequencially read out by adding data clock pulse". I don't think there's anything about it reversing the bit order of the bytes stored (doesn't really make sense for a serial PROM), though it makes sense that the NSS probably brings it into an 8-bit shift register serially, and apparently shifting left (first bit in becomes MSb). nocash wrote: According to the datasheet the extra 8bit is for testing. But it can be also used as general purpose storage; the NSS bios is using that extra 8bit, so that value is very important, too. Oh, I didn't realize that it actually used the test bits for anything. And actually, when I was watching it on the logic analyzer, I never saw it read them. But I can modify the MCU dumping app to read those bits and redump them if you need them. This was the stream of Super Tennis on the logic analyzer, which is just the 64 bits repeated about 2.5 times: (0)011000011110110101110001101111010010111011000101011101100110101001100001111011010111000110111101001011101100010101110110011010100110000111101101011100011011(1) Maybe that's a clue to why your method wasn't working on those games? I don't have notes on F-Zero on the logic analyzer... maybe it did read the test bits? nocash wrote: Yipieh! And it's even digitally dumped directly from the OSD pins? Heh, no... I thought about the various ways to do it, and the font scaling, take picture, hand copy is the approach I took. Attachment: DSCF2842.JPG [ 57.83 KiB | Viewed 4975 times ] It took a few hours (128 12x18 chars), and a very careful eye, but I figured it was less time than it'd take to even make the hardware to read the image, and then I'd have to write the software to actually read the font. Or I could have gotten that Scanning Electron Microscope that I've always been wanting. nocash wrote: That would be wonderful! For the font-dumping it seems to be no longer needed. But it's also containing a bunch of other tests, for the OSD attributes and I/O bits and such things; seeing the results would be interesting. I hope the test will work on real hardware. I can't really get to my NSS cab right now, but I have a JAMMA test bench that I'll try it on. I'll let you know, hopefully this weekend. nocash wrote: Odd effect. That problem happens only when using BOTH mode-7 AND dsp-1? If it's a general dsp-1 problem (not mode7 related), maybe there too many components connected to the bus, or the dsp-1 chipselect isn't okay, maybe unplugging the other 2 game cartridges may help... just some ideas. Unfortunately I didn't take notes on this... I'm pretty sure it was a DSP-1 problem, but I don't remember what I did to verify that. Basically, Mario Kart and Pilot Wings both had normal looking foreground stuff, but the Mode 7 stuff was garbled. I think I tried a different Mode 7 game (without DSP-1), and it worked, and I want to say I tried a DSP-1 game without Mode 7 and it worked. But I could be mistaken on that. What I do remember is that it changed depending on the cart. I popped in an original Mario Kart, and it looked horrible, but then I loaded Mario Kart on my SNES PowerPak, and it was less bad (but still not right). I didn't have any other carts in the slots, but the cables on my adapter connecting the SNES cart to the NSS cart are a little bit long (6 inches, maybe), so I'm wondering if that's my problem. Oddly, lots of other goofy games work (Star Fox, Stunt Race FX, Super Gameboy, etc). Mega Man X2 and X3 didn't, but I think that's because there's no CIC (which IIRC, the CX4 requires). DogP Top     nocash  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Sat Oct 20, 2012 8:26 pm  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 Quote: the NSS probably brings it into an 8-bit shift register serially, and apparently shifting left (first bit in becomes MSb). It's shifted bit-by-bit by software, the other way around: right-shifted, so first bit becomes bit0. Datasheet also says that first bit is something like "bit0" or "address 0" or the like. Quote: This was the stream of Super Tennis on the logic analyzer, which is just the 64 bits repeated The NSS can toggle test mode by software. And it's reading the PROM data a couple of times, in some cases with test mode on, in other cases off. So you probably got the "off" case there. For F-Zero I am sure that test mode can be enabled. For Super Tennis I am not sure, maybe it's wired differently, with Test pin GNDed or so. Haven't yet experimented with your Super Tennis values - but with them, I guess I'll get the game working, even if there are some odd secrets like Test pin or CounterOut pin wired to GND. Converted the font file to gif (I guess you have something similar, too), but anyways, here it is... Attachment: nss-char.gif [ 3.59 KiB | Viewed 4961 times ] Quite different as in the M50458-001SP datasheet. The graphics symbols are all changed, zero isn't slashed, and some punctuation marks are added/moved/removed. Good to know that! For the latter ones I'll need to fix some debug/assembler functions. And here's the nss-char.bin file Attachment: nss-char.zip [1.19 KiB] Downloaded 179 times with 16bit values in little-endian for use with no$sns... Hmmmmm. loading the font into no$sns v1.3 looks like crap :-) because of how I've been resizing it to match with the SNES screen resolution. Next version will look slightly better (with gaps between the characters). For perfect emulation one would need to resample it somehow and draw semi-transparent pixels on the font-edges, which is maybe not really worth doing it. Do you have more of the font screenshots, like the DSCF2842.JPG file? Would be neat to see them, too. EDIT: There's really no exclamation mark? The datasheet for the other chip has it at chr(3Fh) ... if you clipped the font two sets of 3 pages of 7x3 characters ... then you might have lost 3Fh (?) Quote: Basically, Mario Kart and Pilot Wings both had normal looking foreground stuff, but the Mode 7 stuff was garbled. Maybe timing problem. Some games use 2.68MHz access rate, faster ones 3.58MHz. Don't know which of the games you mentioned use which speed, but maybe they are all using the faster variant. Then replacing 74LSxxx gates by 74HCxxx might help, or using faster ROMs/EPROMs. Or maybe it's actually the cable-length, though mere 6 inches doesn't sound too long. Top     DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Sat Oct 20, 2012 11:42 pm  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 nocash wrote: It's shifted bit-by-bit by software, the other way around: right-shifted, so first bit becomes bit0. Datasheet also says that first bit is something like "bit0" or "address 0" or the like. Oh, yes... looking at my notes, I said Super Tennis should actually be: 566EA374BD8EB786 (serial read LSb first), but then wrote my dumping software as if it was reading it MSb first. And in your case, you're saying F-Zero is: 17F6DFB503FA6349, with 0000B7B70000B7B7 being the upper (test) bits, which I agree with (sorry... long day ). And that means SMW should be EA8DDAEC1CA8D4AE. nocash wrote: The NSS can toggle test mode by software. And it's reading the PROM data a couple of times, in some cases with test mode on, in other cases off. So you probably got the "off" case there. For F-Zero I am sure that test mode can be enabled. For Super Tennis I am not sure, maybe it's wired differently, with Test pin GNDed or so. Haven't yet experimented with your Super Tennis values - but with them, I guess I'll get the game working, even if there are some odd secrets like Test pin or CounterOut pin wired to GND. On Super Tennis, I'm fairly certain it was consistently not toggled (at least at boot, maybe I didn't check when accessing instructions), but I don't think it's grounded on the cart. When I didn't know what the chip was, I probed it w/ the logic analyzer, and have a note that it was high when I ran it without the INST EPROM (and the game said "NON SLOT"). I can check when I go to check the other stuff. nocash wrote: Hmmmmm. loading the font into no$sns v1.3 looks like crap because of how I've been resizing it to match with the SNES screen resolution. Next version will look slightly better (with gaps between the characters). For perfect emulation one would need to resample it somehow and draw semi-transparent pixels on the font-edges, which is maybe not really worth doing it. Heh, yeah... mixing analog video has a funny way of making pixel sizes not consistent. nocash wrote: Do you have more of the font screenshots, like the DSCF2842.JPG file? Would be neat to see them, too. EDIT: There's really no exclamation mark? The datasheet for the other chip has it at chr(3Fh) ... if you clipped the font two sets of 3 pages of 7x3 characters ... then you might have lost 3Fh (?) Yeah, all the original images are attached... there's no '!'. I did 21 characters per screen, and on the last file, you see the font roll back over at 128. You can see a couple characters going off the edge of the edge of the screen on a couple images... those were just left over from writes to that character position that I didn't overwrite (since I didn't care what was there, because the large scale mostly pushed them off the screen). nocash wrote: Maybe timing problem. Some games use 2.68MHz access rate, faster ones 3.58MHz. Don't know which of the games you mentioned use which speed, but maybe they are all using the faster variant. Then replacing 74LSxxx gates by 74HCxxx might help, or using faster ROMs/EPROMs. Or maybe it's actually the cable-length, though mere 6 inches doesn't sound too long. I don't think it should be a speed thing though... I imagine there's more games that use the high speed than Pilotwings and Mario Kart (I have tried quite a few games, and those are the only two that I can remember failing in that way). And I was using actual cartridges, so it shouldn't be a ROM/EPROM speed. And about the cable length... I'm not thinking it's the actual length of the cable causing timing skew or anything... but if anything, it's either crosstalk, or added inductance caused by the 6 inches of ribbon cable. I have seen strange problems caused by cable length, and a lot of times I'm surprised it even works at all after looking at it on an oscope. And I've heard of problems from people trying to make Sega Neptune-like systems (Genesis+32x, usually in a Genesis Model 2 case) that using more than a few inches of ribbon cable for the cartrdge connector will cause problems with certain games, but not others. If I was motivated, I'd just cut these cables shorter and try it to eliminate that possibility. The only other goofy things I can remember were the CX4 games not working (assume they need a CIC), and the SuperFX chips were a little bit sensitive about the +5V (would get some glitchy lines if the +5V was <4.95V). DogP Attachments: font_imgs.zip [407.08 KiB] Downloaded 93 times Top     DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Sun Oct 21, 2012 12:48 am  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 Hmm... so I tried your nss-test.bin, but it just gives me a black screen. :/ It's supposed to go in place of the BIOS EPROM, right? I tried two different EPROMs (both verified correctly), just to make sure. Are there any requirements (i.e. cartridge in the slot, test switch, press a button, etc)? I'm running it in my JAMMA testbench, not the cabinet... but that shouldn't really matter (the real BIOS and games work). Anything useful that I can probe to tell you more about what it's doing? And yes, the PROM test pin is not tied to any rail. I'll fix my dumping program to correct the bit order, and add the dumping of the test bits. Oh, and for fun, here's a screenshot of Mario Kart on the NSS... pretty weird: Attachment: DSCF3861.JPG [ 73.1 KiB | Viewed 4947 times ] DogP Top     nocash  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Sun Oct 21, 2012 9:58 am  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 The mariokart problem looks familar. On my SNES I am getting a dozen of scanlines with continous mode 7 scroll offsets, and then some more dozens with completely different offsets. That, both in the same screen half - ie. normally the screen should be split into two halves, but mine looks more like split into four quarters. It's a bit more stable than in your screenshot, but still unplayable. The reason here is probably the http://nocash.emubase.de/fullsnes.htm#s ... adwramboot mod that I've wired to the SNES mainboard. With other games it's working fine, even with the 1.5 meters parallel port cable attached to the SNES databus. Just tried some things: removing the SRAM chip, unplugging the 1.5m cable, replacing the four 74LS chips by 74HC ones - none of that did change the problem. The wiring from SNES mainboard to my 74xx chips is maybe 10-15 centimeters long, maybe it's really the wires causing the problem. Or some other obscure electro smog thing; I've no shielding on the SNES mainboard, no shielding on my PC, and use 5V from my PC as power-supply for the SNES. Quote: Hmm... so I tried your nss-test.bin, but it just gives me a black screen. How nasty. Yes, just plug into the BIOS socket on mainboard, best using a 27C512 eprom. There should be no special things needed, cartridge inserted should be don't care, and buttons should be don't caree as well - unless you hold down joypad buttons forever - then it'd hang waiting for them getting released, but I guess you didn't do that :-) Well then... either I didn't initialize the OSD chip correctly, or it's some more basic thing like maybe the Z80 being continously reset by a watchdog; if it's that then you might see that on the Z80 reset pin. Do you have the four LEDs connected on your NSS board? Then I could make some LED blink test program, just to see if the Z80 code is alive and working. How did you get the OSD chip to display the charset? Via the Z80 CPU, or via something else? And do you have a datasheet or some sample code for the OSD chip? I didn't find any datasheet there. And aside from the internal OSD registers, the connection to the Z80 is rather unclear to me, too. OSD and RTC are somehow controlled via Port 02h/82h/72h/EAh.W but it's hard to see which bit has which purpose, and if the four port addresses behave different, or if they are all the same. Quote: I'll fix my dumping program to correct the bit order, and add the dumping of the test bits. Would be great! Can you also check if the Super Tennis PROM is wired to same pins as in F-Zero? And maybe also dump the CounterOut output the same way as the Data output? On F-Zero it should output just 32 zeroes, then 32 ones, and so on. If Super Tennis isn't doing that then it'd explain my problems. Though hard to believe that Nintendo used some different chip than the RP5H01 on some carts - maybe I just made a very silly mistake somewhere. Btw. the CRC32 for the 32Kbyte Super Tennis INST ROM is 8880596E, correct? Oh, one thing I was wondering about: The 32Kbyte INST ROM is mapped to a 8Kbyte memory space on Z80 side. Do you know if the extra 24Kbytes are accessible? Or are the upper INST ROM address lines just wired to VCC? Top     DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Sun Oct 21, 2012 7:19 pm  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 nocash wrote: The mariokart problem looks familar. On my SNES I am getting a dozen of scanlines with continous mode 7 scroll offsets, and then some more dozens with completely different offsets. That, both in the same screen half - ie. normally the screen should be split into two halves, but mine looks more like split into four quarters. It's a bit more stable than in your screenshot, but still unplayable. The reason here is probably the http://nocash.emubase.de/fullsnes.htm#s ... adwramboot mod that I've wired to the SNES mainboard. With other games it's working fine, even with the 1.5 meters parallel port cable attached to the SNES databus. Just tried some things: removing the SRAM chip, unplugging the 1.5m cable, replacing the four 74LS chips by 74HC ones - none of that did change the problem. Interesting... I'm gonna try to shorten that cable soon... it's been a nagging bug for a couple years, and that's really the only logical thing I can come up with. Oh, and it's not only a graphical problem... it drives off the track and Lakitu picks me up and has a hard time figuring out where to drop me. And IIRC, Pilotwings goes into a crazy nosedive and eventually crashes. nocash wrote: How nasty. Yes, just plug into the BIOS socket on mainboard, best using a 27C512 eprom. There should be no special things needed, cartridge inserted should be don't care, and buttons should be don't caree as well - unless you hold down joypad buttons forever - then it'd hang waiting for them getting released, but I guess you didn't do that Well then... either I didn't initialize the OSD chip correctly, or it's some more basic thing like maybe the Z80 being continously reset by a watchdog; if it's that then you might see that on the Z80 reset pin. I assume you mean a 27C256? That's what I'm using (the file is 32KB), and that's the chip used for the BIOS. I'll check the reset pin for the watchdog, and if I get a chance, I'll hook up the logic analyzer and see where it's running. I'm not holding any buttons, though it's possible that there's an input floating, if the cab would normally pull it up externally or something. nocash wrote: Do you have the four LEDs connected on your NSS board? Then I could make some LED blink test program, just to see if the Z80 code is alive and working. I don't have any LEDs hooked up, but I have a logic probe on the bench that I could touch to the pins to show high or low. nocash wrote: How did you get the OSD chip to display the charset? Via the Z80 CPU, or via something else? And do you have a datasheet or some sample code for the OSD chip? I didn't find any datasheet there. And aside from the internal OSD registers, the connection to the Z80 is rather unclear to me, too. OSD and RTC are somehow controlled via Port 02h/82h/72h/EAh.W but it's hard to see which bit has which purpose, and if the four port addresses behave different, or if they are all the same. I cut the pins to the OSD and connected my own MCU. It's basically just SPI IIRC. I forget where I found the datasheet, but it's attached to this post in case you don't already have it. nocash wrote: Can you also check if the Super Tennis PROM is wired to same pins as in F-Zero? And maybe also dump the CounterOut output the same way as the Data output? On F-Zero it should output just 32 zeroes, then 32 ones, and so on. If Super Tennis isn't doing that then it'd explain my problems. Though hard to believe that Nintendo used some different chip than the RP5H01 on some carts - maybe I just made a very silly mistake somewhere. Btw. the CRC32 for the 32Kbyte Super Tennis INST ROM is 8880596E, correct? Yep... will do. My notes on Super Tennis show the Counter Out low for 32, high for 32, and so on... but I'll add that into my dumping code just to verify. And yeah... I just redumped the INST EPROMs... Super Tennis is 8880596E, and Mario World is F2C5466E. nocash wrote: Oh, one thing I was wondering about: The 32Kbyte INST ROM is mapped to a 8Kbyte memory space on Z80 side. Do you know if the extra 24Kbytes are accessible? Or are the upper INST ROM address lines just wired to VCC? A13 and A14 are connected to VCC, so yeah... there's only 8K available. They must have gotten a better deal on the 27C256s than 27C64s. DogP Attachments: m50458.pdf [737.68 KiB] Downloaded 108 times Top     DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Mon Oct 22, 2012 1:04 am  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 Okay... I got the dumper code modified to dump the test bits, and redumped the PROMs. The results are below. Super Tennis: 00009F9F00009F9F 566EA374BD8EB786 F-Zero: 0000B7B70000B7B7 17F6DFB503FA6349 Super Mario World: 00007D7D00007D7D EA8DDAEC1CA8D4AE And yes, the counter bits do function the same between all three (my code actually already checked it, and threw an error if the count bit didn't act as expected). I also checked your test app... it's not watchdogging, but I didn't get a chance to connect the logic analyzer to check where it's running. If that'd be helpful, I'll try to get to it tomorrow. Also, regarding the difference between the hardware of the games (cart/chips)... I don't think that's the case here. I swapped the INST ROM, PRG ROM, and PROM between Super Mario World (ROM-A cart) and F-Zero (ROM-B cart), and they both were correctly identified, and both played without a problem (except F-Zero of course won't save anything w/o battery backed RAM). DogP Top     nocash  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Mon Oct 22, 2012 8:47 am  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 Quote: I assume you mean a 27C256? That's what I'm using (the file is 32KB) I'm not holding any buttons, though it's possible that there's an input floating Yes, 27C256, not 27C512, sorry. Don't think that buttons are a problem; they are probably having pull-ups on the mainboard, so they act as not pressed. And the test program only checks joypad buttons (no special service buttons or so). Quote: I forget where I found the datasheet, but it's attached to this post in case you don't already have it. Cool. I've searched everywhere and couldn't find scans. Only found 2 docs that mentioned the datasheet to exist (on paper presumably). Many thanks! Then I can remove dozens of questions marks in the fullsnes.htm specs & in the OSD emulation. Quote: I swapped the INST ROM, PRG ROM, and PROM between Super Mario World (ROM-A cart) and F-Zero (ROM-B cart), and they both were correctly identified Good idea. Then the PROMs must be wired the same way. And CounterOut is same as normal (thanks for checking that, too). Looks more and more as if there is no special hardware, and I just made some basic mistake on the non-working games. Quote: Super Tennis: 00009F9F00009F9F 566EA374BD8EB786 F-Zero: 0000B7B70000B7B7 17F6DFB503FA6349 Super Mario World: 00007D7D00007D7D EA8DDAEC1CA8D4AE Thanks! Tried the Super Tennis values in my emu - didn't work - produced a checksum error right after the first decryption pass :-/ And here comes my stupid mistake: All working PROMs have a "1" in the first bit. The non-working PROMs are having a "0" in that place. Looking back, it's quite obvious & eye-catching. I did even extract the first 8 bytes of the Contra/Robocop/SuperSoccer PROM-data from (supposed) copies in INST ROM, and they all had "0" as first bit, too. But I've somehow completely missed that detail :-) Without your help, I would have NEVER noticed it. Many-many-many thanks for the PROM dumps and confirming CounterOut and Pin-outs!!! And the thing that happens on "0" as first bit is this: The decryption code is generating a 1-to-0 CLK transition at SAME time as when releasing RESET. I suspect the PROM manufacturer would treat that as invalid/unstable operation - but it does apparently work stable: The PROM is ignoring the CLK edge in that case. Having that emulated, Super Tennis is now working fine. And the other four games will be probably working the same way, too. Quote: A13 and A14 are connected to VCC, so yeah... there's only 8K available. Good to know! Quote: I also checked your test app... it's not watchdogging, but I didn't get a chance to connect the logic analyzer to check where it's running. If that'd be helpful, I'll try to get to it tomorrow. Looking at the OSD SPI-bus might be good thing to start with. I've tried to program it same as in original BIOS, but maybe I missed the chipselect or something like that. You can see what I am trying to do in the "nss-test.a22" source code file (starting with the "reset_cont_d" function). Some of the outcommented lines are relicts from the SFC-Box version (that's also having a OSD chip, but it's accessed differently and has nothing to do with the NSS - so just ignore the outcommented stuff). I'll review the test source code against the M50458 datasheet - maybe I just didn't set an important display enable bit. Author Message DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Tue Oct 23, 2012 1:32 am  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 nocash wrote: Many-many-many thanks for the PROM dumps and confirming CounterOut and Pin-outs!!! No prob... glad you were able to get it figured out! nocash wrote: Looking at the OSD SPI-bus might be good thing to start with. I've tried to program it same as in original BIOS, but maybe I missed the chipselect or something like that. I didn't decode the bits, but all three SPI pins show activity on the logic probe at boot, so I think your code is running. I can hook up the logic analyzer tomorrow and check the data you're sending, if you don't find the problem before then. DogP Top     nocash  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Tue Oct 23, 2012 12:20 pm  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 Quote: I didn't decode the bits, but all three SPI pins show activity on the logic probe at boot, so I think your code is running. I can hook up the logic analyzer tomorrow and check the data you're sending, if you don't find the problem before then. Good to know that there is some activity. Logic analyzer test would be neat - maybe it's revealing some obvious bug like wrong chipselect. The OSD control register settings seem to match up with the OSD datasheet, and they are taken from the NSS BIOS anyways, so they should be working. Internal Clock is on, so it should work even if SNES PPU is disabled. The OSC1,OSC2 stuff is stopped - looks a bit suspect, but the NSS BIOS is always doing that, too. One possible problem might be that the program is accessing the OSD chip too soon after reset. The datasheet is mentioning 'something' about 1ms on last page (not quite clear what that means, and how it fits to reset signals that might be generated by the NSS mainboard). Anyways, the OSD chip is re-initialized in each test screen - if you push some of the four joypad direction keys then the program should redo the OSD init far away from the reset signal. There should be also some new activity visible on the OSD SPI bus when pushing joypad DPAD buttons, that might also help to see if the Z80 is running or crashed. --- Here are working PROM dumps for all 12 games: http://nocash.emubase.de/nss-keys.zip - the 5 new keys (with zeroes in first bit) will be working in next no$sns update. Your two new dumps worked find, and for the remaining three games I already guessed the first 8 bytes from INST ROM, and the 9th is usually containing some checksum, so I could calculate the missing value, which worked, too - except for Contra 3, that's using a "wrong" checksum in 9th byte - but I got it deciphered with the brute-force program. NB. Contra 3 is somewhat less than an experimental pre-prototype game, the INST ROM is almost empty, and even the main menu title string just says "New Game 1". There isn't anything contra-specific in INST ROM, and I think also nothing NSS-specific in the PRG ROM. With the dumped font & the datasheet details about things like character sizes and the odd scrolling/wrapping feature, my OSD emulation is now looking much nicer. Many thanks there! Top     nocash  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Tue Oct 23, 2012 5:42 pm  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 Here's the new no$sns version with improved NSS emulation http://nocash.emubase.de/sns.htm (it's currently completely freeware, all versions available with and without donations; I am totally broke so it doesn't matter if I don't get money or not). It's now working with all NSS games via the 12 keys in http://nocash.emubase.de/nss-keys.zip. My homebrew NSS game is also updated, http://nocash.emubase.de/magicflr.htm (with nicer BG graphics, more OSD colors, and lowercase text, and punctuation marks matched to the OSD font). And, my NSS specs in http://nocash.emubase.de/fullsnes.htm are also updated (with info from the OSD datasheet and some other new notes). Top     DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Wed Oct 24, 2012 3:25 am  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 nocash wrote: One possible problem might be that the program is accessing the OSD chip too soon after reset. The datasheet is mentioning 'something' about 1ms on last page (not quite clear what that means, and how it fits to reset signals that might be generated by the NSS mainboard). Anyways, the OSD chip is re-initialized in each test screen - if you push some of the four joypad direction keys then the program should redo the OSD init far away from the reset signal. There should be also some new activity visible on the OSD SPI bus when pushing joypad DPAD buttons, that might also help to see if the Z80 is running or crashed. I didn't have time to hook up the logic analyzer... I'll do that tomorrow night. But I did do the controller test, and it does cause activity on the SPI pins (Left/Right do a lot, Up/Down do just a short blip), but there's still nothing on the screen. So, the code is running, but apparently something isn't quite right. Hopefully the logic analyzer will give us a clue. nocash wrote: With the dumped font & the datasheet details about things like character sizes and the odd scrolling/wrapping feature, my OSD emulation is now looking much nicer. Many thanks there! Cool... glad it helped! DogP Top     nocash  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Wed Oct 24, 2012 7:13 am  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 Quote: it does cause activity on the SPI pins (Left/Right do a lot, Up/Down do just a short blip) Sounds good (up/down just redraws the cursor, and left/right leaves/enters new pages). So overall Z80 code and joypad input seem to be okay. Then the SPI data/clk/select signals are probably wrong. Or there's some Z80 OUT port externally disabling the OSD layer (like externally masking off the RGB signals from P0..P2 pins, or holding the /AC pin in reset state). Top     nocash  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Wed Oct 24, 2012 8:40 am  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 Here's an updated version of the test program - http://nocash.emubase.de/nss-test.zip It's inserting a new OUT [72h],59h prior to the old OUT [72h],C3h chip-selection. The NSS BIOS is doing the same thing. Most of the databits are just cryptic random-garbage, but I think that bit6 is CLK, that might be important to be switched high BEFORE setting chipselect to low (which is probably done via bit4). If that is fixing the OSD output, then I am having a massive problem with initial CLK levels... it's a bit similar to my PROM problem with CLK occuring upon releasing RESET. Top     DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Thu Oct 25, 2012 2:36 am  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 nocash wrote: Here's an updated version of the test program - http://nocash.emubase.de/nss-test.zip Success! Were there any specific tests that you wanted run on hardware? Attachment: DSCF3862.JPG [ 75.02 KiB | Viewed 1940 times ] Attachment: DSCF3863.JPG [ 117.26 KiB | Viewed 1940 times ] DogP Top     nocash  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Fri Oct 26, 2012 3:33 pm  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 Cool. Which tests? The OSD REG 3/7 tests are rather outdated (since having the datasheet). The OSD OFFSET tests might be still interesting (as how I do understand the datasheet, the hori/verti offsets should move the screen in 4pixel/4scanline units, but not absolutely sure if did understood that correct). The TEST SLOTS test was mainly for seeing PROM Data/CounterOut and Title as hexdumps (on the three screens accordingly). That's no longer needed, too. But the Titles in clean-text (not the hex values) would be interesting, to see which slot maps there. If you plug in three cartridges, their titles should appear, probably in same order as how the slots are numbered. Slot selection is done via a 2bit number (hence 4 slots displayed), the last slot might be empty, garbage, or a mirror to another slot. Then 3 register dump screens would be interesting, so see initial values, and mirrors, and what is stored in unused bits and so on. For the CURRent port values, bit6 of the first byte should be "blinking" - don't know if there are more such bits showing activity? SELFTEST is measuring some timings, probably 60Hz vsync or vblank from OSD chip or SNES or so. But, if the values are different as expected (and emulated in no$sns), it might have other timings, not related to 60Hz at all. (Btw. The selftest part is very slow, takes some seconds, sorry). And finally, the JOYPAD/PANEL/COIN screens would be also interesting - but there you might need the whole cabinet, not just the plain mainboard. JOYPADs are of course normally going to the SNES, but of the joypad 6 buttons are also wired to the Z80. The 4 direction keys, and Button A, and (maybe, totally guessed:) Button B. And I don't if it's joypad 1 or 2 (or both) wired to the Z80. Front PANEL should be correctly shown in the test, except, quite possible that I've swapped PageUp and PageDown with each other. COIN/SERVICE should be also as shown. Would be (mildly) interesting if Coin 1 is the Left or Right slot. And aside from the Service button, the official wiring diagram also mentions a Test button - did you ever see that thing? The BIOS doesn't seem to use it at all. If it does exist, then it might show up in the Unknown Bits hexvalue. Cu, Martin Top     DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Tue Oct 30, 2012 3:01 pm  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 nocash wrote: The OSD OFFSET tests might be still interesting (as how I do understand the datasheet, the hori/verti offsets should move the screen in 4pixel/4scanline units, but not absolutely sure if did understood that correct). Here are the first 3: Attachment: DSCF3864.JPG [ 77.41 KiB | Viewed 1814 times ] Attachment: DSCF3865.JPG [ 63.35 KiB | Viewed 1814 times ] Attachment: DSCF3866.JPG [ 58.62 KiB | Viewed 1814 times ] DogP Top     DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Tue Oct 30, 2012 3:10 pm  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 nocash wrote: The OSD OFFSET tests might be still interesting (as how I do understand the datasheet, the hori/verti offsets should move the screen in 4pixel/4scanline units, but not absolutely sure if did understood that correct). And the 4th: Attachment: DSCF3867.JPG [ 60.05 KiB | Viewed 1814 times ] nocash wrote: SELFTEST is measuring some timings, probably 60Hz vsync or vblank from OSD chip or SNES or so. But, if the values are different as expected (and emulated in no$sns), it might have other timings, not related to 60Hz at all. (Btw. The selftest part is very slow, takes some seconds, sorry). Attachment: DSCF3874.JPG [ 72.24 KiB | Viewed 1814 times ] nocash wrote: And finally, the JOYPAD/PANEL/COIN screens would be also interesting - but there you might need the whole cabinet, not just the plain mainboard. JOYPADs are of course normally going to the SNES, but of the joypad 6 buttons are also wired to the Z80. The 4 direction keys, and Button A, and (maybe, totally guessed:) Button B. And I don't if it's joypad 1 or 2 (or both) wired to the Z80. Front PANEL should be correctly shown in the test, except, quite possible that I've swapped PageUp and PageDown with each other. COIN/SERVICE should be also as shown. Would be (mildly) interesting if Coin 1 is the Left or Right slot. And aside from the Service button, the official wiring diagram also mentions a Test button - did you ever see that thing? The BIOS doesn't seem to use it at all. If it does exist, then it might show up in the Unknown Bits hexvalue. I'll try it in the actual cab when I can... but yes, I the cab has a test button, but I remember it (seemingly) not do anything. I think it's just there because it's standard for a JAMMA cabinet to have, and these cabs were made by Dynamo (they build a lot of arcade cabinets... and air hockey tables). The test switch doesn't seem to do anything in your test software (I have a test switch on my testbench, and the unknown bits didn't change). Attachment: DSCF3875.JPG [ 54.1 KiB | Viewed 1814 times ] Top     DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Tue Oct 30, 2012 3:15 pm  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 nocash wrote: The TEST SLOTS test was mainly for seeing PROM Data/CounterOut and Title as hexdumps (on the three screens accordingly). That's no longer needed, too. But the Titles in clean-text (not the hex values) would be interesting, to see which slot maps there. If you plug in three cartridges, their titles should appear, probably in same order as how the slots are numbered. Slot selection is done via a 2bit number (hence 4 slots displayed), the last slot might be empty, garbage, or a mirror to another slot. Yep, they were in order of slot 1, 2, and 3 (Super Mario World was in slot 1). Attachment: DSCF3868.JPG [ 99.75 KiB | Viewed 1812 times ] Attachment: DSCF3869.JPG [ 84.63 KiB | Viewed 1812 times ] Attachment: DSCF3870.JPG [ 99.29 KiB | Viewed 1812 times ] DogP Top     DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Tue Oct 30, 2012 3:21 pm  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 nocash wrote: Then 3 register dump screens would be interesting, so see initial values, and mirrors, and what is stored in unused bits and so on. For the CURRent port values, bit6 of the first byte should be "blinking" - don't know if there are more such bits showing activity? The only activity was on bit 6 of the first byte of some of the rows (a couple of the rows would blink between C0 and 80). Attachment: DSCF3871.JPG [ 81.23 KiB | Viewed 1812 times ] Attachment: DSCF3872.JPG [ 82.64 KiB | Viewed 1812 times ] Attachment: DSCF3873.JPG [ 83.87 KiB | Viewed 1812 times ] DogP Top     DogP  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Wed Oct 31, 2012 12:20 am  Joined: Wed Oct 17, 2012 7:41 pm Posts: 22 Just a misc update... I shortened the cables to my SNES cart adapter by about 4", and it's much better... but still not 100%. Using my original Mario Kart cartridge, there's only a few lines across the screen. On my flash cart, the screen looks perfect, but the game still glitches when you drive. So, I guess I should just finish laying out the PCB and get it made... then see where I'm at. DogP Top     nocash  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Sun Dec 02, 2012 10:20 am  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 Cool, many thanks for running the tests! And sorry about the late reply! Seeing the I/O ports & mirrors is nice. The VBL test does apparently show VSYNC timings (not VBLANK), and with the bit being inverse of what I had guessed. The OFF test disables NMIs (and does show wait-for-NMI timeouts as expected). The NMI test was meant to enable NMIs (but does also run into timeouts, damn) Now I am bit clueless how to enable NMIs... either it requires some strange combination of Port 00h Bit0 and Bit1... maybe enable AND acknowledge or so... or maybe the NMI source is missing... it might be Vblank or Vsync from OSD chip... or fromSNES PPU... or maybe NMIs are triggered by SNES controller reads or whatever. Btw. if somebody wants to modify the Z80 source code of the test proggy: You could assemble that Z80-dialect with the Utility/AssembleFile function from my no$zx emulator. Top     nocash  Post subject: Re: Nintendo Super System (NSS) (Arcade Cabinet) Posted: Tue Dec 25, 2012 5:13 am  Joined: Fri Feb 24, 2012 12:09 pm Posts: 487 DogP has tested the Game/Demo-mode detection being used in the Magic Floor NSS version (http://nocash.emubase.de/magicflr.htm). I have been afraid that it might fail on real hardware.... but, it worked perfectly! The detection works by reading the 17th bit from the serial joypad data, ie. same as the "joypad-connected" detection on normal SNES consoles. On the NSS the bit means "joypad enabled". For a nice arcade-feeling one can use that detection to "autostart when money inserted". A pity that the original NSS games didn't support that feature, but at least they didn't show "no joypad connected error" messages in demo mode - which would have looked really bad. http://retro-repairs.netai.net/nintendo_super_system/font_imgs.rar http://retro-repairs.netai.net/nintendo_super_system/nss_char.rar http://retro-repairs.netai.net/nintendo_super_system/nss_keys.rar  http://retro-repairs.netai.net/nintendo_super_system/nss_dips.rar  http://retro-repairs.netai.net/nintendo_super_system/nss.c_drivers.rar  http://retro-repairs.netai.net/nintendo_super_system/nss_test.rar  ++++++++++++++++++++++++ Mitsubishi M50458-001SP Chip https://octopart.com/m50458-001sp-mitsubishi-15127345