Chuck(G)
25k Member
Ah well, it's probably a bus-related issue. Yer running it too fast, mate!
They didn't. I detailed the system in the OP. There is a PC-Sprint overclocking module installedThis is a 5150 running at 7+ MHz? Didn't know that IBM made them like that.
It does indeed, working boot sector and all. That will be my workaround I guessOut 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?
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.
Except the warning isn't true, I can write disks just fine. I simply cannot verify sectors.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...
No, it's soldered to the board and since it works for everything else I just left it be1) Have you replaced the 5150 8237 with a faster 8237A-2 or even an 82C37A?
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"?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.
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."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.