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