XTIDE Universal BIOS

[migry]

Does that corruption vary, e.g. where the strange characters appear in the model string?

Yes. Strangely the main form of corruption is the C-like (cedillas?) characters for the NWDOS7(*) CF, sometimes the string is blank (for the MSDOS 3.11 CF).

(*) Apparently Novell DOS 7 was abbreviated NWDOS!

Just FYI. While trying to debug the hardware, having swapped the faulty 74LS688 out, I used debug to "probe" for the card. This is how I discovered that the card is addresses at even port addresses. Initially I sent the "EC" (Identify) command and repeatedly read the data register (in 300). I wrote down the hex values and found that the expected CF 2 byte signature was wrong. This alerted me to the fact that I needed to use a command to put the card into 8-bit mode. Once I did this and re-issued the Identify command, I read out a string of sensible values from port 0x300. I saw the ASCII serial number, but stopped around there.

 

[migry]

Some issues that I have experienced with a POST card in a PC or XT class computer, are detailed at [here].

Instead, for a PC or XT class computer, I insert code that sends diagnostic codes/bytes to a parallel (LPT) port, and use the device shown at [here] to view the bytes. The bytes can also be viewed by a line printer that has a 'hex' mode - example at [here]. Rather than sending to a single LPT port, for flexibility, I send to three:

Thank you for alerting me to the problem with (some) POST cards.

I did create a custom binary, simply by adding code to write a value to port 0x80.
I have four POST cards, sourced via AliExpress. They plug into either ISA or PCI, and appear to work OK in the 486.
The Hyundai 8088 BIOS does not write to port 0x80.
I did not see the number from the custom binary appear on the POST card. The displays on one card flickered badly. I'm guessing there is a timing problem.

Just FWIW. One of the TTL parts on all four cards has the exact same date code, suggesting that they likely came from the same "batch". However the GALs do not show this pattern. Some are scratched. One is a 3.3V part #FFS. I'm thinking that the GALs have been "rescued" from scrap PCBs, something that is known to happen in China.

So inspired by your LPT POST card, I rolled my own using an Arduino NANO. The Hyundai has a built in parallel port. I added code (using a simple NASM macro) to write to the 8 bit databus and used the strobe to indicated valid data. It can display ASCII, so gives me a way to display debug information. I guess I could also have done the same thing with serial, but then I get into the issue of serial cables and USB to RS232 adapters.

 

[migry]

Presumably, you will be acquiring more 360K sized floppies.

FYI. In the 8088, if you attach a 'standard' 1.44M drive up to the floppy controller, in place of the 360K drive, it is expected that you will be able to boot from a 720K sized DOS boot diskette. For those with an IBM PC or IBM XT, the instructions that I point to are at [here].

FYI. In the 8088, the XTIDE Universal BIOS (XUB) together with the motherboard's serial port, and some other hardware, can access a serial drive - see [here].

TBH, you can't squeeze much onto a 360k floppy. Nevertheless I can boot from A: and run "debug.com".

After I attached the 360k to the 486, I realised that I could have the 360k 5+1/4 and a 720k 3+1/2 in the Hyundai PC. Nevertheless it's a way to be able to run some utilities, but I still have the problem of no mass storage on the 8088.

Yes, I was aware of the serial drive solution. I was avoiding going the serial route, but it is something I will consider.

 

[migry]

Are you aware of 'Hak Foo's' Boot bios and 'FreddyV's' DOS driver ?, If you got a spare ROM board you could try with the Boot bios on that.

Your first priority is to get the CF 'Model string' to read correctly, Wipe the CF RAW / Zero out the whole of the CF, The XUB issues the 'Drive Identify' command and gets the parameters from the CF. Did you build this XT-CF lite yourself or buy it Pre-built ?. What IC's are on the board, are they 'LS' / 'HC' / 'HCT' series or ?.

The EPROM card I am using, is my attempt to fix the bugs with ROM address decode on the Chinese CH375B ISA card. While searching the web for information about the CH375 to see if it could be replaced with the CH376, which I have several of, I think it was "Hak Foos" messages which I read.

The board was bought via Ebay, and I built it myself. All the parts are LS TTL. The only parts which I needed to buy, were the 74LS688 comparators. I can't recall where I sourced them from, either: Ebay UK; Digikey; or AliExpress.

 

[migry]

Note: both CF cards are the exact same size and brand (256Mb). I ought to try a different card to see if it behaves in the same way.

I am still working my way through the XTIDE code.

I have captured the data written to the IDE (CF) registers



So I need to find where the data is read for the EC command and send it to the LCD, to to see if is getting read with corruption.

 

[migry]

Update...

I created another Novell DOS 7 image on a different compact flash card. I confirmed that it boots on the 486.

I swapped the card over to the 8088 PC. The XTIDE boot ("Master") message showed what appeared to be the same card ID string as shown on the 486, with no funny characters. The LED on the card blinked briefly as each sector was read. The debug Arduino on the LPT port was still in circuit and since I had slowed the character output, it was painfully slow, but every 10 or 20 seconds was another LED flash (sector read). I gave it 10 minutes then got bored and switched off, however it did appear that sectors were being read from the compact flash. I replaced the "debug" ROM with a previous ROM which had the standard "XT" image. I switched on, and after a short delay booted from the compact flash and I got the "C:" prompt.

So the problems were caused simply by the compact flash card(s) I have initially used, which just happened to be the same brand and size.

Luckily in February I managed to find someone selling compact flash cards for $2 a piece, so I bought 5. The working card is one of the others which is a different brand and size (8Gb). I realise that hard disk size and DOS max partition size is a bit of a minefield, however it appears that Novell DOS 7 supports a max primary partition of 2Gb, and logical partitions of the same size. Nowhere on the CF card is the capacity clear to read.

My best guess is that the cards have different timings. My hunch is that it might be data hold time, and that perhaps if the CF card had been buffered then reading data from the CF to the ISA bus, the data would have been "held" just a little longer due to the propagation delay through the buffer. This intrigues me, and I will investigate further, although not immediately. I might simple roll my own CF card PCB and add a buffer. At the very least it will give me some more PCBs for future use.

 

[super-sama]

See attachment.

Tried this as I have the same issue with r625 doing the double-drive clunk like no one's business on my NEC PowerMate SX/20vi. This ROM works with the drives hooked to the onboard IDE (at 1F0h), but only when the 2864 is inserted into a proper XT-IDE card (GW rev4a). if I shove the ROM into the ROM socket on either my 3com 3C509B, Novell/Eagle NE2000plus3 or even the oddball 3Com 3C515-TX I have here (all configured for D000h ROM location), it gets to the point of drive detection, drops down an extra blank line like it's going to try to boot, and just hangs the system. I'm looking to see where my one Intel EtherExpress card is that I remember seeing like a month ago to see if this happens on that card too, but I'm going to be honest that it might also act the same.

Even if I quickly mash A to get it to try to boot floppy, nada. just hangs there, so it's not a partition compatibility issue I'm believing. I only have two ISA slots in this machine and both are taken up, by an SB16 and any of the above eth cards.
What's even weirder is, if I use r601 like I have been up to this point, it can see and use a single drive fine, but other drives on the same cable cause random issues. one of my drives is a Seagate Medalist 6531 6.5GB drive that for all intents and purposes is super healthy for its age, and yet it won't enumerate any of the partitions I made on it if there's a drive in the master position on the cable (in this case, it's a 512MB Apacer DOM SSD thing with a male-male gender changer adapter on the IDE cable to get that to work). In the other corner, it refuses to even detect a WD Caviar 2420 425MB drive I've had in my posession for 15 years, also astoundingly healthy as determined by spinrite. Moving up to r625, it sees both of them in the slave position but does that double disk reset that clunks the heads. The modified r625 without the power management module fixes the no clunk, but again, leaves me hanging if the ROM is in an eth card, and yet will boot if it's in an XT-IDE card proper. The interface on the card isn't even configured for use on this ROM, it's just sitting there doing nothing, acting as a glorified ROM card. it's an extremely weird bug that's driving me bonkers.

Ah, Editing this in: the SX/20vi is just a 386SX, the chipset on the board is a Western Digital WD7600A/LP/LV chipset. just recently submitted the datasheets for all three chips in the chipset to theretroweb so I'm gonna link it here as it may be pertinent to my particular issue. It could also be NEC's horridly rudimentary BIOS implementation as well, as it has nearly zero configuration options and I'd really love to have something else on there if possible.

 

[ltning]

I have been using Apacer CF cards for a while, but apparently somehow been able to avoid pairing them with XTIDE. Yesterday I did, and that cost me the better part of a day troubleshooting
The cards do work, but the first few reads take 20++ seconds to complete. This happens at several stages:
- During whatever happens before XTIDE actually boots - so immediately after detecting the card
- During the "Booting C>>C" stage
- When picking a partition from whichever boot manager is used, if any

Once past that step - which can end up taking almost a minute - things seem to work fine. I'm even able to re-write the MBR (fdisk /mbr) without problem; this does *not* take longer than expected.

Once I thought of trying a different CF card (Delkin, Swissbit..), it took me 5 seconds to realise I was fighting a losing battle: The Apacer Industrial CF cards do not play nice with XTIDE

This was tested on a rev4 xtide card, and on a couple of different 16-bit ISA IDE controllers (UMC chip).

I also tested the build from earlier in this thread with the power management code ripped out; this did not change anything.

I'll be happy to ship a problematic card to anyone who wants to look into this. I won't need it back.

/Eirik

 

[Krille]

@super-sama; I'm thinking the gender changer adapter might be the cause of the problems. Have you tried with just two regular hard drives directly connected to the cable?

 

[super-sama]

@super-sama; I'm thinking the gender changer adapter might be the cause of the problems. Have you tried with just two regular hard drives directly connected to the cable?

yep, I tried with both the gender changer and just two normal hard drives, the behavior is exactly the same. For now I moved back to the ROM I was using previously and just hooked the Apacer DOM in by itself, but this is a really troubling problem altogether. I'm wondering if it's just how the BIOS does stuff with this board and what-have-you that the XTIDEUB doesn't like, but I can't be the one to figure that out as decompiling the Phoenix BIOS to get a glimpse of what it's wanting is beyond my expertise... and I know doing such with more modern Phoenix BIOS editor software is completely pointless as it will refuse to even open it. western digital chipsets in general all seem to be a bit on the weird side for stuff.

 

[super-sama]

Wanted to give a quick update, I did some snooping around datasheets for my board chipset and discovered that the control register for the onboard IDE is not 3F0h as predefined, but 3F7h. 3F0 is reserved specifically for floppy control register use!
This would also explain another long-standing bug I've had where I had floppy drives that would just stop working mid-write or mid-read. What was actually happening was, I was using the control register for a drive and ended up conflicting.
This likely means I don't need to use 2M.sys anymore as originally solved this problem.

Nearly a month later and now I have an XGecu T48 and 4 rather nice new-old-stock Seeq DQ28C256 chips from ~1987-14/17. They all function properly, but 0x7FC0 is stuck blank because I'm using the Atmel 28C256 template to flash it. Atmel bought Seeq's memory/flash assets in 1994 and the two are compatible to that point. I emailed XGecu's support about this with datasheets and such and have yet to hear back.
Regardless, padding the ide_386l.bin file to 16k and then concatenating it into a 32K ROM image works fine. The padding is all blank, so the write is good, and initial testing with an older 2013-03 XUB ROM works perfectly in my 3C509 and on my Rev4a... which, it shouldn't, as these are 300ns EEPROMs. All documentation I've read says that this should not be possible and to use 150ns or faster, and Hargle himself had issues with Seeq parts failing... but I think that's a culmination of using the PQ and not DQ (plastic encapsulated vs ceramic oreo) parts and whatever plastic formulation Seeq used being quite susceptible to moisture ingress post-manufacture, depending on the plant.

I'm going to try the R625 non-PM ROMs again but with the 3F7h change and report back once it's been verified this allows for more than one drive to be seen by the system.

 

[FreddyV]

Hi,

Doing my PicoMEM BIOS, I found that on the 5150, the Keyboard does not work.

GLA Bios Author told me that the kb interrupt code is not Active when the Optionnal ROM are run in IBM PC.

But checking at the XTIDE Code, it seems that the IRQ just need to be enabled.
Then, Key pressed can be checked:

Initialization in xtideuniversalbios/tags/v2.0.0_beta_3/XTIDE_Universal_BIOS/Src – xtideuniversalbios

xtideuniversalbios.org

sti ; Enable interrupts for keystrokes

test BYTE [BDA.bKBFlgs1], (1<<2) ; Clears ZF if CTRL is held down
jnz SHORT .SkipRomInitialization

But.... it is done using sti, then check the BIOS variable directly
it mean that the Keyboard interrut need to be fired between 2 assembly instructions.... Impossible.

Does anybody know where to find the LAST Version of the code (This repository say it is 10 years old) ?
And How is it possible to detect the Ctrl key pressed within a so short time... (Or the Ctrl Key press to skip the BIOS init does not work on 5150)

I see that the XTIDE code use the BIOS interrupt, strange if the Keyboard buffer is not initialized....

 

[Trixter]

sti ; Enable interrupts for keystrokes

But.... it is done using sti, then check the BIOS variable directly
it mean that the Keyboard interrut need to be fired between 2 assembly instructions.... Impossible.

It's not impossible. Once interrupts are enabled, the CPU is free to process pending interrupts. Keyboard is IRQ1, so unless there is an IRQ0 already raised, it will get processed first.

Does anybody know where to find the LAST Version of the code (This repository say it is 10 years old) ?

Most recent revision appears to be here: https://xtideuniversalbios.org/browser/xtideuniversalbios/trunk/XTIDE_Universal_BIOS?rev=625

And How is it possible to detect the Ctrl key pressed within a so short time... (Or the Ctrl Key press to skip the BIOS init does not work on 5150)

I think the idea is for someone to hold down the CTRL key if they don't want XUB to load. So the code enables interrupts, which will process a pending IRQ1 (because someone has already been holding down the CTRL key for many seconds), then the status of CTRL can be checked.

You might also want to look at the larger source that lets the user input a regular keystroke to pick A drive, C drive, etc.

 

[FreddyV]

It's not impossible. Once interrupts are enabled, the CPU is free to process pending interrupts. Keyboard is IRQ1, so unless there is an IRQ0 already raised, it will get processed first.



Most recent revision appears to be here: https://xtideuniversalbios.org/browser/xtideuniversalbios/trunk/XTIDE_Universal_BIOS?rev=625



I think the idea is for someone to hold down the CTRL key if they don't want XUB to load. So the code enables interrupts, which will process a pending IRQ1 (because someone has already been holding down the CTRL key for many seconds), then the status of CTRL can be checked.

You might also want to look at the larger source that lets the user input a regular keystroke to pick A drive, C drive, etc.

Thanks for your reply.

After reflection, I did remember that of course, XTIDE BIOS really start in the Boot interrupt that is executed at the end of the BIOS.
So, everything is setup at that time.

I will do the same, a version that hook the boot IRQ and start the bios from there.
The only problem is that It will not work if an XTIDE BIOS is executed after the PicoMEM BIOS.

I spent a huge amount of time to have my board "Starting" to work on 5150, Its ISA timings are faster than on the Amstrad PC, and I can't use ALE easily, so I modified the code to not use it.
I think I still need to reduce the reaction time to by 10/20 to have it stable...

 

[sergey]

A few feature requests for the XTIDE Universal BIOS:

• Automatic CPU detection, particularly for 8088 vs. V20, resulting in a single XT image
  • It is trivial to detect 8086/8088 vs. V20/V30, for example, using the AAD instruction with an argument other than 0xA
  • The CPU-specific code is very short - pretty much limited to IdePioBlock.asm. There is also some CPU-specific code in IdeTransfer.asm, but I think that code is being used only once per block, and it appears that the performance benefit of using more advanced instructions is minimal (maybe I am wrong?!). So supporting both CPUs wouldn't significantly increase the image size
  • The detection can either done once, e.g. at the BIOS initialization, storing the CPU type or a dispatch table in the XT-IDE BIOS data area, or on the fly. Again, it is very simple to detect 8088 vs. V20, and the performance overhead is minimal
• Support Flash ROMs other than SST39SF0x0
  • Fairly simple to implement - I have implementation in my 8088 BIOS and in the stand-alone xiflash utility
  • Generally two types of flash devices: (1) Requiring page erase / byte program (SST39SF0x0, Am29F01x0) and (2) Automatic page erase / page program (AT29C010, W29EE011, SST29EE010/GLS29EE010)
• Define and document the format of the configuration area. Move checksum correction byte into the configuration area
  • This will allow 3rd party utilities to make modifications to the configuration
  • Would likely require adding the configuration structure version number, and also some considerations to keep the data structure backward compatible
  • I am thinking about adding functionality to configure XTIDE in the built-in setup in my 8088 BIOS or Multi-Floppy BIOS Extension
• Integrate the configuration utility into XTIDE Unversal BIOS
  • Shouldn't take that much space. Should fit in 16 KiB ROM image
• It might be a good idea to combine XTIDE Universal BIOS and Multi-Floppy BIOS extension. This would eliminate the issues related to what BIOS extension gets initialized first, and also will provide the users single set of configuration tools

 

[Krille]

Automatic CPU detection, particularly for 8088 vs. V20, resulting in a single XT image

It is trivial to detect 8086/8088 vs. V20/V30, for example, using the AAD instruction with an argument other than 0xA
The CPU-specific code is very short - pretty much limited to IdePioBlock.asm. There is also some CPU-specific code in IdeTransfer.asm, but I think that code is being used only once per block, and it appears that the performance benefit of using more advanced instructions is minimal (maybe I am wrong?!). So supporting both CPUs wouldn't significantly increase the image size
The detection can either done once, e.g. at the BIOS initialization, storing the CPU type or a dispatch table in the XT-IDE BIOS data area, or on the fly. Again, it is very simple to detect 8088 vs. V20, and the performance overhead is minimal

Yes, CPU detection is easy, but that's not the problem. The CPU-specific code is almost exclusively there to reduce size, not to increase performance. (The exception is the transfer functions in the files you linked to.) If you search the list files (with all macros expanded) for USE_186 you'll find that there's a lot of them sprinkled throughout the BIOS, not just in the transfer functions. So there's no point in adding a CPU detection routine (and dispatch tables etc) because it would require major changes all over the project and it would only result in a larger BIOS that runs slower for everyone. So this is a hard no from me. (Adding CPU detection could be useful however, to be able to warn a clueless user that they are using the wrong build. But then again, I guess very few people would need that kind of hand holding - it would probably just annoy anyone intentionally using the wrong build.)

Support Flash ROMs other than SST39SF0x0

Fairly simple to implement - I have implementation in my 8088 BIOS and in the stand-alone xiflash utility
Generally two types of flash devices: (1) Requiring page erase / byte program (SST39SF0x0, Am29F01x0) and (2) Automatic page erase / page program (AT29C010, W29EE011, SST29EE010/GLS29EE010)

This is a great idea! I would love to add support for more types of flash ROMs. The problem here is that I have very little free time and would need to acquire the ROM types you mentioned (and probably additional hardware) for testing purposes. However, if someone sends me a patch I'd be happy to add it.

Define and document the format of the configuration area. Move checksum correction byte into the configuration area

This will allow 3rd party utilities to make modifications to the configuration
Would likely require adding the configuration structure version number, and also some considerations to keep the data structure backward compatible
I am thinking about adding functionality to configure XTIDE in the built-in setup in my 8088 BIOS or Multi-Floppy BIOS Extension

Everything you need is in RomVars.inc and Version.inc. No need to move the checksum byte(s) since you can just multiply the third byte with 512 and calculate the checksum for that whole range. (Far easier in my opinion.) Note the special case with 8 kB builds that use 3 checksum bytes for compatibility with 3Com 3C503 cards. Also note that for each IDEVARS struct you'll need to identify the device type first since the virtual serial device uses the struct differently from the rest of the device types.

Integrate the configuration utility into XTIDE Unversal BIOS

Shouldn't take that much space. Should fit in 16 KiB ROM image

I do think you're a wee bit too optimistic here. If you manage to implement all of the functionality of XTIDECFG (except file handling) into the ~5 kB free ROM space then I'll be extremely impressed. Unless I'm misunderstanding you and you meant that all of those 16 kB would be used by the configuration program?

It might be a good idea to combine XTIDE Universal BIOS and Multi-Floppy BIOS extension. This would eliminate the issues related to what BIOS extension gets initialized first, and also will provide the users single set of configuration tools

Yeah that sounds like a good idea as well. Do you have anything specifically in mind?

 

[boggit]

Two newbie questions:

1. I have an AT28C64B in my XT-CF-Lite 4.1. Whenever I try to flash the EEPROM, it doesn't work when I choose EEPROM type 2864. I then go through the list of various types, none of which work, and then, when I try 2864 again, it works. Why is this?

2. When updating my BIOS configuration (for example, changing the boot settings), is it better to load from (and save to) file or to load from (and save to) EEPROM?

 

[boggit]

Two newbie questions:

1. I have an AT28C64B in my XT-CF-Lite 4.1. Whenever I try to flash the EEPROM, it doesn't work when I choose EEPROM type 2864. I then go through the list of various types, none of which work, and then, when I try 2864 again, it works. Why is this?

2. When updating my BIOS configuration (for example, changing the boot settings), is it better to load from (and save to) file or to load from (and save to) EEPROM?

Anyone?

 

[modem7]

I have an AT28C64B in my XT-CF-Lite 4.1. Whenever I try to flash the EEPROM, it doesn't work when I choose EEPROM type 2864. I then go through the list of various types, none of which work, and then, when I try 2864 again, it works. Why is this?

More information required:

Explain "doesn't work". What is the error message?

If the following is not the exact sequence used to see the error, then what is? The exact sequence is required for others to be able to reproduce the symptom.

1. Run XTIDECFG.EXE
2. Arrow down to {Load BIOS from file}.
3. {ENTER} key.
4. Navigate to the desired BIN file then press the {ENTER} key.
5. {ESC} key.
6. Arrow down to {Flash EEPROM}.
7. {ENTER} key.
8. Arrow down to {Start flashing}.
9. {ENTER} key.

( Observation: The 2864 is the default value for EEPROM type, and therefore, 2864 does not need to be specifically chosen. )

 

[modem7]

When updating my BIOS configuration (for example, changing the boot settings), is it better to load from (and save to) file or to load from (and save to) EEPROM?

Assumption: The BIOS presently loaded in the EEPROM is not corrupt/damaged in some way.

For simply a configuration change, the only disadvantage that I can see to {load BIOS from file} is that you may have forgotten that say, six months ago, you changed some other setting.