[Coco] Video band width and accessing video memory

RETRO Innovations go4retro at go4retro.com
Mon Jun 3 00:39:04 EDT 2019


On 6/2/2019 11:18 PM, Walter Zambotti wrote:
> Very interesting!
>
> That’s what I expected.
>
> The video hardware must access 2 bytes per cycle (or on one edge of the cycle).
>
> And the video frequency must always be 1788000 regardless of CPU speed.
>
> And if that is the case then the maximum accessible bytes would be double 29800 or 59600.

I think it's just 29800, as far as I can see, since it's 2 bytes per 
2Mhz cycle, or 1788000/60 bytes = 29800

29800/320 = 93 and change, so I think it's worse than you note.

That said, the mode could potentially still exist, but would not be 
usable without much faster RAM.

The base GIME freq is 28.63636MHz, or 28636360 Hz

The base E (fast) clock looks to be fbase/16 = 1789772.5Hz

The half period of E would be 1/1789772.5/2 = 558nS/2 = 279nS

The base DRAM in the unit were 150nS, at least the ones in my CC3 are

That's not *quite fast enough to quad clock the RAM, but 120nS would 
have been fast enough, and I think 120nS DRAM was available then.

So, if 120nS had been cheap enough, they could have quad clocked, and 
which would have allowed 32 bit (4 bytes, pulling in memory twice during 
the E low half cycle) or maybe even 48 bits (6 bytes, pulling in memory 
twice during the low half cycle and once again in the E high half cycle 
while letting 1 memory pull be for the CPU), which then brings your 
numbers to 59659 (still not enough) or 89488 bytes (enough, I think)

89488/320 = 279.65 or 280, which is enough.

It is possible, then, the circuitry could be in the unit, but the DRAM 
would have to be swapped out for faster memory

It's a *LOT* of "ifs", though.  I'm betting it was working in the lab, 
and then got cost reduced out of the final ASICs.

Jim




More information about the Coco mailing list