[Coco] Video band width and accessing video memory

[Dave Philipsen]

There doesn’t appear to be a design access limitation as you state. The GIME chip is clocked at 28.63636 MHz. That means a single cycle of the GIME clock is about 35ns. That means there are 16 GIME cycles for every CPU cycle. Think of the GIME as a CPU which shares its access to the memory with the 6809. The 6809 runs at 1.789 MHz but the GIME runs 16 times as fast. Therefore, as long as the memory is fast enough, the GIME is not limited as the CPU is. If the RAM had an access time of 35ns then the GIME could read from 8 different addresses during a single CPU clock cycle. If each address yielded 16 bits of data, that’s 16 bytes of data that could be read per CPU clock cycle. That would allow for a 460k graphics screen which means you could even do a 640x200 256-color mode easily.

So there doesn’t seem to be anything missing from the GIME circuitry that would prevent it from accessing the RAM multiple times during a single CPU clock cycle. The limiting factors are the GIME clock of 28.63636 MHz, the 120ns RAM access time, and the maximum speed of the 74LS244 and 74LS374 chips that are used on the data lines.

Dave

> On Jun 4, 2019, at 3:08 AM, Walter Zambotti <zambotti at iinet.net.au> wrote:
> 
> Dave.
> 
> Theoretically yes.
> However the actual design access limitation is 16bits once every cycle.
> So if you are considering an upgrade to the standard cocoIII like CoCoMem then maybe yes.
> But did the original designers have this available to them at that time? 
> I suspect not so why would they bother to include a feature that no one could use reasonably be expected use?
> 
> Like you're thinking though!
> 
> Walter
> 
> -----Original Message-----
> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Dave Philipsen
> Sent: Tuesday, 4 June 2019 3:57 PM
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Subject: Re: [Coco] Video band width and accessing video memory
> 
> 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
>> 
>> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco