How do I adjust the OS print output to different screen dimensions on VIC-20?

Question

The graphics chip of the VIC-20 has a setting for the number of columns and the number of rows to display. So, instead of the default values of 22 columns and 23 rows, for example, it is possible to set 24 columns and 25 rows:

POKE 36866,128+24:REM SET 24 COLUMS
POKE 36867,2*25  :REM SET 25 ROWS

However, the OS would still align printed text to lines 22 columns wide and avoid printing into the additional rows, making the mode only usable for characters which are directly poked into the screen memory.

Is it possible to adjust the actual value for rows and columns for the OS without the need for reimplementing the CHROUT function?

Answer 1

Is it possible to adjust the actual value for rows and columns for the OS without the need for reimplementing the CHROUT function?

Simple Answer:

No, you need to write a 'driver' and have it hooked.

---

Background:

While the Kernal does have attempts to support size independent operation, like with the SCREEN call at $FFED, returning screen size in X/Y to applications to adapt, all internal functions use hard coded values of 22/23.

---

How-to:

Hook the CHROUT vector (#10 at $0326) and, check in your driver if the current output (at $9A) is the screen (#3), if yes, do your thing, if no, continue with the original vector.

For a clean install it is a good idea to use the vector copy function at $FF8D to first copy the original vector table ($20 bytes) to some place in your memory (X/Y=address, CY set), then move the existing vector to your code (the exiting jump for not screen condition), then modify the table entry (Table+18/19) and finally move it back using the vector copy function (X/Y=address, CY cleared).

Caveat: This will only let program output use your driver and obey whatever new margins there are. The program editor will still work with its build in 22/23 values.

And while it would be nice to intercept $FFED as well, it isn't possible. So all programs checking for screen size will still see a 22/23 sized screen.

So, if someone wants to write an improved ROM, this would be one point to take care of :))

---

P.S.: All mentioned calls work on all Kernals on VC20, C64 Family (C64, C128, C65) and TED Family (C16, C116, Plus/4) and are assigned the same addresses. They don't exist, or have different addresses on PET/PET II family computers.

Answer 2

As Raffzahn points out, unfortunately you can't "adjust" the OS; you need to replace KERNAL code to have a different number of screen columns work mostly as expected.

So while there are demos out there such as Big One (s).prg and Big 2.prg (PAL version), which are nice to look at, they don't help when you actually want to program using such a screen. (They may well be worth looking at to get more details about how this technique works, however.)

If what you're looking for is a way to make programming more comfortable, however, and you have at least an 8K expansion, you might do better with one of the software 40-column systems. These might also serve as sophisticated examples of how to replace the KERNAL code, if you're willing to disassemble them or can find source.

TechTinkering reviews both "The Big One" above and several 40-column solutions in this blog post and demos them in this video.

He covers:

• VIC 40/FAT-40 (Fat 40.prg, PAL): This is one of the most memory-hungry extensions because it includes a lot of code to add PET compatibility; the intent is to make the VIC-20 able to run PET BASIC programs. It can also overlay "high" resolution graphics (such as they are on the VIC-20 :-)) on text. The demo (Fat40 demo.prg) is fairly impressive.

• Screen-40 (Screen-40.prg, NTSC): Similar to VIC 40/FAT-40 but drops PET compatibility, using 653 fewer bytes. This actually worked for me on PAL as well, though the text area was offset far to the upper-left on the screen, probably in the overscan area of a real television.

• Super Screen (PAL): Leaves slightly less memory free than Screen-40 and, but it does indeed have an nicer font. I've not played with (it needs to be pulled out of a tape image), but apparently in BASIC it prints annoying extra newlines. There may be an NTSC version available as well.

• PET Loader (PET Loader.prg, but it's actually a cartridge image; PAL): A cartridge that lets you boot up right into 40 columns. Provides PET emulation, but not as good as VIC-40/FAT-40. Doesn't work on NTSC, though some people are working on that.

The first two above are available on from Zimmer's archive under /pub/cbm/vic20/utilities/8k. The PET Loader cartridge image is available under /pub/cbm/vic20/roms/tools/8k/.

Answer 3

It is possible, if you copy the editor-code to RAM and create the hooks in the vector-table. I did a program for this some 2 years ago:

http://sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?f=2&t=8375

Basically you need to replace the CHRIN and CHROUT-vectors to point to your own code, which in this case is just a copy of the editor-code in the kernal, where every place the old screen-dimensions are those are replaced with the new values. You also need to make sure to move the screen-line-link-table to your own RAM if it becomes larger then 24 lines (=bytes). To make it work nicely, also let the BRK- and NMI-vectors point into your setup-code, so the editor will survive STOP/RESTORE. The source code is available in the program-download mentioned above for further insight.