![:worship:](http://reboot.pro/public/style_emoticons/default/worship.gif)
In any case I never tested too much the \\.\PhysicalDevice "direct" access.
Anyway, you can still dd the stoopid USB thingy to an image file and then dd it back to the device (outside Qemu).
![:worship:](http://reboot.pro/public/style_emoticons/default/worship.gif)
Wonko
Posted 05 December 2010 - 01:42 PM
Posted 05 December 2010 - 04:25 PM
Posted 05 December 2010 - 08:03 PM
P.S. This might explain why the grub4dos savedefault command never seemed to work in my Qemu sessions!
Posted 04 March 2013 - 02:32 PM
A neat thing I do is use Grub4dos and Chenall's Fat tool.
I create a ramdrive, format it,
then create a file of wanted floppy /superfloppy size,
then I map the file as (floppy),
then create a filesystem.
See here:
http://reboot.pro/to...os/#entry168760
From dos + grub.exe, you can
(using Chenall FAT tool)
Map (md) 0x300+0x1000000 (fd1)
map --hook
fat mkfs (fd1)
fat mkfile size=10000 (fd1)/img
map --mem (fd1)/img (fd0)
map --hook
fat mkfs (fd0)
(md) is multiple 32 (0000). Fat filesize is in bytes.
A batch can make things automated.
Chainload the Dos kernel, and edit the image.
The file on (source) (fd1) is updated.
From Grub I think you have to map --hook the file twice for some reason,
otherwise only small files can be copied.
Do echo hello there>file.txt, works.
Copy a big file to the (fd0), won't work.
But if you map --hook again, then operations are OK.
Posted 04 March 2013 - 02:51 PM
@Bertrand
Yes , BUT no
, in the sense that the OP was talking about MS-DOS 6.22 which IO.SYS is NOT chainloadable from grub4dos (uness this feature has been added recently
), so in his case the need to use format /s or sys from a booted 6.22 still remains.
Or one could use bootpart, together with a 7.1 MS-DOS or FreeDos, but that would be more complex (an I am not even sure if bootpart would work on floppy, most probably not )
As a side note, and just for the record, the grub4dos FAT tool makes a "non-standard" filesystem (with only one FAT instead of the "standard" two) which may create incompatibilities issues with other software.
Wonko
Posted 04 March 2013 - 02:55 PM
For 6.22 I think I got this to work...
title MS-DOS 6.22 root () geometry --bios --sync chainloader /io.sys
Posted 04 March 2013 - 03:05 PM
MS-DOS 6.22
Thanks. People should really upgrade!
Well debugged both!
Posted 04 March 2013 - 03:15 PM
only one FAT instead of the "standard" two)
Thanks, I think I'd noted that as I always edit the FAT to 1.
But, I didn't know of the incompatibility..
Posted 04 March 2013 - 03:31 PM
But, I didn't know of the incompatibility..
Well, it is not a "recorded/verified" one.
It is a "possibility".
Knowing how much the (non-existing) FAT filesystem (and related matters) specifications have been (mis)interpreted, ignored or badly implemented over the years, even "internally" by the MS guys (anyone old enough to remember the folly that the win 9x volume tracking represented? ) it wouldn't surprise me at all if some (dated or recent) software would "assume" that a FAT filesystem has two copies and corrupt something.
For 6.22 I think I got this to work...
title MS-DOS 6.22 root () geometry --bios --sync chainloader /io.sys
Nice
Forgot about it, should be since:
http://reboot.pro/to...2-boot-problem/
https://code.google....ce/detail?r=169
And the bios sync should be only on Qemu (or however only on some "pesky" BIOS):
http://code.google.c...es/detail?id=79
Wonko
0 members, 0 guests, 0 anonymous users