Hi Leo,

> > First the positive hints, I recognize:
> > 	- it supports my new Falcon FX memory extension card
> > 	  (message 8 MB RAM after starting BOOT-kernel)

If I understand correctly, currently the info for the FX is taken from
a cookie, or something similar, which is provided by an auto folder
program?

What I'm interested in is, how can I recognize the FX card if NetBSD
is *not* booted from TOS, but directly by the boot loader in sector 0
of your harddisk. Does anyone have information about the hardware
registers?

> > Some negative hints (not important):
> > 	-  the TOS-tools: chg_pid, rawwrite, and loadbsd are not "user-friendly"
> > 	   i.e. they don't wait for RETURN after finished work, 
> > 	   so one couldn't recognize status or error msg on GEM, because
> > 	   the output screen dissapeared at once

You could run them from a text shell. Mupfel is quite nice under TOS, and
allthough it's shareware, you don't have to pay for it at the moment, the
price has gone down to DM 0,00 for quite some time now.

> Yes we did. Loadbsd.ttp _should_ wait when it is about to exit to TOS,

Loadbsds output behaves very strange when running it from a shell under
MagiC. Not that it really matters to me, just a FYI. :-) Maybe it's a
problem of the libc (which one are you using?).

> The disklabel recognition code has been significantly changed (improved)
> by Waldi to allow for NetBSD labels. We decided on strong checking in
> the AHDI-label code. The idea was that at (nearly) any cost, we should
> avoid messing up existing partitions. It turns out that not all partition
> programs follow the rules exactly and there is - of course - the possibility
> of bugs and/or thinko's on the NetBSD side. To analyze the AHDI-partitioning,
> Waldi has written a small program to check things. I'll send this to
> you by private e-mail. If people on the list are interested, I'm willing
> to put it on the list too. In time it will be available from the ftp
> server.

I've just mailed the sources to you. Since at least Helmar would like to
run these tools from a gem window, I'll probaly add an option to redirect
the output to a file (currently aptck is intended to be run from a shell
that understands about output redirection).

It would be nice if everybody who gets these 'illegal TOS partition table'
messages from TOS would run aptck and send the full report to the list.
Then we can see where things are going wrong and release some of NetBSDs
strong checking a bit. Or alternatevily, I can extend aptck to automatically
fix a `broken' partition table (*if* it turns out that it's really the
labels causing the problem and not the kernel code).


Waldi