• Please review our updated Terms and Rules here

5150 Cannot format floppies

This is a 5150 running at 7+ MHz? Didn't know that IBM made them like that.
There are some turbo XT clone BIOSes that slow the system clock back down to 4.77MHz when Int 13H access is happening. I suppose that could be done with yours.
 
Out of curiosity, NFORMAT has the option to format without verify by specifying the "Q" parameter on the command line, will that create a usable disk?
It does indeed, working boot sector and all. That will be my workaround I guess
 
Fer the love of &^*&^*!!:

PC SPRINT Website said:
Accelerator to boost original clock speed of 8088/NEC V20 past 4.7mhz to 7.5mhz

*NOTE* With the 7.5mhz option enabled the machine will be unable to write to floppy disks until set off to default speed, This is due to the floppy controllers reliance on CPU speed for write cycles.

In the old days of 5150 and 5160, we'd just take an XCO and feed it into the EFI input on the 8284 and tie the F/C* pin to the 8255--just the way the taiwanese would do it.
Of course, in turbo mode, the clock ran a bit fast, but you could use a small TSR to capture the keyboard and then scale the 8253 interrupt to match the turbo speed--and drop the speed when Int 13H was called. Worked quite well and very cheap---and it was switchable from the keyboard. No switches necessary.

The point of the warning above is because the 5150 BIOS used CPU loops to pace interaction with the 765. In particular, the result of an operation lagged the initial command by about 50 microseconds, so you needed to delay a bit or else you'd get a bogus status. In the AT and later, you could get a guaranteed 50 microsecond delay by using the refresh status bit (not present on the 5150).

What the heck, this was only 40 or so years ago...
 
Fer the love of &^*&^*!!:



In the old days of 5150 and 5160, we'd just take an XCO and feed it into the EFI input on the 8284 and tie the F/C* pin to the 8255--just the way the taiwanese would do it.
Of course, in turbo mode, the clock ran a bit fast, but you could use a small TSR to capture the keyboard and then scale the 8253 interrupt to match the turbo speed--and drop the speed when Int 13H was called. Worked quite well and very cheap---and it was switchable from the keyboard. No switches necessary.

The point of the warning above is because the 5150 BIOS used CPU loops to pace interaction with the 765. In particular, the result of an operation lagged the initial command by about 50 microseconds, so you needed to delay a bit or else you'd get a bogus status. In the AT and later, you could get a guaranteed 50 microsecond delay by using the refresh status bit (not present on the 5150).

What the heck, this was only 40 or so years ago...
Except the warning isn't true, I can write disks just fine. I simply cannot verify sectors. :cool:

The warning is generally understood to refer to the fact the 8237 DMAC is being overclocked by the PC-Sprint. That's an interesting point about not having the 50us delay though. Maybe I can hack the GlaBIOS to accommodate this.
 
...which is very strange, because while the 765 is issuing a read, the 8237 is performing a VERIFY, which doesn't involve memory access at all:
Screenshot_2022-10-02_08-59-52.png
Since the FDC is still performing a garden-variety read operation, with the data dumped down a black hole by the 8237, you'd think that the timing is the same as for a data-transfer read.
My guess is that the 5150 is inserting a wait state during real data transfers that doesn't occur during verify. Two questions:
1) Have you replaced the 5150 8237 with a faster 8237A-2 or even an 82C37A?
2) I don't recall what the other question was.
 
I've been reading the source code for the other BIOS I tried (GlaBIOS) which exhibits the same behaviour with respect to this problem as the original IBM BIOS. There are no additional delays inserted into a read or write operation vs a verify. My belief is the 8237 is not the issue here. I think the 765 just needs a fuzz more time to settle before getting the status. Why that only seems to affect verify I cannot say, but I'm going to try changing the value in the FDC get status delay function and see if that fixes it.
 
You're not following me. If read and write work fine, then verify, which is the same as a read, but with the 8237 set to non-transfer mode, the only thing that's different is the 8237 timing. I'm saying that the 5150 when doing DMA transfers inserts a wait state if actual memory data is involved. This has to do with the interface of the 8237 to memory; the 765 isn't the one with the problem.

To check this, see what the 765 7-byte status code is after a failure.
 
You're not following me. If read and write work fine, then verify, which is the same as a read, but with the 8237 set to non-transfer mode, the only thing that's different is the 8237 timing. I'm saying that the 5150 when doing DMA transfers inserts a wait state if actual memory data is involved. This has to do with the interface of the 8237 to memory; the 765 isn't the one with the problem.

To check this, see what the 765 7-byte status code is after a failure.
So you're saying the problem has nothing to do with getting the status from the 765, it's that back to back DMA transactions are occurring too rapidly because there is no wait state during the read/write to system memory which would otherwise occur if the transaction was not a "verify"?
 
If that were the case, why does it work fine when I swap over to a 1990s multi-io card with integrated FDC? It's only the old discreet 765 cards that exhibit the problem
 
"Discrete". I have no idea--do the multi-I/O cards have their own BIOS?

In any case, if the 765 failed, you'll see the reason in RAM at 40:41h-40:48h. So just trap the return from Int 13H and display the status bytes if an error is returned. Easy.
 
Last edited:
"Discrete". I have no idea--do the multi-I/O cards have their own BIOS?

In any case, if the 765 failed, you'll see the reason in RAM at 40:41h-40:48h. So just trap the return from Int 13H and display the status bytes if an error is returned. Easy.
It's a bog standard Taiwanese IDE/FDC/IO card for AT class systems with everything but the FDC disabled. No BIOS
 
"Discrete". I have no idea--do the multi-I/O cards have their own BIOS?

In any case, if the 765 failed, you'll see the reason in RAM at 40:41h-40:48h. So just trap the return from Int 13H and display the status bytes if an error is returned. Easy.
Since I have access to the source code for the GlaBIOS I might as well hack in something to preserve the status codes after a verify failure. Probably easier than writing a program from scratch to revector int 13. In any case, I tried doing a build increasing the command delay to the 765 and it had no effect.
 
Okay, that's pretty definitive. The DMA controller isn't keeping up with the FDC. The FDC is making requests faster than the DMA controller can acknowledge them.
You have to remember that the bus clock isn't the stumbling block for the FDC. In 8" mode, it normally runs at twice this speed (It was intended after all, as an 8" controller).

Recall that the format-verify operation usually operates a track at a time, where normal sector reads generally involve a cluster or less. So even though the DMAC isn't writing to memory, it still has to service the FDC DRQs.

Perhaps the other FDC support circuitry "stretches" the DRQ a bit so the DMAC can pick it up. A logic analyzer might show the issue.
 
Back
Top