modded VIC 20 kernals?

[Overdoc]

I wonder if there are any modded VIC 20 kernals around?
Apart from Jiffydos as well as the Dead-Test and Ram-Test kernals (which are for diagnostics, only) I am not aware of any others?

I am thinking about some mods like a built-in memory monitor (like the one from C64's Dolphindos?), or a built-in turbo tape (ok, due to smaller VIC files maybe not so much useful than on the C64), disk drive useage enhancements, etc.
Ofcourse Jiffydos is already offering many additions, but maybe they would be more?

If used together with the original kernal and the option to switch kernals without crashing the VIC, it would be cool to use different kernals for different tasks.
e.g. load some big VIC 20 program into memory with a disk or tape speeder kernal, then switch over to another kernal with built-in monitor to change some bytes, the switch over to the original kernal to test it running, etc., etc.

I wonder what's your opinion about this and if there are maybe already some VIC kernals I am not aware of?

[srowe]

Without adding some form of bank-switching you would have to remove some functionality (as JiffyDOS does). That then prevents you from switching it while the computer is running. There's too much code that presumes it can use any part of the KERNAL, not just the public entrypoints, having any alternative code in that block is just going to cause compatibility issues.

[Overdoc]

Well, maybe there are some major differences in the designs of the VIC 20 and C64 kernals, but on a C64 I can switch between Jiffydos, normal system, Dolphindos, Prologicdos, Speeddos, TurboTape Kernal, etc, etc. without the computer crashing, even though there is ofcourse functionality removed in all of those modified kernals. (most of them remove the RS232 and standard tape loading functions)

I understand that switching without crashing might not be possible at any time, from within any running application, but imho that also wouldn't be needed. At least for kernals which speed up disk or tape transfer it would be a benefit if switching was possible in 'idle mode', for instance switching back to normal system after having used an alternative kernal for loading (from disk or tape)

Another idea that just came to my mind would be a modified kernal, which makes the VIC20 compatible with a 1541 drive?
Since it is possible to set a 1541 into 1540 mode just via it's DOS rom, I guess that the same (speed?) adjustment could be made possible on the VIC 20's kernal rom to make the VIC 1541 compatible??

[srowe]

Another idea that just came to my mind would be a modified kernal, which makes the VIC20 compatible with a 1541 drive?

There's no compatibility problem between the VIC-20 and a 1541. The UI+/- allows you to recover the transfer speed loss that had to be added for compatibility with the C64.

[Overdoc]

Thanks for the correction, you are right, it is the other way round, the C64 is not compatible with the 1540 drive, but the VIC is compabiel with the 1541 anyway, also without switching it back to 1540 mode.
So there is no need for kernal modding

[Merytsetesh]

If I had one mod for the VIC KERNAL, it would be to amend the screen routines to take account of variable dimensions instead of relying on the hardcoded values...

[tokra]

If I had one mod for the VIC KERNAL, it would be to amend the screen routines to take account of variable dimensions instead of relying on the hardcoded values...

You do not need a new kernal for that: http://sleepingelephant.com/ipw-web/bul ... php?t=8375

Apart from that, I don't see much use in a kernal-replacement. With expansion-memory at IO2/IO3 you could use SoftJiffy and MINIMON also uses that area to hide itself.

The use-case that would make me replace the internal kernal just isn't there.

[Overdoc]

True, running Minimon in $9800..$9FFF certainly is a nice trick.

However, the disadvantage is that it needs an additional cartridge which is blocking the expansion port, so you will also need an expander.

In my case, I already have a kernal/eprom adapter and I can still add 4 more kernals to the 4 I have ready for burning into the eprom. So I would not need any additional hardware if I had a kernal with integrated Minimon

Jiffydos already covers many useful additions to the kernal, like the @ command for disk operations, or the function key shortcuts.
But there is a number of additional useful kernal modifications not available in Jiffydos:

- Minimon (or something alike)
- display of the start and end address in hex when loading a file (this is something I never want to miss being used to it for over 35 years from my Dolphin C64)
- various reset functions like bypassing autostart of a cartridge by holding certain keys during reset
- user defined startup text/colours
- SD2IEC enhancements (file browser, speed-loading, etc.)

[tokra]

True, running Minimon in $9800..$9FFF certainly is a nice trick.

However, the disadvantage is that it needs an additional cartridge which is blocking the expansion port, so you will also need an expander.

No, it does not, the cartridge port is extended on the MINIMON-cartridge: http://sleepingelephant.com/ipw-web/bul ... 29#p115929

- various reset functions like bypassing autostart of a cartridge by holding certain keys during reset

MINIMON does that as well.

I actually use a prototype of MINIMON in conjunction with the MegaCart. The MegaCart has SJLOAD included, so it automatically loads fast from floppy. When I need MINIMON I can just flip the switch on the cartridge and there it is.

All without opening up your VIC-20 and unsoldering the kernal-ROM. I like to compare the MINIMON-cartridge to the "TRON"-program from the movie of the same name

[RJBowman]

The KERNAL is accessed through a jump table in RAM. You can change those jump points and switch out any KERNAL subroutine you want without having to replace ROMs.

[Mike]

The KERNAL is accessed through a jump table in RAM. You can change those jump points and switch out any KERNAL subroutine you want without having to replace ROMs.

That is the same case with the C64, but it did not give people a reason not to produce modified KERNAL ROMs.

Edit/Addition: That being said, IMO the main application for modified KERNALs is/was to provide alternate I/O for parallel drive speeders (on the user port), incorporate IEEE support (similar to the VIC-1112 cartridge), perhaps providing parallel printer support. These KERNALs always had to compromise on the tape and RS232 routines in case the original IEC routines were intended to be kept.

On the C64, it is possible to try out a modified KERNAL without a permanent change on the mainboard by just doing a RAM copy and changing CPU port/PLA action to let the CPU access the RAM under the ROM. Alternatively, some involved circuitry in a cartridge can also replace the KERNAL from the outside, while still allowing access to the RAM under the (then external) KERNAL. Both methods cannot be realised on a VIC-20 without internal modifications, the chipset logic does not allow for that. One needs to replace the KERNAL ROM itself, perhaps by unsoldering it first and placing a socket instead. All this puts a strong impediment on any developments in that regard on the VIC-20, and JiffyDOS is about the only notable exception to the rule.

- user defined startup text/colours

IMO, changes to the standard display colours and startup message are not much more than a vanity job. They are only visible for a short time after power up, and any loaded and started program will likely have its own idea about the display colours.

[bjonte]

If I had one mod for the VIC KERNAL, it would be to amend the screen routines to take account of variable dimensions instead of relying on the hardcoded values...

Yeah, asking for the screen size returns hard coded values. It would have been nice if that was dynamic, but sadly too late.

[Mike]

[...] asking for the screen size returns hard coded values. It would have been nice if that was dynamic, but sadly too late.

The KERNAL call JSR $FFED (SCREEN) is beyond uselessness. It assumes a level of abstraction (regarding the screen size) that at that time neither was expected nor required from programs using screen output.

With the 264 series, JSR $FFED still returns 40x25 as screen size even if a window had been set. That had been corrected on the C128, but there, for example, TEDMON still does not adapt its M display for a windowed - i.e. reduced - number of columns ... ... it only switches between a fixed 8 bytes/line for the 40 column display on VIC-II and 16 bytes/line for the 80 column VDC display.

In any case, the fundamental issue is sorted out for the VIC-20 anyway with tokra's Maxi-/Uber-Edit. Programs are free to use this tool for a certain given, new screen size - and then they have a good idea what that new screen size is and neither do need JSR $FFED to inquire it.

[Rich]

So are there any custom kernal roms, I have jiffydos and the original with a switch.

[Overdoc]

On the C64, it is possible to try out a modified KERNAL without a permanent change on the mainboard by just doing a RAM copy and changing CPU port/PLA action to let the CPU access the RAM under the ROM. Alternatively, some involved circuitry in a cartridge can also replace the KERNAL from the outside, while still allowing access to the RAM under the (then external) KERNAL. Both methods cannot be realised on a VIC-20 without internal modifications, the chipset logic does not allow for that. One needs to replace the KERNAL ROM itself, perhaps by unsoldering it first and placing a socket instead. All this puts a strong impediment on any developments in that regard on the VIC-20, and JiffyDOS is about the only notable exception to the rule.

Correct, floppy-speeder systems were the main reason for modified kernals. But most of them came with additional benefits like the ones I listed.
But soft-loading a kernal in RAM below the original kernal ROM only makes sense for testing. Otherwise, the soft-loaded kernal will be overwirtten by any game or application which uses the RAM below the ROM (the RAM in this location is also overwritten by most unpacker-routines, even if the game/app does not have code in there)

But I think at least some VIC20s have the kernal already socketed from factory?

IMO, changes to the standard display colours and startup message are not much more than a vanity job. They are only visible for a short time after power up, and any loaded and started program will likely have its own idea about the display colours.

Since the startup colour selection is more readable on the VIC20 than it is on the C64 (blue on blue), this is indeed not a big topic on the VIC.
(I always had my Dolphindos with the colour schema from the SX64, which is similar to the VIC20 startup colours)