bob@kunk.jriver.com wrote:
> My Performa 575 with 36mb ram and fast 2 gig hard drive w/ hacked 800x600 video
> is up and running on 1.4C 19990606 release  as of today.

cool!
 
> A few observations...
> 
> X works in 16 bit mode @ 800x600 with the onboard video and the newest OSFA
> server, COOL, THANKS!!!
> 
> The receive speed of the apple comm slot card with the sonic chipset is UNREAL.
> sn0 at obio0 address 00:a0:40:2b:c6:24
> I did a good sized ftp test receiving to /dev/null, 800k/sec on receive! Wow.
> Considerable slower on xmit, more like 170k/sec but that will include disk
> access of course.

i generally find we're a lot faster than macos on networking :-)

> A couple of error messages...
> 
> iwm0 at obio0: Apple GCR floppy disk controller
> iwm: Chip revision not supported (-77)
> -I didn't REALLY expect this to work...

i get something similar on my q840av, i think

> 
> PRAM time does not appear to have been read correctly.
> PRAM: 0x83da82c4, macos_boottime: 0x3763b7f2.
> -Is this normal?

more or less, although yours is off by quite a bit, so maybe not.  is the
time set correctly for you under netbsd?

> Then finally, I got the same weird behavior when trying to install the
> "sets" from the distribution as I did with 1.3. Here is the symptom.
> I partitioned the drive with the patched apple hd setup util,
> made the filesystem (80 megs swap sd1b and 2g root&usr sd1a) with mkfs145 and
> went to install the base. After some period of time the install gets "write
> errors" and dies. Then I can't write to it at all. The only way I can
> get the OS installed is to first make the devs, then install etc (which
> goes cleanly if it is first) then the base.tgz. The install of the base gets
> most of the way through before dying. I then cpin the rest of the
> .tgz sets to the nstbsd root, boot to netbsd in single user mode and 
> install all of the sets and X with gzip -dc file | tar xvf -
> commands. Usuable but kind of a pain...
> It's NOT a drive problem, does the same thing with several different
> drives and anyway, once in unix the drive behaves perfectly.

the above is a fairly common experience.  when we switch to a
sysinst-based install, this problem will hopefully go away...

later.

colin