Coding

After introducing BASIC and Forth as interpreted languages on the Steckschwein, it’s time to add another unique and productive language—Brainf*ck.

For those unfamiliar, Brainf*ck (or Brainf**k) is an “esoteric” programming language created in 1993 by Urban Müller, the founder of Aminet. You can read more about it on Wikipedia.

A compact Brainfck interpreter can be found here, originally developed for the Apple ][. This version served as the foundation for the Steckschwein adaptation. The Apple ][ ROM calls were replaced with custom code, and the interpreter loop was optimized using 65C02-specific instructions, making it smaller and faster. Although performance gains in Brainf*ck aren’t critical, the improvements are noteworthy.

In order to generate our own QR codes natively on the Steckschwein, we drew a lot of inspiration from this article https://8bitworkshop.com/docs/posts/2022/8bit-qr-code.html

It even points to an adapted version of the qrtiny library, that has been made to compile with cc65, including a demo for the Apple ][, using cc65’s own Tiny Graphics Interface (TGI). Which is very nice, because all the hard work has already been done.

We have not implemented TGI (yet?), but we do have our rudimentary BGI (Borland Graphics Interface), which is similar. So all that’s left to do is porting the code to BGI, which has proved to be fairly trivial:

To share my fascination for the numerous sorting algorithm videos on youtube, I took some sorting algorithm examples in C from https://www.geeksforgeeks.org/sorting and visualized them using our BGI compatible C graphics library (more about that later).

The algorithms shown are:

• Bubble Sort
• Cocktail shaker Sort
• Gnome Sort
• Insertion Sort
• Comb Sort
• Heap Sort
• Shell Sort
• Selection Sort
• Quick Sort
• Merge Sort
• Radix Sort

The code examples from https://www.geeksforgeeks.org/sorting are only slightly adapted and could be compiled with cc65 almost instantly. The trick was only to find the places in the code where the interesting search array accesses happen.

Frank van den Hoef, who is adapting the Steckschwein SPI & FAT32 code for his tiny65 machine made me aware of a classic mistake for a 6502 assembly coder to make. Namely in our sdcard driver, when waiting for the “proper” response from the card (which should have bit 7 cleared). The routine handling this looked like this:

1  sd_cmd_response_wait:
2 	ldy #sd_cmd_response_retries
3 @l:	dey
4         beq sd_block_cmd_timeout ; y already 0? then invalid response or timeout
5         jsr spi_r_byte
6         bit #80	; bit 7 clear
7         bne @l  ; no, next byte
8         cmp #$00 ; got cmd response, check if $00 to set z flag accordingly
9         rts
10 sd_block_cmd_timeout:
11        debug "sd_block_cmd_timeout"
12        lda #$1f ; make up error code distinct from possible sd card responses to mark timeout
13        rts

Classic. Obviously, line 6 should read:

The main motivation to get Forth up and running on the Steckschwein was to participate at The Ultimate Benchmark, in order to crush all 8bit competition to dust.

So the plan was to benchmark the Steckschwein live at the VCFe. Unfortunately, Carsten could not be there, so no Forth benchmark competition this year. Recently, Carsten presented his benchmark results using TaliForth2, which led us to run the same benchmarks he did and send the results to Carsten, who was kind enough to include them on his site:

The woz monitor, also known as WOZMON, is a pretty simple memory monitor and was the system software located in the 256 byte PROM on the Apple I. Wozmon is used to inspect and modify memory contents or to execute programs already located in memory. Steve Wozniak managed to squeeze all that functionality into 256 bytes. That’s right, bytes. Not megabytes, not kilobytes. Bytes.

We already had attempted to get wozmon ported to our Steckschwein, but we did not succeed so far. That might have been because the wozmon-code is a little bit hard to read and makes use of some Apple I specific things, which we did not know they were, since we do not have any expertise about the Apple I.