While in the previous article I was only philosophizing, in this one, I’m getting somewhat less theoretical. It’s still a ways away from having working code, though.

I found an answer on the Retrocomputing Stackexchange site, explaining how software sprites “work”. In my own words:

Sprites are rectangles of image data that are put in video memory, so the video processor can display them on a video screen. Sprites always need one of the colors to be transparent (invisible). In a two-color display that usually is black (0), while the visible color is non-black (1). The invisible color could be considered the background color, the visible color the foreground color. However, with a background drawn on screen, things can get confusing.

To enable mixing of sprite images with the background image, for every sprite image there should be a mask to punch a whole into the background. The mask contains 0s where the sprite image is visible; 1s where the sprite image is transparent. It makes sense to precompute mask data for efficiency.

Sprite data is drawn on top of image data. First, the background is masked out where the sprite will appear, resulting in a “hole” in the background. Second, this hole is filled with sprite data. Of course, if the sprite was moved, the original background image of that previous location should be restored too.

On older PCs (read: in certain display modes) colors are planar, which means that each color is stored in its own block of memory, instead of combined into a single memory block (one or more bytes of color information per pixel). Each color plane has to be processed first by punching a hole with the same mask and then filling the hole with sprite image data, specific for that color.

The (generic) algorithm for drawing sprites is as follows:

1. erase the previous position, if any, by copying the original background at the previous location
2. establish the address of the rectangle in video memory where the sprite should appear
3. apply AND with the mask on this rectangle to “cut” data behind the mask; now there is a hole in the background where the mask is
4. apply OR with the sprite image data to insert it into the background image; OR will only draw inside the cut mask

On the C64, things are quite different if bitmap graphics is to be ignored (too slow in most cases). In two-color (monochrome) character display, there are 1000 character positions (25 lines of 40 characters). The characters can be programmed by changing their image data (8 rows of 8 columns of pixels). In character generator memory, blocks of 8 bytes (8 by 8 pixels) are stored for each of the 256 characters that are in a character set. To display a character, its code is stored in screen memory, depending on the character’s location (column and row) on the video screen.

Let’s imagine a single 8 by 8 character (organized as 8 rows of 8 bits, 64 bits in total). Since the characters don’t represent text, but rather images, it’s probably better to refer to them with the more generic term “glyph”. A glyph can be a character, but also an image, e.g. a sprite.

To remove a sprite from the previous position, the previous glyph code that represented the background in that position is put back in screen memory. The background glyph code should be stored somewhere separately if it isn’t possible to determine that code from its position alone.

To put a sprite in its new position, some bit manipulation has to be done, combining the original image data of the background glyph with that of the sprite and store the result into image data for the glyph that displays a sprite-on-background.

The data structure that contains a sprite could look something like this:

• memory address in screen memory (2 bytes)
• background glyph code (1 byte)
• sprite-on-background glyph code (1 byte)
• sprite image data (8 bytes)
• sprite mask image data (8 bytes)

That is 20 bytes in total for displaying a single 8 by 8 square of pixels. That could be 8 bytes less if the sprite mask image data is computed on the fly.

From the steps above in the general case, the C64-specific steps would look like as follows:

1. if the sprite was already being displayed, write the background glyph code into the memory address in screen memory
2. calculate the current memory address in screen memory, based on the given sprite location
3. store the glyph code in the memory address in screen memory in the background glyph code
4. AND every of the 8 bytes of mask data with the corresponding bytes of background image data, as determined by the background glyph code and store the result in the 8 bytes of image data for the glyph that displays sprite-on-background
5. OR every of the 8 bytes of sprite image data with the corresponding 8 bytes of the sprite-on-background image; store the result back into the sprite-on-background image
6. write the sprite-on-background glyph into the current memory address in screen memory

That is a lot of overhead and storage space for sprite the size of a single character of text. If the sprite needs to be able to be moved left and right, up and down, with the resolution of a single pixel, things can get even more complicated and require even more resources (instruction cycles and storage space). It’s doubtful if this kind of accurate positioning is sensible, if one could use hardware sprites for pixel-wise movement instead.

I’m curious how this could be coded, and then recoded for efficiency (storage-wise and/or instruction-cycle-wise). I’m sure it depends on what is needed for the game.

To make it more interesting for video games, one would like to introduce colors, like in multi-color character mode, and bigger sprites. I might not get to this, because monochrome character mode seems daunting enough for me.

Visited Palace Het Loo yesterday. Just in case, I reminded myself of the Sphinx riddle here. I didn’t take much pictures of this former royal residence, now museum, because I was after good impressions, not documentation. I was sightseeing, after all. Made me a little more pro house of Orange. 🇳🇱

My iPad is having issues. I already have powered down and up again twice this week because of lack of responsiveness. I suppose it could be that the CPU is being slowed down to compensate for an elderly battery, or whatever goes on in the proprietary iPadOS from Apple 🤷‍♂️ Who knows, who knows…

While reading through some articles about hardware sprites, sometimes called movable object blocks (MOBs), I realized that the C64 is probably too slow to move software driven sprites. In 1/60 s at ± 1.02 Mhz there are 17000 instruction cycles for an interrupt, or (17000 / 4 =) 4250 average instructions per interrupt cycle.

A typical copy operation is with zero page indexed addressing in a loop requires 14 instruction cycles per copied byte. Add to this a bit shift in a buffer (add another 4 cycles), and an area of 32 by 23 pixels to hold a 24 by 21 pixel MOB, then a back of the envelope calculation gives us (4 x 23 x 18 =) 1656 instruction cycles per pixel shifting MOB, at 60 fps. With nothing else to do, that would give us (17000 / 1656 =) 10 MOBs at most.

If the Kernal is supposed to do something, like being able to run Basic, then it’s probably feasible to maintain 3 MOBs at most.

Another calculation. What if one wanted to fill a whole screen, all 1000 bytes at 14 instruction cycles per byte? With the interrupt disabled, that would make a refresh cycle possible of at most 1/7th of a second, which is clearly noticeable. It makes sense in that case to use a frame buffer, and switch buffers after a buffer has been updated. This would enable slowly animating backgrounds, in other words, choppy animation, which could be interesting in some cases. There wouldn’t be any redrawing of the screen, breaking suspension of disbelief in most players.

Of course, it’s possible to rewrite only a part of the buffer, so the frame rate can be increased. Using the estimated 3 MOBs per 1/60 s. That is ((4 MOBs of 23 rows of 4 bytes) / (40 bytes per line) =) 9 lines per 1/60 s, or around (9 / 25 ≈) ⅓ of the screen which can be believably animated using a frame buffer. This needn’t be a contiguous areas. Disparate parts of the screen could be animated, at some instruction cycle cost to update zero page pointers to new values.

I should emphasize, this is all theoretical (philosophical?) and for 2-color MOBs. With multi-colored MOBs more bytes need to be updated, reducing the frame rate by at least 50 percent. The “claims” above have to be proven by code first.

It was fun dreaming about such an endeavor, and see what the possible limits would be. For snappy code, one should really disable the Kernal interrupt routine, and use one’s own instead. I suppose this is why most video games require a reset to return to Basic. If Basic has to coexist, it will limit what kind of games can be played. Fast moving action-based games are probably not among those. In that case, you’re probably already committed to using hardware sprites.

I have a very unoptimized way to fill a rectangle on a C64 video screen with characters, as in a MOB (movable object) instead of a hardware sprite. It’s around 25 times faster than using Basic, and has “frame rate” of around 12 fps on a 50 Hz monitor. I’m sure it can be much faster. 👨‍💻

I was looking through the Commodore 64 Programmer’s Reference Guide, in the chapter about graphics, how I could POKE screen codes to the screen, so to speak, in 6502 assembly. Here is what I came up with.

First of all, what do I mean with “POKE” and “screen codes”?

POKE is a CBM Basic 2.0 command, also available on many Microsoft Basic variants on 1980’s and 1990’s home computers. It allowed the programmer to place a value anywhere in the 64 Kb of memory addressing space available to the Central Processing Unit (CPU, which is the 6510, a variant of the 6502). Since the screen in the default configuration is located at memory addresses 1024 to 2023, one could put a value A into column C and row R as follows:

POKE 1024 + 40*R + C, A

where:

• 0 <= R <= 24
• 0 <= C <= 39
• 0 <= A <= 255

This is all well and good, but it seems rather slow, even if we invoked these commands in 6502 machine code. I’ll come to that later.

Screen codes are Commodore specific values, which are used internally to represent characters. There is a direct correlation between a screen code an its position in the character ROM. The codes are different than the codes used for printing (which codes are collectively called PETSCII, Commodore’s own version of ASCII). For instance the letter ‘A’ is the value 1 in screen code and 65 in PETSCII.

Why do I even want to POKE screen codes to the screen, if the same can be done using PETSCII and printing? Well, I want to put blocks of screen codes onto screen, using a self-defined character set, to use for a video game. In that case the Basic commands and even the routines in the underlying operating system (Kernal) are just too slow. I need custom routines to put screencodes onto screen.

So I started to explore what is needed.

It seems the video chip, the VIC II, can only “see” a quarter of the 64 Kb of addressing space, i.e. 16 Kb, in four banks:

• bank 0, $0000 - $3FFF (default)
• bank 1, $4000 - $7FFF
• bank 2, $8000 - $BFFF
• bank 3, $C000 - $FFFF

This is controlled through bits 0 and 1 of data register A (DRA) of the Complex Interface Adapter (CIA) chip. There are four possible values:

• %11 VIC II bank 0 (default)
• %10 VIC II bank 1
• %01 VIC II bank 2
• %00 VIC II bank 3

So bits 0 and 1 have to be inverted to get the binary value of the VIC II bank. Furthermore, in order to read data register A, their bits have to be set to zero selectively in the data direction register (DDRA) for data register A. All the other bits of DDRA have to left alone.

Within the 16 Kb available at one time to the VIC II, there are 16 possible relative locations of screen memory (25 lines of 40 characters, or 1000 bytes):

• $0000 - $03E7
• $0400 - $07E7 (default)
• $0800 - $0BE7
• $0C00 - $0FE7
• $1000 - $13E7
• $1400 - $17E7
• $1800 - $1BE7
• $1C00 - $1FE7
• $2000 - $23E7
• $2400 - $27E7
• $2800 - $2BE7
• $2C00 - $2FE7
• $3000 - $33E7
• $3400 - $37E7
• $3800 - $3BE7
• $3C00 - $3FE7

The relative base address of screen memory is controlled by the lower 4 bits of register 24 of the VIC II. Again, only these bits should be manipulated, while the upper 4 bits should not be changed for selecting the screen location. Of course, I am only reading the bits, so I’m safe in that regard.

The Kernal has (half) a pointer to the full address of the beginning of screen memory, the high-byte. This pointer is stored in location 648 ($288). I can either use that, or calculate it myself.

• $288 (648): high-byte of pointer to the base of screen memory

Of course, if I would relocate the screen, I would have to change this pointer in my code, so there’s value in knowing how to calculate this high-byte, even if it isn’t needed if I don’t change the screen location in memory. I could just as well use the value in $288.

I calculated the high-byte of this pointer as follows:

; some addresses defined

vicmemptr       eqm $d018       ; VIC II memory pointer register
cia2rega        eqm $dd00       ; CIA 2 register A
cia2ddra        eqm $dd02       ; CIA 2 data direction register A

; determine location of screen memory
; returns .A hi byte of base address of screen memory
; modifies .A, flags

screenbas:

                ; determine the VIC II base address

                lda cia2ddra    ; set
                and #%11111100  ; bits 0, 1
                sta cia2ddra    ; of reg A to "read"
                lda cia2rega    ; read reg A
                and #%00000011  ; only bits 0, 1
                eor #%00000011  ; invert bits 0, 1
                lsr             ; optimization -> shift into bits 6, 7
                ror             ; in effect, multiply by 2^6
                sta screenb1+1  ; self-mod code

                ; determine location of screen memory inside the 16 Kb VIC II bank

                lda vicmemptr   ; get
                and #%11110000  ; upper 4 bits
                lsr
                ror             ; make it hi byte * 2^2

                ; add base address of VIC II to relative base address of screen memory

                clc
screenb1:       adc #$ff        ; self-modded
                rts

I hope you didn’t mind my code self-modification trick, but it does work in RAM. In ROM one would do it differently, naturally.

Now I know where the screen is located in memory, how can I put a screen code into a particular column and row? There are 40 columns and 25 rows, numbered from 0 to 39, and to 25, respectively. This means the memory location, based on column and row value can be calculated as follows:

• screen base + column * 40 + row

I’ll use indirect indexing to point to this address, where the .Y register serves as the index:

                 sta (putadr),y ; store it in the yth column

where putadr holds the address of the first row of the column on screen. The .Y register then accesses the Y-th column in the instruction above. It makes sense to store the column value in the .Y register (the same as the Kernal does).

Adding address values is pretty straight forward, but how to calculate times forty?

Remember that the 6502 has a shift left instruction, which is equivalent to multiplying by two. So, with some shifting and adding it is possible to get to times forty quicker than doing it traditionally (multiply two 8-bit values into a 16-bit value):

• value * 40 = ( value + (value * 2^2) ) * 2^3

That is 5 left shifts and 2 additions. However, while five times a column value still fits into a single byte, multiplying it by 8 doesn’t fit in that single byte anymore. At that point two bytes are needed.

Here is the code:

; put screen code onto screen
; parameters:
;     .A screen code
;     .Y screen column, between 0 and 39
;     .X screen row, between 0 and 24
; returns:
;     carry flag set means an error occurred
; all registers are affected
; bits 0, 1 of DDRA of CIA 2 ($DD02) are set to zero (read)
; zero page $02, $03 are used

putadr:          eqm $02        ; 2-byte screen address

putonscn:        cpy #40        ; column >= 40 ?
                 bcs putexit    ; yes, then exit w/ error
                 cpx #25        ; row >= 25 ?
                 bcs putexit    ; yes, then exit w/ error
                 pha            ; save for later
                 stx putadr     ; initialyze screen address
                 txa            ; transfer row to .A
                 asl
                 asl            ; row * 2^2
                 adc putadr     ; row * 2^2 + row
                 sta putadr
                 ldx # 0        ; zero hi byte
                 stx putadr+1   ; of screen address
                 asl
                 rol putadr+1
                 asl
                 rol putadr+1
                 asl
                 rol putadr+1
                 sta putadr     ; (row * 5) * 2^3
                 jsr screenbas  ; add hi byte of screen base address
                 adc putadr+1
                 sta putadr+1   ; baseadr + (row * 40)
                 pla            ; get screen code back
                 sta (putadr),y ; store it in the yth column
                 clc            ; no errors
putexit          rts

To check if this code actually works I added a combination of assembly and Basic language, so it could run from the Basic prompt on the Commodore 64 with the RUN command.

It working made me a happy coder.

On the C64, using the Kernal, you can set the cursor position (one routine) and then print a character (another routine). I wanted a single routine to put a screen code onto the screen, at a particular colomn and row, wherever the screen was located in memory. So I wrote it, and it works, yay! 👨‍💻

I installed droid64, a Java application to manipulate Commodore disk images and copy files between your host OS and a disk image (e.g. a file with a D64 extension). I needed it to be able to play new games. I also put a SPEEDLINK SL-650212-BKRD Competition PRO USB joystick on my Amazon wish list 🎮

It is said, by some, that there’s nothing magical about January 1. So resolutions seem rather nonsensical, at least, putting a start date on something. Just start, which is what I just did, by writing and publishing this blog post. And, I warn you in advance, I will ramble and meander through my “ideascape” (if that’s even a word—it now is).

As announced in my previous post, and I’m still calling it that, my self-challenge is called 366 Days of Coding. The year 2024 will become the year that I finally produced a video game. I’ve tried many times before, but was held back by lack of confidence, mostly. I’ve worked on that in 2023, and my improved mental hygiene should give me the protection against self-doubt I need.

Now how is this going to work, what will be my general overarching workflow? Well, I don’t know… I’ve never been much of a planner. I always let deadlines pass by, and brushed it off as proof that I’m worthless, because, well, see! That’s no way to live. First of all, seeing how long indie games are in beta, testing and debugging seems a rather important part of software development. Also, it’s good to have a second opinion to rely on, which means beta-testers. However, on my first try I’ll have to do most of that myself, since I lack any reputation to call for outside help, and actually receive help.

I can imagine it’s like writing one’s first novel. It takes such a long time, because a lot has to be learned, especially accepting outside help from a closed reader group, who give positive feedback on one’s writing. In that first attempt, as a new writer, I guess most figure that out for themselves, perhaps by using a partner or close friends as “guinea pigs”, or whatever is available to them. Purposefully looking for a group of dedicated beta-readers, often means one has been oneself first. I suppose being an avid reader is a prerequisite for becoming a writer, why else would one even want to write a book? In fact, helping a writer out with positive critique may give the critic ideas on how to become a writer themselve. From that perspepctive, gathering a group of beta-readers seems to me like paying something forward, from the writer’s point of view.

However, there are many more readers of books than there are players of retro-games. It’s a self-selecting group of mostly older people with nostalgia, and younger people who can identify with the old times, as an esthetic. They will be opinionated, perhaps even rude, since they are far off the beaten path, into a barren land (space-time, actually) that once was great and thriving, and only is accessible through personal memory and documentation (books, magazines, videos, etc.). On the other hand, retro-gaming is having a revival, as all things eighties of the previous century. Things in the current news are rather grim, and there is certainly a hunkering for the good old days, even in those who never lived through those.

So, however I will go about things, testers are an essential part of software development. After all, a video game, like a book, is to be experienced by others than the author/creator. It makes sense to accept input by those others, not what or how to make something, but how they experienced what you made. Still, there are always those who think they know better than you, and offer how-to tips. They might know better, but you are the person making, on your terms, schedule and responsibility. Whatever you make, it is always a compromise between what you aim at (aim as high as you can), how much time you have (besides daily chores, work, etc.), and what you can put up with and still enjoy it (mostly).

If you have no idea of the final product, don’t have the time, and don’t like the process, this is not for you.

I have some ideas what to make, so many, that I need to pick one. My first task, then, is to explore the world of indie gaming on retro computers, briefly (!), and see what I like and don’t like. There are no original ideas—well so few that they don’t stand out—but there are original spins on existing ideas. With a shortlist of ideas I can think about what my take would be. This will lead to an opinionated product, some will like, others won’t. That is a good thing, since you don’t want a bland product no one hates, but also no one prefers. You can’t please everyone. Heck, it’s hard to please anyone nowadays, with the world being as polarized as it currently is.

After having a list of possible ideas, it’s time to prototype, and see what appeals to me. This is often done on paper or in a design document, rough, yet playable, if you do the mechanics of the game yourself. In the final game this is all automated, but in this rough stage, you are the driver, leaving room to change mechanics on the fly.

Now comes the hard part, picking and committing. You can always go back and pick something else once you hit a dead end, but that shouldn’t be par for the course.

What comes after that is still blurry to me, because I’ve never done something like this before. I’m sure to keep you posted once I discover the intricacies of game development, at least, how I perceive those. This is an experiment of one. You shouldn’t copy someone else’s workflow, but, instead, learn from it, to improve yours. This doubly applies to a newbie like myself, looking at how other, more seasoned developers go about things.

It will be educational. Of that I’m sure.

Thanks for sticking with it until the end of this thought piece. I’m sure I got most things (slightly) wrong. Please feel free to comment and enlighten me with your bright ideas, maybe suggest (parts of) how to do what I’m planning to do. I’m sure I will learn something from it, and, reciprocally, by formulating your ideas in clear words, you might as well.

I redid the random maze program in assembly language. If you load and RUN the program, it displays the maze, waits for the user to press a key, then clears the screen and returns to the BASIC prompt. It’s simple, but it made me proud nonetheless that it actually works.

Two very eager feline buddies 🥰

I have found a better way to assemble 6502 code than Virtual 6502 Assembler. I installed DASM from the official Pi OS repository on my Raspberry Pi-400, rewrote the KickAss source code, and assembled that into a BASIC loader program. Took long, because of differing assembler directives, and a nasty typo 🤬

The file I assembled and downloaded as a .PRG file, using the Virtual 6502 Assembler, I smart attached in the V.I.C.E. C128 emulator. I then attached an empty .D64 disk file, and used Basic 7.0 to save memory location $C000 to $C12F to a binary file, called “usrfunc04.c000”. I detached the .D64 file, and closed V.I.C.E. C128. In the C64 emulator I rewrote the previous C64 Basic program so it loads this binary file from disk. It then proceeds to checking of primality of numbers between 0 and 65535. I saved this Basic program to the same disk as the binary file, and copied it as text in the listing below.

[ part 1 | part 2 | part 3 | part 4 | part 5 ]

It was a bit of a hassle, but it all works, and that’s what counts here.

0 rem testusrf-0-4.bas
1 rem version 6 - test completed usr function
10 on s goto 20,40
20 print "loading binary file...":print
30 s=2:load"usrfunc04.c000",8,1
40 poke 785,0: poke 786,192:rem usr function at $c000
50 print "... (tests between 0 and 65535)":print
60 for n=0 to 65535
70 m = usr(n)
80 print n;"is ";: if not m then print "not ";
90 print "prime"
100 print "any key to continue"
110 poke 198,0:wait198,1:poke198,0
120 next n

I had to search for a particular Commodore 128 command, and found it here, which, BTW, I typed in myself from a book, and corrected many errors in that book. It now is the definitive guide on the web for Commodore 128 retro-computer users. It is anonymous, though, since I haven’t written the book.

In the Commodore 64 Programmer’s Reference Guide, published by Commodore Business Machines, Inc. and Howard W. Sams & Co., Inc. in 1982, there is a chapter on programming graphics with history’s most popular retro-computer. Graphics are an essential part of computing, and understanding how it works under the hood is essential for the C64, since it has no Basic commands to manipulate graphics. It all has to be done with PEEKs and POKEs.

I want to use C64 graphics to create a simple game, maybe a few games. There are a few characteristics to a video game:

• introduction screen (typically colored bitmap graphics) while loading the code and assets
• game area, which has to be somewhat fast, which rules out bitmap graphics, instead what’s mostly used is:
  • standard character mode with programmable characters for black and white games
  • multi-color character mode with programmable characters for color games

Modes can be mixed, using interrupts when the electron beam isn’t displaying anything. Of course, this is an advanced programming technique, and doesn’t always render perfectly.

On top of that there are hardware sprites, all 8 of them, but those can be multiplied virtually, by moving them lower on the screen after they have been displayed by the VIC-II chip. It all comes down to timing, and, hence, using optimized 6502 machine language. Sprites, since they are moving, can bump into each other, which is only possible doing convincingly using machine code. It seems all very exciting and challenging.

If the world of the game is larger than what fits on a video screen, side scrolling can be used. Side scrolling is a video game genre in its own right. There’s also free scrolling, where the screen is a window on the game world that can move up, down, left and right.

Since there is a limited amount of memory in the computer, it makes sense to use repeating patterns to represent the game world. The screen then exists of tiles of the same content, which together represent grass, forest, pavement, etc. It is part of game design.

The game logic could be written in Basic, though, since it doesn’t have to be so snappy, responding to user input. This also allows users to modify the game, which is a bonus, in my opinion. However, in order for Basic to work, RAM becomes inaccessible while Basic and Kernal ROM is being switched on, to enable Basic to run. There are ways around this, since, while switched away, RAM is still available, can even be written to, just not read from (and not be used while a Basic program runs).

The thing is, that the Commodore 64 is a very quirky computer, with many restrictions, that can be worked around, but need special attention from the coder, in other words, creative solutions.

To not get bogged down by details, maybe it’s more effective to start simple, and only make things more complicated if there’s a need for it. It’s better to write a minimal viable solution than keep putting off finishing, because it could be “so much more awesome.” Yes, it would, but will it ever see the light of day? Like real artists, real software developers ship.

Even games written in Basic can be quite appealing. Sometimes Basic isn’t fast enough, and in those cases one can use some machine language to speed things up. Games completely written in 6502 assembly language are often developed on another computer. Nowadays that would be a Mac or Windows computer.

The idea that the game player can change things appeals to me. Of course, that needn’t be in Basic. There are other programming languages. A popular one nowadays is Lua (free and open source, easy to implement in your own code). However, Basic is already there, so why not use it?

This is going to be a long haul, isn’t it?

Since it probably is, it would be such a nice goal for the end of 2024 to have developed and published a game for the Commodore 64, one I feel proud of.

Who knows, it might even be several games. For now, being realistic, let me stick to promising that I will finish at least one game.

However the gaming dice will roll for me, 2024 will be my “266 days of coding.” Yep, it’s a leap year.

Oh wow! I went to Github.com on my iPad, clicked on one of my repo’s, connected an USB keyboard and pressed the period key “.” 🤯

Here’s an exercise from the book “Programming the 6502”, 4th edition, by Rodnay Zaks.

Exercise 1.12: Complete the following additions. Indicate the result, the carry C, the overflow V, and whether the result is correct or not:

10111111  (_______)
11000001  (_______)
------------------ ﹢
________  (_______)

V:____ C:____
[ ] CORRECT [ ] ERROR

11111010  (_______)
11111001  (_______)
------------------ ﹢
________  (_______)

V:____ C:____
[ ] CORRECT [ ] ERROR

00010000  (_______)
01000000  (_______)
------------------ ﹢
________  (_______)

V:____ C:____
[ ] CORRECT [ ] ERROR

01111110 (_______)
00101010 (_______)
------------------ ﹢
________  (_______)

V:____ C:____
[ ] CORRECT [ ] ERROR

To say that this was easy to transcode in Markdown/HTML would be a grand understatement. My “code editor”, the Drafts app was fighting me all the way, and, while split view was showing me the PDF of the book in the Documents app, Apple’s native Files app was having a grand mal. So much so, that I had to reboot my iPad to get the Files app unjammed (it was completely locked up, unresponsive, frozen). I guess the 9th generation iPad isn’t cut out to do any “professional” work, like code-editing HTML 😅

I suppose if there was ever a reason to need a more pro version of the iPad, here it is. I guess an iPad Air would do much better, even if it costs twice as much as the “primary school iPad”—cough—iPad 9th generation.

I have a Raspberry Pi-400, but it has drawbacks as well, a gleaming one being lack of any good application software. Linux on the desktop is always “just a year away”, permanently 😉

I’m told 2024 will be “the year of the iPad.” I’m hoping it is, because not only is my current iPad underpowered, its battery also is getting old. You see, I’m not using it casually, as a beginner iPad user, but as a full-fledged work computer, so to say. In a school setting it would’ve been replaced, no doubt, or, at least, sent to an authorized Apple Service Center for maintenance & repair.

So, yay for 2024, may it bring me a nicer iPad.

🙄 I’m such a consumer, totally in the Apple camp of things…

I’ve rewritten the code I developed earlier and extended it into a full-fledged usr machine language routine. However, it needed testing, because of all the rewrites. So I grabbed my copy of Working Copy on my iPad and started Git-versioning both the assembly and the Basic code. It was invaluable for getting the code to work correctly.

[ part 1 | part 2 | part 3 | part 4 | bonus ]

Here are some of the major changes I made:

• the input and output of functions now use the .A, .X and .Y registers
• the prime function now picks out of a list of all the 54 prime numbers that smaller than 256
• a main routine was added that tests the primality of the value put into the usr function in Basic, and returns either a zero (false) or minus one (true)

After every part was tested, I ended up with a collection of documents, I’ll share next. These are the algorithm, assembly code, and Basic test program (the machine code already loaded in locations $c000, or 49152, and higher). I did away with a machine code loader in data statements, because that became too much of a chore. The point of this whole exercise was to learn something about coding for the Commodore 64, particularly in 6502 assembly language.

And that I have accomplished. It isn’t the most efficient 6502 machine language routine, but it does work. And that always makes me happy 😃

"usrfunction-0-4.asm"

; usrfunction-0-4.asm

        getadr = $b7f7
        givayf = $b391
        
        *= $c000
        
                jsr getadr      ; convert real into unsigned int 
                                ; in .A & .Y (hi/lo)
                sty testnum     ; save for later use
                sta testnum+1
                ldx #$00
                stx isprime     ; assume it is not a prime
                cpy #$02        ; is testnum less than 2?
                lda testnum+1
                sbc #$00
                bcs okay        ; testnum >= 2
                jmp foundit     ; no, then output value of isprime
        okay:

        ; test if test number is equal to one of the prime numbers

                ldx #53
                stx order       ; start with 53th prime
        loop1:        
                ldx order
                bmi loop1x      ; if < 0 then exit loop

                jsr prime       ; get nth prime in .X
                cpx testnum     ; is testnum == prime?
                bne loop1a      ; no, then next prime
                lda testnum+1
                bne loop1a

                ldy #$ff        ; yes, then
                sty isprime     ; it is a prime
                bne foundit     ; skip to the end
        loop1a:
                dec order       ; try previous prime
                clc
                bcc loop1       ; continue loop
        loop1x: 
        
                lda #$ff
                sta isprime     ; assume testnum is prime
                
                lda #$00
                sta order       ; start with 0th prime
                
        loop2:
                ldx order
                jsr prime       ; find the nth prime
                stx temp        ; store for later use
                txa
                jsr square      ; square the prime
                
                cmp testnum     ; prime * prime == testnum ?
                bne loop2a
                cpy testnum+1
                bne loop2a
                ldy #$00
                sty isprime     ; yes, then it is not a prime
                beq foundit
                
        loop2a:
                cmp testnum     ; is prime * prime > testnum?
                tya
                sbc testnum+1
                bcs foundit     ; then exit the loop
                
                ldx temp        ; prime is divisor
                lda testnum     ; testnum is dividend
                ldy testnum+1
                jsr modulo
                
                cmp #$00        ; is remainder zero?
                bne loop2b      ; no, then next prime
                cpy #$00
                bne loop2b
                ldy #$00        ; yes, then
                sty isprime     ; it is not a prime
                beq foundit
                
        loop2b:
                inc order       ; try next prime
                clc
                bcc loop2       ; continue loop
                
        foundit:
                lda isprime     ; primality flag is
                tay             ; either $0000 or $ffff
                jmp givayf      ; make it real & return to Basic
    
        
        testnum:
                .word $ffff     ; container for number to be tested
        order:
                .byte $ff       ; container for n, as in nth prime
        isprime:
                .byte $ff       ; container for flag that signals
                                ; primality
        temp
                .byte $ff       ; temporary storage for prime


; prime
; Finds the nth prime on the number line.
; E.g. prime(0) = 2, prime(1) = 3, etc.
;
; input .X order n
;
; output .X nth prime number
;
; effects on .A, .X, .M, .Z
                                
        prime:
                lda primes,x    ; load from list of primes
                tax             ; put it in .X
                rts
        ; ordered list of all 54 prime numbers less than 256
        primes  .byte   2,   3,   5,   7,  11 
                .byte  13,  17,  19,  23,  29
                .byte  31,  37,  41,  43,  47
                .byte  53,  59,  61,  67,  71
                .byte  73,  79,  83,  89,  97
                .byte 101, 103, 107, 109, 113
                .byte 127, 131, 137, 139, 149
                .byte 151, 157, 163, 167, 173
                .byte 179, 181, 191, 193, 197
                .byte 199, 211, 223, 227, 229
                .byte 233, 239, 241, 251
        
                
; square
; Calculates the 16-bit unsigned square of an 8-bit unsigned integer.
;
; input .A number to be squared
; output .A, .Y squared number (lo/hi)
;
; Destroys all registers.

        number = $61            ; 8-bit value to be squared
        nsquare = $62           ; 16-bit value of squared number
        tnumber = $64           ; temporary storage for number
        
        square:
                sta number      ; put .A in number
                lda #$00        ; clear A
                sta nsquare     ; clear square low byte
                                ; (no need to clear the high byte,
                                ; it gets shifted out)
                lda number      ; get number in .A
                sta tnumber     ; save original for later use
                ldx #$08        ; 8 bits to process
        sqloop:
                asl nsquare     ; shift square to left
                rol nsquare+1   ; (i.e. multiply by 2)
                asl a           ; get next highest bit of number
                bcc sqnoadd     ; don't do add if carry is zero
                tay             ; save .A for later use
                clc
                lda tnumber     ; add original number value
                adc nsquare     ; to square
                sta nsquare
                lda #$00        ; add a possible carry
                adc nsquare+1   ; to the high byte of square
                sta nsquare+1
                tya             ; get .A back
        sqnoadd:
                dex             ; decrement bit counter
                bne sqloop      ; go do next bit
                lda nsquare     ; lo byte of square in .A
                ldy nsquare+1   ; hi byte of square in .Y
                rts
                
                
; modulo
; Calculate the modulo of an 8-bit number with a 16-bit number.
;
; input .A, .Y dividend
;       .X divisor
;
; output .A, .Y remainder
;
; Destroys all registers.

        num1 = $61      ; 16-bit dividend
        num2 = $63      ; 8-bit divisor
        rem = $64       ; 16-bit remainder
        
modulo:
        sta num1        ; .A lo byte of dividend
        sty num1+1      ; .Y hi byte of dividend
        stx num2        ; .X divisor
        lda #$00        ; clear remainder
        sta rem
        sta rem+1
        ldx #16         ; do 16 bits
modloop:
        asl num1        ; shift num1 to the left
        rol num1+1
        rol rem         ; into remainder
        rol rem+1
        sec
        lda rem         ; do trial subtraction
        sbc num2        ; with divisor
        tay
        lda rem+1
        sbc #$00        ; divisor is 8-bit value
        bcc modnosub    ; was there a borrow, 
                        ; then skip subtraction
        sta rem+1       ; save the result
        sty rem
modnosub:
        dex             ; repeat for 16 bits
        bne modloop
        lda rem         ; lo byte of remainder in .A
        ldy rem+1       ; hi byte of remainder in .Y
        rts

"testusrf-0-4.bas"

0 rem testusrf-0-4.bas
1 rem version 5 - test completed usr function
10 poke 785,0: poke 786,192:rem usr function at $c000
20 input "number";n
30 m = usr(n)
40 print n;"is ";: if not m then print "not ";
50 print "prime"
60 print "any key to continue"
70 poke 198,0:wait198,1:poke198,0
80 goto 20

Fun semi-fact. Cats only meow to humans, not other cats, because they have experienced we humans communicate through sound, and meowing is how that sounds to cats, presumably.

Writing correct code is such a hassle, yet it has to be done to be able to run it, preferably without error in code, nor confusion in user.