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 firstname.lastname@example.org.
Archive generated by hypermail 2.1.1.