• Please review our updated Terms and Rules here

XT High density floppy code.

P

prime

Experienced Member
Joined
Sep 20, 2009
Messages
153
Location
Coventry, UK
Hi all,

Here's the disassembled code from my XT floppy controller View attachment 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 ?

Enjoy.

Cheers.

Phill.
 
prime said:
Is there a better way of doing this on an XT class machine
Click to expand...
I don't think that "better" is the word to use. It's more about requirements and abilities.

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

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.
 
prime said:
Here's the disassembled code from my XT floppy controller.
Click to expand...

Good job!

prime said:
Is there a better way of doing this on an XT class machine that does not have CMOS ?
Click to expand...

A few ideas:

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.
 
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:
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:
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".
 
Malc said:
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".
Click to expand...


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.
 
CarlosTex said:
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.
Click to expand...


You need to patch the last byte of the bin file so it has the correct checksum,

run :
debug xtfdc.bin
from within debug :
g=106

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.

Cheers.

Phill.
 
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.
 
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.
 
The creation of the check sum requires non-standard action of
the assembler. Some assemblers aren't even capable of doing
it.
Dwight
 
Dwight, who uses an assembler to generate the checksum? I never have.

Some PROM programmers will do it, but the simplest is a little DEBUG script or utility.

I can post a bit of C code here for a utility if anyone is interested; it's not rocket science.
 
Yes, if anything, it's more of a linker's task. But with nasm you generally don't use a linker, but generate a binary blob directly from the assembler.
The most compatible way would be to use a separate tool to calculate the checksum after the ROM image is made, and then patch the checksum into the image.
That way you can just include the tool as the last step in your build script (which could just be a simple .bat file for DOS).
 
Malc, how's this:

Code: 
DEBUG (whatever your BIOS file is]
-a80
0822:0080 push cx
0822:0081 mov ch,[102]
0822:0085 xor ax,ax
0822:0087 mov cl,al
0822:0089 add cx,cx
0822:008B dec cx
0822:008C mov si,100
0822:008F lodsb
0822:0090 add ah,al
0822:0092 loop 8f
0822:0094 neg ah
0822:0096 mov [si],ah
0822:0098 pop cx
0822:0099 int 3
0822:009A

-g=80
-w
-q

I haven't tested it, but it should work.
 
Malc said:
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".
Click to expand...

Just out of curiosity, what does that look like? As in, what is the BIOS code running on? Is it a replacement/mod of the IBM BIOS or something completely different such as an ad-in card?
 
JFYI: There is also a sourcecode for the "800.COM" by Alberto Pasquale, another popular diskette driver (mostly in Europe).
It consumes very few memory as TSR.
Alberto was interviewed by Russian "Downgrade Magazine" and kindly gives sourcecode for public.
Unfortunately there is no English translation for this interview.

"Downgrade Magazine" 2015 N15 p.6
http://dgmag.in/N15/DowngradeN15b.pdf
(in Russian, google translation may help?)

Binaries and sourcecode
http://old-dos.ru/index.php?page=files&mode=files&do=show&id=243
 
In one of my machines i have an 8-bit HD floppy controller and dumped the bios to use in my other machines, i use either a ROM board / Boot ROM socket on a nic / 16-bit multi IO card with it's own boot rom / XT-IDE card ROM, Basically anywhere i can home the BIOS.

lutiana said:
Just out of curiosity, what does that look like? As in, what is the BIOS code running on? Is it a replacement/mod of the IBM BIOS or something completely different such as an ad-in card?
Click to expand...
 
prime said:
You need to patch the last byte of the bin file so it has the correct checksum,

run :
debug xtfdc.bin
from within debug :
g=106
Click to expand...


OK i tried this method but how can i see the checksum value that was left in the AL register?


Anyhow, all i needed to do in this BIOS was to edit the drive type and change the checksum. The drive type byte is at 02BAh and the checksum byte is at 1F66h. 1F66h is the exact last byte of the 16th and last 512 byte block.

Knowing this i was lucky enough that Phoenix BIOS reports how much bytes are off the checksum so with this cue i was able to get to the correct checksum byte manually. I've made a table based on the original from config.asm:



Code: 
                                     (02BAh)              (1F66h)
; drive A     drive B	              value 	         Checksum
;  360		360		        00h	             6Ah	
; 1200	 	360		        01h	             69h
;  720		360		        02h	             68h
; 1440		360		        03h 	             67h
;  360		1200		        04h	             66h
; 1200		1200		        05h	             65h
;  720		1200		        06h	             64h
; 1440		1200		        07h	             63h
;  360		720		        08h	             62h
; 1200 		720		        09h	             61h
;  720		720		        0Ah                  60h
; 1440 		720		        0Bh	             5Fh
;  360		1440		        0Ch	             5Eh
; 1200		1440		        0Dh	             5Dh
;  720		1440		        0Eh	             5Ch
; 1440		1440		        0Fh	             5Bh
 
Last edited:
You must log in or register to reply here.
Back
Top