Why is the 40/80 col. display manager slowing the VIC?

[eslapion]

Boray recently posted this bar graph with different speed performance comparisons:


I was truly dissapointed to notice how much slower the VIC-20 is when using the 40 or 80 col. mode of the data20/Protecto80 display manager.

Can anybody care to explain why there is so much slowing down? Also, why is it that the 80 columns mode slows down the machine even further?

I mean, the VIC-20 is not like the Amiga where more access to the video ram will slow down the CPU so I don't get it.

[groepaz]

i don't know that "40 columns manager" - but i'd assume that it creates a 40 columns display in software, which is quite a bit slower than normal text screen (and the test also takes PRINT speed into account, even including scrolling the screen - which will have a huge impact on speed)

[Boray]

i don't know that "40 columns manager" - but i'd assume that it creates a 40 columns display in software, which is quite a bit slower than normal text screen

No it's a hardware add-on for real 40 and 80 column display. I don't know why it's slowing it down though. Maybe the graphics chip used is slow? It's only the text output tests that is slower than a normal Vic. The rest of the tests got the same score as a normal NTSC Vic.

[groepaz]

if its hardware, then the cause is likely that the chip does not have its videomemory memory mapped, but its accessed via an i/o port - which is also kinda slow.

[sjgray]

I have one of those, but I've never tested it speed-wise. The unit uses a 6545 or compatible video chip, which is the same as in the PET. If I recall, the video memory IS mapped into regular memory. That said, it's probably a simple case of more characters to scroll = longer time. You can see the difference between 40 column and 80 column using the adapter. It's also possible the unit's firmware scrolling routine is not optimized.

Steve

[groepaz]

interesting.... in any case it shows that this test program isnt really suited for measuring the speed of the basic interpreter if the screen i/o does have such a huge impact

[Boray]

interesting.... in any case it shows that this test program isnt really suited for measuring the speed of the basic interpreter if the screen i/o does have such a huge impact

If the test was to just test the basic interpreter, it would have to be done on the same computer running different basic versions. This test is of the basic and computer as a whole, and screen output speed is an important factor for the feel of a computer, AND it's just one of 6 tests. You can run the program and compare every subtest if you like. The 80 col mode slows down the output by a factor of 5! so of course it influences the whole score a lot even if it's just one of 6 tests. Here is the program:
http://www.boray.se/commodore/qbench.html

[groepaz]

This test is of the basic and computer as a whole, and screen output speed is an important factor for the feel of a computer

maybe - but then again the graph says "basic commands per second", which is questionable at least. removing i/o bound operations from these measurements would give better numbers for comparison, imho.

[eslapion]

i don't know that "40 columns manager" - but i'd assume that it creates a 40 columns display in software

Wrong

if its hardware, then the cause is likely that the chip does not have its videomemory memory mapped, but its accessed via an i/o port - which is also kinda slow

Wrong again

If either was true then I wouldn't even have asked the question...

This test is of the basic and computer as a whole, and screen output speed is an important factor for the feel of a computer, AND it's just one of 6 tests. You can run the program and compare every subtest if you like. The 80 col mode slows down the output by a factor of 5! so of course it influences the whole score a lot even if it's just one of 6 tests.

There is the real answer to my question.

Everytime the screen scrolls, there is about 4 times more chracters to scroll.

This brings a more intricate question:
Since the CPU runs slightly slower on an NTSC C64 than on the VIC-20, why would the VIC-20 with a display manager in 40 col. mode turn out to be slower than a C64 which also has to shuffle around 40 columns of 25 characters? (assuming both machines are NTSC)

[Boray]

maybe - but then again the graph says "basic commands per second", which is questionable at least. removing i/o bound operations from these measurements would give better numbers for comparison, imho.

But PRINT IS a basic command too. And one used quite frequently I would say.

[sjgray]

This brings a more intricate question:
Since the CPU runs slightly slower on an NTSC C64 than on the VIC-20, why would the VIC-20 with a display manager in 40 col. mode turn out to be slower than a C64 which also has to shuffle around 40 columns of 25 characters? (assuming both machines are NTSC)

Don't forget, the C64 also has to scroll colour memory. So a C64 has to move 2000 bytes (1000 screen, 1000 colour), the VIC has to move 1012 bytes (506 screen). With display manager in 40 column mono it's 1000 bytes, and in 80 column it's 2000 bytes. You would expect the VIC with display manager in 80 column mode to be about the same speed as the C64, but it's only 1/2 the speed. This points to the firmware being the main culprit.

Steve

[Mike]

i don't know that "40 columns manager" - but i'd assume that it creates a 40 columns display in software, which is quite a bit slower than normal text screen (and the test also takes PRINT speed into account, even including scrolling the screen - which will have a huge impact on speed)

MG BROWSE (download here, enter 'INTERVIEW' at the 'FILE?' prompt) is an example of such a 40 column display done entirely in software. Even though it has to move ~4K each time a complete screen has to be scrolled up or down, it manages ~10 lines/second scroll speed - and there's still some BASIC involved to do the housekeeping.

It would be interesting to know how an equivalent application would compare in speed on the 40/80-Display Manager. After all, a benchmark first of all measures only one kind of speed - its own.

[groepaz]

But PRINT IS a basic command too. And one used quite frequently I would say.

yes, but typically programs don't scroll the screen all the time (using the print command) - so the speed of that operation isn't terribly important - it should have much less impact on the score of a "generic" benchmark.

After all, a benchmark first of all measures only one kind of speed - its own.

hehe yep, that's why i don't like benchmarks that measure anything besides the equivalent of instruction timings.

that said, a basic version of the famous "byte bench" (google for source) would be somewhat interesting

[Boray]

yes, but typically programs don't scroll the screen all the time (using the print command) - so the speed of that operation isn't terribly important - it should have much less impact on the score of a "generic" benchmark.

I guess you never have tried a basic game. Moving portions of, or the whole screen around, is very central to most games. As we all probably know - The Vic-20 with it's small screen has a big advantage here for making actually playable basic games.

That said, the string test is about as much slower on the Plus/4 or C128 (compared to the Vic-20) as the text out test is, so... Maybe the balance isn't as skewed as you think. If you think it's a bad test, then just go and make your own.

[Boray]

Something else that is pretty interesting - comparing the C64 to the C128:

Code: Select all

comparison base 4
pal c128 =1.00 (more=you are faster)

e. loop:  1.43396226
math:     1.17307692
arrays:   1.39215686
strings:  1.71698113
text out: 1.30952381
poke&peek 1.27419355
all:      1.38591549

you are 1.38591549 times faster than a p
al c128.

it's basic commands per second value is
296 and yours is 410.

I find it a bit strange that the C128 manages to slow down even the text output that much.