Super Famicom Box (Hotel Box)

Mark has been running my "kromtest" program (ie. replaced the KROM bios chip on the SFC-Box mainboard by the kromtest EPROM)!
21 screenshots showing the kromtest v1.0 results can be found here: (aside from the screenshots, the original test program v1.0 is also included for reference).

The cpu tests are showing invalid opcode traps, "-"=passed, "0"=trapped with UFO=0, "."=skipped/not tested. The interesting part is that the HD64180 is actually trapping all undocumented opcodes, even those that are more or less commonly used on Z80 CPUs, ie. the HD64180 doesn't support accessing IX/IY 16bit registers as 8bit fragments (IXH,IXL,IYH,IYL), doesn't support "SLL" opcode, nor useless opcode mirrors (like alternate NEG/IM/RETN/RETI/NOP mirrors).
Please ignore the "DDCBxx" test page, it's rather meaningless; I wanted to test DDCBNNxx, not DDCBxx, but I got that wrong :-)

The TEST "VBLANK" TIME test... I've no clue what the results mean. It was intended to measure timings of a bit that was assumed to be a VBLANK (or maybe VSYNC) signal, but somehow the timings don't seem to match either one...
For a 60Hz signal I would have expected 8 times bigger values (although the HD64180 waitstates and refresh cycles might slowdown the CPU, but even then the values should be around 4 times bigger as they are). And transformed to 262 total scanlines, the "duty" would be around 10 scanlines, which also doesn't match typical vblank or vsync periods.

The WATCHDOG is trapping in both cases (when leaving the watchdog bit stuck set to "1", or stuck set to "0"). Meaning that... watchdog reset should occur either on 1-to-0 or 0-to-1 transitions (or both)... or on repeated writes without transitions. That isn't quite clear yet, anyways it's confirmed that the bit is really having a watchdog function.
The 00000ABAh value gives some hint on the timeout, but it's also affected by memory waitstates and refresh cycles, so it'd be a bit difficult to convert that value to an actual "time" value counted in cycles or seconds.

OSD Tests are showing the full charset, the resolution isn't yet good enough for dumping it, but at least one can see japanese characters, special volume/tape/am/pm/no/arrow symbols, and the normal ASCII characters (which lack some chars like "@|\").
Char Sizes test reveals which bits do control horizontal and vertical zoom. Also note that, after vertical zoom, the next line is skipped, eg. after zoom in Line 3, next line is Line 5 (and Line 4 isn't displayed).
The Special Styles screen reveals a blink-feature, the abitlity to use the "unknown color" as per-character background color, and some complicated bit-combinations that do enable using the "background color" either as "outline" or as "solid" background.
The blink interval isn't visible in the screenshots (obviously), but it can be seen in the original test video http://www.youtube.com/watch?v=nDwZ62e1FdQ

Next kromtest version will include a higher resoltion font-viewer with chars drawn on a chessboard pattern. The missing DDCBNNxx opcode trap test, and verification of (un-)expected traps.

Martin,
i forgot to mention that the controllers, only the up works (to make the menu scroll down).
Some of the other buttons work, do you want me to document of what they do or wait for the next Krom test?

mark

What up, in which menu, and what scrolling? You mean dpad up button, in the kromtest menu... moving the cursor symbol? Ah, yes, looked at the source code, and I've toggled the joypad clk bit the wrong way, thanks for pointing me on it! Here's an updated version, http://nocash.emubase.de/kromtest.zip most of it is same as in old version (you don't need to repeat all tests). Things that are new (and would be nice if you test them):

Joypad should be now working.

The five CPU TEST screens are now colorizing expected/unexpected results in green/red (if everything is working as expected then they should be all green), and the 5th cpu test screen is now testing what I had originally wanted it to do.

In OSD TESTS II, there's a new OSD FONT (ZOOMED) option, showing the character set in double size on four pages. This is intended for dumping the charset, pixel by pixel from screenshots. So a good camera resolution would be nice here (so one can see the individual pixels). If you have a PC with Video-In, that would be even better (as it should give perfectly horizontally and vertically arranged pixels/scanlines, so one could easily dump pixels from the bitmap array by software) (with camera based screenshots that'd be more difficult, as due to the camera perspective "straight" lines are appearing "curved" in screenshots).

The eight REGISTER DUMPS screens would be nice, too (you somehow skipped them in previous test). They are maybe all showing more or less the same values, but that's just the interesting part: If they are same, or if they do differ. For getting an idea about I/O mirrors and such stuff.

And in GENERAL TESTs, there is the SHOW SYSTEM inputs page. Can you check if it shows correct input states? If you do slowly turn the keyswitch from left to right, it should display
"SWITCH: 1st/2nd/3rd/4th/5th/6th (FROM LEFT)"
in exactly that order. If it shows differently ordered positions then I got something wrong.

And RESET BUTTON and TV/GAME BUTTON should display "PUSHED" when pressed, RELEASED otherwise.
For the TV/GAME button, I am not sure, is it a normal push button (shows PUSHED when/while pressed), or is it "sticky" (keeps showing PUSHed when pressed once, and RELEASED when pressed another time)?

And finally, GENERAL TESTs has two PULSE PORT xxh options, and eleven TOGGLE UNKNOWN BITS options. Which I was thinking that something might happen when running the PULSE tests, or when changing the eleven bits from 0 to 1 (or back from 1 to 0).
Ie. watch out (and listen) if something happens. Like a beep sound appearing (if you have speakers connected), a relay rattling, a LED starting to blink, the screen getting black, or the like. Can't promise that anything like that will happen, but maybe you'll notice some interesting effects.

I'll try to get to these tests soon. Sorry, but I don't have a pc video capture card.

Mark

Here comes the SFC-Box OSD charset.
Mark has got hold of a video grabber which gives pretty much perfect screenshots of the charset:

Here's the same picture with a red pixel grid:

For extracting the "raw" pixels, I've been writing a tool that computes the average pixel color (within the above grid). If it's a clearly black or clearly white pixel then it's takes as is. If it's an unclear "gray" pixel, then the tool is examining the left and right pixels, and adjusts the intensity of the middle pixel to the opposite of the intensity of those left/right pixels, and does then retry to identify the adjusted pixel. The result looks like so:

The final font bitmap (with the chessboard pattern and duplicated chars removed):

In case somebody should be interested, here's the conversion tool with source code: (it does require the above "MB90082_screenshot.png" file saved as 24bpp 5,005,966-byte bitmap named "MB90082_original_screenshot.bmp" as input file).

And finally, the plain font as binary file: containing the MB90082.BIN file for use in no$sns BIOS folder (works with the currently released no$sns version) (ie. no$sns v1.4 was ready to support the font once when it gets dumped) (though the emulator's font resizing doesn't look too well, maybe I'll add some cosmetic fixes on that part in next no$sns versions).