Now it's time to explain the development details and the code organization. Here's the memory map of the Midway 8080 hardware:

0000-1fff: 8K ROM
2000-23ff: 1K RAM
2400-3fff: 7K VRAM
4000-: RAM Mirror

Even that the system has 8K ROM, the Amazing Maze ROMs uses 4K ROM, so I'm limited to this amount. I'm using the RAM to store the variables, such as the score digits and the array grid.

For the VRAM (video display), I implemented text video mode with a cursor and some basic font to draw on the screen. For 256 unique tilesets it'll consume 2048 bytes (256 * 8), which will be too much, so the strategy is to use few font tilesets. If I use only 64 unique tilesets it'll consume only 512 bytes (64 * 8), which will be sufficient for special glyphs.

I'm organizing the code by using the assembler directives like defining the data segment and code segment, and using a macro to help loading the video address to the BC register.

For the strings I'm using a custom encoding and the strings terminate with 0xff. I have a subroutine to print it passing the string address to HL register and cursor position to BC register.

Remember the RET opcode on the 8086 assembly which you can optionally pass an immediate value to pop the bytes after returning to calling procedure? It's very useful to implement the Pascal-style calling convention which the callee (the subroutine) is responsible to clear the arguments of the stack.

The problem is that the RET opcode on the 8080 assembly doesn't have that, so I have to use a different calling convention. The first parameter is stored on HL register, the second on BC register, and the third on DE register.

After all the explanation, here's the drawing of the losing screen of the 2048 game on the system (I still need to implement the gameplay):