Comment 5 for bug 556416

Paul (dummy) wrote :

So it seems like the problem is that MEMDISK has changed their default memory handling routine, and since Unetbootin uses those defaults, DOS boot floppies are now having a problem.

It would seem that there are two options:

1) Get them to change the default back to what it was and/or fix the current mode so it works better.

On that front, for what it's worth, I tried booting previous versions of my floppy disk and NONE of them work with Unetbootin (I tried 442 also, BTW). This is interesting because these disks use completely different memory managers and ramdisk TSRs, yet NONE of them make it all the way through the boot process. The only thing they have in common is that they all have FreeDOS kernels, but they are also different versions, and even different boot sectors!

Jack Ellis, the author of the XMGR memory manager, also points out that it is likely FreeDOS itself that has the incompatibility, since the FreeDOS kernel successfully displays a message AFTER the memory manager finished loading:

Here are links to the various disk images and a short summary of their memory manager, ramdisk drivers, and image sizes. As you can see, it's quite a combination and yet NONE of them work. (HIMEM64/XMSDSK/1440) (FDXMS/XMSDSK/1440) (FDXMS/PC-DOS 7.1 RAMDRIVE/1680) (FDXMS/RDISK/1680) (XMGR/RDISK/1680)

(I am testing on my laptop, a Toshiba A605-201.)

So maybe this information will help the MEMDISK team change their minds about this default and/or fix the new implementation.

The other option, though, is:

2) Unetbootin can override the MEMDISK defaults so things will work just like before. Perhaps this would make an easy solution while pushing ahead with option 1.