Denial

Did the 40- or 80-column expansions provide an alternate kernal ROM to allow them to be used by BASIC programs without modifications? Or did some of them, or none?

Those 40/80-column cartridges come along with an own video chip, dedicated video RAM, an own character generator ROM, firmware and some glue logic. They install their alternate screen editor routines as wedges into the KERNAL vectors. In many cases they add a RAM expansion (having 40 or 80 columns but still only 3.5K RAM available for BASIC wouldn't be that useful, no?).

Any 'malicious' program could kick these new screen editor routines out of service, by overwriting or re-initializing the involved vectors. Compatibility thus only is guaranteed for simple BASIC programs and machine code programs that do not bypass the KERNAL. Applications are thus restricted to self-written programs and software (like word processors) bundled with the cartridge, all of which anyhow are supposed to honour the new screen layout.

...

Incorporating the new screen editor into the KERNAL to somehow circumvent aforementioned issues would probably make more problems than it solves: first of all, on the VIC-20, it is not possible to replace the KERNAL with a cartridge. The replacement KERNAL thus would have to go onto the mainboard. Not all VIC-20s (especially not those with a CR board) have the KERNAL socketed, so you arrive at soldering work to remove the old KERNAL, place a socket there and insert the replacement KERNAL - all of which already go against the idea of having a non-permanent external cartridge solution. Unless that KERNAL then is switchable, it will likely render all 'standard' non-trivial programs and games non-functional, as these would be not prepared for the new environment. IMO, users would be better off using one of the bigger 8-bit CBMs instead, or a C128.

Thanks for the detailed response. So the only problem would be to ensure that the running program can fit in the RAM that isn’t blocked by cartridge ROM.

bjonte wrote:So the only problem would be to ensure that the running program can fit in the RAM that isn't blocked by cartridge ROM.

BLK1..3 for +24K RAM at your service.

What application did you have in mind?

Mike wrote: ↑Mon Oct 02, 2023 12:57 am IMO, users would be better off using one of the bigger 8-bit CBMs instead, or a C128.

Agreed! The VIC chip is the soul of the computer IMO (it's even in the name ha). Take away the VIC-20's video hardware, and you're left with a pretty generic 8-bit computer.

Mike wrote: ↑Mon Oct 02, 2023 4:26 am What application did you have in mind?

I’m working on a file manager application for the C128 and I started considering to port it to the VIC20 since it doesn’t have many such applications. The standard screen would of course work but it would be nice to make use of additional hardware as well. I’m not sure it will fit in 24 kB though. We’ll see.

Are you aware of these two?

• CBM Command (looks like this is someone else's clone of the repo? Sadly, I think Payton left the community and deleted everything he could after growing frustrated with some members of the community).
• DIRPlus

I think they both use 22-columns (or thereabout) and I'm not sure how they compare to what you have in mind in terms of features. I don't know if one exists, but it seems like a program using a soft-40 column mode would be both useful and reasonable to implement.

I tried a couple of file browsers before I started making my own. I didn’t like the ones I tested because they didn’t feel intuitive to me. Lots of keys to remember or small inconveniences like for example CBM Command overwriting files without asking and using @: which triggers the dreadful 1541 bug. I wanted dual listers (unlike Dirplus), proper support for recursive operations and I wanted the program to run in the internal function ROM of the C128.