email sol follow sol rss feed of the blog wishlist Sol::Tutorials

A Brief z80 Assembly Tutorial

Chapter 9

Chapters:0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 | 0x08 | 0x09 | 0x0a | 0x0b | 0x0c | 0x0d

Okay, the uncompressed, huge image data started bugging me, so let's compress it. I fetched Einar Saukas' excellent zx0 (github) decompressor and the windows compressor, compressed the image, included the decompressor source, replaced the raw data with the compressed one.

Compressed Image


keyselect_scr:
        INCBIN "keyselect.scr.zx0"

        INCLUDE "dzx0_standard.asm"

..and replaced the image copy ldir with a call to the decompressor:


        ld de, SCREEN
        ld hl, keyselect_scr
        call dzx0_standard    

Result: 3868 bytes, or 5329 bytes saved.

I also desaturated the image so it will compress a bit better. Whether the resulting image looks better or worse is a matter of taste.

New Assets

We need those minitiles for the minimap, but before doing that, I wanted a few new tiles. We know that the falling rock will be its own tile, so it might as well have a separate image too. When the rock hits the player the player goes splat, let's have a tile for that. I also want a wandering monster type, so four tiles go to the purple people eater, and finally let's have water and water source. Like so:

Again, the tiles are laid out top down to make them easier to parse.

With all the tiles done, I shrunk them with point sampling down to 8x8 and did some fixing by hand. The mini-tiles don't need to look too great, as they are just for preview.

The artwork done, I again converted these to binary with using my "png2bin" tool from my speccy github tool, and designed the colors straight in the source file.


tiles:
        BLOCK 32,0 	; empty tile
        INCBIN "tiles.dat"

        ; 0x00 0x00 = black      0x04 0x20 = green
        ; 0x01 0x08 = blue       0x05 0x28 = cyan
        ; 0x02 0x10 = red        0x06 0x30 = yellow
        ; 0x03 0x18 = magenta    0x07 0x38 = white
        ;      0x40 = bright          0x80 = blink
tilecolors:
        db 0x00, 0x00, 0x00, 0x00 ; 0 empty
        db 0x05, 0x05, 0x04, 0x04 ; 1 player
        db 0x10, 0x10, 0x10, 0x10 ; 2 ground
        db 0x57, 0x57, 0x57, 0x57 ; 3 bricks
        db 0x44, 0x44, 0x44, 0x44 ; 4 goo
        db 0x45, 0x05, 0x05, 0x45 ; 5 gem
        db 0x07, 0x07, 0x07, 0x07 ; 6 stone
        db 0x04, 0x04, 0x04, 0x04 ; 7 exit (closed)
        db 0x44, 0x44, 0x44, 0x44 ; 8 exit (open)
        db 0x07, 0x07, 0x07, 0x07 ; 9 falling stone
        db 0x07, 0x07, 0x02, 0x02 ; 10 splat stone
        db 0x03, 0x03, 0x03, 0x03 ; 11 people eater up
        db 0x03, 0x03, 0x03, 0x03 ; 12 people eater right
        db 0x03, 0x03, 0x03, 0x03 ; 13 people eater down
        db 0x03, 0x03, 0x03, 0x03 ; 14 people eater left
        db 0x0d, 0x0d, 0x0d, 0x0d ; 15 water
        db 0x07, 0x07, 0x0d, 0x0d ; 16 water source

minitiles:
        BLOCK 8,0 	; empty tile
        INCBIN "minitiles.dat"

minitilecolors:
        db 0x00 ; 0 empty
        db 0x05 ; 1 player
        db 0x10 ; 2 ground
        db 0x57 ; 3 bricks
        db 0x44 ; 4 goo
        db 0x45 ; 5 gem
        db 0x07 ; 6 stone
        db 0x04 ; 7 exit (closed)
        db 0x44 ; 8 exit (open)
        db 0x07 ; 9 falling stone
        db 0x07 ; 10 splat stone
        db 0x03 ; 11 people eater up
        db 0x03 ; 12 people eater right
        db 0x03 ; 13 people eater down
        db 0x03 ; 14 people eater left
        db 0x0d ; 15 water
        db 0x07 ; 16 water source    

Since the minitile colors are always the first ones from the tile colors, I could have saved a few bytes by just keep using those, but maybe it's cleaner this way.

Drawminitile got a few small changes to use the new minitile data; the changes are so trivial that I don't think it makes much sense to copy all of it here.


        ; One tile is 8 bytes
        add hl, hl ; *2
        add hl, hl ; *4
        add hl, hl ; *8
        ld de, minitiles
        add hl, de
        ld de, hl  ; hl now is pointing at the start of tile x

Since one tile is 8 bytes, *8 is now enough.

        
        ; Instead of looping, we'll plot each pixel separately..
        DUP 7
            ld a, (de)    ; Read pixels from data
            ld (hl), a    ; Write to screen
            inc de        ; Increment de and hl..
            inc h
        EDUP
            ld a, (de)    ; Read pixels from data
            ld (hl), a    ; Write to screen

One INC DE is gone from here, since we don't need to skip data anymore.

        
        pop hl ; tile index
        ld de, minitilecolors
        add hl, de  ; hl now points at tile color

Again, simplification: *4 is gone.

General Physics Fixes

Since we're going to have different kinds of physics interactions than just falling, we'll need to scan the whole map, which means we need to check that we're not falling through the bottom of the map.

The changes to scan the whole map are trivial:


physofs:
        db 0, 176

        jr nz, physics_notlooped
        ld hl, 176
physics_notlooped:        

Stopping items from falling below the map requires a new check at the start of physics_drop.


physics_drop:
        ld a, ixl
        cp 16*11+map
        jr nc, physicsdone    

Since IX points at the map data and is not just the tile index, we also need to take the map address into account. Which is bad. After all, the map address is 16 bit. Let's move the map data to a 256 byte offset so we don't need to deal with this - after this change the bottom byte of the address and tile index is the same thing. (This is one of those things that would be really complicated in C, but trivial in assembly).

We'll remove the +map from above, and move the map definition to be the very last thing in the file, with ORG to say what address it should start from.


        ORG $fd00
map:
        BLOCK 16*12,0

Careful now. The interrupt jump table is at 0xfe00 - 0xff01 and the table points at 0xfdfd, meaning we should really leave the memory area 0xfdfd-0xff01 alone. Our map will now be at 0xfd00-0xfdc0, so it's fine. There's also plenty of loose bytes in that region, but unless we're really hurting for space, we should keep everything under 0xfd00 now.

While we're dealing with things like this, let's stop player from pushing rocks outside the screen. The movestone handling gets a new check at the start.


movestone:
        ld a, l
        and a, 0xf
        jr z, movedone ; left border; can't be pushed
        cp 15
        jr z, movedone ; right border; can't be pushed        

Since the player can't be between the border and a rock that's already at a border, the pushing is impossible.

All that out of the way, we can start adding more physics stuff. Let's start with the falling rock.

Making Player go Splat

Making the player go splat requires a few changes. We need to change the stone's state when it's moving, add handler for falling rock, and add a flag that says the player's inputs are no longer desired.


        cp 0
        jr nz, physicsdone
        ld a, (ix)
        cp 6 ; stone
        jr nz, notstone
        ld a, 9 ; falling stone
notstone:
        or 0x80

In the physics_drop after we see that an item is about to fall downwards we need to check if it's a stone or not, and if it is, we replace it with a falling stone. Running the game after this change is a bit boring as the falling stone doesn't do anything. The sprite changes, though.


        cp 5
        jr z, physics_drop
        cp 6
        jr z, physics_drop
        cp 9
        jr z, physics_stone

In the physics handler we'll check for the moving stones and jump to a new handler, physics_stone.


physics_stone:
        ld a, ixl
        cp 16*11
        jr nc, stone_stop
        ld a, (ix+16)
        cp 0
        jr z, stone_fall
stone_stop:
        ld (ix), 0x86 ; inert stone
        jp physicsdone
stone_fall:
        ld (ix), 0x80
        ld (ix+16), 0x89
        jp physicsdone    

The handler is pretty simple; we check if we're at the bottom and go back to inert stone if we can't, then check if there's empty space below us and if there is, move there, otherwise go inert. Testing this we see the sprite change from inert to moving back to inert like we wanted.

One thing to note is that we're using JP to physicsdone here, because our function has grown so large that JR can't reach it anymore. The assembler will complain in these cases, and the fix is trivial. I'll be doing a lot of these changes as the program grows, and won't be mentioning about it every time.

Next we'll deal with the game state. After adding a single byte variable playerdone, we need to clear it at the start of levelselect or the player won't be able to keep playing:


levelselect:
        ld a, 0
        ld (movekey), a
        ld (playerdone), a

To stop player from moving (but not from hitting space), the moveplayer function's start changes to:


moveplayer:
        ld a, (movekey)
        bit 4, a
        jp nz, levelselect
        
        ld a, (playerdone)
        cp 1
        ret z

What's left is changing the moving stone's behaviour to accept moving on top of the player.


        cp 0
        jr z, stone_fall
        cp 1
        jr z, stone_splat

Simply check if the falling stone's target is 1 (player)...


stone_splat:        
        ld (ix), 0x80
        ld (ix+16), 0x8a ; splat
        ld a, 1
        ld (playerdone), a
        jp physicsdone

...move the stone there (as the splat sprite), mark player as done, and that's it. The player has been splatted.

This chapter's version of the source as well as the new assets and source of the decompressor is available here.

Size is at 4385 bytes, which tells me that sjasmplus does not include zero bytes in the raw output (as the size should be closer to 32k if it was). The good news there is that we can keep using the .raw file for size estimates; the bad side is that we can't be sure if the zeroed data is actually zeroed. Doesn't matter in our case, but something to keep in mind. Since our optimized size at the start was 3868 bytes, we increased by 517 bytes, mostly from the new tile graphics.

Any comments etc. can be emailed to me.

Site design & Copyright © 2021 Jari Komppa
Possibly modified around: May 08 2021