On Fri, 27 Oct 2000, Dave Daniels wrote:
> In article <Pine.NEB.4.29.99999.0010231725510.22973-100000@localhost>,
>
>    David Brownlee <abs@netbsd.org> wrote:
> > 	Action items from the show:
> >
> > 		- We need to find out if we can distribute memfix inside
> > 		  !BtRiscBSD for RiscOS 4 users.
>
> This is needed for people with the Kinetic card for sure. The
> problem is that the SWI OS_Memory with R0=7 that is used by the
> bootloader is broken with RISC OS 4.03 but memfix cures it.

Doh, so it's only needed for kinetic systems?  I wonder what the table looks 
like without the memfix patch (IE if we could detect if the patch was there 
and work with or without, then again the PRM's document what it's meant to 
provide...)

> > 		- !BtRiscBSD defaults to 1024x768 - users with monitors unable
> > 		  to display that resolution need to exit a config file to
> > 		  run - that should be fixed.
>
> This is wrong. The second screen of the !BtRiscBSD configurer
> options allows the screen resolution to be set. I have found that
> with NetBSD 1.4.1, 640 by 480, 1024 by 768 and 1280 by 1024 work
> fine but the screen is corrupted in 800 by 600.
>
> If you do not specify one of the resolutions given above the
> console driver appears to default to 1024 by 768. Perhaps 640 by
> 480 or 800 by 600 (once it is working) would be better.

It's the default in !BtRiscBSD, as there are a few bits that may need looking 
at with BtRiscBSD it might be a case of changing the default string...

> > 		- The number of supported resolutions should be expanded.
>
> Is this tied in with the previous point?

possibly, my thinking was to get more of the same modes but different refresh 
rates.

> Don't quote me on it, but I have a vague recollection of seeing
> some monitor mode definition files in the arm32 kernel source.
> Maybe I should have another look...

Yes the modes are based on a mode definition file (from a Taxan I believe)

> > 		- Need to determine if !BtRiscBSD can boot gzipped kernels.
>
> It does not. It assumes that the kernel is unpacked, but how
> complex is the code to un-gzip it? Although I do not know what
> would be involved, I cannot see, in principle, any major
> difficulties in adding support for gzip'ed kernels.

It would be an useful feature to add (the reason being that the real kernels 
on the CD I did were gzipped, the install ones weren't, and the ones that are 
downloaded are normally gzipped as well.)

Chris