• Please review our updated Terms and Rules here

Diagnosing an old floppy controller in a weird system

Hak Foo

Experienced Member
Joined
Jul 18, 2021
Messages
218
I'm working on building one of the "homebrew8088.com" V40 mainboards. Since it only has four slots, I wanted to try to get a multi-I/O card, to cover all my serial/parallel/floppy needs at once.

The one I chose was a used, unbranded card where the only identifying mark is "COPYRIGHT BY B". https://i.ebayimg.com/images/g/u7YAA...RF/s-l1600.jpg is close, perhaps even the same one I bought.

I snipped out the battery, which had began to rot its contacts, and neutralized with vinegar/cleaned with water and alcohol. I also Deoxited the bus connector and the floppy connector, just in case.

I've scavenged an old cable from a 386 clone, and tried to connect several different 1.44Mb drives to it (to hopefully eliminate single-drive failure as a cause). (mostly because the cable only has one of the connector type used by this card and 5.25 drives, and I think most of the 5.25" drives I kept were 1.2Mb). I had heard that 1.44M drives on an XT-class floppy controller will typically work as 720k.

Now, the machine I mentioned has a very... unusual... hardware and BIOS layout. I'm using a modified version of the Phatcode Anonymous BIOS... introducing just enough boot code to initialize the V40 CPU onboard peripherals and the keyboard controller used by this board. There's also an option ROM that hooks INT 13h to handle the board's "use a USB drive as drive C" feature. That ROM is set up so if you ask for any disk other than 0x80, it jumps back to the Anonymous BIOS INT13 code in a naive attempt to keep floppy compatibility.

What I've noticed so far (with a 720k disc inserted)

* When I power up, the drive motor spins briefly.
* At the end of the POST, it pauses for a second or two about where you'd expect to seek the drive, but no seek or attempt to boot from floppy occurs that I can tell. This seems baked into the BIOS; it did that even before I had a floppy drive controller in the system.
* When I boot from the "hard disc" (a PC DOS 2000 install), and do A:, the drive spins up-- you can hear the motor spin, and the light goes on. Sometimes there's a minor clunk. But it always eventually announces "Not Ready Reading Drive A".
* If I try ELKS (the 'it's sort of linux for an 8086' project), its boot loader, it lets me specify to boot from floppy or a partition. The "floppy" option does a similar "spin up the disc" but reports failure.
* Snooper and ELKS both report zero floppy drives.
* If you point Snooper at drive A, it reports "No disc in drive" but also a geometry of 1016 cylinders/63 sectors/16 heads. I'm wondering if this is a red herring, because that's suspiciously close to the geometry of the "hard disc" on the system.
* Snooper also shows IRQ6 in use but not DMA2. (only 0, 1, 3)

I'm not sure where to move forward on diagnosing this.

I can see several possible angles:
1. The hardware works, but somehow has been confused into believing the floppy drive is a 500Mb hard disc. This seems suspect, because even a test run with the Option ROM removed didn't seek the drive.

2. The hardware is misconfigured-- switches set wrong. There's, of course, no obvious documentation for this card.

3. The hardware is faulty-- has enough marbles to activate the disc drive, but not enough to say "Yo, there's a disc in here!"

4. The hardware doesn't work with 1.44M drives; the info I've found about using them as 720k seems to revolve mostly around the "real" IBM controller.

5. There's a firmware weirdness, like not enabling the right resources in the controller to talk to the floppy drive. It looks like BIOS does try to set interrupts 0, 1, and 6. I see pokes to ports 61-63 and 81-83 in the initialization code, but the V40-specific setup code doesn't seem to drop any peripherals there-- we have the DMA controller at port 0, the interrupt controller at port 20, and the timer at port 40 hex. (The serial port is at D0, probably for lack of anywhere good to dump it). At least some of port 61 must be wired to something, because the beep works, and that seems to entail toggling port 61.

6. There's some underlying incompatibility with the mainboard-- maybe we're fundamentally missing something to make it "PC enough". I notice a lot of comments that the V40 includes an 8255-style parallel controller, but the datasheet doesn't seem to mention it or how we'd drop it into position-- maybe that's supposed to land at port 61-63 or 81-83

The BIOS I'm working with is here for a reference: https://gitlab.com/hakfoo1/v40-bios
 
Last edited:
Okay, first of all, this appears to be your card The empty DIP sockets are for a second 8250 UART and its accompanying MC1488 and MC1489 EIA drivers/receivers.

The chip with the stickers on it is a NEC µPD765A.

Okay, on to why you get a "not ready". This is a "catch-all" type of error, so there can be several explanations:
1. The INDEX signal from the drive isn't getting through to the FDC. With a logic probe or 'scope, check to see that pin 17 on the 765 is getting a pulse every disk revolution when the drive is selected.
2. You have an interrupt problem. This card requires that IRQ 6 not be taken up by another card.
3. You have an I/O port conflict. Make sure that I/O addresses 03f2h-03f5h aren't being used by another device.
4. You could have a DMA problem. This card requires that DMA channel 2 not be taken up by another device.

This should be enough to get you started.
 
Cool. That looked like the closest match on the TH99 site, but I was skeptical because it looked different in how the switch block was positioned, and the connector for the second serial port is 26 pins instead of 9.

Some progress....

The card works (at least seeking the drive during POST) when I dropped it into a DTK 286-10 mainboard.

I tried the TESTFDC program as part of the ImageDisk suite and it reported "No FDC Interrupt" after turning on the drive light. That made me think somehow IRQ6 is the issue. (I suspect some of the detection software may just say "I see a FDC, it must have IRQ6".)

I figured out that the mainboard's "USB stick as hard drive" device was built to reside on IRQ6, but currently this is unsupported in the firmware design; I think it was basically holding the IRQ6 line off . Lifting a pin to keep that signal out of circulation seems to have improved progress. It will now do a brief seek of the drive during POST, and trying to access the drive with an "A:" seems to report *data* errors instead of *not ready* errors. (I have a couple of old commercial 720k discs, when I slapped them into the LS-120 in my modern machine, they seem to read okay)

I tried TESTFDC, telling it was a 720k drive, and it always reported "OVERUN" during the format test. The drive made seeking-related noises, indeed a lot of noise, but it reported OVERUN errors in the format test, regardless of drive type specified. Other tools in the ImageDisk package do seem to seek the heads, but I don't know enough about them to understand how they work.

If I do "format A: /F:720", it says unsupported parameter combination and dies. If I try format a: /f:360, it says track 0 is bad/disc unusable. This seems to happen with two different discs and a couple of different drives. MSD seems to think the machine has 360k drives, which could be some weird fingerprint of a BIOS designed assuming 360k drives.

Part of me remains skeptical about DMA. If it's sending the commands and expecting a DMA to relay the response data, that could explain errors. However, since the machine uses SRAM, the refresh stuff was do-nothing, meaning this is the first time I actually need to have functional DMA. Is there a good way to diagnose if it actually works as it should?

At boot, the BIOS enables the V40's DMA controller, and sets it to live at port 0x00, but then we just rely on the Anonymous BIOS to initialize the channels to something useful for a floppy. The Snooper output shows that DMA2 isn't "in use", but it also insisted IRQ6 was in use by the floppy controller when it was really being consumed by the "hard drive"
 
"Overrun" error is usually due to the DMAC not servicing transfers. So I'd start looking there. That is, when the card issues a DRQ, are you getting a DACK in response?
 
I finally pulled it together overnight (conceptually at least).

The design of the board is to use the V40's DMA controller. Which is not a perfect PC/8237 compatible design. So of course, all the code in the BIOS that's trying to set up 8237 DMA stuff is going to be completely wrong.

I guess this puts a cap on the compatibility of the design: I could try to rewrite the BIOS to use V40-style DMA invocations, but then if I ever try a sound card or some other DMA-using device, we're back to square 1.
 
It sounds like you're using an IDC to card edge cable backwards? Will a cable meant to go from a pin connector controller to a card edge floppy work the other way around? Seems like the twist location would be wrong.
 
Back
Top