Having settled on the use of the win2c64 compiler for now, I wanted to push ahead and continue getting my hands dirty with the 6502/6510 instruction set. I decided to write a simple routine that would clear the screen.

The first step I figured would be to write the basic version. It’s quite a straight forward routine. The default screen memory location starts at $0400 (or 1024 in decimal) and is 1024 bytes long. The first 1000 bytes is allocated for the screen characters (40×25) and these are the bytes I need to modify when clearing the screen.

For this routine, I figured I’d simply populate the screen with spaces to “clear” it. All the routine needs to do is poke the decimal value for space (32) into each screen character location.


With that done, it was time to look at writing an assembly version. For the first pass of this routine, I decided to use the Kernal “chrout” routine, located at $ffd2. To use it with the screen, you simply load the value you want to output into the Accumulator and then “jump” to that routine. It will then put the character on screen in the current cursor position. Since the “chrout” routine outputs to the current cursor position, it’s necessary to set the position of the cursor to the top left before we begin. This is done using the plot routine (another jump location in the kernal) located at $ffd0. The routine then uses two loops to output the correct number of spaces. Since we are dealing with 8-bit memory, the highest value we can store is 255. Hence the two loops instead of simply looping for 1000. This can be overcome however, but will look into this another time.

Another approach I thought I would try was to again use the chrout kernal routine, but this time output character 147, which is the clear home key code. This clears the screen and resets the cursor to the top left.

I don’t like using the kernal routines however as they are often slow. So I wanted to press on and see what I could do to improve it. The loops need to be improved to increase the speed. Writing multiple characters at the same time would save some loops. Thinking about it logically – I want to write 1000 bytes. This can be divided by 4 easily into 250. Can I loop 250 times (instead of 1000) and write 4 characters per loop? Yes, as we see in my next attempt.

This can be optimised by unrolling the loop completely, but would waste a lot of memory for something so simple and that is already fast.

I decided to have a quick look around online to see what other people had done and came across a similar solution. In this routine, the screen and border are both set to black first, before writing spaces to the screen character map.

I found this one interesting as it loops 255 times to write 4 bytes. This prompted me to look at the memory may around $1000 and see what the extra 24 bytes at the end actually are.

We know that the screen is located at $0400 (1024) and runs for 1000 bytes (to $07e7). The 16 bytes from $07e8 to $07f7 is unused memory, so writing over this has no effect in the context of this routine. The last 8 bytes are multipliers for sprite data (sprites 0 to 7) and runs from $07f8 to $07ff). Again in the contexts of this routine, overwriting this would be fine also. However in another program, these 24 bytes may be in use while a clear screen routine is running, so may not be safe to simply overwrite. It’s also additional clock ticks to clear these memory locations when it’s possiblt not required. It’s interesting though and I was glad to see I was on the right path for this.