I'm Designing a board that provides up to 30V OC outputs from 3v3 GPIO lines. The board will be attached directly to the processor board GPIO header (for example raspberry/banana pi etc).
My question is whether there is any special consideration required for the ground plane, currently it's a single solid copper pour with a 0.1uF bypass capacitor fitted near the Darlington common pin.
In the end the latching of the high byte from the media based on ISA /IOR proved too troublesome (although the DP logic seems to get away with it, somehow!) so my board makes use of the 8-bit transfer mode in all compact flash cards. This simplifies a lot of the logic so enabling new features too, like reduced wait-state operation in newer machines (thanks to Alan for raising that somewhere in the depths of this thread), PC/XT slot-8 compatibility, and an unconventional DMA mode that I think makes this is the fastest EVER disk controller for the IBM PC and PC/XT!
So I just wanting to publicly thank Ian, Pietja and everyone else involved in the DP version, without which (and whom) I couldn't have done any of it - cheers :)
I'm trying to make a small (50mm x 50mm) board taking a 12V DC battery input and providing 3.3V @ 1.3A and 5V at 0.7A.
Initial plan was a pair of LM1086IS fixed output regulators - cheap and simple, but the power dissipation will be a problem (small sealed plastic box) and anyway it will waste battery power.
So I need an alternative approach; is the answer a switching regulator IC with external inductor and a MOSFET? Something like LTC1147-3.3 for example?
Yes it will work in any machine with an ISA slot. Part of my test rig is a 'dispensible' P200, just note that throughput will be a lot lower than the on-board controller because of the 8-bit transfers (which also means 8-bit transfers of the BIOS code too). Performance seems to max out at about 800KB/s.
For anyone interested, I put up more detail on my CPLD workings with schematics etc, here.
CPLD code is a port of the code proved on my compact-flash board. Hopefully it will work on the DPv2 :)
BIOS code is very much alpha code, a custom build from the universal BIOS v2 (beta). Two images are included, for port-mapped only and for memory-mapped. Both assume the ROM is at D000h, the IDE IO port is at 300h, and the memory-mapped BIOS also needs a 4KB window available at D800h.
If Pietja is still following this or anyone else with a working board, please do test (I let my board go in the interest of drive compatibility testing).
After a bit of effort to undestand ISA bus timing charts, turns out that we can't tell whether an IO will be a read or a write in the address setup phase, since /IOW or /IOR aren't supposed to be asserted at that point. So inverting the IDE command lines (/CS0 and /CS1) based on /IOW wasn't a good idea. I guess the SanDisk card was following the specs more closely, or put another way it's a mystery why the other card worked at all.
But fortunately the cards have always tested A4 to be low, so I could use A4 for writes, i.e. reads via port 300h/301h, and writes via ports 310h/311h, with a simple mod to the BIOS, and use A4 status to invert the IDE command lines (so the write trigger is on the high byte written). And that seems to have done the trick, both CF cards now work in both machines.
The BIOS maintainers also had a good idea to return a constant from a port not used by the IDE interface, so I've included that too.
Will upload new CPLD code with all of this for the DPv2 soon.
Hi, thanks. I don't have a logic analyser but I do have an ordinary o-scope. Just not too sure what to look at, and this board being all SMT there aren't many easy places to attach it unfortunately.
At first I thought it might be some 'decay' issue with the PC/XT being so slow, but that the slower code works is very confusing. According to the CPLD timing reports the IDE control lines /CS0 and /CS1 have slightly more delay on them than others (22ns vs 15 or 11ns, depending) but to my mind that seems to be (by chance) the way we'd want it anyway.
Maybe I'll try porting Pietja's Chuck-mod DPv2 code to the CF board next, and see what that does.
- with a PQI 1GB CF card, it works in both P200 and PC/XT. Passes very extended pattern tests, everything seems fine. - with SanDisk SDCFH-004G (4GB '30MB/s'), it works perfectly in the P200. However in the PC/XT it won't play; it's not detected properly (listed as "isk SDCFH-004G", i.e. missing SanD) and won't boot, can't create paritions tables etc
Reverting to the standard (Pietja's) code, it works just fine.
I tried re-generating the code with a slow slew-rate design goal but it made no difference. I read that some later CF cards and microdrives default to PIO mode 2, and the XTIDE BIOS maintainer very kindly added some code to attempt to set to mode 1, again made no difference.
So I guess this is some timing issue I've introduced. But I'm struggling to think what it could be.
First attempt at DPv2 CPLD code attached, and the pre-beta BIOS to make it work (select 'fast xt-ide' as the controller type in the BIOS configuration utility). As I don't have a board at the moment, I've not tested it.
EDIT - also, the mux schematic, for anyone interested: [attachment=0]
