NetBSD/atari Frequently Asked Questions
NetBSD/atari Frequently Asked Questions
- What does "St-mem pool exhausted, binpatch 'st_pool_size'" mean?
- What does "dma-ready: code = 2" mean?
- What does "NetBSD bootblock not on primary AHDI partition" mean?
- What does "Does not support linked commands" mean?
- Can I tell my Atari which OS it should boot?
- How do I increase the number of virtual consoles?
- Can I change my screen colors and resolution?
- What is the floppy device scheme?
- What is the hard disk partitioning scheme?
- Can I create a disklabel on my disk?
- Can I fix the link between a SCSI target and a device node?
- Why doesn't NetBSD use the time I set my system clock to?
- Can I override the normal boot sequence?
- What do I need to get X11 running?
- Using (Iomega and MS-DOS formatted) Zip disks
- Riebl card jumper settings
- Termination on the TT SCSI-bus
- Serial ports (which is which)
- PCI DMA problems on the Hades
- A new atari mouse (from a serial mouse)
- NetBSD Serial Port Primer
- NetBSD on the Atari TT030 Wiki
- ATARI Document Archive
- Atari TT030 Hardware Reference Manual
- Atari TT headquarter
- The documentation for TOS
This is the frequently asked questions list for the
Atari port of NetBSD. It was compiled by Rainer J. H. Brandt
<email@example.com>. Most of the answers
were written by Leo Weppelman
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.
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
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.
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
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.
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.
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.
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.
To change the number of virtual consoles, you have to build your own kernel.
The atari console driver is built of the following components:
viewis an abstraction of the video hardware.
- This is the graphics driver. This driver deals with
the screen in graphics mode. The X11 driver accesses the
grf-driver is layered above a single
- This is the terminal emulator. Each
ite-driver is layered above a single
There is a 1-1 connection between the layers.
grfxx2 that talks to
the TT and Falcon,
cc, on the
et.) For autoconfigure purposes, the
grf-devices are grouped as a bus, the
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
ite0/grfxx0 are always defined. To
be exact, they are defined in the file
which is included in all config files. The minimum number of
virtual consoles is 1.
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?
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
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
Notice: There seems to be a
problem with ICD-formatted disks. Try to mount them without
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)
- 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.
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
sd1. When you add a new disk with scsi-id 0, the old
disks will become
the new disk becomes
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
sd2 getting a different name.
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
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
/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.
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
date [-u] +%Y%m%d%H%M.%S>/dev/rtc
If your RTC runs in UTC, supply the
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`
/etc/rc.local (or something equivalent).
See also the rtc(4) manual page.
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.
- 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:
- You may also want to get the xcomp set (you will need it if you want to compile any X11 software).
- 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/Xto 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
- Type the command
startxto start X.
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).
"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.
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.
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.
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 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...)
- 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
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.
- 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.
- 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.
Other sources of informationEtherNEC.
Back to NetBSD/atari Port Page