Dumping/reverse engineering MSX models thread

Champion (320)

07-11-2022, 16:15

Louthrax wrote:

This looks like the "too fast acesses to MSX1 VDP" not beeing emulated by openMSX (or is it now ?).

After seeing Bounder or Operation Wolf quite destroyed, I'm convinced that it's not the VDP itself but the surrounding circuitry, as Manuel suggested. It seems that most of the time the #1 and #3 vertical thirds of the screen are the affected ones. I'll see if I can map this to the VRAM memory chips. It fails mainly when it writes something, the reads seem to be fine.
The too fast writes are emulated, by the way.
A good side effect of me trying to understand what is going on and repairing is that I'll have a lot of information to add to the wiki!

By mcolom

Champion (320)

07-11-2022, 23:24

I have some interesting news!
I made a small program in assembly which simply fills the screen with some fixed data (I use ROM's) in SCREEN 2, over and over again. The goal of this test is:
1) Check if the image, which is supposed to be steady, changes over time. That would mean faulty VRAM 4416 chips.
2) Check if the problem is caused by writing too fast to the VDP.

My results:
1) The failure in the VRAM chips seems to be discarded. When I repeat several writes with the right (slow) speed, the image is steady. No R/W problems.
2) When I write at a rate which is supposed to be acceptable for the VDP, in the emulator I obtain a normal image, while in the real machine I obtain write-too-fast wobbling artifacts.

I'll copy my code below. The number of nops is the delay:
0, 1, and 2 nops: bad image in both emulator and NMS 800.
3 nops: good image in the emulator (as expected), artifacts in NMS 800 (!!)
4 and more nops: same correct image in both.

My conclusion: either the VDP is run slower in the NMS 800 and therefore there are unexpected artifacts, or simply my machine has some timing problem.

Can anyone check with one NMS 800 (or 801)? You can run Bounder or Operation Wolf for example, very clear problems.

My code:

write_loop_outer1:
    ld hl, 0
    call SET_VDP_WRITE
    ld bc, 24 * 32 * 8

        write_loop2:
            ld a, (hl)
            out (0x98), a
            
            ; Variable number of nops here.
            ; Difference between emulator and NMS 800 observed with 3 nops.
            nop
            nop
            nop
            nop
            nop
            nop
            nop
            nop
            nop
            out (0x98), a

            inc hl
            
            ; Decrement according to the number of OUTs
            dec bc
            dec bc
            
            ld a, b
            or c
            jr nz, write_loop2

    jr write_loop_outer1

By Manuel

Ascended (19678)

08-11-2022, 00:35

Did you also try this test program on another MSX1?

By mcolom

Champion (320)

08-11-2022, 01:20

Manuel wrote:

Did you also try this test program on another MSX1?

No, I only have this (almost) MSX1 here.
If someone wants to try, I've uploaded the 10 small tests (CAS files) here: https://transfert.free.fr/nSu5yH
Each of the tests introduces 0, 1, 2, ... 9 "nop" delays. The interesting test is the one with 3 nops. If someone could run the 3-nop test in another real NMS 800 or 801 would be great, since I'd know if it's just a particular problem in my machine, or if this happens with all NMS 800/801.

By theNestruo

Champion (429)

21-11-2022, 18:39

Hi!

I've dumped the BIOS and the firmware of a Sony HB-11 using Tiny Slot Checker.

Checksums:
- Sony_HB-11_SL00P0.rom: 6716404cf248f92d672fa4c54c9c07f47990b011
- Sony_HB-11_SL30P1.rom: 21baaf52bc5355417d810dd479679482bb9a45a0
- Sony_HB-11_SL31P1.rom: 4ee80ca1645c1f3c01fd04c3ceb6f78d44fc13c0
- Sony_HB-11_SL33P1.rom: 8a827cf0cddce2c98c6c6cdd830e7791eb9a28cf

A couple of firmware screenshots:
- link
- link

I did it during a small meeting in Spain and, unfortunately, the computer ended up in the boot of the wrong car so I can't dump the Kanji ROM* or check any additional information at the moment.

Please let me know the best way to add this computer to the databases: GitHub issue in OpenMSX project? Shall I wait to retrieve the computer again and validate the values in the new machine .XML file?

* If needed, as according to this thread, the Kanji ROM is identical to the HB-F900 one, which is dumped.

By sdsnatcher73

Enlighted (4291)

21-11-2022, 21:10

I also dumped the machine today, such a coincidence. I did dump the kanji font ROM as well. I sent the dumps to Manuel including a preliminary config (that does work but misses the initial RAM content).

SHASUMs of my dumps (which match yours):
6716404cf248f92d672fa4c54c9c07f47990b011 hb-11_basic-bios1.rom
21baaf52bc5355417d810dd479679482bb9a45a0 hb-11_firmware_1.rom
4ee80ca1645c1f3c01fd04c3ceb6f78d44fc13c0 hb-11_firmware-2.rom
8a827cf0cddce2c98c6c6cdd830e7791eb9a28cf hb-11_firmware_3.rom
6acaf2eeb57f65f7408235d5e07b7563229de799 hb-11_kanjifont.rom

By Manuel

Ascended (19678)

22-11-2022, 00:08

Thanks guys! Some of the keyboard details are still missing. Can you check them?

By sdsnatcher73

Enlighted (4291)

22-11-2022, 07:20

Please specify what info is missing. The layout is same as HB-10 as you can see in the images.

By Manuel

Ascended (19678)

22-11-2022, 07:41

Yes, but stuff like the key ghosting is not known yet.