As we’ve discussed, large integer math is a pretty interesting problem, even for modern computers.

What if we wanted to add very, very, very large integers without using scientific notation, but this time let’s do it extra slowly. Extra slow… this seems like a job for BASIC!!

Strings

We’re going to need to use strings. On the Commodore BASICs of the 80s, strings have a max length of 255, so the largest sum we’ll be able to represent is:

I built the world’s worst paper tape reader some weeks ago. It works pretty okay on anything with a USR-style port like a KIM-1 clone or a VIC-20.

It at least attempts to live up to the world’s worst name. Paper tape was (and is) an interesting medium. Sure it’s hard to work with and fragile, but it also has the advantage of being slow. I mean, what’s not to like??!!!

Can we get a little more speed from a 6502 than we did last week? Almost certainly.

The memory test we used was a general-purpose one. It’s flexible and reusable. The price is some speed. Let’s try and make it faster.

The test machine for this one

I’m going to rerun the test on a Corsham KIM-1 Clone for a couple of reasons:

• It’s still on my desk from last time
• It’s clocked at EXACTLY 1Mhz
• It has a large block of contiguous memory available if we want it without ROMs , etc. getting in the way.
• The memory expansion is connected directly to the bus, making the “expansion” the same access speed as the built-in memory
• It doesn’t compete with other devices (I’m looking at you, video chips!), so we’re just talking 6502 and memory here.

And by clocked at EXACTLY 1Mhz, assuming the frequency counter in my scope is pretty accurate:

The amazing Gregorio Naçu posted the article title graphic this week to bring attention to the venerable 6502 processor and poke fun at Apple’s M2 chip marketing slides. He’s doing probably the most ambitious single-person Commodore 64 project I know of and has a fantastic blog.

Apple claims the new M2 chip has the following specs.

M2 features Image by Apple via Youtube

We all know that these numbers are probably a little fluffy. Maybe a lot fluffy, and in practical applications, they are probably pretty far off. Benchmarking in a lab is fine, but the numbers rarely reflect real-world performance.

Bill Gates has been a controversial figure in the Computer World for 50 years now.

Back in 1976, he famously (infamously?) wrote a letter bemoaning what he saw as rampant piracy of BASIC. Micro Soft was selling their version of BASIC, which is quite good for a whopping $150. This was fine for a company, but to a "tinker in your garage" person, $150 ($760 or so in 2022) was pretty steep.

I’m doing a year-long project to reverse engineer the output and functionality of a VIC-20’s video chip, and create a drop-in replacement. At the start of this project (a few days ago), I only actually know how to do a percentage of the things I’ll need to complete this project. Writing a long series on how things work as I learn will help the project along. Plus, maybe having all of this information in one place would be nice, right?

I’m very pleased with my PAL VIC-20 replica, the Vicky-20. It’s almost a year old and the VIC-20 that sits on my desk all the time.

I’ve wanted the absolute best video out of this thing I could muster. This board is fortunately VERY easy to modify.

Connections

Sure, you need an S-Video Cable for this. You can use a 5 Pin DIN to RCA jack from the Amazonies for a few bucks. This works without modification with my RetroTink 2X Pro

I stumbled across a ZX Spectrum version of the 100 Door problem that got me thinking. Wouldn’t it be nice to have PRINT AT in Commodore BASIC?

We do this in Assembly all the time.

We already know from several previous articles that moving the cursor is pretty straightforward using a Kernal routine:

Load the row number in X, the column number to Y, clear carry, and jump to $fff0. Simple.

Sometimes there’s an absolute joy in doing something the hard way to REALLY understand what’s happening.

I struggled (still struggle) with wrapping my mind around using the display on the KIM-1. The best way (for me anyway) to be motivated to learn something is to have an outcome in mind of what I want to see and work towards that.

Most people who started on the KIM-1 probably spent a fair amount of time in an early book called “The First Book of KIM.” There are several examples of the basics in it, including one way to show memory locations on the display.

Quite a while ago, I started playing with random numbers on 8 Bit machines. I don’t think anyone is doing “serious” work on these machines, but playing with Ciphers and Crypto got me at least curious about how a Commodore 64 generates random numbers.

There are many ways to determine randomness. Humans are pretty good at picking out patterns in visual representations. Luckily our beloved machines have easy screen memory access. Let’s poke some random stuff to the screen and see what we see.

In mid-2021, I built a MiniPET 40/80. It’s one of the best replica kits I’ve ever seen. Even the keyboard is wonderfully awkward to use, just like a real Chicklet PET keyboard is.

Switching between ROM versions with DIP switches has been great for learning and experimenting with internals.

My only wish is that I could occasionally get a green screen out of it. I use the composite output, which is black and white (just like many original PETs), but the 7-year-old in me just loves a Green Screen PET. So I was on Twitter one day when someone (I’m sorry, I’ve forgotten who) pointed me to a small project by a chap in Spain.  This takes a monochrome VGA signal and lets you change the colors with dip switches. AND it was only 9 bucks.

Someone asked me yesterday how to very simply split the Commodore 64 screen to display two solid colors.

The screen is 1000 “blocks”(character cells) starting at Hex $0400 (1024 decimal). It’s 40 characters wide and 25 rows.

25 rows don’t divide evenly, so we can tell the VIC register to hide a small part of the screen to display 24 rows instead. Register $d011 needs bit 3 toggled to zero to set the screen to 24 rows.

Someone asked me this week if I would help him with a graph theory problem on 8-Bit machines. The first task was to get all permutations of 1 to 9. Since the total permutations is 9! (362,880) I knew this would take a while.

Learning without learning, the standard library problem

There are no shortcuts to pretty much anything worth doing. If you fail to learn the basics, then when you get to more advanced things, the basics will feel like black magic, and the thing you’re working on will only make sense on the surface.

There’s a wonderful yearly online event called Advent Of Code (#adventofcode). Each day there are two code challenges that follow a holiday narrative. Some of them are easy, and some of them are quite difficult.

This year I’ve attempted to do as much of it as I can on 8-Bit Machines. Mostly Commodore 64 because it’s what I know the best, and also what I like most to actually code on.

I LOVED Ayliean MacDonald’s Tower of Hanoi video on Numberphile this week. I wanted to try it with some “soothing” sounds from the 80s with the SID from a Commodore 64

No code breakdown this time, just a little Thursday lunchtime fun I whipped up during a conference call ;-)

I’ve been obsessed with the Random number generator on the Commodore computers for a LONG time, and I’m not the only one who is, to be sure.

We’ve used this random function in many of the Cipher series articles before, both via BASIC and directly getting randomness from the SID oscillator 3.

Let’s try a “practical” example we might code into a game that throws dice and tests the frequency distribution. For one or two dice, we can easily calculate what a “perfect” distribution should be, so this should be a good test to see if the random number generator is sufficient to make a fair game.

I’m a Commodore guy through and through. This isn’t tribalism, it’s what was in my room from 1983 to when I graduated High School in 1993.

After my sorta failed attempt at spending the month of September with my Coco 2, I decided for October to try spending a week at a time with a particularly less familiar computer.

So starting on October 1st, and ending on the 7th, I spent my free time with the Atari Systems that I have.

Back in March, we did a simple set of programs to brute force calculate Pi using a simple and well-known series. It works, even if it’s inefficient.

Speaking of inefficient, it’s September and that means it’s time for #Septandy! I have a Tandy Color Computer 2 - 16k of RAM version. There are versions of this machine with more RAM and an enhanced version of BASIC called “Extended BASIC”, but I’ve had this machine since the 80s and it is the most entry-level version Tandy made.

What’s the 100 door problem?

It’s a just for fun problem in “beginning” math and computer courses. The idea is simple:

There are 100 closed doors in a row.

You walk past the doors 100 times (100 passes)

The first time, visit every door. If the door is closed, open it. If it is open, close it. In programming, you’d probably call this toggling the door so let’s call it that.

The Commodore 64 and PET are fairly similar systems. Other than a few memory location differences, many BASIC programs written for the Commodore 64 that don’t use graphics can run on a PET.

There is one caveat. The PET doesn’t relocate a saved BASIC program to the beginning of BASIC, like all of the Commodore lines after it. So if you find yourself trying to load a program on your PET written on one of its younger siblings, you may wonder why it loads, but you can’t find it.

We’re on ANOTHER random number generation technique today. Let’s work on the Lagged Fibonacci Sequence, a fun way to use the Fibonacci Sequence on itself to generate pseudo-random numbers.

One of our long term goals is to add a bunch of tools to our toolbox. Making reusable components makes doing more complicated things easier. You can rifle through your toolbox in hopes of an “Oh, I already have something we can use for this part!”.

One of my main goals in sharing retro computing is to help people DO things with these machines. They are useful for all sorts of reasons, not the least of which is education and demonstration. The constraints are wonderful for this.

Using 30-50 year old hardware comes at a price. They are, well… old.

They require constant care and maintenance and parts are becoming more and more scarce.

Enter the retro pinout project

In fixing or maintaining these old computers, one of the best resources you can have is a similar working model next to it. Being able to test things out on a working example is invaluable.

I posted this on Twitter a few weeks ago, but a young lady has been exploring programming in Python and also with Commodore BASIC which is pretty neato. She’s 11 and asked if there was a way to do modulo functions on Commodore BASIC because she’s using her Dad’s VIC-20 and Simon’s BASIC is obviously not available for the VIC-20.

The answer is pretty simple and will actually work in most programming languages.

If we wanted to do A mod B (or A%B in a lot of newer programming languages) we can do it in one line. We’re really just looking for the remainder of a division that we’ll call R

Cryptonomicon Pontifex/Solitaire

We’re back to my favorite book for another round. We’ve done quite a bit with Cryptonomicon so far. One of my favorite moments is when Enoch Root introduces a cipher that two prisoners used to communicate using just a humble playing card deck.

Bruce Schneier

Pontifex is an encryption method you can do with another person using a deck of cards. It was invented for “Cryptonomicon” for Neal Stephenson by Bruce Schneier. He called it Solitaire. In the book it’s called Pontifex to obfuscate the method a little bit.

A while ago, I explained in detail how to generate one time pad sheets and use them to encrypt and decrypt messages.

It turned out to be doable, only requiring a pencil and a way to create random numbers, but it’s slow, error prone and tedious.

Why

The one time pad article was born out of my annual reading of Cryptonomicon. I wanted to learn how to make these pads, which if used correctly are mathematically unbreakable. I figured 3 or 5 other people might read it and learn how to make them too.

Hashes

We did an implementation of a once popular hashing function in Part 8 on RC4 without really going into why.

A hash function is any function that is used to map data of an arbitrary size (input) to a fixed size output. An algorithm is applied to the input and results in a fixed length output called the hash.

In cryptography it’s important to get a repeatable output for a given input, but ideally NO information about the input that created it.

Recap

So far we’ve

• Reversed a string
• Shifted bits left and right (mostly right)
• Brute forced a known simple cipher
• Channeled our inner John Connor by cracking ATM machines
• Searched through a large number looking for matches
• Learned how to use XOR to recover data
• Created a Linear Feedback Shift Register to generate better random numbers
• Implemented a “real” but outdated cipher: RC4

Disclaimer: I’m sure I’ll get an angry email from a mathematician about this, but we’re going for understanding here. No one expects to be looking for large primes on a Commodore 64. Calm down.

An “almost teenager”, Josh, sent me an email yesterday asking how I do slow text on the Commodore. He is just starting assembly at 12 which is pretty impressive. He’s been using KickAssembler, but wants to try it “on hardware”.

It’s not difficult really. There are probably a lot of ways to do this, here’s how I do it in Turbo Macro Pro.

Let’s start with some text: ARE YOU KEEPING UP?

Concept Cyberdeck

I’m fortunate to have a number of vintage computers I’ve collected over the years. Some were fun finds, others donated. One I’ve had since 1983 (we think) and it’s one of my most prized possessions.

I travel a fair bit and not long ago I was looking for something for my “TheC64” to do. It’s technically an emulator, but with it’s accurate Breadbin keyboard and REU support it makes a pretty decent development platform for some things.

Recap

So far in this 8 part series on doing weird things with Ciphers on old computers we’ve:

• Reversed a string
• Shifted bits left and right (mostly right)
• Brute forced a known simple cipher
• Channeled our inner John Connor by cracking ATM machines
• Searched through a large number looking for matches
• Learned how to use XOR to recover data
• Created a Linear Feedback Shift Register to generate better random numbers

The warning

“In September, 1994 someone posted source code to the Cyberpunks mailing list-anonymously. It quickly spread to the Usenet newsgroup sci.crypt, and via the Internet to ftp sites around the world. Readers with legal copies of RC4 confirmed compatibility. RDA Data Security, Inc. tried to put the genie back into the bottle, claiming that it was still a trade secret even through it was public, it was too late. It has since been discussed and dissected on Usenet, distributed at conferences, and taught in cryptography courses.” - Applied Cryptography, Bruce Schneier, 1997

I have several items from DIY Chris that we’ll review over the next week including a GAL PLA and flash-able ROM drop in that can hold kernal, character or BASIC ROMs.

First on the list is the RAM tester.

The problem child 128

I have a Commodore 128 which developed a bad RAM issue a few weeks ago. These old computers just sometimes sacrifice a part to the component gods.

So far in this 7 part (shocked I’ve made it through 7!) series on doing weird things with Ciphers on old computers we’ve:

• Reversed a string
• Shifted bits left and right (mostly right)
• Brute forced a known simple cipher
• Channeled our inner John Connor by cracking ATM machines
• Searched through a large number looking for matches
• Learned how to use XOR to recover data

Author’s Note:

This one stretched my skills quite a bit, but I kept it under 2000 words (by 89). I’m not sure when I started this I knew I’d be doing a Linear Congruential Generator on a 40 year old machine, but here we are ;-)

Review

So far we’ve:

• Reversed a string
• Shifted bits left and right (mostly right)
• Brute forced a known simple cipher
• Faked it, but then looking for a 4 digit known pin
• Searched through a large number looking for matches

We now have most of the basic skills in Assembly to start doing some real work. Let’s tackle what is arguably the most important of the bitwise operators for ciphers and encryption: The exclusive OR. (XOR/EOR)

If you REALLY want to get into the weeds on how I figured out the Easter Egg(s) inside the Easter Egg on a 35 Year old album on a 35 year old computer then you’re in luck! This video is for you!

I mention “the original author” in the video several times, but fail to say his name. It’s Tom Beaton (aka TCB1984)

A common task in our code is to determine the length of something. In this example, let’s check the length of a string like “are you keeping up?”

In Python, this is crazy easy.

#!/usr/bin/env python

message = "are you keeping up?"
len(message)

In 6510 Assembly, this is also easy. Not crazy easy, but straightforward anyway.

messagelength
	ldx #$00
checkdel 
	lda message,x
	cmp #$00 ; or whatever we're using as a delimeter
    	beq done
    	inx
    	jmp checkdel
done 
	stx messagelen
	rts
    
.byte messagelen 0

message .null "are you keeping up?"
    
    

Pretty easy right?

Just the BASICs, please

Our friend in retro @NoelsRetroLab has a simple BASIC benchmarking tool that’s fun to use to compare different basic systems execution speed.

We’re counting jiffies, which is roughly (sometimes very roughly) 1/60th of a second.

We’re using three variations of this code on the Commodore BASIC computers. This will vary a little if you try it on something else. And PLEASE try this on whatever you have. It’s for “science”!!!

Many of you know that you can use a “Jiffy” on a Commodore as a measure of time. Sorta.

The short short version is that we have a 3 byte clock that increments once every interrupt, so 1/60th of a second. It’s not considered reliable as a real time clock, but it IS useful for benchmarking.

According to “Compute’s Complete Guide to the C64” p. 156:

“TI equals PEEK(162) + 256PEEK(161) + 256256*PEEK(160); for TI$, the value of TI (in jiffies) is converted into hours, minutes, and seconds.”

Let’s recap a little

So far we’ve:

• Reversed a string
• Shifted bits left and right (mostly right)
• Brute forced a known simple cipher
• Faked it, but then looking for a 4 digit known pin

What we need next in our toolbox is to be able to search through a large number of values to look for something. This will build on the previous skills and also reinforce working with tables and 24 bit math on an 8Bit Processor.

It’s Pi day tomorrow, and you know what that means!

Cherry is favorite. Apple is second favorite.

There is a well known and easy to understand method for calculating Pi with the Gregory Leibniz series. Leibniz built on the work on Gregory.

It has the added benefit of being pretty inefficient to implement on computers. This seems like a job for the Commodore VIC-20!

Our outcome repeats a variation of:

__π = (4/1) - (4/3) + (4/5) - (4/7) + (4/9) - (4/11) + (4/13) - (4/15)…

There are many hacks you can do in Assembly language on the Commodore.

Here’s a very easy one with impressive results according to my analog stopwatch.

We want to count to $ffffff or 2563 (224) which is 16,777,216

We wont print to the screen to save a lot of time, and just put an “a” in the top right corner when we’re done.

One way (and yes, I want to know all the other ways you know of to do this) would be:

Ahh, the quest for a better Vintage computer picture never ends. I’m having fun with it anyway.

Side thought: At what point does a computer cross over from old: no one wants that 2007 Windows tower you built in your basement, to OMG, it’s Vintage, let’s drive up the eBay bids to the stratosphere!!!!

How bad was it?

A few minutes into Terminator 2, the young John Connor takes his Atari Portfolio out of his bag and inserts a foil covered card into an ATM machine and proceeds to crack a pin number and steal some cash from an unsuspecting account.

This is a movie prop and doesn’t really appear to do anything useful. It’s almost certainly just a script that runs on the Atari Portfolio, and just counts down some strings to make a “cool” effect.

Well here we are at part three and it’s a lot to pack into one page.

Let’s build upon [what I called the Shift Cipher] and implement what is often referred to as the Caesar Cipher, although there is much debate on when this was really first done.

The idea is the same as our Part 2. We’re going to shift the letters a given number of times, but this time we’re going to do the encoding and decoding programmatically instead of just creating a reference to do it by hand.

In Part 1 we did a simple reverse of a string. While simple, these software steps will help build the skills we need going forward in Assembly without feeling like I skipped right to a 300 line after doing a short one. One foot in front of the other and all that.

The Shift Cipher

For Christmas, my wife and I bought my sister’s kids this code wheel. It implements a simple shift cipher to be transposed by hand. This was common low tech way to scramble messages for quite some time, and fits nicely in between reversing a string and a more complex implementation of the Caesar cipher in software.

The output on my newest Commodore 64 (1989) is pretty marginal. The colors are okay(ish) but the text lines are clearly bleeding and the picture is very muddy. Most vintage computers don’t do red text on blue very well, but this one is particularly painful.

Sometime during my weeklong exploration of SHA-256 on a Commodore realized that there was a whole world of exploration that could be explored. Just because a Computer system is old, doesn’t mean it’s not interesting or useful.

I had expected it to take months to figure out the SHA-256 implementation, but it only took me a week or so. This was pretty surprising to me and is an excellent demonstration of what might be possible on a Commodore 64

Last week, at this bat-time on this bat-channel, I talked about checking off one of my 35 year old bucket list items by learning Commodore assembly language. (shut up, you’re old too.) Coincidentally, I picked this up at the time I was re-reading Cryptonomicon by Neal Stephenson for the ump-teenth time. There are a few books that I consider so good that they’re worth re-visiting, and this is one of them.

If you haven’t read it, you don’t need to worry about spoilers. The plot is multi-generational. One character, Lawrence Waterhouse, is a high level Allied Cryptographer tasked with cracking codes and coming up with new encryption methodologies. His weapon of choice for the most secure messages is the one time pad.

Some time in the month of September 2020 I dug out the old Commodore 64 that my Dad bought for himself in 1983. It quickly migrated its way into my room and stayed there until 1993 when I joined the Navy. Someone in my family, probably Mom, carefully packed it back into its original box and put it into storage. Despite its many years of use/ abuse by a messy teenager, it’s in surprisingly good condition, 38 years later. (You’re old.) Back then, I had attempted some programming on it, but I had the patience and focus of your typical suburban kid. Over the years I’ve thought about the many hours I spent on that machine (remember when computers lasted more than a single year?) and as a seasoned developer I began looking at the computer and seeing more potential than I was able to realize as a kid. Modern software is very powerful. Unfortunately, if you program with it long enough, it stops feeling “real.” It’s like learning to fly on Microsoft Flight Simulator, versus taking private pilot lessons to actually control and fly a real aircraft. My experience with flying actual planes prepared me to recognize the distinction that afternoon in September when I pulled out my old machine. I had the idea that if I could get closer to the bites, I could become a better programmer. And if that didn’t work, I could at least have fun with it. (nostalgia is a hell of a drug.)

I’m blown away by some modern games still being developed for the Commodore line of computers.

Both games I’m playing in January are sold by Protovision, who has probably the best vintage company name on the market right now.

Soul Force is an excellent take on a side-scrolling space shooter (maybe the cool kids abbreviate these SSSS?). It seems both familiar and unique, which is hard to do in a space based shooter like this.

People are funny on the internet. We always seem to divide into tribes even when it’s not necessary or advantageous to do so.

I wasn’t surprised to see someone (there’s always one isn’t there?) comment that I might be using real hardware, but for only part of my retro setups.

“I’m disappointed that you’re using an LCD monitor on your retro computers”

You’re… disappointed? Kinda dramatic isn’t it?

Do I get more pleasure out of doing retro on real hardware rather than emulators? I do. Do I think less of someone who only uses emulators? Absolutely not, it would be silly to. Besides, emulators like VICE are incredible feats. They work REALLY REALLY well and represent many thousands of hours of hard work over decades. I’m in awe of these kinds of projects, not ashamed of them.

It was just a few months ago that I started to get back into 8-Bit computing. It started with Ben Eater’s Breadboard 6502 build. Something about his complete exploration of that build including single stepping the clock and watching the processor registers was really compelling to me.

I built Ben’s project by following along with the videos. It’s currently inside a shadowbox in my office wall blinking away :-)