[Coco] Fw: CoCo Hardware Questions

[Kevin Diggs]

Alex Evans wrote:
> 
> On Jan 24, 2005, at 12:56 PM, Dino Steeman wrote:
> 
>> Now I have a couple of questions:
>>
>> * There is only an E-line going to the 6809 and not to the VDG. How 
>> does the
>> VDG
>> "know" when to access memory? Does the 'clock'-pin do the trick?
> 
> 
> Actually the SAM accesses memory for the VDG and it knows the state of 
> the E and Q clocks, and generates the clock signal for the VDG as well.
> 
The SAM thingy monitors the A0 line from the VDG address bus (which is 
otherwise unused) to now when to get the next byte. The SAM also knows 
enough about the VDG modes to know when to reset the address back to the 
start. I think that is why you have to program both the VDG and SAM with 
video modes. Does SAM monitor HSync and/or VSync?

The SAM does not access memory for the VDG as it has no data bus (I 
think that is why you have to use all those precious even/odd address 
pairs to set bits in SAM registers). It does generate addresses for the 
VDG at the appropriate time so the VDG can read the data on the bus.

This kind of explains what is going on in a deuce when you put it into 
double speed mode:  the cpu needs to get to memory twice as often so the 
SAM no longer has any cycles to give the VDG. But the VDG is oblivious 
to all this and keeps right on reading data which it thinks is its.
>> * What does the Q-signal do?
> 
> 
> In stead of stepping through one state every cycle like many CPUs, the 
> 6809 breaks a single cycle into four states using the combination of the 
> E and Q clocks to determine which state the CPU is currently in.  This 
> allows the CPU to get more done in a single cycle (it in a way looks at 
> it as four ticks for one cycle), and makes sharing memory with another 
> device like the SAM potentially very straightforward.
> 
>> * As the VDG is reading one byte at a time, and as it must manage to go
>> through
>> the entire videoram, is there a screen image stored anywhere for the
>> video-signal? (I know, complex question, but still...)
> 
> 
> I'm not really sure what you're asking.  If it is a text screen, the 
> data read from the computer's memory is translated using the current row 
> number and the value of the byte read to give a value that is rotated 
> through a barrel shifter to drive the elements that physically convert 
> into your actual video signal,  for a graphics screen the translation is 
> a little more direct.  At the same time it keeps track of a horizontal 
> and vertical counter so that it knows when to go into horizontal and 
> vertical blanking and when to issue horizontal and vertical sync signals.
>