Can all registered uses please login, even just for a few minutes..
It helps build a picture where our "good traffic" is coming from..
Thanks :)
It helps build a picture where our "good traffic" is coming from..
Thanks :)
WIP: A/UX 3.1.1 for the Atari Falcon030
- sascha.springer
- Posts: 19
- Joined: Wed Mar 25, 2020 6:56 am
Re: WIP: A/UX 3.1.1 for the Atari Falcon030
Great stuff, that's incredibly cool!
Re: WIP: A/UX 3.1.1 for the Atari Falcon030
Wow! Does it boot off a disk image on the Falcons HDD? Also do you think it might work on an 060 Falcon?
- sascha.springer
- Posts: 19
- Joined: Wed Mar 25, 2020 6:56 am
Re: WIP: A/UX 3.1.1 for the Atari Falcon030
I will see if I can get it installed on a HD Driver partition on my real Falcon today.Steve wrote: Mon Sep 07, 2026 6:47 pm Wow! Does it boot off a disk image on the Falcons HDD? Also do you think it might work on an 060 Falcon?
Re: WIP: A/UX 3.1.1 for the Atari Falcon030
Nice - and the shell is working too :p
d:m:l
BadMooD d/l: https://www.leonik.net/dml/sec_bm.py
SVO30 d/l: https://www.leonik.net/dml/sec_svo30.py
Q2 engine d/l: https://www.leonik.net/dml/sec_q2.py
AGT project: https://www.leonik.net/dml/sec_agt.py
Atari page: http://www.leonik.net/dml/sec_atari.py
YT: https://www.youtube.com/@dmlTPT
BadMooD d/l: https://www.leonik.net/dml/sec_bm.py
SVO30 d/l: https://www.leonik.net/dml/sec_svo30.py
Q2 engine d/l: https://www.leonik.net/dml/sec_q2.py
AGT project: https://www.leonik.net/dml/sec_agt.py
Atari page: http://www.leonik.net/dml/sec_atari.py
YT: https://www.youtube.com/@dmlTPT
- sascha.springer
- Posts: 19
- Joined: Wed Mar 25, 2020 6:56 am
Re: WIP: A/UX 3.1.1 for the Atari Falcon030
I have now a SD card image ready for IDE equipped Falcons (14MB RAM + MC68882 FPU). Unfortunately that image requires an RGB/TV monitor. If someone wants to test it: PM me. Beware: I haven't tested it yet due to time contraints. 
Code: Select all
# F030AUX on a card — write it, boot it
A/UX 3.1.1 for the Atari Falcon030, as a complete card image. Write it to a
CF or SD card, put the card on the Falcon's IDE port, and the machine boots
it: no HDDRUTIL, no driver to install, no files to copy.
This is bring-up software. It has been run under Hatari; **no part of it has
run on real hardware yet**, and you are the first. Everything it does is
reported over the serial port, so please have a terminal attached — that
capture is the whole value of a first hardware run.
## What the machine needs
- a Falcon030 with 14 MiB ST-RAM and a 68882
- TOS 4.04
- a CF/SD card of 1 GB or more on the internal IDE port (the image is 992 MiB
and leaves the rest of the card unallocated)
- a terminal on the Modem port at TOS's baud rate, 8-N-1
- for the graphical part, the desktop in 640×480 with 16 colours; on a 15 kHz
RGB monitor boot in a **50 Hz** mode first, or the bottom 80 lines of the
A/UX screen are not shown
## Writing it
sha256sum -c SHA256SUMS
zstd -d -c f030aux-card.img.zst | sudo dd of=/dev/sdX bs=4M conv=fsync
`/dev/sdX` is the whole card, not a partition — check it twice with `lsblk`,
and unmount anything the desktop auto-mounted first. **This overwrites the
entire card**, partition table included.
## Booting it
1. Put the card in, switch on. The terminal should show
F030AUX hd: the card's TOS partitions
F030AUX hd: driver at 000xxxxx
C: 00000040 0000f000
and the desktop should come up with a hard disk icon. That line is the
card's own TOS driver, in block 0: TOS has no partition mounter of its own,
so the card brings one.
2. **Run `F030BOOT.TOS` from C:** — it is in the root directory. It is the
fault probe: 13 stages of 68030 bus-fault behaviour that the port depends
on. It writes `F030BOOT.TXT` and reports to the terminal. `result: PASS`,
or please stop there and send the capture.
3. **Before trusting the card, check the byte order.** Run
`C:\F030AUX\FINDER\F030INST.TOS` and let it get as far as the partition
list, then quit with `q`. Two things to read:
- the drive's model string. If the character pairs are transposed
(`aHaticr DIsE` rather than a readable name), the Falcon's IDE interface
swaps bytes relative to the host that wrote the card, and the image has
to be written again with `dd conv=swab`. Everything else on the card is
then wrong too, so stop.
- the partition list. It must read `GEM start 64 blocks 61440` and
`RAW start 61504 blocks 1970139`.
4. **Boot A/UX: switch off, switch on holding Alternate.** Keep it held
through the boot. The loader takes the machine, the kernel comes up, and
the A/UX Login window appears on the Falcon's screen. Log in as `root`,
password `root`, and dismiss the two AppleTalk alerts.
Without Alternate the machine boots TOS as usual and the card behaves like
an ordinary TOS disk — the loader sees `C:\AUTO\F030AUX.INF`, finds no key
held, and stands aside.
5. **Shutting down:** Special → Shut Down in the Finder. The shim reports the
stop on the terminal; switch off after that. From a shell instead, `sync`
three times before switching off.
## The other two kits
The card carries three, under `C:\F030AUX\`. The one the machine boots is
whichever `F030AUX.TOS` and `F030AUX.INF` sit in `C:\AUTO` (as `F030AUX.PRG`
and `F030AUX.INF`), so switching means copying two files from the desktop:
| Kit | What it boots | Touches the disk |
|---|---|---|
| `RAMROOT` | a serial shell on a RAM root — the disk is never read | no |
| `TEXT` | a 4 MiB text root: single-user shell on the serial line | needs `F030INST.TOS` to install its root first |
| `FINDER` | the 928 MiB Macintosh root already on the card — the one that boots as shipped | no, it is already there |
`RAMROOT` is the gentlest first test of all: it boots A/UX to a shell without
reading a single block of the disk.
## If something goes wrong
The serial capture is what matters — please keep it whole, including the
lines before the failure. Useful detail: which step, what the screen showed
(a row of bombs is worth counting), and whether the terminal had stopped
before it.
## Contents
f030aux-card.img.zst the card image, zstd-compressed
SHA256SUMS checksums of the image and the compressed file
README-CARD.md this file
The image holds A/UX 3.1.1 and a Macintosh II ROM image. Both are Apple's,
neither is mine to give away, and this card is for your own testing of the
port — please do not pass it on.
- sascha.springer
- Posts: 19
- Joined: Wed Mar 25, 2020 6:56 am
Re: WIP: A/UX 3.1.1 for the Atari Falcon030
Update: VGA is now also available but still untested, though.
Re: WIP: A/UX 3.1.1 for the Atari Falcon030
Interesting! I just saw this, and was talking to the group working on updating Amix, and have started my own quest to update the Atari System V for TT, I'll start up my own thread for that. But I was thinking of having it updated with a bunch of stuff, namely to try to make it more like A/UX so it could run Atari and Unix software from the same OS. But... I kind of think these efforts should all be unified and we could get Unix working on both the Atari and Amiga computers, and get it to cross run Amiga/Atari/Mac software too... I mean, that'd be kind of sick! This is sweet though!
Apple seemed to be the one of the three to 'do it right' and make it so apple software could still work under Unix...
Apple seemed to be the one of the three to 'do it right' and make it so apple software could still work under Unix...
- sascha.springer
- Posts: 19
- Joined: Wed Mar 25, 2020 6:56 am
Re: WIP: A/UX 3.1.1 for the Atari Falcon030
F030AUX ports A/UX 3.1.1 to the Atari Falcon030. The base port works on real hardware: testers report that A/UX boots to the Login window and runs from an IDE card on a DFB1X-accelerated Falcon and from a SCSI card on a BlueSCSI, with the Macintosh environment. The drivers cover the console, IDE, SCSI, video, keyboard and clock. Known open problems there are the keyboard sometimes repeating a key and the boot loader failing at 50 MHz.
The current work is networking through a DaynaPORT SCSI adapter. A new kernel module and a small daemon give A/UX's own TCP/IP an interface called dp0. Under the Hatari emulator, with its emulated DaynaPORT, it works on both the IDE and SCSI setups. Ping, finger, a telnet login and an FTP transfer of 1 MB each way, bit-exact, all pass. The adapter and the root disk also share one SCSI bus without trouble. Along the way I found and fixed a kernel panic in the daemon's signal handling.
Four new tester cards (SCSI and IDE, debug and release) are built, boot-checked in the emulator, and packed into ZIP files for Frank and BW. None of the network code has run on real hardware yet, so the hardware gate (G11d) is still open.
Known limits: on a plain 14 MiB Falcon the system runs out of memory once the Login window is up, while 16 MiB or more of extra RAM works. Transfers are slow in the emulator, about 6 to 7 KB/s, and the real rate is unknown. The first telnet login prompt is often lost, and pressing Return brings it back. That also happens on stock A/UX, so it isn't ours. Nothing on the Macintosh side (MacTCP, EtherTalk) works yet.
Next steps are getting the cards to the testers, collecting their hardware results, measuring the real SCSI transfer rate, and then deciding about more memory or DMA transfers.
The newest versions (SCSI/IDE bootable disk images) are available for download and I will share the links via PM.
The current work is networking through a DaynaPORT SCSI adapter. A new kernel module and a small daemon give A/UX's own TCP/IP an interface called dp0. Under the Hatari emulator, with its emulated DaynaPORT, it works on both the IDE and SCSI setups. Ping, finger, a telnet login and an FTP transfer of 1 MB each way, bit-exact, all pass. The adapter and the root disk also share one SCSI bus without trouble. Along the way I found and fixed a kernel panic in the daemon's signal handling.
Four new tester cards (SCSI and IDE, debug and release) are built, boot-checked in the emulator, and packed into ZIP files for Frank and BW. None of the network code has run on real hardware yet, so the hardware gate (G11d) is still open.
Known limits: on a plain 14 MiB Falcon the system runs out of memory once the Login window is up, while 16 MiB or more of extra RAM works. Transfers are slow in the emulator, about 6 to 7 KB/s, and the real rate is unknown. The first telnet login prompt is often lost, and pressing Return brings it back. That also happens on stock A/UX, so it isn't ours. Nothing on the Macintosh side (MacTCP, EtherTalk) works yet.
Next steps are getting the cards to the testers, collecting their hardware results, measuring the real SCSI transfer rate, and then deciding about more memory or DMA transfers.
The newest versions (SCSI/IDE bootable disk images) are available for download and I will share the links via PM.

