The SAM coupe can use IM1, as we can page in ram to the &0038 address, but there's an issue!
The screen ram takes a whopping 24K, two thirds of one of the pagable banks. If we want to page in pattern graphics into the low bank (&0000-&7FFF), to draw to the screen in the high bank (&8000-&FFFF)
Where will our interrupt handler be?

We could disable interrupts, while we copy graphics, but missed interrupts on the SAM never occur, so our music would slow down.

 

The solution we'll use it to set up an IM2 block at the &E000-&E200 range (Vram uses &8000-&DFFF). Our interrupt handler will page the music back in (and out) to the &0000-&7FFF range

We'll then copy our drawing routines to &E400 - This allows the drawing routines to page in more bitmap patterns into the &0000-&7FFF range to copy to Vram.

In this mode an address is formed by taking the top byte from the R register, and the bottom byte from the interrupting device.
A 16 bit word is read from that address, and that address is called.
We can't effectively predict what the bottom byte will be, so we need to define a block of 257 bytes which all point to the same address.
The common solution is to fill memory addresses $8000-$8101 with the value $81. The effect of this is that all interrupts will call to $8181, and it's at that address  we put the code for (or jump to) our actual interrupt handler.
This is not very convenient, and IM 1 is far more useful. But on systems like the Spectrum, where low memory (Address &0038) is ROM, then this is the best solution for us.

We use a LDIR to fill the 257 bytes with &E1E1 We load I with &E0 - as our IM2 block starts at &E0xx We as our IM2 block contains &E1E1, we copy our interrupt handler to address &E1E1. The area &E102-&E1E0 is actually free for use (eg ram vars/stack)
The interrupt handler must be relocatable, meaning we can use JR, but not JP or CALL (the Call to ChibiTracks_PLAY is fine, as the paging operation moves this to the right address) port 250 controls the low bank, we remember the current setting, then page in the music bank (%00100001) so we can play it Our interrupt handler updates the music. Chibitracks uses HL,BC,DE IX and AF only
We need to switch on IM2 and enable interrupts

ChibiTracks

To use ChibiTracks, we need to include the modules of the music player, We also need the platform specific "Chibisound Pro" sound driver.
We need to have a ChiBiTracks music file to play.
We have two options 'Allow Speed change' allows us to change the speed of our song. This is useful to keep the song playing the same speed on 50hz and 60hz screens. NOTE: Whether this will work effectively depends on if the speed was pre-multiplied on export (faster playback, but stops this function working) AllowRelocation allows the binary to be loaded at any memory address, not just the one 'compiled' into the binary at export time - while disabling this will save a little speed/memory it's recommended you keep this enabled! We need to allocate up to 128 bytes of memory for ChibiSoundPro, and ChibiTracks player. We define pointers to the ChibiTracks variables within this ram.
Before we play anything we need to init the ChibiSoundPro Driver. To start our song, we set SongBase to point to the music file we want to play, and call StartSong - we do this any time we want the music to change
All that's left is to execute the PLAY routine to update the playing music. ChibiTracks uses AF,BC,DE,HL and IX... it does not use IY or shadow registers.

This is the Simple version of ZX Maxtile. Tile patterns do not set the color attributes, so each pattern is 8 bytes.
The screen is 256x192, which is 128x96 in logical units. The VRAM base of the screen is &4000. We use some of this spare memory for the 3 draw caches (each 256 bytes) we also use 256 bytes for the 'Xflip lookup table' We define these in the unused memory of the &C000-&FFFF bank Our drawing routine uses Stack misuse, and we use the IX+IY registers, so we keep interrupts disabled by defining the 'DOEI' macro to not turn interrupts back on.
Here is the Tile pattern data The Speccy Tile Drawing routines use 2 color 8x8 tiles, So each tile uses 8 bytes. MaxTile was designed for 4 color, 16 byte tiles, so we will need to do some extra shifting in pattern calculations. 'Fill tiles' are a special case, they fill a tile with 2 bytes (saving time and memory)
The Spectrum screen has eight 1 bit pixels in a byte We'll calculate an Xflip LUT It would be too slow to shift these in realtime, so we 'precaclulate' the flipped equivalent of each of the 256 possible source bytes. This saves memory compared to storing alternative patterns. Yflip does not require a lookup table, we instead move UP VRAM instead of DOWN as we draw the pattern!
The Tile drawing routines do not set color attributes in this example, so we 'clear the screen' to a single color here.
When we want to draw a sprite object to the screen, we need to calculate the VRAM destination. MaxTile uses X,Y co-ordinates in 'Logical Units' (Pairs of pixels) - this is passed in BC, and the Vram destination is returned in HL Moving across the screen is easy, we just add 1 to the HL pos. as our tiles are always 8 pixel aligned on the speccy Moving down within a tile is also easy, we just add 1 to H The full calculation is a little tricky though, we have to split the Y-line into 3 parts, and shift the bits to the correct positions.

The DrawTile Routine is called by the shared code, This shared code will backup and restore the stack pointer and load the first byte of the 16 bit tile number into A The low bit is shifted out (the update bit)... we need to reset it to 0 anyway! The following registers are loaded: BC=Tilemap DE=Tile Bitmap Pattern data HL'=VRAM Destination
To optimize things, the tile drawing works as a 'binary tree', deciding the kind of tile drawing routine to use The Platform specific draw routine DrawTile starts by ckecking Bit 1 (now Bit 0) This is the 'Program' flag - If this is 0, then this is the simplest unflipped tile, otherwise we switch to the advanced routine. If we're drawing a basic tile, we shift a 0 back into A, and write it back, that clears the Update flag, as we will draw the tile now.
We're going to draw a basic unflipped tile We need to load the second byte of the tilenumber, As it was designed for a 16 byte pattern,The data is in the format %NNNNNNNN NNNN---- , we need to shift it right 1 bit for an 8 byte pattern and add it to DE (the pattern data) This gives us the source address - which we shift into SP, as we'll use stack misuse and POP the source bitmap data off the stack!
We now use ab 'unwrapped loop to move each line of our source pattern to the screen. HL is the VRAM destination. We back up the top byte of the HL destination in C We pop a pair of bytes out the pattern source and write them to the HL destination, moving down after each line by INCing H we reset the HL pair (from C) after the tile and return. Note: the XY bits of the pattern number are unused in this case (They define flip mode if the Program bit was set)... These could be used for a 'Tile Tint' (for 4 color patterns on 16 color systems) or a bank number (for bankswitching huge tile sets)
If the Program bit was 1, then either we need to flip, or run some 'custom code' Next we check the XY bits, if both are 0 this is not a flip (Transparent, Filled, Double etc) If either bit (or both) is 1, then this is some kind of flip, so we calculate the pattern source address, and move it into the stack pointer.
If the Y flip bit is 0 we must be X flipping! We use BC as a pointer to the Xflip lookupt table we defined before, we load C with the value we want to flip, and read the flipped equivalent from (BC) We Pop each source pattern byte off the stack, then Xflip it via the Lookup table (in BC) The code is basically the same as the unflipped one, but Unfortunately, as we're using BC for the LUT and A for converting bytes, the code is a bit less efficient moving down the screen. As we're using BC this time, we reset the H part of HL by subtracting 7
If the Y flip bit was set we now check if the X flip bit is also set. If it's not we're just Yflipping! To flip vertically we load the source pattern data normally, but we write it from the bottom of the tile upwards. We add 7 to the H port, this moves us to the last line of the tile
if the X bit was set as well as Y we need to XY flip. We do this with a combination of both 'tricks' We use the LUT to X flip, and draw to the screen Bottom to Top to Y flip!

MaxTile Custom Draw Types

Bits 1,2,3... XYP=%001 defines a custom program When a custom program is being used Bits 4,5 define the program type (rather than part of the low tile number) %00=Filled Tile %01=Double height tile %10=unused %11=Transparent tile/empty tile The remaining two bits 6,7 act as the High part of the tile number %------NN nnnnnnnn
A double height tile uses only 4 lines of a pattern, so we multiply the pattern number by 4 We then draw each line of the pattern twice to the screen.
The fill tile is the simplest! We use 2 bytes from the pattern data, and fill each line with one of the two We use E for one line, then D for one line - this allows us to make a nice 'checkerboard' patterned fill, or alternate lines in different colors. As so little data is read, This routine is the fastest, so should be used for as much as possible of our tilemap!
The final type is the Transparent tile. if the Tilenumber=255 then this tile is completely transparent, and no data will be drawn
Our transparency is a crude '0 byte' transparency. Basically, any byte equal to 0 is not drawn to the screen, others are drawn normally. We compare to the transparent 0 (in A) and skip over the draw command if the bytes match. In fact, if we switch C we can define another byte to be transparent (Chibiakumas used a 'rainbow byte' with color 3210 or 0123 as transparent in some cases). More impressive transparency can be achieved via a LUT and a combination of AND/OR, however this simple transparency is fast, and tends to give a nice 'cartoon' effect with black outlines to characters

This is the Simple version of ZX Maxtile. Tile patterns do not set the color attributes, so each pattern is 8 bytes.
The screen is 256x192, which is 128x96 in logical units. The VRAM base of the screen is &4000. We use some of this spare memory for the 3 draw caches (each 256 bytes) we also use 256 bytes for the 'Xflip lookup table' We define these in the unused memory of the &C000-&FFFF bank Our drawing routine uses Stack misuse, and we use the IX+IY registers, so we keep interrupts disabled by defining the 'DOEI' macro to not turn interrupts back on.
Here is the Tile pattern data The Speccy Tile Drawing routines use 2 color 8x8 tiles, with a 1 byte color attribute per tile , So each tile uses 9 bytes. MaxTile was designed for 4 color, 16 byte tiles, so we will need to do some extra shifting in pattern calculations. 'Fill tiles' are a special case, they fill a tile with 2 bytes  1 color attribute (saving time and memory)
The Spectrum screen has eight 1 bit pixels in a byte We'll calculate an Xflip LUT It would be too slow to shift these in realtime, so we 'precaclulate' the flipped equivalent of each of the 256 possible source bytes. This saves memory compared to storing alternative patterns. Yflip does not require a lookup table, we instead move UP VRAM instead of DOWN as we draw the pattern!
When we want to draw a sprite object to the screen, we need to calculate the VRAM destination. MaxTile uses X,Y co-ordinates in 'Logical Units' (Pairs of pixels) - this is passed in BC, and the Vram destination is returned in HL Moving across the screen is easy, we just add 1 to the HL pos. as our tiles are always 8 pixel aligned on the speccy Moving down within a tile is also easy, we just add 1 to H The full calculation is a little tricky though, we have to split the Y-line into 3 parts, and shift the bits to the correct positions.

The DrawTile Routine is called by the shared code, This shared code will backup and restore the stack pointer and load the first byte of the 16 bit tile number into A The low bit is shifted out (the update bit)... we need to reset it to 0 anyway! The following registers are loaded: BC=Tilemap DE=Tile Bitmap Pattern data HL'=VRAM Destination
To optimize things, the tile drawing works as a 'binary tree', deciding the kind of tile drawing routine to use The Platform specific draw routine DrawTile starts by ckecking Bit 1 (now Bit 0) This is the 'Program' flag - If this is 0, then this is the simplest unflipped tile, otherwise we switch to the advanced routine. If we're drawing a basic tile, we shift a 0 back into A, and write it back, that clears the Update flag, as we will draw the tile now.
We're going to draw a basic unflipped tile We need to load the second byte of the tilenumber, As it was designed for a 16 byte pattern,The data is in the format %NNNNNNNN NNNN---- Each tile pattern has 8 bitmap bytes + 1 color attrib byte. We repeatedly bit shift, first to the 'x8' position, then to the 'x1' position, we then add these two together we need to shift it right 1 bit for an 8 byte pattern and add it to DE (the pattern data) This gives us the source address - which we shift into SP, as we'll use stack misuse and POP the source bitmap data off the stack!
We now use ab 'unwrapped loop' to move each line of our source pattern to the screen. HL is the VRAM destination. We back up the top byte of the HL destination in C We pop a pair of bytes out the pattern source and write them to the HL destination, moving down after each line by INCing H we reset the HL pair (from C) after the tile and return. Note: the XY bits of the pattern number are unused in this case (They define flip mode if the Program bit was set)... These could be used for a 'Tile Tint' (for 4 color patterns on 16 color systems) or a bank number (for bankswitching huge tile sets)
We now need to do the color data. We can convert our HL vram destination to point to the tiles color attribute by bit shifting the H byte 3 bits right, and ORing in the color base at &5800 We then transfer the 9th byte (E) from the pattern data into the color attribute
If the Program bit was 1, then either we need to flip, or run some 'custom code' Next we check the XY bits, if both are 0 this is not a flip (Transparent, Filled, Double etc) If either bit (or both) is 1, then this is some kind of flip, so we calculate the pattern source address, and move it into the stack pointer.
If the Y flip bit is 0 we must be X flipping! We use BC as a pointer to the Xflip lookupt table we defined before, we load C with the value we want to flip, and read the flipped equivalent from (BC) We Pop each source pattern byte off the stack, then Xflip it via the Lookup table (in BC) The code is basically the same as the unflipped one, but Unfortunately, as we're using BC for the LUT and A for converting bytes, the code is a bit less efficient moving down the screen. As we're using BC this time, we reset the H part of HL by subtracting 7
If the Y flip bit was set we now check if the X flip bit is also set. If it's not we're just Yflipping! To flip vertically we load the source pattern data normally, but we write it from the bottom of the tile upwards. We add 7 to the H port, this moves us to the last line of the tile
if the X bit was set as well as Y we need to XY flip. We do this with a combination of both 'tricks' We use the LUT to X flip, and draw to the screen Bottom to Top to Y flip!

MaxTile Custom Draw Types

Bits 1,2,3... XYP=%001 defines a custom program When a custom program is being used Bits 4,5 define the program type (rather than part of the low tile number) %00=Filled Tile %01=Double height tile %10=unused %11=Transparent tile/empty tile The remaining two bits 6,7 act as the High part of the tile number %------NN nnnnnnnn
A double height tile uses only 4 lines of a pattern, so we multiply the pattern number by 9, then use either the first byte, or offset by 4 to get the second half of the bitmap data We then draw each line of the pattern twice to the screen. once we've done the bitmap data we do the color byte, which is either next, or 4 bytes onward
The fill tile is the simplest! We use 2 bytes from the pattern data, and fill each line with one of the two We use E for one line, then D for one line - this allows us to make a nice 'checkerboard' patterned fill, or alternate lines in different colors. As so little data is read, This routine is the fastest, so should be used for as much as possible of our tilemap!
The final type is the Transparent tile. if the Tilenumber=255 then this tile is completely transparent, and no data will be drawn
Our transparency is a crude '0 byte' transparency. Basically, any byte equal to 0 is not drawn to the screen, others are drawn normally. We compare to the transparent 0 (in A) and skip over the draw command if the bytes match. In fact, if we switch C we can define another byte to be transparent (Chibiakumas used a 'rainbow byte' with color 3210 or 0123 as transparent in some cases). More impressive transparency can be achieved via a LUT and a combination of AND/OR, however this simple transparency is fast, and tends to give a nice 'cartoon' effect with black outlines to characters

Lesson P97 - MaxTile software tilemap on the Spectrum NEXT - 256 color tiles Lets take a look at the advanced 'Maxtile' tilemap on the Spectrum Next, it supports Xflip,Yflip, Fastfill and more! This version uses 256 color tiles

ZXN_MaxTile_Mid.asm ZXN_V1_MaxTile_Normal.asm

MaxTile Definitions