33 replies to this topic

[Wonko the Sane]

Yep, it is very possible that some versions default to "ReadOnly" and some don't and that would also exclude my being too forgetful , it is likely that some previous versions I used did have it not set as RO.

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).


Wonko

[steve6375]

There is a temporary fix possible by using a snapshot of the USB drive.
In Qemu Manager there is an entry that says

Do Not Apply Changes to VM Session = No

Set to Yes we get snapshot mode and any changes to the USB drive appear to work and are persistent (but for that session only - still no sectors are actually written to the USB drive).
So the difference is that -snapshot is being used when we say Yes. This has the affect of making writes appear to work - but this is only temporary as they are not actually committed to the physical drive. Even typing commit all in the console of qemu does not make the changes permanent.
However, at least this is a way to properly emulate booting from a USB drive for DOS in that writes do 'appear' to work during that session (at least for BIOS based OS's).

P.S. This might explain why the grub4dos savedefault command never seemed to work in my Qemu sessions!

[Wonko the Sane]

P.S. This might explain why the grub4dos savedefault command never seemed to work in my Qemu sessions!

Yes, that would be a nice explanation.

You were using a "mixed-mode" testing bed, say 3/4 virtual and 1/4 "real".

I prefer "whole virtual" or "whole real".


Wonko

[betrand]

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.

[Wonko the Sane]

@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

[steve6375]

For 6.22 I  think I got this to work...

 

title MS-DOS 6.22
root ()
geometry --bios --sync
chainloader /io.sys

[betrand]

MS-DOS 6.22

Thanks. People should really upgrade!

 

Well debugged both!

 

[betrand]

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.. 

[Wonko the Sane]

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