Commodore 64 ROM Generations
Jim Butterfield, Associate Editor
Commodore products are often subject to changes in logic. Not marketing logic or pricing logic (although they change too), but the internal logic that drives the machines: the programs in ROM. This has been true of PET/CBM and various disk systems. This article traces differences in two major ROM releases of the Commodore 64 computer, plus a third released with the SX-64 portable computer.
Two Environments
The first 64s used ROM set 1. Before releasing a European version of the 64, Commodore developed ROM set 2. ROM 2 is unique in that it's the same for North America and Europe, yet recognizes and copes with differences between the two environments. More on that later.
Programs developed on ROM set 1 sometimes didn't seem to work on ROM set 2. This was particularly true when the screen was set up using a POKE statement. For example, a user clearing the screen and then typing the command POKE 1500,1 will print a letter A around the middle of the screen, but with ROM 2 this letter is "invisible." Many games and educational programs using the screen this way couldn't make the transition from ROM 1 to ROM 2; attractive graphics would become invisible and the effect would be lost.
I have met a third ROM recently; it's used in the SX-64 portable computer. There are small differences: For example, disk activities are given preference over tape, and screen POKEs are once again legal.
In all cases, the BASIC language in ROM is not changed (addresses $A000 to $BFFF). All changes are in the Kernal ROM, which resides at addresses $EOO0 to $FFFF.
All three ROM sets are very similar; the differences are largely cosmetic. Sometimes, of course, cosmetic differences are enough to prevent a particular program from working in a satisfactory manner; but there's a strong bond between all models I have examined.
The Tape Pause
When you give a tape LOAD command, the computer blanks the screen and searches for a program "header" on the tape. When it finds a program, it reports the name with a message, FOUND XXXXX, unblanks the screen, and waits. When you touch a key (preferably the Commodore Logo key), the screen blanks once again and the program starts to load.
ROM 1 waits forever. If you don't press a key, it keeps waiting. ROM 2, however, waits only a few seconds and then proceeds with the program load activity. ROM 3 for the SX-64 doesn't have a cassette tape connection, so it doesn't do either.
Why does the screen need to blank? Here's the reason: The screen interferes very slightly with the processor. Roughly once every y2ooo second, the processor chip is stopped briefly to allow the video chip to get extra information from memory. This is no hardship except when we need to read or write tape.
When cassette tape is active, the processor needs to time events precisely. It can't afford to miss even the brief time lapse that the video chip might cause. So it turns the screen off in order to get the most efficient timing "edge."
Technical note: The "Find Tape Header" subroutine at $F761 is changed in ROM 2 so that it calls a new subroutine at $E4E0 to allow time-out. The same coding is used in the SX-64 ROM, but it's not useful since this machine can't use tape.
Screen Clear
When ROM 1 clears the screen, it sets the foreground color of all screen locations to white. As a result, it's easy to POKE screen memory and have white characters appear.
ROM 2 changed all that. When the screen clears, the foreground color of all characters is set to the background color. If you POKE to an unused location, you'll end up printing blue on blue, which makes it invisible. The character is indeed there: You can see it if you place the cursor over that position. But it's not much use to the viewer.
Commodore may have done this to reduce screen "sparkle"—colored or white flashes that appear randomly on the screen. Whatever the reasoning, it caused writers of software some anguish if their existing programs POKEd the screen a good deal. Many Commodore demonstration programs lost their appeal on the new machines. All programs would still run, but the screen wouldn't look right.
With the new SX-64 ROM, we're back to allowing screen POKEs. It may be too late for software writers, but when the SX-64 clears the screen, it sets the foreground color of all screen locations to the cursor color. That's better than ROM 1, which sets white only—you have a chance to choose the POKE color.
Technical note: The Clear-a-Line subroutine at $E9FF was changed slightly to call a new sub-routine at $E4DA; this sets character color to back-ground color on ROM 2. On SX-64 ROM, character color is set to the value from $0286, the current "cursor" color.
Different Crystal Speeds
ROM 1 was designed for North American use. ROM 2 was designed for worldwide use, and considerable thought was put into creating a universal design. When power is applied to the computer, ROM 2 does some interesting detective work.
Very early in the game, ROM 2 set the raster interrupt to fire at scan line 622. Here's the trick: There is no line 622 on North American sets; if the interrupt signal fires, we must be elsewhere.
Depending on the continent, the ROM sets up timing for the clock and RS-232 transmission. What's happening here is that the two different types of machine are driven at different "crystal" speeds, and the program must compensate for this to allow consistent overall speed.
The programmer on a ROM 2 system must keep in mind that the raster interrupt register in the video chip has already been used by the system; it cannot be assumed to be zero.
Technical note: The table at $ECB9 which sets up the video chip has been changed to include the raster interrupt. The Power-Up Reset program itself has been changed at $FCFB by the insertion of a call to a new subroutine at $FF5B. If line 622 (Europe) is detected, address $02A6 is set to 1 to signal "European System." This new location, $02A6, is used to set up the timer which creates "jiffies"—1/60-second interrupts. It will also be checked if the RS-232 channel is opened, and timing information extracted from the appropriate table.
Small Stuff
ROM 1 had troubles if you tried to PRINT# to a device that wasn't there; ROM 2 has its act together a little better.
SX-64 ROM identifies itself with a new message: SX-64 BASIC V2.0, in case you didn't notice that it was an SX-64 you had.
If you hold down SHIFT and press RUN/STOP on the SX-64, you'll get a load/run from disk; the screen reads LOAD":*",8 … RUN. This data is stored in an area of memory that usually contains the message PRESS PLAY, but you won't be using the cassette this time so you won't miss that message. Any attempt to use a cassette on the SX-64, by the way, will result in an ILLEGAL DEVICE NUMBER message.
The differences are not great. Most users will spot only the tape pause and the screen POKE as operational differences.
Serious programmers will appreciate the fact that changes have been made as "patches," which means that previous entry points have not moved; they are still in the same places that they used to be. A call to a machine language subroutine at a given location will still be good.
There are still things that many users would like to see improved in Commodore 64 BASIC and Kernal. In particular: The INPUT statement is uncomfortable at times, and certain types of screen editing work awkwardly. You may have a wish list of your own. It seems quite likely that we'll see another ROM system one of these days.
Coming Soon
Commodore is said to be working on new ROM systems for the 64 and its peripherals. Compatibility is expected to be retained with previous ROMs, but certain operational annoyances will be eliminated.
Watch for a new Kernal ROM—we expect it to be coded 901227-03. It will fix up a couple of problems associated with screen usage.
The Commodore 64, like the VIC-20, behaves oddly if an INPUT statement is written with a lengthy prompt; if the prompting message is long enough, the user input will need to be typed onto the next line of the screen. In such a case, the computer receives a peculiar input: As well as reading what the user has typed in, it reads its own prompt message.
A more serious problem arises if a user types in a line longer than 80 characters, and then backs up using the Delete key. The too-long line goes beyond two rows on the screen, of course; but when the user backs up, the computer might stop working.
The above problems are expected to be fixed when the new version 3 chip is released. In addition, some of the above-noted changes for the SX-64 will also be implemented—for example, screen POKEs.
Commodore is also said to be working on new logic for printers and disk units. Watch for them, too.
Commodore 1541 Generations
Tracking the generations of Commodore's 1541 disk drive is not unlike reading a mystery novel. Unfortunately for 1541 owners, Commodore so far has not written the last page in which the mystery is revealed, so we can only examine the dues and speculate.
Clue No. 1: The original 1541 had a "long" circuit board which extended the length of the drive. This board probably was the same as was in the 1540 drive, predecessor to the 1541.
Clue No. 2: Both the 1540 and the original version of the 1541 had white cases.
Clue No. 3: Later versions of the 1541 have brown cases, and a "short" board which extends about half the length of the drive. Our sources tell us that the short board is a redesigned long board and that when the circuit I board was redesigned, timing problems showed up in the drive.
Clue No. 4: ROM chips bearing four different part numbers have been seen in 1541 drives. During a teleconference on the Commodore Information Network on March 29, 1984, a Commodore Research & Development representative gave the part number of the latest ROM as 901229-05. (The suffix 05 indicates the ROM version.) ROM chips with suffixes 01, 02, and 03 also have been seen in 1541 drives.
Clue No. 5: During the teleconference, the Commodore representative said that one of the changes incorporated into the 05 ROM version had to do with the serial bus. (Peripherals such as the 1541 and the 1525 printer connect to the Commodore 64 through the serial bus.)
Clue No. 6: Owners of the 1541 have reported problems when trying to use two 1541s; occasionally, when a program accesses one of the drives, the system locks up. Problems also have been reported involving lockup on systems with one 1541 drive and the Commodore 1526 and MPS-801 printers.
Clue No. 7: 1541 users report an intermittent problem when saving files to disk using the replace option (SAVE "@0:filename",8). Instead of replacing the intended file, the drive's operating system writes over another file on the disk, and changes the directory pointers so that the intended file is no longer accessible. A similar problem has been reported in the Commodore 4040 drives. At the teleconference, the Commodore representative said he'd never experienced this problem. However, he also said that the 4040 and 1541 used the same basic operating system.
Clue No. 8: A technical representative with Integrated Computer Repairs (ICR), of Santa Mesa, California, told us that his company repairs and updates the 1540 and 1541 drives. ICR claims that merely replacing the ROM chip with an 05 version is not enough; they also make hardware changes, modifying the short circuit board.
Clue No. 9: Overheating problems have been reported with the 1541. After the drive has been on for several hours, some users report input-output errors and other problems.
Clue No. 10: In the past, Commodore representatives have said that the 1541 ROM changes were "mainly cosmetic."
Clue No. 11: ICR claims that the drives they have updated no longer have lockup problems. It is not clear whether their update solves the save-with-replace problem.
Clue No. 12: COMPUTE! made several telephone calls to Commodore Business Machines, Inc., asking Commodore to respond to the above items. Ms. Susan West, of the Public Relations Department, promised to find a technical representative who could answer our questions. We never heard from a technical representative, and Ms. West failed to return our subsequent calls, the last placed as this article was going to press.
So, it seems that Commodore has issued at least four different versions of the 1541 disk drive, for reasons which are known only to them. And problems may exist (or have existed) not only in the ROM chips but also in the board circuitry. Finally, it appears that Commodore is unwilling to help us solve the mystery.