NetBSD/atari Frequently Asked Questions

General Information

What is this document about?

This is the frequently asked questions list for the Atari port of NetBSD. It was compiled by Rainer J. H. Brandt <brandt@ph-cip.uni-koeln.de>. Most of the answers were written by Leo Weppelman <leo@NetBSD.org>. When the personal pronoun "I" appears, it is often Leo Weppelman speaking.

It is strongly recommended that you read the INSTALL documentation accompanying the latest NetBSD release.

If you have any questions on NetBSD/atari that are not answered here or in INSTALL, ask the port-atari mailing list.

Kernel messages

What does "`St-mem pool exhausted, binpatch 'st_pool_size'`" mean?

Note: This section does not apply to the Hades.

The "St-mem pool" is allocated at boot-time. It is located in the lower 16MB of memory. It is used by drivers for Atari peripherals that were designed for the old 1040 ST that had an 24-bit address bus.

As it is currently impossible to specify where to allocate memory at run-time, there is no other way to allocate this memory at boot-time, before memory management is setup.

The St-mem pool is currently used by the video, floppy and the Falcon SCSI driver. The SMALL030 kernel supplied has a rather small St-mem pool. This is done to enable it to boot in systems having only 4Mb of ram. In fact it has a pool just big enough for 2 virtual consoles in ST-mode.

You can extend the size of the pool by binpatch-ing the kernel. In ftp://ftp.NetBSD.org/pub/NetBSD/arch/atari/binpatch/, you can find a binpatch binary and manual page.

For setting the St-mem pool size, issue the following command from the shell prompt:

  binpatch -l -s st_pool_size -r <new_size> <path to kernel>

The value of new_size should be given in bytes and depends on the following:

  video-resolution:
       ST-mode:    : 32KB + 8KB slack
       TT-mode     : 154KB + 8KB slack
       Falcon modes: size = (width * height * depth)/8 + 8KB slack
  Falcon SCSI bounce buffers:
       I think 16KB per SCSI target will do.
  Floppy:
       Maximum 1 track == 18KB

Note that each virtual console needs a video buffer. So you should multiply the value needed by the video by the number of virtual consoles defined.

What does "`dma-ready: code = 2`" mean?

You are probably suffering from SCSI parity errors. By default, parity checking is off on all devices.

The discussion of whether or not SCSI parity checking should work on all devices on the Atari has not yet ended. There were rumours of hardware problems but until now, I've not yet seen a sensible reason why it shouldn't work. In practice however, some devices will give a lot of parity errors. Note that the discussion is about the parity checking on the host adapter (the Atari), not about parity checking on the SCSI-targets. The Atari generates the parity bit correctly. So it should be possible to enable parity checking on the SCSI-targets.

The NetBSD/atari kernel has a "bitfield" describing on what targets parity checking should be disabled. You can modify it with the binpatch program. The exact command line is:

  binpatch -b -s ncr5380_no_parchk -r <new_value> <path to kernel>

Target 0 is the low-order bit and target 7 the most significant bit of the mask. So if you want to disable parity checking on targets 0 and 3, substitute 0x09 for <new_value>.

It is recommended that you enable parity checking on all devices that it works for. The parity bit was not invented for fun! Also, you should enable the parity check on all connected targets.

What does "`NetBSD bootblock not on primary AHDI partition`" mean?

An explanation from Udo Erdelhoff:

As you might know, every hard disk has a "root sector" that contains information about the size of the hard disk and the partitions on the hard disk. The root sector can only contain the necessary data for four partitions. Nobody thought that this limitation would cause any problems. After all, 640 KByte should be enough. As hard disks grew, it was necessary to define more than four partitions. In order to be more or less compatible with the old format, a new type of partition entry was defined: XGM partitions.

An XGM partition is a "look over there" sign: Another root sector can be found at the start of the XGM partition. This root sector contains the remaining real partitions. And this is the big mystery: Partitions defined in the root sector of the hard disk are called "primary partitions", partitions defined in the root sector of an XGM partition are called "extended partitions".

The bootblock will only work if the first NBD partition is a primary partition. This is not a limitation of NetBSD but a limitation of TOS/AHDI: You can only boot from primary partitions.

If you are creating your partitions with HDX, you'll have to be very careful to fulfill this rule. HDX has some very strange ideas when it comes to extended partitions. Fortunately, you can edit this stuff: The "Edit partition scheme of the unit" dialog box has a button label "expert". This button is inactive unless you have defined more than four partitions. Click on it after you have defined the sizes of the partitions.

A new dialog box appears on the screen. The left side contains two blocks of partitions: The upper block always contains the first four partitions, the lower block contains the last three partitions. If you have defined less than 7 partitions, some fields of the lower block will contain the string "unused". Some of the partitions will be displayed in reverse video: These are the extended partitions.

The right side contains six possible ranges for the extended partitions. It is not possible to define your own range, you will have to use one of the schemes offered by HDX. To quote from Ghostbusters: "Choose and die". The default scheme used by HDX is the first scheme: Extended partitions start with the second partition and end with the second to last partition. If you have defined 7 partitions, partitions #2 to #5 will be extended partitions, while partitions #1, #6 and #7 will be primary partitions.

You can move the extended partition range by clicking on one of the buttons on the right side of the dialog box. Try to find one where your first NetBSD partition is a primary partition. Golden rules:

If the disk contains no GEMDOS partitions, don't use AHDI. Let NetBSD handle it alone.
If the disk contains one GEMDOS partition, make it partition #1 and start the extended partition range at partition #3. This allows you to boot from both the GEMDOS and the NetBSD partitions.
If the disk contains two GEMDOS partitions, use partitions #1 and #2 for GEMDOS, partition #3 for NetBSD-root. Start the extended partition range with partition #4.
If your disks contains three or more GEMDOS partitions, you are in trouble. Try using partitions #1 and #2 as the first two GEMDOS partitions. Use partition #3 as the first NetBSD partition. Start the extended partition range with partition #4.

What does "`Does not support linked commands`" mean?

Linked commands is a method of chaining SCSI commands to each other. Usage of linked commands might be slightly faster on the SCSI-bus because the target selection phase can be omitted between linked commands. Some of the older SCSI devices are not capable of handling linked commands, some devices even choke on them...

To allow mixing older and newer devices, the atari SCSI-driver can be told explicitly to _never_ use linked commands on a target. This is done with the compile-time option 'TRY_SCSI_LINKED_COMMANDS'. This is a bit mask. A zero bit means: 'never use linked commands on this target'. A one bit means: 'try a linked command when appropriate, if the target gives an error on it, never try it again'. Another possibility is not to define this option at all, this will tell the SCSI-driver not to use linked commands at all.

Bits are numbered from right to left. Excluding target 0 gives a mask of 0xfe. Normally, target 7 (the host adapter == interface) is also excluded, giving: 0x7e.

System configuration

Can I tell my Atari which OS it should boot?

Yes. The Atari's clock chip contains 64 bytes of battery-sustained non-volatile RAM, of which only the first 14 bytes are used for the system clock. Of the remaining 50 bytes, 48 bytes can be used for other purposes. The highest two bytes contain a check sum. The XBIOS call 46 (NVMaccess) is available for reading and writing these 48 bytes.

(A side note for Hades owners: Although the Hades BIOS does not support the BootPreference-bit, the NetBSD boot loader will take it into account.)

When Atari was working on a System V port, it was decided to use the first byte for boot preference. While Waldi Ravens was working on a bootstrap loader for NetBSD/atari, he wanted to remain compatible with TOS and ASV. So he asked Eric Smith if it would be possible to reserve boot preference bit 0x20 for NetBSD. They agreed on the following scheme:

  0x80 - TOS
  0x40 - ASV
  0x20 - NetBSD
  0x10 - Linux

While in the NetBSD install program, you are given an opportunity to install bootblock code on your root disk. This requires a valid disklabel, though. (Also, see question 'Can I create a disklabel on my disk?') You can also install the bootloader and change the boot preference from a running NetBSD system. Read the boot_atari(8), bootpref(8) and the installboot(8) manual pages.

How do I increase the number of virtual consoles?

To change the number of virtual consoles, you have to build your own kernel.

The atari console driver is built of the following components:

view: A view is an abstraction of the video hardware.
grf: This is the graphics driver. This driver deals with the screen in graphics mode. The X11 driver accesses the console through grf. Each grf-driver is layered above a single view.
ite: This is the terminal emulator. Each ite-driver is layered above a single grf.

There is a 1-1 connection between the layers. ite2 talks to grfxx2 that talks to view2. (On the TT and Falcon, xx is cc, on the Hades, it's et.) For autoconfigure purposes, the grf-devices are grouped as a bus, the grfbus0.

If you want to have 3 virtual consoles, your config file looks like:

  pseudo-device      # View (graphics mapping)
  grfxx1 at grfbus0  # second graphics driver
  grfxx2 at grfbus0  # third graphics driver
  ite1 at grfxx1     # second tty
  ite2 at grfxx2     # third

The devices ite0/grfxx0 are always defined. To be exact, they are defined in the file std.atari which is included in all config files. The minimum number of virtual consoles is 1.

Can I change my screen colors and resolution?

Yes, you can. Take a look at the iteconfig(8) manual page. TT owners can change the colors/height/width and depth. Falcon owners can change colors, but can they change depths?

What is the floppy device scheme?

On TT030 and Falcon, floppy devices are coded as follows:

  /dev/fd0a -  default (720KB or 1.44MB, specified by the config switches)
  /dev/fd0b -  360KB
  /dev/fd0c -  720KB
  /dev/fd0d - 1.44MB

ISA floppies on Milan use a different scheme:

  /dev/fd0a -  360KB
  /dev/fd0b -  720KB
  /dev/fd0c - 1.44MB

What is the hard disk partitioning scheme?

  partition a: A root-filesystem (if any)
  partition b: Swap space (if any)
  partition c: Whole disk (always :-) )
  partition d: First user/other partition
            |
            |
  partition p: Last user/other partition

The number of partitions that NetBSD can handle is currently 16 per disk. (That may be changed to 32 later.) When you mount a GEMDOS file system, don't forget to use the -G option (see mount_msdos(8)).

Notice: There seems to be a problem with ICD-formatted disks. Try to mount them without -G.

Can I create a disklabel on my disk?

Read the INSTALL document on this issue and consult the disklabel(8) and disklabel(5) manual pages.

Waldi Ravens remarks:

Disklabel(8) doesn't know anything about the AHDI partition table. It can only handle a NetBSD partition table. It is very old software, from the times that hard disks had a fixed geometry. Modern SCSI disks do not have a fixed number of sectors per cylinder, so you'll have to do some calculations here.

Guaranteed is the total number of sectors per unit (the size of partition c, the whole disk), which is provided by the SCSI driver. You'll have to figure out which values are best used for the number of cylinders and sectors per cylinder (depending on your partitions; it's best if partitions start and end at cylinder boundaries).

BTW, when you add a partition to the label, you must increase the number of partitions manually. It will certainly be improved. But disklabel(8) is not a platform dependent tool, so it's much more difficult to get some improved code in the main source tree.

I recommend that you:

never change the bytes/sector field.
choose a proper sectors/cylinder value, I suggest 1024, 512 or 256. (note that bsd-ffs can't use part of a cylinder, only complete cyls).
based on sec/cyl, set tracks/cyl and sectors/track, for example 512 sec/cyl => 8 tracks/cyl and 64 sectors/track.
determine the number of cylinders: (size of c partition)/(secpercyl) if the remainder is not equal to zero, add one to the result.
when splitting AHDI partitions, try to use sizes which are a multiple of the secpercyl value, and make sure it can be split in an integer number of cylinder groups (see newfs(8) option -c).
changing partition c is generally not a good idea.
the bsize, fsize and cpg fields are set by newfs(8), but it's usually a good idea to determine those values, when creating the partitions.

Can I fix the link between a SCSI target and a device node?

Currently, the device nodes for SCSI devices are assigned dynamically. For example if you have 2 harddisks at scsi-id's 1 and 2, they will have device numbers sd0 and sd1. When you add a new disk with scsi-id 0, the old disks will become sd1 and sd2 while the new disk becomes sd0.

To fixate the links, you have to build your own kernel. Go to the config directory and edit 'std.atari'. Currently the line for configuring disks looks like:

  sd*   at scsibus? target ? lun ?

If you change this to read:

  sd0   at scsibus0 target0  lun?
  sd1   at scsibus0 target1  lun?
  sd2   at scsibus0 target2  lun?
   |    |              |      |
   |    |              |      |

you can remove scsi-0 without having to worry about scsi-id's sd1 and sd2 getting a different name.

Why doesn't NetBSD use the time I set my system clock to?

A UN*X system expects its system clock to be set to UTC (Universal Time Coordinated). Your local time zone is used to calculate your local time. This only works if you link /etc/timezone to the appropriate file in /usr/share/timezone. If you live in Central Europe, for instance, use

  ln -s /usr/share/timezone/MET /etc/timezone

Daylight Savings Time will automatically be taken care of. This may break if your local politicians change the DST scheme. You will then need a new time zone file.

There is currently a problem with this approach: Files copied to a Gemdos partition from NetBSD will appear to have a modification time that is off by the difference between UTC and your local time. If you copy these files back to a NetBSD file system, this offset will double.

If you don't want your Atari system clock to run UTC, set it to your local time and symlink to UTC under NetBSD. Manually adjust the system clock for DST twice a year as you did in the past.

In kernels newer than mid-december 1996 (1.2B), there is a new device /dev/rtc. I consider it experimental - there is no consensus in the NetBSD developers group about this. In the meantime, it's there and you can use it and it has some side effects that you have to be aware of. Also, let me know what you think of it and your experiences using it.

Both the DST and TIMEZONE options are gone from the kernel config-files. When the kernel boots, it grabs the time from the RTC as if it were running in UTC. When the kernel is instructed to reboot/halt, it won't update the RTC device with the kernels idea of the time. This means that setting the date with date(1) will not change the RTC time. If you want to update the RTC, you'll have to do so explicitly using:

date [-u] +%Y%m%d%H%M.%S>/dev/rtc

If your RTC runs in UTC, supply the -u flag. For a clock running in local time, omit it. In the latter case, you have to reset the date during startup too. Add a line

date `cat /dev/rtc`

to /etc/rc.local (or something equivalent).

Can I override the normal boot sequence?

Keep the right Shift key down right after the memory test is finished (i.e. just after power-on). You will get a prompt in the loader, and you can specify an alternative kernel name there.

If there is no working kernel on the NetBSD partition, you can use the floppy with loadbsd.ttp on TOS. To skip the NetBSD loader to boot into TOS, keep the Alternate key down right after the memory test. You can also enter the command .t<return> to boot TOS on the above prompt invoked by the right Shift key.

What do I need to get X11 running?

You need a kernel with 3 views (or at least one more than there are ite's).
Make sure the "ST-mem pool" message doesn't appear during system startup. (See the answer to the question on St-mem pool exhausted.)
Get the following binary installation sets from the NetBSD/atari 5.0 distribution:
```
  xbase.tgz
  xetc.tgz
  xfont.tgz
  xserver.tgz
```
You may also want to get the xcomp set (you will need it if you want to compile any X11 software).
```
  xcomp.tgz
```

Unpack the sets you retrieved:

  # sh -c 'for name in x*.tgz ; do tar --unlink -C / -xzvpf $name ; done'

In case you are using a pre-1.4 Xserver, you have to uncompress all the X11 fonts. The current distribution contains fonts compressed with gzip, but the old atari X servers cannot read compressed fonts.
```
  # cd /usr/X11R6/lib/X11/fonts
  # sh -c 'for name in * ; do ( cd $name && gzip -d *.gz && mkfontdir ) ; done'
```
Make a symlink from /usr/X11R6/bin/X to the correct X server for your video hardware. For example:
```
  # cd /usr/X11R6/bin
  # rm X
  # ln -s XF86_FBDev X
```
Copy the right config file to /usr/X11R6/lib/X11/XF86Config.
Type the command startx to start X.

Using (Iomega and MS-DOS formatted) Zip disks

Iomega 100MB Zip disks designated as PC100 (_as_is_ right out of the box) can be mounted as follows:

  # sleep 100 < /dev/rsd*c &
  # mbrlabel sd*
  # mount -t msdos -o rw,-l /dev/sd*a /mnt

Note that the file structure of the disk will not be modified by these steps. Replace the '*' by the number your Zip-driver got during the device probing. Study the output of 'dmesg' for the occurrence of 'ZIP' to determine this. Include the '-l' option to maintain Windows 95 long filename support. Performing a 'disklabel' on the disk should give you the following partition info:

  # disklabel sd*
        ...
  3 partitions:
  #        size   offset     fstype   [fsize bsize   cpg]
    a:   196576       32      MSDOS                        # (Cyl. 0*- 95)
    c:   196608        0     unused        0     0         # (Cyl. 0 - 95)

After mounting, 'df' should yield the following (if you 'rm' the demo program from the disk first):

  # df
  Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
  /dev/sd*a       98078        0    98078     0%    /mnt

If a Zip disk is formatted under Windows 95 _without_ Iomega Zip Tools installed then only the following command is required to mount it:

  # mount -t msdos -o rw,-l /dev/sd*c /mnt

After mounting, 'df' (with no files or directories) should yield:

  # df
  Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
  /dev/sd*c       96050        0    96050     0%    /mnt

If you 'mbrlabel' a zip disk with this latter format then you will get the following:

  # mbrlabel sd*
  Warning: NetBSD partition 'a' includes AHDI bad sector list

At this point you will need to start over (using eject sd* is an easy way to do this).

Hardware configuration

Riebl card jumper settings

     "top side"
    +-----------------------------------------------------------------+
    |                                                                 |
  A++  +-----+                                                        ++
  U||  |  A  |  ++                                                    ||
  I||  +-----+  || D                                                  ||
   ++           ++                                        +-+         || VME
    |                                                     | |         ||
    |                                                     | | C       ||
  B |                                                     | |         ||
  N-+                                                     +-+         ||
  C |                                                         +---+   ++
    |                                                         +---+ B |
    +-----------------------------------------------------------------+

  jumper array A (J1-J6):
    all to bottom -> BNC (thin Ethernet)
    all to top    -> AUI (thick Ethernet)

  jumper D (J7)
    to top    -> BNC (according to Udo there should be NO jumper!)
    to bottom -> AUI

  jumper array C (J17-J23):
    all closed -> TT
    all open   -> MegaSTE

  jumper array B (J8-J10)
    meaning unknown. Jumpering on Udo's and mine TT-card: closed/open/closed


  There is additional info about the jumper 'D' settings. According to
  Doug Duchene, he has a card that has only two pins installed on jumper
  'D'. It only allows the "top" setting. For his card, the description
  should read:

  jumper D (J7)
    shorted -> fused power (+12vdc) to pin 13 of the AUI connector.
    open    -> no power available at pin 13 of the AUI connector.

Termination on the TT SCSI-bus

As you might know, a SCSI-bus should be terminated on both ends of the cable (no more, no less!). On a stock TT, the internal hard disk is on one end of the cable (and thus should always be terminated), the host adapter is in the middle and the external connector is on the other end of the cable.

     +---------------+
     |           |  '|
     |           |   | (The ' gives the location of the 3 packs - note
     |===============|  that this was supposed to be a top view...)

All TTs have sockets for terminators located near the SCSI connector on the back (see picture above). Not all TTs have the resistors inserted. These resistors should be inserted only when no external device is present and be removed otherwise. In the latter case, the external device at the end of the chain should be terminated.

Serial ports (which is which)

The following table should clear up some confusion:

  text     devicename  new name   driver   chip       supported  see note#
  ========================================================================
  serial1  /dev/ser01  /dev/ttyB1          68901       No
  serial2  /dev/ser02  /dev/ttyA0  zs0     ZS8530      Yes        1
  modem1   /dev/mdm01  /dev/ttyB0  ser0    68901       Yes        2/3
  modem2   /dev/mdm02  /dev/ttyA1  zs0     ZS8530      Yes

On the Hades and the Falcon, this port is only available as a 'lan' connector.
The Falcon has no connector for this port.
You can use this port as a console. When DCD is supplied during the device probing, the mdm01 port will become the system console.

To add some more confusion in serial driver land, the column 'new name' was added. What gives... Since the introduction of the dialin/dialout split in April 1998, the original choice of the atari-bound tty names turned out to be clumsy. At that time it was decided to adhere to the NetBSD-standard convention of tty[A-Z][0-9] for dialin and dty[A-Z][0-9] for dialout devices.

PCI DMA problems on the Hades

It seems that if you have only one FPM (Fast Page Mode) SIMM in the Hades, DMA to PCI cards becomes erratic. I even had frequent kernel crashes during playback on my soundcard. It looks as if memory gets corrupted. The problems seem to stem from the fact that burst-access is not possible with an odd number of SIMMS (I only tried one, not three...). This fact was more or less confirmed by Fredi Aschwanden. The problem should not occur when EDO SIMMS are used, but I cannot test this.

A new atari mouse (from a serial mouse)

What do I need to buy?

a 3 button serial mouse. I used a Trust-mouse, but the description can easily be adapted for other mouse types.
a piece of 9-wire cable. This must be as flexible as possible!
a 9 pin subD connector
4 47k resistors 1/8 watt
an 74HC14 (hex schmitt-trigger)
maybe an extra resistor (read on...)

What equipment do I need?

a soldering iron (max. 35Watt, thin point)
a solder sucker
some small gauge wire
a piece of shrink sleeve
a hobby knife (to cut unwanted PCB tracks)
some experience in soldering is mandatory

Part one

Before making the mouse unusable as a serial mouse, see if you can identify the following items:

the IR-LEDs
the photo transistors (there might be 4 of them when they are not integrated as indicated by the dotted box in the schematic).

Also, follow the trace connecting the IR-LEDs. There should be a resistor in this path. The extra resistor you need should have approximately the same value as the resistor you find here.

Part two

start removing the components you don't need (IC, crystal). Keep the traces and holes intact and remove solder from the holes. You might want to re-use the holes.
find some suitable spots for the power-supply (+5v + GND). These usually have the most wires connected too...
build the circuit for the IR-LEDs, buttons and connect the elco (watch the polarity!). Cut traces if you have to...
Identify the traces from the photo-transistors that you need to connect to. When you have, put the 74HC14 on its back on the pcb and figure out how you can connect the resistors to the traces and the 74HC14. Put the resistors in place (adding shrink sleeves when you feel it's necessary). When that's done, put a piece of double-sided sticky tape on the back of the 74HC14 and stick it onto the pcb.
connect the resistors (as shown in the schematic) and the power supply to the 74HC14 (+5 = 14, gnd = 7).
make a visual inspection of your work. It's much easier to correct things without a few meters of cable attached.
Connect the 9 pin subD connector to one end of the cable. Write down the colour/pin relations.
connect the other end of the cable to the various points in the modified mouse.

Part three

attach the mouse to your atari and power on the atari. If the power led on the atari doesn't light-up within a second, turn off your atari immediately and start looking for shorts or other problems.
start GEM or X to see if your mouse works. There are a few major problem areas:
- none of the buttons work - very unlikely unless you made a cabling error.
- the middle button does not work - the connection between mouse connector pin 5 and joystick pin 1(??) is missing. You will have to make that yourself.
- the mouse movement is flaky - add the extra resistor by soldering it parallel to the existing resistor in the IR-LED circuit. Since the power supply has dropped (from approx. 15V to 5V), the IR-LEDs may not provide enough illumination on the photo transistors.
- one or all of the movements are reversed - exchange XA with XB or YA with YB (dependent on the reversed direction ;-)
frob a bit with the cable throughput. Since the new cable is thicker than the original, check the functioning of the middle button with the cable below it.

NetBSD/atari Frequently Asked Questions