I picked up every accessory, every productivity package, every Thing I could get my hands on that was related to this Mac-like GUI for the Commodore 64 and 128. And this included geoProgrammer, the official symbolic macro assembler, linker, and debugging package from BSW.
Code is written for geoProgrammer using the stock GEOS word processor, called geoWrite. This has the fun side-effect of not only allowing image assets to be integrated into the source code document, but also allows you to use all the fonts and styles and margins to make your code as beautiful as possible.
So armed, I spent the 90s and early 2000s writing numerous applications for GEOS. You can find information about most of them on my geoProjects page. However, my geoCoding spree pretty much came to an end in 2002 ..... until very recently.
The C64Net WiFi modem, which I've blogged about to the point of exhaustion at this point, inspired not only my 8-bit programming in general, but got me back into GEOS programming in particular.
In 2017 I wrote an 80 column ansi terminal program called geoTelnet, which I've also mentioned in previous posts before, but you can find more information about it here.
In early 2018, not long after its release, I got asked to do a color PETSCII terminal program for enjoying online BBSes from GEOS. I figured this would be a pretty easy slam dunk, since the hardest problem, rs232 communication in GEOS, was already solved.
However, as engineers are wont to do, I decided I needed to re-architect things. You see, geoTelnet was a VLIR application, so it theoretically could grow naturally with new swapped-in code modules. However, it was only designed for two modules: a GEOS 64 module with all features, and a GEOS 128 module with all features. This left things rather squeezed, with no room for, for example, more transfer protocols or a settings screen.
This created a slew of linking issues, since the code sections for the features were already pretty integrated with each other, and weren't expecting to be separated from each other. However, that was a straight-forward problem. What really frustrated me for several days as I started migrating to the new architecture was hard system crashes whenever text was printed on the screen. My interest soon waned, and a year went by when I gave no thought to it.
Then, in early 2020, on a whim, I decided to pick it back up and see if I couldn't find that bug. And find it I did, almost immediately (it was pretty stupid). I was so excited that I spent the entire rest of the day hacking away on my PETSCII renderer.
To test it, the next feature I tackled was getting the Buffering system working again. This would allow me to load PETSCII files from disk for testing. I then generated the above test pattern in Commodore BASIC, saved it, loaded it into my program, and eventually got it to what you see above.
The first time I saw true online PETSCII art rendered correctly on the screen, I was ecstatic. I was able to borrow from the code written for ANSI and Telnet codes to implement the cursor and other special PETSCII codes.
The last unique feature to put in place is the ability to actually input PETSCII codes from the keyboard. Things like color codes, special graphics characters, and the ability to toggle between the two font modes (lower/upper and upper/graphics). Surprisingly, this turned out to be trickier than I thought.
You see, the GEOS kernel doesn't care about many of the keys on the keyboard, so they simply don't scan them. And since they don't scan them, they aren't available as keystroke events for my terminal program to act upon. This led to me having to learn how the standard Commodore KERNAL actually accomplishes the feat, so that it can be replicated in my application. Turns out it's not too bad -- you consult an 8x8 matrix of all possible keys, tell the 6526 CIA to pull one of the rows, and then read back an 8-bit bitmap, which tells you which, if any, keys on that row are being pressed.
Once that was done, fixing the remaining features was pretty much a down-hill process. The phonebook, terminal options, desk accessories, and x-modem worked pretty much the same as they did in geoTelnet. X-Modem uploads did give me a little trouble, due to the fact that serial communication must be de-activated to swap modules, causing it to "miss" the handshake character from the remote side. This was quickly figured out though.
I'm not sure what's next at this point. I'd considered fulfilling the promise of the re-architecteing by not only adding new transfer protocols, but by actually integrating the ascii and ansi features of geoTelnet back into this program, to create one large full-featured terminal. Though, I might also venture into other areas -- geoFTP, geoIRC, geoETC...
We'll see.
