Back in the late 1980s, I was hired for my first commercial programming task. I wrote two programs for the Super Snapshot cartridge… a Sprite Monitor, and a Sprite Editor.
What was a Super Snapshot cartridge? What’s a sprite? Why do you want to monitor or edit it?
To tell that story, we have to start with the Commodore 64’s disk drive.
The 1541 Drive
In my Commodore 64 post, I discussed the 1541 disk drive that was the standard floppy drive for the C64. This external drive was extremely slow, even for floppy disk drives, achieving top speeds met by a 2400 bps telephone modem.
Fortunately, the 1541 drive was basically a computer in its own right. It had a MOS 6502 CPU in it with its own operating system, CBM DOS 2.6. Commodore 64 users will remember LOAD “*”,8,1 as the usual command to load and run a program on a floppy disk.
Soon after the drive’s release, enterprising hackers* found ways to rewrite the operating system to make it faster while still maintaining compatibility with the Commodore 64.
* by “hacker” I mean people who poke around in computers to figure out how the hardware and software work, not criminals who break into systems and steal information or hold them for ransom.
Software Piracy and Copy Protection
Ever since people started charging money for software, other people tried to copy (“pirate”) the software and use it for free. Until 1980, software was not protected by copyright so there was no real legal issue with copying software. With the passage of “H.R.6934 – The Computer Software Copyright Act of 1980” – championed by people like Bill Gates, who was tired of people copying his Altair BASIC for free – software was protected by copyright in the USA.
Companies tried various means to prevent their software from being copied. Some software shipped with hardware “dongles” that had to be inserted into the computer for the program to run. This was common for high-cost, low-volume software like industrial control software and I encountered these many times in my career.
Some programs had the user look up a phrase in the software manual, reasoning that if the software was copied, the pirate wouldn’t have the manual. There were several popular Commodore 64 programs that used this method.
Many Commodore 64 programs used specially formatted floppy disks to deter pirates. These disks would intentionally have “bad” sectors or non-standard disk parameters that could not be read normally by the 1541. If the potential pirate tried to duplicate the disk onto a blank one, it would fail, or not include these “bad” sectors and therefore not be a perfect copy.
Naturally, an arms race ensued between software pirates and commercial software developers. Programs like Carbon Copy II were developed to make more faithful disk copies.
Another approach was a “freezer”. Typically software would do its copy protection checks while loading, so the theory of a freezer was that you would load the software and let it do its checks, then “freeze” the computer and save the entire memory of the C64. Later, when you wanted to run the program, you could load the frozen copy that did not include the copy protection check.
These “freezers” were typically cartridges that plugged into the back of the C64, and the Snapshot 64 was one of the first.
The Super Snapshot Cartridge
The Super Snapshot cartridge was wildly popular. It was owned by the Canadian company LMS Technologies, based in the Maritimes, and the primary developers were Ron Smith and Marcel LeBlanc. It was a combination of hardware (the cartridge that plugged into the C64), software (on the cartridge and later on a supplied floppy disk), and an extensive manual.
The Super Snapshot cartridge combined the “freezer” capability of the Snapshot 64 with “Turbo DOS”, disk accelerator software that greatly increased the speed of the drive (“up to 500%”). This was integrated with the Commodore 64 on startup so it was always there as long as the cartridge was inserted.
Over time, more features were added to the Snapshot cartridge, like a disk editor, screen copier, and so forth. It evolved into the Super Snapshot 64, then the Super Snapshot 3, 4, and finally the Super Snapshot 5. This page has a tremendous amount of detail on the Super Snapshot.
The Super Snapshot 4 added several features, including the Sprite Monitor and Sprite Editor, the two software programs that I developed.
What’s a Sprite?
I won’t get too deep into computer graphics, but I’ll give an overview. Computer displays are basically a grid of “pixels” where each pixel can be turned off or on (black and white) or set to a specific colour. This concept carries over into televisions where a 4K TV is a grid of 3,480 pixels wide by 2,160 pixels tall. Generally the more pixels you have in a given space, the better it looks. The Commodore 64 had a resolution of 320 x 200 pixels, which was good for 1985!
This display is basically “bitmapped” meaning that there is an area of memory in the computer that corresponds to the pixels on the display, so a game can write a 0 or 1 to a memory location and it will change the display.
This is fine but a little slow. Imagine if you want to have a lot of the screen rapidly changing; that’s a lot of pixels to write and it takes time for the processor to do that. Your Mario character running across the screen involves a lot of writing to turn pixels off and on to animate the display.
Enter sprites. These are basically a small “overlay” on top of the bitmapped display. A programmer will design a sprite – like a Mario character – and then the program just has to say “move the sprite here” and the graphics do the rest. It’s much faster than rewriting many pixels to animate the display. Often a mouse cursor is a sprite, like the arrow that many systems use for a cursor.
The Commodore 64 supported eight sprites “out of the box”, but with some tricky graphics programming you could show more than 8 at a time. On the C64 sprites were 24 pixels wide and 21 pixels tall.
Where Did I Come In?
LMS Technologies, the owners of the Super Snapshot cartridge and code, wanted some sprite capability in the upcoming Super Snapshot 4 cartridge. They wanted two programs – a sprite monitor to capture sprites when the computer is “frozen”, and the ability to replace sprites “on the fly” – and a sprite editor to build your own sprites or edit sprites you saved from the monitor.
I was an active BBS** user at the time, and the major Fredericton-area BBS was Northern Connection (later “Online Services”), run by Calvin Martini and Colin Longman. I think LMS Technologies found me through Calvin, who I knew from the regular Commodore 64 / computer group meetings in the area.
** Bulletin Board System, a computer you would dial up using a modem and participate in message boards and download files from. More later.
I talked with Mark Smith, brother of Ron Smith, who co-owned LMS Technologies. Once he was satisfied that I had the technical chops to do the programming, we negotiated a price and a schedule and off I went.
Developing the Sprite Monitor
Code that ran off the cartridge wasn’t written in the BASIC language. It was in machine language, the native code that the Commodore 64’s 6502 processor understood. Since it is hard for humans to write directly in bits and bytes, we use what’s called assembly language to write this kind of code. It uses short mnemonics to represent individual machine instructions and it is more human readable. A program called an assembler translates the text assembly language into executable code, much like a compiler translates languages like C++ into executable code.
At this time, I had an Amiga 500 and used that as my main computer. I still had my C64 but it was mostly gathering dust. Mark hooked me up with a cross-assembler program (maybe this one). It ran on the Amiga but produced code for the C64, so I could use a more comfortable programming environment on my Amiga and write the executable code onto a floppy disk and test it on the C64.
I don’t remember having a 5 1/4″ floppy drive for my Amiga. I am wondering if I had a 3.5″ drive for my C64 by this time and exchanged discs that way.
The sprite editor wasn’t on the cartridge. The Super Snapshot 4 came with a companion floppy disc and the editor was on that. I was fortunate to find an image of the opening screen of the sprite editor here. This tells me I finished writing it near the end of 1988! Infinity Enterprises was the name of my company.
Someone gave a few tips on the sprite monitor and sprite editor here.
Anyway, I wrote the two programs on my Amiga and delivered them to LMS. I have no doubt that there was a little back-and-forth as we did testing and revisions before the final version made it onto the cartridge. My friend Nick MacDonald did some beta testing on these programs.
My Small Fame
You can see my name in the Super Snapshot 4 manual on page 50.
(It wasn’t highlighted in the actual manual, alas)
Many years later, I met a client at their site in Tennessee and he recognized my name from the Super Snapshot cartridge. I was more than a little surprised!
I still have a Super Snapshot cartridge – the lead photo is my cartridge – and I had a second one that I gave to my son. I don’t have a Commodore 64 but it’s nice to have a little piece of my programming history.
4 thoughts on “A Computer Geek: The Super Snapshot Cartridge”
I am so completely enjoying this series of posts on Commodore-era subjects. I see details that instantly transport me back to working with our Commodore machines and my attempts to get them to do things I was curious about. This stuff is just wonderful. Thank you.
Thank you, Chris! I’m glad you are enjoying them. It’s been fun going down memory lane.
What a nice stroll down memory lane Steve! Thank you so much.
Hi Calvin! I’m glad you enjoyed the stroll 🙂