[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