40- and 80-column expansions

[bjonte]

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?

[Mike]

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.

[bjonte]

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.

[Mike]

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?

[Wilson]

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.

[bjonte]

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.

[Wilson]

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.

[bjonte]

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.

[bjonte]

The file manager has matured a bit now and consumes almost 32 kB on the C128. So that will rule out any use of 40- or 80 column solutions unless they use external screen memory. Cutting some features may bring it down closer to 24 kB and use the top bank for variable storage.

[doug_in_nc]

I don't know about other 40/80 column cards, but the Protecto card I have has 2K of ROM that resides at A000, and 2K of video RAM that resides at B000. You can issue a Poke (I don't remember which location, but I can check) to allow all memory available to be used contiguously, so the standard 3.5K, the normal VIC video RAM, 24K in blocks 1-3 and a 3K RAM expansion at RAM 1,2,3. I'm not near home right now to check, but off the top of my head, BASIC reports a bit over 31,000 bytes free on boot-up with a 16K, 8K and 3K RAM expansion added, so pretty close to the 32K you are using on the C128.

[Mike]

BASIC reports [...]

As soon as BLK1 is populated with RAM, the range for the +3K RAM expansion is blocked from BASIC use.

As maximum value, BASIC reports 28159 bytes free *).

There is a sticky Memory Map in the Programming Section, please consult such info beforehand.


*) unless, for example, the VFLI mod has been fitted, which adds the +3K on the VIC side of the busses. This then allows to move the screen RAM further down to $0400 so another 3072 bytes are added to aforementioned figure. This and any similar mod require soldering work on the mainboard, so they are rather unlikely to become 'mainstream' anytime soon.

[bjonte]

I'm not near home right now to check, but off the top of my head, BASIC reports a bit over 31,000 bytes free on boot-up with a 16K, 8K and 3K RAM expansion added, so pretty close to the 32K you are using on the C128.

Ah, yes. With 24 kB expansion I have a piece of the unexpanded 5 kB to chew on as well. The more RAM I can get the more directory entries can be loaded. I shall make an attempt to port it to see how small it can get without important things lost.

[doug_in_nc]

BASIC reports [...]

As soon as BLK1 is populated with RAM, the range for the +3K RAM expansion is blocked from BASIC use.

As maximum value, BASIC reports 28159 bytes free *).

There is a sticky Memory Map in the Programming Section, please consult such info beforehand.


*) unless, for example, the VFLI mod has been fitted, which adds the +3K on the VIC side of the busses. This then allows to move the screen RAM further down to $0400 so another 3072 bytes are added to aforementioned figure. This and any similar mod require soldering work on the mainboard, so they are rather unlikely to become 'mainstream' anytime soon.

As I said, BASIC can use the 3K same time as memory in Blocks 1-3 when you are using the video memory from the Protecto 80 column card and not the normal video memory. POKE 642,4:SYS 58232 and then reboot and you will see it.

See page 9 of the manual where it discusses BASIC showing 15359 bytes free when the 8K of extra RAM in the cartridge is augmented with a 3K RAM cartridge (details on page 9 of the manual linked below)

http://www.geocities.ws/cbm/data20/prot ... 3-MatA.pdf

[Mike]

My bad, I stand corrected.

Of course there's no need to place the screen into internal RAM, for VIC-I, when there's another video chip which has its own RAM elsewhere.

[bjonte]

Does Protecto ensure location 214 in memory reflects the current screen line? If you place the cursor on the first line, what does PRINTPEEK(214) print? And if on the last line?