Simon Wood writes:
>
> > The advent of nano-X and graphics under ELKS, together with this discusion
> > has set me thinking more seriously about ROMing ELKS.
> >
> > In the bath last night (as always) I thought about how I could modify ELKS
> > so it would run without a filesystem, and came up with a way of storing
> > binary images in an area of ROM. The ROM would simply contain all the
> > binaries in minix format concatenated together, the header of each aligned
> > to a 16 byte boundary. The unused field of the header could contain a
> > 4 character unterminated string which identifies the binary.
> >
> > exec would then be recoded to search this area of ROM for the binary in
> > question, leaving the text segment and running it in place. The
> > initialised
> > data would then have to be copied into RAM, but very little RAM would be
> > required as only the kernel and program data segments would need to be
> > stored there.
> >
> > Any thoughts anyone?
> >
> > Al
> [<Simon Wood>]
> Hi Al (and others),
> my thoughts were along a similar approach. But I feel that the ROM File
> System should integrate with the VFS and allow the storage of any type of
> file. We know that the contents are NOT going to change (it's ROM!!) so
> perhaps we could used a small area as a Fixed-FAT that could reference the
> individual items on the drive.
The ROMfs code that has already been ported to ELKS is very good for this
sort of thing, and I have set up the filesystem code so that a compiletime
option can be specified to remove all the filesystem code related to
writing to actual filesystems. This would allow a very small kernel to be
created that could run binaries from a compact ROM filesystem. I think we
should have the option of going further than this and removing the
filesystem and block device code, and just loading binaries as described
above so that ELKS can be used in systems where the memory is very tight,
and only one or two binaries are required.
>
> Providing the ROM area was mapped into main memory the loader could be made
> to create a new data segment and point to the ROM code segment. Perhaps this
> would be easiest if the ROM executables were of a slightly different type
> (i.e. not true minix), maybe just with a different magic number. As building
> the ROM filesystem image would be a one off task, it wouldn't be too much to
> do a conversion from minix to special
The minix executable format is quite well suited to being run in place on a
ROM filesystem, providing as you say that filesystem is mapped into the
main address space.
>
> This sort of thing could also be applied to a RAM only system, for example
> the Psion 3a - which I'm doing some work on.
One of the things I keep in mind is the Psion port. A filesystemless kernel
would be easier to boot on the 3A initially until we have sorted out
getting a RAMdisk image loaded.
>
> As a side comment about Psion stuff-
> I've got a keyboard scanning working and some basic screen stuff, but I need
> to find a 'free' bit mapped font to use (probably want 8*13 bits per
> character to make it readable, would be really flash if it was anti-aliased
> to include a grey and much easier on the eye).
> Any suggestions......
>
Have you looked at the fonts that come with X11? They are nice and clean,
and seem to work in a good range of sizes.
Al
