<- Back to last page

Set Scroll direction

Depending on the scroll direction, we may need to change the direction the gradient moves, we use self-modifying code for this, and alter the bits within the gradient definition. There are 3 options, Scroll Right, Left or no movement (inteded for vertical levels)

Background Gradient

First, lets remember what the gradient definition looks like! The first two bytes are the starting pair... they are used for the first and second line... every other line is a new line number, and an extra byte for the gradient - this pushes out one of the old bytes, and the new pair is used. when a 255 is found, the gradient routine ends!
When this routine is called, HL points to the right of the top screenline... DE points to the gradient definitions (as shown above), B is the linecount and C is the bitmask of the scroll rate.. We use Self-modifying code to store the scroll rate at the correct point next we load in the first pair for the gradient - we load them into  IXH and IXL... we also swap the source data pos into IY We also load in the 'next line' number - and self modify this in so we know when we need to read in more line data. We also back up the stack pointer - we're going to use stack misuse to draw to the screen quickly!
We now start the main sequence, first we check if we're at a 'new line' point.. .if we're not then we skp to the 'rendering routine' If we do need to do a shift, first we check if the line byte is zero (blank area)... bitshifting zero makes no sense, so we skip if it is... If it's not, then we next check if the timer ticks ANDed with the scrollrate are not zero - if it's not, then we want to do a bitshift at this point, so we jump to the correct routine to do this (it will be altered by self-modifying code, depending on the scroll direction)
The drawing routine starts by checking the B counter, to see if we need to draw any more lines... If B is not zero, we need to draw some more - we misuse the stack pointer to draw quickly to the screen, so we swap HL to the stack pointer... Next we set D and E to IXH - the first line byte of the gradient... We then need a lot of PUSH DE's to quickly draw to the screen! Note - on the CPC we keep interrupts enabled - the ChibiAkuams interrupt handler can cope with runing during stack misuse!
While the interrupt handler can cope with stack misuse, it won't work right unless there are a few bytes for it to write to, so we disable interrupts before the final push. We need to move down a line, because we know we're on an even line, we can simply add &8 to H - but we need to re-update the stack pointer The line drawing is done in pair, so once we've done the first line, we load in the fata for the second from IXL and repeat the procedure
For the finish up procedure, we need to move down a line... however this time we need to check bit 7, to see if we've gone over the bottom of the memory range, and correct the HL position if we have. We now repeat the procedure again. The finishup procedure restores the proper stack pointer, turns interrupts on and returns.

Shift procedure

The bitshift procedure is pretty simple, we need to pull out the 2 bits that make up the rightmost pixel, shift the bits to the left, and OR in the two bits - to put them in the left hand pixel we store the result back into the memory which makes up the gradient definition

Drawing the TileMap

When we call the Tilemap drawing routine, we need to pass some parameters HL is the Tilemap Definition (example shown right) DE is the V9990 tilemap definiton (it can be more complex because the V9k is faster IX is the Gradient definition for the MSX2 - we'll look at that later
The Background routine starts with some special code on the V9K, which will switch in the alternate definition - we do this here, because the level code is common on both the V9K and MSX2 Now we need to load in the current screen position... the MSX2 screen will be at Ypos 0 or 256, depending on which framebuffer is shown, we then replace the low byte with the one read in from the definition, this gives us DY - our destination to show the tile to. Next we load in the number of lines to show, this is saved into NY The next one is a bit tricky, our tiles are saved as a block in the sprite data - and we need to load in the start of that block into this code (Via self-modified code) - we then add the Y offset of the current strip to that block Y offset - the result is the source Y - SY for the current strip.
You can see the Sprite data here - in the Z80 coding bugs level, the Tiles should be at the start, so the position will be calculated correctly automatically
Here's how the scrolling effect works. The tilestrip is split in two parts by the 'scroll point'... everything to the right is copied to the far left of the screen... everything to the left is put on the right... then the scroll point is increased... The result is a tilestrip the full width of the screen, which scrolls, and is filled with only 2 VDP commands (fewer commands= faster)
Next we load in the 'Tickmask... the top bit will allow the scroll direction to be reversed, the other bits are ANDed with 'TicksOccured'... this allows the rate of the scroll to be altered It should be noticed there is a 'slowdown' section - this is used on the V9990, and is self modified to slow down the effect of the scroll The MSX2 VDP can only work in pairs, but the V9K can work in indevidial pixels, the two NOPS will be converted to INC (HL) or DEC (HL)s depending on the scroll direction. We're copying from the middle of the strip to the end - so the Width (NX) of the strip to copy is caclulated by flipping all the bits in the X pos (SX) the Destination DX is the far left of the screen,  and we set the top byte of the NX to Zero.
Next we need to do a check on the number of pixels we're going to draw... usually NX will be <255 - so a single byte - but if the low bit is 0 - then we need to set the high byte to 1... we do that now, buy calling the 'ByteUp' command, which will increase the high byte by one... On the V9K we just draw the tilemap. On the MSX2 we run 'BusyGradient'... this checks if the VDP is busy, and if it is, then the Z80 will draw part of the gradient via memory access... we'll have a look at this command later. When the VDP is idle, we actually draw the gradient
We now copy from the start of the tile definition up to the scroll point, so we zero SX We now load in NX and check if it was 256 - if it was, we've nothing more to draw, as we've filled the screen.... if not we use this as the destination of pixels to copy - effectively copying to the position the last copy ended. We do another CPL to work out how many pixels we need to draw to fill the remaining width of the screen Now we use the same routines as before, BusyGradient to draw any gradient while the VDP is busy, then we actually draw the tiles! We now repeat untill we've drawn all the tile definitions.. Finally we have the Byteup command - it just sets NX to 256, for the rare time we need to draw the full width in one go!

Solid Fill

Gradient fill via Z80 ram access

We start with a blank screen... our gradient procedure is: 1. Fill a strip 4 pixels wide, and 192 pixels tall with the gradient (on the left hand side) 2. Copy it over the whole screen 3. Add the tilestrips, sprites etc.

The gradient is made up of 2 alternating line definitions - of 2 bytes per line... The Gradient definition has to be passed in HL... The definition has a start line - which is the first two lines - each line takes 2 bytes... All following lines have a Line-number - a byte-pair for the new definition (which replaces the oldest of the two being cycled) and a shift timer -which is a bitmask used with 'ticks occured' to decide when to scroll the background Finally the last definition is ended by a 255 byte...
When we call the routine, HL will point to the gradient definition and B will be the line count (which is always 192) The first thing we do is INIT the destination ranges... we need to set the 'screen start Y', which will either be 0 or 256, depending on if screen buffer 0 or 1 is shown We now load in the two bytepairs for the first line.. we store them into IX/IY first - but we soon move them into the shadow registers BC/DE (which are faster) Then we load in the next point we need to change the gradient, and store it via self modifying code.
We need to initialize two HMM commands... one to fill the strip on the left (HMMC) and the other to fill the whole screen with that strip (HMMM) Once we've set the command definitions up, we start the HMMC command.
We send 4 bytes to the VDP data port - remember our strip is only 2 bytes wide, so this effectively fills 2 lines! We now see if we need to do a gradient change - if not we jump over the next bit... Now we check if we need to do the Gradient scroll by ANDing in the 'Ticks occured' counter... if the result is not Zero, then we need to do a shift now!
When we need to load in a new byte, we first swap DE into BC... then we load new bytes for DE in from the source again We also load in the new scroll tick mask, and the next line we need to change the gradient again.
Whether any updates are done or not - we decreace B and repeat until done!
We're going to copy a 252x192 area from the far left to the right... this results in the copy command copying the 4 pixels repeatedly over the entire screen.. In theory we'd just  copy the 4 pixels across the screen, but in practace this doesn't work!... the reason for this is that the V9K is caching the bytes we just wrote... To counter this we double the 4x192 area to 8x192... then we copy this over the entire screen... The result is the gradient now fills the entire screen.

The background pixel shift for the V9K is almost identical to the MSX2... We take the rightmost pixel in the two bytes and shift it... Then we shift the other 3 left, and put the shifted first pixel at the far right. Once the bytes have been shifted, we save them back to the Gradient definition.

Lesson Aku20 - Level Init and Loop When a level starts, some Initialization is required to get things working, Once this is done, the main level code will proceed with the Level loop - which will continue to execute until either the player dies, or wins the level. Lets see how all this works!

On the MSX systems, we need to initialize the memory locations of the Tile data used to draw the background - the positions these need to go will have been set by the previous load commands - however we need to Self-Modify these into the code. Afterwards, we need to actually get the bitmap data... The data is RLE compressed, and it's bytes are stored in the level data block, so we decompress this from RAM  into VRAM
On the V9K on the MSX2 in Chibiakumas, boss battles uses custom sprites for enemy bullets, we need to load them in here.
For the next stage, we'll want the Player & game parameters.
Some levels of ChibiAkumas on the CPC flipped colors every frame to 'fake in between' colors... if the user allowed it it would be turned on here... On the MSX2 we would see if the V9K was present, and turn on the alternate background if it is.
On the Spectrum we have a problem! the 2nd set of sprites are held in the level data, but we need to page it out , and page in bank 7 for the second screen buffer - which means we can't get access to the sprites! To solve this, we copy the sprites into bank 7 where the second buffer is.
Now we need to initialize the 'Event Stream' (the level contents' HL points to the Event Stream data... DE points to a bank of ram which can be used by the event stream for an extra 16 object definitions (128 bytes)... it's not needed if you don't use "evtSettingsBankEXT"
Next we need to INIT arkostracker to get the music playing. Note that on the Speccy we use Bankswapper_CallHL - this function swaps the bank in, calls HL, and restores the level bank on the spectrum, so everything works OK
We now initialize the screen buffers - this sets up double buffering... Because of the memory layout of the CPC, and the fact we need to recalculate the memory location every time we go outside of the 16k bank of screen ram, we need to use self modifying code to change the conditions of the "Get Next Line" routines... HL will be set to the correct code by the ScreenBuffer_Init routine.
Finally, we start the interrupt handler... The main level loop will now begin!

RLE stands for Run Length Encoding... this is a compression method where consecutive pixels that are the same are compressed.. .by storing them as a color and a count RLE is LOSSLESS - the image will be a perfect recreation of the original, but it will be slower to draw! Lets imagine we have a bitmap.... and the pixels are colored 122222222221111111123 ... that's 21 characters.... Now let's imagine we stored that as 1x1.2x10.1x8.2x1.3x1... that's 19 characters Now that's a ridiculous example, but the principle stands - and rather than characters, we'll store our data in Nibbles (half bytes)

Rle Bitmap shown on the CPC!

With the right data, RLE files are much smaller than raw bitmaps, and because the compressor 'understands' image data, they can beat compressors designed to work with byte data (an RLE compressor can save space on 5 consecutive pixels the same color, a byte compressor cannot) One thing to bear in mind, the resulting RLE will be more efficient if lots of consecutive pixels are identical, and you can use this in your art design if you need to save space!

A file optimized for RLE - note the grey and black 'lines' and few single pixels These compress better than a checkerboard

My free, open source AkuSprite Editor can create RLE files for the CPC, Spectrum, MSX and Sam Coupe... the file format is basically the same, but because of the different bit depths of the machines, the number (and order) of the pixels compressed differers... on the Spectrum the color information is also RLE compressed as an extra data set. It should be possible to write decompress ors for the other systems, however it is not my plan to do so at this time, as I have no plans to use RLE on other systems at this time - and porting the decompresser is time consuming.

When we use the RLE function, the RLE sourcecode is stored into the clipboard... If we just add an ORG &8000  we can compile the code, and just do a CALL &8000 to show our RLE... Note, the color information is not stored in the RLE, so we'll need to set the palette ourself! Also Note, this example has a DI, HALT at the end - so we'll need to change this depending on what we want to do!
If we want to use the CPC firmware (for example to return to basic, we need to make some changes! The firmware relies on the shadow register BC being unchanged, so we need to back that up! By adding an EXX and PUSH/POP of BC, we can keep the firmware happy!

The compressor was designed for the CPC, but was ported to the other systems, on the speccy each nibble is 4 pixels - on the MSX/SAM it's just one! Basically the decompresser is the same though, just with code reprogrammed for screen pixel drawing, and the 'GetNextLine' command is changed

The Spectrum RLE export is basically the same, it will export code that you can just go ahead and run. you should note that the decompresser uses the IY register - again, this is needed by the Spectrum firmware, so you'll need to back it up if you're using the speccy firmware.

The MSX version is the 'odd one out'... Rather than saving the RLE to the clipboard, it is saved to a file - this is because the MSX screen is very large (24k), and the ram is very small (64k)... also the disk is relatively slow..., For this reason ChibiAkumas usually streams RLE from the disk to the VDP without using ram - this ends up faster, and doesn't use any memory (well technically it uses a 128 byte buffer) However, when we use the export routine in Akusprite editor, a simple 'Loader' will be created which does allow the RLE to be viewed from ram, This can just be pasted in and should run OK, provided your screen is set up correctly, and you have the 'VdpMemory.asm' module included - which handles the VDP init commands for the RLE draw

The ChibiAkumas RLE format probably isn't the best - but it's FREE... Chibiakumas was developed for personal achievement by the developer, and the author wanted to try to make his own RLE compressor - being the best or fastest wasn't the mission!

Lesson Aku22 - ChibiAkumas RLE decompresser While the Compressor is written in C#, The ChibiAkumas RLE decompresser is Z80 based... In this lesson we're going to look at the CPC version of the decompresser and see how it works! (the Speccy/SAM and MSX ones are fairly similar)

RLETest.asm

As we saw before, When the RLE decompresser is started HL points to the start of the data in RAM, DE points to the end,B points to the Y line  to start drawing, IXH is the width in bytes, and ITL is the X pos of the RIGHT HAND SIDE.... This is because the decompresser works Right-> Left, this was to allow the option of using stack misuse for filling.

First we need to initialize various parameters using self modifying code... Next we need to calculate the starting screenpos, we use the NextScreenLine function to do this, but it automatically adds the image width (as it's designed to recalculate the starting line during drawing) so we need to subtract that width for each iteration Once we're ready we set E to 255 - E is used during drawing RLE data to mark which half of the byte is currently drawn - as each RLE nibble is 2 pixels there are two iterations per screen byte. Once set up is done, we're ready to draw our RLE!

First we check what kind of data we have ....as discussed before, the second nibble is the RLE count... if the count is zero - then this byte is linear data. Otherwise we store the count for later

Now we load in the pixel data... two visually consecutive pixels on the CPC are not consecutive in RAM. To optimize the RLE compression we store in the file according to the visual layout, and bitshift into the correct position for the screen now. We also check the count... if the count is 15 (all bits of the nibble are 1) we read in the next byte as well, and add it to the count... if that byte is 255 then we keep reading in bytes and adding them to the count until one isn't!
We're going to fill the bytes of the screen with the nibble we read in, we have two versions of the code, so that whatever the position we need to plot our pixel pair to video ram, we can do so. If we've completed a line of the RLE, we recalculate the position of the start of the next line. We check IX to see when we've completed all the drawing for this RLE batch - once we're done we back up the screen pos of the current draw Note 'ByteNibbles' this is a special routine that will fill entire bytes with the nibble for extra speed.
We need some commands to allow for the starting of RLE data half way through a screen byte. These commands handle this, flipping E (the current nibble selection), and jumping to the middle of the loop

If there is a lot of RLE data left, it's faster to fill it in bulk, so we do that with the ByteNibbles function It's essentially just copies the C byte to the screen, decreasing the count by 2 each time, until theres only 3 nibbles left, then we switch back to the regular routine

If the 'RLE count' nibble is zero then the top nibble is a count for a series of bytes to be shown to the screen This is where we could not compress the data as an RLE, so we're storing it 'As Is' we need to shift the top nibble to the bottom, then (as before) if the count is 15, we load in more bytes to get the total count. Once we've got our count, we start reading bytes from the source, and writing them to the screen, checking for a newline until we've done all the bytes

We CALLED MultipushDE5... we're going to push bitmap data to the screen, so we need to get that return address out of there... we pop it into HL, and then do the 5 pushes... Once we've done, we effectively return, by Jumping to the address in HL that we popped earlier
The NextLinePushDE2 is just a pair of DE pushes... but execution falls into the code to calculate the start of the next screen line, and then falls into the jump code which runs the drawing routine for the next line

The NextLine Command will need to be modified if you're intending to use a second screen buffer, You will also need to reprogram the code if you want to reposition the sprite