AMIX an an emulator?

Hi,

I downloaded quite a bunch of AMIX (Amiga UNIX) stuff like the boot and
root floppy, the install tape etc. I'd REALLY REALLY love to see this stuff
come to live in the emulator, but AFAIK WinUAE does not (at least not
good enough) emulate the 68030's MMU. Nor does any other emulator
available.

Except using real Amiga hardware: does anyone have any hints or points
on what I could try to get this flying?

TIA
s/c

[davidk]

There is a UAE patch which adds MMU support, and is apparently good enough to run Linux, so may well be enough for AMIX.

It's against UAE 0.8.20 and linked to from the main UAE web page, the link is
http://www.freiburg.linux.de/~uae/bin/patches/mmu/

I guess the first step would be to try to get the patch working with a build of WinUAE. If you can compile WinUAE then adding the patch shouldn't be too hard. That could be tested with the Linux filesystem at the same web page as above. (It won't work with JIT, of course.)

Having done that, the next problem would likely be the tape image: you'd have to try to add support for the tape drive to the emulator. Since I don't know much about the tape drives CBM used, that bit might be harder

One day I'd love to look into getting this going. It's just a question of spare time, of which I have little!

[Toni Wilen]

AMIX AFAIK only works with 68030. MMU patch "only" includes 68040 MMU.

68030 MMU is _much_ more complex than 68040/060's MMU.

Thanks for hints and pointers. I will take a look at it. Should there be
progress, I'll let you know.

Cheers
s/c

[davidk]

Originally Posted by Toni Wilen

AMIX AFAIK only works with 68030. MMU patch "only" includes 68040 MMU.

True, but it's not obvious whether AMIX actually needs the full 68030 MMU. AMIX doesn't work with the 68040, but that could just as easily be due to cache issues, or something similar.

Unfortunately, it would take quite a lot of work to get to the point of finding out ...

[redblade]

I never managed to get AMIX running on A1200 with a ViperMK2 030, sysconfig says it has a MMU to.

I could never get the damn thing to get past track 70 on disk1. If some one could WHDLoad it , would be nice.

But I THINK the kernel on the first disk is compressed and gets decompressed on the fly. That was last year when I had a look at the .adf in a hex editor under WinXP

[andreas]

Toni & redblade, it could also be a Kickstart and/or hardware issue.
The TOSEC renamer has put a (A2500-A3000UX) at the end of the filenames, and I *think* he did that with a good reason.

Mind you, the A3000* kickstarts do not only fail on WinUAE, they are in any case a lot different from the 500, 1200 and 4000 kickstarts.
I reckon that if someone with an A3000 tests the set on his real thing, it MIGHT work, as he appears to have both the correct kickstart and chipset required for the OS to work.
Give it a try.

[ant512]

AMIX only ever worked on the A3000UX. It won't work on any other hardware. Dunno if that's a ROM issue or a custom hardware extension, but you need a UX box to run AMIX.

[andreas]

I was suspecting sort of this stuff...
Anyhow...

this usenet post definitely proves that there is a possibility to successfully install AMIX on an A3000 with no "UX", 4 MB RAM and 200 MB HD space.

[LocalH]

It's not a ROM issue - a while back over at amiga.org there was a discussion about AMIX, with someone stating that they successfully ran it with 3.1 ROMs, so you shouldn't need the hardware 1.4 ROMs from the SuperKick A3000.

Originally Posted by Failure @ amiga.org

It might be useful to note that AMIX doesn't depend on ROM 1.4, but works fine even on 3.1 ROMs. Not that I'm trying to say getting 1.4 working in WinUAE is pointless, just that it isn't necessary for AMIX.

Also, I'm pretty sure that the only difference between the A3000 and A3000UX was the badge and the software bundled - I bought my A3000 secondhand, and it had 2.0 ROMs and WB 2.1 installed, and the case has a custom paint job, including the badge, so I don't know what it says. However, it had this sticker on the back: "A3000UX (B) NTSC 4MB RAM/ 100MB DISK" (the sticker fell off but I keep it in a drawer).

Cool!

It seems like there is actually some interest in AMIX.

I *really* hope I find some time to do some serious investigation. I did already
have a look at the MMU patch, but it's for an older version of UAE. What's more,
three stock versions of UAE I downloaded didn't even compile, including the current
devel version. Well otherwise it wouldn't be fun I suppose ;-)

Anyway, regarding the MMU: true, the 030 *is* more complicated, and it could
well be AMIX it taking advantage of this. From what I remember when I actively
portet Unices across 68k boxes, one nifty feature of the 030 was the Early
Termination that was useful to cut short the translation table for large 1:1 mappings.
The 040 dropped this. ET would occasionally save huge amounts of page table
memory, and memory was scarce when AMIX was current.

Will keep you posted. Anyone knowledgable on the matter willing to give a hand is
warmly welcome to speek up!

Cheers,
s/c

[redblade]

Originally Posted by LocalH

It's not a ROM issue - a while back over at amiga.org there was a discussion about AMIX, with someone stating that they successfully ran it with 3.1 ROMs, so you shouldn't need the hardware 1.4 ROMs from the SuperKick A3000.

Yeah that's why I tried to get the disks running on my A1200, but sadly disk 1 crashed.

Even just typing 'ls' of the disks would of been good enough .

[LocalH]

The only thing odd about the whole thing is that the TOSEC renamer put (A2500-A3000UX), and in doing some searching I find that Commodore did indeed release an A2500UX, which came with an A2620 turboboard, A2090A/ A2091 controller with harddisk, additional integrated streamer and AMIX (AT&T Unix System V). That means that AMIX isn't limited to running on an '030 (or for that matter an A3000), since the 2620 is an '020 accel with an '851 MMU and '881 FPU.

There's something about the setup of A2000+A2620+A2091 that allows AMIX to run. Does your Viper have an FPU on board? If so, perhaps it's the differences between '881 and '882 (if there are any, I'm not that well versed on FPUs) that cause it to puke.

[redblade]

yeah it does have a fpu, a 68882 @ 28mhz as well.

perhaps that's it. Any way as my screen is f#$!@# I'm gonnah have to wait for a 2nd hand one to appear.

[redblade]

INTRODUCTION
------------

This directory contains the source to the UNIX bootstrap utilities.
These utilities can be used to produce bootstrap images with either
relocatable or fully linked kernels.

Because AmigaDOS bootstraps are limited to the first two blocks of
the boot device, for a maximum size of 1Kb, we use a two level
bootstrap. The level 1 boot simply loads the level 2 boot, verifies
it's checksum, and jumps to it. If anything goes wrong during the
load, it puts up a deadend alert.

Note that all code in the level 1 and level 2 boots must be position
independent. This is currently handled with a couple of kludges, one
to change jsr's to bsr's, which are PC relative (only needed when
trying to use GCC, which currently fails for other reasons). The other
kludge is a small assembler routine that computes the relocated value
of an address, primarily useful for getting the correct address of
strings.


BOOTSTRAP IMAGES
----------------

A bootstrap image currently has the following structure:

Boot Offset Size Function
----------- ---- -------------------------------

0 0x400 Boot level 1 bootstrap, read by
AmigaDOS and executed like any
normal AmigaDOS bootstrap.

0x400 0x200 Boot level 2 information block.
Contains size and checksum of level
2 boot.

0x600 var Level 2 bootstrap, variable length.
Loaded and jumped to by level 1
bootstrap.

var 0x200 Kernel information block. Contains
size, checksum, and prefered load
address of the ELF kernel file.

var var ELF kernel file, either relocatable
or fully linked. Loaded and jumped
to by level 2 bootstrap.


CHECKSUMS
---------

Note that the level 1 boot checksum must be a valid AmigaDOS checksum,
and the system will expect it to be valid. The level 2 boot also contains
a valid AmigaDOS checksum, but it is ignored. Instead, the SVR4 "sum"
compatible checksum, stored in the info block, is used to validate the
level 2 boot. Similarly, the checksum stored in the kernel info block
is used to validate the kernel file.

If the level 1 boot AmigaDOS checksum is incorrect, the system will not
attempt to boot from it. If the level 2 boot SVR4 checksum is incorrect,
the level 1 bootstrap will post a deadend alert. If the ELF kernel file
SVR4 checksum is incorrect, the level 2 bootstrap will post a recoverable
alert warning that the checksum does not match the expected one. Pressing
any mouse button will allow the boot to attempt to continue.


RELOCATABLE KERNELS
-------------------

If the kernel file loaded by the level 2 bootstrap is relocatable, the
level 2 bootstrap will perform the necessary relocation at boot time.
This can result in a noticable delay during boot, on the order of 15
seconds or more.

If the kernel info block contains a preferred load address, the relocation
is done to that address and an attempt is made to load and run the kernel
at the desired address. This is designed to allow testing of various
load addresses by simply changing the info block, rather than relinking
the kernel. The default load address in the info block is 0xFFFFFFFF,
which indicates to the level 2 bootstrap that it should do automatic
binding, by scanning the system's memory list and picking a suitable
relocation address (currently the largest chunk of contiguous, non-CHIP
memory). If the kernel is not relocatable, the preferred load address
is simply ignored.


MULTIVOLUME BOOT IMAGES
-----------------------

If the boot image is larger than will fit on a single floppy, the boot
image can be split among as many floppies as necessary. The level 1
bootstrap knows the expected size of the kernel file, and will prompt for
additional volumes as necessary, using a recoverable alert.


COMPRESSION
-----------

The boot code is capable of loading compressed kernels, I.E. kernels
which have been compressed by the standard public domain "compress"
utility, using LZW compression with 12 to 16 bits. The makeiblk utility
automatically recognizes that the kernel is compressed (from the compress
magic number) and sets the appropriate fields in the IBLK so the boot
code will know how much space the decompressed kernel will require. The
decompression is done as the kernel is read from the boot device, and
the decompressed data is written directly to the kernel memory buffer.
Decompression can be painfully slow on anything less than a 68030
based machine.


COMPACT RELOCATION
------------------

In order to squeeze even larger kernels on a single boot floppy, a
special form of ELF file can be generated using the elf2brel utility.
This utility takes a standard ELF relocatable file and turns it into
an ELF file with some custom relocation tables. The resulting file
is still a well-formed ELF file, it is just no longer usable by
the standard utilities as a relocatable file. This custom form is
about 40% smaller than a normal ELF relocatable, and is still fully
relocatable by the kernel boot code.

It seems that the source to the Amix boot disks are located in

/usr/sys/amiga/boot/

[OddbOd]

Originally Posted by LocalH

...I find that Commodore did indeed release an A2500UX, which came with an A2620 turboboard, A2090A/ A2091 controller with harddisk, additional integrated streamer and AMIX (AT&T Unix System V). That means that AMIX isn't limited to running on an '030 (or for that matter an A3000), since the 2620 is an '020 accel with an '851 MMU and '881 FPU.

Definitely correct, my A2000HD has a 2620 in it and the board's CPU selection screen has three entries - 68000, 68020 and AMIX. The only thing stopping me from trying AMIX is that I'm not sure how to setup the HDD, presumably this would have to be done from Linux, there is a SCSI adapter in my SUSE box so no problem there, but as far as sizes, partition types etc. are concerned I'm not really sure how to proceed.

[redblade]

You could try the boot disks that are available on the net, and see if it sets up the HD of the disks.

But if you can modify the boot disks so that it can run on all amiga hardware would be nice.

But the C code confuses me