You are not logged in.
Hello, ASM hackers (I wish I could say "fellow" but I'm quite a n00b @ ASM... )
I have a question about the low-level, "bit-banging" of accessing a floppy drive and, since you guys have all written your own (or at least understand someone else's) floppy drive code, I figured this would be the place to ask.
On http://www.storagereview.com/guide2000/ … taRLL.html and http://www.storagereview.com/guide2000/ … taMFM.html they explain different ways data can be written to a magnetic medium, like hard disks and floppies. I was wondering, since in your homebrewn OSes you have direct control over the floppy, would it be possible to use MFM or RLL on a floppy disk?
I know that it would break compatibility with DOS/Win disks, but who cares? If it can increase the space and transfer rate of a floppy significantly, I think it would be worth it. Besides, maybe a new driver could be written for those "antique" OSes to allow them to use "megafloppies" too.
Of course, looking at the BOS code for writing to the floppy (which looks broken, to me, but what do I know?...) it looks like you might be just handing data off to hardware which does the actual writing; in which case, it will take the creation of new controller hardware, and I just wasted everyone's time
Well, thanks for reading,
Amos
PS: regarding the floppy write code: (fdc.inc)
It looks like it's overwriting the data-to-be-written (AL) with a status byte of some sort, which would then be written to the disk instead. If this is wrong, I would appreciate an explanation of how it actually works.
Oops! Somehow I missed/forgot/whatever the fact that floppies already use MFM; but I still would like to try an RLL floppy. Well, carry on
Amos wrote:
PS: regarding the floppy write code: (fdc.inc)
It looks like it's overwriting the data-to-be-written (AL) with a status byte of some sort, which would then be written to the disk instead. If this is wrong, I would appreciate an explanation of how it actually works.
This is not so, the read/write users dma transfer to read/write data.
The full version of the driver is here: http://www.dex4u.com/images/FloppyDriver.zip
Please can you cut and paste the code you mean, if you still can not figure it out.
Offline
Dex4u wrote:
Amos wrote:
PS: regarding the floppy write code: (fdc.inc)
It looks like it's overwriting the data-to-be-written (AL) with a status byte of some sort, which would then be written to the disk instead. If this is wrong, I would appreciate an explanation of how it actually works.This is not so, the read/write users dma transfer to read/write data.
The full version of the driver is here: http://www.dex4u.com/images/FloppyDriver.zip
Please can you cut and paste the code you mean, if you still can not figure it out.
Well, like I said, I'm a total n00b
I looked again and saw the push/pop of eax... I'm always forgetting about those.
Thanks for the info/code! Although I understand the theory, I haven't looked closely at the actual mechanics of DMA transfers.
I don't think the RLL floppy thing is possible w/out a new controller, though
Well, keep up the good work on your respective OSes (and other cool software junk )
And remember, if you ever get tired of working on this [url=http://www.biblegateway.com/passage/?book_id=68&chapter=3&verse=9&end_verse=11&version=50&context=context]temporary junk[/url], there are [url=http://www.biblegateway.com/passage/?search=mk%2016:15-16&version=50]a few simple things you need to do[/url] to get [url=http://www.biblegateway.com/passage/?book_id=53&chapter=2&verse=9&version=50&context=verse]the really good stuff[/url].
Actually if one was motivated enough I think it's possible to have an RLL FDC driver that uses the MFM hardware, at least a modified RLL that would allow you to use MFM bitstrings to encode it. Those MFM encodings would be controlled by the data you send to the FDC and are predictable but you would have the consequence of funny sector sizes. Combined with compression you could fit even more on a floppy but of course totally incompatible with any other software. The sector headers and CRCs would still be MFM encoded, can't control that. Links on [url=http://en.wikipedia.org/wiki/Modified_Frequency_Modulation]MFM[/url] and [url=http://en.wikipedia.org/wiki/Run_Length_Limited]RLL[/url]. Then again I may spewing sh*t. (If you haven't noticed I love tweaking hardware, especially the old stuff, and I may investigate this further later.)
Nevermind, looks like all solutions degenerate back into MFM.
Pages: 1