A little while back I put up a small tutorial on making a 1×1 text scroller. This tutorial builds on that foundation and becomes a dynamic 4×4 scroller. Why dynamic? I use this term since it builds each 4×4 character as needed, based on a character from a 1×1 font set. I achieve this by using a matrix of 16 character “patterns” that make up all possible 4×4 bit combinations. This is handy in situations where you’re pressed for memory in your intro and can achieve a 4×4 version of the 1×1 font for only an extra 128 bytes in font data.
The first step is to source a 1×1 character set to use. You can either rip one out of an intro (or game) using a Vice snapshot and then import it to a tool like Charpad. Or you can download one of the many from here: http://kofler.dot.at/c64/. Either way, the goal is to have the data ready to include into our assembly file and will look something like this:
font_data .byte $00, $00, $00, $00, $00, $00, $00, $00
.byte $fc, $c6, $dc, $c6, $c6, $c6, $fc, $00
.byte $fc, $c6, $c6, $c6, $c6, $c6, $fc, $00
.byte $7c, $c6, $f8, $c0, $c0, $c0, $c0, $c0
.. and so on
In the source code provided with this tutorial, I’m assuming the character set contains 64 individual 1×1 characters. I have a script file (written in LUA) which exports the raw font data into the formatted “.byte” statements shown above. Depending on your choice in compiler, the format will vary.
Now we need to create a set of 16 character patterns that can be used to form any of the characters in the set. This is made easy by using a tool like Charpad. Basically we want to create a series of characters that cover every possible combination of 4×4 bits in a character. This totals 16 possible combinations and for this example, I’ve simply used small squares.
The order of these is important and they will be used to create a matrix which the scroller code to look up to display the correct character.
These 16 characters will also need to be output for inclusion in our assembly file and will be added to the end of our 64 1×1 characters that were exported above.
Now for some source code. Many of my intros & effects run under interrupts. The code will begin by setting up an interrupt to initialise the part and then run through an interrupt chain to handle the hardware scrolling, scrolling reset and scrolling update. The chain looks like this:
Something to note is the source code here is not optimised – there are some assumptions made to help simplify, but there is plenty of room for you to improve upon in your own implementations.
At the top of the source file, I have a few helper sub routines for preparing the screen for the scroller. These routines will be called from the initialise interrupt.
The first is to clear the screen ram:
clear_screen_ramroutine lda #032
ldx #000
clear_screen_ram_loop sta C_SCREEN_RAM, x
sta C_SCREEN_RAM + $100, x
sta C_SCREEN_RAM + $200, x
sta C_SCREEN_RAM + $2e8, x
inx
bne clear_screen_ram_loop
rts
The second sub routine is use to clear the colour ram:
clear_colour_ramroutine lda #000
ldx #000
clear_colour_ram_loop sta C_COLOUR_RAM, x
sta C_COLOUR_RAM + $100, x
sta C_COLOUR_RAM + $200, x
sta C_COLOUR_RAM + $2e8, x
inx
bne clear_colour_ram_loop
rts
Another block of code at the top of the source file is for apply_interrupt. This takes care of setting up the next interrupt in the chain. It assumes information about the next interrupt is stored in the 3 registers. It’s also responsible for acknowledging the current interrupt. The apply_interrupt_repeat label is for cases where we want to acknolowedge the current interrupt, and have it repeat again before advancing to a different inteerrupt in the chain. It’s not used in this example.
apply_interrupt sta REG_RASTERLINE
stx REG_INTSERVICE_LOW
sty REG_INTSERVICE_HIGH
apply_interrupt_repeat inc REG_INTFLAG
jmp $ea81
Now let’s initialise the program. First up we call the two sub routines defined above to clear the colour and screen ram. Then we want to relocate the character data to a spot in memory where it can be used. For this program, I’m going to store the character set at $3000 (C_CHARSET). Next I want to fill the colour ram where the scroller will appear with white. I also want to print a short message to screen using the 1×1 font. This is just to show a comparison of the 1×1 and 4×4 fonts at run time. Now it’s time to tell the C64 where to source its character data from & set the screen and border colours to black. That’s the set up done.
sync_routine jsr clear_screen_ramroutine
jsr clear_colour_ramroutine
ldx #000 ; relocate character data
relocate_font_data lda font_data, x
sta C_CHARSET, x
lda font_data + $100, x
sta C_CHARSET + $100, x
lda font_data + $180, x
sta C_CHARSET + $180, x
inx
bne relocate_font_data
ldx #160 ; init colour ram for scroller
lda #001
set_scroller_colour sta C_COLOUR_RAM + 759, x
dex
bne set_scroller_colour
ldx #019 ; render short message to screen
init_short_message lda short_message, x
sta C_SCREEN_RAM + 610, x
lda #014
sta C_COLOUR_RAM + 610, x
dex
bpl init_short_message
lda #029 ; switch to character set
sta REG_MEMSETUP
lda #000 ; init screen and border colours
sta REG_BORCOLOUR
sta REG_BGCOLOUR
jmp hook_update_scroller
The next bit of source I want to cover are the two small interrupts which handle the setting and resetting of the hardware scroll register. The first interrupt handler is in charge of applying the hardware scroll value. The interrupt triggers just before the scan line the scroller starts on. We set up the accumulator ready to apply the hardware scroll (and 38 column mode), wait for the scroller start line and then apply the value to the register. Something to note here is the “scroller_amount” label. During the scroller update handler, this label will be written to with new values based on the scroller progress. To start with though, it will be 7 (the maximum scroll amount) and contain values in the range of 0 – 7.
hook_apply_hw_scroll lda #201
ldx #<apply_hardware_scroll
ldy #>apply_hardware_scroll
jmp apply_interrupt
apply_hardware_scroll lda #$c0 ; 38 column
scroller_amount ora #007 ; + hardware scroll
ldy #202 ; wait first scroller scanline
wait_scroller_start cpy REG_RASTERLINE
bne wait_scroller_start
sta REG_SCREENCTL_2 ; apply hardware scroll value
jmp hook_reset_hw_scroll
The second interrupt handler is responsible for resetting the hardware scroller register and returning to 40 column mode. The accumulator is again set up, we then wait for the final scroller scan line to complete and then apply the value to the register. Both of these handlers are very light weight for this example.
hook_reset_hw_scroll lda #234
ldx #<reset_hardware_scroll
ldy #>reset_hardware_scroll
jmp apply_interrupt
reset_hardware_scroll lda #$c8 ; 40 column mode + no scroll
ldy #235 ; wait for final scanline done
wait_scroller_end cpy REG_RASTERLINE
bne wait_scroller_end
sta REG_SCREENCTL_2 ; reset scroll & column mode
jmp hook_update_scroller
The final interrupt handler to look at is the update scroller. This handler is where the magic in the scroller happens. Thankfully it’s not much more complicated than a 1×1 scroller. The same sort of logic applies. Decrease the hardware scroll until it’s negative. At that point we shift the screen ram contents to the left by 1 character and render a new character in the far right column. Then finally, we reset the the hardware scroll value and repeat. The difference between a 1×1 and 4×4 (apart from scrolling 4 lines of data) is instead of grabbing a new character from the message each time we scroll the data, we only grab the next character every 4 shifts. What needs to happen now is some bit masking, to work out which characters from our specially defined set of 16 to use. Do this for each of the 4 rows each time. Once we have rendered the 4×4 character, we then advance the message pointer.
First up, we advance the hardware scroll value. Here I’m advancing by 3 pixels every update. You can make the scroller slower by removing some of the dex instructions. Or you can increase the speed by adding more. We then detect if it’s time to physically shift the screen ram to the left. If not, the updated scroll value is written into a label in the apply_hardware_scroll interrupt handler and the update is complete.
update_scroller ldx scroller_amount + 1
dex ; advance hardware scroll
dex
dex
bmi shift_scroller_data ; time to shift scroller?
stx scroller_amount + 1 ; not time, so update scroll size
jmp update_scroller_done ; we're done for now
The next part of the update is in charge of scrolling the screen ram to the left. At this point we’ve detected that it’s time to advance the characters to the left. We do this for all 4 rows of the scroller.
shift_scroller_data ldy #000 ; shift screen ram left
scroller_shift_loop lda C_SCREEN_RAM + $2f9, y ; shift all 4 rows
sta C_SCREEN_RAM + $2f8, y
lda C_SCREEN_RAM + $321, y
sta C_SCREEN_RAM + $320, y
lda C_SCREEN_RAM + $349, y
sta C_SCREEN_RAM + $348, y
lda C_SCREEN_RAM + $371, y
sta C_SCREEN_RAM + $370, y
iny
cpy #039
bne scroller_shift_loop
The next two lines are where we detect at what stage of rendering we are at into the current character. When the example starts, the value in scroller_char_step will be 255 – a negative value – which means we need to get the next character in the message string. A little bit later in the routine, this value will then be set to 3 since there are 4 steps to render for each characters (3, 2, 1, 0). If the value is a positive (0 to 3), then we jump forward in the route to render the next column of data for the current character.
ldx scroller_char_step + 1 ; grab step into rendering bpl render_next_scroll_colm ; time to render a new character?
If the next block of code is reached, it means we’re grabbing the next character from the message string and preparing to render it. The label scroller_message_index holds the next index into the message string we will use. It uses this index to look up the byte in scroller_message. In this example, if a negative value is read from the message string, that means we have reached the end of the message and need to loop back to the start. If we have to loop, then the first character from the scroller message is read into the accumulator and the index set 1 for the next character to read. We also want to grab the high byte of the scroller_message label and reset where we are reading the message from. Why do this? Well the x register can only contain values from 0 to 255. For small scroller messages, this would be fine. What happens when we have longer messages? Once we advance to offset 256, the index will be reset to 0, so we advance the source high byte by 1 and continue on. This allows us to have very long scroller messages and once complete, just reset the high byte and our message will loop. You can also use all sorts of control characters to perform different actions in your scroller (for example – adjust speed, flash colours, etc).
scroller_message_index ldx #000
read_next_scroller_char lda scroller_message, x ; grab next character to render
bpl advance_scroller_index ; detect end of message
lda scroller_message
ldx #001 ; reset index
ldy #>scroller_message ; reset message ptr
sty read_next_scroller_char + 2
jmp save_scroller_index
If the above block of code was not required, then we can safely advance the message index for the next time through this code. Here it detects if the x register goes past 255 back to 0 and if so, advance the high byte of the scroller message pointer (as mentioned above). This will let us have long scroller text as the above block will reset the pointer (and offset) once it’s time to loop the text again.
advance_scroller_index inx ; advance scroller message index
bne save_scroller_index ; detect if reached 256 offset
inc read_next_scroller_char + 2
save_scroller_index stx scroller_message_index + 1
The final part of set up for the next character now happens. I’m making an assumption the character set will contain 64 characters. That means the character set is split into 2 x 256 byte blocks (32 chars * 8 bytes = 256). Therefore, when rendering, we need to know where the font data is so we can use a bitmask against it and render the correct characters. That means the high byte will either be #$30 or #$31. We also need to know the low byte of where to read the character data from. Once we know the high byte, we AND the character code so the value is between 0 and 31 before multiplying by 8 to give us the low byte. The values are then stored into the rendering code as they will be required for each of the 4 steps (remembering 4 characters – steps – for each 1×1 character). The bit mask is reset to 192 (binary – 11000000 – so we start with the two left most bits) and the step counter set to 3.
ldy #>C_CHARSET ; char in which charset half?
cmp #031
bcc calc_scrollchar_src_low
ldy #>C_CHARSET_HIGH
calc_scrollchar_src_low and #031 ; calc offset into char data
asl
asl
asl
sty render_scroller_column + 2 ; store pointers for render
sty render_scroller_column2 + 2
sta render_scroller_column + 1
sta render_scroller_column2 + 1
lda #192 ; reset scroller char mask
sta scroller_character_mask + 1
lda #003 ; reset step into char mask
sta scroller_char_step + 1
Remember, the above code blocks are only done each time we move to the next character in the message string. At this point, our setup for the next character is done – time to do some rendering.
First up we reset the hardware scroll value. We simply add 8 onto the current value (which will be a negative value as that’s what will trigger this code to run) and will leave us with the next scroll value. If we were only scrolling by 1 pixel each time, then this could just simply set the value to 8. But because this example scrolls by 3, there are multiple possible values it would have to reset to for the next frame. So simply adding 8 means it will always move to the hardware scroll value to the next correct value.
render_next_scroll_colm clc
lda REG_ZERO_FE ; reset hardware scroll
adc #008
tax
stx scroller_amount + 1 ; save index
We’re almost there now – all the set up work is done and it’s time to actually render something to those 4 characters on the far right of the scroller. First up we set up the screen offset and character source byte index values to be 0. The screen offset value is stored on the zero page in $fd. This value will have 40 added to it each time through the loop as we render each of the 4 characters on the right side of the screen. Because each character to render represents a 2×2 bit segment of the character, we need to look at two bytes of character data for each character we render to screen. The current bit mask is applied and the result shifted down until the 2 bits are in bits 0 and 1. This leaves us with a value between 0 and 3. This is the first part of the look up value and is multiplied by 4. Why 4? Remember earlier I said the order of the 16 characters we created was important? Here is why. Have a look at the 4×4 character table earlier in the post. Notice that the top two blocks on the first 4 characters are blank (this is 00). Then in the next row it’s 01, then 10 and then 11. This is 0, 1, 2 and 3. That’s why the order is important. This first component of the look up tells us which row of our custom characters to use. The next byte of character data is read, the same bit mask applied and value again shifted down to bits 0 and 1. The second calculated value is now added to the first, which gives us our completed index into the 4×4 character matrix. We add 64 since our 16 custom characters start at screen code 64. The value is then rendered to the screen. This is repeated another 3 times until the column has been rendered.
ldx #000
stx REG_ZERO_FD ; reset screen offset
render_scroller_column lda C_CHARSET, x ; load source byte
scroller_character_mask and #192 ; apply mask
scroller_char_step ldy #255
beq skip_shift_1 ; no shift if masking bits 0 and 1
shift_scroll_mask_loop1 lsr ; shift down to bits 0 and 1
lsr
dey
bne shift_scroll_mask_loop1
skip_shift_1 asl ; mul by 4 - look up char matrix
asl
sta REG_ZERO_FE ; cache to recall shortly
inx ; advance to next byte in char ram
render_scroller_column2 lda C_CHARSET, x
and scroller_character_mask + 1 ; apply current mask
ldy scroller_char_step + 1
beq skip_shift_2 ; no shift if masking bits 0 and 1
shift_scroll_mask_loop2 lsr ; shift down to bits 0 and 1
lsr
dey
bne shift_scroll_mask_loop2
skip_shift_2 clc ; calc char code to use in 2x2 block
adc REG_ZERO_FE ; grab offset calculated earlier
adc #064 ; add offset to the character matrix
scroller_render_offset ldy REG_ZERO_FD
sta C_SCREEN_RAM + $31f, y ; render character to screen
tya
adc #040 ; advance offset for next loop pass
sta REG_ZERO_FD
inx ; advance next byte in char ram
cpx #008 ; entire column rendered?
bne render_scroller_column
All the hard work is now done. The final part of this routine advances the scroller step value and also shifts the bit mask to the right by 2 bits, ready to render the next column of the character. Then we’re done. We now have a routine that will generate a 4×4 scroller of the 1×1 font, rendering each character on the fly.
dec scroller_char_step + 1 ; advance step lda scroller_character_mask + 1 ; advance mask lsr lsr sta scroller_character_mask + 1
Hopefully I’ve explained this well enough for you to follow along. There are quite a few comments through out the source code too (more than shown in snippets above) which should help with further understanding of what’s going on.
You can view the source on GitHub here: https://github.com/0xc64/tutorials/tree/master/scroll4x4
The source and compiled .prg file can be downloaded here: scroller_4x4.zip
This is my first tutorial where I’ve used a code plug in to help colour the syntax (instead of posting images of the source). Hopefully this is more useful for people too.
That brings an end to the tutorial. Hopefully it’s been helpful 🙂 There are a number of things you can easily do to pretty this scroller up. Why not add an FLD (Flexible Line Distance) effect just before the scroller start to make it bounce? Or add colour cycling to the colour ram behind the scroller? Or use an inverse set of characters and render some raster bars behind it? Those are just a few ideas – there are plenty more. You can expand this example to render an 8×8 font easily enough too and animate the characters (see my intros “We Are” and “Ursa Minor” for examples of this).
If you want to contact me, there is a 0xc64 Facebook page here: 0xc64 Facebook and I’m also on Twitter here: 0xc64 Twitter
I’m hoping 2017 will be a more productive year for me on the C64 front – so hope to have more tutorials and content coming soon 🙂