• Please review our updated Terms and Rules here

Low Level Disk Format on "IBM"-PCs or are modern PCs capable of reading SD-floppys?

cerker said:
It gave the status "ABRT" to me with "unsupported feature"
Click to expand...

I'd revisit this; the specification is really specific on the requirement for 8-bit support:

A device that implements the CFA feature set shall implement the following minimum set of commands:

- CFA REQUEST EXTENDED ERROR CODE
- CFA WRITE SECTORS WITHOUT ERASE
- CFA ERASE SECTORS
- CFA WRITE MULTIPLE WITHOUT ERASE
- CFA TRANSLATE SECTOR
- SET FEATURES Enable/Disable 8-bit transfer

Using 8-bit transfer mode will save you a tonne of work.
 
Using 8-bit transfer mode will save you a tonne of work.
Click to expand...

Since I have already done that work, thats not much of an argument ;). I designed the CPLD in a way that 16bit IDE Transfers are simply accomplished by writing 16bit into the data register address or reading 16bit from there. Additionally, I made a configuration register into the CPLD for various things, including a switch between 8 and 16bit transfers.

That's done via a state machine, if you do a read access on Register 0 while 16bit mode is active, you will get the MSB on the bus and the LSB gets latched (MSB because Motorola CPUs were generally big-endian back then), a subsequent read access on Register 1 gives the LSB of register 0. Writing is analogous, access on Register 0 stores the MSB, subsequent access on Register 1 writes it together with MSB into the IDE-device. That wasn't my idea, various people on the web did that before and "inspired" me. Actually, the famous GIDE works very similar.

It is a bit of effort, but in exchange I get full IDE support and will be able to use "real" harddrives, too .. or even CD-Drives ;).
 
Some news:

The IDE-interface is working fine. I can read and write sectors in 16bit mode without any problem, just have to fix the endianess, but thats an neglectable change in the CPLD sources.

Back to original question: Somebody know something about the actual low-level-format used in IBM-compatibles? For FM as for MFM?
 
cerker said:
Back to original question: Somebody know something about the actual low-level-format used in IBM-compatibles? For FM as for MFM?
Click to expand...
Datasheets on the floppy controller used may help.

Photos of the floppy controller cards used in the IBM PC (IBM 5150) are [here].
They show controller chips of Intel P8272 and NEC uPD765A

The IBM Technical Reference for the IBM 5150 is [here]. It includes source code for the BIOS.
 
Thanks, that helps a bit.

Meanwhile I have been able to boot the original operating system FLEX from a CF card .. reading is fine, writing kills the filesystem .. there must be some overseen bug in the drivers.
 
Could be a bad low byte... try a pattern test on raw sectors, walking 1's for example.
 
cerker said:
SBack to original question: Somebody know something about the actual low-level-format used in IBM-compatibles? For FM as for MFM?
Click to expand...

I might. :)

To the best of my knowledge no "echt" IBM PC before the offshored models supports FM using IBM's own controllers. Not the 5150, 5160 or 5170. It is possible to modify some of them that use the WD9216 (or equivalent) to support FM reading, but that's as far as it goes.

FM-ability varies all over the place. There are some hallmarks that may give a hint. Anything using an NSC "all-in-one" FDC, such as the 8473 or 8477 supports FM. Any manufacturer who licensed the design, such as DTC probably supports FM. SMSC chips generally support FM. An Intel 82077, but not an 82077AA chip supports FM. Most Japanese "all in ones" do not. WD "all in ones" such as the WD37C65 do.

As far as the howto, get your hands on some NEC µPD765 app notes, the datasheet for one of the "all in ones" (they're all over the 'net) and a copy of the 5150 BIOS listing. You should be able to take things from there.
 
Last edited:
How are you determining writes in the CPLD (to suppress /IOW or flip /CS0 and /CS1 to no-op for the first byte)?
 
To my problem: I've found an old "TSC-Newsletter" (TSC is the developer of FLEX) which reports about a bug in 6809 FLEX which destroys the directory when using >20000 sectors .. and how to fix it. I will try that this evening.

To your question: I'm sampling addresses at the rising edge of Q (adresses are valid 110ns after falling edge of Q, rising edge of Q is 250ns after falling edge of E) to go through a FSM which has the states [nothing, 8bit read, 8bit write, 16bit read LSB, 16bit read MSB, 16bit write LSB, 16bit read LSB, read status, write config] .. the state is controlling a busmultiplexer which switches the data bus and the control signals. I analyzed that problem a little bit deeper ... and I don't think it's a interface problem. It writes the sectors correctly, but sometimes simply the WRONG sectors (e.G. T: 9D, S: 3E with the contents of T: 02, S:3E into T: 00, S:07), but still in a formally correct format. Very unusual for a low-level error I thing. Sectors in the wrong location could be setting the LBA registers wrong .. but a correct header and correct body .. but mismatched and in the wrong place?

Also, testing the write/read sector routines with a test program only shows that they are working absolutely fine. Together with TSCs mention of a bug which screws up the directory by writing formally correct, but misplaced sectors into it .. I think the drivers are just doing what the OS is telling them to do.
 
lynchaj said:
How is the XT-IDE project "infamous"... Please explain.
Click to expand...

Andrew, thanks for pointing out my blatant misunderstanding of the meaning of the word - no offense intended, I assure you. I can't correct the post now unfortunately. Illustrious, was what I was meaning to convey.
 
Last edited:
I'm having some difficulty following this thread. My original thought was that it was about floppy disk recording modes.

Where does the XT-IDE come into this? Have you developed drivers for the ATAPI Superdrive or the Caleb 144MB unit?

Color me confused. :blush:
 
Last edited:
@cerker endian swap is the least of your problem since it's child's play to fix just by wiring it correctly.

And still IMHO without DMA your CPU would be tied up doing Disk I./O while it could have been doing something useful.
 
@cerker endian swap is the least of your problem since it's child's play to fix just by wiring it correctly.
Click to expand...

I already fixed that in my CPLD-sources ;)

And still IMHO without DMA your CPU would be tied up doing Disk I./O while it could have been doing something useful.
Click to expand...

As the operating system FLEX expects Disk I/O to be blocking and isn't able to anything while reading/writing, that's not much of a problem ;). I still think about that as an "nice to have" which I can do later.

I have thrown away my old approach to map 256 byte sectors to 512 byte sectors. The main reason for this was performance, because writing a single sector using this method meant moving 1280 bytes, reading also moves 768 bytes. Since disk space is VERY cheap, even on CF cards (0.3 eurocent/MB) I now use simple 8bit transfers (I had the smart sense to design a configuration register into the CPLD to switch between modes) and just write 256 byte sectors (as some of you suggested many times, a dmittedly). By doing that, I get a performance 3-5 times higher for the expense of 5 eurocents a 16MB drive .. I think thats a nice deal ;). And .. no filesystem crushing problems anymore .. its working perfectly now (of course I still have to include some error handling for safety reasons). Speed is also very acceptable for me.
 
cerker said:
I already fixed that in my CPLD-sources ;)



As the operating system FLEX expects Disk I/O to be blocking and isn't able to anything while reading/writing, that's not much of a problem ;). I still think about that as an "nice to have" which I can do later.

I have thrown away my old approach to map 256 byte sectors to 512 byte sectors. The main reason for this was performance, because writing a single sector using this method meant moving 1280 bytes, reading also moves 768 bytes. Since disk space is VERY cheap, even on CF cards (0.3 eurocent/MB) I now use simple 8bit transfers (I had the smart sense to design a configuration register into the CPLD to switch between modes) and just write 256 byte sectors (as some of you suggested many times, a dmittedly). By doing that, I get a performance 3-5 times higher for the expense of 5 eurocents a 16MB drive .. I think thats a nice deal ;). And .. no filesystem crushing problems anymore .. its working perfectly now (of course I still have to include some error handling for safety reasons). Speed is also very acceptable for me.
Click to expand...

I'm happy, your happy.

This whole project of yours made me think, I am gonna build my own homebrew computer. :p
 
So is the 16-bit MUX abandoned?

Also re concurrency, not only is the OS expecting blocking IO but also with zero cache and then a saturated memory subsystem there could be no processing anyway.
 
16Bit isn't used for "FLEX" anymore, yes. The main reason I introduced in first place it was quite simple: I had some timing issues which wasn't easy to overcome with convential glue logic, so I deceided to use the CPLD. And then .. "If I use a CPLD anyway, I can implement the 16bit mode, too" ;).
 
You must log in or register to reply here.
Back
Top