Xt-cf-lite corruption problems

[roddersuk]

I decided to add hard disk capability to my Amstrad PPC640 so I designed an ISA expansion board very similar to the one described at www.einide.net and built an xt-cf-lite v4.1 board with r632 of XUB. Trouble is, I can't seem to get it working. i've checked my handiwork and even made duplicates of the boards but the outcome is the same. I have managed to update the EEPROM using the xt-cf-lite so it gives me some confidence that it is mostly working.
After much messing about with different CF cards (Lemwei, Transcend, SanDisk and even an SD to CF adapter) the furthest I've got is a successful install of MSDOS 5.0 but a CHKDSK reports many errors, and it wont boot. Most of the time I don't get that far, generally speaking FDISK says there are no partitions defined, even after just creating one and rebooting. FDISK /MBR doesn't fix it. Sometimes it won't even see the drive.
Recently I've been using TESTMBR to check out what is going on and i've seen some curious results. If I write all zeros, FFs, 55s or AAs to the MBR they are verified correctly, but if I write a rising sequence or random values I get many validation errors and i get different results each time it tries to read it back.
As a final test I wrote the MBR using FDISK /MBR on the PPC then read the CF card on my linux box and printed out a hex dump of the first sector. I then used TESTMBR to read it on the PPC and compared the results. The PPC seemed to be reading back mostly correct but there is the occasional glitch where two bytes are skipped and the previous byte is repeated. This looks very much like a timing issue, could it be down to using cheap Chinese logic chips? I've just used basic 74LSxxx ics, would it be worth trying 74HCxxx ?
I'd be very grateful for any insight into what could be going on and what to try.

 

[kevju]

his looks very much like a timing issue, could it be down to using cheap Chinese logic chips? I've just used basic 74LSxxx ics, would it be worth trying 74HCxxx ?

Do you have an oscilloscope or multimeter that you can use to check the 5V power rail? I have a Monotech XT-IDE Deluxe card that behaves the same as yours when used with lower quality power supplies, but works great with a proper supply. FWIW it is assembled from a mix of HC and HCT parts. The HC parts have much less noise margin than HCT or LS. If your 74LS are sourced from China, then there is a good chance that they are remarked 74HC parts.

 

[Plasmo]

This is a classic case of signal integrity or lack of. You need a slower, earlier CF disk such as Cisco 64MB. Transcend is too fast and generates way too much ground bounce. Some earlier, smaller capacity models of SanDisk worked better than later, bigger disks. If you know which signal is CF read strobe, you can hang a scope probe there and observe the problem either go away or significantly reduced because of the scope probe loading. A 100pF capacitor from CF read strobe to ground nearby can do wonders. The corruption is data pattern specific, as you’ve already found out. The short explanation is a fast CF disk driving 16 data lines opposite of the previous 16-bit data, it created a tremendous ground spike or VCC rail collapse sufficient to glitch the CF control lines. The proof of pudding test is successful copy-with-verify operations.
Bill

 

[roddersuk]

Do you have an oscilloscope or multimeter that you can use to check the 5V power rail?

Yes, that's worth checking. Power is coming from the expansion port on the PPC640 so may be a bit flaky.

Some earlier, smaller capacity models of SanDisk worked better than later, bigger disks

I'm currently trying a SanDisk 512MB card but still hitting trouble.

A 100pF capacitor from CF read strobe to ground nearby can do wonders.

That sound like something worth trying, there is certainly nothing on the board.

 

[Eudimorphodon]

I hadn't heard of "TESTMBR" before, but it looks useful. That said, another tool I would recommend is DISKTEST from lo-tech:

DOS Disk Tester - Lo-tech Wiki

www.lo-tech.co.uk

Both the "mediatest" and "signaltest" switches might be useful for this case.

I had some similar issues with corruption with my homemade CF-XT cards for my Tandy 1000 EX and HX (another system with a proprietary but mostly ISA-like bus) and "disktest mediatest" turned out to be really useful in narrowing down the problem to card compatibility. The TL;DR there is only about a third of the CF cards I tried would reliably pass the "mediatest", even if they would get far enough to format and boot.

My usual recommendation at this point is to try an SD adapter, because so far I have had 100% perfect luck with them; I actually ended up building the final version of my cards so instead of desktop 40 pin IDE or CF card slots they have laptop (2mm pitch) 44 pin disk headers so I can direct-plug the laptop form-factor PATA->SD cards into them... but you say you already tried a CF to SD adapter. That's... not great, and makes me think this might not be (completely) card compatibility. The PATA->SD adapters use the same chipset as the CF-SD adapters.

This looks very much like a timing issue, could it be down to using cheap Chinese logic chips? I've just used basic 74LSxxx ics, would it be worth trying 74HCxxx ?

The general rule is you can drive (LS)TTL from CMOS without issues other than fan-out, fanout being a little limited because of the low current of CMOS, while going the other way might need pull-ups because the voltage, particularly on the high side, might be too low from TTL. (Here's a helpful old PDF with hints.) So...

Standard ISA specifies 74LS signal levels so if the PPC640's bus circuitry is in line with that then 74LS would be an OK choice. If this were ISA then I would *not* recommend going to HC because if the voltage levels *are* LS compatible then the "swing", particularly on the high side, might not be enough to reliably trigger them. Where this might get iffy, though, is the PPC640 is a portable machine, right? It probably *is* using CMOS on the motherboard because CMOS is a lot less power hungry than LS (in terms of amps, not voltage), so the question then becomes whether the circuits driving the expansion bus are HC or HCT. HCT (or related flavors like ACT) is what I see on most second-half-of-the-80's PC motherboards (like my Tandy 1000s) because its input thresholds are compatible with LS, and therefore it *should* be fine interfacing with an LS populated card.... But *if* the PPC640 is using straight CMOS on the motherboard then you should probably switch to either HCT or straight HC.

HCT drives close enough to the rails to drive HC fine, unlike LS, which makes it a pretty safe choice in cases where you're not sure what you're dealing with. So... maybe swapping the LS for HCT would be a reasonable "shotgun" approach for a first step?

I decided to add hard disk capability to my Amstrad PPC640 so I designed an ISA expansion board very similar to the one described at www.einide.net and built an xt-cf-lite v4.1 board with r632 of XUB.

That "einide.net" link seems to be dead, did you mean this?. Looking at the schematics for that seems to confirm that the expansion bus is HC, because it uses 74HC244s to buffer the output signals and applies pull-ups to the data lines. (One question I have about this: why does it only buffer the bottom 8 address lines? *shrug*) This would probably imply you might be better off switching processes; the pull-ups are going to add a little bit of propogation delay; this shouldn't be a big deal at the speeds an XT goes, but if you're building everything anyway you might as well optimize it.

That said, per @Plasmo's comment, I wonder how "clean" this whole mess is electrically. Do you have bypass capacitors on the VCC lines for all the ICs? I ask because I've seen a lot of knockoff XTIDE/XTCF cards where people just didn't include them. There is another thing I'm going to chuck out there: Is this the board you made? I'm generally a big fan of skiselev's work, but there is one thing I am *not* a fan of with this design: IDE has a function to detect if a drive isn't present by having a pull-down on pin D7; this works because 74LS busses normally float high. The thing is, on a full IDE port that D7 where the pull-up is should be behind a 74x245 buffer that's only enabled (and thus applying the pull-down) when the card is actually selected. This design omits the buffer, which means that pull-down on D7 is always there. Always. It shouldn't be "harmful" in *most* cases, but in this one, well, that pull-down might actually be fighting with the pull up to deal with the TTL->CMOS transition, so it might be contributing to signal issues? If your card has it installed I would recommend removing it, just for laughs.

(Edit: FWIW, the prototype of my Tandy 1000 card was based on this lo-tech design that has the data buffer. The final version replaced all the decoding with GALs shared with other functions, but I retained the buffer.)

 

[roddersuk]

I hadn't heard of "TESTMBR" before, but it looks useful. That

Here's a link to TESTMBR. It's a simple tool but quite useful.

minuszerodegrees.net

 

[max25]

I decided to add hard disk capability to my Amstrad PPC640 so I designed an ISA expansion board very similar to the one described at https://www.jewelerstoolsmall.com/ and built an xt-cf-lite v4.1 board with r632 of XUB. Trouble is, I can't seem to get it working. i've checked my handiwork and even made duplicates of the boards but the outcome is the same. I have managed to update the EEPROM using the xt-cf-lite so it gives me some confidence that it is mostly working.
After much messing about with different CF cards (Lemwei, Transcend, SanDisk and even an SD to CF adapter) the furthest I've got is a successful install of MSDOS 5.0 but a CHKDSK reports many errors, and it wont boot. Most of the time I don't get that far, generally speaking FDISK says there are no partitions defined, even after just creating one and rebooting. FDISK /MBR doesn't fix it. Sometimes it won't even see the drive.
Recently I've been using TESTMBR to check out what is going on and i've seen some curious results. If I write all zeros, FFs, 55s or AAs to the MBR they are verified correctly, but if I write a rising sequence or random values I get many validation errors and i get different results each time it tries to read it back.
As a final test I wrote the MBR using FDISK /MBR on the PPC then read the CF card on my linux box and printed out a hex dump of the first sector. I then used TESTMBR to read it on the PPC and compared the results. The PPC seemed to be reading back mostly correct but there is the occasional glitch where two bytes are skipped and the previous byte is repeated. This looks very much like a timing issue, could it be down to using cheap Chinese logic chips? I've just used basic 74LSxxx ics, would it be worth trying 74HCxxx ?
I'd be very grateful for any insight into what could be going on and what to try.

Your symptoms suggest data bus timing issues or glitches, likely due to slow rise/fall times or noise. The XT bus on an 8088 system like the PPC640 is relatively slow (~4.77MHz), but even at these speeds, signal integrity matters a lot, especially with longer traces or marginal logic levels.

 

[roddersuk]

One question I have about this: why does it only buffer the bottom 8 address lines?

This is because the upper address lines are buffered by the PPC640.

Do you have bypass capacitors on the VCC lines for all the ICs?

Yes

This design omits the buffer, which means that pull-down on D7 is always there. Always

The construction instructions say to omit the pull-down resistor on D7 for this reason. I left it out.

It does all seem a bit of a mess, the PPC640 has a mix of logic types. There is an LC latch on A8-A15, and HC buffers on D0-D7, A16-A19 and some of the control lines. A0-A7 comes from a custom chip so who knows what that is. My expansion board has 74AHCT244s so they should be good but the XT-CF-Lite has LC chips. I'm currently working on the assumption that LC logic signals coming back to the PPC may not be triggering HC logic chips correctly. I've ordered HCT chips for the XT-CF-Lite.
Not had chance to scope the power or other signals yet. I'll report when I get around to it.

 

[rodney]

t does all seem a bit of a mess, the PPC640 has a mix of logic types. There is an LC latch on A8-A15, and HC buffers on D0-D7, A16-A19 and some of the control lines. A0-A7 comes from a custom chip so who knows what that is. My expansion board has 74AHCT244s so they should be good but the XT-CF-Lite has LC chips. I'm currently working on the assumption that LC logic signals coming back to the PPC may not be triggering HC logic chips correctly. I've ordered HCT chips for the XT-CF-Lite.

Years ago one weekend I decided to wire together a XT-IDE board and get this built into my PPC640.
The way I did it was crazy and not meant as recommendation here with all the loose wires which is terrible, however I did open the thing up just now to record all the logic types as used. So all the logic is HCT chips except one AND gate chip which is HC08, which I just happened to have on hand. Anyway I thought that some were LS etc but apparently not, it was long ago. I just offer this as background info for what it may be worth since I also am using this on the PPC640. So my experience was also that HCT worked best as kevju commented, because I do remember swapping chips until the HCT turned out to work best.

Indeed I remember that the solidity of the wiring was a big factor so having an actual PCB is the best way to go which resulted in much more solid operation in my XT mainboard design. So there I immediately saw the difference that there all drives functioned, while in the PPC640 with my relatively more unreliable loose wiring method, only certain drives worked correctly and others refused to work. So that must be due to the ground bounce etc due to less solidly being put together which was already commented here I think. Also because my XT is a completely different system the timing needed to be different and I exchanged a few parts with LS I think. To get the timing right. Anyway that design is on my GitHub page.

Anyway what I also want to point out is that the XT-IDE device may be timing sensitive though the CF-lite is more simple and therefore likely much less sensitive, and in addition I remember reading long ago that the PPC640 has certain specific buffering requirements as is described in the Amstrad user manual specifically when putting any device on the expansion lines of the system, I think you are also aware of these things from what I read. Also, in my PPC640 I anticipated that the mechanical laptop HDD(I love mechanical drives) would possibly need more power from the 5V line so I wired in a separate power module from 12V to the drive 5V so it would not tax the PPC640 power supply too much. I removed the modem to make space for the drive stuff. I seem to remember that when powering the HDD from the Amstrad 5V line directly this may have resulted in weird flashing on the LCD display.

So this drive solution as-is has worked fine and stable for years and I just want to share the schematic details in case you may find something useful in there like the logic types for me HCT worked well. My hand wired board is of course the complete XT-IDE.
I don't know what the Amstrad power supply can deliver but maybe it's a factor as well.
And I would also suggest to make a really solid ground wire from the XT-IDE to the Amstrad ground.
Just make the power really solid as you can.

So this is in no way meant to illustrate how to do it, because it isn't, but it is functional and I was able to install DOS, it boots etc so it does what you would need from the thing. The flat cables are long etc so that's also not ideal, it was really an impulsive experiment to see if it could work.

Hope you can get it to work and be able to boot the Amstrad from the thing which is always cool to be able to do!

Kind regards,

Rodney

 

[Eudimorphodon]

Anyway what I also want to point out is that the XT-IDE device may be timing sensitive though the CF-lite is more simple and therefore likely much less sensitive, and in addition I remember reading long ago that the PPC640 has certain specific buffering requirements as is described in the Amstrad user manual specifically when putting any device on the expansion lines of the system, I think you are also aware of these things from what I read.

FWIW, your device *does* have buffering between the Amstrad's bus and the IDE/CF device that @roddersuk's lacks.

Regarding the CF-Lite's "sensitivity", it might be worth pointing something out about how the 8-bit access mode actually works. In normal 16 bit mode a regular IDE device has a counter that starts at 255 and goes down to zero every time it's accessed (IE, a read or write strobe is cycled against the data register), which advances the device through the 512 byte sector read/write buffer in 256 16 bit chunks. When you set 8-bit mode that counter behaves differently; with every access strobe the device will present *each half* of the 16 byte word at each of the 256 sector buffer word locations. This difference seems like it might be relevant because of this:

As a final test I wrote the MBR using FDISK /MBR on the PPC then read the CF card on my linux box and printed out a hex dump of the first sector. I then used TESTMBR to read it on the PPC and compared the results. The PPC seemed to be reading back mostly correct but there is the occasional glitch where two bytes are skipped and the previous byte is repeated. This looks very much like a timing issue, could it be down to using cheap Chinese logic chips? I've just used basic 74LSxxx ics, would it be worth trying 74HCxxx ?

If it's repeating bytes this kind of feels like the CF card might be missing read or write strobes and getting its counters out of sync? In these cases where you get these symptoms does the rest of the dump lag behind from that point or does it sync back up again? If the rest of the dump after these glitches lines up properly then it probably *isn't* missing read strobes, it's more likely to be a bus integrity problem of some kind? It's hard to think what that would be, although since the PPC640 apparently uses a V30 CPU there could be something weird about the bus glue that converts from 16 to 8 bit.

The construction instructions say to omit the pull-down resistor on D7 for this reason. I left it out.

Good. I guess there's still the point that by not having a buffer you still have a *another* connector on top of the ISA slot (and in this case the D plugs) between the thing that's driving the bus and the motherboard, but I suppose a counterpoint is that if you have a CF socket on the board instead of an IDE header and an adapter it's at least not a long dangling cable. (IE, mechanically it shouldn't be much worst than just having a socketed chip.) Nonetheless there's still probably something to be said for being able to isolate the removable black box behind a "known quantity". (But of course fixing that would mean building a new XT-CF from a lo-tech schematic or whatever.)

Anyway, this page confirms that the data lines on the expansion connector are at CMOS levels, and also say it's important for the memr/w, ior/w, and A0-7 to be externally buffered, which the schematic for that slot backplane did have, so I guess that's settled. It says all the other outputs should be TTL compatible so focusing on the data bus integrity and *possibly* the IOR/IOW control lines is probably the right angle to attack things from.

 

[roddersuk]

In these cases where you get these symptoms does the rest of the dump lag behind from that point or does it sync back up again?

No, it doesn't sync back up it carries on with the lag.

focusing on the data bus integrity and *possibly* the IOR/IOW control lines is probably the right angle to attack things from.

Yes, I feel that its the IOR/IOW lines that are using TTL signals and when it hits the CMOS levels they can sometimes get it wrong. If the signal is outside the CMOS range (as TTL can be) I guess it would be treated as floating and ignored.

 

[Plasmo]

IOR is the most critical signal. Retro hardware are too slow to respond to ground bounces generated by CF. The victim of ground bounces is CF itself, specifically the IOR control line that reads the internal data FIFO. A glitch can cause the FIFO to advance to next byte. A simple low-pass RC filter, 100ohm series resistor to 100pF cap, is sufficient to filter out the glitch.

 

[roddersuk]

Well I've measured the power and its a solid 5v and replacing the ICs with HCT types didn't fix it.

IOR is the most critical signal. Retro hardware are too slow to respond to ground bounces generated by CF. The victim of ground bounces is CF itself, specifically the IOR control line that reads the internal data FIFO. A glitch can cause the FIFO to advance to next byte. A simple low-pass RC filter, 100ohm series resistor to 100pF cap, is sufficient to filter out the glitch.

I agree that IOR is the likely culprit, particularly as reflashing the EEPROM worked OK which would indicate that the data and address lines are fine. I'll scope out IOR and try the low pass filter if it looks dodgy.

 

[roddersuk]

A simple low-pass RC filter, 100ohm series resistor to 100pF cap, is sufficient to filter out the glitch.

Just to be clear: the resistor in series with the IOR line and the capacitor from IOR to ground and close to the CF connector?

 

[Plasmo]

The 100pF capacitor should be close to the CF connector. Resistor placement is less critical, but I generally place it next to the capacitor.
Edit, here is a picture of the RC filter. It was someone’s CF board design that was problematic. I added the filter to fix the problem.

 

[FreddyV]

There are problems on the PicoMEM with the enide design as well, and probably some other.
And Adding an XTIDE board make the PicoMEM work

 

[roddersuk]

The 100pF capacitor should be close to the CF connector. Resistor placement is less critical, but I generally place it next to the capacitor.

I've made the LP filter mod but sadly it didn't work. It seems to have gone the other way now adding in extra values (often zero) even when filling with the same value.
Here's the mod, I used SMD components as space is tight:

Could it be that the cutoff frequency is too low, the values you suggested give a -3dB cutoff at 16MHz and with a bus frequency of 8MHz that would cut out all the odd harmonics?
I need to do some scoping to see exactly what I'm getting and then I'll play around with smaller resistors so see what changes. I'll probably switch back to 4.77MHz to see if that's better as well.

 

[Plasmo]

Shoot, surprised that didn’t fix the problems. Is this 8-bit data bus or 16-bit? For Z280 and 68K 16-bit CF interfaces I also have 100 ohm series resistors on each data lines to reduce the current spikes. 8-bit CF interface for Z80 and 6502 do not need series termination resistors. I don’t believe CPU clock matters; the basic CF interface worked from 1.84mhz to 30+mhz.
For setup and holding, Zx80 timings worked out so CF can connect directly to CPU bus, but for 68K and 6502, setup time between CFchipselect and CF read/write strobes needed additional flipflops and wait states logic.
I probably have 20 homebrew designs using CF across 6502, Zx80, and 68xxx, so I believe the CF problems are solvable.

 

[roddersuk]

Here are the scope results measured at the isa bus (I guess I should measure at the CF card next, this was just less fiddly):
IOR

IOW

AEN

D0

D7

A0

A8

A16

My observations:
1. The IOR signal looks good, slightly better than IOW
2. All signals seem to be TTL except A8-A15 which are CMOS. A8-A15 is buffered by a 74AHCT244 but so are IOR and IOW (different IC) and they are TTL. Go figure.
3. A16-A19 are very noisy but these are not used for accessing the CF card, only the ROM

Looking again at the MBR corruption and there is a pattern, when extra bytes are inserted this happens every 8 bytes for a few occurrences. The sequence eventually syncs by dropping a byte, seemingly at random.
Thoughts?

 

[roddersuk]

Is this 8-bit data bus or 16-bit?

Its an XT class machine with an 8 bit data bus.
Thanks for your help with this Plasmo, I'm losing hair...