- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Getting XT-CF-Lite/XT-IDE working
- Thread starter Bill-kun
- Start date
Looks fine to me.
Should I try reprogramming the ROM at this point?
modem7
10k Member
From what I have read, the VMWare passthrough method is hit-and-miss. I tried it myself once, and it was unsuccessful. I believe the reason is put down to differences in CHS translation. Doing the partitioning and formatting on the vintage computer is normally the fix.
True, and I thought of that yesterday too. However regardless of addressing format the boot sector is at the beginning and fixed length. Don't CHS 0/0/1 and LBA 0 map directly? E.g int13h should get boot sector in both of the cases.
Anyways. This seems to be a peculiar problem with my environment so to speak. The peripheral works great. I moved back my HDD and I'm using CF as secondary drive and removable/transfer media.
I can verify that XT-CF-Lite 3 using XUB v2.0.0β3+ (2013-04-03) configured with default I/O ports works on M19 together with onboard MFM HDD controller. Thank you for support
Anyways. This seems to be a peculiar problem with my environment so to speak. The peripheral works great. I moved back my HDD and I'm using CF as secondary drive and removable/transfer media.
I can verify that XT-CF-Lite 3 using XUB v2.0.0β3+ (2013-04-03) configured with default I/O ports works on M19 together with onboard MFM HDD controller. Thank you for support
gotcha
Member
My 2 cents.
With such a big CF, the BIOS will perform a CHS translation between what the CF card gives (the physical CHS) and what the DOS sees (the logical CHS) .
If you have a different translation method between the VMWare BIOS and XUB on the XT-CF, the same CHS address can point to a différent physical sector of the CF card.
Note that you can configure the translation method on the XT-CF. I don't know about the VMWare BIOS.
I think it's worth checking the same translation method is used.
You could try with a older and smaller CF card. For example a 32MB. In this situation, there should not be any CHS address translation so VMWare and XUB will be consistant.
With such a big CF, the BIOS will perform a CHS translation between what the CF card gives (the physical CHS) and what the DOS sees (the logical CHS) .
If you have a different translation method between the VMWare BIOS and XUB on the XT-CF, the same CHS address can point to a différent physical sector of the CF card.
Note that you can configure the translation method on the XT-CF. I don't know about the VMWare BIOS.
I think it's worth checking the same translation method is used.
You could try with a older and smaller CF card. For example a 32MB. In this situation, there should not be any CHS address translation so VMWare and XUB will be consistant.
Last edited:
gotcha
Member
The MBR looks fine to me too.Looks fine to me.
I don't understand this. Unless it's a botched programming, the above code should not fail that cmp, unless es:bx does not point to MBR which again I'm not sure how would happen.
Should I try reprogramming the ROM at this point?
The boot issue you get may actually come from after the BIOS and the MBR are executed: in the boot sector of the DOS partition.
Last edited:
modem7
10k Member
That is a very old version of XUB, and there have been many fixes to the XUB since 2013. If you decide later to upgrade to a recent version, note that since 2013, the CHS translation in the XUB has been changed, and as a result, you will probably need to redo the partitioning and high-level format of the CF card. I have all my XT-IDE/XT-CF cards now running a recent version, and have no problem at all swapping the CF cards from the XT-IDE/XT-CF to/from my Windows 10 computer (in order to copy/move files to/from my vintage/modern computers).
I have storaged the computer for the time being, until I get some time to play with it again. For me it was important to assert that the product works immediately after I received it from the seller.
Btw. I am able to seamlessly move files just as you. The card runs everywhere and everyone sees the 40MB partition - M19, Windows 10 when not passed through, VMWare when passed through, and Pentium 200 in its CF-IDE adapter. But, M19 does not boot from it, while VMWare and Pentium do. "NORMAL" used in CMOS setup.
Currently I still can't reconcile this but it's not that important. You know if addressing scheme is the problem then MBR would be read correctly but first partition wouldn't be read correctly, while here we have the issue that first partition is read correctly everywhere, but there is an issue with XTIDE and MBR since it fails to detect magic where it's supposed to be? The error messages I get correspond to FirstHardDiskSectorNotBootable and not FailedToLoadFirstSector which is a code path that tests for magic and fails if isn't there, code past the MBR adressing?
I think everything can be nullified with the recommendation to get a very small CF which can house a CHS adressing. But I find it not easy getting a new one that small. Smallest I found on Amazon is 1GB "Cloudisk" and it does not work.
Btw. I am able to seamlessly move files just as you. The card runs everywhere and everyone sees the 40MB partition - M19, Windows 10 when not passed through, VMWare when passed through, and Pentium 200 in its CF-IDE adapter. But, M19 does not boot from it, while VMWare and Pentium do. "NORMAL" used in CMOS setup.
Currently I still can't reconcile this but it's not that important. You know if addressing scheme is the problem then MBR would be read correctly but first partition wouldn't be read correctly, while here we have the issue that first partition is read correctly everywhere, but there is an issue with XTIDE and MBR since it fails to detect magic where it's supposed to be? The error messages I get correspond to FirstHardDiskSectorNotBootable and not FailedToLoadFirstSector which is a code path that tests for magic and fails if isn't there, code past the MBR adressing?
I think everything can be nullified with the recommendation to get a very small CF which can house a CHS adressing. But I find it not easy getting a new one that small. Smallest I found on Amazon is 1GB "Cloudisk" and it does not work.
modem7
10k Member
Still going through my to-do-list.
At [here], in the 'I upgraded the release of 2.0.0 Beta 3+ of the ...' entry, I included an observation that the symptom appeared to be a booting one only. But in doing file CRC tests, I would not have tested many files. Still, odd.
I decided to try many more files.
I brought out an IBM XT, and to it, fitted an XT-IDE card, one that had XUB of release R625. The XT-IDE's CF card is 64 MB sized, but because I run IBM DOS 3.3, the DOS partition on it is 32 MB sized, enough for what I do. I put 20 MB worth of small files (440 files) onto that CF, scattered over about 100 directories. Using a particular CRC tool, a record was made of the CRC of every single file. The record is a CRCKLIST.CRC file that resides in each directory. As expected, sweeping (SWEEP.EXE) through all directories showed that all files had a CRC that matched the recorded one.
Then, on the XT-IDE card, I removed the EEPROM containing XUB release R625, and in its place, put in an EEPROM containing XUB release R602. R602 on this new EEPROM was preconfigured for my XT-IDE card. Because of the aforementioned 'I upgraded the release of 2.0.0 Beta 3+ of the ...' entry, I knew that there would be a problem when I tried to boot from the XT-IDE card. Sure enough, I saw "Missing operating system".
I then booted from an IBM DOS 3.3 boot floppy (i.e. no change in DOS version) then repeated a 'sweep' through all directories on the CF, using the CRC tool to see if all files had a CRC that matched the CRC recorded in CRCKLIST.CRC. They all matched !
Between R602 and R625, there was a change/fix in the CHS-to-CHS translation algorithm or CHS-to-LBA translation algorithm. With my crude understanding of CHS translation, I can understand the "Missing operating system" at boot time. But what I don't understand is why a CRC validation of 20 MB worth of 440 files still gave no CRC mismatches.
Will someone adequately knowledgeable in the CHS translation subject, please explain that ?
gotcha
Member
@modem7 in XUB r606, I see this:
If your CF declares more than 1024 cylinders, I assume there are no changes since the translation is applied as usual in the old and new XUB.
For exemple, I have a 32MB CF that declares 490 cylinders and that would be affected by the change.
My understanding is that it only concerns small CFs that declare less than 1024 cylinders.
If your CF declares more than 1024 cylinders, I assume there are no changes since the translation is applied as usual in the old and new XUB.
For exemple, I have a 32MB CF that declares 490 cylinders and that would be affected by the change.
modem7
10k Member
That is why the bug affects my configuration, but I am asking a different question. Different CHS translation is being applied, which explains the "Missing operating system" at boot time (presented CHS ends up being pointed to different blocks), but not the fact that after booting via other media, all is working.
I'm not sure i follow, Why would they mismatch, The way i see it, it's purely a booting issue, Pre R606 XUB used LBA for CFs that declare less than 1024 cylinders and now NO translation.
Booting from hard drives is more complex than booting from floppy.
gotcha
Member
All these translation aspects are tricky. And this is amplified by the fact that different BIOS may use different formulas.
From what I understand, in case the user left the translation as 'auto' in the XUB config, and in case a CF has less than 1024 cylinders declared, we have 2 cases:
From what I understand, in case the user left the translation as 'auto' in the XUB config, and in case a CF has less than 1024 cylinders declared, we have 2 cases:
- before r606, the 'assisted-LBA' translation is used by the XUB. The XUB does the conversion between logical CHS addresses and LBA and accesses the CF with LBA addresses.
I assume that the XUB uses the 'standard' Phoenix BIOS translation rules. This is described in https://www.singlix.com/trdos/archive/pdf_archive/ATA_EDD_11.PDF .
Phoenix selects a CHS geometry that depends on the CF capacity (see picture at the end of this message). This geometry always have 63 sectors. - after r606, no more translation is applied.
The XUB accesses the CF directly with a CHS addressing. The LBA translation still happens internally to the CF (the CF being naturally LBA on the contrary to hard disks).
If the CF declares a CHS geometry different from what XUB/Phoenix selected in case 1, then I think the translation will be different even if they both use the same CHS->LBA conversion formulas.
Last edited:
Yes. Just make sure there's no I/O-address conflict.
Thanks!
Tell me more about the configuration.
Both cards are known working, each on their own, in that same computer? What kind of computer is it? Which version and build of XUB? What are the settings as configured by jumpers/switches for each card?
If there are no conflicts they should both be detected when running 'Auto Configure' in XTIDECFG (with at least one drive connected to each card). Is that working?
What other configuration options did you change (if any)? Are you using 'Full operating mode' or not?
Which card did you disable the ROM on and how did you do that?
Are you getting any sign of life from the XUB? Any drives detected at all?
<snip>
It's all working now!
IBM XT 5160, 64-256K motherboard, IBM original floppy controller, AST SixPackPlus filling RAM to 576K, some sort of Cirrus VGA that happens to work in an 8-bit slot.
XT-IDE Glitchworks 4A, BIOS on that card, at B000. I/O set to 320.
XT-CT-Lite Sergey, BIOS disabled. I/O set to 340.
Yesterday afternoon I thought I noticed something, that some working configurations stopped working after slight reconfiguration, until the machine was power cycled. Then last night while googling around related to that, I found this:
https://forum.vcfed.org/index.php?threads/xtide-problem.41419/post-502249
So this morning I very carefully and systematically tried everything again, starting from scratch with XUB 1.1.5 with Compat Mode and just the XT-IDE controller. And worked my way up to XUB R625 with XT-IDE in Hi Speed mode, and the XT-CF-Lite present.
All working! (currently tested with a Fujitsu 4.3 GB disc)
Power cycling was definitely required between some of the changes.
So it's possible that before when I thought certain disks didn't work correctly with my XT-IDE / XUB, that it was the fresh power up of those drives that "fixed" it. I will go back now and try the older smaller drives.
It's also possible I had the XT-CF-Lite in Slot 8 for at least one of the previous failures. Dunno if that matters.
Bill