Thanks! Shouldn't be too much difference, although the device write cache is disabled by the V2 BIOS and I've not tested that. I gave away my DPv2 to get the drive compatibility tests done, so can't test it unfortunately.
I've ordered an ST1 microdrive though - which may or may not work - but if it does that might give some idea. Might also answer some of the earlier criticism against Compact Flash being solid-state and hence not authentic, for such machines.
After a week of messing about with this... success! I'll post up the files on my wiki tomorrow.
I revisited Pietja's mux design and noticed the stored bytes were sent back through the IDE output buffers, so doing the same the new mux is simplifyed with just a single LD8 latch and a couple of internal buffers. A side effect is also to reduce the CPLD resources to just under 50%. I haven't tried yet, but maybe it will fit on the 9536, or conversly it might make possible the idea raised a couple of posts up of having a dual-channel board with 40-pin and CF driven by seperate CPLD pins maybe.
Anyway with the revised 'high speed' design here are the all import stats. First, P200 with BIOS shadow enabled, but the XT BIOS (no word IO instructions):
In both it passes all the pattern tests OK too. It's a near doubling of the write speed and I think the BIOS can be streamlined for these cards too, with a bit of work (but I'm not sure it's worth the effort of creating a fork in the universal BIOS for that).
This CPLD code will be portable to the DPv2, I just need to change the pinout to match. I'll ask the xtide-universal-bios project lead to release the code too as it's just in a one-off build at the moment.
I'm really struggling with the CPLD code for faster writes; would very much appreciate another pair of eyes on it. Now obviously, I'm very much a novice at this so please don't be afraid to be blunt. I've only just managed to get the damn stuff to compile! Please find attached.
I started with Pietja's DPv2 CPLD code, and changed the mux and the decoder. I want it to work exactly per the 'chuck-mod' for reads, but for writes the BIOS will transfer Low, High (via ports 300h, 301h) instead of high, low as it does today, so the ATA command control lines (for a write, CS0- asserted and CS1- not asserted) are swapped (to the no-op state) for port 300h only; all other ports they remain set.
So, the byte written only makes it as far as the latch for port 300h, but for all other ports (301-30Fh) data is transferred to IDE DL (i.e. lines D0..D7) via the latch, with the note that for ports other than 301h as it is today the byte is also presented to the IDE interface on DH too (D8..D15), although that would be easy to stop. For port 301h the latch gate is shut hence the previously written (low) byte is presented to IDE DL with the current data on the ISA bus running through to IDE DH.
As it is today it doesn't work at all (except for ROM decode), so with the new BIOS or the chuck-mod code the flash card isn't detected. Maybe I should start again with Pietja's working mux :)
Sleepwalker - possibly I've just realised what you meant; i.e. having the card provide both a primary and a secondary IDE interface (like on a motherboard with two physical 40-pin headers), but one of them providing the CF card socket already present? So really a 'secondary' channel supporting two drives via 40-pin.
It might be do-able if seperating IDE /CS0 and /CS1 were enough; the IDE decode logic could be extended to consider a seperate consecutive port range (say, 300-30Fh for primary, and 310-31Fh for the secondary) so the secondary controller could be hooked up to a 40-pin header. Which way around the 'controllers' are could be configured via CPLD code I suppose.
It seems the real limitation of all the boards in this thread though is that fellow enthusiasts don't want to venture into SMT to build them.
Yes, it's possible, but not without issues. To use CF and drive simultaneously, there would need to be PDIAG connection between them, but that's not presented by 80-wire cables at the host end. I think it should work with a 40-wire cable though. Also routing the signals from the CF header to the 40-pin header is tricky, would need the upper bracket hole to be moved for a start, but it is possible.
Really because of this and as 8GB CF cards cost only about £10, I thought it might be better to use both the CF and the DPv2 in a system needing both 40-pin & CF, and in that config no expensive EEPROM would be needed on the DPv2 board as the xt-ide universal BIOS can be configured to run two cards I think (with the switches on them set so the IO port ranges are different). Actually with 32K available my board could accomodate completely seperate BIOS's for both of them anyway.
As promissed here's my schematic that should provide for fast writes with the DPv2 board. The command trigger is changed for port xx0h writes to xx1h, hence allowing the CPU to write low then high bytes, hence opening up the OUTSW instruction on the V20. Otherwise it should work like the chuck-mod schematic.
OK so I've got a circuit design for this, which adds one 74LS245 and a couple of NXOR gates to the existing v2. Will upload a schematic once it's drawn out. It will use 'chuck-mod' BIOS code for reads, but needs new code for writes (obviously) but also needs some changes to IDE register code, since all writes to port 300h must then be 16-bit. No idea if it will work :)
BTW more test results have come in for the DPv2 board. Seems like a possible issue with Western Digital drives of around 1GB, but pretty much everything else seems to work well. There is a v2 beta of the xtide-universal BIOS just released; I'm hoping to get the non-functional drives re-tested with that BIOS soon.
I've been thinking about BIOS and throughput, and revisited the (long) thread on vc-forum on the chuck-mod. Chuck himself has very kindly expanded on the design changes that would be needed to speed up writes via word instructions give 80188 or V20 CPU thus,
If I were to do a CPLD version, the change that would be required would be to take into account that the write signal to the IDE interface needs to occur on the output of the high-order byte, while when reading, the read signal occurs on the input of the low-order byte. Both IN AX,DX and OUT DX,AX transfer the low-order byte first, then the high-order byte.
Is this something we could have a go at with the CPLD code? The next XT-IDE universal BIOS (V2) is being developed actively it seems so maybe there could be scope to include changes for any new logic there, or at least fork that for it anyway.
Hi Pietja, many thanks for talking the time to put in all your test results - complete with links I see! I can't find almost anything about your test rig (Tandon TM 7305) - what is that?
Thanks for the input on that. Interesting that Acetone can attack the plastics!
I decided to adapt my board to 100mm width and get it made by Seeed. But, when I change a drill to anything other than 0.6mm the Seeed 1.1 DRU produces drill size errors. So drill = 15 mils produces DRC drill size errors on layer 20, yet seemingly the same config in DPv2 BRD file passes the check just fine? What am I missing!? EDIT: Turned out I'd put a value in the net classes at some point.
In case anyone is interested, I just assembled a V1B board, which works just fine. The only change I made to it was to tie CSEL (pin 28) to pin 30 (ground) on the underside of the header instead.