[Coco] Video band width and accessing video memory

Dave Philipsen dave at davebiz.com
Tue Jun 4 03:57:23 EDT 2019


But in your example below you are assuming that the video subsystem can only access the memory once every CPU clock cycle. If the CPU is running at 1.789 MHz that means the cycle time is 560ns. If we divide that up and give half of it to the CPU and half to the video subsystem then they each get 280ns of time with the memory per CPU clock cycle. Theoretically, if you had two banks of 140ns RAM the video system could access it twice during each CPU clock cycle (reading four 8-bit bytes). If it could do that, then it could actually access more than 119,000 bytes of memory every 1/60th of a second. That’s way more memory than is needed for a 320x200 256-color screen.

Dave

Dave

On Jun 3, 2019, at 11:08 PM, Walter Zambotti <zambotti at iinet.net.au> wrote:

>> But it *is* feasible to do a 160x200 mode in 256 colors. 
> 
>> Dave
> 
> Yes but Mr X of the Hidden 256 Color Mode myth stated:
> 
> It was 320 x res by 200 y res by 256 cols.
> 
> Which means 320bytes_per_line * 200lines = 64000 bytes.
> 
> Halve that if video can access 2 bytes in one cycle equals 32000.
> 
> Divide that figure into 1788000 and you get 55.875.
> 
> So that’s 55 frames per second max you should expect, which is not 60.
> 
> Even if Mr. X was mistaken regarding Y being 200 when recalculated at 192 Y the max frames per second is 58.  And again that is not 60.
> 
> So unless the system can tolerate a vsync of 0.0172ms instead of the expected 0.0167ms you are not going to get a lot of video output.
> 
> To get 60 fps with a 320pixel wide 256 col mode the Y must be restricted to 186 lines and the CoCo doesn't have such a mode.
> 
> So with the memory bandwidth limitations I doubt this hidden mode exists as the designers would have known these timing limitations before they started.
> 
> Walter
> 
> 



More information about the Coco mailing list