Sega Megadrive – 9: Maps and scrolling planes

Okay! Things are going smoothly, I’ve been managing to write up a article once every three weeks so I’ll try to keep that pace going. Here’s the next couple of things I’ve been dabbling in: loading plane data from maps, then scrolling them vertically and horizontally.

First, some corrections: I made a few errors in the source of the last post, mainly to do with the number of bytes copied when updating a sprite animation frame (basic maths, typical me), so the source at the bottom should clear up the mess.

The VDP’s plane A and B memory space can fit in more tile descriptors than there are cells – the surplus is hidden offscreen ready for scrolling. Typically, the data describing the entire scrolling field would come from a map of sorts, which would contain the tile IDs, palette IDs and flipping info for every cell in the entire level. This data would usually be generated from some map designing program to make it easier. I found several tools to do the job, alas they were very much DOS based and I had difficulties getting them to run under Windows 7, even using DOSbox. I settled on MMM, a very basic (but good enough for my needs) Genesis map editor which is able to import tilesets from BMP2Tile, my tool of choice for converting BMP images, which is perfect.

First, I need some test data. I spent an evening hand crafting a basic tileset which could be used for a simple platform game – four rounded corners, green grassy top, with various soil tiles and even two plants. Not bad for the world’s worst artist, I think:

The idea is to forward plan the re-use of each tile. Ignoring the flower for a minute: the 4 border tiles either side can only be used at the sides of one platform island, but the two centre columns of soil/grass can be placed many times in the middle to make the island longer or shorter. The one odd soil tile (two from the bottom, two from the right) can be dotted around the island to make large areas of soil less repetitive. Well, that’s the idea, if it was executed better and perhaps with a bigger tileset, but I’m keeping it simple for the learning process. The flower can either be very tall, as presented in the tileset itself, or just the top two tiles could be used to make a short flower. The two stem tiles themselves could be used alone to make a small headless plant, too. The possibilities are… not exactly endless… but with only 20 tiles we can now make something which would pass as a platformer. Notice the very first tile has been left empty, this is to ensure the whole screen doesn’t get filled with some data when the tileset is copied to VRAM, as well as defining the “blank” tile for MMM.

It could have been optimised further; I didn’t realise MMM supported flipping until after I’d finished my test map. This would have allowed to me to do the same thing with just a 4×4 tileset, since I could get away with flipping the first column to create the last column.

Making sure to convert the image to indexed colour, save as a BMP, and then open it up in BMP2Tile, the process goes something like this:

  • Press the * key to select the whole region
  • File -> Save Palette -> In ASM
  • File -> Save Tiles -> In ASM
  • File -> Export TLE -> New

The palette and tile data can be tidied up and included as assets in code, but for now we’re just interested in the TLE file. This is the format MMM is able to import for designing maps. BMP2Tile has another option – Save Map – but I can’t figure out how it works or where it gets the map data from. I might have another shot at this later, since MMM exports its final map in binary format, and up until now I’ve been trying to keep everything in text format so I can add metrics to it. It wouldn’t be that difficult to convert it back to a block of dc.b text, it’s just a load of bytes after all.

Next, open up MMM, and select File -> New. I plan to make a horizontally scrolling platform map, so I set the metrics to 64×16, and imported the TLE file dumped out by BMP2Tile:

In the bottom-left hand corner is the tileset, and above it a preview for whichever tile is currently selected. On the right-hand side is the play field. It works pretty simply – select the tile to be placed, then the draw icon, and then click in the playfield to place it. After some messing around, here’s what I came up with:

There. Some islands of varying dimentions, and some plants of varying heights. Then File -> Export Binary to get it out of there.

Copying to VRAM

The dumped BIN file should now contain ready-prepared plane data which can be copied to VRAM in one blast; each word in the file contains the tile ID, palette ID and flipping bits for each cell in a 128×16 field, in a VDP friendly format. However, the tile IDs begin at zero, and it assumes the first palette, so if we were to upload the tileset to any location other than 0x0000 or use an alternative palette slot, we would see incorrect results. Also, I didn’t plan for my map to begin at the top of the screen, it represents a platform for the player to walk on so it needs to be moved further down. So, whilst copying the data we need to modify each word to suit our environment:

LoadMapPlaneA:
 ; a0 (l) - Map address (ROM)
 ; d0 (b) - Size in words
 ; d1 (b) - Y offset
 ; d2 (w) - First tile ID
 ; d3 (b) - Palette ID

 mulu.w  #0x0040, d1            ; Multiply Y offset by line width (in words)
 swap    d1                     ; Shift to upper word
 add.l   #vdp_write_plane_a, d1 ; Add PlaneA write cmd + address
 move.l  d1, vdp_control        ; Move dest address to VDP control port

 rol.l   #0x08, d3              ; Shift palette ID to bits 14-15
 rol.l   #0x05, d3              ; Can only rol 8 bits at a time

 subq.b  #0x01, d0              ; Num words in d0, minus 1 for counter

 @Copy:
 move.w  (a0)+, d4              ; Move tile ID from map data to lower d4
 and.l   #%0011111111111111, d4 ; Mask out original palette ID
 or.l    d3, d4                 ; Replace with our own
 add.w   d2, d4                 ; Add first tile offset to d4
 move.w  d4, vdp_data           ; Move to VRAM
 dbra    d0, @Copy              ; Loop

 rts

If the map’s width doesn’t match the VDP’s setup, I’ll need to modify this to copy the data line by line and offset the address after each one, but it’ll do for now.

We have the tile data and palette in ASM files already, the metrics just need adding to it as per previous articles. The map data itself is in a BIN file, so in order to add some sizes it’ll need wrapping up:

Level1Map:

; Include data from .bin file
incbin    "assets\maps\level1_map.bin"

Level1MapEnd
Level1MapSizeB: equ (Level1MapEnd-Level1Map) ; Map size in bytes
Level1MapSizeW: equ (Level1MapSizeB/2)       ; Map size in words
Level1MapSizeL: equ (Level1MapSizeB/4)       ; Map size in longs

Level1MapDimentions: equ 0x4010              ; Dimentions (W/H)

We also need to tell the VDP the dimentions of our map. VDP register 16 controls the scrolling field size, and is set up using the following bit pattern:

00VV00HH

where:

  • 00 = 32 cells
  • 01 = 64 cells
  • 11 = 128 cells

so for a 128×64 playfield (the smallest we can go to support my 128×16 map), register 16 needs initialising to 0x01.

After setting up the size and adding the three assets to the asset map, it’s ready for testing:

; ************************************
; Load palette
; ************************************
lea Level1Palette, a0 ; Palette source address (ROM) to a0
move.l #0x0, d0       ; Palette slot ID to d0
jsr LoadPalette       ; Jump to subroutine

; ************************************
; Load map tiles
; ************************************
lea      Level1Tiles, a0       ; Tileset source address (ROM) to a0
move.l   #Level1TilesVRAM, d0  ; VRAM dest address to d0
move.l   #Level1TilesSizeT, d1 ; Number of tiles in tileset to d1
jsr      LoadTiles             ; Jump to subroutine

; ************************************
; Load map
; ************************************
lea      Level1Map, a0           ; Map data to a0
move.w   #Level1MapSizeW, d0     ; Size (words) to d0
move.l   #0x18, d1               ; Y offset to d1
move.w   #Level1TilesTileID, d2  ; First tile ID to d2
move.l   #0x0, d3                ; Palette ID to d3
jsr      LoadMapPlaneA           ; Jump to subroutine

Since I’ve now separated palettes into their own asset files, I knocked up a quick LoadPalette routine. It’s not much to look at, see the source if interested.

Anyway, here’s the result:

Somewhere along the way I’ve lost all the black pixels, most likely it’s using colour 0 in the palette (transparency), and my flower doesn’t look how I designed it. I’ll go back and correct it at some point, perhaps the palette can be manually messed with in GIMP before saving.

Scrolling horizontally

The rest of the map is in VRAM ready to scroll to the right to see it. For horizontal scrolling there are three scrolling modespixel, cell and screen. The first mode allows us to scroll each line of pixels individually, the second allows us to scroll each line of cells individually, and the latter allows us to scroll the entire plane in one go. For vertical scrolling, there are just two modes – 2-cell and screen, which either scrolls sets of two cells or the entire plane. For both scroll directions, the scrolling can be nudged in pixel steps.

For horizontal scrolling, the data to describe each line or tile scroll value is stored in VRAM, at the address space defined in VDP register 13 (currently set to 0xD000), but for vertical scrolling the VDP has an entirely separate area of memory called VSRAM. I’m not quite sure why the two are separated, perhaps this chip model didn’t originally have support for vertical scrolling, and it was tacked on at a later date, requiring a new area of memory for the job. Of course, that’s complete guesswork, but I think it’s good guesswork.

I’ll go ahead and assume (perhaps dangerously?) that scrolling vertically is done in the same way as scrolling horizontally, so I’ll just concentrate on horizontal for now. I’m also not too worried about scrolling individual lines of pixels or tiles yet, until I get round to doing wavy water effects, so for simplicity I’ll just scroll the entire screen. First, the scrolling mode needs to be set. This is defined – for both scroll directions – in VDP register 11:

  • Bits 0-1: Horizontal scroll mode (0=screen, 1=pixel, 2=cell)
  • Bit 2: Vertical scroll mode (0=screen, 1=two-cell)

In pixel mode every word in the scroll memory area of VRAM describes the scroll value (in pixels) for a row of pixels. In cell mode every 8th word describes the scroll value (in pixels) for a row of cells. In screen mode, the very first word describes the scroll value (in pixels) for the entire plane.

So, after a lengthy introduction, we simply need to ensure horizontal scrolling is set to mode 0 (0x00 in VDP register 11) and move the scroll value to 0xD000 in VRAM:

move.l  #0x50000003, vdp_control
move.w  #0x0010, vdp_data

This should shift the whole of plane A 16 pixels to the left. To make it a little more useful, let’s scroll it using the joypad:

 move.l #0x0, d6              ; HScroll value

; ************************************
; Main game loop
; ************************************
GameLoop:

; ************************************
; Read gamepad input
; ************************************
 jsr ReadPad1 ; Read pad 1 state, result in d0

 btst   #pad_button_right, d0 ; Check right button
 bne    @NoRight              ; Branch if button off
 subi   #0x1, d6              ; Update H scroll value
 @NoRight:

 btst   #pad_button_left, d0  ; Check left button
 bne    @NoLeft               ; Branch if button off
 addi   #0x1, d6              ; Update H scroll value
 @NoLeft:

; ************************************
; Update scrolling during vblank
; ************************************

 jsr WaitVBlankStart   ; Wait for start of vblank

 move.l  #vdp_write_hscroll, vdp_control ; Update H scrolling (scroll value in d6)
 move.w  d6, vdp_data

 jsr     WaitVBlankEnd ; Wait for end of vblank
 jmp     GameLoop      ; Back to the top

This is all very primitive, though. It’s a relatively tiny map when compared to most scrolling Megadrive games, and since 128 tiles is the widest we can go then we’d need some method of streaming in new map data offscreen whilst scrolling. I’d also like to mess with per-pixel line scrolling and create a water effect at some point, but this will do for now.

Matt.

Source

Assemble with:

asm68k.exe /p scrolltest.asm,scrolltest.bin
References
Advertisements

2 thoughts on “Sega Megadrive – 9: Maps and scrolling planes

  1. I love how you include your references/sources for where you found your information. I can’t believe you’ve been able to find these details online. This is really old coding and these technics are not something any company would have been willing to share when this stuff was current.

    • The community around 16-bit development is superb, there’s a lot of information out there but it’s very thinly spread about. I have some official docs that came with my devkit which I’m hoping to scan and share as soon as I have a reliable scanner.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s