Hi everyone,


Agreed, I really like the idea of dropping the 8255 off the SBC V2 (connecting IDE directly to the bus as Sergeys suggestion)

====Yes. This was the approach on the Mark IV, and the idea worked.

>>> Address & data lines look okay; as do /MREQ, /IORQ, /RD, & /WR. /M1 does not tri-state; I hope the CPU keeps it high.

Had assumed the SBC V2 would be good to go. Would not know how implement tri-state on /M1 as

====With CPU & DMA on the same board, you don't need to worry about the chip signals. DMA knows to keep hands off of /M1. BTW: S-100 get the board priority done the right way. Each board is jumpered for its priority, and board may be plugged in anywhere on the backplane.




>>> None of the existing backplanes support DMA or Z80 interrupt priority arbitration out of the box.

I had installed all links on the boards I had constructed not really understanding the full use. Fortunately easy to install for those haven't. Now I'm wondering if they should only we installed in locations where the ecb-board is not using /IEI-/IEO & /BAI-/BA

====Yes they should.



>>> Also, the DMA board must be placed on the correct side of the CPU board, and adjacent to it, to get the priority chains to work.

I wasn't aware of this requirement. I think some of Wolgangs design have /IEI-/IEO & /BAI-/BA linked on the ecb-board. It seems to me that that is the correct way to go to make them position independant and removes the need for the links on the backplane?

>>> The CPU board will have to be modified to ground /IEO & /BAO to initiate the priority chains.

==== Don't forget, /BAO goes out from the CPU board; in on the next backplane slot on /BAI; hence the need for the soldered jumper on the backplane. [BAO and BAI should actually be on Axx & Cyy, respectively, where xx == yy. Similarly for IEO & IEI. However, the two are backwards on the Kontron backplane. IEO is on pin Caa and IEI on Abb (aa == bb). Note: BAI->BAO goes from row A->C; IEI->IE0 goes from row C->A. The backplane wiring would be easier if these signals came into a board from one side, and both left from the other side, and each change on the SAME NUMBERED PIN; i.e., Axx->Cxx and Ayy->Cyy respectively. Kontron really missed the mark on the chaining scheme. They require soldered jumpers, or more than a 2 layer backplane.



Not really understanding this yet ... will get the datasheet out and read up more. Thank you for your insightful comments.

====Wolfgang published the schematics of a couple of Kontron boards. Reading the schematic would tell you immediately how this is done.

--John

I would suspect the reason that some [many?] CF cards work with non-compliant ATA interfaces is due to them not forcing the specification timings. I've definitely seen CF cards that will respond properly to PIO mode 4 timing even though they're configured for the much slower PIO mode 0. This may also explain why only certain brands of CF cards may work on a particular interface and also why physical disks might not. I've experienced hard drives that were picky about being properly configured with timing that matched the selected mode.

Thank you for the explanation about CF card timing. SD cards have some slow timing requirements on start-up, although they are of a different nature.

//               cycle   a_setup  rd/wr(reg)  rd/wr  wr_hold
//       PIO 0 :  600      70      290         165     30
//       PIO 1 :  383      50      290         125     20
//       PIO 2 :  330      30      290         100     15
//       PIO 3 :  180      30             80           10
//       PIO 4 :  120      25             70           10
//    CF PIO 5 :  100      15             65            5
//    CF PIO 6 :   80      10             55            5

//                    cycle   r_setup  rd/wr  wr_hold  rd_neg  wr_neg
//       DMA 0 :       480      150     215      20      50      215
//       DMA 1 :       150       60      80      15      50       50
//       DMA 2 :       120       50      70      10      25       25
//    CF DMA 3 :       100       50      65       5      25       25
//    CF DMA 4 :        80       45      55       5      20       20

@wsm: I don't think its necessarily modes and timings that are the problem. I see the same problems with the Memotech MTX CFX-II and with the backplane based CF cards in RC2014. In both cases getting the CF adapter closer to the CPU helps which to me suggests it also involves signal quality. Likewise on some buffered adapters people have found that 74LS or 74ALS works and 74HC/HCT does not for certain cards.

...
I also agree that many of the ATA designs I've seen don't pay attention to the ATA specifications about timing and would be prone to failure. Interfaces like GIDE and one recently promoted on VCF simply rely on having a slow processor that doesn't exceed the PIO mode 0 timing of 290ns rd/wr pulses and 600ns cycle times ... unrealistic on something like a 20MHz Z80 without external wait logic. Note that the ATA specification calls for all devices to be initialized in PIO mode 0 before possibly being configured for higher rates, including DMA.

The only reliable way I've found to efficiently implement ATA on fast processors is to use a CPLD or FPGA to control the timing. In it's simplest form it can assert a processor wait signal for register access and PIO modes plus take over the bus for the entire duration of a DMA block. DMA mode is most efficient in an FPGA using a dual-ported buffer between the two different clock domains and Ultra DMA adds a LOT of extra complexity.

I would suspect the reason that some [many?] CF cards work with non-compliant ATA interfaces is due to them not forcing the specification timings. I've definitely seen CF cards that will respond properly to PIO mode 4 timing even though they're configured for the much slower PIO mode 0. This may also explain why only certain brands of CF cards may work on a particular interface and also why physical disks might not. I've experienced hard drives that were picky about being properly configured with timing that matched the selected mode.

As someone that's been tinkering with GIDE in the RC2014 context recently (waiting for Plasmo to sell me one of his PC90 boards) I'd be super interested in reading more about your experiences here. I went looking over at VCF to see if I could find the thread(s) you allude to here without any success. Any pointers (in general) would be gratefully appreciated...