Hi Jerome
On 6/24/23 15:13, jer...@shidel.net wrote:
Hi,
On Jun 24, 2023, at 9:50 AM, Patrick McCavery <patr...@mccavery.com>
wrote:
Hi Everyone
Thanks very much for all the excellent posts here.
I am a little mixed up. One message seems to say that format /s will
write solely to the boot sector while another says it won't.
I am being a bit lazy, I am using gparted under Slackware Linux. I
formatted to Fat32. I ran qemu with -hda freedos.img -hdb /dev/sdc
freedos did not like the way that gparted formatted it so it
reformatted it. It copied over files. I was able to boot the usb
device under qemu, FreeDos came up just fine.
gparted says that that almost 15Mb are used on the USB key. du
command says 0.
I would like to dd the minimal image of FreeDOS. If I write this to
disk, and copy over, fdconfig.sys, command.com <http://command.com>,
an exe and an autoexec.bat that calls it, I think things should be
good. Am I missing anything? Is it only a minimal pre-kernel in the
boot sector? Do I also need to copy over the kernel?
I work with scientific instruments. Surely, as per your industry,
there are too many people trying to sell "new and improved" items.
There are people selling new scientific instruments that are hardly
better than the old ones and in many cases are worse. Lots of people
have old computers with ISA cards lying around that could control
their old instruments but they don't have the software to run nor the
staff to write software for it.
So the requirements are soft real time, astronauts will not suffocate
etc :)
Thanks again to all-Pat
As for creating a bootable DOS image, you could settle for the same
method used by the RBE. The RBE (Release Build Environment) is a fully
automated linux system that uses some fairly complicated scripting to
pull various components from the internet, modify them and generate a
FreeDOS Release or the Interim Build media. Simply run “make” and
return an while later to retrieve all the various release files.
The RBE creates bootable media of various sizes and media types. When
it comes to creating the Floppy or Hard Disk images, the process more
or less works like this:
Included with the RBE is a tiny compressed floppy image (a Bootstrap
image). The floppy image contains a boot sector. The RBE copies over
other items like the Kernel, FreeCom, other utilities and a job runner
batch file. It then executes QEMU booting the updated floppy with the
new disk image also attached. The QEMU instance partitions the drive,
reboots, formats the filesystem, then transfers the system files to
the new disk image and shuts down. The New disk image is now bootable.
Since you only need a bootable disk image, you could perform a similar
task in a much less complicated way. You could create a bootstrap
floppy image that contains all the tools needed to perform the
partition, reboot, format and system transfer files. Then when you
deploy a build. A script could generate the new disk image, use DOS
under QEMU to perform the tasks needed to make it bootable, then copy
the program over and boot the new image.
So when you compile and deploy the program, it could call a script
that looked something like…
# create hard disk image
qemu-img create -f raw DOSDISK.IMG 15M || exit $?
# boot bootstrap image to partition, format and transfer system files.
qemu-system-i386 -display none -m 16M -drive
file=bootstrap.img,media=disk,index=0,if=floppy,format=raw -drive
file=DOSDISK.IMG,media=disk,format=raw -boot a
# mount disk image
# copy executable files to DOSDISK.IMG
# unmount disk image
# boot DOSDISK.IMG for testing compiled executables
Or to simplify things even more, you could just keep one or more
various “ready-to-go” disk images of the size(s) needed compressed,
then expand a fresh copy when deployed. Like…
# Pick an appropriate image size
if [[ ${needed} -gt 16 ]] ; then
img=DOS32MB.tar.gz
elif [[ ${needed} -gt 8 ]] ; then
img=DOS16MB.tar.gz
else
img=DOS8MB.tar.gz
fi
# extract a ready to go copy of DOSDISK.IMG from an archive
tar -xzf ${img}
# mount disk image
# copy executable files to DOSDISK.IMG
# unmount disk image
# boot DOSDISK.IMG for testing compiled executables
Of course, there are other ways to handle all of this.
For example, you most likely could just use one single larger pre-made
image. After all, 64Mb is not a lot of disk space and would be an
enormous DOS program.
Personally, I think you should just go with a single larger compressed
"ready to go” image and not worry about it much.
:-)
Jerome
Thanks very much for your helpful post. i will follow your suggestion. I
think I will try to keep the image under 50Mb so that it can be
zipped/tarred and emailed to others.
Have a great week-Pat
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
