VOGONS

Common searches


FDD Access?

Topic actions

First post, by Yushatak

User metadata
Rank Member
Rank
Member

If I want to write old floppy images using DOS-based tools on a 64-bit machine, I have few options.. or rather no options. Is there any conceivable way for me to use such tools through DOSBox - now or in the future - or is this something that will simply never happen?

I know that the NTVDM was capable of FDD access and would allow you to use such tools to reconstitute floppy disks from images - I do realize that it was MS-coded and part of Windows, and as such they had free reign to tap as deeply into the kernel as they wanted for hardware access, and DOSBox doesn't want to do this because it's intended as a userspace app. I'm not sure how abstracted the ability to write to a floppy drive is, however. I also realize that this would need to be differently implemented for *nix, but I'm sure that it would be immeasurably easier.. 😜

Before someone mentions windows-based floppy imaging tools, there are many exe-based disk creators that won't work under Win64 and aren't disk images, nor can they be extracted from the exe. There are also lots of now-defunct floppy image formats of various eras that can be read and written via DOS tools but are not capable of being written by contemporary ones.

Anybody?

~Yushatak

I'm notorious for repeatedly editing posts, so please excuse me if new information just pops up while you're writing your post... xD

Reply 1 of 4, by Yushatak

User metadata
Rank Member
Rank
Member

DOSEMU manages this under Linux, which I understand is probably easier to achieve, but still surprising.

Anybody have any comments or thoughts on the concept?

I know that you guys only like to integrate OSS into DOSBox, but there is a driver, FDRAWCMD.SYS, that is free for commercial and non-commercial use and extends the capability of the default Windows driver for FDDs when using a non-USB solution. Someone more experienced than I could write a patch to allow DOSBox to access a floppy drive at that level using this..

~Yushatak

I'm notorious for repeatedly editing posts, so please excuse me if new information just pops up while you're writing your post... xD

Reply 2 of 4, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

The current interfacing exposes int13 access to dos applications ONLY,
so the interesting floppy accessing programs won't work unless you implement
the port-based direct access. Then you can think about where you get the
data from, ie. low-level windows/linux/whatever.

Reply 3 of 4, by Yushatak

User metadata
Rank Member
Rank
Member

So you're saying that DOSBox isn't set up for it, and the floppy "hardware" would have to be massively rewritten to be capable of such access and for DOSBox to access the outside hardware as it does for CDROM - correct?

If so, then unless someone who knows C++ more than I wants to assist, looks like this will have to wait a long while. 🙁

~Yushatak

I'm notorious for repeatedly editing posts, so please excuse me if new information just pops up while you're writing your post... xD

Reply 4 of 4, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

to be capable of such access and for DOSBox to access the outside hardware as it does for CDROM - correct?

cdroms are even less low-level on the emulated part, namely there's only
dos-level access and no bios-level (or even port-level access). But for cdroms
there's no necessity unless you want dos cdrom drivers (or other operating systems that don't utilize dos access) to work.
The other end is making the data available, by higher-level routines ("simple"
directory/file access to the physical cdrom, using the operating systems or library
functions) or by low-level functions (ioctl sector-based access).

As i've said the "better" floppy utilities use port level access which is not implemented.