The pictures on this site do not come from the emulator: tools/graficos.py draws them from the bytes of the ROM. The emulator is used for the opposite, which is checking that those pictures are true.
"C:/Program Files/openMSX/openmsx.exe" -machine Philips_VG_8020 \
-cart pingpong.rom -script tools/omsx_vram.tcl
The script lets the game run and, at seven moments spread over the startup and the match, dumps into work/omsx/:
It sets no breakpoints at all: the dumps are scheduled on emulated time, which is the only thing that does not choke the emulator. And it carries a real-time watchdog, so a broken script cannot leave it hanging.
python3 tools/coteja_vram.py pingpong.rom work/omsx/vram_01.bin logotipo
python3 tools/coteja_vram.py pingpong.rom work/omsx/vram_03.bin titulo
python3 tools/coteja_vram.py pingpong.rom work/omsx/vram_04.bin nivel
It compares the four tables -colour, patterns, names and sprite patterns- byte for byte, and says in which and in how many bytes they differ. What comes out today:
| scene | bytes different out of 16,384 |
|---|---|
| logo | 0 |
| table with the menu | 0 |
| title | 1 |
The one byte left is the eighth of the small "KONAMI" at 0x3868: the dump catches that animation half-way through, it is not a format error.
Sprite attributes are not compared: they change every frame. What is compared is the scenery, which is what graficos.py claims to reproduce.
info_00 regs 02 E2 0E 7F 07 76 03 E4 scene 0, subscene 2
info_02 regs 02 E2 0E 7F 07 76 03 E0 scene 1, subscene 3
info_04 regs 02 E2 0E 7F 07 76 03 E0 scene 3, subscene 5
Three things at once:
level 3, which confirms the fixed value set by 0x40A9With any MSX1 emulator and the cartridge in page 1. With openMSX:
openmsx -machine Philips_VG_8020 -cart pingpong.rom
Player 1's keys are the arrows and the space bar; player 2 has their own keys, spread over four rows of the matrix, and both joystick ports work too.