• Please review our updated Terms and Rules here

XT-FDC project level of interest

I uploaded an updated image - version 2.1b. It has the fixed print subroutine implementation. Please give it a try...
Confirmed as fixed. Thanks.

One issue that took no time at all was something seen by ibmapc on his early IBM 5160. That was the POST errors of:
F6600 ROM
F8600 ROM
FA600 ROM
FC600 ROM
Symptom cause found. The IBM 5160 (and later 5150) POST is coded such that it requires that the "ROM size" byte in BIOS expansion ROMs be a multiple of 2 KB. The ROM size byte in Sergey's BIOS is presently set to 0F, a value corresponding to "8 KiB - 512 bytes (for configuration)".

Symptom disappeared after I changed the byte to 0C (6 KB) and then adjusted a byte within the 6 KB to effect a 00 checksum.

I remember that there was a similar problem with someone elses BIOS expansion ROM. The problem it causes is that the POST fails to detect other BIOS expansion ROMs in the address space that follows.
In the 11/08/82 BIOS for the 5160, the subject symptom will be an additional problem that results.
 
Symptom cause found. The IBM 5160 (and later 5150) POST is coded such that it requires that the "ROM size" byte in BIOS expansion ROMs be a multiple of 2 KB. The ROM size byte in Sergey's BIOS is presently set to 0F, a value corresponding to "8 KiB - 512 bytes (for configuration)".

Symptom disappeared after I changed the byte to 0C (6 KB) and then adjusted a byte within the 6 KB to effect a 00 checksum.

I remember that there was a similar problem with someone elses BIOS expansion ROM. The problem it causes is that the POST fails to detect other BIOS expansion ROMs in the address space that follows.
In the 11/08/82 BIOS for the 5160, the subject symptom will be an additional problem that results.

Thank you for debugging!
It looks like my idea of not checksumming the configuration space doesn't work well. The other BIOS that you're mentioning is the Turbo XT BIOS by Anonymous. It has a bug, that causes it to fail to detect any BIOS extension ROMs following BIOS extension with a size that is not a multiple of 2 KiB.

I will update the Floppy BIOS configuration utility to calculate and adjust its checksum.
 
Experimentation in regard to the symptom of:
With IBM 5160 motherboard, XT-FDC boots from a 720 KB diskette, but not a 1.44 MB diskette

IBM 5160 - 256K MOTHERBOARD - BIOS 11/08/82

Configuration:

* Early IBM 5160 with motherboard BIOS at 11/08/82 revision.
* Only cards are the XT-FDC and IBM CGA.
* XT-FDC ROM at D0000.
* Connected to the primary internal connector (P18) of XT-FDC is only one 1.44M drive. Nothing on other connectors.
* Sergey BIOS at version 2.1d
* Sergey BIOS configured for a 1.44M as only floppy drive ("Drive 0: 1.44 MB, 3.5", #0 on FDC 1")
* Two 1.44M boot diskettes, of MS-DOS 6.21, and IBM-DOS 3.30

In that configuration, the XT-FDC can boot from either of the 1.44M boot diskettes.

IBM 5160 - 256K MOTHERBOARD - BIOS 01/10/86

Upgraded motherboard BIOS chips to second revision, 01/10/86. That was the only change.
Power on.
After a while the Sergey BIOS sign-on message is displayed and the 1.44M drive LED comes on about the same time.
I see the "Press F2 to run Multi-Floppy BIOS to ..." message, but do not press F2.
The 1.44M drive LED momentarily turns off for a split second.
After a short while, I then see "Boot failed, error 02 ..."

If I power off/on (10 seconds in between) and then quickly insert the second 1.44M boot diskette, there is no symptom change.

If I power off/on (10 seconds in between) and then quickly insert a 720K boot diskette, the XT-FDC boots from that.

IBM 5160 - 256K MOTHERBOARD - BIOS 05/09/86

Upgraded motherboard BIOS chips to final revision, 05/09/86. That was the only change.
Same symptoms as second revision BIOS.


Put the original BIOS chips back into the motherboard, and the XT-FDC regains the ability to boot from a 1.44M boot diskette.
This is the same as what I see with the Multi Unique floppy controller card.
 
Experimentation in regard to the symptom of:
With IBM 5160 motherboard, XT-FDC boots from a 720 KB diskette, but not a 1.44 MB diskette

modem7, thank you for testing again!

I have a suspicion that IBM BIOS might be overwriting INT 1Eh (diskette parameter table) vector after BIOS extensions initialization and before boot.
I uploaded yet another version of my floppy BIOS, that updates the INT 1Eh vector before trying to boot - version 2.1e.

Can you please give it a try?
 
I have a suspicion that IBM BIOS might be overwriting INT 1Eh (diskette parameter table) vector after BIOS extensions initialization and before boot.
I uploaded yet another version of my floppy BIOS, that updates the INT 1Eh vector before trying to boot - version 2.1e.

Can you please give it a try?
No change.
 
I just had a play with 2.1e floppy bios and found the same as modem7.

IBM XT 5160 with final revision motherboard bios.
16-bit IDE / Floppy controller with IDE disabled.
XT-IDE Rev 1 card flashed with 2.1e floppy bios.
VGA Video Card
1.44 3.5" floppy drive as A:
360k 5.25" floppy drive as B:
No other cards installed.

Machine boots from a 720k floppy disc but will not boot from a 1.44 floppy disc, If i try and boot from a HD floppy i get the error: " Boot Failed, Error 02. Press F for the original IPL or any key to try again... " Pressing any key to try again fails and machine goes into Basic, but if i change the HD floppy for a 720k the machine then successfully boots.

I do like the configuration utility :) nice one.
 
I just had a play with 2.1e floppy bios and found the same as modem7.

This puzzles me... could it be that BIOS replaces INT 13h handler after extension ROM initialization? That is not impossible but at least weird... and when how hard drive BIOS extension gets installed?

I will debug it more during the coming week. I should be getting an 5150 motherboard, or alternatively I can try putting the original IBM XT BIOS into my Turbo XT clone board.
 
I don't know if this helps in any way but if there are any incompatibilities with XTIDE Universal BIOS then maybe this will help.

During ROM scan, XTIDE Universal BIOS installs INT 19h handler and does nothing else. Drive detection and rest of the initialization is done on INT 19h.

When processing INT 19h, XTIDE Universal BIOS makes copy of existing INT 13h handler (stored to RAM area where DPTs are created). INT 13h handler is copied to 40h only if existing 40h handler is not found. XT builds have very simple check: if INT 40h handler segment is C000h or above, then existing 40h handler is assumed to be present and it is not replaced. AT builds have more complex check (comparing results from INT 13h, AH=08h and INT 40h, AH=08h for drive 0).

XTIDE Universal BIOS detects number of floppy drives by reading equipment WORD from BDA (XT builds) or by calling INT 40h, AH=08h for drive 0 (AT builds). Number of floppy drives is used to determine drive letters for hotkeys and to display all floppy drives in boot menu. Floppy drive types for boot menu are determined by calling INT 40h, AH=08h. It it is not supported, then boot menu assumes the drive is 5.25" or 3.5" DD drive.

Before booting, XTIDE Universal BIOS replaces INT 19h hander. The new handler properly resets the system. This is done since some old software try to reset the system by calling INT 19h.
 
I often wish i tried harder in my younger days and continued to learn to program in assembly, now at the wrong side of 50 it gives me brain ache, You guy's are doing a fantastic job :)

Today i tested my IBM PC 5150 with 2.1e floppy bios.

IBM PC 5150 with 64kb - 256kb motherboard and final revision motherboard bios.
16-bit IDE / Floppy controller with IDE disabled.
XT-IDE Rev 1 card flashed with 2.1e floppy bios.
VGA Video Card
1.44 3.5" floppy drive as A:
360k 5.25" floppy drive as B:
No other cards installed.

The machine successfully boots using either a 1.44 Mb or 720 kb floppy boot disc, However i do get 4 ROM error's on boot up but this doesn't stop the machine booting up successfully:
<code>
FDC 1 at 03F0, IRQ6, DRQ2
Drive 0: 1.44 MB, 3.5", #0 on FDC 1: 360 Kb, 5.25", #1 on FDC 1
Bios extension is installed on INT 13
F660 ROM
F860 ROM
FA60 ROM
FC60 ROM
Press F2 to run the multi-configuration utility...
Starting MS-DOS
</code>

Removing the 4 BASIC chips makes no difference, The machine successfully boots from a 1.44 floppy still showing those ROM error's.

EDIT: Re: Modem7's post #421, I changed the "ROM Size Byte" to 0C but not sure how to get the checksum to 00 so left it as is, My IBM PC 5150 now successfully boots from a 1.44 floppy disc as before but now with no ROM Error's.


This puzzles me... could it be that BIOS replaces INT 13h handler after extension ROM initialization? That is not impossible but at least weird... and when how hard drive BIOS extension gets installed?

I will debug it more during the coming week. I should be getting an 5150 motherboard, or alternatively I can try putting the original IBM XT BIOS into my Turbo XT clone board.
 
Last edited:
During ROM scan, XTIDE Universal BIOS installs INT 19h handler and does nothing else. Drive detection and rest of the initialization is done on INT 19h.

When processing INT 19h, XTIDE Universal BIOS makes copy of existing INT 13h handler (stored to RAM area where DPTs are created). INT 13h handler is copied to 40h only if existing 40h handler is not found. XT builds have very simple check: if INT 40h handler segment is C000h or above, then existing 40h handler is assumed to be present and it is not replaced. AT builds have more complex check (comparing results from INT 13h, AH=08h and INT 40h, AH=08h for drive 0).

XTIDE Universal BIOS detects number of floppy drives by reading equipment WORD from BDA (XT builds) or by calling INT 40h, AH=08h for drive 0 (AT builds). Number of floppy drives is used to determine drive letters for hotkeys and to display all floppy drives in boot menu. Floppy drive types for boot menu are determined by calling INT 40h, AH=08h. It it is not supported, then boot menu assumes the drive is 5.25" or 3.5" DD drive.

Before booting, XTIDE Universal BIOS replaces INT 19h hander. The new handler properly resets the system. This is done since some old software try to reset the system by calling INT 19h.

aitotat, thank you for this information! I will try the late initialization approach: install INT 19h during the ROM scan, install all other interrupt vectors in INT 19h handler.

Still need to figure out how to make this to play nicely with XT-IDE Universal BIOS and with XT & AT hard drive BIOS extensions.

Apparently if using INT 19h handler I want it to run before XT-IDE Universal BIOS's one, which means that Multi Floppy BIOS should be initialized after XT-IDE Universal BIOS (so the Multi Floppy BIOS will be first in the chain). Also there is a question if the Multi Floppy BIOS's INT 19h should try booting from floppy... It apparently should if no hard drive extension was installed. But what if a hard drive extension is installed? Should it still attempt to boot from the floppy first?
 
Removing the 4 BASIC chips makes no difference,

What is hapening is that the POST now thinks that the four BASIC ROMs start at different addresses to what they actually start at.
So, if we take the first one as an example:
* POST thinks that it starts at F6600 instead of the ROM's actual address of F6000.
* POST calculates the 8-bit checksum of the 8 KB block starting F6600 and displays "F660 ROM" because the block checksum is not 00.

That is why removing the BASIC ROMs makes no difference.

Note that in the 5160, BASIC ROMs do not exist. The code from each one has been lumped together spanning both chips U18 and U19. Pretty much, the same "check BASIC ROMs" code from the 5150 has been used.
 
EDIT: Re: Modem7's post #421, I changed the "ROM Size Byte" to 0C but not sure how to get the checksum to 00 so left it as is, My IBM PC 5150 now successfully boots from a 1.44 floppy disc as before but now with no ROM Error's.
Fixing that will be on Sergey's to-do list.

In the meanwhile, use a hex editor (includes DEBUG) to make the following changes to the version 2.1e BIOS. It is only applicable to the version 2.1e BIOS

1. Change byte at offset 0002 from 0F to 0C
2. Change byte at offset 15E8 from 2E to 00
3. Change byte at offset 15E9 from 00 to B4

The last two steps are shortening the message "Press F2 to run the Multi-Floppy BIOS configuration utility..." by one byte (i.e. two dots instead of three), and then using the spare byte as the checksum byte.
 
.... It seems that no matter where I put it my 360k drive, it prevents the 3.5" drive from using 1.44M media. In other words, if a 360k drive is connected anywhere, and a 3.5" drive is connected, either on the same cable or the other, then it must be configured as 720k. ...
I did some more testing tonight. After modifying sergey's BIOS ver 2.1e as modem7 suggested, the ROM errors did indeed go away. Still unable to use 1.44M media when 360K drive is attached. I then tried a different 360k drive, a Shugart SA455 and the problem goes away. So, with the 5155's stock drive attached, a Qumetrak 142, the 3.5" drive only works when configured as 720k.
With a Shugart SA455 attached, the 3.5" drive works as a 1.44M or a 720K drive.
I would prefer to use the original Qumetrak 142 for the internal drives to keep the original appearance of the 5155. So, does anyone have any idea what the difference might be between these two drives that could cause this behavior? Could it be something to do with DENSEL(pin 2 on the connector)? What does DENSEL do? Could the Qume be modified to behave like the Shugart?
 
So, I tried the "brute force" approach. I figured one or more of the signals is getting interupted by the Qume 360k drive, keeping the 3.5" drive from working in High Density mode. So I disconnected pin 2 on the internal cable, connected to the Qume. No difference. So, I thought, besides the grounds and N/Cs the only non-essential pin is #34, DSKCHG. And, what do ya know, with pin 34 disconnected on the 360k drives, it now works. I can have my two 360k QumeTrak drives connected to the internal connector and a 3.5" 1.44M on the external connector and can boot from any of them as long as I use IBM 1982 BIOS or Plasma's "Super PC/Turbo XT BIOS 2.5".
The only glitches right now on my system are as follows:
When using either of the 1986 versions of IBM BIOS the 3.5" drive only works as 720k
Can only Format the 3.5" drive as 144M if it is set as logical drive 0. When any other drive is set as logical drive 0, the format appears to go ok untill the very end. Then the error "Unable to write BOOT" comes up and the disk is unreadable.

Can anyone tell me what problems, if any, I might see having pin 34 disconnected on the 360k Drives?
 
Last edited:
So, I tried the "brute force" approach. I figured one or more of the signals is getting interupted by the Qume 360k drive, keeping the 3.5" drive from working in High Density mode. So I disconnected pin 2 on the internal cable, connected to the Qume. No difference. So, I thought, besides the grounds and N/Cs the only non-essential pin is #34, DSKCHG. And, what do ya know, with pin 34 disconnected on the 360k drives, it now works.
In the early days of the 5.25" floppy interface standard, pin 34 was optionally used for a READY signal (floppy drive is ready). Some 360K drives generate it and some do not, and some (like the JU-455-7) have a jumper to select the desired behaviour.
The IBM 5150 and 5155 and 5160, as supplied by IBM, do not care what is on pin 34. If you look at the IBM floppy controller supplied in the 5150/5155/5160, pin 34 is not connected. Accordingly, the floppy portion of the motherboard BIOS doesn't care.

With the introduction of the IBM 5170, pin 34 is used by the supplied floppy controller, and 1.2M drives are required to supply a DISK CHANGED signal on pin 34.
The rules for the IBM 5170 are:
* 1.2M drive: Must generate a DISK CHANGED signal on pin 34. The controller and motherboard BIOS expects that signal from 1.2M drives.
* 360K drive: Generate no signal on pin 34, not even a READY signal. Disconnect pin 34.

Like the 5170's floppy controller, the XT-FDC controller has pin 34 connected. The 5170 rules probably apply. I'm guessing that your Qume 360K drives generate a READY signal on pin 34, and that was confusing the XT-FDC, until you disconnected pin 34.
 
When using either of the 1986 versions of IBM BIOS the 3.5" drive only works as 720k
As far as I am aware, it is a booting problem only. For example, I boot from a 720K diskette, then substitute the 720K diskette for a 1.44M one. Operations (read/write) on that 1.44M diskette work as expected (over the full capacity of 1.44M).
 
Can only Format the 3.5" drive as 144M if it is set as logical drive 0. When any other drive is set as logical drive 0, the format appears to go ok untill the very end. Then the error "Unable to write BOOT" comes up and the disk is unreadable.
I don't see that. Please provide specifics of the hardware/software/configuration you have so that I can replicate the problem.
 
I don't see that. Please provide specifics of the hardware/software/configuration you have so that I can replicate the problem.

Thanks for your assistance Modem7. Here's the specs for my machine;
-IBM 5155 with original motherboard with NEC V20, IBM 08NOV'82 BIOS
-640k on motherboard
-CGA adapter
-XT_FDC with basic FDC and BOOT ROM only, no ROM drive. Internal and external connectors, BIOS 2.1e modified per post #432
-Two Qume QumeTrak 142 360k floppy drives attached to internal connector with pin 34 disconnected at controller end of cable. Last drive on cable, physical drive 0 has 150 ohm terminator.
-One Sony 3.5" 1.44M drive attached to external connector, physical drive 2.
-PC DOS 7

Do you think it would work better if the terminating resistor on the internal drive matched the 3.5" drive, which I believe is a 1k non-removable?
 
Last edited:
-IBM 5155 with original motherboard with NEC V20
Try taking the V20 back to an 8088.

-640k on motherboard
Also, "May 1986 Bios" from an earlier post of yours.

-XT_FDC with basic FDC and BOOT ROM only, no ROM drive.
What is the BIOS version on the XT-FDC? If 2.1e, is is 2.1e as obtained from Sergey's web site, or 2.1e modified per post #432 ?

Internal and external connectors
I don't have the external connector. I have the secondary internal connector (P2) in its place. I have to use that when trying to replicate isues.

Do you think it would work better if the terminating resistor on the internal drive matched the 3.5" drive, which I believe is a 1k non-removable?
No.
 
Back
Top