Nintendo Super System (NSS) (Arcade Cabinet)

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic

Nintendo Super System (NSS) (Arcade Cabinet)
by nocash on 2012-07-02 (#96368)

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.

by byuu on 2012-07-02 (#96370)

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.

by nocash on 2012-07-02 (#96374)

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.

by byuu on 2012-07-02 (#96375)

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

by tepples on 2012-07-02 (#96377)

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.

by nocash on 2012-07-02 (#96384)

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.

by byuu on 2012-07-03 (#96402)

> 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

by tepples on 2012-07-03 (#96403)

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.

by byuu on 2012-07-03 (#96430)

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.

by nocash on 2012-07-03 (#96437)

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.

by nocash on 2012-07-12 (#96735)

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).

by nocash on 2012-07-19 (#96927)

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.

by Memblers on 2012-07-19 (#96928)

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.

by byuu on 2012-07-19 (#96933)

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.

by nocash on 2012-07-20 (#96952)

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?

by Memblers on 2012-07-20 (#96983)

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.

by byuu on 2012-07-20 (#96984)

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.

by nocash on 2012-07-21 (#96990)

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).

by nocash on 2012-07-23 (#97064)

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.

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by nocash on 2012-08-14 (#98129)

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).

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-17 (#101375)

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

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by nocash on 2012-10-20 (#101455)

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

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-20 (#101474)

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 8009 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

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by nocash on 2012-10-20 (#101481)

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 7995 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 257 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.

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-20 (#101493)

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

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-21 (#101496)

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 7981 times ]

DogP

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by nocash on 2012-10-21 (#101506)

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?

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-21 (#101538)

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

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-22 (#101544)

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

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by nocash on 2012-10-22 (#101556)

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.

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-23 (#101616)

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

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by nocash on 2012-10-23 (#101637)

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!

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by nocash on 2012-10-23 (#101663)

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).

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-24 (#101686)

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

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by nocash on 2012-10-24 (#101692)

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).

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by nocash on 2012-10-24 (#101694)

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.

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-25 (#101745)

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 3987 times ]

Attachment:

DSCF3863.JPG [ 117.26 KiB | Viewed 3987 times ]

DogP

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by nocash on 2012-10-26 (#101814)

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

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-30 (#102012)

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 3861 times ]

Attachment:

DSCF3865.JPG [ 63.35 KiB | Viewed 3861 times ]

Attachment:

DSCF3866.JPG [ 58.62 KiB | Viewed 3861 times ]

DogP

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-30 (#102013)

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 3861 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 3861 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 3861 times ]

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-30 (#102015)

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 3859 times ]

Attachment:

DSCF3869.JPG [ 84.63 KiB | Viewed 3859 times ]

Attachment:

DSCF3870.JPG [ 99.29 KiB | Viewed 3859 times ]

DogP

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-30 (#102018)

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 3859 times ]

Attachment:

DSCF3872.JPG [ 82.64 KiB | Viewed 3859 times ]

Attachment:

DSCF3873.JPG [ 83.87 KiB | Viewed 3859 times ]

DogP

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by DogP on 2012-10-31 (#102049)

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

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by nocash on 2012-12-02 (#103880)

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.

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by nocash on 2012-12-25 (#105092)

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.

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by darkchao on 2013-09-05 (#117596)

Apologies on reviving a dead thread - I've just acquired an NSS in beautiful shape and have it running with the default carts. I've read through this thread - the progress that you guys have made is incredible. However, I have a few questions. I apologize if they seem noob/have been answered earlier.

- I want to check out Magic Floor on the real hardware, although I'm not sure how to go about splitting an NSS rom so I can put it on an EEPROM. Any advice?
- Does anyone know what a suitable replacement would be for the IC4 chip? Do we even need this anymore or can we bypass it in the PRG ROM?
- I saw that there are some issues with getting MODE7 games running on the NSS, but I would really love to switch out Super Tennis for something better. I need a little direction .

Any advice is appreciated.

Re: Nintendo Super System (NSS) (Arcade Cabinet)
by Markfrizb on 2013-09-05 (#117615)

Hey,
Welcome to the NSS club.
You might be interested in this....
http://m.youtube.com/watch?v=qKbor0zHd00

Pm your email address and I can send you the rom file split, ready to burn.

The roms are the same as regular Snes roms. The host cartridges are all low rom, 1mbyte or smaller games. The f-zero will save your progress if you add a battery (or use the 5 in 1 set up)
It is possible to run hi roms with some re-wiring of the host carts pi outs. I think 8 lines need to be swapped if memory serves. thanks to no-cash, you can edit the instruction file and void the security chip.
Have fun!

Edit: mode 7????

Oh, and you'll definitely want the version 3 bios too.

Below is a pic of the edited menu.