First off let me say I wasn't considering the problem of getting
the 8237 to work with the C64 in terms of interfacing a 16 bit
ISA card. I assume you'd have to multiplex the data bus for that,
I leave those details to you.
> > synchronizing the 8237s cycles with the C64s timing
>
> The problem is that a synchronized 4 MHz signal does not mean that the
> produced read- and write-cycli are sunchronized as well. So I'll use two
> 573's to create a temporary buffer in the databus between the C64 and
> ISA-bus. Although actually not needed then, it worked fine in my first
> design.
The 8237's /WRITE is referenced to the rising edge of it's clock
during S2 or S3. On the C64 side the important thing is that
/WE be low during the falling edge of /CAS. If things can be kept
synchronized so that the rising edge of the 8237's clock during the
relevant state (S2 or S3 depending on the mode) coincides with
the PHI2 edges, then the timing ought to work out.
from the 6567 data sheet
Trhl, RASlo from the clock edge 155ns Min
Trcd, CASlo from RASlo 25ns Min
82S100 propagation delay 35ns typ
giving something like 215ns Min for /CASRAM from the C64's
clock edge
for the 8237a
tDCL /WRITE low from the clock rising edge is 190ns Max
the RAM want 20ns setup so 215 - (190 + 20) 5ns to spare, worst case
(unless the 82S100 is really fast) however that doesn't include
any scewing due to buffering or gating.
So it would probably work, but maybe not.
For data, I think you're right, you'd have to provide your own
data latch for writes.
For reads, no problem, I think, just assume a cycle is a read unless
/WRITE is asserted
> > Also, perhaps you could manage a memory to memory transfer at something
> > like 1.5 PHI2 cycles per transfer ie 3 cycles of PHI2 to move a byte
>
> I'm afraid that M2M transfer will stick at one byte for every two cycles.
> Unless we use two 8237's. I'm still playing with this idea because of the
> speed we gain but also the fact that I haven't worked out the scheme for
> telling the 8237 what byte goes/comes to/from to which part of the circuit
> during this type of the transfer. I'll explain:
>
for memory to memory I'm visualizing something like this:
for the first half of PHI2, the CPU's time, the bus is tristated, data,
addresses
and /WRITE to the C64 are tristated, UMAX is asserted to suppress RAM
accesses
first quarter S11
second quarter S12
second half of PHI2, VIC half of the cycle
third quarter S13
fourth quarter S13 (wait state inserted)
second PHI2 cycle, first half, CPU time, now we do our RAM access
fifth quarter S13 (another wait state) data, addresses and /WRITE are
applied
(untristated)
sixth quarter S14
now same thing going the other way
second half, second PHI2 cycle, VIC time, data, addresses and /WRITE to
the C64,
tristated
seventh quarter S21
eigth S22
third PHI2, first half, CPU time, stuff still tristated, UMAX asserted
ninth S23 \
tenth S23 (inserted) \
\ in here some where you do your
third PHI2 second half, VIC time / external access
eleventh S23 (inserted) /
twelfth S24 /
now you're back where you started.
of course that doesn't say anything about how you keep synchronized
or stay out of the VIC's way during bad lines.
(haven't thought that far)
and you might want to release UMAX during the VIC's half of the cycle.
> At this moment I don't know what to make of it. What could help is the
> missing page 14 of IBM's original schematic of the AT. Can anybody help me
> in this?
>
If you're talking about what I think you're talking about, I may have it
here
some where, I'll see if I can find it.
But don't hold your breath, if I can find it at all, it'll take some
digging.
bogax
-
This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tml.hut.fi.
Archive generated by hypermail 2.1.1.