[Oberon] PO2013 - SD Image Tool

Michael Schierl schierlm at gmx.de
Sat May 16 13:51:52 CEST 2020


Hello,


Am 16.05.2020 um 11:43 schrieb Tomas Kral:

> Thinking about a tool, outputting files to RISK.img file.
> Could run on System-V (Overon07 code) or RPI (c code).

When running such an image tool inside the Oberon filesystem, you have
to keep in mind that this filesystem has a maximum file size of about
3MB. This is sufficient for small images, and if you do not care too
much about performance of large files (as they are rare), it can be
quite easily lifted:

<https://github.com/schierlm/Oberon2013Modifications/tree/master/RemoveFilesizeLimit>


> Image.Create - initialise empty image with header
> Image.Add Modules.bin (Inner Core), Viewers.rsc, .., System.rsc,
> Oberon.rsc ~
>
> I expect a difficult part updating system directory info.

When running it inside the Oberon system, you can save a lot of work if
you use copies of FileDir and Files (and call them ImageFileDir and
ImageFiles), so you don't have to implement the logic yourself.
ImageKernel could then look like this (this has more functionality than
what you need):

<https://github.com/schierlm/OberonEmulator/blob/4ccd9174124e7a42546ff6946277ca8869ae0ddf/Oberon/ImageKernel.Mod.txt>

And ImageTool which can initialize the filesystem and add files would
look like this:

<https://github.com/schierlm/OberonEmulator/blob/4ccd9174124e7a42546ff6946277ca8869ae0ddf/Oberon/ImageTool.Mod.txt>

This does not cover adding the inner core, as I added support to my boot
linker to write the inner core into a filesystem image, but since this
requires just a copy loop, it could be easily added.

If you prefer to do it on your Raspberry Pi, you may want to have a look
at Peter's Project Norebo at
<https://github.com/pdewacht/project-norebo>.

> Looking for hints and examples, I could then code on my own, if not too
> difficult, and not silly idea.

Not too silly. Still the file size limit may limit its uses.

> This would lead to a compact image <= 64M

I am not sure where your figure of 64MB comes from. The default
filesystem offset requires a padding of 256MB (+512 bytes), so if you
include the padding, the image would always be larger than 256MB.

If you look at existing filesystem images that do not include the
padding (e.g. those bundled with Peter's emulator), they are about
900-1000 KB, so far away from 64 MB (and they include source code). A
minimal image I built some time ago (without compiler or source code)
weighs about 180 KB.


Nevertheless, if your main goal is to "shrink" images you have (after
you deleted files you don't need), a slightl less silly idea (that is
not limited by the maximum file size, and can be easily run
periodically) would be to write a defragmenter. I did it here:

<https://github.com/schierlm/Oberon2013Modifications/tree/master/DefragmentFreeSpace>

It will first increase the image size by the amount of used space (by
creating copies of all files), but then it will move them all to the
beginning and write an end marker to the image so that you can cut off
the unused part.


Regards,


Michael


More information about the Oberon mailing list