• Please review our updated Terms and Rules here

XT-FDC project level of interest

The code controlling the XT-FDC is the POST and BIOS code in the 5170 motherboard, code that 'knows' all about 1.2M drives and disks.

Compared to the IBM floppy controller supplied in the 5170, maybe the 8477/8473 chips require extra ininitialisation and/or support code for HD operation.

Hi
Have you tried Sergey's or Chuck's BIOS? I suspect there is some "secret sauce" in it for HD floppy drives.

Thanks!

Andrew Lynch

PS, I just barely recall that there is a fundamental difference between the PC/XT FDC and the AT FDC which may explain why it is not working. For certain, the two are not interchangeable and I think it has to do with the DMA. Maybe Chuck knows for sure.
 
Last edited:
Well, the XT FDC doesn't have variable data rates (except for the later ones) and the XT doesn't have CMOS memory to record the drive types. Otherwise, it's the same controller using the same port addresses (3Fx), IRQ (6) and DMA (2).
 
Chuck may I ask when will be XT-FDC BIOS ready ? I am right now playing with 16-bit MultiIO card in a PC/XT so I would like to build one myself tailored to my floppies. (I somehow suppose it will work with 16bit cards and it will be configurable at build time)
 
It's in the works, but I'm a bit snowed under with regular work, so be patient. All legacy floppy controllers are 8-bit, right from the 5150 to the last P4 system with floppies. The interface simply hasn't changed measurably since the 5170.
 
It's in the works, but I'm a bit snowed under with regular work, so be patient. All legacy floppy controllers are 8-bit, right from the 5150 to the last P4 system with floppies. The interface simply hasn't changed measurably since the 5170.

Chuck, as I said feel free to reuse my code. It needs some minor modifications (basically to make it an extension ROM - right now it is built in the BIOS). So I guess:
- Initialization / installation code - should install itself either on INT 13h or INT 40h (any ideas how to detect which vector? As I understand it should be INT 40h if hard drive extension is installed, or INT 13h otherwise)
- Configuration - right now it uses configuration stored in AT-like CMOS/NVRAM, it should be replaced with configuration bytes stored in the ROM (and perhaps it should have a configuration utility).
- All regular extension ROM stuff (signature, length, make sure that checksum == 00h)

Probably I'll do it eventually myself, but I am also busy at work/home.

BTW I tested my code yesterday with 3.5" / 2.88 MB drive and disks, and the FDC controller I built (based on PC8477B similar to what you're trying to build), and it works just fine.
 
I created a floppy BIOS extension ROM using the code from my BIOS and posted it here (look for floppy_bios-0.7e.bin in the attached files section at the bottom of the page):
http://www.malinov.com/Home/sergeys-projects/isa-fdc-and-uart

I did some minimal testing and I am able to boot from a 1.44 MB drive using a 1.44 MB diskette on an XT clone. I also can read 1.2 MB diskettes on it. I tested it on my Xi 8088 board (http://n8vem-sbc.pbworks.com/w/page/59325872/Xi 8088) and it works too.

Some notes:

- ROM's drive configuration is: 1st drive: 3.5"/1.44 MB, 2nd drive: 5.25"/1.2 MB. You have two choices if you want a different configuration:
1) Drop me a note, and I'll compile the image according to your configuration
2) Patch the ROM. Floppy drive types are stored in bytes 06h - 09h (06h - first drive, 09h - forth drive). Byte 05h is used to correct the checksum. When changing floppy configuration in ROM make sure to update this byte, so that the checksum (sum of all bytes) of the image is 00h. Either do some hexadecimal math or use your programmer's software checksum output (my programmers software displays 16-bit checksum, in this case only lower 8-bit matter).
Floppy drive types (configuration bytes' values) match INT 13h AH=08h results (drive type - BL) and defined as follows: 00h - no floppy, 01h - 360 KB, 02h - 1.2 MB, 03h - 720 KB, 04h - 1.44 MB, 06h - 2.88 MB

- I started adding some support for 4 floppy drives, but it is not complete yet (2 drives are supported now)

- It looks like DOS (at least MS-DOS 6.22) uses CMOS in addition to INT 13h to determine floppy drive configuration. At least on my Xi 8088 board it behaved funky when CMOS settings didn't match the ROM drive configuration. I need to do some more testing on this...

- BIOS will install itself on INT 13h if INT13h vector is the original BIOS one (the vector's offset is 0EC59h), otherwise it will install itself on INT 40h (this assumes that HDD BIOS extension ROM was installed and redirected original INT 13h to INT 40h). Probably there are some problems with this logic, but it is the simplest approach I could think of. Please let me know if you have any better ideas.

- No warranties. This is a mostly untested code, it might ruin you floppy disks (so don't use any disks with valuable information). It could produce some unexpected results. But most likely it won't damage the hardware :)
 
Sergey, you're well along on this. Why not simply add a "Press Fx for configuration" prompt during bootup initialization and include code to update the EEPROM drive types? One issue with 4-drive support is the lack of dedicated BIOS RAM-area locations to record things such as datarate, double-stepping, media type detected, etc. flags.

(I'm assuming that you're using the standard 5170 BIOS dedicated RAM cells)

-----------------
I'm currently wrestling with a client whose potential workload is huge--I'll probably be at this through the end of the year. So what I can do will be very limited.
 
Sergey, you're well along on this. Why not simply add a "Press Fx for configuration" prompt during bootup initialization and include code to update the EEPROM drive types?

I actually started working on that too. But unfortunately the only AT28C64 I have appears to be dead (not sure why, but probably it has something to do with the wrong programmer configuration). So I am doing all the testing using a flash chip.

One minor complication with updating the EEPROM chip in the system is that the EEPROM update code needs to be relocated to RAM since EEPROM does not read correctly while write operation is performed.

One issue with 4-drive support is the lack of dedicated BIOS RAM-area locations to record things such as datarate, double-stepping, media type detected, etc. flags.

(I'm assuming that you're using the standard 5170 BIOS dedicated RAM cells)

This is a good point. I haven't got that far - I only added updating the equipment bits in the BIOS data area (and configuration of 4 drives in the EEPROM configuration utility that I've started to write).
Any ideas how other 4 drive controllers implement that? My guess would be that 4-drive controllers never supported anything above 360KB (or maybe 720KB) :)
 
That's essentially the nub of the problem. The 5170 uses only 40:3E, 40:3F, 40:8B and 40:8F-40:95 for its work areas. So, if you need to keep current cylinder information around, that's 4 bytes right there. I figure 3 bits per drive for media, if you want to also support 2.88--1 bit for "I know what this is" and 2 bits for datarate, and assume that if you've got 300Kbps data rate, you're double-stepping. Maybe it can be done; I haven't mapped things out.
 
OK, I'll postpone the 4 drives support for the later time. Meanwhile I purchased some AT28C64B and will work on the built-in configuration utility.
BTW, Avnet Express sells AT28C64B for $2.68, other parts (if Avnet has them in stock) are cheaper too, at least compared to Mouser and Jameco.

I posted an updated version (1.0b1) of the floppy BIOS along with the source code here:
http://www.malinov.com/Home/sergeys-projects/isa-fdc-and-uart
 
Last edited:
Sergey I tested previous version 0.7e in a Commodore PC20-II XT machine with 16bit MultiIO card together with CF card and http://www.vintage-computer.com/vcforum/showthread.php?33783-Software-only-XT-IDE-Controller. It works like a charm. Both A: 1.44MB and B: 1.2MB drives working. What is new in this version ? Should I upgrade ?

Thanks for testing. It shouldn't be any functionality difference between these versions. Newer version has some changes to enable built-in configuration utility (this is work in progress, and not available yet).
 
Have you tried Sergey's or Chuck's BIOS? I suspect there is some "secret sauce" in it for HD floppy drives.
A few posts back, I reported that whilst the prototype XT-FDC card worked well in my XT clone machine, I could not get it to work in my IBM AT (5170). I was expecting the AT's IBM authored motherboard BIOS being able to read/write 1.2M and 360K drives connected to the XT-FDC.

Well, today I got around to trying sergy's BIOS extension ROM code. I flashed his code (revision 1.0b1 from post #230) to an AT28C64B and put the AT28C64B in the XT-FDC. In my IBM AT, I removed the IBM hard/floppy controller, substituting that with the XT-FDC. To the XT-FDC, I connected a 1.44M drive as A: and a 1.2M as B:

Powered up the IBM AT, and it successfully booted from a DOS 6.21 boot diskette. On that diskette, I ran a CRC checker and the checker reported all files on the diskette as good (compared to pre-recorded CRC signatures). From A:, I then formatted a 1.2M floppy in B: and then copied all the files on A: to B:. The CRC checker reported all files on B: as good.

Thanks sergy.

I'll do some thorough checks using Checkit later, but I'm not expecting any problems.

8" drive connector

I have a dual sided TM848, which works well as a 1.2M drive via an FDADAP adapter (http://www.dbit.com/fdadap.html).
The other thing on my to-do-list is to see if the TM848 works on the 8" drive connector of the XT-FDC.
I'll be checking the connector pinout carefully to ensure that I don't damage my TM848.
I am aware that the XT-FDC won't be generating the TP43 signal ("write current switch") required by the TM848.
 
Well, this depends upon whoever's writing the code. The density/TG43 pin can be programmed in the 8477, so it's more a matter of software. We left it on the connector, but the FDADAP is probably the right solution--but there are also some 8" drives that derive the TG43 signal internally and don't look at the signal on the connector.
 
I received the PC8477BV from modem7 and after installing it, my card works correctly. So it seems that the Intel parts work in a different way...
 
I got around to trying my 8" drive (Tandon TM848) on the prototype XT-FDC.

Connected to 50 pin connector via straight-through cable. Drive select at first position.

Reconfigured ANADISK software (version 2.07): added third drive as unit 2 on primary controller.
I had ANADISK format a floppy (@ MFM, 77 cylinders, high density, 15 SPT) and I watched the drive step as the format proceeded.
I then had ANADISK scan the disk (as expected, failing on cylinders past 77).
I modified certain randomly selected sectors (on both sides), writing unique data into them, and was able to later read back the data without issue.

My opinion is that the 50 pin connector is wired up as expected.

The lack of a TG43 signal (required by the TM848) did not result in a problem during my crude tests.
 
Hi! Thanks Modem7 for the update. That's good news on the 8" floppy drive connector. If you need a TG43 signal, there are a couple of unused latch output pins on the U17 latch that could be used. It would take a cut and jumper to enable if it would be useful.

How are the rest of the builders coming along with this project? Are the build and test of the prototyping boards complete enough to go to a final board? How is the BIOS coming along?

Thanks and have happy holidays!

Andrew Lynch
 
Hi! Thanks Modem7 for the update. That's good news on the 8" floppy drive connector. If you need a TG43 signal, there are a couple of unused latch output pins on the U17 latch that could be used. It would take a cut and jumper to enable if it would be useful.
Per Chuck's November 9th post, the hardware is already in place - the TG43 pin (pin 2 of P6) being connected to the 8477, all ready to be software controlled as required.

I don't anticipate much use of the 8" interface by others. Myself, I use an FDADAP.
 
How are the rest of the builders coming along with this project? Are the build and test of the prototyping boards complete enough to go to a final board? How is the BIOS coming along?

Thanks and have happy holidays!

Andrew Lynch

I'm terribly behind ...

(Hangs head in shame despite the good excuses ...)


Mike
 
Back
Top