nesdev.org

Posted: **Sat Mar 03, 2012 11:13 am**

PAL16L8 outputs commonly implement S/R and transparent latches, not like the latch in the wiki talk page, but as a multiplexer with feedback since it's more efficient to SOP. You may build a true M-S flip flop from two latches (thus 2 outputs), but it's expensive to implement and isn't sure to work on all chips because of variable propagation so it's not common. If every output in the design drives an external signal, it's unlikely there is any internal state by conventional means.

Posted: **Sun Mar 04, 2012 4:28 am**

Super Famicom Box pcb pictures

Regarding Satellaview information:
This data was gathered by using a memory viewer running on the SNES.
I'm unable to find my Satellaview modem at the moment, so all of the following is from memory:

nocash wrote: > reg (r/w): def description
"def" means initial value on Power-Up (and/or on Reset)?

Default values / values after cold boot, yes.

nocash wrote: > 2188 (r/w): ... 14 bits wide ... reading back $aa,$55.
How can it read-back 55AAh if it's only 14bit wide? Which bits are used/unused? And what are the unused bits, open-bus, or always 0, always 1?

The games I've seen test these values in succession, i.e first $aa, then $55.

nocash wrote: > 2194 (r/w): $00 (4bit)
> bit0 affects bit0 of 2196
> bit2 switches satellaview access light on
> 2196 (r) : $02 bit0 alternates fast if bit 1 of 2194 is set
Okay, with 4bit you mean bit0-3? (existing software uses only that bits), so bit4-7 are always zero, not read/write-able?
Ehhhhm, which bit affects 2196.bit0? "bit0" of 2194 or "bit 1" of 2194?
LED is ON or OFF when setting 2194.bit2?
Software always writes same value to bit2+bit3 of 2196, so my guess was that both are LED related (like givining it more power when both bits set, or switching it from Red to Green on certain values or so). But now, after reading your doc, the Access-LED is solely controlled by bit2? And, just to be sure, the Power-LED isn't software controlled?
> 2195 (r) : $00
That one isn't used by existing software. On hardware it's just always reading zero?[

Don't remember the details.
Will have to check again when I locate my modem.
I was unable to toggle the power-LED, so yes, my assumption is that it's not software controlled.

whicker wrote: 9 - Service Mode (Install mode)

0 - Play any game, no restrictions. There is no option 5 after selecting the game.

1 - Giant Japanese yellow text on blue background saying the equivalent of THE KEY IS ON, please turn the key OFF. (kii ga ON ni natte imasu. kii o OFF ni shite kudasai). It looks like the Super Famicom is generating this text.

2 - After selecting a game, you can now pick option 5 to Try a game (for free) for 2 minutes. Onscreen text counts down time. Warns one minute left, then when almost out of time counts down the seconds. Resets back to the menu. You can still pick option 1 and play freely, but onscreen text does not go away.

3 - Self Check. White text on a blue screen like 1.Controller....Ok, 8.RTC.....OK. Just continues to loop.

4 - Power OFF, Scared me the first time because a relay clicks. If the unit has the optional power outlet (mine does not), I think this is intended to shut off the television set.

Not relevant to emulation, but I thought this might fit here, anywhere:
It appears that there are different keys for different purposes.
For example, the key that came with my machine says "visitor", and the only possible positions you can select with this key are "ON" and "OFF".
Explains why I never got that Kirby intro...

Posted: **Sun Mar 04, 2012 7:53 pm**

I am not familar with PALs, but I think the NOR-gate-flipflop idea should work (see above Talk page). Don't know if it's possible to program that PAL so that the flipflop acts like a "hidden" internal variable. Otherwise, one could program it so that the flipflop state shows up on one of the output pins (and from there it could be fed back into the chip).

You are right that it is possible to make a flip-flop on an unregistered PAL like the 16L8, and this was done on devices like the PLS153 before the registered PAL parts (16R4 series and up) became popular.

However the Tribal Tap PAL isn't programmed to implement the logic needed to make a flip-flop. And, being a 16L8 device we know it doesn't have any internal flip-flops.

So it really has no internal state -- it simply was not programmed in a way to implement any kind of storage.

Maybe there's other versions of the device that are different (just theorizing, not saying that's the case), but at least between the models that guy and I tested our findings were identical.

BTW nocash, it is really great to see you back in the emulation world after so long. Glad all is well!

Posted: **Mon Mar 05, 2012 3:11 am**

Okay, then there's no internal state in the tribal tap's PAL. Thanks kyuusaku & charles for explaining.

The games I've seen test these values in succession, i.e first $aa, then $55.

Sorry, my fault. Thought one of them would go to MSB.

the key that came with my machine says "visitor", and the only possible positions you can select with this key are "ON" and "OFF".

Nice detail, good to know.

I am looking at the sfc-box at the moment. Already reversed most of the I/O ports, though without having the real hardware, it's hard to be sure about the meaning of some bits.
The KROM is nasty: Most of the 64Kbytes are filled with compiled HLL-code; very ugly & inefficient. It looks even worse than the old C64-ports that used compiled 6502-code on home computers with Z80 CPUs.

The major missing detail is the part number of the OSD video controller (should be the huge 28pin SMD chip in rear section of mainboard). The thing is apparently accessed via the HD640's CSI/O serial port, the software seems to be writing character numbers, screen coordinates, and maybe color attributes & other info to it. For the latter stuff, it'd be REALLY nice to know the chip's part number (hoping that there's a datasheet for it).
NB. the KROM doesn't contain a character set, so the charset ROM is probably in the OSD chip, another undumped ROM.
EDIT: Since it's accessed via serial bus... maybe the OSD thing is another smaller chip, not the 28pin one.

4 - Power OFF, Scared me the first time because a relay clicks. If the unit has the optional power outlet (mine does not), I think this is intended to shut off the television set.

By "power outlet" you mean the 4-pin AC OUT 200W MAX connector on rear-side of the power supply? If yes... from what I've seen on photos, there seem to be no signals going from mainboard to power supply - so I'd bet that it isn't possible to control the AC OUT socket by software.
Another idea, maybe the relay is controlling some accept/eject coin mechanics?

Posted: **Mon Mar 05, 2012 2:10 pm**

nocash wrote: The major missing detail is the part number of the OSD video controller (should be the huge 28pin SMD chip in rear section of mainboard). The thing is apparently accessed via the HD640's CSI/O serial port, the software seems to be writing character numbers, screen coordinates, and maybe color attributes & other info to it. For the latter stuff, it'd be REALLY nice to know the chip's part number (hoping that there's a datasheet for it).
NB. the KROM doesn't contain a character set, so the charset ROM is probably in the OSD chip, another undumped ROM.

Are you unable to make out the package part number in the pictures I provided?
It's a Fujitsu MB90082-001.

Posted: **Mon Mar 05, 2012 5:30 pm**

Are you unable to make out the package part number in the pictures I provided?

Ahhh, sorts of... I couldn't make out the pictures. Because... nobody told me to click on "Super Famicom Box pcb pictures" (now I've found it).
Wow, nice pictures! Until today, I did have found 60 sfcbox pictures that didn't show any interesting details. Now there are 3 pics with about all details - thanks!

Haven't found a MB90082 datasheet, but some others
MB90050 - 48pin, 35x16 chars, out of 512 chars
MB90075 - 28pin, 24x12 chars, out of 256 chars
MB90089 - 28pin, 24x12 chars, out of 256 chars
the sfcbox uses 24x12 chars (and of course a 28pin chip), so the latter two datasheets should be useful, except, they don't include pictures of the 256 characters. As far as I understand, the chips can be manufactured with different charsets... though the "-001" suffix does probably indicate that it contains the standard charset; whatever those chars may look like.

Posted: **Tue Mar 06, 2012 2:42 pm**

Dumping the charset would be nice.
I saw a pin labeled test in one of the datasheets.
Surely there's some way to dump/verify the ROM.
No idea if it's worth the effort, though.

If everything else fails, we could resort to hacking KROM1 to display all chars at once and take a picture of that...

Posted: **Wed Mar 07, 2012 11:57 am**

we could resort to hacking KROM1 to display all chars at once and take a picture of that...

Should be best way. And probably easier than to figure out what the /TEST pin does. Seeing a picture of the complete charset would be great. And if the quality isn't good enough to spot pixels... one could enable the double-size mode... or even extract pixels in sync with dotclock from the 3bit-color TTL outputs.

Accessing the OSD chip via a KROM-replacement should work like so (with upper 8bit of all I/O addresses all zero):

Code: Select all

OSD_INIT
  OUT[81h]=00h                    ;osd chip deselect
  OUT[0Ah]=00h                    ;init CSIO
  for i=1 to 4,OUT[81H]=80h,OUT[81H]=00h,next  ;osd wake-up from reset-state

OSD_SEND_BYTE
  set OUT[81H]=80h                ;osd chip select (before EVERY byte)
  set OUT[0BH]=data               ;prepare TX data (8bit, transferred LSB first)
  set OUT[0AH]=10h                ;start TX
  wait until (IN[0Ah] AND 10h)=0  ;wait until TX ready
  set OUT[81h],00h                ;osd chip deselect (after EVERY byte)

Are you familar with Z80 programming & have time to play with the OSD chip?

The KROM1 code uses the commands described in MB90075 datasheet, plus some of the new MB90089 functions (which are more or less undocumented), it doesn't use the three "sprite" commands, but does use one "reserved" command (0Bh). Oh, and I just read that dotclock can be 6-8 MHz, so the horizontal resolution could be anything.

PS. Also important to enable WRAM (else you have ROM in whole 64K address space).

Code: Select all

  OUT[3Ah]=C8h, OUT[38h]=18h, OUT[39h]=18h

That sequence maps 32K ROM at 0-7FFFh, and 32K WRAM at 8000h-FFFFh. Of which, C000h-FFFFh can be used as WRAM (the portion at 8000h-BFFFh is a "save area" with a read/write-protection feature, so accessing that memory may need further I/O).

Posted: **Wed Mar 07, 2012 12:38 pm**

@nocash,

I am so loving it. It makes the emulator look great I must say. Congratulations and keep up the good work. One more thing I would like to ask a question:

Are you continuing to work on No$gba as well as no$sns ? Again, good job and welcome back!

Posted: **Sat Mar 10, 2012 2:03 am**

nocash wrote: Are you familar with Z80 programming & have time to play with the OSD chip?

Would like to, but I am unfortunately seriously lacking time these days...

Posted: **Sat Mar 24, 2012 12:29 am**

I was recently splitting the core opcodes from the SNES register interfaces for the Cx4, so I took a peek at your notes.

It's a shame everyone who works on the chip has to make up their own mnemonics for it. Overload had his own as well. The chip itself is part of the HG51BS family, but Hitachi won't give us the technical manual for the chip to get the official names.

Code: Select all

  7F48h        ?/W  Unknown "toggle" (set to 00h/01h, maybe cache load/on/off?)

This register is "secondary ROM enable". At power-on, it's set to #$00.
For MMX2, there is an 8mbit+4mbit ROM. So at power-on, the last 4mbit returns open bus.
Set it to #$01, and now you can read out the last 4mbit.
It appears to be a very crude anti-dumping trick.

The reason it's not emulated is because of MMX3: MMX3 only has one 16mbit ROM, and this register has no effect on it.

I don't know what the other unknown registers are for.

Code: Select all

  612Eh   movb   ext_dta,[ext_ptr]          ;\these 3 opcodes are used to
  4000h   inc    ext_ptr                    ; read one byte from [ext_ptr],
  1C00h   finish ext_dta                    ;/and to increment ext_ptr by 1

It really doesn't matter how we emulate this to get MMX2/3 running, but I'm fairly confident that 0x4000 is the opcode that reads from the external bus. An inc bus address instruction is inconsistent with the rest of the architecture.

It is an interesting theory to presume the $2e is a reference to one of the built-in special registers. But this requires a further assumption that x1xx in LD references yet another external data register.

The 0x1c00 is confusing no matter how you look at it. I believe it's some sort of HALT-style opcode that waits for the 0x4000 rdbus instruction to complete.

Either way, there's a lot of opcodes MMX2/3 never used.
We have limited ability to execute "new" opcodes by finding 0xfc00 HALT instructions in other locations in the ROM (aside from 208000-range.)
Eg basically execute code/data at 2+ bytes before we see 0x00 0xfc in the ROM, and examine the results on the GPRs.

We can examine time in a bit of a vacuum, eg "how far does Vcounter:Hcounter advance after executing function NN?", but it's too coarse to really get the timing right.

The most troubling behavior is that from the decap, we see there are two 256x16-bit ROM pages. There's some definite caching going on that'll make the chip much slower than the 20MIPS we currently emulate it at.

What I really want is to find someone who can replace the second ROM chip on Rockman X2 with a RAM chip. If anyone can do this, I'm willing to pay at least $100 for the trouble.

Overload apparently made such a cart, but I haven't seen him online in a while.

EDIT: if you ever get bored and want to take a look, Cydrak and I found what appears to be a timer in the ST018, but we can't figure out how and if the game actually uses it. It seems fully playable without it, but maybe you could find something by disassembling the game as only you seem to be best at? :/

Posted: **Sun Apr 01, 2012 8:54 am**

7F48h ... This register is "secondary ROM enable".

That's an unexpected feature. Aside from the anti-dumping effect, it might be intended to R/W-protect SRAM (when using ROM+SRAM instead 2xROM), or to switch addressing for boards with 1 or 2 ROMs.
Are you sure it's controlled by 7F48h? The way how 7F48h is used in software looks entirely different than what you described. For example, in the ROM checksum calculation (at 13FAE0h in Megaman X2), 7F48h is toggled after checksumming every 800h byte block. And, after writing 7F48h, the software seems to wait for a busy-flag.
My conclusion was that it loads the cache (source in program counter register, and destination 0 or 1 in 7F48h (in case of checksumming stuff that wouldn't make too much sense though)). Whereas... cache-loading may in fact temporarily "disable" the ROMs.

Code: Select all

  612Eh   movb   ext_dta,[ext_ptr]          ;\these 3 opcodes are used to 
  4000h   inc    ext_ptr                    ; read one byte from [ext_ptr], 
  1C00h   finish ext_dta                    ;/and to increment ext_ptr by 1

I can only guess there, too. Doing (or invoking) the memory access in 1st opcode makes most sense to me. Yup, the 3rd opcode may be a "wait", or just forwarding the result in case the memory access can be finished within the 3 opcodes without waiting. And the 2nd opcode, maybe it's doing some memory-access stuff, too, the only thing that is sure is that it does increment ext_ptr (inconsistent with the architecture or not).

What I really want is to find someone who can replace the second ROM chip on Rockman X2 with a RAM chip.

Would be nice. And not very complicated: Basically a 32pin SRAM mounted with 1:1 connection on top of the 32pin ROM, plus a switch to select between ROM and SRAM, and finding a /WR write signal from the CX4 chip (or if the thing doesn't have a /WR signal, then it'd be easiest to use a EPROM or FLASH chip instead of SRAM).

if you ever get bored and want to take a look, Cydrak and I found what appears to be a timer in the ST018

When I've time. At the moment I've focused on bugfixes, and SFC-Box...

Super Famicom Box:

Here's a new KROM1 replacement with diagnostics functions: http://nocash.emubase.de/kromtest.zip Would be great if somebody could burn it into EPROM (27C512), and then replace the KROM1 by that chip.

It's showing the full OSD character set, different character sizes, mono and color palettes, background "bordering" styles, etc. Plus I/O port dumps, some CPU invalid-opcode TRAP tests, button/switch test, and some "pulse" and "toggle" functions for unknown outputs (some that might blink the LEDs... or possibly produce BEEP sounds in case there's an external audio source).

Best would be taking JPG screenshots of all test screens with some video grabbing hardware (should be better quality than photos). Though picture quality doesn't matter too much for now, at the moment I'd be just happy to see if/how it's working on real hardware.

So far, I've tested it only in no$sns (where it's working fine). Real hardware seems to include a watchdog, but that should be handled, so I hope the program won't crash or hang!

Oh, and some general questions: That GAME/TV button... does that have any visible effect on video input or output? Or maybe pauses the game while in TV mode? Ah, and is it a "normal" push-button, closed when/while pushed, or is it closed when pushed once, and opened when pushed another time? And same for the RESET button?

The right-most switch setting... is it possible that the relay does switch-off the SFC-Box (rather than switching-off the TV-Set)?

Some (maybe only newer) MBxxxxx OSD chips seem to have a Blink-feature, is there such a thing used in the SFC-Box, too? (If yes, it might appear in the "OSD STYLES" test).

And are there any "external" non-APU sound effects? The menu is using the APU, but maybe there are in-game sounds, prompting for new-coin, or confirming coin-insertion. (If there's such a feature, then it's probably merely a BEEP sound, and sould be heard in the "PULSE" tests).

Posted: **Sun Apr 01, 2012 5:29 pm**

Very interested and happy about your interest in the SFC Box.
Even for me, I just can't get excited about the system at all :/
If not for you, this one would probably be lost to time.

> Are you sure it's controlled by 7F48h?

My understanding of it is that anyone who tries to dump MMX2 gets open bus on the last 4MB. uCON (a misc. copier tool that can dump games) dumps MMX2 by writing to this register first.
So indeed, it may not be its -only- function, but rather a side-effect of the bit being clear. Interestingly enough, it has no effect on reading out the last 8MB of MMX3 (MMX3 is 4MB larger, and on one single ROM chip.)

> 7F48h is toggled after checksumming every 800h byte block. And, after writing 7F48h, the software seems to wait for a busy-flag.

Ah, should have known that you'd have a better understanding than I do, heh.
That does indeed make sense what you're saying. I guess we'll have to wait and see with some hardware test code =)

> I can only guess there, too. Doing (or invoking) the memory access in 1st opcode makes most sense to me.

That is true, but the pattern matches better for 4000 being the read. Again, only one surefire way to get this correct :D
It's going to be a fun little treat to emulate regardless. Especially getting the failures right when one of the three opcodes are missing.

> When I've time. At the moment I've focused on bugfixes, and SFC-Box...

Alright, sounds good. I'm in no big hurry.
FWIW, if you hook up your ARM7TDMI GBA core, it'll work fine with ~2KB of glue code for the MMIO ports. I'm sure you are fully aware, but this game relies on unaligned memory reads rotating data to work. Also, Jonas Quinn discovered that the difficulty flag is stored in 07bf, and is written as a parameter to a function at PC e7b8. Possible the timer comes into play when making complex moves in different difficulty modes.

Posted: **Wed Apr 25, 2012 12:36 pm**

Hey nocash... I can fill in the blank for some of these multi-tap games for number of players through your documentation.

Bakukyuu Renpatsu!! Super B-Daman: 4 players (via "Battle Mode")
Bakutou Dochers: 4 players (via the bottom option, "Battle Mode")
Battle Jockey: 4 players
Dream Basketball - Dunk and Hoop: 5 players (six could have been possible, but the multi-tap only supports five)
Dynamic Stadium: 4 players
ESPN National Hockey Night: 5 players
FIFA 97: 5 players
FIFA 98 - Road to World Cup: 5 players
Finalset: 4 players
Go! Go! Dodge League: 4 players
Hat Trick Hero 2: 4 players
Human Grand Prix 3 and 4: Both appear to support 3 players
Hebereke no Oishii Puzzle wa Irimasenka: 5 players
J.League Excite Stage '95 and '96: 4 players for both games
J.League Super Soccer '95: 4 players
Jikkyou Power Pro Wrestling '96 - Max Voltage: 4 players (It could have supported five, but I determined it only supported four.)
Jimmy Connors Pro Tennis Tour: 4 players (Japanese version only!?)
JWP Joshi Pro Wrestling - Pure Wrestle Queens: 4 players
Kunio-kun no Dodgeball: 4 players
Madden NFL '98: 5 players
Mizuki Shigeru no Youkai Hyakkiyakou: 4 players
Multi Play Volleyball: 4 players
NBA Hang Time: 4 players
NFL Quarterback Club: 5 players
NFL Quarterback Club '96: 5 players
NHL '98: 5 players
Shin Nihon Pro Wrestling - Chou Senshi in Tokyo Dome: 4 players
Shin Nihon Pro Wrestling Kounin '94: 4 players
Shin Nihon Pro Wrestling Kounin '95: 4 players
Sugoi Hebereke: 4 players
(TODO: rest of the games on your list)
Yuujin no Furi Furi Girls: 4 players

And... you missed at least one:
Bomberman B-Daman: 4 players (via Battle)
Kiteretsu Daihyakka - Choujikuu Sugoroku: 5 players
J.League '96 Dream Stadium: 4 players

Corrections:
Elite Soccer/World Cup Striker: 5 players (Using the "Multiple Players" option while setting up for a game, you can assign different people to different controllers.)
FIFA International Soccer: 5 players
FIFA Soccer 96: This actually supports 5 players, not four. Pause the game and access the controllers with a multi-tap connected... up to five can join in.
Madden NFL '94: 5 players
Madden NFL '95: 5 players
Madden NFL '97: 5 players

Does this really support the multi-tap? (A quick check came up... as a big question mark. Not sure how the multi-tap would have been used for now.):
Dino Dini's Soccer
J.League Soccer Prime Goal
NHL '95 through '97 (Didn't detect additional players through the one emulator I used them on... could be a hiccup on my end.)

Lemmings 2 supports the super scope for shooting lemmings, but it does not appear to have software calibration.

Posted: **Thu Apr 26, 2012 1:02 am**

KungFuFurby wrote:Hey nocash... I can fill in the blank for some of these multi-tap games for number of players through your documentation.

Appearently NOCASH is down, just a notice

nesdev.org

fullsnes - new SNES hardware specs