In the emulator

Three measurements, all of them on the machine and all reproducible with make. No image in this repository comes from the emulator: the captures are for checking, not for publishing.

Booting it

openmsx -machine Philips_VG_8020 -cart bomberman.rom

The VG-8020's BIOS takes more than five seconds to call INIT. Before that the cartridge has not even copied the starting values into RAM, and a dump taken at three seconds is worthless.

The VRAM comparison

make cotejo

It boots openMSX with no window, lets the title screen run, presses space through the keyboard matrix (row 8, bit 0, which is what GTTRIG reads on input 0) and dumps the VDP's 16 KB twice, plus 1,792 bytes of RAM. Then tools/coteja_vram.py subtracts them from the VRAM that tools/vram.py builds.

==================================================================
 LA PORTADA, contra el volcado de t=8
==================================================================
  color                         0 de  6144  ok
  patrones                      0 de  6144  ok
  tabla de nombres              0 de   768  ok
==================================================================
 LA PARTIDA, contra el volcado de t=18
==================================================================
  color                         0 de  6144  ok
  patrones                      0 de  6144  ok
  marco y pilares               0 de   184  ok
  ladrillos que rompen la regla      0 de    29  ok
  premio y puerta bajo ladrillo      0 de     2  ok
==================================================================
 0 diferencias en todo lo que no decide el azar.

Each line says something different:

And a trap that cost a round trip. Comparing the VRAM's name table with the RAM screen says nothing: vuelca_la_pantalla (0x510E) dumps it and leaves it blank, so at any instant the RAM is half-built while the VRAM holds the last complete frame. The frame and the pillars have to be looked at in the name table.

The twenty differences that turned up on the title screen the first time were all explained, and two of them were findings:

Measuring the blast's reach

make alcance

The listing says the flame reaches two board cells per side but only wears down the bricks in the first. That can be read, but it can also be measured.

tools/omsx_alcance.tcl gets into a game, dumps the board, writes two bomb records by hand into the list at 0xE359 — state 1, column, row and count zero, which is exactly what pon_una_bomba leaves — and dumps the board again eight seconds later.

The two cells were picked by reading the board from an earlier dump: emulation is deterministic, so the same timings give the same deal.

  ladrillos antes  : 29
  ladrillos despues: 27
  bomb A: brick 1 cell  to the right in ( 5, 0) -> FALLS
  bomb A: brick 1 cell  below         in ( 4, 1) -> FALLS
  bomb B: brick 2 cells to the left   in (11, 0) -> STILL STANDING

Checking the auto-bomb mode

make fase4

It forces the stage to 4 by writing (0xE310) and dumps the name table four times in a row, to catch the bottom label in both halves of its blink. This comes out:

a row 23: '#                           @:3#'
b row 23: '#                           @:3#'
c row 23: '#  BOMB AUTO SETTING STAGE  @:3#'
d row 23: '#  BOMB AUTO SETTING STAGE  @:3#'

On every other stage that row carries the signature BOMBERMAN HUDSONSOFT 1983 and does not blink.

Tricks for looking inside

Seeing the board, which is where the real map is:

debug read_block memory 0xE38A 768

Skipping stages, which is what make fase4 does:

debug write memory 0xE310 4

Seeing who is hunting: byte +3 of the first enemy record.

debug read memory 0xE31F

When it is zero, that monster is coming for you — and it turns red.

And the golden rule for any dump of this cartridge: the RAM screen (0xE000) is always half-built. What has to be read is the VRAM name table (0x1800), which holds the last complete frame.