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?

  • 16
    10 PRINT "HELLO WORLD" 20 GOTO 10 :-)
    – cbmeeks
    Commented May 31, 2017 at 17:24
  • 4
    One of the 'fun' parts of writing a Vic-20 emulator for ordinary users is that most of its software doesn't even work across all memory sizes of Vic-20 — because the window of RAM doesn't grow linearly, it also relocates, 6502 code is not inherently relocatable and a relocating loader is not supplied. Which doesn't rule out something being machine neutral through leverage of the OS but I feel it might be unlikely.
    – Tommy
    Commented May 31, 2017 at 18:30
  • ... though, perhaps relevantly, although the Vic and C64 share the same tape encoding format, they output with slightly different tone lengths (although within acceptable tolerances for each other), and some early C64 software is known to have shipped with the Vic-20 lengths. Sadly I got this tidbit from writings around attempts to differentiate target machine from tape images, where it was meant simply to say that tone lengths is one weighed factor with a certain known correlation. But nothing more specific than that.
    – Tommy
    Commented May 31, 2017 at 18:33
  • IIRC the jump table in RAM was mostly there to allow wedging in custom routines, since you can't really change the ROM (well, on the C64 you could use the RAM "under" the ROM, but not on the other machines), and not so much for compatibility across machines. The jump tables at $300 on several memory maps I looked at (VIC20, C64, Plus/4) are similar but not exactly the same.
    – Joe
    Commented Jun 1, 2017 at 2:06
  • 1
    "Commodore Educational Software" I believe was at least designed to run on the PET and C64. "Lemonade" was one of those programs.: myabandonware.com/browse/publisher/…
    – LawrenceC
    Commented Mar 6, 2018 at 20:28

6 Answers 6


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.

  • I guess it's possible that the jump table is consistent only because Commodore took advantage of a perpetual licence for that one version of Microsoft BASIC, shipping the same version with all its machines? So maybe they didn't document it because the result is unpredictable technical chance, caused unwittingly by purely business decisions? All speculation.
    – Tommy
    Commented Jun 1, 2017 at 11:37
  • 2
    Commodore had a fairly large collection of educational software for the 40-column PET series of computers. The programs which were written in BASIC 2.0 ran perfectly fine on the 40-column Commodore 64, although they were monochrome and only used PETSCII graphics. I believe some of them are available here: zimmers.net/anonftp/pub/cbm/pet/edu/Canada/index.html
    – Tim Locke
    Commented Jun 2, 2017 at 1:06
  • @TimLocke: The VIC-20 reference manual documents the Kernel jump table and recommends that programs use the addresses in that table rather than other addresses because other addresses might change. Programs that need only functions in the table tend to use the table, though there are a number of useful functions that aren't in the table, and a fair amount of code uses those. The BASIC interpreters in the Commodore 64 and VIC-20 are essentially the same except that for some reason the C64 interpreter is split into two address ranges $A000-$BFFF and $E000-$Exxx, versus...
    – supercat
    Commented Jun 19, 2017 at 19:31
  • ...the VIC-20 which just uses $C000-$Exxx. The $A000-$BFFC portion of the C64 version matches the VIC-20 version instruction for instruction, shifted down 8K; $E000-$E002 of the C64 match $BFFD-$BFFF of the VIC-20, and $E003-$Exxx of the C64 match $E000-$Exxx of the VIC-20, shifted up 3 bytes.
    – supercat
    Commented Jun 19, 2017 at 19:33

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


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.

  • Is there a proof-of-concept available (at least instructions) on how to do this?
    – bjb
    Commented Jun 19, 2017 at 17:21
  • @bjb: I don't remember the details, but there are a variety of ways one could go about it. Doing [untested] 1 OPEN 1,8,1,"PIRATE'S COVE":CMD 1:PRINT CHR$(0);CHR$(128); 2 FOR I=32768 TO 49151:PRINT CHR$(PEEK(I));:NEXT 3 PRINT#1,"";:CLOSE 1 on the VIC-20 would be a slow way of grabbing the data to disk, but would likely work [careful to include all the semicolons!]. Note that PRINT# is one word with no space. Using CMD 1 and PRINT should be faster than PRINT#1 for the individual bytes; the final PRINT#1,""; cancels the effect of CMD.
    – supercat
    Commented Jun 19, 2017 at 19:00
  • It's worth noting that these are the same games referenced in EL Dendo's comment above, not different ones: Adventure International was Scott Adams' company.
    – Jules
    Commented Feb 28, 2018 at 20:16
  • @Jules: Fair enough. My main point was that the games wouldn't run perfectly "without modification", but that the modification required was very slight (literally changing one byte, IIRC).
    – supercat
    Commented Feb 28, 2018 at 23:32

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

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.

  • 2
    Hey now, that program is cross platform to at least a dozen machines! :-)
    – bjb
    Commented Jun 19, 2017 at 17:21

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:

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.


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.

  • "driver"? Afaik there is no such thing in 8-bit commodore machines.
    – peterh
    Commented Dec 13, 2020 at 15:08
  • @peterh-ReinstateMonica Indeed? cc65.github.io/doc/c64.html#s7
    – Polluks
    Commented Dec 13, 2020 at 16:18
  • If I see it well, it is a C compiler for 8-bit machines! Wow!
    – peterh
    Commented Dec 13, 2020 at 18:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .