> : Yes. Fortunately the DEC system boots a bootloader out of the first n
> : (16?) blocks of the disk, so only the boot loader need know about
> : where to find the kernel. In my mind, this boot loader is just a
> : modified version of lilo...
> Yup. Heck, you could replace the read/write/open commands that are
> there now with ones of your own and it should just work. I have a dim
> memory of Andy saying that he did this to test it under an OS that is
> POSIX compliant before rebooting the machine...
Yes, this are the original idea when I wrote that stuff. Aside of that
these wrapper routines also proofed to be a wonderful place to hide
ARC BIOS workarounds. And then there is this stupid (C) problem with
the ARC documentation that we also solved that way. I hope we can finally
solve that in direction of a fully GPL'ed Milo source as soon as SNI gives
us ARC docs.
> : Yep - I'm sure that with the right amount of fussing with GNU config
> : files, we could build gcc/binutils that knew about all formats: a.out,
> : ELF, ECOFF, ECOFF-DEC... at least, I sincerely hope we can so that we
> : have a single consistent development tool chain.
> Likely... I'm still trying to figure out how to get my elf tools to
> generate ECOFF, but I haven't looked hard.
Look at the Milo source tree. Milo uses the normal a.oout or ELF compiler
and links the output to ECOFF. Just a single option. As alternative
setting the environment variable GNUTARGET to the desired target would
also work but I think this is inconvenient.
> Hmmm, I recall that the 4G DAT drives are about US$500 here in the
> states generally. Not cheap, but not horribly expensive.
> One of the other hacks I want to do at some point is to hack FreeBSD's
> dump program to automatically compress the data before writing it to
> tape and restore when reading it back from tape... Don't know if my
> machine is fast enough to keep up with it. However, what I have now
> works, so I'm not massively motivated just yet.
Just say "Backups are for wimps" ;-)