See http://www.macbsd.com/macbsd/macbsd-docs/machine-status/ for a fairly up-to-date list.
[ Waiting for new ADB ROM driver, after which I will create a file similar to the machine-status file for working & non-working ADB devices. ]
For now, check out the INFO Sheet
[ Again, I will ask everyone for this information soon and create a file called video-card-status. ]
In general, 24-bit video cards seem to have some trouble (there is no support for 24-bit video at the moment anyway).
For now, check out the INFO Sheet
[ At some point, I will create an accelerator-card-status file ]
Currently, both the 33MHz Daystar 030 Accelerator and the 50 MHz 030 Accelerator are known to work. You may need to disable the external cache via the control panel first. A DiiMO 50 MHz '030 accelerator also appears to be working, as does a Dove MaraThon 030 accelerator for a Mac II.
Work is underway by Kevin Radke (radke@cpre1.ee.iastate.edu) on enabling the cache on the Daystar accelerators. If you would like to try one of his kernels out, they can be found here:
ftp://cpre1.ee.iastate.edu/pub/netbsd/
Some 040 accelerators for 040 machines might also work. However, there appear to be some difficulties getting 040 accelerators for 030-based machines working, but work is in progress on getting a Carrera040 accelerator to work.
Check out the INFO Sheet for more information on accelerator card status.
Check out the Ethernet Status page
For the FDHD (i.e. MFM format, high-density floppies), here's the word from Ken Nakata (kenn@eden.rutgers.edu):
It doesn't work because we don't have any kind of documentation as to how to control SWIM chip directly. Calling ROM routines for the floppy is probably unwise since it will disrupt NetBSD's multitasking (ever noticed the frozen mouse cursor on Mac OS when accessing the floppy?).
As for low-density floppies, Hauke Fath (saw@sun0.urz.uni-heidelberg.de) has developed a very experimental IWM driver in an LKM. The relevant files are:
ftp://ftp.macbsd.com/private/hauke/README.iwm
ftp://ftp.macbsd.com/private/hauke/iwmModule.tar.gz
As Hauke notes, use this kit at your own peril.
The current kernel supports the Apple Sound Chip, so it will beep at you on the console and using the newest version of dt (version 1.1.5). However, it may not work under the X Window System. See the below for more details. Machines with the EASC or other sound chips will not currently work under NetBSD (the EASC in my Q700 only clicks). Work is in progress on further sound support, however.
Only if you have a 68020. An AMU is not enough.
The current kernels will boot on a machine without an FPU, but programs requiring an FPU will fail without one or built-in FPE (floating-point emulation), causing the machine to drop into the debugger. Fortunately, this problem has almost been solved (see the note below on the 'LC040, though).
A note from Ken Nakata (kenn@eden.rutgers.edu):
Any recent kernel has FPE (floating point emulation) built in it, albeit incomplete. So, if you want an FPE kernel, get a current kernel.
Anyone running NetBSD/mac68k without a hardware FPU, please obtain and install this math library files for FPU-less environment:
ftp://ftp.macbsd.com/private/kenn/libm-nomc68881.tar.gz
This gzipped tar file contains libm (math library) which avoids use of some of mc68881 instructions, thus you hopefully won't get "unimplemented instruction" error with the current, incomplete FPE implementation (what I'm trying to do here is very similar to what i386 people have been doing for years).
If you wish to build your own version of the FPU-less math library, apply
the following patch from Ken to the Makefile in
/usr/src/lib/libm and do a make && make install:
*** Makefile~ Sun Oct 26 10:28:48 1997
--- Makefile Sun Oct 26 10:30:30 1997
***************
*** 61,70 ****
# s_sinf.S s_tan.S s_tanf.S
.elif (${MACHINE_ARCH} == "m68k")
.PATH: ${.CURDIR}/arch/mc68881
! ARCH_SRCS = e_acos.S e_asin.S e_atanh.S e_cosh.S e_exp.S e_fmod.S e_log.S \
! e_log10.S e_remainder.S e_scalb.S e_sinh.S e_sqrt.S s_atan.S \
! s_ceil.S s_copysign.S s_cos.S s_expm1.S s_finite.S s_floor.S \
! s_log1p.S s_logb.S s_rint.S s_scalbn.S s_sin.S s_tan.S s_tanh.S
.elif (${MACHINE_ARCH} == "vax")
.PATH: ${.CURDIR}/arch/vax
NOIEEE_ARCH=n_infnan.S n_argred.S n_sqrt.S
--- 61,67 ----
# s_sinf.S s_tan.S s_tanf.S
.elif (${MACHINE_ARCH} == "m68k")
.PATH: ${.CURDIR}/arch/mc68881
! ARCH_SRCS =
.elif (${MACHINE_ARCH} == "vax")
.PATH: ${.CURDIR}/arch/vax
NOIEEE_ARCH=n_infnan.S n_argred.S n_sqrt.S
The above patch should work cleanly with NetBSD 1.3 sources. Earlier (and
perhaps later) releases may require patching by hand.
Please note that the 1.1 distribution kernel does not include FPE. The 1.2 distribution kernel does include FPE (as do later kernels).
It should be noted that even though FPE support does now exist, machines based on the FPU-less 68LC040 chip are not fully working (even with the recommended math library mentioned above). Typical symptoms are frequent "illegal instruction" errors and segmentation faults. Work is in progress to fix this bug, which should enable many more people to have a more or less fully usable MacBSD machine. For more information on the 'LC040 FPE issue, check out Ken's page:
http://www.macbsd.com/macbsd/LC040-and-BSD.html
Kelly Campbell recently found and fixed a bug which caused most of the segmentation faults due to 'LC040 FPE. However, FPE still does not produce the correct results for some operations on the 'LC040.
We did. It turns out that Software FPU is basically an exception handler that calls SANE. It is not an FPU emulator. Work on FPU emulation is in progress by Ken Nakata.
See the previous answer for more information.
Internal video works on the II-series Macs with internal video. Internal video for Quadra/Centris-series Macs should be working for most models as of the NetBSD 1.3 release. You may have to check the "LC575 video hack" box in the Booter's "Booting Options" dialog box in order for some machines to work (Booter 1.11.1 and later). PowerBook internal video may or may not be working. Please note that only monochrome support is available at the moment. Color support is in the works though.
Check out the machine status document for more details:
http://www.macbsd.com/macbsd/macbsd-docs/machine-status/
Connected to localhost.
Escape character is '^]'.
telnetd: All network ports in use.
Connection closed by foreign host.
From Ken Nakata (kenn@eden.rutgers.edu):
You are out of ptys. By default older versions of the Installer only
create four of them. There could be maximum of 64 ptys (/dev/ptys0 through
/dev/ptysf besides the ones you listed above). To create more of them, go
to the /dev directory and (as root) type:
sh MAKEDEV pty0
That'll make 12 more ptys (ptyp4 through ptypf). The default number of ptys for GENERIC configuration is 16, so it may not help even if you created more ptys by typing:
sh MAKEDEV pty1
If you need more than 16 ptys, you will have to compile your own kernel
after having increased both the maxusers line and the
pseudo-device pty line in the kernel configuration file.
Note: The versions 1.1e or later of the Installer do create all 16 ptys that configured into a GENERIC kernel by default. However, a bug was found in this routine that wasn't fixed until 1.1f, so please use that version or later.
Try setting your 'main' monitor in Mac OS to the internal screen if it's not already set that way. This has been known to work.
SCSI devices under NetBSD are numbered starting from 0 in the order of SCSI
ID number. In other words, you lowest-numbered SCSI device will be
/dev/sd0, the next device will be /dev/sd1, etc. Notice
that this is the assignment that they are given during the boot process.
If you compile your own kernels, you can set the SCSI devices to point to any SCSI ID number you want with a line like:
sd0 at scsibus0 target 4 lun 0
sd* at scsibus? target ? lun ?
Yes, Bill Studenmund (wrstuden@loki.stanford.edu) has written a ghostscript driver for it. He has this to say about it:
I've got my DeskWriter up, so maybe I can help.
Don't use the LocalTalk connectors.
Don't use printcap to set up the port. lpd uses the old tty setup
routines, so it can't access some of the cool (and needed) features
of the modern tty stuff (I've forgotten the names of the various
routines, so I'm vague). Also, it's hard-coded to not like bauds above
19200 or so. I forgot exactly where the cutoff is, but AFAIK the
routine called to set the baud rate won't be happy with 57600, so it's
more than just lpd.
I've got a "stty -f /dev/tty01 raw 57600 crtscts" in my rc.local script.
For you, I'd suggest "stty -f /dev/tty01 raw 57600 crtscts opost onlcr".
This will: turn off all character processing, set the port rate, set
hardware flow control (which was implimented just so I could get my
DW to work), and then turn on output processing so that UNIX's NL's
get turned into CR's.
Or if you can wait a bit, I have a simple input filter which sets
the DeskWriter to accept NL's as CR/NL pairs, then prints the file.
this way, we don't need the stty output processing, so we can dump
PCL code directly to the printer & print graphics.
And the followup from Bill:
I've got GhostScript to work with my DeskWriter printer.
To get gs to work, just download my stuff from
ftp://ftp.macbsd.com/pub/NetBSD/contrib/gs
.
gs262.mac68k.tgz is a gzipped tar file containing my gs binary, the
changed source files, all the files needed to install gs, some
documentation, and nenscript, a freeware version of enscript. The
documentation is still rough, and someone is looking at it for me to
see how bad it is. :-)
ghostscript-fonts-2.6.2.tgz is a BUNCH of PS fonts to make gs more
useful.
The other two files are source code. You don't need thm, but you might
want them. :-)
So try them out & let me know what you think.
Yes, thanks to Monroe Williams (monroe@pobox.com), there is now a driver for the Color StyleWriter 2400 which should also support the StyleWriter I and II (and presumably the StyleWriter 1200 as well). Monroe has this to say about his driver:
A new version of my StyleWriter driver for NetBSD is available at:
This driver works on the Color StyleWriter 2400 (in B&W and
color), the StyleWriter II and the StyleWriter I (*). It may or may
not work on other models -- guinea pigs are welcome. ;) There are a
number of improvements over previous versions, including better
serial port control, better buffer management for faster printing
and better configuration through runtime options.
(*): My SWI broke just about the time the 2400 started working, so I
can't test the SWI anymore, but I expect it should still work.
From Ken Nakata (kenn@eden.rutgers.edu):
Anything which supports Apple Extended Mouse Protocol. However, I know of only Logitech MouseMan/TrackMan that do support the protocol. For some unknown reason, each manufacturer seems to have decided to reinvent their own wheel.
With the standard Apple mouse and a keyboard, the middle and right buttons are emulated by pressing the option key and left and right arrow keys, respectively. Logitech mice do not emulate the middle button; they return each button's status in separate bit.
You should be able to use a 3-button mouse from Logitech, MouseSystems, or their compatibles on PC, too. At least that was my experience with NetBSD 0.8 with XFree86 (a long time ago).
Note, however, that key stroke generation is simulated by the device driver for Mac OS on some mice. If that's the case, you won't be able to generate the option-arrow sequence under NetBSD/mac68k.Further information regarding about the Extended Mouse Protocol is available on Apple's web site at http://developer.apple.com/technotes/hw/hw_01.html#Extended Apple Mouse Protocol
If you are using a 1.2G or later kernel, you can also emulate all three buttons by pressing "option-1", "option-2", or "option-3". However, this is by default switched off in the GENERIC kernel. See FAQ 9.22.
Do the following:
/dev/cd0? exists.
cd /dev; sh MAKEDEV cd0
mkdir /cdrom
mount -t cd9660 -o ro /dev/cd0c /cdrom
Yes. From Jack Culpepper (jack@cs.hmc.edu):
Look for the pin numbers on the monitor connector and short out pins 4 & 11 (monitor sense lines) with a paper clip. (I've been using this for months.) Another method is to spend $25 on an SVGA adapter that can be configured to emulate a mac display.However, you probably cannot boot a machine which lacks any kind of video hardware at all (e.g. an older II-series Mac without a NuBus video card), since it may not even boot into Mac OS in this configuration.
For more information on the video connector pin configurations, Apple has a TechNote on the subject:
http://developer.apple.com/technotes/hw/hw_30.html
Thanks to Nigel Pearson (nigel@ind.tansu.com.au) for the above pointer.
Yes, NetBSD/mac68k follows the UNIX tradition of having only 8 partitions per disk. Increasing this limit will be quite an effort, but it is a project in the works for NetBSD 1.4. This limit causes a problem for older kernels, since NetBSD would not check more than the first 8 partitions to see if they contained usable filesystems. Since the Apple drivers and partition maps among other partitions often lie at the front of the disk, NetBSD partitions could have been overlooked. However, more recent kernels (definitely NetBSD 1.2 and later) will scan the first 32 partitions on the disk for NetBSD partitions. This should take care of most people's problems. Keep in mind that the partition lettering scheme only allows for about 6 usable partitions (i.e. a, d, e, f, g, and h; b is designated as swap and c is the raw disk interface).
This problem results from a recognized but as yet unfixed bug in the
ncrscsi driver. For some reason, it seems to attack Quantum drives more
often than others. The usual symptoms are that under heavy disk usage, the
drive light suddenly stays on, but the system is hung. After rebooting, an
fsck run will turn up rather nasty filesystem damage. Sometimes you
may not notice the damage until you try to run some binary file and realize
that it is now a device file instead (i.e. its directory listing looks
something like b--------- or c---------).
In order to fix the problem, Scott Reynolds (scottr@og.org) wrote the sbc scsi driver to replace the standard ncrscsi driver. Since this driver operates in polled mode by default, it is a little slower and more CPU-intensive than the stock ncrscsi driver (especially on slow SCSI devices like CD-ROM's and tape drives). However, it is much less likely to corrupt your data. Scott recommends that you use it instead only if you are currently having trouble with the stock ncrscsi driver.
Recently, Scott has made several changes to the driver, improving stability with MO drives (the driver no longer causes medium damage/partially written blocks) and performance with several and/or slow targets. Scott has this to say about the performance improvements:
I've just checked in several changes to the `sbc' SCSI driver that should
allow it to perform better with several and/or slow targets. More
specifically, disconnect/reselect is now supported without having to
enable the not-quite-cooked `blind' mode transfers. Note, however, that
there is an ambiguity in the SCSI specification regarding the behavior of
a target when it disconnects, so there is a chance of data corruption. If
you are not familiar with and/or comfortable with dealing with broken file
systems, please read no further.
To enable this mode in the driver, simply add a `flags 0x5' to the sbc0
line in your kernel config file, like so:
sbc0 at obio? flags 0x5
The actual performance of the driver will decrease slightly if you have a
single SCSI target, but if you do any measurements, the performance will
probably take an apparent jump for the better! The reason for this
paradox, if you will permit me to call it that, is that the driver eats up
so much CPU doing PDMA without allowing the target to disconnect that it
misses clock ticks while it is waiting for the disk to fetch the requested
data. This change allows clock ticks to be caught most of the time, to
the point where a `lost' tick due to SCSI access happens far less often
than those due to heavy Ethernet activity (I'm seeing my IIcx's clock
drift by <90 seconds per day). It also allows slow devices, such as tape
drives, to relinquish the SCSI bus tell the CPU to go do something else
for a while.
Finally: If your target is one of those that is affected by a looser
interpretation of the SCSI specification, it will require an SDEV_AUTOSAVE
quirk in the quirk table in sys/scsi/scsiconf.c. I believe there is some
work going on to find a better overall solution to the problem, but a
local modification to your tree will certainly do the trick for now. How
will you know if you're affected? Usually, a corrupted file system
results very quickly; I trashed the superblock on some of my disks at
least a half dozen times while working on this driver and checking for the
need for the quirk on them. (Good thing there's a backup copy!)
The driver should be no more and no less stable than previously. It
should certainly be more `correct,' but there is at least one bug
remaining in the machine-independent part of the driver that causes
trouble when dumping a kernel core to disk after a panic. I'm also aware
of trouble on at least one IIci, though I have personal experience with 2
such machines that are running well (and in fact, one of them _requires_
the sbc driver).
There are several kernels compiled with the newer driver, so you will probably want to use one of them instead. They are usually named something like GENERICSBC or kernelname-SBC. Recent kernels with the SBC driver can be found at:
ftp://ftp.NetBSD.org/pub/NetBSD/arch/mac68k/new/
Needless to say, you will need to delete and then reinstall any of the corrupted or missing files (I keep and extra copy of base.tar.gz around for just this purpose).
However, the ncrscsi driver may not be the sole source of your problems. Remember that many SCSI problems are the result of bad SCSI cables or poor termination. Both ends of a SCSI chain must be terminated. Also, you might consider buying shorter, higher-quality cables or an active terminator.
Yes. You can either dig into the console source code (look at ite.c),
which would be rather difficult, or you can get a copy of the dt
program. The dt utility supports a number of useful features,
including inverse video. You will need to modify the config.h file to
define INVERSE and recompile in order to get this mode. You can find
the dt utility at:
ftp://ftp.macbsd.com/pub/NetBSD/utils/dt/dt-1.1.5.tar.gz
First, you'll need to be able to compile your own kernel. Then all you have to do is comment out the line:
options DISABLE_EXT_CACHE
The ADB hanging problem which only seems to affect those machines with dirty ROM's (i.e. the SE/30, II, IIx, and IIcx...although I've only seen problems reported on the IIcx and SE/30). The manifestation of this problem is twofold:
1) Sometime after NetBSD 1.2.x, these machines would hang during boot if they didn't have both a keyboard and a mouse attached.
2) Kernels from Nov 7, 1997 onward would hang these machines if an extended keyboard is attached.
Note that this problem only seems to affect kernels using MRG_ADB. The HWDIRECT method appears to be immune.
The problem is that (on these machines at least), the hardware seems to create a "ghost" keyboard or mouse when none is attached. On newer machines, a subsequent probe of these devices indicates that they are not really there. However, for those machines listed above, a probe of the non-existant device hangs in an infinite loop awaiting a reply. The reason why this has only shown up since 1.2 is that the extended mouse support performs this kind of probe. The Nov. 7 change is a result of another probe added to support non-EMP Logitech mice.
The solution for now is to compile a custom kernel that uses HWDIRECT ADB support instead of MRG_ADB. To do this, simply comment out the line:
options MRG_ADB
ftp://ftp.macbsd.com/pub/NetBSD/eskimo.copy/kernels/
See the above Q&A.
Assuming that you have upgraded X along with the rest of the OS, the problem you are seeing is one that has affected a number of people using internal video on Quadra and Centris series Macs. It appears that support for 800x600 resolution might be broken in the 1.3 release kernel. Getting one of Steve Brown's MADHATTER kernels may help you:
ftp://ftp9.ba.best.com/pub/sbrown/NetBSD/kernels/
If you compile your own kernels, you will probably want to use the
following two patches which seem to work for most people. The first is the
MADHATTER patch, and should be applied to
sys/arch/mac68k/mac68k/machdep.c:
*** machdep.c.orig Sun Jan 25 18:19:02 1998
--- machdep.c Sun Jan 25 18:20:32 1998
***************
*** 2241,2246 ****
--- 2241,2249 ----
case MACH_CLASSQ:
case MACH_CLASSQ2:
mac68k_machine.sonic = 1;
+ /* The next two lines are the infamous "madhatter" patch */
+ mac68k_vidlog = mac68k_vidphys = 0xf9000000;
+ mac68k_vidlen = 1 * 1024 * 1024;
case MACH_CLASSAV:
VIA2 = 1;
IOBase = 0x50f00000;
This patch fixes a possible problem in the mode sense code in the internal
video driver (sys/arch/mac68k/dev/grf_iv.c):
*** grf_iv.c.orig Sun Jan 25 18:22:18 1998
--- grf_iv.c Sun Jan 25 18:27:53 1998
***************
*** 108,116 ****
sense = (bus_space_read_4(oa->oa_tag, bsh, 0x1C) & 7);
- if (sense == 0)
- found = 0;
-
/* Set "Turbo SCSI" configuration to default */
bus_space_write_4(oa->oa_tag, bsh, 0x24, 0x1d1); /* ch0 */
bus_space_write_4(oa->oa_tag, bsh, 0x28, 0x1d1); /* ch1 */
--- 108,113 ----
Thanks go to Steve Brown (sbrown@shellx.best.com) and Michael Zucca (mrz5149@cs.rit.edu) for providing the above patches.
At the moment, you don't. When the NetBSD/mac68k serial driver was converted to use the machine-independent version of the driver, this feature managed to break. According to Bill Studenmund (wrstuden@loki.stanford.edu):
The problem is there's a race condition with the present open code. If we have an external clock, we will enable interrupts before we have a chance to realize we shouldn't enable the status interrupt on that pin.
A clock on the CTS pin will be ok, with a minor change to the kernel (the #if 0 on line 825 of /src/sys/dev/ic/z8530tty.c needs to be an #if 1) (the CTS status interrupt isn't enabled by default. ;-)Work is in progress to re-enable this feature.
Table of contents of this chapter, General table of contents