Tomu is a super cheap Open Source Hardware 24 MHz ARM computer with 8 KB of RAM and 64 KB of ROM that fits into your USB connector! Of course I had to put Commodore 64 BASIC on it, which can be accessed through the USB-Serial port exposed by the device.
It can be found in the cbmbasic subdirectory of my fork of the tomu-quickstart project.
Update: It has been merged into the official tomu-quickstart repository!
Use a terminal emulator to connect to the virtual serial port and hack away!
Recently, the 1986 adventure game “Murdlok” was published here for the first time. This is author Peter Hempel‘s “making-of” story, in German. (English translation)
Am Anfang war der Brotkasten: Wir schreiben das Jahr 1984, oder war es doch schon 1985? Ich hab es über all die Jahre vergessen. Computer sind noch ein Zauberwort, obwohl sie schon seit Jahren auf dem Markt angeboten werden. Derweilen sind sie so klein, dass diese problemlos auf den Tisch gestellt werden können. Mikroprozessor! Und Farbe soll der auch haben, nicht monochrom wie noch überall üblich. Commodore VC20 stand in der Reklame der Illustrierten Zeitung, der Volkscomputer, wahrlich ein merkwürdiger Name, so wie der Name der Firma die ihn herstellt. C=Commodore, was hat dieser Computer mit der Seefahrt zu tun frage ich mich? Gut, immerhin war mir die Seite ins Auge gefallen.
Das Ding holen wir uns, aber gleich den „Großen“, der C64 mit 64 KB. Den bestellen wir im Versandhandel bei Quelle. So trat mein Kumpel an mich heran. Das war damals noch mit erheblichen Kosten verbunden. Der Computer 799 D-Mark, Floppy 799 D-Mark und noch ein Bildschirm in Farbe dazu. Damals noch ein Portable TV für 599 D-Mark.
Als alles da war ging es los! Ohne Selbststudium war da nichts zu machen, für mich war diese Technologie absolutes Neuland. Ich kannte auch niemanden, der sich hier auskannte, auch mein Kumpel nicht. Es wurden Fachbücher gekauft! BASIC für Anfänger! Was für eine spannende Geschichte. Man tippt etwas ein und es gibt gleich ein Ergebnis, manchmal ein erwartetes und manchmal ein unerwartetes. Das Ding hatte mich gefesselt, Tag und Nacht, wenn es die Arbeit und die Freundin zuließ.
Irgendwann viel mir das Adventure „Zauberschloß“ von Dennis Merbach in die Hände. Diese Art von Spielen war genau mein Ding! Spielen und denken! In mir keimte der Gedanke auch so ein Adventure zu basteln. „Adventures und wie man sie programmiert“ hieß das Buch, das ich zu Rate zog. Ich wollte auf jeden Fall eine schöne Grafik haben und natürlich möglichst viele Räume. Die Geschichte habe ich mir dann ausgedacht und im Laufe der Programmierung auch ziemlich oft geändert und verbessert. Ich hatte mich entschieden, die Grafik mit einem geänderten Zeichensatz zu erzeugen. Also, den Zeichensatzeditor aus der 64’er Zeitung abgetippt. Ja, Sprites brauchte ich auch, also den Sprite-Editor aus der 64’er Zeitung abgetippt. „Maschinensprache für Anfänger“ und fertig war die kleine abgeänderte Laderoutine im Diskettenpuffer. Die Entwicklung des neuen Zeichensatzes war dann eine sehr mühselige Angelegenheit. Zeichen ändern und in die Grafik einbauen. Zeichen ändern und in die Grafik einbauen………….und so weiter. Nicht schön geworden, dann noch mal von vorne. Als das Listing zu groß wurde kam, ich ohne Drucker nicht mehr aus und musste mir einen anschaffen. Irgendwann sind mir dann auch noch die Bytes ausgegangen und der Programmcode musste optimiert werden. Jetzt hatte sich die Anschaffung des Druckers ausgezahlt.
Während ich nach Feierabend und in der Nacht programmierte, saß meine Freundin mit den Zwillingen schwanger auf der Couch. Sie musste viel Verständnis für mein stundenlanges Hacken auf dem Brotkasten aufbringen. Sie hatte es aufgebracht, das Verständnis, und somit konnte das Spiel im Jahr 1986 fertigstellt werden. War dann auch mächtig stolz darauf. Habe meine Freundin dann auch später geheiratet, oder hatte sie mich geheiratet?
Das Projekt hatte mich viel über Computer und Programmierung gelehrt. Das war auch mein hautsächlicher Antrieb das Adventure zu Ende zu bringen. Es hat mir einfach außerordentliche Freude bereitet. Einige Kopien wurden angefertigt und an Freunde verteilt. Mehr hatte ich damals nicht im Sinn.
Mir wird immer wieder die Frage gestellt: „Warum hast du dein Spiel nicht veröffentlicht?“ Ja, im nachherein war es vermutlich dumm, aber ich hatte das damals einfach nicht auf dem Schirm. Es gab zu dieser Zeit eine Vielzahl von Spielen auf dem Markt, und ich hatte nicht das Gefühl, dass die Welt gerade auf meins wartete. War wohl eine Fehleinschätzung!
Sorry, dass ihr alle so lange auf „Murdlok“ warten musstet!
Zu meiner Person: Ich heiße Peter Hempel, aber das wisst ihr ja schon. Ich bin Jahrgang 1957 und wohne in Berlin, Deutschland. Das Programmieren ist nicht mein Beruf. Als ich 1974 meine Lehre zum Elektroniker angetreten hatte waren Homecomputer noch unbekannt. Ich habe viele Jahre als Servicetechniker gearbeitet und Ampelanlagen entstört und programmiert.
Das Spiel ist dann in Vergessenheit geraten!
Derweilen hatte ich schon mit einem Amiga 2000 rumgespielt.
Wir schreiben das Jahr 2017, ich finde zufällig einen C=Commodore C65. Ein altes Gefühl meldet sich in mir. Was für eine schöne Erinnerung an vergangene Tage. Aufbruch in die Computerzeit. Der C65 stellt sofort eine Verbindung zur Vergangenheit her. Die letzten Reste meiner C64 Zeit werden wieder vorgekramt. So kommt das Adventure „Murdlok“ wieder ans Tageslicht. Spiel läuft auch auf dem C65, was für ein schönes Gefühl.
Ich habe dann Michael kennengelernt. Ihm haben wir die Veröffentlichung von „Murdlok“ zu verdanken. Ich hätte nie gedacht, dass mein altes Spiel noch mal so viel Ehre erfährt.
Danke!
Ich wünsche allen viel Spaß mit meinem Spiel und natürlich beim 8-Bit Hobby.
Murdlok is a previously unreleased graphical text-based adventure game for the Commodore 64 written in 1986 by Peter Hempel. A German and an English version exist.
Murdlok – Ein Abenteuer von Peter HempelBefreie das Land von dem bösen Murdlok. Nur Nachdenken und kein Leichtsinn führen zum Ziel. (Originalversion von 1986) |
Murdlok – An Adventure by Peter HempelLiberate the land from the evil Murdlok! Reflection, not recklessness will guide you to your goal! (English translation by Lisa Brodner and Michael Steil, 2018) |
The great thing about a new game is that no walkthroughs exist yet! Feel free to use the comments section of this post to discuss how to solve the game. Extra points for the shortest solution – ours is 236 steps!
If you have ever written 6502 code for the Commodore 64, you may remember using “JSR $FFD2” to print a character on the screen. You may have read that the jump table at the end of the KERNAL ROM was designed to allow applications to run on a all Commodore 8 bit computers from the PET to the C128 (and the C65!) – but that is a misconception. This article will show how
The KIM-1 was originally meant as a computer development board for the MOS 6502 CPU. Commodore acquired MOS in 1976 and kept selling the KIM-1. It contained a 2 KB ROM (“TIM”, “Terminal Interface Monitor”), which included functions to read characters from ($1E5A) and write characters to ($1EA0) a serial terminal, as well as code to load from and save to tape and support for the hex keyboard and display.
Commodore asked Microsoft to port their BASIC for 6502 to it, which interfaced with the monitor only through the two character in and out functions. The original source of BASIC shows how Microsoft adapted it to work with the KIM-1 by defining CZGETL and OUTCH to point to the monitor routines:
IFE REALIO-1,<GETCMD==1
DISKO==1
OUTCH=^O17240 ;1EA0
ROMLOC==^O20000
RORSW==0
CZGETL=^O17132>
(The values are octal, since the assembler Microsoft used did not support hexadecimal.)
The makers of the KIM-1 never intended to change the ROM, so there was no need to have a jump table for these calls. Applications just hardcoded their offsets in ROM.
The PET was Commodore’s first complete computer, with a keyboard, a display and a built-in tape drive. The system ROM (“KERNAL”) was now 4 KB and included a powerful file I/O system for tape, RS-232 and IEEE-488 (for printers and disk drives) as well as timekeeping logic. Another 2 KB ROM (“EDITOR”) handled screen output and character input. Microsoft BASIC was included in ROM and was marketed – with the name “COMMODORE BASIC” – as the actual operating system, making the KERNAL and the editor merely a device driver package.
Like with the KIM-1, Commodore asked Microsoft to port BASIC to the PET, and provided them with addresses of a jump table in the KERNAL ROM for interfacing with it. These are the symbol definitions in Microsoft’s source:
CQOPEN=^O177700
CQCLOS=^O177703
CQOIN= ^O177706 ;OPEN CHANNEL FOR INPUT
CQOOUT=^O177711 ;FILL FOR COMMO.
CQCCHN=^O177714
CQINCH=^O177717 ;INCHR'S CALL TO GET A CHARACTER
OUTCH= ^O177722
CQLOAD=^O177725
CQSAVE=^O177730
CQVERF=^O177733
CQSYS= ^O177736
ISCNTC=^O177741
CZGETL=^O177744 ;CALL POINT FOR "GET"
CQCALL=^O177747 ;CLOSE ALL CHANNELS
(The meaning of the CQ prefix is left as an exercise to the reader.)
In hex and with Commodore’s names, these are the KERNAL calls used by BASIC:
At first sight, this jump table looks very similar to the one known from the C64, but it is indeed very different, and it is not generally compatible.
The following eight KERNAL routines are called from within the implementation of BASIC commands to deal with character I/O and the keyboard:
But the remaining six calls are not library calls at all, but full-fledged implementations of BASIC commands:
When compiled for the PET, Microsoft BASIC detects the extra commands “OPEN”, “CLOSE” etc., but does not provide an implementation for them. Instead, it calls out to these KERNAL functions when these commands are encountered. So these KERNAL calls have to parse the BASIC arguments, check for errors, and update BASIC’s internal data structures.
These 6 KERNAL calls are actually BASIC command extensions, and they are not useful for any other programs in machine code. After all, the whole jump table was not meant as an abstraction of the machine, but as an interface especially for Microsoft BASIC.
Version 4 of the ROM set, which came with significant improvements to BASIC and shipped by default with the 4000 and 8000 series, contained several additions to the KERNAL – all of which were additional BASIC commands.
Even though Commodore was doing all development on their fork of BASIC after version 2, command additions were still kept separate and developed as part of the KERNAL. In fact, for all Commodore 8-bit computers from the PET to the C65, BASIC and KERNAL were built separately, and the KERNAL jump table was their interface.
The VIC-20 was Commodore’s first low-cost home computer. In order to keep the cost down, the complete ROM had to fit into 16 KB, which meant the BASIC V4 features and the machine language monitor had to be dropped and the editor was merged into the KERNAL. While reorganizing the ROM, the original BASIC command extensions (OPEN, CLOSE, …) were moved into the BASIC ROM (so the KERNAL calls for the BASIC command implementations were no longer needed).
The VIC-20 KERNAL is the first one to have a proper system call interface, which does not only include all calls required so BASIC is hardware-independent, but also additional calls not used by BASIC but intended for applications written in machine code. The VIC-20 Programmer’s Reference Manual documents these, making this the first time that machine code applications could be written for the Commodore 8 bit series in a forward-compatible way.
The following PET KERNAL calls are generally useful and therefore still supported on the VIC-20:
The calls for the BASIC commands OPEN, CLOSE, LOAD and SAVE have been replaced by generic functions that can be called from machine code:
(There is no separate call for VERIFY, since the LOAD function can perform this function based on its inputs.)
OPEN, LOAD and SAVE take more arguments (LA, FA, SA, filename) than fit into the 6502 registers, so two more calls take these and store them temporarily.
Two more additions allow reading the status of the last operation and to set the verbosity of messages/errors:
BASIC uses all these functions to implement the commands OPEN, CLOSE, LOAD, SAVE and VERIFY. It basically parses the arguments and then calls the KERNAL functions.
The KERNAL also exposes a complete low-level interface to the serial IEC (IEEE-488) bus used to connect printers and disk drives. None of these calls are used by BASIC though, which talks to these devices on a higher level (OPEN, CHKIN, BASIN etc.).
BASIC needs to know where usable RAM starts and where it ends, which is what the MEMTOP and MEMBOT function are for. They also allow setting these values.
BASIC supports the TI and TI$ variables to access the system clock. The RDTIM and SETTIM KERNAL calls allow reading and writing this clock.
These functions use the addresses that used to be the BASIC commands SYS and VERIFY on the PET.
Machine code applications may want to know the size of the text screen (SCREEN) and be able to read or set the cursor position (PLOT). The latter is used by BASIC to align text on tab positions.
On the PET, the BASIC’s random number generator for the RND command was directly reading the timers in THE VIA 6522 controller. Since the VIC-20, this is abstracted: The IOBASE function returns the start address of the VIA in memory, and BASIC reads from the indexes 4, 5, 8 and 9 to access the timer values.
The VIC-20 Programmer’s Reference Guide states: “This routine exists to provide compatibility between the VIC 20 and future models of the VIC. If the I/O locations for a machine language program are set by a call to this routine, they should still remain compatible with future versions of the VIC, the KERNAL and BASIC.”
The PET already allowed the user to override the following vectors in RAM to hook into some KERNAL functions:
The VIC-20 ROM replaces these vectors with a more extensive table of addresses in RAM at $0300 to hook core BASIC and KERNAL functions. The KERNAL ones start at $0314. The first three can be used to hook IRQ, BRK and NMI:
The others allow overriding the core set of KERNAL calls
The “USRCMD” vector is interesting: It’s unused on the VIC-20 and C64. On all later machines, this vector is documented as “EXMON” and allows hooking the machine code monitor’s command entry. The vector was presumably meant for the monitor from the beginning, but this feature was cut from these two machines.
The KERNAL documentation warns against changing these vectors by hand. Instead, the VECTOR call allows the application to copy the complete set of KERNAL vectors ($0314-$0333) from and to private memory. The RESTOR command sets the default values.
If an application hooks the IRQ vector, it could just insert itself and call code originally pointed to by the vector, or completely replace the IRQ code (and return with pulling the registers and RTI). In the latter case, it may still want the keyboard and the system clock to work. The PET already had the UDTIM ($FFEA) call to update the clock in the IRQ context. The VIC-20 adds SCNKEY to handle the keyboard and populating the keyboard buffer.
The CBM-II series of computers was meant as a successor of the PET 4000/8000 series. The KERNAL’s architecture was based on the VIC-20.
The vector table in RAM is compatible except for ILOAD, ISAVE and USRCMD (which is now used), whose order was changed:
There are two new keyboard-related vectors:
And all IEEE-488 KERNAL calls except ACPTR can be hooked:
For no apparent reason, the VECTOR and RESTOR calls have moved to different addresses:
And there are several new calls. All machines since the VIC-20 have a way to hand control to ROM cartridges instead of BASIC on system startup. At this point, no system initialization whatsoever has been done by the KERNAL, so the application or game on the cartridge can start up as quickly as possible. Applications that want to be forward-compatible can call into the following new KERNAL calls to initialize different parts of the system:
The LKUPLA and LKUPSA calls are used by BASIC to find unused logical and secondary addresses for channel I/O, so its built-in disk commands can open channels even if the user has currently open channels – logical addresses have to be unique on the computer side, and secondary addresses have to be unique on the disk drive side.
It also added 6 generally useful calls:
Both the KERNAL and the BASIC ROM of the C64 are derived from the VIC-20, so both the KERNAL calls and the vectors are fully compatible with it, but some extensions from the CBM-II carried over: The IOINIT and CINT calls to initialize I/O and the text screen exist, but at different addresses, and a new RAMTAS call has been added, which is also useful for startup from a ROM cartridge.
The other CBM-II additions are missing, since they are not needed, e.g. because BASIC doesn’t have the V4 disk commands (LKUPLA, LKUPSA) and because there is only one RAM bank (TXJMP, ALOCAT).
The next Commodore 8 bit computers in historical order are the 264 series: the C16, the C116 and the Plus/4, which share the same general architecture, BASIC and KERNAL. But they are neither meant as successors of the C64, nor to the CBM-II series – they are more like spiritual successors of the VIC-20. Nevertheless, the KERNAL jump table and vectors are based on the C64.
Since the 264 machines don’t have an NMI, the NMI vector is missing, and the remaining vectors have been moved in memory. This makes most of the vector table incompatible with their predecessors:
The Plus/4 is the first machine from the home computer series to include the machine code monitor, so the USRCMD vector is now used for command input in the monitor.
And there is one new vector, ITIME, which is called one every frame during vertical blank.
The Plus/4 supports all C64 KERNAL calls, plus some additions. The RESET call has been added to the very end of the table:
There are nine more undocumented entries, which are located at lower addresses so that there is an (unused) gap between them and the remaining calls. Since the area $FFD0 to $FF3F is occupied by the I/O area, these vectors are split between the areas just below and just above it. These two sets are known as the “banking routine table” and the “unofficial jump table”.
The DEFKEY call has the same functionality as FUNKEY ($FF75) call of the CBM-II series, but the two take different arguments.
The Commodore 128 is the successor of the C64. Next to a 100% compatible C64 mode that used the original ROMs, it has a native C128 mode, which is based on the C64 (not the CBM-II or the 264), so all KERNAL vectors and calls are compatible with the C64, but there are additions.
The KERNAL vectors are the same as on the C64, but again, the USRCMD vector (at the VIC-20/C64 location of $032E) is used for command input in the machine code monitor. There are additional vectors starting at $0334 for hooking editor logic as well as pointers to keyboard decode tables, but these are not part of the KERNAL vectors, since the VECTOR and RESTOR calls don’t include them.
The set of KERNAL calls has been extended by 19 entries. The LKUPLA and LKUPSA calls from the CBM-II exist (because BASIC has disk commands), but they are at different locations:
There are also several calls known from the Plus/4, but at different addresses:
And there are another 14 completely new ones:
Interestingly, the C128 Programmer’s Reference Guide states that all calls since the C64 “are specifically for the C128 and as such should not be considered as permanent additions to the standard jump table.“
The C65 (also known as the C64X) was a planned successor of the C64 line of computers. Several hundred prerelease devices were built, but it was never released as a product. Like the C128, it has a C64 mode, but it is not backwards-compatible with the C128. Nevertheless, the KERNAL of the native C65 mode is based on the C128 KERNAL.
Like the CBM-II, but at different addresses, all IEE-488/IEC functions can be hooked with these 8 new vectors:
The C128 additions of the jump table are basically supported, but three calls have been removed and one has been added. The removed ones are DMA_CALL (REU support), DLCHR (VDC support) and GETCFG (MMU support). All three are C128-specific and would make no sense on the C65. The one addition is:
The removals and addition causes the addresses of the following calls to change:
The C128-added KERNAL calls on the C65 can in no way be called compatible with the C128, since several of the calls take different arguments, e.g. the INDFET, INDSTA, INDCMP calls take the bank number in the 65CE02’s Z register. This shows again that the C65 is no way a successor of the C128, but another successor of the C64.
The successorship of the Commodore 8 bit computers is messy. Most were merely spiritual successors and rarely truly compatible. The KERNAL source code and the features of the jump table mostly follow the successorship path, but some KERNAL features and jump table calls carried over between branches.
If you want to write code that works on multiple Commodore 8 bit machines, this table will help:
|
PET |
VIC-20 |
C64 |
CBM-II |
|
|
$FF80 |
– |
KERNAL Version |
– |
|
|
$FF81 |
– |
CINT |
– |
|
|
$FF84 |
– |
IOINIT |
– |
|
|
$FF87 |
– |
RAMTAS |
– |
|
|
$FF8A |
– |
RESTOR |
– |
|
|
$FF8D |
– |
VECTOR |
– |
|
|
$FF90 |
– |
SETMSG |
||
|
$FF93 |
– |
SECOND |
||
|
$FF96 |
– |
TKSA |
||
|
$FF99 |
– |
MEMTOP |
||
|
$FF9C |
– |
MEMBOT |
||
|
$FF9F |
– |
SCNKEY |
||
|
$FFA2 |
– |
SETTMO |
||
|
$FFA5 |
– |
IECIN |
||
|
$FFA8 |
– |
IECOUT |
||
|
$FFAB |
– |
UNTLK |
||
|
$FFAE |
– |
UNLSN |
||
|
$FFB1 |
– |
LISTEN |
||
|
$FFB4 |
– |
TALK |
||
|
$FFB7 |
– |
READST |
||
|
$FFBA |
– |
SETLFS |
||
|
$FFBD |
– |
SETNAM |
||
|
$FFC0 |
– |
OPEN |
||
|
$FFC3 |
– |
CLOSE |
||
|
$FFC6 |
CHKIN |
|||
|
$FFC9 |
CHKOUT |
|||
|
$FFCC |
CLRCHN |
|||
|
$FFCF |
BASIN |
|||
|
$FFD2 |
BSOUT |
|||
|
$FFD5 |
– |
LOAD |
||
|
$FFD8 |
– |
SAVE |
||
|
$FFDB |
– |
SETTIM |
||
|
$FFDE |
– |
RDTIM |
||
|
$FFE1 |
STOP |
|||
|
$FFE4 |
GETIN |
|||
|
$FFE7 |
CLALL |
|||
|
$FFEA |
UDTIM |
|||
|
$FFED |
– |
SCREEN |
||
|
$FFF0 |
– |
PLOT |
||
|
$FFF3 |
– |
IOBASE |
||
Code that must work on all Commodore 8 bit computers (without detecting the specific machine) is limited to the following KERNAL calls that are supported from the first PET up to the C65:
The CHKIN, CHKOUT, CLRCHN, CLALL and UDTIM would be available, but they are not useful, since they are missing their counterparts (opening a file, hooking an interrupt) on the PET. The UDTIM call would be available too, but there is no standard way to hook the timer interrupt if you include the PET.
Nevertheless, the four basic calls are enough for any text mode application that doesn’t care where the line breaks are. Note that the PETSCII graphical character set and the basic PETSCII command codes e.g. for moving the cursor are supported across the whole family.
If you are limiting yourself to the VIC-20 and above (i.e. excluding the PET but including the CBM-II), you can use the basic of 34 calls starting at $FF90.
You can only use these two vectors though – if you’re okay with changing them manually without going through the VECTOR call in order to support the CBM-II:
VECTOR and RESTOR are supported on the complete home computer series (i.e. if you exclude the PET and the CBM-II), and the complete set of 16 vectors can be used on all home computers except the Plus/4.
The initialization calls (CINT, IOINIT, RAMTAS) exist on all home computers since the C64. In addition, all these machines contain the version of the KERNAL at $FF80.
Between 1992 and 1995, I reverse engineered Commodore 64 applications by printing their disassemblies on paper and adding handwritten comments (in German). These are the PDF scans of the 62 applications, which are 552 pages total.
| File | Author | Date | Description |
| Adv. Squeezer | 1995-08-19 | Decompression code | |
| Amica Paint Schnellader | Fast loader Amica Paint extension | ||
| Bef.-Erw. | Diethelm Berens | BASIC extension | |
| Bitmap Manager | Hannes Sommer | 1994-10-26 | AGSP map editor |
| Bitstreamer | 1994-11-06 | Decompression code | |
| Blanking | Screen blanker | ||
| Creatures 2 Autostart | John Rowlands | 1993-05-03 | |
| Creatures 2 Loader | John Rowlands | 1993-05-04 | |
| Delta Coder | Nikolaus Heusler | 1994-08-25 | |
| Drive Composer | Chester B. Kollschen | 1994-05-25 | 1541 drive head sample player, Magic Disk 07/1993 |
| Drive Digi Player | Michael Steil | 1994-05-25 | 1541 drive head sample player |
| Drive ROMs | 1995-04-19 | Differences of the 1541/-II/-C/1571/1581 ROMs | |
| EmBa | Nikolaus Heusler | 1992-08-08 | Emergency BASIC |
| Errorline-Lister | 1992-08-18 | BASIC extension | |
| Fast Disk Set | |||
| Fast Load | Frank Deizner | 1994-09-29 | |
| Fast Save | Explorer/Agony | 1995-08-24 | |
| File Copier | 1993-07-22 | ||
| Final Cartridge III Freezer Loader | 1994-05-01 | Fast load/decompression code of the FC3 unfreeze binary | |
| Fred’s Back II | Hannes Sommer | 1994-12 | Parts of the AGSP game |
| GEO-RAM-Test | Mario Büchle | 1996-05-21 | GeoRAM detection code |
| GEOS Select Printer | 1993-01-25 | GEOS tool | |
| GoDot | A. Dettke, W. Kling | 1994-05-17 | Core code, ldr.koala, svr.doodle |
| Graphtool | 1992 | ||
| Heureka-Sprint | 1994-01 | Fast loader | |
| IRQ Loader 2 Bit | Explorer/Agony | 1995-08-24 | Fast loader |
| Kunst aus China Autostart | 1993-03-31 | ||
| MIST Entpacker | Michael Steil | 1995-08-21 | Decompression code |
| MIST Load V2 | Michael Steil | Fast load | |
| MSE V1.1 | 1992-08-08 | Programm type-in helper from 64’er Magazin | |
| MSE V2.1 | 1993-03-28 | Programm type-in helper from 64’er Magazin | |
| MTOOL | Michail Popov | 1992-08-14 | |
| Mad Code VSP | 1994-10-21 | VSP + DYSP code from the demo “Mad Code” | |
| Mad Format | 1995-04-20 | Fast format | |
| Magic Basic | BASIC extension | ||
| Magic Disk Autostart | 1992-07 | ||
| Master Copy | 1995-09-21 | Disk copy | |
| Master Cruncher | 1994-05-25 | Decompression code | |
| Mayhem in Monsterland VSP | John Rowlands | 1994-12 | VSP code from the game “Mayhem in Monsterland” |
| Mini-Erweiterung | Marc Freese | 1992-08-09 | |
| Mini-Scan | The Sir | 1993-07-22 | Disk error scanner |
| Mini-Tris | Tetris | ||
| Movie-Scroller | Ivo Herzeg | 1995-01 | |
| RAM-Check | T. Pohl | 1995-09-08 | REU detection |
| SUCK Copy | 1995-04-30 | File copy | |
| SUPRA 64 Loader | |||
| Shapes 64 | R. Löwenstein | 1994-09-05 | Text mode windowing |
| Small Ass | S. Berghofer | 1993-08-07 | Assembler |
| Spriterob | Andreas Breuer | 1992 | |
| Startprg.obj | M. Hecht | 1992-06 | |
| SuperinfoIRQ | Nikolaus Heusler | 1992-06 | |
| Swappers Best Copy | Disk copy | ||
| TPP’s Screensplitter | Armin Beck | 1995-03 | |
| The Sampler | 1994-04-30 | $D418 sample player (high volume on 8580!) | |
| Tiny Compiler | Nikolaus Heusler | 1994-09-06 | BASIC compiler |
| Turrican 1 Autostart | Manfred Trenz | 1994-11-02 | |
| Turrican 1 Loader | Manfred Trenz | 1994 | |
| Turrican 2 Autostart | Manfred Trenz | 1994-10-03 | |
| Vectorset | M. Strelecki | 1995-02-05 | |
| Vis-Ass | Mazim Szenessy | 1992-08 | Assembler and screen editor |
| Vocabulary | Schindowski | 1993-01-05 | FORTH library |
| Warp-Load | 1994-10-02 | Fast loader | |
The text screen of the Commodore 64 has a resolution of 40 by 25 characters, based on the hardware text mode of the VIC-II video chip. This is a step up from the VIC-20’s 22 characters per line, but since computers in the professional segment (Commodore PET 8000 series, CP/M, MS-DOS) usually had 80 columns, several solutions – both hardware and software – exist to allow 80 columns on a C64 as well. Let’s look at how this is done in software! At the end of this article, I present a fast and full-featured open source implementation with several different character sets.
First, we need to understand how 40 columns are done. The VIC-II video chip has dedicated support for a text mode. There is a 1000 (= 40 * 25) byte “Screen RAM”, each byte of which contains the character to be displayed at that location in the form of an index into the 2 KB character set, which contains 8 bytes (for 8×8 pixels) for each of the 256 characters. In addition, there is a “Color RAM”, which contains a 1000 (again 40 * 25) 4-bit values, which represents a color for each character on the screen.
Putting a character onto the screen is quite trivial: Just write the index of it to offset column + 40 * line into Screen RAM, and its color to the same offset in Color RAM. An application can load its own character set, but the Commodore 64 already comes with two character sets in ROM: One with uppercase characters and lots of graphical symbols (“GRAPHICS”), and one with upper and lower case (“TEXT”). You can switch these by pressing the Commodore and the Shift key at the same time.
There is no hardware support for an 80 column mode, but such a mode can be implemented in software by using bitmap mode. In bitmap mode, all 320 by 200 pixels on the screen can be freely addressed through an 8000 byte bitmap, which contains one bit for every pixel on the screen. Luckily for us, the layout of the bitmap in memory is not linear, but reminds of the encoding of text mode: The first 8 bytes in Bitmap RAM don’t describe, as you would expect, the leftmost 64 pixels on the first line. Instead, they describe the top left 8×8 block. The next 8 bytes describe the 8×8 block to the right of it, and so on.
This is the same layout as the character set’s: The first 8 bytes correspond to the first character, the next 8 bytes to the second character and so on. Drawing an 8×8 character onto a bitmap (aligned to the 8×8 grid) is as easy as copying 8 consecutive bytes.
This is what an 8×8 font looks like in memory:
0000 ··████·· 0008 ···██··· 0010 ·█████·· 0001 ·██··██· 0009 ··████·· 0011 ·██··██· 0002 ·██·███· 000a ·██··██· 0012 ·██··██· 0003 ·██·███· 000b ·██████· 0013 ·█████·· 0004 ·██····· 000c ·██··██· 0014 ·██··██· 0005 ·██···█· 000d ·██··██· 0015 ·██··██· 0006 ··████·· 000e ·██··██· 0016 ·█████·· 0007 ········ 000f ········ 0017 ········
For an 80 column screen, every character is 4×8 pixels. So we could describe the character set like this:
0000 ········ 0008 ········ 0010 ········ 0001 ··█····· 0009 ··█····· 0011 ·██····· 0002 ·█·█···· 000a ·█·█···· 0012 ·█·█···· 0003 ·███···· 000b ·███···· 0013 ·██····· 0004 ·███···· 000c ·█·█···· 0014 ·█·█···· 0005 ·█······ 000d ·█·█···· 0015 ·█·█···· 0006 ··██···· 000e ·█·█···· 0016 ·██····· 0007 ········ 000f ········ 0017 ········
Every 4×8 character on the screen is either in the left half or the right half of an 8×8 block, so drawing an 4×8 character is as easy as copying the bit pattern into the 8×8 block – and shifting it 4 bits to the right for characters at odd positions.
In bitmap mode, it is only possible to use two out of the 16 colors per 8×8 block, because there are only 1000 (40 * 25) entries for the color matrix. This is a problem, since we need three colors per 8×8: Two for the two characters and one for the background. We will have to compromise: Whenever a character gets drawn into an 8×8 block and the other character in the block has a different color, that other character will be changed to the same color as the new character.
Scrolling on a text screen is easy: 960 bytes of memory have to be copied to move the character indexes to their new location. In bitmap mode, 7680 bytes have to be copied – 8 times more. Even with the most optimized implementation (73ms, about 3.5 frames), scrolling will be slower, and tearing artifacts are unavoidable.
Creating a 4×8 character set that is both readable and looks good is not easy. There has to be a one-pixel gap between characters, so characters can effectively only be 3 pixels wide. For characters like “M” and “N”, this is a challenge.
These are the character sets of four different software solutions for 80 columns:
COLOR 80 by Richvale Telecommunications
80COLUMNS
SCREEN-80 by Compute’s Gazette
Highspeed80 by CKtwo
Some observations:
The “EDITOR” is the part of C64’s ROM operating system (“KERNAL”) that handles printing characters to the screen (and interpreting control characters), as well as converting on-screen contents back into a PETSCII string – yes, text input on CBM computers is done by feeding the keyboard input directly into character output, and reading back the screen contents when the user presses the return key. This way, the user can use the cursor keys to navigate to existing text anywhere on the screen (even to the output of previous commands), edit it, and have the system interpret it as input when pressing return.
The C64’s EDITOR can only deal with 40 columns (but has a very nice feature that allows using two 40 character lines as one virtual 80 character input line), and has no idea how to draw into a bitmap, so a software 80 characters solution basically has to provide a complete reimplementation of this KERNAL component.
The KERNAL provides user vectors for lots of its functionality, so both character output, and reading back characters from the screen can be hooked (vectors IBSOUT at $0326 and IBASIN at $0324). In addition to drawing characters into the bitmap, the character codes have to be cached in a 80×25 virtual Screen RAM, so the input routine can read them back.
The PETSCII code contains control codes for changing the current color, moving the cursor, clearing the screen, turning reverse on and off, and switching between the “GRAPHICS” and “TEXT” character sets. The new editor has provide code to interpret these. There are two special cases though: When in quote mode (the user is typing text between quotes) or insert mode (the user has typed shift+delete), most special characters show up as inverted graphical characters instead of being interpreted. This way, control characters can be included e.g. in strings in BASIC programs.
There are two functions though that cannot be intercepted through vectors: Applications (and BASIC programs) change the screen background color by writing the color’s value to $d020, since there is no KERNAL function or BASIC command for it, and the KERNAL itself switches between the two character sets (when the user presses the Commodore and the Shift key at the same time) by directly writing to $d018. The only way to intercept these is by hooking the timer interrupt vector and detecting a change in these VIC-II registers. If the background color has changed, the whole 1000 byte color matrix for bitmap mode has to be updated, and if the character set has changed, the whole screen has to be redrawn.
I looked at all existing software implementations I could find and concluded that “80COLUMNS” (by an unknown author) had the best design and was the only one to implement the full feature set of the original EDITOR. I reverse-engineered it into structured, easy to read code, added Ilker Ficicilar’s fast scrolling patch as well as my own minor cleanups, fixes and optimizations.
https://www.github.com/mist64/80columns
The project requies cc65 and exomizer to build. Running make will produce 80columns-compressed.prg, which is about 2.2 KB in size and can be started using LOAD/RUN.
The source contains several character sets (charset.s, charset2.s etc.) from different 80 column software solutions, which can be selected by changing the reference to the filename in the Makefile.
The object code resides at $c800-$cfff. The two character sets are located at $d000-$d7ff. The virtual 80×25 Screen RAM (in order to read back screen contents) is at $c000-$c7ff. The bitmap is at $e000-$ff40, and the color matrix for bitmap mode is at $d800-$dbe8. All this lies beyond the top of BASIC RAM, so BASIC continues to have 38911 bytes free.
In order to speed up drawing, the character set contains all characters duplicated like this:
0000 ········ 0008 ········ 0010 ········ 0001 ··█···█· 0009 ··█···█· 0011 ·██··██· 0002 ·█·█·█·█ 000a ·█·█·█·█ 0012 ·█·█·█·█ 0003 ·███·███ 000b ·███·███ 0013 ·██··██· 0004 ·███·███ 000c ·█·█·█·█ 0014 ·█·█·█·█ 0005 ·█···█·· 000d ·█·█·█·█ 0015 ·█·█·█·█ 0006 ··██··██ 000e ·█·█·█·█ 0016 ·██··██· 0007 ········ 000f ········ 0017 ········
This way, the drawing code only has to mask the value instead of shifting it. In addition, parts of character drawing and all of screen scrolling are using unrolled loops for performance.
Contributions to the project are very welcome. It would be especially interesting to add new character sets, both existing 4×8 fonts from other projects (including hinted TrueType fonts!), and new ones that combine the respective strengths of the existing ones.
Reducing the size of characters to 4×6 would allow a text mode resolution of 80×33 characters. Novaterm 10 has an implementation. At this resolution, logical characters don’t end at vertical 8×8 boundaries any more, making color impossible, and the drawing routine a little slower. It would be interesting to add an 80×33 mode as a compile time option to “80columns”.
Many reverse-engineered versions of “KERNAL”, the C64’s ROM operating system exist, and some of them even in a form that can be built into the original binary. But how about building the original C64 KERNAL source with the original tools?
The Commodore engineer Dennis Jarvis rescued many disks with Commodore source, which he gave to Steve Gray for preservation. One of these disks, c64kernal.d64, contains the complete source of the original KERNAL version (901227-01), including all build tools. Let’s build it!
First, we need a Commodore PET. Any PET will do, as long as it has enough RAM. 32 KB should be fine. For a disk drive, a 2040 or 4040 is recommended if you want to create the cross-reference database (more RAM needed for many open files), otherwise a 2031 will do just fine. The VICE emulator will allow you to configure such a system.
First you should delete the existing cross-reference files on disk. With the c1541 command line tool that comes with VICE, this can be done like this:
c1541 c64kernal.d64 -delete xr* -validate
Now attach the disk image and either have the emulator autostart it, or
LOAD"ASX4.0",8
RUN
This will run the “PET RESIDENT ASSEMBLER”. Now answer the questions like this:
PET RESIDENT ASSEMBLER V102780 (C) 1980 BY COMMODORE BUSINESS MACHINES OBJECT FILE (CR OR D:NAME): KERNAL.HEX HARD COPY (CR/Y OR N)? N CROSS REFERENCE (CR/NO OR Y)? N SOURCE FILE NAME? KERNAL
The assembler will now do its work and create the file “KERNAL.HEX” on disk. This will take about 16 minutes, so you probably want to switch your emulator into “Warp Mode”. When it is done, quit the emulator to make sure the contents of the disk image are flushed.
Using c1541, we can extract the output of the assembler:
c1541 c64kernal.d64 -read kernal.hex
The file is in MOS Technology Hex format and can be converted using srecord:
tr '\r' '\n' < kernal.hex > kernal_lf.hex
srec_cat kernal_lf.hex -MOS_Technologies \
-offset -0xe000 \
-fill 0xaa 0x0000 0x1fff \
-o kernal.bin -Binary
This command makes sure to fill the gaps with a value of 0xAA like the original KERNAL ROM.
The resulting file is identical with 901227-01 except for the following:
Also note that $FF80, the KERNAL version byte is $AA – the first version of KERNAL did not yet use this location for the version byte, so the effective version byte is the fill byte.
An ASCII/LF version of the source code is available at https://github.com/mist64/cbmsrc.
;**************************************** ;* * ;* KK K EEEEE RRRR NN N AAA LL * ;* KK KK EE RR R NNN N AA A LL * ;* KKK EE RR R NNN N AA A LL * ;* KKK EEEE RRRR NNNNN AAAAA LL * ;* KK K EE RR R NN NN AA A LL * ;* KK KK EE RR R NN NN AA A LL * ;* KK KK EEEEE RR R NN NN AA A LLLLL * ;* * ;*************************************** ; ;*************************************** ;* PET KERNAL * ;* MEMORY AND I/O DEPENDENT ROUTINES * ;* DRIVING THE HARDWARE OF THE * ;* FOLLOWING CBM MODELS: * ;* COMMODORE 64 OR MODIFED VIC-40 * ;* COPYRIGHT (C) 1982 BY * ;* COMMODORE BUSINESS MACHINES (CBM) * ;*************************************** .SKI 3 ;****LISTING DATE --1200 14 MAY 1982**** .SKI 3 ;*************************************** ;* THIS SOFTWARE IS FURNISHED FOR USE * ;* USE IN THE VIC OR COMMODORE COMPUTER* ;* SERIES ONLY. * ;* * ;* COPIES THEREOF MAY NOT BE PROVIDED * ;* OR MADE AVAILABLE FOR USE ON ANY * ;* OTHER SYSTEM. * ;* * ;* THE INFORMATION IN THIS DOCUMENT IS * ;* SUBJECT TO CHANGE WITHOUT NOTICE. * ;* * ;* NO RESPONSIBILITY IS ASSUMED FOR * ;* RELIABILITY OF THIS SOFTWARE. RSR * ;* * ;*************************************** .END
The GEOS operating system managed to clone the Macintosh GUI on the Commodore 64, a computer with an 8 bit CPU and 64 KB of RAM. Based on Maciej Witkowiak's work, I created a reverse-engineered source version of the C64 GEOS 2.0 KERNAL for the cc65 compiler suite:
https://github.com/mist64/geos
This makes the source a great starting point for
Just fork the project and send pull requests!
Major GEOS applications on the Commodore 64 protect themselves from unauthorized duplication by keying themselves to the operating system's serial number. To avoid tampering with this mechanism, the system contains some elaborate traps, which will be discussed in this article.
The GEOS boot disk protects itself with a complex copy protection scheme, which uses code uploaded to the disk drive to verify the authenticity of the boot disk. Berkeley Softworks, the creators of GEOS, found it necessary to also protect their applications like geoCalc and geoPublish from unauthorized duplication. Since these applications were running inside the GEOS "KERNAL" environment, which abstracted most hardware details away, these applications could not use the same kind of low-level tricks that the system was using to protect itself.
The solution was to use serial numbers. On the very first boot, the GEOS system created a 16 bit random number, the "serial number", and stored it in the KERNAL binary. (Since the system came with a "backup" boot disk, the system asked for that disk to be inserted, and stored the same serial in the backup's KERNAL.) Now whenever an application was run for the first time, it read the system's serial number and stored it in the application's binary. On subsequent runs, it read the system's serial number and compared it with the stored version. If the serial numbers didn't match, the application knew it was running on a different GEOS system than the first time – presumably as a copy on someone else's system: Since the boot disk could not be copied, two different people had to buy their own copies of GEOS, and different copies of GEOS had different serial numbers.
The code to verify the serial number usually looked something like this:
.,D5EF 20 D8 C1 JSR $C1D8 ; GetSerialNumber
.,D5F2 A5 03 LDA $03 ; read the hi byte
.,D5F4 CD 2F D8 CMP $D82F ; compare with stored version
.,D5F7 F0 03 BEQ $D5FC ; branch if equal
.,D5F9 EE 18 C2 INC $C218 ; sabotage LdDeskAcc syscall: increment vector
.,D5FC A0 00 LDY #$00 ; ...If the highest 8 bits of the serial don't match the value stored in the application's binary, it increments the pointer of the LdDeskAcc vector. This code was taken from the "DeskTop" file manager, which uses this subtle sabotage to make loading a "desk accessory" (a small helper program that can be run from within an application) unstable. Every time DeskTop gets loaded, the pointer gets incremented, and while LdDeskAcc might still work by coincidence the first few times (because it only skips a few instructions), it will break eventually. Other applications used different checks and sabotaged the system in different ways, but they all had in common that they called GetSerialNumber.
(DeskTop came with every GEOS system and didn't need any extra copy protection, but it checked the serial anyway to prevent users from permanantly changing their GEOS serial to match one specific pirated application.)
The downside of this scheme is that all applications are protected the same way, and a single hack could potentially circumvent the protection of all applications.
A generic hack would change the system's GetSerialNumber implementation to return exactly the serial number expected by the application by reading the saved value from the application's binary. The address where the saved valus is stored is different for every application, so the hack could either analyze the instructions after the GetSerialNumber call to detect the address, or come with a small table that knows these addresses for all major applications.
GEOS supports auto-execute applications (file type $0E) that will be executed right after boot – this would be the perfect way to make this hack available at startup without patching the (encrypted) system files.
Such a hack would change the GetSerialNumber vector in the system call jump table to point to new code in some previously unused memory. But the GEOS KERNAL has some code to counter this:
; (Y = $FF from the code before)
.,EE59 B9 98 C0 LDA $C098,Y ; read lo byte of GetSerialNumber vector
.,EE5C 18 CLC
.,EE5D 69 5A ADC #$5A ; add $5A
.,EE5F 99 38 C0 STA $C038,Y ; overwrite low byte GraphicsString vectorIn the middle of code that deals with the menu bar and menus, it uses this obfuscated code to sabotage the GraphicsString system call if the GetSerialNumber vector was changed. If the GetSerialNumber vector is unchanged, these instructions are effectively a no-op: The lo byte of the system's GetSerialNumber vector ($F3) plus $5A equals the lo byte of the GraphicsString vector ($4D). But if the GetSerialNumber vector was changed, then GraphicsString will point to a random location and probably crash.
Berkely Softworks was cross-developing GEOS on UNIX machines with a toolchain that supported complex expressions, so they probably used code like this to express this:
; Y = $FF
lda GetSerialNumber + 1 - $FF,y
clc
adc #<(_GraphicsString - _GetSerialNumber)
sta GraphicsString + 1 - $FF,yIn fact, different variations of GEOS (like the GeoRAM version) were separate builds with different build time arguments, so because of different memory layouts, they were using different ADC values here.
Note that the pointers to the GetSerialNumber and GraphicsString have been obfuscated, so that an attacker that has detected the trashed GraphicsString vector won't be able to find the sabotage code by looking for the address.
If the hack can't change the GetSerialNumber vector, it could put a JMP instruction at the beginning of the implementation to the new code. But the GEOS KERNAL counters this as well. The GetSerialNumber implementation looks like this:
.,CFF3 AD A7 9E LDA $9EA7 ; load lo byte of serial
.,CFF6 85 02 STA $02 ; into return value (lo)
.,CFF8 AD A8 9E LDA $9EA8 ; load hi byte of serial
.,CFFB 85 03 STA $03 ; into return value (hi)
.,CFFD 60 RTS ; returnAt the end of the system call function UseSystemFont, it does this:
.,E6C9 AD 2F D8 LDA $D82F ; read copy of hi byte of serial
.,E6CC D0 06 BNE $E6D4 ; non-zero? done this before already
.,E6CE 20 F8 CF JSR $CFF8 ; call second half of GetSerialNumber
.,E6D1 8D 2F D8 STA $D82F ; and store the hi byte in our copy
.,E6D4 60 RTS ; ...And in the middle of the system call function FindFTypes, it does this:
.,D5EB A2 C1 LDX #$C1
.,D5ED A9 96 LDA #$96 ; public GetSerialNumber vector ($C196)
.,D5EF 20 D8 C1 JSR $C1D8 ; "CallRoutine": call indirectly (obfuscation)
.,D5F2 A5 03 LDA $03 ; read hi byte of serial
.,D5F4 CD 2F D8 CMP $D82F ; compare with copy
.,D5F7 F0 03 BEQ $D5FC ; if identical, skip next instruction
.,D5F9 EE 18 C2 INC $C218 ; sabotage LdDeskAcc by incrementing its vector
.,D5FC A0 00 LDY #$00 ; ...So UseSystemFont makes a copy of the hi byte of the serial, and FindFTypes compares the copy with the serial – so what's the protection? The trick is that one path goes through the proper GetSerialNumber vector, while the other one calls into the bottom half of the original implementation. If the hack overwrites the first instruction of the implementation (or managed to disable the first trap and changed the system call vector directly), calling though the vector will reach the hack, while calling into the middle of the original implementation will still reach the original code. If the hack returns a different value than the original code, this will sabotage the system in a subtle way, by incrementing the LdDeskAcc system call vector.
Note that this code calls a KERNAL system function that will call GetSerialNumber indirectly, so the function pointer is split into two 8 bit loads and can't be found by just searching for the constant. Since the code in UseSystemFont doesn't call GetSerialNumber either, an attacker won't find a call to that function anywhere inside KERNAL.
I don't know whether anyone has ever created a generic serial number hack for GEOS, but it would have been a major effort – in a time before emulators allowed for memory watch points. An attacker would have needed to suspect the memory corruption, compared memory dumps before and after, and then found the two places that change code. The LdDeskAcc sabotage would have been easy to find, because it encodes the address as a constant, but the GraphicsString sabotage would have been nearly impossible to find, because the trap neither uses the verbatim GraphicsString address nor GetSerialNumber function.
Usual effective hacks were much more low-tech and instead "un-keyed" applications, i.e. removed the cached serial number from their binaries to revert them into their original, out-of-the-box state.
In mid-1990, the floppy disk of special issue 55 of the German Commodore 64 magazine "64'er" contained the "Amica Paint" graphics program – which was broken beyond usefulness. I'll describe what went wrong.
"Amica Paint" was devloped by Oliver Stiller and first published in 64'er special issue 27 in 1988, as a type-in program that filled 25 pages of the magazine.
Two years later, Amica Paint was published again in special issue 55, which this time came with a floppy disk. But this version was completely broken: Just drawing a simple line would cause severe glitches.
64'er issue 9/1990 published an erratum to fix Amica Paint, which described three ways (BASIC script, asm monitor and disk monitor) to patch 7 bytes in one of the executable files:
--- a/a.paint c000.txt
+++ b/a.paint c000.txt
@@ -67,8 +67,8 @@
00000420 a5 19 85 ef a5 1a 85 f0 4c 29 c4 20 11 c8 20 6c ........L). .. l
00000430 c8 08 20 ed c7 28 90 f6 60 01 38 00 20 20 41 4d .. ..(..`.8. AM
00000440 49 43 41 20 50 41 49 4e 54 20 56 31 2e 34 20 20 ICA PAINT V1.4
-00000450 01 38 03 20 20 20 4f 2e 53 54 49 4c 4c 45 52 20 .8. O.STILLER
-00000460 31 39 39 30 20 20 20 01 31 00 58 3d 30 30 30 20 1990 .1.X=000
+00000450 01 38 03 42 59 20 4f 2e 53 54 49 4c 4c 45 52 20 .8.BY O.STILLER
+00000460 31 39 38 36 2f 38 37 01 31 00 58 3d 30 30 30 20 1986/87.1.X=000
00000470 59 3d 30 30 30 20 20 20 20 20 20 20 20 20 00 01 Y=000 ..
00000480 31 00 42 49 54 54 45 20 57 41 52 54 45 4e 20 2e 1.BITTE WARTEN .
00000490 2e 2e 20 20 20 20 00 64 0a 01 00 53 43 48 57 41 .. .d...SCHWAThis changes the credits message from "O.STILLER 1990" to "BY O.STILLER 1986/87" – which is the original message from the previous publication.
64'er magazine had published the exact same application without any updates, but binary patched the credits message from "1986/87" to "1990", and unfortunately for them, Amica Paint contained code to detect exactly this kind of tampering:
.,C5F5 A0 14 LDY #$14 ; check 20 bytes
.,C5F7 A9 00 LDA #$00 ; init checksum with 0
.,C5F9 18 CLC
.,C5FA 88 DEY
.,C5FB 79 51 C4 ADC $C451,Y ; add character from message
.,C5FE 88 DEY
.,C5FF 18 CLC
.,C600 10 F9 BPL $C5FB ; loop
.,C602 EE FD C5 INC $C5FD
.,C605 C9 ED CMP #$ED ; checksum should be $ED
.,C607 F0 05 BEQ $C60E
.,C609 A9 A9 LDA #$A9
.,C60B 8D E4 C7 STA $C7E4 ; otherwise sabotage line drawing
.,C60E 60 RTSThe code checksums the message "BY O.STILLER 1986/87". If the checksum does not match, the code will overwrite an instruction in the following code:
.,C7DC 65 EC ADC $EC
.,C7DE 85 EC STA $EC
.,C7E0 90 02 BCC $C7E4
.,C7E2 E6 ED INC $ED
.,C7E4 A4 DD LDY $DD
.,C7E6 60 RTSThe "LDY $DD" instruction at $C7E4 will be overwritten with "LDA #$DD", which will cause the glitches in line drawing.
The proper fix would have been to change the comparison with $ED into a comparison with $4F, the checksum of the updated message – a single byte fix. But instead of properly debugging the issue, 64'er magazine published a patch to restore the original message, practically admitting that they had cheated by implying the re-release was not the exact same software.