> der Mouse <mouse@Rodents.Montreal.QC.CA>


> >> Then I have no idea why it failed.  What happened when you tried to
> >> boot from the resulting partition?
> > Varied.  But, always consistent with "crud" getting dragged in and
> > executed (aren't any sanity checks done on the image as it is
> > loaded??? even a magic number test???).
>
> Perhaps.  But if the crud is the _second_ block of the file, the magic
> number can be intact and still end up executing garbage.

Yes.  Hence some *better* form of sanity check (even a simple
checksum... doesn't take more than a handful of instructions to
implement!)

> > For example:
> >     Instruction Access Exception
> > (sorry, may be misremembering this... notes are in the other room)
>
> Probably trashed code, yeah.
>
> Does your root partition include anything beyond the first 1G of the

Drive is only 365M.  So, if there is anything beyond 1G, I'd *love*
to know what it is!  :>

> disk?  I'm wondering if your ROM version has the 6-byte-CDB limit.
> Copying /boot into / could "fix" it then because files in / will often
> end up entirely in cylinder group zero, whereas if the file is created
> in /usr/mdec it usually will be in some "random" higher cg and quite
> possibly past the 1G point.  (If you copy /usr/mdec/boot to (say)
> /usr/mdec/fnord and then mv /usr/mdec/fnord to /boot, instead of
> copying /usr/mdec/boot to /boot directly, that could reveal the
> difference.)

So, this is yet another caveat that isn't documented in the man page??


> This is exactly the symptom you get if the boot file is past - or
> partially past - the 1G point: everything but the low 21 bits of the
> block number gets ignored, so blocks past the magic boundary end up
> reading as a predictable but otherwise unrelated block below the
> boundary.  (Writing is no problem, since the writing code is NetBSD's,
> which doesn't have the limitation.  But reading goes through the ROM.)
>
> >> (7.5K isn't really much room, even when you don't have to do the
> >> actual disk I/O yourself.)
> > I guess that's relative... designed a LORAN-C position plotter in
> > *12K* (and that had to do *all* the I/O as well  :>)
>
> Perhaps your skill at tightening code up would be valuable in this
> endeavour.  Fitting functionality into small amounts of space is a much
> less common skill now than it has been in the past.  I know I don't
> have nearly as much of it as I'd like....

I can recall a boot loader for a Nova 3 that fit in 32 words (16 bit) of
core...
the sort of thing that gives you nightmares when you need to add *one* more
instruction  :>

--don