Re: [Freedos-user] Bootable FreeDOS CD for BIOS flashing

[E. Auer]

Hi! I think for BIOS flashing, a good way would be to start
with a minimal boot floppy image, you can find that online
for FreeDOS. Or use one with more apps on it and remove
some of them to make space. Then, you mount or open the
image with a free tool (depends on the OS, in Linux you
can use mtools as user or actually mount the image if you
are admin, as well as using any of various other methods)
to add the BIOS flash tool and BIOS file to it.

Next, you use the boot floppy image to make a CD or DVD
bootable in emulation mode. Most BIOS variants support
booting from 1.2, 1.44 and 2.88 MB floppy images and a
variety of CD/DVD writing tools let you specify an image
if you select that you want to make a bootable CD/DVD.

The advantage is that you will not need any CD/DVD drivers
which could interfere with the BIOS flash process, or any
other drivers apart from those that the flash too might be
needing. And of course keyboard drivers, if you like. For
many cases, you can use the small MKEYB to cover popular
layouts without needing additional data files.

The disadvantage is that the booted DOS "floppy" will be
read-only and that it will not have access to the rest of
the CD unless you also put the CD drivers on the "floppy".

You could probably also work with MEMDISK and a Linux
style boot menu instead of the pure BIOS floppy image
boot method. This will allow compressed floppy images
and writing, but of course any changes will be lost as
soon as you reboot the PC, because the floppy image is
never updated by MEMDISK. Changes only exist in RAM.

Also, MEMDISK again is a bit like a driver, so it can
interfere with your flash tool.

Of course, the best way would be to have a BIOS which
supports loading a BIOS file from any connected drive's
root directory, including USB sticks, without having to
boot anything from those, but a BIOS which is too old to
boot from USB will also be too old to have that feature.

Regards, Eric



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Bootable FreeDOS CD for BIOS flashing

[Betibeteka Beranduetxea]

Hi all, first post here.

I did some different searches on this forum archives but all gave me
thousands of results. Some of them from more than a decade ago. So forgive
me for being still another guy asking about for a bootable FreeDOS CD for
BIOS flashing.

I'm hoping some of you could give a pointer to a thread, blog, website,
etc, where this has been done and where it's explained clearly.

What I would like is to compile and burn a bootable CD with the flash
utility of my election and the BIOS update file. Well, more than one flash
utility/ BIOS update probably. Then I could put that CD on storage for next
time I need to fiddle with still another old computer BIOS.

It would be nice to have a localized keyboard, too.

Floppies aren't an option, really, even if I still have a couple of floppy
drives lying around. I have found that floppies aren't a good long-time
storage medium, and now they are ridiculously priced. USB booting isn't an
option either; I have found many times that those old systems doesn't boot
from USB. Same for PXE LAN booting. So CD booting seem the better way to go
to me.

Any pointers would be greatly appreciated
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] ISO repack reduces size by 10%

[E. Auer]

Hi Jerome and Darik,


  1. Unzip each FDN package.
  2. Further unpack each ZIP and 7Z source file.
  3. Zip+Store each SOURCES/* tree like it has LFN.
  4. Rezip each FDN package like usual.
  5. Optimize each package with AdvanceCOMP.


I suggest a much shorter algorithm: Simply apply
advzip with the "recompress" option to the ZIP
files :-) Without unpacking them and zipping them
again etc. Also, the advcomp/advmame tools can be
configured to put extreme effort in compression,
but from my experience with advpng, you already
get most of the possibe disk space reduction at
medium settings :-)

It is interesting that you also got savings with
arj and bz2-zip, but ZIP in the DOS compatible
variety (people with ancient PKZIP may enjoy the
ability to unzip without having to use INFOZIP)
I would not "overdo" things. Also, UNZIP can work
on old hardware with low RAM, which LZMA or BZIP
style algorithms do not necessarily offer. As far
as I remember, there may have been a license issue
behind not using RAR, but others may know more on
that point.

You can do mass-recompression of ZIP files with
advzip with your favorite shell (BASH for example)
so it does not take much effort to recompress the
whole repository once. I propose to use ZIP -o on
each file afterwards to reset the timestamps to
the newest timestamp of the contents, though!

Of course before this is done on the whole repo,
somebody with PKUNZIP2 has to volunteer to tell
us whether an example advzipped ZIP is still fully
compatible. As far as I remember, this was one of
the design goals of advcomp, so I am optimistic.

About the diskette edition: One question probably is
whether you want to use DOS from floppy or whether
you want to install it to harddisk. In the latter
case, you could just put everything into one tar or
7z with global (not per-file) compression applied
to have the smallest number of install disks, but
you would have less flexibility that way. And with
floppy, it is better when a broken sector only lets
installation of one of many zips fail instead of a
whole install.

However, I do not think that ANYBODY has drives
with less than 360k capacity. In particular, the
last time I touched a PC with 360k-only drives,
it did not have any harddisk, so you would not
need any type of installer to run there either.

Regards, Eric



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] ISO repack reduces size by 10%

[Jerome Shidel]

Hi Darik,

> On Nov 8, 2021, at 6:55 PM, Darik Horn  wrote:
> 
> Hi all,
> 
> The FreeDOS repo ISO file that was published today can be reduced from 632MB 
> to 579MB by repacking it. This adds 53MB of media headroom, which should 
> reduce pressure to bump packages in future point releases.

Just a note regarding the FreeDOS repo ISO... The Repo ISO image is mostly 
provided just as a convenience. The creation and publishing of that ISO is part 
of a fully automated process that is handled by the repository management 
utilities. Once per day in the early morning hours, the management utilities 
check to see if any packages have been added or updated. When it notices that 
occurred, it gathers all of the latest versions for each package and generates 
a ISO out of them. The creation of that ISO is not very complicated. However, 
it is not just a simple copy and burn image. It also goes through and generates 
listing and other metadata files for programs like FDNPKG and FDIMPLES. It also 
generates a bunch of “flat” html pages for that image as well.

There are several “packages” that are not in the repository at present that may 
be added later. There are various reasons for their current exclusion. 

For example, someday PC/GEOS[1] may be added. I have not discussed it with it’s 
developers for quite a long while. But, the last time I did, they did not feel 
it was ready for general public use/testing. That may be different now. Anyhow, 
the full version of that is around 120MB.  

I only see the total amount of software in the repository growing over time. 
Assuming we continue to provide a convenient download ISO that contains all of 
those packages, we will need a long term solution. That would probably involve 
splitting package groups onto separate images or possible a dvd iso. 

> 
> Original (as of 2021-11-08):
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/cdrom.iso
>  
> 
> 
> Repack:
> https://drive.google.com/drive/folders/1b7IE-EsK5R1ROmXTaEvYNi9-kfVvH5wi?usp=sharing
>  
> 
> 
> The procedure is:
> 
>   1. Unzip each FDN package.
>   2. Further unpack each ZIP and 7Z source file.
>   3. Zip+Store each SOURCES/* tree like it has LFN.
>   4. Rezip each FDN package like usual.
>   5. Optimize each package with AdvanceCOMP.
> 
> The size at each step is:
> 
>   660,869,928 bytes, original
>   629,362,932 bytes, rezipped with InfoZip 3.0
>   605,766,821 bytes, optimized with AdvZip 2.1
> 
> Everything stays in zip format 2.0 and remains compatible with PKUnzip 2.04g 
> and FDNPKG.
> 
> Supposing that other ARCHIVER/* formats were implemented by the FreeDOS 
> packaging system, the cdrom.iso size could be:
> 
>   627,403,406 bytes, ARJ (-jm)
>   557,334,645 bytes, ZIP/BZ2 (-9)
>   495,380,042 bytes, RAR2 (-m5 -mdE -mm)
>   449,729,467 bytes, 7Z/LZMA2 (-mx9 -ms=on -mqs=on -md=1m)

The test results you’ve provided are interesting. They definitely show an 
improvement over the current packages. It would be better to recompress the 
packages when they are added to the repository. There are several benefits to 
doing it at that point.  As you have noted, it would reduce the space required 
on the repo ISO. It would also reduce the space used on the server and download 
size/time for individual packages. 

Recompression is something that will be considered for the next version of the 
repository management utilities. The current version of the repo utils is 
something like version 3 or 4. I haven’t really been counting. Nowadays, the 
management of the repo is fully automated. It makes things much easier to 
manage. For example, we can just push an updated package on the server and walk 
away.  It will do a bunch of verification stuff on the package and repository 
itself. Locate the older version. Version out the different copies. Adjust some 
symlinks for updater programs like FDNPKG. Create metadata and index files. 
Create/update static browsable HTML files from customizable templates. 
Maintains an RSS feed. Builds repository status vs previous OS release 
comparison charts. Publishes a package ISO.  And a couple other things. 

There are plans for a new version of the repo management utilities. There are a 
number of new features and things that can be improved. Just for example… Image 
and screen snapshots for packages. Improved directory versioning hierarchy. 
External software metadata (HTML pages for software not in the repo and link to 
an external website). And many many more.

> 
> UnRAR 2.50 is particularly impressive because it is 16-bit, fast, and will 
> extract on an 8088 with 640KB of memory. It also has an output size 
> competitive with the kind of 7-Zip 19 archive that can be extracted by 7ZDEC.
> 
> For fun, I also replaced SLICER with RAR and reduced the number of 
> installatio