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

[Kweepa]

The 6845 and the 6502 have to share access to the memory. Depending on the architecture, bus contention solutions could definitely slow down any output.

[eslapion]

The 6845 and the 6502 have to share access to the memory. Depending on the architecture, bus contention solutions could definitely slow down any output.

If you have your own Data20 display manager, you may notice when the CPU accesses the display ram often, the display becomes temporarily garbled.

I tested this by converting the Compute's Gazette maze generator to work with the display manager. Not only does it generate mazes that are considerably more complex than the original version designed for the 22x23 standard VIC's display but it also draws pretty much the same number of tiles per given unit of time as on a standard unexpanded VIC. That's why I found it quite strange that some basic benchmark would result in a slower speed with the display manager vs without.

While the maze is being drawn, there are garbled characters appearing randomly on the screen. This, I assume is caused by contentions between the6502 and 6845 trying to access the same ram.

Ergo 1: the CPU has priority over the video chip for display RAM access.
Ergo 2:At the cost of having a bit of garbage in the display that only lasts a few millisecs, there is no slow down to the CPU when accessing the display ram. In any case, the VIC-20 itself is not equipped with the necessary communication lines that would allow it to wait for slower or buzy ram to become available.

So: Answer to question 1: "Why is the display manager slower when running Boray's basic benchmark?" - > Mostly because the display manager makes the VIC-20's CPU scroll a greater number of columns when displaying.

Answer to question 2: "Why is the VIC-20 with display manager slower than a C64 which has to display the same number of columns?" - > Apparently because the display routines built into the display manager's firmware are not as efficient as those programmed into the 64's kernal.

[groepaz]

One of the characteristics of high functioning autism is to be unable to understand many obvious jokes or expressions which were not previously explained so I take it you feel it is ok for you or anyone else to belittle autistic people...

whatever. one of the characteristics of being me is being immune to the assburger excuse. and yes i know how autistic people "tick" (pun intended) ever since i have worked here (sorry, german only)

Not only does it generate mazes that are considerably more complex than the original version designed for the 22x23 standard VIC's display but it also draws pretty much the same number of tiles per given unit of time as on a standard unexpanded VIC. That's why I found it quite strange that some basic benchmark would result in a slower speed with the display manager vs without.

the maze generator only spends a fraction of its running time in the output code, which makes the time spent in PRINT negligible. that benchmark on the other hand spends (in the print test) almost all time in the scrolling code, which results in those huge differences. hence unless your program also scrolls the screen the same way, comparing with that benchmark is pointless. it can be used to compare scrolling speed of different output devices - no more no less

[eslapion]

One of the characteristics of high functioning autism is to be unable to understand many obvious jokes or expressions which were not previously explained so I take it you feel it is ok for you or anyone else to belittle autistic people...

whatever. one of the characteristics of being me is being immune to the assburger excuse. and yes i know how autistic people "tick" (pun intended) ever since i have worked here (sorry, german only)

Yes Adolf, I understand Adolf... I am genetically inferior, I am unworthy. Send me to the gas chamber right now. My handicap is invisible and therefore it does not exist, I invented it.

the maze generator only spends a fraction of its running time in the output code, which makes the time spent in PRINT negligible. that benchmark on the other hand spends (in the print test) almost all time in the scrolling code, which results in those huge differences. hence unless your program also scrolls the screen the same way, comparing with that benchmark is pointless. it can be used to compare scrolling speed of different output devices - no more no less

The maze generator uses POKEs to draw the maze, not print. It draws at the same rate wether you have a display manager or not.

Therefore your comment is pointless.

You assume a lot and actually say very little.

[orion70]

Indipendently from who's right or wrong here, I think you exceeded a limit. This discussion and every other one with similar fights will be closed.