On Wed, 3 May 2000, Michael Lorenz wrote:

> > > > > ... then loaded the kernel and died. Second time I remembered that I had
> > > > > to switch to 256 colours first...
> > > > *grin*  Anyone feel like fixing rasops?
> > > My knowledge of Acorn hardware is - well, limited. Next to nonexistant.
> > 
> > This job doesn't require any particular Acorn knowledge, just an ability
> > to try to code portable, fast rasterop code in C.
> Hmm, did kind of this in assembler on x86, but someone must provide me
> with information about the video memory organization in 4-bit color on
> the Acorn ( planes like on the Amiga ? one byte - two pixels ? ) and how
> to set the palette...

Don't worry about the palette -- that's my problem.  The pixel format is
simply little-endian packed pixels, so in a four-bit mode, the
least-significant four bits of the first word (or byte) of screen memory
is the top-left pixel of the screen.  Other bit-depths work
analogously.  If you're going to fix the rasops code, though, the first
thing that needs doing is to make it properly endianness-independent.

> not to talk about a cross compiling environment
> for NetBSD/(i386 or hp300) or Solaris/SPARC, whatever may work.

I sent message to the list a few days ago about this.
<URL:http://mail-index.netbsd.org/port-arm26/2000/05/02/0003.html>
Basically, it's still non-trivial.

> > > What about switching the screenmode in BBBB ?
> > 
> > I'd rather not, but I'll get it to print a warning if it thinks things
> > won't work.  That way, the old bootloader won't get in the way when the
> > kernel finally supports lower bit-depths.
> Hmm, it could ask wether it should switch to 8bit / same resolution when
> possible ? At least as long as the kernel dies in anything else than
> 8bit

It only dies in 4-bit.  In 1-bit and 2-bit the screen display is
interestingly garbled.  Anyone who's not tried booting in a 1-bit mode yet
should do so -- the result is rather fun.

Working out which screen mode is equivalent to the current one at a
different depth is non-trivial, since it involves snarfing the mode
database and reading through it.  Better would be to have the kernel
change screen mode to something it can handle, but changing screen modes
is mildly tricky (it involves actually thinking about DMA timings).

> Cool ! I'll try it later ( no time today ) and send you the results... 
> btw. - what does the kernel expect when it asks for a root device ?
> simply ea0 to make it RARP and rpc.bootparam ?

Actually DHCP.  I'll turn on RARP/bootparam if people want it.

> Sorry, can't keep it back - how hard is it to make the internal IDE on
> A5k style machines work ? 

Should be easy enough, but I'm not trying it without the hardware in front
of me.

-- 
Ben Harris
Unix Support, University of Cambridge Computing Service.