VIC - why 22 Columns?

[Schnurri]

Atari 400 with only 32 columns? That's definitely wrong. The 8-bit Atari machines all have 40 columns in normal text mode. Best regards, Schnurri

[cbmeeks]

Since the bus in the NTSC C64 runs at exactly the same speed, doubling the resolution required implementing a 40 bytes cache. On the 1st scanline of a row of 40 characters, the CPU can't access the bus at all and the VIC-II can now access at double the rate because it is 'stealing' the CPU half cycles. On the 7 subsequent scanlines, the VIC-II 'remembers' the character codes for all 40 columns and only needs to read the CG data, leaving the half cycles the CPU needs, as it should.

For the VIC-II, displaying a line of text require access to the bus 40x2+40x7=360 times. A jump from 22 to 40 columns of text only requires 8 more accesses for a line of text because of that cache.

Since there are 25 lines of text on the C64 normal display, the VIC-II steals 40x25=1000 cycles from the CPU every time the screen is refreshed. That's 60'000 cycles taken out of 1'022'727 cycles every second; a slowdown of 5.9%.

One of the best explanations of the infamous "bad lines" on the Commodore 64. Well done!

[MiaM]

The ZX-80 and ZX-81 actually had a trick where video memory did contain line feeds so you didn't need the full 32*24 screen in memory. This was only active when the total amount of ram were less than a few K (for ZX-80 expansions of 1/2/3k were afaik not uncommon, while for ZX-81 the standard expansion were 16k).

In general the resolution / pixel clock discussion is valid for NTSC, but on PAL you have a higher color clock (4.43 instead of 3.58) and also PAL does some tricks to cause less clash from the luminance to the color information - specifically by using a (up till about -85 analogue/mechanical) delay line and mix the color from the current line with that of the previous line, and also phase shift the color information each line. That in combination with the rations between clock frequencies makes a static black and white picture have less bleed onto the color, even though it's not ideal. VIC-I and VIC-II on purpose doesen't adhere to the standard ratio between the frequencies for two reasons. One is to make any color creep steady instead of moving, and another is to have as close to 50/60 Hz vertical frequency even though the picture is non interlaced (which otherwise would lead to one line too much or too little for every second non-interlaced frame).

Back to VIC 20:
At the time VIC 20 were desgned, there were of course no hardware reason to put the screen at 7680 and not at 4096 even without block 1 memory. By putting the screen at 4096 there wouldn't had been any reason to optimize for maximum usage of 512 bytes, at least not with 1024 nybbles of color ram.

Did they maybe have some kind of 512 nybble sram's in mind for color ram? maybe reusing slightly broken sram from warranty repairs of old PET boards? Were there even any 512 nybble SRAMs reasonably priced back then?

Or could it just had been that whoever made the first prototypes used 8k, maybe by modifying a PET 2001 sram board (which became obsolete by the PET 2001N/3000 series dram boards in -79)? Then putting the screen at 7680 would make sense, and at some point someone decided to scrap an amount of the RAM and to not disturb too much of the small amounts of test software written they might just had made the 3k "hole".

In hindsight of course the memory map could had been far better, and the kernal/editor should had been able to handle variable screen sizes, and there should had been a basic command to resize the screen.

Btw is there really any reason to want an even amount of chars? Anyway 22*23 or 23*22 is the most efficielt useage of 512 bytes with a VIC-I, so the question is mostly academic.

[Mike]

At the time VIC 20 were desgned, there were of course no hardware reason to put the screen at 7680 and not at 4096 even without block 1 memory. By putting the screen at 4096 there wouldn't had been any reason to optimize for maximum usage of 512 bytes, at least not with 1024 nybbles of color ram.

That arrangement would have made the +3K RAM expansion unusable for BASIC programs. As it stands, the +3K RAM expansion can be used without a repositioned screen memory (with RAM from $0400..$1DFF for BASIC programs), and of course the bigger RAM expansions take precedence and in that case "rightfully" *) lock away the smaller RAM expansion (if present).

Anyhow, a program that needs a bigger screen of course can reprogram the VIC screen (and character) base register as it wants - there's no requirement other than the default values applied on startup/reset, that the screen "has" to reside at any given position. And that bigger screen can then also use more than 512 nibbles of colour memory.

In hindsight [...] the kernal/editor should had been able to handle variable screen sizes, and there should had been a basic command to resize the screen.

This, and what's wrong with using just 4 POKEs for that purpose?


*) the video chip can only access internal RAM, therefore it is not possible to move the screen all the way down to $0400 (unless one modifies the mainboard). Rather, it is moved to the lowest possible address usable for both BASIC RAM or video RAM and that is $1000 - consequently, BASIC RAM has to start at $1201.

[MiaM]

At the time VIC 20 were desgned, there were of course no hardware reason to put the screen at 7680 and not at 4096 even without block 1 memory. By putting the screen at 4096 there wouldn't had been any reason to optimize for maximum usage of 512 bytes, at least not with 1024 nybbles of color ram.

That arrangement would have made the +3K RAM expansion unusable for BASIC programs. As it stands, the +3K RAM expansion can be used without a repositioned screen memory (with RAM from $0400..$1DFF for BASIC programs), and of course the bigger RAM expansions take precedence and in that case "rightfully" *) lock away the smaller RAM expansion (if present).

Well, the 3k expansion could be used with the screen at top (like it actually is) while unexpanded could still have had the screen at 4096.

Anyhow, a program that needs a bigger screen of course can reprogram the VIC screen (and character) base register as it wants - there's no requirement other than the default values applied on startup/reset, that the screen "has" to reside at any given position. And that bigger screen can then also use more than 512 nibbles of colour memory.

In hindsight [...] the kernal/editor should had been able to handle variable screen sizes, and there should had been a basic command to resize the screen.

This, and what's wrong with using just 4 POKEs for that purpose?

I'm just saying that that should had been there back in 1980.

*) the video chip can only access internal RAM, therefore it is not possible to move the screen all the way down to $0400 (unless one modifies the mainboard). Rather, it is moved to the lowest possible address usable for both BASIC RAM or video RAM and that is $1000 - consequently, BASIC RAM has to start at $1201.

In hindsight it seems like it would had been better to omit address 5k-8k and have 5k continuous ram from 0.

[Mike]

Well, the 3k expansion could be used with the screen at top (like it actually is) while unexpanded could still have had the screen at 4096.

People already had the trouble to understand why the screen base address makes that single change from 7680 to 4096 with a bigger RAM expansion - and you demand them to grasp that the screen would be at 4096 with no expansion, at 7680 witk +3K, and again at 4096 with the bigger RAM expansions. Are you serious?

In hindsight it seems like it would had been better to omit address 5k-8k and have 5k continuous ram from 0.

This would have rendered the bigger RAM expansions unusable, unless a hypothetical +3K RAM expansion from $1400 to $1FFF was present to fill that gap.

In hindsight the VIC-20 should have been equipped with 8K internal RAM right from the start.

Now this kind of talk is rather pointless. CBM was sitting on a heap of 2114 SRAMs which they wanted to get rid of with the VIC-20. The VIC-20 was supposed to have strictly more than 4K RAM, but not much more. Fitting the VIC-20 with 5K RAM (ten 2114s plus an extra one for the colour RAM) was the sweet spot of cost, and the rest is history.