DMA Timing Issue #5
Comments
|
Hi A-Small-Mice, It has been a while since I worked on this last. When I worked on my prototype, which is clocked at 8MHz, I also spent time debugging the system. The way I went about it is very similar to what you have done, by swapping logic types in certain key locations, the timing of the system is shifted. Some locations are much more critical than others, for example the 74HC74 D-latches and 74HC08 AND gates in the DMA arbitration circuits are particularly sensitive. Also changing the 74LS138 decoder logic types will shift the chip selects which may help shifting the timing in the right spot. After you have solved the timing issues now, you may in fact find that you can swap back other IC locations to the original values and the system will continue to work fine. It's quite possible that only one or two IC locations are the most critical changes which made the most difference. The DMA arbitration circuits are an influence, and also the chip select decoding logic is another side. If these are too fast it also may shorten the window of the other DMA logic where this still is able to work. Indeed it is helpful to have some 74Fxx logic ICs on hand for the areas which need to be the fastest. The photo you posted looks to me like the IOCHRDY processing may have been the issue judging from the character errors. I didn't have this problem myself on the XT, but on my AT design this was the initial issue causing VGA screen memory updates to get missed in many locations. I shifted the ready enable timing to resolve it in the AT. Similar things could be going on in the XT. The problem is, when you use these TTL ICs, some may have significant different timing from the ones I used. Even if the type indication is identical, the timing will be different because the different manufacturers used different chip fabrication methods. These also continued to develop over the years and a newer part may have different timing, even from the same brand. Also the DMA controller timing will vary in my experience, which will in turn influence the DMA arbitration timing because the controller has a different response time. On the other hand, having so many logic areas does at least provide more ways to shift the timing where you want with different logic families. So anyone constructing this design will do well to keep a stock of different logic types especially for the 74HC08, 74HC74, and the data transceivers. The address latches are much less sensitive parts in my experience. Another example is the XT-IDE design which may be somewhat relevant for this project. There, swapping logic types for the decoders and delay circuits makes all the difference between a working and not working IDE interface. Great job, and thank you for sharing the list and information, no doubt this may help others. After overcoming your initial struggles, your system will now surely feel even more precious to you. :) I have similar sentiments after a long period of development. I had a lot of struggles with bad IC sockets from Chinese sellers. One was so loose that some of the keystrokes didn't even arrive on the bus. One should not buy cheap IC sockets! ;) Kind regards, Rodney |
When building my ATX Turbo XT, I faced significant challenges in adjusting the DMA timing. The motherboard built according to the BoM you provided works well at 4.77 MHz, but at 8 MHz, issues arise, such as the floppy disk not reading correctly or digitized sound not playing properly. I received help from CHARLIE IM, known for assembling a Soviet Poisk-2 with American parts, and managed to resolve the DMA timing issue by making adjustments according to the following table. I hope this information will be helpful to others as well.
The text was updated successfully, but these errors were encountered: