[Coco] Video band width and accessing video memory

[L. Curtis Boyle]

I think I remember mention that some of the hardware scrolling required RAM running at least 142 ns to run fully reliably, and that the 150 ns parts did cause issues at times.


L. Curtis Boyle
curtisboyle at sasktel.net



> On Jun 2, 2019, at 10:39 PM, RETRO Innovations <go4retro at go4retro.com> wrote:
> 
> 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
>