On May 25, 11:24am, Patrick Vervoorn wrote:
> What should I do now? The kernel looks pretty stable (is it Michael? :),
> but I definately need new binaries... What I'm also wondering about is, how
> do I do that? What should I build first? A new ld.so? Something else? Any
> hints and/or tips would be appreciated.

  I have been able to binpatch the the kernel enough to get it to run with
the older binaries.  If anyone is interested in the patches required, I
can probably write something up what needs to be patched.  This would allow
people to use the new kernel with the old binaries until a new binary
distribution is available.

> And, what would 'supping' gain me over getting the .tar.gz snapshots from a
> sun-lamp mirror?

  Supping allows you to get only the new files that have changed since the
last sup, instead of having to ftp the entire tar file(s).  If you're updating
infrequently, the tar files are probably ok, but if you want to keep real
up to date frequently, the supping is more efficient.  Also, the tar
snapshots are weekly, so if you get a snapshot what won't compile, you either
have to fix it yourself, get the required changed files individually, or
wait for the next week's snapshot (and hope that it's not broken).  One other
advantage of supping the kernel changes is that you don't need to get all
the other architecture-dependent files.

> While I'm on the question-asking tour, what is the status of the memory
> management changes that were suggested quite a while ago? I have the
> feeling NetBSD-Amiga is still far from usable in 4megs of RAM (and I mean
> this with regard to console-only stuff). Even with 8megs (which I have) I
> find memory still rather tight. Of course, I should just plunk in another
> 8megs and be done with it, but I find that a rather silly solution. :)

  I put a little fix in that reduces the number of kernel page table pages
allocated, but it only does that on systems with 4MB or less.  I had thought
about doing it for 8MB or less.  The fix allows 4MB systems to run in
configurations where they wouldn't run before the fix.  I don't know if the
fix will help 8MB systems that much, but it's very easy to change.

> Also, I can remember the '040 support consisted of setting up a complete
> level-[123] (?) page-table of about 60KB for every process started. Is this
> still the case? If so, that would explain why I have so little memory left
> after booting into multi-user mode. (I have 8 meg, but it leaves me,
> according to vmstat, with about 300/400KB of free memory. Of course stuff
> gets swapped out after a while.) Are there any plans to fix this? Is it
> even fixable or is it a 'feature'?

  It's fixable, but a real fix would require some significant rewriting of
the pmap and amiga_init code that I haven't had to time (or ambition) to do
yet.  The hp300 port has some changes that will help, but that code has
just been put into the -current source tree very recently.  I hope to
take a look at it and see if I can add those changes to the Amiga stuff.

> After trying Linux/68k a while back, I couldn't help notice that their
> console is much (MUCH) faster than NetBSD-Amiga's console, due to which it,
> on the whole, just 'feels' (a lot) faster than NetBSD-Amiga. Is there any
> chance the NetBSD-Amiga console could get any faster? Also, Linux/68k has
> support for some neat (AGA?) modes (720x400@70Hz NI, 640x400@76Hz NI, etc).
> Could the implementation of these be of any help to NetBSD-Amiga?

  The Amiga console was much faster before Chris Hopps rewrote the console
stuff to use views.  The trick is to have a copper entry for each line of
text, so when you need to scroll the screen, you just update the copper list
instead of having to copy all the bitplanes.  The Amiga Minix console was
done that way and after I fine-tuned it a bit, it would scroll stuff so
fast on my 68040 system that it was hard to see what was being output.

  I'd love to add some AGA modes, but I don't have a monitor that will accept
any of the them.

Michael

-- 
Michael L. Hitch			INTERNET:  osymh@montana.edu
Computer Consultant			BITNET:  OSYMH@MTSUNIX1.BITNET
Office of Systems and Computing Services
Montana State University	Bozeman, MT	USA

------------------------------------------------------------------------------