> Please have a look at fig. 12, the memeory-to-memory transfer, at page > 2-221. The MEMW cycle is only about 125 nsec. long, and that is too short. > Same for compressed mode. > 1) As already said in other mail, with 4 MHz the read/write signals are too > short IMHO. But I realy honnestly hope that I am wrong. I assume the worst case on the C64 side would be the 335ns (memory cycle time) memorys, they only need data for about 55ns max (of course it has to come at the right time, I haven't tryed to figure out the memory cycle timing relative to the 8237 - yet) and the minimum write pulse is also 55ns. > 3) And if the above doesn't matter, how are you able to program the 8237 so > that that particular step happens exactly at the right point and not in the > middle of the low half of CLK2? sync on ADDSTB and insert S3s ? > If you mean iochRDY, see remark above. If you mean the RDY-input of the > processor, you won't find this at the expansionport. To access it, you > really have to do some hacking. And as already mentioned, I haven't found a > card yet which needs this slowdown. /DMA asserts RDY (and CAEC) I suspect you could run the 8237 at 4Mhz with out too much trouble (though I haven't examined the matter in detail yet), but would there be any point? even with compressed timing you couldn't get 2 transfers per PHI2 so the most you'll likely get is one transfer per PHI2 which could probably be done using a 2Mhz clock. On the other hand it might be useful to split PHI2 as fine as possible for synchronizing the 8237s cycles with the C64s timing 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 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.