February 5th, 2013, 10:49 AM
XT High density floppy code.
Here's the disassembled code from my XT floppy controller xtfdc.zip I've commented it as fully as I can and it is at the stage where it can be re-assembled with NASM and works on both the original hardware and on a generic 16 bit multi-io card in an 8 bit slot.
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 ?
February 5th, 2013, 12:44 PM
I don't think that "better" is the word to use. It's more about requirements and abilities.
Originally Posted by prime
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/tran...h/2m-xbios.htm
However, for PC and XT class machines where free memory is low, and the machine owner does not want to lower it any further, then the owner would need to use a ROM based solution. Your disassembled (and modified) BIOS code is one example. Sergey's BIOS code is another.
February 5th, 2013, 02:30 PM
Originally Posted by prime
A few ideas:
Originally Posted by prime
1. If the BIOS extension ROM is stored in an EEPROM chip (e.g. 28C64) it is possible to store the configuration in the same EEPROM chip. In my floppy BIOS extension I implemented a built-in configuration utility that can write configuration to the EEPROM.
2. Even if BIOS is not stored in EEPROM, the configuration can be stored in the system RAM which will work until the next reboot.
3. It might be possible to auto-sense the diskette type, pretty much the same way 1.2 MB / 720 KB / 360 KB media is auto-detected. There are a few issues here: A diskette formatted with a maximal supported capacity needs to be present in the drive at the BIOS extension initialization time to perform the proper auto-detection. Alternatively it is possible to have INT 13h / AH=08h to return a more capable drive type (e.g. type = 4 / 1.44 MB), but then I am not sure that 1.2 MB drives will be supported properly. For example DOS format utility uses INT 13h / AH = 08h to determine the default media type. While it is possible to specify media (or number of tracks/sectors) manually, it very well could be that sure FORMAT will refuse to format 1.2 MB disk in 1.44 MB drive.
4. (An addition to 3) Probably the main purpose of the extended BIOS is to boot from the diskette. Once in DOS a small utility (can be in a .SYS format) can be used to set the actual floppy configuration.
April 8th, 2013, 07:08 PM
I want to know. Is someone be willing create a bios ROM for me? (so i can write it on my own to EEPROM chip)
Its for my kouwell KD-530D floppy drive controller iam still havent fount a working bios for it..
It needs to be auto sensed type of bios that willing detect the drive by its self.
My card doesnt have a option onboard for choosing seperate drive types..
I only can put the dip switch on or off..
When on it should only detect a 360KB or 720KB floppy drive.
When off it should only detect high capacity drives 1.44MB floppy or 1.2MB floppy.
Iam not that tecnical to write my own bios rom for it.
Last edited by Robin4; April 8th, 2013 at 07:13 PM.
THE BIOS MASTER
January 11th, 2017, 03:01 AM
Hi, i'm bumping this thread because this BIOS seems to be useless. Everytime i try to use it it gives bad checksum errors. I tried both assembling a file myself and using the binary file that comes in the package. I tried with Plasma's Turbo XT BIOS, Phoenix, AMI and original IBM XT BIOSes and they all report bad checksum.
I took a look into the assembly code but my knowledge is so limited that there's nothing i can do. Which is a shame, cause setting a different floppy configuration is really easy with this BIOS.
Can anyone take a look into the source and see what's wrong? I don't understand why checksum is not being calculated correctly.
EDIT: I even tried a few more BIOSes in PCem: Amstrad, Olivetti M24, all seem to report bad checksum for this BIOS. But curiously enough DTK/ERSO BIOS reports no error and actually executes BIOS code. I think it's safe to assume then that DTK/ERSO BIOS is a piece of crap.
Last edited by CarlosTex; January 11th, 2017 at 03:22 AM.
January 11th, 2017, 04:06 AM
I use the DTK HD floppy bios in my XT 5160 with no problems except for the fact that i can not format a 1.44M floppy but there are utilities to get around that. I use "SetDrive".
January 11th, 2017, 04:13 AM
Originally Posted by Malc
I have no experience with DTK High Density Floppy BIOSes, i was only referring to the fact that DTK/ERSO system BIOS does apparently not detect bad checksums in extension ROMs. I don't think the HD Floppy BIOS being discussed in this thread is DTK.
January 11th, 2017, 06:38 AM
Originally Posted by CarlosTex
You need to patch the last byte of the bin file so it has the correct checksum,
from within debug :
This will run the checksum calculator and leave the checksum in the AL register, patch this into the last 0 byte of xtfdc.bin and you should be good to go.
You'll obviously need to do this again if you re-assemble the ROM file, for example to change the drive types.
January 11th, 2017, 07:50 AM
OK i'll try that thanks.
I just find it a bit weird that it doesn't correct itself when assembled.
Anyway i only need to change drive types which means that the range of bytes i'll change is small, so maybe i can add or subtract the checksum directly with a hex editor. What is the exact address of the checksum byte?
I noticed that the byte for drive configuration is at 2BAh.
January 11th, 2017, 08:32 AM
The checksum byte (actually the complement of the arithmetic sum) is located in the last byte as described in the BIOS extension header, which may or may not be the last byte of of the ROM. In other words, your option ROM starts off with the bytes 55 AA nn, where nn is the number of 512-byte blocks occupied by the ROM code. The checksum is in the last byte of the last 512-byte block and is computed such that when all of the specified bytes in the option ROM are summed, modulo 256, the result is 0. That means that the checksum is the complement of the arithmetic sum of all of the bytes before it.
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.