Getting XT-CF-Lite/XT-IDE working

[Bill-kun]

I had been planning to write something up on the subject for a while.
I have started that - see [here].

Thank you. I will save this in case I become interested in that in the future.

Maybe the problem is the first one listed at [here].

Refers to using FDISK /MBR. Yes, that was the problem. Once I used FDISK /MBR, the 512 MB. card works fine in the XTIDE board.

I think this takes care of almost everything that I want to do with the Compaq Portable 1 before I "permanently" close it up. The only two things left I can think of are taking a picture of the XTIDE board, writing down the settings (and stuffing a written copy of the settings in the power cord compartment), and attaching an access LED. I just ordered 4 status LEDs (enough for other XTIDE boards plus screw-ups) with 12-inch wires and jumper connectors from Mouser. What I can do is route it to the grill above the XTIDE board expansion slot, and twist-tie it to the inside of the grill. That will make it visible from the outside without modifying the case at all, or risking being smashed by the Portable 1's sliding door. See this screenshot from the 8-Bit Guy.


I can do a similar access LED placement inside the front grill of the Epson Apex 1.

 

[Bill-kun]

A word of advice to my past self and others’ future selves.

As I get more experience in using this XT-CF-Lite board, I am noticing that it “suffers” from the lingering capacitor charge effect. Meaning, if I turn the computer off for 4 or 5 seconds, it will often not solve whatever weird thing should have have been solved by a reset or a power-off. But if I wait 30 seconds, it will solve it, because the capacitors will have time to discharge. This was no doubt feeding into my frustration at at least one point while I was on the journey of getting this thing to work.

 

[modem7]

As I get more experience in using this XT-CF-Lite board, I am noticing that it “suffers” from the lingering capacitor charge effect. Meaning, if I turn the computer off for 4 or 5 seconds, it will often not solve whatever weird thing should have have been solved by a reset or a power-off. But if I wait 30 seconds, it will solve it, because the capacitors will have time to discharge. This was no doubt feeding into my frustration at at least one point while I was on the journey of getting this thing to work.

I have the same XT-CF-Lite as you, and I have not noticed the above.

It may be the Portable, not the XT-CF-Lite. According to the operations guide for the Compaq Portable, if you turn off the Portable, you then need to wait a minimum of 15 seconds before you power the Compaq Portable back on.

 

[Twospruces]

A word of advice to my past self and others’ future selves.

As I get more experience in using this XT-CF-Lite board, I am noticing that it “suffers” from the lingering capacitor charge effect. Meaning, if I turn the computer off for 4 or 5 seconds, it will often not solve whatever weird thing should have have been solved by a reset or a power-off. But if I wait 30 seconds, it will solve it, because the capacitors will have time to discharge. This was no doubt feeding into my frustration at at least one point while I was on the journey of getting this thing to work.

Actually, I'm not sure that is it, or at least not always it.

(does your machine use DRAM? probably)

I noticed when I looked at the XUB code, that it does not "wipe" the RAM to 00 before use. It assumes that RAM is starting from 00 on power up, which is a fair assumption usually. But not always.

In my application I was using SRAM for system RAM, and on Reset, there were some very weird behaviours.

To get my application to work correctly, I had to force-initialize a certain RAM location.

Point is - if you have any residual corrupt RAM data on power up or reset, that could be the issue. And of course that MAY relate to capacitor charge - especially with SRAM.

 

[Krille]

I noticed when I looked at the XUB code, that it does not "wipe" the RAM to 00 before use. It assumes that RAM is starting from 00 on power up, which is a fair assumption usually. But not always.

In my application I was using SRAM for system RAM, and on Reset, there were some very weird behaviours.

To get my application to work correctly, I had to force-initialize a certain RAM location.

Can you elaborate, please? AFAIK, we do initialize everything so this is a bit surprising to read but I could be wrong of course.

Unless you're talking about the BDA HD count? Because that doesn't... count.

 

[Twospruces]

sure, sorry, I know you are the expert. I was going from memory.
In fact, maybe you addressed the issue in the past, and my comment was not correct.

So, the machine I was working on was Zenith Z-171. You are right it was BDA..bHDCount..
Was I just unlucky and only BDA HD count was not initialized to zero?

https://forum.vcfed.org/index.php?threads/xtide-universal-bios-v2-0-0-beta-testing-thread.30259/post-886825

here's the synopsis -

Here's the short summary of the issue:

* in Z171, when booting a stock machine, the BIOS BDA entry 0040:0075, which represents # of detected HDD, is set to 0FF.
* (It also seems like it is not initialized on normal boot up, so FF might be what you get when power up)
* XUB assumes this value is correctly set by the BIOS.
* in the case of Z171, it should be set to 00 on every boot

Fix:
* in DetectDrives.asm there is a natural location to initialize the variable BDA..bHDCount which points to 0040:0075
* by initializing to 00 we correct the problem that un-initialized data is messing up the boot
* in the make file you need to add this line to the appropriate area
# Z171_HACK use to fix Z171 boot issue
* and of course, you need to add this to your specific build.

original code

mov cx, [RAMVARS.wDrvCntAndFlopCnt] ; Our count of hard disks
mov al, [es:BDA.bHDCount]
add [es:BDA.bHDCount], cl ; Add our drives to the system count
or al, 80h ; Or in hard disk flag
mov [RAMVARS.bFirstDrv], al ; Store first drive number


modified code


%ifdef Z171_HACK ; INITIALIZE .bHDCount every time
mov BYTE [es:BDA.bHDCount], 0 ; Set hard disk count to zero
%endif ; Z171_HACK

mov cx, [RAMVARS.wDrvCntAndFlopCnt] ; Our count of hard disks
mov al, [es:BDA.bHDCount]
add [es:BDA.bHDCount], cl ; Add our drives to the system count
or al, 80h ; Or in hard disk flag
mov [RAMVARS.bFirstDrv], al ; Store first drive number

 

[Krille]

Yeah, the system BIOS is supposed to clear the BDA HD count. XUB can't do it automatically because that would prevent people from using other harddrive controllers with a BIOS. That's why it's a configuration option ("Remove other hard drives") as of r605. Enabling that option means that drives connected to a SCSI-controller, for example, will be "removed".

 

[Twospruces]

Yeah, the system BIOS is supposed to clear the BDA HD count. XUB can't do it automatically because that would prevent people from using other harddrive controllers with a BIOS. That's why it's a configuration option ("Remove other hard drives") as of r605. Enabling that option means that drives connected to a SCSI-controller, for example, will be "removed".

I see, thanks for explaining that. Appreciate the insight.
In the end, with that Z-171... I ended up using a custom XUB to patch up a couple of other deficiencies with the main BIOS.
So patching XUB was very convenient for me!

 

[Bill-kun]

It may be the Portable, not the XT-CF-Lite. According to the operations guide for the Compaq Portable, if you turn off the Portable, you then need to wait a minimum of 15 seconds before you power the Compaq Portable back on.

It must be the Portable 1, then. The XT-CF-Lite and the Portable 1 are one electronic unit when it’s installed, so whatever.

I ordered a second XT-CF-Lite kit, had a more skilled solderer put the CF slot on, I assembled the rest and continuity-checked it all. That took a small fraction of the time the first one did. I’ve installed it in the Apex 1 and it fully worked on the first try. The I/O address is set to 320h because 300h is occupied by the serial port expansion card I added to give it a serial port.

I have made my list for closing up the Compaq Portable 1. Within a week, both computers will be finalized, off my kitchen table, to make room for actual eating, plus whatever next computer case I will work on next. The Portable 1 has been there since December. Likely, the next case will be the Compaq Deskpro 386, to add a new battery after modding the Dallas module. Then that one will finally boot.

 

[Zare]

Hello guys,

I purchased a preprogrammed XT-CF-Lite v4.1 from ebay. The SW1 dips are set to 300h and SW2 dips are set to use EEPROM on address CE000 and write disable it. This is how the device came.

Im running Olivetti M19 and I get "Master not found at 300h" regardless of unplugging the only peripheral which is the Olivetti disk controller.
For memory card I used diskpart on windows 10 to make a primary partition, active, 20 MB size and formatted it to FAT16.
What are my options here? I guess 300h is conflicting with something, but if itsn't the disk controller, I'm out of jumpers and DIPS to tweak.

 

[modem7]

Hello guys,

Hello. Welcome to these forums.

I purchased a preprogrammed XT-CF-Lite v4.1 from ebay.

Presumably, the seller tested it before sale.

Im running Olivetti M19 ...

I cannot see much technical information about that model online.

... and I get "Master not found at 300h" regardless of unplugging the only peripheral which is the Olivetti disk controller.
For memory card I used diskpart on windows 10 to make a primary partition, active, 20 MB size and formatted it to FAT16.

Per [here], for the XTIDE Universal BIOS (XUB) to display the CF card's model information, there does not need to be any data (from the CF card's perspective, data includes partitions, etc.) - the CF card can contain nothing but zeroes.

I guess 300h is conflicting with something, but if itsn't the disk controller, I'm out of jumpers and DIPS to tweak.

That is one possibility.
Per [here], we are aware of some XT-class motherboards that have a real-time clock starting at I/O port 300h.

Your reference to using diskpart suggests to me that the CF card was something you acquired separately to the XT-CF-Lite V4.1
The XT-CF-Lite V4.1 is shown, with comments, at [here].
Could it be that the CF card is incompatible with the XT-CF-Lite V4.1 ?

Do you have another computer to test the XT-CF-Lite V4.1 in? (I.e. Possibly disprove the I/O 300h conflict hypothesis.)

If you want to try using something other than 300h, there is a procedure at [here] which gives you an idea of what is required. If there is an existing I/O port conflict at 300h, the procedure should still work, because it doesn't use the 'Auto Configure' functionality within XTIDECFG.COM. The XTIDECFG.COM that you use needs to be the one supplied with the particular XUB version on the card - see [here].

 

[Eudimorphodon]

If you want to try using something other than 300h, there is a procedure at [here] which gives you an idea of what is required

FWIW, I kind of wish the default for XUB cards was 320h. I know why they *don't* use it because that would conflict with standard XT MFM/RLL controllers and there's certainly a use case for having an XTIDE and an XT hard disk controller coexisting, at least briefly, but it seems like 300h has its own gochyas. In addition to real-time clocks it seems like there are a number of different ISA network cards that use "soft-configuration" routines instead of jumpers that require 300h to be open to use the soft config utility even if ultimately you program the card for a different address.

 

[modem7]

FWIW, I kind of wish the default for XUB cards was 320h. I know why they *don't* use it because that would conflict with standard XT MFM/RLL controllers and there's certainly a use case for having an XTIDE and an XT hard disk controller coexisting, at least briefly, but it seems like 300h has its own gochyas. In addition to real-time clocks it seems like there are a number of different ISA network cards that use "soft-configuration" routines instead of jumpers that require 300h to be open to use the soft config utility even if ultimately you program the card for a different address.

Owners of the 'TexElec IDE to SD Adapter' (see [here]) are going to be ticked off if they discover an I/O 300h conflict and then discover that neither their 'TexElec IDE to SD Adapter' nor the conflicting hardware can be changed from 300h.

 

[Chuck(G)]

I have to admit that I've been out of the XTIDE loop since Hargle. Looking at the board that you cited, it's a bit hard to figure out what's on it. Is the 28 pin PLCC a CPLD?

 

[modem7]

I have to admit that I've been out of the XTIDE loop since Hargle. Looking at the board that you cited, it's a bit hard to figure out what's on it. Is the 28 pin PLCC a CPLD?

No idea.
I saw the 'TexElec IDE to SD Adapter' card for the first time on Monday, when someone referred to it in another thread ([this one]).
I know that TexElec sell Lo-tech cards, and so initially, I thought it was a Lo-tech card, but I could not find the card at the Lo-tech web site.

( New XT-IDE/XT-CF cards pop up from time to time, and I add them to my database at [here]. )

 

[Eudimorphodon]

I have to admit that I've been out of the XTIDE loop since Hargle. Looking at the board that you cited, it's a bit hard to figure out what's on it. Is the 28 pin PLCC a CPLD?

I would bet several shiny nickels it’s a PLCC ATF22v10 GAL. I’ve gone through the exercise of seeing if it’s possible to fit all the logic of an XT-CF (including ROM decode) into one GAL and yeah, you can. It’s tight, though, which would explain why they couldn’t spare a pin for I/O select.

Not impressed they didn’t buffer the data pins to the SD adapter. I know it’s piggybacked right there with no cable, but there’s still a connector, and so far as I’m concerned any IDE device, especially things related to CF cards (which the chipset in that adapter emulates) should be actively kept quiet until allowed to speak.

EDIT: wait… I guess I should be fair, maybe there’s a surface mount ‘245 hidden from view under the piggybacked adapter. Maybe.

 

[Zare]

Hello to you to @modem7 , thanks for the reply.

Olivetti M19 is a 8088 machine with Plantronics ColorPlus graphics adapter. It's a 64kb mem CGA that has normal text mode and 2 proprietary modes that utilize doubled base memory to display more colours. Apart from graphics adapter it's a bog standard 8088, mine runs @ 4.77MHz and has 512kb of RAM and it's a 20MB HDD model. The only peripheral card is MFM disk controller branded by Olivetti. There are 3 8 bit ISA slots on the mobo. 5.25" drive needs repair/restoration. I have monochrome display model.

After I posted yesterday I went googling and found ebay ad for the same item, in description it lists M19 as one of a dozen listed 100% compatible machines, and says that the CF must be 8GB max. The only CF I have is 32GB. I ordered 1 and 4 GB cards which should arrive soon.

I have a mediating machine which is Pentium 200. I can plug XT-CF into it, and I can also connect to LAN or Internet from it and also have it connected serially to M19 via Kermit which I have on M19. This is my way of moving internet files to M19 (so there is a possibility to reprogram the card from M19)

M19 has RTC I used it to make graphics demos recently in Turbo C. There is no configuration (apart from resampling it), so I presume it runs on 70h/71h?

 

[Chuck(G)]

I would bet several shiny nickels it’s a PLCC ATF22v10 GAL. I’ve gone through the exercise of seeing if it’s possible to fit all the logic of an XT-CF (including ROM decode) into one GAL and yeah, you can. It’s tight, though, which would explain why they couldn’t spare a pin for I/O select.

Not impressed they didn’t buffer the data pins to the SD adapter. I know it’s piggybacked right there with no cable, but there’s still a connector, and so far as I’m concerned any IDE device, especially things related to CF cards (which the chipset in that adapter emulates) should be actively kept quiet until allowed to speak.

EDIT: wait… I guess I should be fair, maybe there’s a surface mount ‘245 hidden from view under the piggybacked adapter. Maybe.

I suppose that a couple of the address pins might be swapped to fix the problem. 10 bits decoded as 11 0000 xxxx,
so one could, for example, shift it to 10 1000 xxxx, (28x) which should be clear for most applications. Just a couple of cuts and jumpers.

 

[modem7]

M19 has RTC I used it to make graphics demos recently in Turbo C. There is no configuration (apart from resampling it), so I presume it runs on 70h/71h?

We know that there are XT-class computers with a motherboard hosted RTC based at 300h.
And I know that at least the Amstrad 1640 has an AT compatible RTC, and like the IBM AT, based at 70h. (See [here].)
There could be XT-class computers with a motherboard hosted RTC based at different addresses.

 

[Zare]

No, 300h is not taken in my case.
I got a Transcend 4GB CF card and now its read correctly and everything works. But, I cannot get the computer to boot from it.

My floppy is inoperable. I don't want to reassign active partition while my HDD is in. I could lose boot on the machine, which is a disaster. I've removed everything (for restoration) and now the computer is motherboard only + XT-CF plugged in.

The card came preformatted so I used diskpart on Windows to null it out. Once on M19 (before HDD removal), I just normally used my DOS 3.30 to partition/format and test copy some files.
When I removed peripherals from M19 the card didn't boot which was probably normal because it didn't have active partition flag.

The error is "boot sector not found"
So I moved it to VMWare where I can passthrough any DOS to it, and installed MS-DOS 3.30, verified it has active flag set. The error resumes on M19. I booted DOS 5 on the VM, and issued fdisk /MBR, again no avail on the M19.

Do you think following procedure should work?

- zero out the card (diskpart clean all)
- install a platform compatible DOS version (like 3.30) via a hypervisor. Devices are virtual floppy, and direct map of CF card.
- boot DOS5 in the hypervisor and rebuild MBR (fdisk /mbr)

IMO after this the card should have a valid master boot record and partition table and and a primary active partition and DOS boot files in the primary partition. I see no reason why no boot on XT? I'll rerun the complete procedure again. If it still doesn't work I'll have to check bytes on the card and see whether there's any junk there.

I have another PC with ISA (16-bit) but XTCF doesn't just work there, no outputs. I need to check BIOS mapping on that machine. It's a 200MMX with AGP slot. It may not work at all.