System information

The same 39 Kernal calls as on the Commodore 64 are also available on the Commodore 128. A few of these

calls differ from the calls made on the Commodore 64. According to "Das C128 Buch", it was necessary to make

these changes considering some special features of the C128, e.g. 40-column mode and 80-column mode.

In addition to the 39 Kernal calls that also exist on the Commodore 64, there are 19 new Kernal calls that are

Commodore 128 specific. There are for example calls for accessing or jumping to memory locations in a

selectable RAM bank (the C128 has two RAM banks each consisting of 64 kB as mentioned before), for going to

C64 mode, for booting from an autostart floppy, for switching between 40-column and 80-column modes, for

programming function keys and for outputting a string of data.

Except for the official Kernal calls, there are numerous other useful routines in the Kernal ROM, the screen editor

ROM and the BASIC interpreter ROM. In particular, it can be mentioned that there are a number of useful

routines in the screen editor ROM that is located at $C000-$CFFF. Some of the screen editor routines are called

when the Esc key followed by another key is pressed but the routines can also be called directly from an

assembly program. The routines are not described in "Das C128 Buch" but there are various other books that

describe at least some of the routines. For example, the "Commodore 128 Tips & Tricks" book (in German)

describes some useful routines.

RS-232

The main difference between programming the User Port RS-232 interface (device number 2) on the C128

compared to the C64 is that on the C128 a fixed range of memory addresses is always reserved for the 256-byte

output and input buffers. On the C64, on the other hand, the buffers are allocated in the end of BASIC text

memory when an RS-232 channel is opened and de-allocated when it is closed. Therefore, on the C64, when an

RS-232 channel is closed, the buffer contents are lost and when opening or closing an RS-232 channel, all BASIC

variables are cleared. This is not the case on the C128.

The memory addresses used for RS-232 system variables in zero-page are the same on the C128 as on the C64.

However, the RS-232 system variables that are not placed in zero-page (e.g. the control register and the

command register) are placed at different memory addresses on the C64 and the C128.

Return from interrupt

Both on the Commodore 64 and on the Commodore 128, if you want to execute your own code when an IRQ

occurs, you do this by changing the IRQ vector at $0314/$0315 to point to your own interrupt routine. When

your own interrupt routine has finished executing, it should then jump (JMP) to the address $FA65 (that was

originally stored in the IRQ vector at $0314/$0315) so that the things the Kernal usually does when an IRQ

occurs are still done. However, when you use more than one raster interrupt per screen update you probably only

want to jump to the Kernal interrupt routine once per screen update. Otherwise, the parts of the Kernal that are

handled at interrupt level will be handled too often resulting in strange effects such as the cursor blinking faster

than usual. Therefore, there is sometimes a need to be able to return from an interrupt without jumping to the

Kernal interrupt routine. The following code should be used for this:

PLASTA $FF00PLATAYPLATAXPLARTI

The red lines above should be added for the Commodore 128. For the Commodore 64, these lines should not be

present. What the two red lines do is to load a byte from the stack and then store it in the MMU configuration

interrupt occurred.

I have found that returning from an interrupt like explained above does not work together with BASIC (you end

up in the machine code monitor or the computer freezes) so do this only when you are programming in

assembly! The only way to return from an interrupt that I have found working together with BASIC is to jump to

the original Kernal interrupt routine (jumping to address $FA65). However, as written above, this leads to strange

effects if you have more than one interrupt per screen update (sprites will move too quickly, music will play too

quickly, the cursor will blink too quickly etc.). If you know how to solve this, please tell me!

Keyboard