11

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?

  • 9
    10 PRINT "HELLO WORLD" 20 GOTO 10 :-) – cbmeeks May 31 '17 at 17:24
  • 3
    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 May 31 '17 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 May 31 '17 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 Jun 1 '17 at 2:06
  • "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 Mar 6 '18 at 20:28
12

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 Jun 1 '17 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 Jun 2 '17 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 Jun 19 '17 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 Jun 19 '17 at 19:33
7

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 Jun 19 '17 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 Jun 19 '17 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 Feb 28 '18 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 Feb 28 '18 at 23:32
6

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

3

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.

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.