China DOS Union

在QEMU中成功测试，见第7帖

(1)
用于从plopcdflp12.iso中提取引导扇区和plopbt.bin到C/H/S为7/1/16的63KB软盘镜像中，该镜像来自ROMOS。然后使用rcompile.bat生成包含plop引导管理器（引导扇区+plopbt.bin）的romos.bin。

结果：
QEMU引导到ROMOS但挂起虚拟机，显示：
plop bt bin

(2)
从QEMU引导并将63KB的plop.img用作软驱a:的尝试

结果：
好的，成功进入plop管理器。

(2)
将plop.img放入grub4dos.img的尝试

代码：
map --mem (fd0)/plop.img (fd1)
map (fd0) (fd1)
map (fd1) (fd0)
map --hook
chainloader (fd0)+1
磁盘错误

root (fd0)
boot

与情况(1)相同

结论：还没准备好将plop放入BIOS

[ 最后编辑者uleak于2008-7-11 上午11:32 ]

Incorrect usage. After map --mem (fd0)/plop.img (fd1), there is another map (fd0) (fd1), then the result is that the latter overwrites the former, so the former doesn't work, only the latter works.

It should be like this:

map --mem (fd0)/plop.img (fd0) map --hook chainloader (fd0)+1 rootnoverify (fd0) boot

当然，进入grub菜单后，包含grldr的fd0就不再需要了，因为grub用于处理fd1的模拟并引导到plop管理器的引导扇区。

一般来说，问题是由于未知原因，ROMOS的FDD模拟代码与plop引导扇区不能很好地配合工作，但qemu模拟可以。grub的FDD模拟不适用于不常见的63k镜像，因为在这种情况下，grub以对典型的1.44M镜像的出色支持而闻名。

由于qemu可以使用我的63k fdd.img并引导到plop主程序，所以我可以认为fdd镜像状态良好。

这里得出的结论是，ROMOS已经停滞多年，而我无法修改源代码。并且grub4dos对于64k的bin来说太大了，还嵌入了一个63k的镜像。所以PCI rom还没有准备好。

Sure, after entering the grub menu, the fd0 containing grldr is no longer needed, since grub is used to handle emulation for fd1 and bootstrap to plop manager's boot sector.

Generally speaking, the problem is that for unknown reasons, the ROMOS FDD emulation code cannot work well with the plop boot sector but qemu emulation does. The grub FDD emulation is not working for the uncommon 63k image, as grub is well-known for its excellent support for the typical 1.44M image in this case.

Since qemu can use my 63k fdd.img and bootstrap to the plop main program, then I can assume the fdd image is in good shape.

Here the conclusion is made that ROMOS has been stagnant for years, and I am unable to modify the source code. And grub4dos is too large for the 64k bin, with a 63k img embedded. So the PCI rom is not ready.

grub4dos has multiple development directions. For example: grub2 is one direction. Transforming Linux to make it a bootloader is one direction. Streamlining grub4dos and using assembly code to save space is another possibility.

Also, I feel that your 63K img should be bootable with map. I guess your img is not a FAT file system, so map failed to detect a suitable CHS value. You need to specify --heads= and --sectors-per-track= in the map command line to fix it. The value of cylinders doesn't need to be specified.

> I feel that your 63K img should be bootable with map
true, this is a mappable img, my mistake.

my tailor-made 63k plop manager image 7-zipped
http://upload.cn-dos.net/img/588.7z

this is from the ROMOS 63K USB boot disk image

i use ultraiso to inject plopbt.bin into the image, the boot sector is also the same.

mapped by grub4dos, booted as fd0, error as stalls. Not clear whether this is a boot sector error, or plopmanager refuses to run under grub4dos with this uncommon disk image, since the zipped plop.img with 1.44M typical size image is working.

the geometry cmd report of 1.44M zipped floppy image is CHS 80/2/18, 2880/512
and the 63k image is LBA 7/1/18, sector count is 126/512

don't know if this difference is due to ultraiso saving the 1.44M boot sector into the 63k image or not.

latest screen output when 63k image is used:
.....................

Just tested, and the following code can start successfully:

map --mem --heads=2 (fd0)/plop.img (fd0) map --hook chainloader (fd0)+1 rootnoverify (fd0) boot

This proves that your 63K FAT image is actually H=2, S=18. However, you incorrectly set H=1 in the BPB table of this FAT, which is the root cause of the error.

Hi there,
the plop manager is now embedded by the ROMOS pci rom within 64k, bootable, successful boot into plopmanager. this is a PCI rom image, so it can be inserted into bios.

download here:
http://upload.cn-dos.net/img/589.7z

Thanks tinybit.

Regards,
uleak