VIC-20 modified Kernal

[TommyE]

Hello

I wonder if there are other kernal replacements for the VIC-20 other than the JiffyDOS kernal?

Regards
TommyE

[Mike]

Hi,

this topic was discussed in another thread in the General section not too long ago ... ... see "modded VIC 20 kernals?".

You might though be interested in a certain modified BASIC ROM, which happens to fix a bug in the multiplication routine of the interpreter.

Greetings,

Michael

[TommyE]

Hello Mike.

Thanks for the pointers

I guess there wasn't to much demand for different kernals on the vic-20.

Guess I'll try to make the kernal with the multiplication fix.

Regards
Tommy

[Mike]

Guess I'll try to make the kernal with the multiplication fix.

As I hinted at in my preceding post, the patch is situated in the BASIC ROM. If you burn the EPROM and exchange the KERNAL ROM for it, you have a VIC-20 with two BASIC ROMs, but no KERNAL ... which just earns you a black screen on power up.

[Orangeman96]

Hello

I wonder if there are other kernal replacements for the VIC-20 other than the JiffyDOS kernal?

Regards
TommyE

You could certainly develop a custom BASIC/Kernal ROM(s) by mod-ing a VICE environment specific to your needs/wants, then produce your own replacement chips for use in your genuine hardware. This would be intricate work, for sure. Although I can't speak to the validity/accuracy of this commented disassembly, it very much illustrates how complex these two 8K ROMs are/can be: almost completely commented Vic 20 ROM disassembly. -OGM

[christo]

In addition to the effort required, and apart from faster disk routines as exemplified by JiffyDOS, what sort of thing would be best done in a kernal as opposed to a cart or disk program? If I understand correctly, the kernal is a fixed standard library or API that any software might rely on.

Perhaps candidates for kernal software can only really be formed from software routines that multiple developers rely on being already present. It seems like such hassle on the VIC to install and switch kernals compared to shipping the dependencies and just relying on enough installed RAM to distribute the whole thing.

Maybe some of the graphics systems I have read about on Denial are candidate components for a future kernal the community can embrace.

[Orangeman96]

Welcome to Denial, christo! I think it mainly had to do with a small number of bug fixes, noting that as an interpreted language, CBM BASIC V2 is itself a "kernal" of sorts. -OGM

[srowe]

The big issue with any alternative KERNAL is compatibility. There's no way to be certain that applications do not use entrypoints beyond what is vectored. CBM were very careful to not move code around even between the VIC-1001 and the VIC-20 (they NOPed unused code out rather than change addresses).

[christo]

Welcome to Denial, christo!

Thanks! Long time lurker.

The big issue with any alternative KERNAL is compatibility. There's no way to be certain that applications do not use entrypoints beyond what is vectored. CBM were very careful to not move code around even between the VIC-1001 and the VIC-20 (they NOPed unused code out rather than change addresses).

This is critical! Casually looking at some of the earliest VIC-20 releases, there are plenty of cases of JSR past the vector table, effectively ruining its whole reason to exist. That is the tip of the iceberg. After decades of releases relying on who knows what exact bytes being just so, I would think the kernal might as well be carved in stone.

On the positive side, it might be feasible to one day build a detailed map of how the kernal is actually used by the entire available corpus of VIC-20 software. I'm aware a claim like this makes quite a lot of optimistic assumptions about the accessibility and analysability of the vast majority of VIC-20 software and of course the software to do this analysis doesn't write itself.

[Mike]

In addition to the effort required, and apart from faster disk routines as exemplified by JiffyDOS, what sort of thing would be best done in a kernal as opposed to a cart or disk program? If I understand correctly, the kernal is a fixed standard library or API that any software might rely on.

The KERNAL provides a good abstraction from the actual hardware for many I/O (keyboard, screen, ...) and file related things. Where sensibly possible, input and output can be redirected from keyboard and screen to files (tape and disk), printers, RS232 and any other devices. For the latter case, the corresponding KERNAL calls are vectored, which allows to expand the functionality of the KERNAL without the necessity to replace it.

With keyboard and screen as standard I/O, the KERNAL provides a screen editor, which is used by BASIC to do entry of program lines and commands. There is a rudimentary memory management, mostly suited to provide BASIC with one big contiguous block of RAM; furthermore, a simple timekeeping function (jiffy clock), and of course the (re-)initialisation of all chips in case of power on, reset or NMI via STOP/RESTORE. The KERNAL also emulates(!) a MODEM for tape operation and the 6551 ACIA for RS232 operation.

Perhaps candidates for kernal software can only really be formed from software routines that multiple developers rely on being already present. It seems like such hassle on the VIC to install and switch kernals compared to shipping the dependencies and just relying on enough installed RAM to distribute the whole thing.

There is a good chance that any such extension will appear feasible to one programmer and unwanted for another programmer. This is even more the case for any extensions/changes that rely on new hardware.

As I wrote above, it is always possible to hook in extra functionality into the KERNAL by wedging into the vectors. The only problem that remains then is interoperability between programs that wedge into an overlapping set of vectors and/or occupy the same position in RAM. The latter issue would partly be solved by placing stuff into the KERNAL, however a program still can do those wedges, possibly rendering any 'improved' routine in the replacement KERNAL useless. That all weighs against that it is necessary to remove original KERNAL functionality for any extended new hardware support or new libraries (point in case: JiffyDOS).

Maybe some of the graphics systems I have read about on Denial are candidate components for a future kernal the community can embrace.

I presume you mean MINIGRAFIK here. That question repeatedly came up in the past, here's my response, and to quote from there:

Tying MG to hardware, either as KERNAL replacement or as autostarting BLK5 ROM - in the way SE did -, makes it only a bit easier for the programmer, but a lot harder for any user.

...

On the positive side, it might be feasible to one day build a detailed map of how the kernal is actually used by the entire available corpus of VIC-20 software. I'm aware a claim like this makes quite a lot of optimistic assumptions about the accessibility and analysability of the vast majority of VIC-20 software and of course the software to do this analysis doesn't write itself.

At least on the C64, KERNAL ROM modifications have a long history and a large body of experience. One important lesson is not to move or change code or data (especially not unrelated stuff) unless absolutely necessary for the modifications to work.

So JiffyDOS somewhat deliberately removed the Tape and RS232 routines to make room for the new routines of the faster IEC protocol. Use of tape or RS232 triggers an ?ILLEGAL DEVICE NUMBER error with JiffyDOS. But everything else still is at its old place.

The thread "Copyright on Vic20 Roms" is also a good read about fairly recent attempts at re-engineering KERNAL and BASIC, which led to mostly the same conclusions, and to quote from there as well:

Given the number (surely in the order of hundred thousands) of existing programs for the C64 (and VIC-20), I'd rather err my estimate to the side, that each and every instruction opcode byte of BASIC and KERNAL potentially could serve as valid entry point. Likewise, all table data could be somehow be referenced by some 3rd party program. There is no abstraction layer whatsoever (the KERNAL jump table being a honorable exception) which would help here.

In other words: if you begin to change the ROMs, you just enter a continuum where more and more programs fail, in proportion to the amount of changed code. A clean room implementation of the ROMs will probably approach 0% compatibility, save for pure BASIC programs and those few machine code programs which just reference the KERNAL jump table.