[Coco] CoCo hardware cycle

Fedor Steeman steeman at webspeed.dk
Sat Feb 5 03:58:39 EST 2005


Thanks! I'll see what I can work out on the basis of this. At this stage, I 
am not yet interested in the precise timing, just the sequence of events.

Cheers,
Fedor

----- Original Message ----- 
From: "Robert Gault" <robert.gault at worldnet.att.net>
To: "Fedor Steeman" <fsteeman at dds.nl>; "CoCoList for Color Computer 
Enthusiasts" <coco at maltedmedia.com>
Sent: Friday, February 04, 2005 11:54 PM
Subject: Re: [Coco] CoCo hardware cycle


> Your steps seem just slightly off when compared to Fig 2 on the SAM data 
> sheet which is the Timing Waveforms for MPU Rate =SLOW. I have no 
> equipment for scanning this page and could not do it justice as an ascii 
> diagram. I'll try to make some useful verbal description but don't promise 
> much. I make no attempt to indicate accurate delays or specific timing.
>
> 1) The SAM has an oscillator input running at 14.31818 MHz from a crystal 
> which feeds back via osc out to the crystal producing the master system 
> clock.
> 2) The timing diagram has $10 (16) steps or full square wave cycles of the 
> master clock. These are labled tau 0-$F. All other system square waves 
> trigger at the middle of an oscillator out transition.
> 3) During the second half of tF the E clock goes low, VDG addresses are 
> invalid, the MPU addresses become invalid, and ^WE goes high.
> 4) Just before the end of tF, A0-A15 and R/^W go invalid and VDG ROW goes 
> valid. As we enter t$00, the states are E low, Q low, S0,S1,S2 valid, DA0 
> valid, VDG address ROW valid, ^RAS0 high, ^RAS1 high ^CAS low, and ^WE 
> high.
> 5) About the middle of t0, S0,S1, and S2 go invalid. ^CAS goes high.
> 6) About 1/4 of the way through t1 VClk goes high. The rate of VClk is 4x 
> the master oscillator.
> 7) At the middle of t1, ^RAS0 and ^RAS1 go low.
> 8) At the start of t2, VDG address ROW goes invalid.
> 9) About 3/4 through t2, VDG address COL goes valid.
> 10) At the start of t3, Q goes high, ^CAS goes low.
> 11) At the start of t6, ^RAS0 and ^RAS1 go high.
> 12) About 1/4 through t6, A0-A15 and R/^W become valid.
> 13) At the middle of t6 S0, S1, and S2 become valid.
> 14) At the start of t7, VDG address COL goes invalid, E goes high, and
>     ^WE goes low.
> 15) At the middle of t7, MPU address ROW goes valid.
> 16) At the start of t8, ^CAS goes high.
> 17) At the start of t9, ^RAS0 and ^RAS1 go low.
> 18) At the start of tA, DA0 goes invalid and MPU address goes invalid.
> 19) At the middle of tA, MPU address COL goes valid.
> 20) At the start of tB, Q and ^CAS goe low.
> 21) Just after the start of tC, DA0 goes valid.
> 22) At the start of tE, ^RAS0 and ^RAS1 go high.
> 23) At the start of tF, E goes low, MPU address COL goes invalid, and
>     ^WE goes high.
> The cycles then repeat.
> The VDG and MPU address lines are Z0-Z7. ^RAS1 is used in 4K and 16K 
> modes.
>
> Fedor Steeman wrote:
>
>> Hello all,
>>
>> I posted this message before, but I guess it got swamped by other 
>> messages,
>> so I am posting it again.
>>
>> I am trying to get a reasonably accurate picture of what is going on 
>> inside
>> the CoCo1/2 in terms of hardware processes. I am especially interested in
>> how hardware components like the CPU, SAM, and VDG communicate. Hence, I
>> have written a preliminary use case to describe the sequence of events
>> during a regular CPU cycle on the basis of descriptions in several books 
>> and
>> articles. Now I  am convinced this use case is flawed so I wanted to hear
>> whether there were any hardware buffs that could help me getting it 
>> right.
>>
>> Here it comes, please feel free to edit:
>>
>> Use Case: Normal Hardware Cycle
>> 1. VDG gets byte from memory address accessed by SAM
>> 2. SAM sends a high Q-signal to the CPU
>> 3. CPU program counter register is incremented
>> 4. SAM accesses videoRAM at the address specified by... ?some internal
>> register
>> 5. VDG gets byte at RAM address and sends data on to video signal 
>> generator
>> 6. VDG increments ?some internal register in SAM
>> 7. SAM sends a high E-signal to 6809
>> 8. 6809 accesses RAM at the address specified by the Program Counter
>> register
>> 9. RAM address sends byte to 6809 (6809 reads RAM address byte)
>> 10. SAM sets Q-signal low
>> 11. 6809 acts on byte (executes instruction)
>> 12.SAM sends a low E-signal (to 6809)
>> 13.repeat steps 1...13 until power is cut
>>
>> Thanks in advance!
>>
>> Fedor Steeman
>> 



More information about the Coco mailing list