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 :)

WIP: A/UX 3.1.1 for the Atari Falcon030

General Discussion, STOS.
Post Reply
User avatar
sascha.springer
Posts: 19
Joined: Wed Mar 25, 2020 6:56 am

WIP: A/UX 3.1.1 for the Atari Falcon030

Post by sascha.springer »

User avatar
agranlund
Site sponsor
Site sponsor
Posts: 1773
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: WIP: A/UX 3.1.1 for the Atari Falcon030

Post by agranlund »

Great stuff, that's incredibly cool!
Steve
Moderator
Moderator
Posts: 3394
Joined: Fri Sep 15, 2017 11:49 am

Re: WIP: A/UX 3.1.1 for the Atari Falcon030

Post by Steve »

Wow! Does it boot off a disk image on the Falcons HDD? Also do you think it might work on an 060 Falcon?
User avatar
sascha.springer
Posts: 19
Joined: Wed Mar 25, 2020 6:56 am

Re: WIP: A/UX 3.1.1 for the Atari Falcon030

Post by sascha.springer »

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?
I will see if I can get it installed on a HD Driver partition on my real Falcon today.
User avatar
dml
Posts: 907
Joined: Wed Nov 15, 2017 10:11 pm

Re: WIP: A/UX 3.1.1 for the Atari Falcon030

Post by dml »

Nice - and the shell is working too :p
User avatar
sascha.springer
Posts: 19
Joined: Wed Mar 25, 2020 6:56 am

Re: WIP: A/UX 3.1.1 for the Atari Falcon030

Post by sascha.springer »

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.
User avatar
sascha.springer
Posts: 19
Joined: Wed Mar 25, 2020 6:56 am

Re: WIP: A/UX 3.1.1 for the Atari Falcon030

Post by sascha.springer »

Update: VGA is now also available but still untested, though.
leech
Posts: 18
Joined: Mon Feb 26, 2024 9:53 pm

Re: WIP: A/UX 3.1.1 for the Atari Falcon030

Post by leech »

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...
User avatar
sascha.springer
Posts: 19
Joined: Wed Mar 25, 2020 6:56 am

Re: WIP: A/UX 3.1.1 for the Atari Falcon030

Post by sascha.springer »

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.
Post Reply

Return to “SOFTWARE”