It is currently Thu Dec 14, 2017 3:19 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 47 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject:
PostPosted: Fri Jul 20, 2012 9:21 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3487
Location: Indianapolis
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
 Profile  
 
 Post subject:
PostPosted: Fri Jul 20, 2012 9:43 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
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.

Image
(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
 Profile  
 
 Post subject:
PostPosted: Sat Jul 21, 2012 6:20 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 538
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
 Profile  
 
 Post subject:
PostPosted: Mon Jul 23, 2012 2:07 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 538
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
 Profile  
 
PostPosted: Tue Aug 14, 2012 3:51 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 538
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
 Profile  
 
PostPosted: Wed Oct 17, 2012 8:34 pm 
Offline

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 142 times
Top
 Profile  
 
PostPosted: Sat Oct 20, 2012 12:10 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 538
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
 Profile  
 
PostPosted: Sat Oct 20, 2012 6:21 pm 
Offline

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. :-P

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
DSCF2842.JPG [ 57.83 KiB | Viewed 6160 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
 Profile  
 
PostPosted: Sat Oct 20, 2012 8:26 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 538
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
nss-char.gif [ 3.59 KiB | Viewed 6146 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 213 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
 Profile  
 
PostPosted: Sat Oct 20, 2012 11:42 pm 
Offline

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. :P 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. :P

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. :P 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 114 times
Top
 Profile  
 
PostPosted: Sun Oct 21, 2012 12:48 am 
Offline

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
DSCF3861.JPG [ 73.1 KiB | Viewed 6132 times ]


DogP


Top
 Profile  
 
PostPosted: Sun Oct 21, 2012 9:58 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 538
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
 Profile  
 
PostPosted: Sun Oct 21, 2012 7:19 pm 
Offline

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. :P

DogP


Attachments:
m50458.pdf [737.68 KiB]
Downloaded 145 times
Top
 Profile  
 
PostPosted: Mon Oct 22, 2012 1:04 am 
Offline

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
 Profile  
 
PostPosted: Mon Oct 22, 2012 8:47 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 538
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.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: 93143 and 3 guests


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

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