Subject: Re: HEADS UP : New bootloader for RISC OS based machines commited
To: Chris Gilbert <chris@paradox.demon.co.uk>
From: Reinoud Zandijk <imago@kabel065011.kabel.utwente.nl>
List: port-arm32
Date: 02/18/2001 14:00:00
Hi Chris,

On Sun, 18 Feb 2001, Chris Gilbert wrote:
> On Sunday 18 February 2001  1:26 am, Reinoud Zandijk wrote:
> > The new bootloader features a new clean startup mechanism that isnt RISC
> > OS version specific anymore as well as a much cleaner and more
> > maintainable. It also features a clean and rock steady loader mechanism
> > that puts the kernel in the correct place before calling it. This means
> > the end of the relocation of a running kernel as the old bootloader
> > demanded.
>
> That reminds me, any reason you did it in BASIC?  Looking over the existing
> bootloader it's all in standalone C, only the gui config stuff needs desklib.
> The reason I ask is that I've looked over the BASIC program and can't follow
> half of it as I'm very rusty at BASIC these days.

The reason for this is simple since it doesnt need compiling (and i dont
have a `C' compiler for RiscOS) but there is no reason why it can't be
written in `C' ... its just that it can be tweaked under RiscOS without
depending on a complete compilation environment / library. It also
eliminated the `chicken and the egg' problem for me.

> > The newest version of the bootloader is allways available at :
> > ftp://ftp.netbsd.org/pub/NetBSD/arch/arm32/bootloader.arc
>
> shouldn't that be:
> ftp://ftp.netbsd.org/pub/NetBSD/arch/arm32/riscos/

I stand a 100% corrected .... sorry for that .. i gave the wrong URL.

> > Next to the MemFix module needed for Castle Kinetic card machines.
>
> To do what with it?  We need it, without it we don't work.  (Castle even
> updated their FAQ to include the solution for how to get netbsd working!)

Well I thought that was evident but i'll include it in next version...
sorry about that too :)

> > P.S. sorry for the reddish colour as yet :( .. switching VT's will solve
> > it but will propably be solved when wscons is included.
>
> Who's fault is the red colour, the bootloader?  or the kernel making an
> assumption that the bootloader has done something with the palette?

Yep I think the later... allthough i cant find any colour/VIDC stuff in
the old bootloader ... maybe i've overlooked something but i couldn't find
it.

Cheers,
Reinoud