• Please review our updated Terms and Rules here

XT High density floppy code.

It seems to me that perhaps the XTFDC could have used a small serial EEPROM to store configuration data. The Microsolutions Backpack drive does this and many various NIC and EMS cards also do this. No necessity for patching code.
 
It seems to me that perhaps the XTFDC could have used a small serial EEPROM to store configuration data. The Microsolutions Backpack drive does this and many various NIC and EMS cards also do this. No necessity for patching code.

Some ATI VGA cards did that too.
 
If the sum is not zero, as detected by the PC's BIOS, no error message is produced--the ROM code is simply viewed as "noise" and is ignored.
Depends on the computer. For example, The POST in the IBM PC family generates an error. Examples follow.

IBM 5150 (IBM PC): "F800 ROM"
IBM 5160 (IBM XT): "F8000 ROM"

It seems to me that perhaps the XTFDC could have used a small serial EEPROM to store configuration data. The Microsolutions Backpack drive does this and many various NIC and EMS cards also do this. No necessity for patching code.
In the XTFDC that was produced by members of these forums, the (large) EEPROM stores both code and configuration data. I have sold my XTFDC, but I remember seeing something like 'Press xx to configure XTFDC" during the POST. Pressing the specified key would execute the configuration code in the EEPROM, and that code would fetch the XTFDC's configuration, also in EEPROM, presenting it on-screen. I would change the configuration as required then choose the option to save. The configuration code would then write the new configuration back to EEPROM.
 
Depends on the computer. For example, The POST in the IBM PC family generates an error. Examples follow.

IBM 5150 (IBM PC): "F800 ROM"
IBM 5160 (IBM XT): "F8000 ROM"

But that isn't in the "option ROM" area, is it? AFAIK, the 5150/5160 does not diagnose a malformed option ROM in paragraphs C000-D000).
 
But that isn't in the "option ROM" area, is it? AFAIK, the 5150/5160 does not diagnose a malformed option ROM in paragraphs C000-D000).

It does. My 5160, 1st revision BIOS does report a bad BIOS at least.
 
For PC and XT class machines that have a relatively large amount of free memory, then the use of the 2M-XBIOS driver is good because the drive types are specified in the CONFIG.SYS line that launches the driver. No reassembling and no ROM burning. More 2M-XBIOS information: http://www.minuszerodegrees.net/transfer/35_inch/2m-xbios.htm

In this example, you remove the existing floppy controller and replace it with the high-density one, then alter the C:\CONFIG.SYS to add the driver. But: Does the card work with low-density drives without the driver? I ask because I can envision a chicken-and-egg problem: If the hard drive develops a problem, you can't boot from floppy to fix it because the floppy won't work without the driver on the hard drive...
 
Last edited:
But that isn't in the "option ROM" area, is it?
A typo. The "F" should have been "C".

AFAIK, the 5150/5160 does not diagnose a malformed option ROM in paragraphs C000-D000).
In the POST of the 5150 and 5160, the search for BIOS expansion ROMs is done as two disctinct activities:
1. Video cards
2. Other cards

5150

Video cards: Search range C0000 - C7FFF in 2K increments. Report 'corrupted' BIOS expansion ROMs, e.g. "C000 ROM"

Other cards: Search range C8000 - F5FFF in 2K increments. Report 'corrupted' BIOS expansion ROMs, e.g. "C800 ROM"

5160

Video cards: Search range C0000 - C7FFF in 2K increments. Report 'corrupted' BIOS expansion ROMs, e.g. "C0000 ROM"

Other cards:
First BIOS searches range C8000 - F5FFF in 2K increments. Report 'corrupted' BIOS expansion ROMs, e.g. "C8000 ROM"
Later BIOS' search range C8000 - EFFFF in 2K increments. Report 'corrupted' BIOS expansion ROMs, e.g. "C8000 ROM"

Corruption scope

Of course, if the 'corruption' includes the first two bytes, the ROM does not get identified as a BIOS expansion ROM, and therefore not checked/reported.
 
In this example, you remove the existing floppy controller and replace it with the high-density one, then alter the C:\CONFIG.SYS to add the driver. But: Does the card work with low-density drives without the driver? I ask because I can envision a chicken-and-egg problem: If the hard drive develops a problem, you can't boot from floppy to fix it because the floppy won't work without the driver on the hard drive...
But being the professional IT people that we are, we would never put ourselves in the position of not being able to recover from an IT failure. Before implementing the solution, we would have developed a failure recovery plan, acquired necessary hardware and software in support of that plan, then tested the plan. :)
 
In this example, you remove the existing floppy controller and replace it with the high-density one, then alter the C:\CONFIG.SYS to add the driver. But: Does the card work with low-density drives without the driver? I ask because I can envision a chicken-and-egg problem: If the hard drive develops a problem, you can't boot from floppy to fix it because the floppy won't work without the driver on the hard drive...

Yes it will. It will also work with low-density disks in high-density drives.

You can also boot from a DR-DOS 7 high-density boot disk, even with no BIOS support. This will then allow you to access any other HD floppy disk.
 
The original card had jumpers read from 03F0h that set the drive type, for use on the multi-io I have assembled them into the ROM, so to change drive types you'll need to re-build. Is there a better way of doing this on an XT class machine that does not have CMOS ?

Crazy idea, you could use the XT motherboard switches 7 and 8 that normally sets number of drives (1-4), and then maybe "appropriate" switch 1 (is there an IPL/floppy installed) giving you 3 bits to describe your floppy drive configuration. It's only half of your drive type table but maybe the permutations could be pared down and you'd only have two ROM versions to swap?

Just a thought...
 
I'm trying to make this BIOS fit in 4096 bytes. There is a padding directive to make the ROM size exactly 8K:

Code:
times 07B1h    db      0FFh           ; Ensure size is romSizeK

if I remove it, the resulting binary is 4175 bytes long Almost there but I see that there is further padding with 0s in two more spots.

There are 50 bytes just before the DBT table:

Code:
new_int00E:    push    ax

... snip int 0E handler code ...

iret

times 32h db 0 <<<<<<< ??

;DBT - Disk Base Table (BIOS INT 13)
; 360K
DPT_360:    db    0DFh    ; specify byte 1; step-rate time, head unload time
... snip DPT  ...

and there are another 1691 bytes after the DMA chip programming data:

Code:
dma_bytes:    db      46h        ; function #2 read sec
        db      4Ah        ; function #3 write sec
        db      42h        ; function #4 verify sec
        db      4Ah        ; function #5 format track
        db     0FFh
        db     0FFh
       
times 69bh     db     0 <<<<<< to align the following code into 4k boundary ??

loc_1000:    push    ds
        push    es

but I really cannot understand the purpose of all that 0s Anybody is able to figure out this?

Thanks a lot
 
I'm trying to make this BIOS fit in 4096 bytes. There is a padding directive to make the ROM size exactly 8K:

Code:
times 07B1h    db      0FFh           ; Ensure size is romSizeK

if I remove it, the resulting binary is 4175 bytes long Almost there but I see that there is further padding with 0s in two more spots.

There are 50 bytes just before the DBT table:

Code:
new_int00E:    push    ax

... snip int 0E handler code ...

iret

times 32h db 0 <<<<<<< ??

;DBT - Disk Base Table (BIOS INT 13)
; 360K
DPT_360:    db    0DFh    ; specify byte 1; step-rate time, head unload time
... snip DPT  ...

and there are another 1691 bytes after the DMA chip programming data:

Code:
dma_bytes:    db      46h        ; function #2 read sec
        db      4Ah        ; function #3 write sec
        db      42h        ; function #4 verify sec
        db      4Ah        ; function #5 format track
        db     0FFh
        db     0FFh
      
times 69bh     db     0 <<<<<< to align the following code into 4k boundary ??

loc_1000:    push    ds
        push    es

but I really cannot understand the purpose of all that 0s Anybody is able to figure out this?

Thanks a lot
Interestingly if you define all of the conditional assembly sections (-D SECRET -D ALLOW_OVERWRITE -D DEF_DRIVES -D MODIFY_BOOT) you get a ROM that's 8,188 bytes (4 bytes shy of the full 8K). I'd assume those conditionals were put in by Prime who did the disassembly, so the original ROM would have been that full size OR that code was added. Perhaps the padding was put in to make sure there is just a little extra space to make sure that even with all options on it doesn't go over 8K? Would be interesting to compare it to the original ROM binary to see how it used the space, though doesn't seem like that was posted unless I'm missing it.

As for why it's 4125 bytes, maybe they just couldn't golf out the 29 bytes to make it fit in a 4K ROM OR they just had a surplus of 8K ROMs OR they had alternate builds enabling more features that weren't shipped on that particular card? Just spitballing now...

FK
 
Back
Top