Add A3000 SCSI controller and tape support for Amiga UNIX (amix)

[codewiz]

Describe the bug

The configuration described in the Amiga Unix install page works with FS-UAE 3.1.66, crashes with Amiberry, either version 5.7.3 or git master.

To Reproduce

1. Configure Amiberry as described here: https://www.amigaunix.com/doku.php/installation
2. Use either kick.a3000.40.72.rom or kick.a3000.37.175.rom
3. Boot amix_21_boot.adf in DF0, available here: https://www.amigaunix.com/doku.php/downloads
4. The floppy loads up to track 60 in a black or white screen
5. After reading track 60, the Amiga reboots immediately

I tried disabling the UAE ROM and the A3000 SCSI controller, as well as toggling various compatibility flags.

Expected behavior Amix boot floppy should request disk 2

Desktop (please complete the following information):

• OS: Arch Linux
• CPU: x86_64 (AMD)

Love Amiberry? Please consider supporting it: 👉 https://ko-fi.com/midwan

Already did :-)

[giantclambake]

@codewiz ... first up, as you're on x86-64, you'll want amiberry v6.3.3 or git preview branch ...the differences between the two are described here --> https://github.com/BlitterStudio/amiberry/wiki/First-Installation

Using preview/x86-64

Disregarding those instructions, and using the A3000 model from GUI->Quickstart (and selecting kick.a3000.37.175 rom), it's happy to get this far...

Notes:

amix is running in NTSC hence why the above screenshot looks a bit gak ~ turning NTSC on looks better.

Not sure what to do about the tar archive (yet, but I've an idea =), and I've not considered a destination HDD file or directory at this time....but getting this far looked 'sane' enough to me here.

Could you retry the operation using amiberry v6.3.3 or git preview and report back?

I've attached the config.uae used as reference (you'll need change it to suit your paths).

This reminds me very much of installing the WatchTower unix release on my A1200 many moons ago =)

amix test.uae.gz

Edit: adding the tar would seem to be the hurdle here ...setting SCSI_ID is also an issue

[giantclambake]

@midwan

I teased this out, and came to the following conclusions;

--there is no way to add a zipped tape archive directly in amiberry

My idea was to unzip the tar into a directory, and add that dir as a hdd entity, but this won't work because...

...the Volume Settings don't expose SCSI ID/LUN due to the fact the dropdown menu here doesn't expose the A3000 SCSI controller (even though it is enabled in GUI->Expansions). It follows on that any HDD entry here, cannot be assigned a SCSI_ID=6 and therefore installation of amix (with hardcoded SCSI IDs) will not work.

HTH

[codewiz]

Could you retry the operation using amiberry v6.3.3 or git preview and report back?

I built amiberry from the head of preview, and indeed, Amix boots just fine on this version, using the exact same config that failed with 5.7.3.

...the Volume Settings don't expose SCSI ID/LUN due to the fact the dropdown menu here doesn't expose the A3000 SCSI controller (even though it is enabled in GUI->Expansions). It follows on that any HDD entry here, cannot be assigned a SCSI_ID=6 and therefore installation of amix (with hardcoded SCSI IDs) will not work.

Could the unzipped tape directory be attached to the A3000 SCSI controller by means of editing the config file?

The Installation page shows how to do it for FS-UAE, but the config format seems to have drifted:

uae_uaehf0 = tape0,ro,:/<path to amix tape>/amix_21_tape,0,0,0,512,0,,scsi4,SCSI1

[giantclambake]

Could the unzipped tape directory be attached to the A3000 SCSI controller by means of editing the config file?

I just had a glimpse through the source, and the answer would seem to be no ~ the device entity tape0 does not make an appearance. That said, all the scsi controller/tape device support code seems to be present...just not implemented as such.

My best guess here is that you hold the distinction of being the first person to ask for these scsi options wrt amiberry (in just the same way as one did hold the distinction of wrestling WatchTower unix onto a real Amiga...we were few =)

Personally speaking, I think it'd be a nice feature add to amiberry's capabilities ~ I would certainly enjoy reliving those days decades ago, without the crippling side-effect of ..for instance... seeing WatchTower unix nearly cripple my dkb-cobra 030/882 + ferret with consummate ease...when you tried to compile anything more complex than "Hello"...lol.. fun days ;)

I'm sure Midwan will weigh in here, when he gets around to looking at it.

[codewiz]

I was a NetBSD/amiga user back in the day, but I've always wanted to see what Amiga UNIX looked like.

If we get get it to installed, perhaps it could be added to SDF's collection of live vintage systems: https://sdf.org/?ssh

[giantclambake]

I was a NetBSD/amiga user back in the day, but I've always wanted to see what Amiga UNIX looked like.

If we get get it to installed, perhaps it could be added to SDF's collection of live vintage systems: https://sdf.org/?ssh

You could do something like that, sure, but I figure there's a wider, more curious interest group, if one got it all installed (with working X11R5 and build toolchain), and then made that available as ie; amix-68k-Amiga.hdf so those with Amiga emulators can relive those olden days. Folks with real Amiga hardware should experience what it is, that lets you know that "you cannot achieve the aim without suffering"... also see -> https://ftp2.grandis.nu/turran/FTP/Misc/AMIX/ ..I'm just d/l that set now, to see what it contains...

@codewiz ... as a matter of house-keeping, you should change the title of this issue to something like 'Add scsi controller and tape support' or such and similar, to better describe the issue at hand (I'm not too worried about it not working in v5.x/master, as doing this is likely a heavy emulation load ;)

[giantclambake]

Much of what I teased out above, was held wrt how I understood WinUAE to handle this emulation case, and it's only just now creating a test case with WinUAE v5.2.0 /WINE to confirm my thoughts, I coincidentally discovered...

The moment track 60 from DF0: is read in, we go straight to illegal instruction and manage to whisper who done it at last breath. Upgrading to WinUAE v5.3.0 didn't help, either hitting the same kernel panic, or punching kickstart ROM out..

Nothing I tried nor any combinations of options, could get it past the kernel panic...with either amix v2.1 or v2.1.7.

'For whatever reason', the current build of amiberry isn't running into this problem ; the panic is happening very early on in the amix kernel boot-up, so you'd tend to think this is in cpu emulation somewhere...ie; the kernel's not even hitting the hardware at all at this point....

....that means...(promo mode on =)...if this scsi/tape stuff could be done, it'd be feature add+ ...(only amiberry can do it, he whispered ;). Looking at that, after RTFM the amix release files, built in A3000 SCSI controller is directly supported by the kernel driver, and in the single machine case becomes the (only) SCSI-0 controller that we care about here. So only the device LUNs need be configurable, on a per hdd device case (be that directory, .hdf, or the tape archive/directory handling we don't currently have)...which are exposed in the Hard Drives/CD panel in amiberry.

I'll attach the WinUAE v5.3.0 generated config.uae file for reference ...

winuae530_amix-test.uae.gz

[codewiz]

I downloaded basicamixX11R4.tbz2 and it boots on FS-UAE using the config recommended by the Amiga Unix installation page. In particular:

 hard_drive_0 = /<path to hardfile>/a3000ux.hdf
 hard_drive_0_controller = scsi6
 hard_drive_0_type = rdb

I couldn't login because I couldn't figure out the root password, and I couldn't test it with Amiberry because right now I'm using my Fedora laptop.

[codewiz]

I installed the Amiberry Flatpak (v6.3.3) and... the Noth preinstalled Amix hdf boots!

Also, I guessed that I could login as guest with no password. Ah, the great security standards of the '90s :-)

I had to hand-edit the config to move the hdf image to the A3000 SCSI controller. All I did is change the last value to "scsi6":

hardfile2=rw,DH0:/home/bernie/emu/amiga/amix/amix.hdf,0,0,0,512,0,,scsi6
uaehf0=hdf,rw,DH0:/home/bernie/emu/amiga/amix/amix.hdf,0,0,0,512,0,,scsi6

[giantclambake]

Nice, that tallies with my observations ~ most of the SCSI supports are there, just not exposed and we don't have a tape archive handler. Of course, a preinstalled .hdf file doesn't replace the experience of being able to/having to get to that point in DIY fashion =) In that regard, found in my archives.. https://mega.nz/file/WUYjhZSY#7PQwQWKJKz1ugKN-y4Ov-rTtEYHZ3bGZTcVjhr5Mgf8 ...if you like a challenge ... ;)

As this is more feature add than it is outright bug as such, it's low priority stuff and midwan can take a look at it anytime at his leisure to decide what to do about it =^)

[codewiz]

Slightly related: the AUR package of Amiberry is built from master. Should I suggest switching to the preview branch?

Also, this package installs the entire tree in /usr/share/amiberry, making it impossible to save configs. What's the recommended directory layout for Linux packagers? Can paths relative to $HOME be configured at build time?

(happy to file a separate bug if needed)

[giantclambake]

Also, this package installs the entire tree in /usr/share/amiberry, making it impossible to save configs. What's the recommended directory layout for Linux packagers? Can paths relative to $HOME be configured at build time?

This is the intent of issue #1073 more or less ;)

Slightly related: the AUR package of Amiberry is built from master. Should I suggest switching to the preview branch?

I had to check this... (https://aur.archlinux.org/amiberry.git)

The package description is -- pkgdesc = Amiga Emulator for ARM Boards (amd64 build)

That's actually correct wrt amiberry v5.x / master ... this package would indeed be the x86-64 (amd64) build of the amiberry release, intended for ARM boards.

The amiberry v6.x/preview builds are not specifically targeting ARM 'boards', instead x86-64 & apple M1/2/3 CPUs.

I don't know what the AUR policies are here, but the Debian-centric view would be the amiberry v6.x releases are still in 'Preview' staging as it were, and would need lose that tag before being considered. On top of that, the issues discussed in #1073 would need be addressed first, so the package adhered to FHS established conventions, and shared common locations with the package/system templates....something like this =)

[midwan]

• The Tape support is missing from the GUI, but I think all the back-end stuff is already implemented in Preview. I'll have to check as some extension hardware is not added yet.
• I don't maintain the AUR package, but I agree - it probably makes more sense to pick from the preview branch, at least until that gets merged into master at some point.

[midwan]

Good news, with the changes I've made (in the separate branch for now), I could install Amix on Amiberry, using the same guide found here: https://www.amigaunix.com/doku.php/installation

I just followed the same steps mentioned for WinUAE.

The new branch adds Tape support in the GUI, but also updates the rest of the dialogs in the HDD panel, to match those of WinUAE closer. There are still a few minor bugs to fix with it, before I can merge it.

[midwan]

This is now merged into preview - I'll see if it can be cherry-picked to master as well.