Is there software that will run across multiple Commodore 8-bit machines without modification?

Question

I noticed in some of the answers in this question that the Commodore 8-bit line apparently used a jump table at $03xx for entry into the kernel ("kernal" for the pedantic) routines. Figuring that the jump table is more of a way to maintain compatibility across ROM revisions, I would also tend to think that maybe there are some entry points which are consistent across the PET/VIC-20/C64/C16/Plus4/C128.

Is there a degree of compatibility across these machines because of this jump table and are there any examples of programs which will run across two or more of these platforms because of it?

Answer 1

BASIC games that use no memory specific code can be ported between different commodore machines. (I did some successfully between PET and C64). Machinecode games could be transferred between some commodore machines if they were written to be portable. I never seen such programs but I found in this wikipedia artikel the following:

"The Adventure International games published for the VIC-20 on cartridge are an example of software that uses the KERNAL. Because they only use the jump table, the games can be memory dumped to disk, loaded into a Commodore 64, and run without modification."

But of course this program should use only the kernal routines. Most commodore programs access the screen by poking directly to the screen area. Since this area is on an other position in different machines this must be changed while porting the program. And of course forget using sound, or specific graphic features.

It is also interesting to note that commodore didn't promote this jumptable. in the 'reference guide' all kernal routines are mentioned with their absolute addresses.

Answer 2

It seems that Michael Steil at pagefault.org has recently posted an analysis of the KERNAL calls from all of the Commodore 8-bit machines to try and track lineage. However, what is relevant here is the table he includes near the bottom of his blog post that shows which vector entries are safe for which platforms.

The result of his findings is that only the following kernal vectors are consistent across all platforms (PET to C65): 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:

• $FFCF: BASIN – get character
• $FFD2: BSOUT – write character
• $FFE1: STOP – test for STOP key
• $FFE4: GETIN – get character from keyboard

Very interesting if you want to see how a "cross platform" program for the Commodore 8-bits can be done.

Link to the analysis is here: http://www.pagetable.com/?p=926

Answer 3

If the contents of the Scott Adams' adventure cartridges for the VIC-20 are loaded into the same addresses on the Commodore 64 and executed, the games will behave on the C64 just as they do on the VIC-20 except that screen formatting will be a little wonky. If exactly 22 characters precede a line break, the next line will appear appended to the first (since the C64 has a wider screen). Changing one byte in the code will fix that. I don't remember the address, but I think the old value was 22 and the corrected value will be 40.

Answer 4

Most basic programs with no use of POKE command should work. The finest example is probably the Hello World program:

10 PRINT "HELLO WORLD"
20 GOTO 10

Besides that, some cassette games from VIC-20 should work on C64 because they load themselves from the datasette to RAM - they most probably won't refer to a weird memory location that on VIC-20 is on the cartridge, but not on C64.

Answer 5

If you restrict your use of BASIC to statements and commands and functions that exist in version 2.0, with no memory-address references (so no POKE, PEEK, SYS, USR, or WAIT), and keep the program small enough to fit into the unexpanded VIC-20's 3583 bytes (including space taken up by variable values during the course of the program's execution), you can write a program that will load and run on any of the 8-bit Commodore machines. Everyone's favorite maze generator works great on all of them, from an original PET all the way through to a C65:

10 PRINT CHR$(142);:REM SHIFT TO UC/GFX, NOT THE DEFAULT ON ALL MACHINES
20 PRINT CHR$(205.5+RND(0));:GOTO 20

So with some care you can write portable BASIC. Portable machine code is harder; you run into a problem right away just picking a load address. Most machine-code programs on Commodores were either on cartridges (which appeared at a fixed spot in the address space) or loaded into the BASIC program area, in which case they started with a small BASIC program that used SYS to launch the machine code. But that's still machine-dependent; the most common start address for BASIC text on these machines is 4096/$1000, which is where it is on the PET, unexpanded VIC-20, and C-16/Plus4. But as soon as the VIC-20 has any memory expansion, the start of BASIC moves down to to 1024/$0400. BASIC text in the C-64 starts at 2048/$0800, while on the C-128 it starts at 7168/$1C00 - unless the high-resolution graphics screen has been reserved, in which case it starts at 16384/$4000 (and is hidden behind BASIC ROM, so you have to change the memory BANK to call it)! And even if you can reliably get the program loaded and executed, it's very hard to write position-independent 6502 code.

You could no doubt write some 6502 assembly source that would work across all the machines as long as it was reassembled (or at least re-loaded/linked, depending on how sophisticated your build system is) for each target machine. And there are of course some ways for code to inspect the machine and figure out which model it's being run on, so you can have different versions of some of the logic for different ones. Probably not and still fit into an unexpanded VIC-20, though. :)

And you'd be pretty much restricted to text I/O. The C64, C128, and C65 are the only machines with sprites; the TED machines (C-16 and Plus/4) do have high-res graphics capability, but while they offer the same basic graphics modes as the VIC-II machines (C64 and C128), the details are completely different. The C-65 uses a VIC-III and is different yet again.

The post-PET machines do all have the ability to simulate high-res graphics using custom character sets, though an unexpanded VIC only lets you map a small patch of screen that way. Even so, the details of how you go about setting that up are completely different from video chip to video chip, so you'd be looking at a lot of platform-conditional code.

Answer 6

With cc65's o65 format you can write drivers even across platforms (from PET to C65). With GEOS you have at least source code compatibility, not to mention LUnix.