Aros/Platforms/68k support

AROS is a choice/option of an open source, portable AmigaOS(TM) OS3.1. System friendly 68K AmigaOS (AOS) binaries will run out of the box on Aros 68k on 68k amiga based hardware. AROS could be the life line for Amiga68K as future kickstart/wb upgrades, i.e. potential for CD-Rom boot, USB boot, potential replacements for all outdated OS parts, standards for drivers, standards for RTG, standards for PCI access.

The AROS kernel rom can be used with the existing OS1.3, OS2.0, OS2.05, OS3.0 or OS3.1 to varying degrees of success - certain hardware will be supported but others will still be a work in progress. AROS rom can be used together with the rest of AROS to replace any commercial rom + workbench combination like high end Amigas. You use as much of AROS as you require.

AROS sources have always been more or less M68K binary compatible (even all library sources have complete 68k register parameters defined and most public structures are 1:1 identical). It is actually designed for 68k from the beginning. A working, binary compatible version of AROS on real Amiga's is pretty much the holy grail for determining how compatible AROS is with AmigaOS (TM).

Native AROS 68k software does not work on any classic amiga(TM) OS, but Classic Amiga(TM) apps will work with AROS m68k OS. Aros m68k OS build is mostly compatible with the apps from the range of 68k amiga operating systems, kickstarts or workbenches, from 1.x to 3.x.

The compatibility may not be perfect or complete in just every area, but this is the goal.

So from software point of view you simply run your amiga 68k software on aros. same for libraries, mui classes, device drivers, things like that. You can use your amiga USB hardware with the device driver delivered by your vendor.

When Aros was ported to 68k Toni Wilen did a great job to develop kickstart replacements that are now part of Aros. For a long time Aros 68k was used by a few people then Vampire/Apollo became reality and Aros offers many advantages here. It has many advantages compared to 3.1 and still low hardware requirements, like AHI, USB-Support (Poseidon), Theming, Network stack and much more

Some elements have even surpassed OS 3.9 but others lag behind. Some of that missing 18% is no longer relevant and will never be implemented. Bugs and missing features are still a problem.

"Most games don't use much from the operating system and Aros68k is binary compatible with Amiga OS3.1 anyway. The Apollo Core of the Vampire has a CPU that implements all the (integer) instructions of all the Motorola 680x0 so any games that use instructions from the 68020 that are not included in the 68040 or 68060 will still boot from floppy on a Vampire. However some games have issues with any faster processor, WHDLoad has fixes for those and the Vampire also has a setting to improve compatibility. In the future the Vampire is also likely to allow AGA only games to be played on the OCS and ECS Amigas"

Most AROS programs are written in C using the Amiga API but some of them in C++.

The point of AROS being open source is that it means people can take it in whatever direction they want - those that want just original hardware can stick with that and still get enhancements; those that want to use all kinds of expansions can get them better integrated with the core. And those who want different hardware altogether can still enjoy an AmigaOS like OS.

Installing

Actual Hardware

AROS m68k resources:

Official downloads (use latest nightly m68k) http://aros.sourceforge.net/nightly1.php
FTP Latest AROS m68k https://dl.amigadev.com/nightly/aros/

AMIGASYSTEM AROS One 68k distro with discussion here and here
AROS Vision UAE,
AROS Vision with minimalistic 3.0 look, while having more modern functionality

Apollo AROS forum
AROS Exec discussion board https://ae.amigalife.org/index.php?board=12.0
Join the IRC #Apollo-Team from IRC client

Vampire V4 IV

2019 Vampire V4 Standalone V4SA
2022

Discussions can be made here ApolloOS is a fork of AROS which removes needless abstraction layers and improving backward compatibility like making a compatible replacement for the Graphics.library used by AROS and removing OOP.library from the ApolloOS kernel which AmigaOS user deemed unnecessary which is OK within the AROS licence.

write the hdf to a sd/cf/hd you will get a bootable drive as result. the tool actually is called Win32DiskImager, just successfully put an hdf onto a sd card with it

attempt to boot from the SD Card you could try Vampire Boot found here

Vampire V2

works via sd card boot

Vampire 2000 V500

Video booting from sd card May 2020

Vampire 1200 V2

Boot up May 2020

Vampire 600 v2

Hopefully it works on the V600 soon, worked just fine for a while, then suddenly not at all.

Vampire 500 V2+

finally boots again on the V500 and also boots on the V1200

Original platforms

AROS Vision distro large download

Latest nightly build ABIv1

To install aros on amiga you need a computer with enough ram. minimal amount is currently around 6mb affair, but this is subject to change. to run any application effectively you need respectively more. aros nightly that is also a base for olafs aros68k vision distro is compiled for plain 68k so should run on any amiga. Would recommend at least an 040.

first of all you need a big enough hard drive with a free bootable partition of at least 100-200mb. if you are just going to try out the pure aros68k nighty, that is. adding contributions or installing aros vision will take much more space. and you might want to put there some amiga programs of your choice as well, then the reasonable size will exceed 1gig for sure.

you can download the iso image of the nightly and the gz archive of contributions on your amiga, but keep in mind, you will need to decompress them to the empty bootable partition. for the iso you can use diskimage device: http://aminet.net/package/disk/misc/diskimage.m68k-aos but you may run short of memory.

the easiest way so far is to prepare the content of your partition in a directory on a mainstream machine, mount it as drive under uae of your choice (under windows obviously winuae) and simply copy the contents of the directory to an amiga drive attached via USB-ide adapter to the pc or to cf card attached via cf adapter.

in order to make aros68k partition soft-bootable on a real hardware (or uae, for that matter) that means without aros roms, just from a genuine amiga rom, you need to edit the startup sequence. remember you need to do it on aros68k/amiga side with an aros/amiga editor because the carriage return of windows text files doesn't correspond to the amiga format and scripts saved with windows editors are not executable on amiga. this isn't a problem with linux text editors.

you need to modify only the first line of the startup-sequence to:

   boot/amiga/AROSBootstrap ROM boot/amiga/aros.hunk.gz

in case you want to use your p96 supported rtg card you need to attach the paths to a location where p96 drivers are to be found to arosbootstrap, as example when using picassoIV the initial entry in the startup-sequence needs to look similar this: Quote (selected)

   boot/amiga/AROSBootstrap ROM boot/amiga/aros.hunk.gz boot/amiga/PicassoIV.card boot/amiga/CirrusGD5446.chip

keep in mind to adopt the actual paths and to save the file.

also add

   SetPatch

immediately after the first line, as usual you can specify option QUIET to it, which i would recommend, except you need to debug setpatch.

now, that you have an amiga formatted drive with an aros partition you can either test boot it under uae or attach it to your amiga and try to boot from there. have fun.

 decompressing aros to drive with a bootable partition, be it a cf card, and adding arosbootstrap followed by kickstart image file should produce a bootable environment

attach cf-card to Amiga (via internal IDE-to-CF converter)
boot Amiga from WB3.1-floppy
"HDToolbox" prepare cf-card (=internal "harddrive")
attach cf-card to linux, mount via "mount -t affs /dev/sdb1 foldername"
copy all files from AROS-m68k-bootiso.iso (mounted) to 'foldername' (=cf-card)
attach cf-card to Amiga, boot from WB3.1-floppy
fix file permissions on cf-card: "protect hd0:#? rwed all" (where hd0: = cf-card)
edit hd0:S/Startup-Sequence, add first line (taken from amiga-m68k-boot/bootdisk-amiga-m68k.adf):

boot/amiga/AROSBootstrap ROM boot/amiga/aros.hunk.gz

done. remove WB3.1-floppy, and reboot.

need to edit your s-s in order to include something like that:

boot/amiga/AROSBootstrap ROM boot/amiga/aros.hunk.gz

followed by paths to and names of you p96 rtg driver files (.chip and .card) (that assuming you want to use graphic card. Also advise to delete prefs/env/sys/theme.var to get rid of skinning. you can enable it later again if you want.

Booting aros on an a4000/csppc all fine. takes 35seconds cold boot from amiga 4000 ide.

if you have your amiga connected to internet, you can of course format your partition directly on amiga, download the iso and mount it with one of numerous utilities, preferably with diskimage device available from aminet and copy the files over directly on your amiga without any disk swapping

Make sure to get the ISO from the AROS site or the alternate Sourceforge site - it's in AmigaOS HUNK format. The tarball (bzip2(bz2) archive is for debugging AROS itself, and is in ELF format. The .adf and rom bins can also be found inside the distfiles directory. Look here for an alternate build and compile chain.

A list of the daily updates are available from ezrec clone mirror, Repo or Ohloh. A digest of the latest news from the AROS world can be found at AROS Planet.

Amiga.org Phase 1 thread, Phase 2 thread and EAB first thread and Second thread - on going. Natami thread, AW.net Minimig and EvilWiki Blog.

Status of aros m68k applications

Emulators

Emu68 (68k on ARM hardware)

PiStorm (Altera Max) (A500 A2000) board will allow you to use

PiStorm32Lite (Efinix) (A1200) board will allow you to use not only the RasPi Zero2-W Zero 2W (RP3A0) or Compute Module 4, but also RasPi 3B+, RasPi 3A, Raspi4 though more work required

Michel's patreon posts and news, github, github, and [irc.libera.chat:6697 / #pistorm-emu68 IRC]

2019 Pi 3b+ and 4
2020 Pi400 keyboard and capstone disassembler added
2021 refactoring to 64bit only
2022 version 0.10 to 0.11, changes due to integration of BCM2711, used in RasPi4 and CM4 compute modules are integrated into main branch
2024 Emu68 version 1.0 - main JIT loop rewritten from AArch64 assembly to C
2025 PiStorm16 for Amiga 600 using Efinix FPGA chip, concept and plan for further work

An alternative, m68k emulation on ARM hardware with Caffeine AROS 68k on top. Surprised by the performance (in positive way 32/64 bit). The project called Emu68 is at the moment intensively developed. The project brings a very fast m68k JIT working on bare metal ARM. On top of that emulator there will be a m68k version of AROS working. So yes, not exactly a full speed, but still much faster than a real amiga emulation. The JIT is already at a stage where it can execute simple m68k apps (of course those which do not need AmigaOS or AROS) which talk to RasPi hardware directly. In next stage will start building a m68k AROS version working on this JIT.

For jit emu AArch64 was not that bad, have reserved 18 A64 integer registers for my own usage and still have more then enough for gcc's generated code as well as for the JIT translator. Keep the Program Counter, Status Register and all D and A regs all the time in their A64 counterparts. The FPU registers are stored in ARM registers for all of the time, too.

The JIT code will have about 12 temporary registers for its own use, with ability to use them as 32 or 64 bit regs. The m68k context will be loaded only once, as soon as the Emu68 starts. It will be saved (or updated) only when necessary, thus saving a lot of saves/restores which have had in 32bit ARM mode.

Now, what are the other news on the AArch64 side? The MMU setup is complete now. Query the available memory, all MMIO ranges for the peripherals and the video memory. They are all mapped in the lowest 4GB region, so that the m68k hardware drivers can talk to the RasPi components. In the topmost bits of the address space there is the Emu68 kernel and a direct map of the first 4GB memory range. The map can be like this one (RasPi 3B emulated on QEMU):

     
    0x0000000000000000 - 0x000000003affffff: User RAM, cached
    0x000000003b000000 - 0x000000003bffffff: 
    0x000000003c000000 - 0x000000003fffffff: VC4 memory, non-cacheable
    0x00000000f2000000 - 0x00000000f2ffffff: RasPi peripherals, device memory type
    0x00000000f3000000 - 0x00000000f31fffff: RasPi per-cpu region
    0x00000000f3200000 - 0xffffff7fffffffff:
    0xffffff8000000000 - 0xffffff8000ffffff: Emu68 core, JIT cache
    0xffffff8001000000 - 0xfffffffeffffffff:
    0xffffffff00000000 - 0xffffffffffffffff: 1:1 map of the first 4GB, non-cacheable, supervisor only

As you can see, there are few voids in the memory map which cause exception when attempted to access. Not only that, the m68k code has no access to the Emu68 address space, since it is way beyond its addressing capabilities. The MMU map is loaded and modified many times during early boot up, since Emu68 core has to move itself from the beginning of the memory to the very top of the available RAM, but, on the other hand, all setup is now pretty clear.

PiStorm

boards

RaspPi v2 v3 v4

The rest of the Emu68 kernel? Rewritten the MMU setup and kernel move routine from C to assembly. Especially the latter was a necessary step, since one of the things being moved is the stack, and have only a very little control over it when using any higher-level language. Besides, the MMU setup in assembly is now independent on the physical location of the kernel, provided it is aligned on the 2MB page boundary anywhere within RAM.

FPU support

First of all, the kernel assumed that it gets loaded at a physical address of 0x00080000. This is correct on RasPi, however is just a wishful thinking on other machines. For example, the Pinebook reserves the lowest 2MB area for ATF - ARM Trusted Firmware. This area is not, and should never be accessible for untrusted software such as e.g. an operating system. Additionally, the binary file was generating was missing a special header, unused on RasPi, but very helpful when one attempts to load and start the kernel through the uboot. The header specifies few basic things, such as the load offset within the 2MB page (this is the magic 0x00080000 value), it declares basic MMU page size used by the kernel, it says whether the kernel wants to be loaded into lowest possible memory area, or if a location anywhere on a 2MB boundary is fine. And it declares the endianness of the kernel, so that e.g. uboot could refuse loading it if the machine does not support the requested mode. The header contains also place for two opcodes allowing one to skip it using a branch opcode. Why two of them when only one would be enough? Well, this trick allows one to use part of the first of them as an identifier of regular EXE file. This way one can embed a PE header into the kernel making it a valid RasPi, uboot and EFI file at the same time. Tricky but impressive!

Pinebook Pro (2019) 64bit ARM8v Rockchip RK3399 SOC with Mali T860 MP4 GPU IPS 1080p

https://www.pine64.org/pinebook-pro/

ISO UK version
ANSI US version

How about PineBook Pro? Got it booting the code, but cannot use the caches yet. The code loads properly, sets up MMU map, dumps the entire device tree and relocates the kernel. Display is not ready yet, but it is not of the highest priority. So far it looks like this:

    [BOOT] Booting Emu68 runtime/AArch64 BigEndian
    [BOOT] Boot address is 0xffffff80000800a0
    [BOOT] Build ID: 4236bd740a2dda0091e3a2a2ad69e8e5ad5f4496
    [BOOT] ARM stack top at 0xffffff8000080000
    [BOOT] Bootstrap ends at 0xffffff8000090000
    [BOOT] Kernel args (0x00000000f3dbc000)
    [BOOT] Local memory pool:
    [BOOT] 0xffffff8000090000 - 0xffffff8000ffffff (size=16187392)
    [BOOT] Device Tree dump:
    [BOOT] 
    [BOOT]  model=Pine64 Pinebook Pro. (50696e6536342050696e65626f6f6b2050726f00)
    [....]
    [BOOT] System memory: 0x0000000000200000-0x00000000f6ffffff
    [BOOT] Moving kernel from 0x0000000000200000 to 0x00000000f7000000

WinUAE

Get the latest WinUAE which has the AROS rom images built-in.

Optionally, you can get the whole nightly build which contains both the ROMs and AROS system but for most people it will not be necessary. Set WinUAE "Main ROM file" = aros-amiga-m68k-rom.bin and "Extended ROM file" = aros-amiga-m68k-ext.bin. arosbootstrap method is meant for easy real Amiga testing, no need to burn EEPROMs etc.

Configure WinUAE to simulate a standard A1200 but with full 68020 CPU (24 bit mode unmarked). Select 2MB CHIP, 64 MB Z3 FAST. On Expansions tab give some RAM to RTG card (I have 16 MB). Then attach the AROS directory as a hard disk and boot from it. It will take some time, but eventually you should have WinUAE booted to Wanderer 640x480x8.

IMPORTANT: be sure to use JIT. Without JIT, loading will be 3-4 times slower as well as AROS crashes very easily (most of the time memory allocation problem in input.device). With JIT, it's "rock stable" (at least for moving windows ;)

Use latest winuae beta with -log -serlog parameters to see serial logging debugging (make sure rom is built with serial logging enabled)

Either use both -serlog -log to open log window (also writes to a file automatically) or tick logging checkbox in misc panel if you don't want to see the log window.

download the nightly amiga-m68k-bootiso to your pc or amiga if internet connection
decompress the archive which contains an iso to a directory on your pc. you may use programs like winrar or isobuster to do that.
prepare an amiga formatted drive with an empty bootable aros partition (preferably highest priority) on your amiga. you may use ffs with its flaws but also pfs3 as file system.
connect the amiga drive (assuming it is an ide drive) to your pc using an ide-USB adapter.
fire up winuae. mount your decompressed iso-directory as drive under winuae:

hardware>harddrives>add directory or archive.

alternatively i think you can just mount your iso archive under

hardware>harddrives>add hardfile.

mount your USB-connected amiga hard drive hardware>harddrives>add hard drive and boot up winuae from a your usual bootable partition.
copy aros installation from iso or iso-directory to your aros partition on your real amiga hard drive using file manager of your choice. diropus? make sure the aros partition on your amiga drive is bootable and has the highest priority.
you can now attach your amiga aros harddrive to your amiga controller. be it internal ide, fastata, or scsi controller via acard scsi-ide adapter. note that csppc or csmk3 controllers are not yet supported and cause problems during bootup.
your amiga will now likely need some time due to kickstart3.1 waiting 30secs for the drives to spinup and then softkick aros. which you will be able to observe as it gives screen output. the aros68k boot from had is not immediate as aos, but it does not take long.

alternatively you could establish a serial debug connection between amiga and whatever else machine you use (likely with an serial sub-d adapter 25>9 pin, null modem cable and serial-USB adapter) and observe the debug output on terminal window on the alternate machine. using tera term on pc. you have to choose your USB port. and debug baudrate: 115200

Working

UAE E-UAE

AROS 68k has two ROM files, a Kickstart and a Kickstart ext, you will need both. The emulator should be set up exactly as an A1200 but with full 020 and above CPU with 4meg fast ram and if possible RTG. It should work then, If AROS doesn't show a disk prompt or gives insert DEVS: errors) then you should ensure a bootable disks (hard hdf or floppy adf) are available

will need to add arosbootstrap command at the beginning of the startup-sequence, pointing to your ks images and rtg drivers

boot/amiga/AROSBootstrap ROM boot/amiga/aros.hunk.gz boot/amiga/PicassoIV.card boot/amiga/CirrusGD5446.chip

uae.rc or euae.rc or uae.config (they are text files) - check to see if these options are set inside

kickstart_rom_file=<path>

kickstart_ext_rom_file=<path>

This option specifies the file path of an extended ROM image to load.

gfxcard_size=<n> (default=0)

Emulate an RTG graphics card with <n> MB of graphics memory. Selecting <n> greater than 0, enables the graphics card or so-called 'Picasso96' emulation. A maximum of 32 MB of graphics card memory may be emulated.

E-UAE must emulate a 32-bit CPU (a 68020 or better, not an 68ec020) to support the graphics card emulation.

Make sure serial port emulation is enabled, it is required in all non-WinUAE versions (WinUAE always emulates serial interrupts internally).

In use

Missing functionality:

intellifont/compugraphic font support (TrueType is indeed the way forward, but it is another resource pig on anything but high-end 
Amigas. And besides, Intellifont should be implemented anyway for backwards compatibility.)
cdrom filesystem (missing L:cdrom-handler. Is it in Aros68k rom? It should be on disk, see note no. 1)
no crossdos (L:fat-handler is missing. Is it in Aros68k rom? It should be on disk, see note no. 1)
recoverable ram volume support is non existent (RAD)
No Overscan support
No PCMCIA ram support

Missing disk components:

C/cpu
ed
edit
magtape (I don't know anyone who has used it, and I highly doubt it is required for backwards compatibility)
remrad (no rad support)
setfont (setdefaultfont does not provide the same functionality. e.g.: missing setfont tooltypes)
CLASSES/DATATYPES/anim.datatype (these datatypes seem implemented, but their classes are physically absent)
animation.datatype (these datatypes seem implemented, but their classes are physically absent)
cdxl.datatype (these datatypes seem implemented, but their classes are physically absent)
CLASSES/GADGETS/tapedeck.gadget
DEVS/audio.device (AHI is fine as a way forward, but it is a resource pig on anything below a 68020 on native) 
mfm.device
parallel.device
DEVS/DOSDRIVERS/aux
rad
cd0 (iso0 is present but we have the renaming issue. See note no.1)
pc1 (maybe a small omission)
DEVS/KEYMAPS/ (it is full of PC keyboard keymaps and a SUN one. But what about Amiga keymaps?)
DEVS/MONITORS/ (missing A2024, dblntsc, dblpal, euro36, euro72, multiscan, ntsc, pal, super72 and vgaonly. A generic one doesn't suit, 
see note no. 1)
DEVS/PRINTERS/ (missing all printer drivers but postscript. Not that it is really needed, but at least, "generic" and "file" drivers 
should be included) 
FONTS (not a single one of the old native ones present. I understand that there are TTF replacements, but then see note no1.) 
L/aux-handler
cdfilesystem (see note no. 1)
crossdosfilesystem (see note no. 1)
port-handler
queue-handler
LIBS/68040.library (680x0.library exists- specific processor libraries are unnecessary. insert setpatch at the beginning of the ss and the universal 680x0.library with the patches for specific processor will be automatically loaded. plug and play. definitely a gain with aros. no libs mess here.)
bullet.library 
PREFS/overscan
pallete
printergfx
printerps
sound (yes, there is AHI, but I have already mentioned its issues)
wbpattern
REXXC/hi
rxc
rxset
tcc
tco
te
ts
waitforport
SYSTEM/diskcopy
intellifont (ftmanager doesn't cut it, as I mentioned before)
nofastmem
TOOLS/bru (not that I or anyone else care or require it for backwards compatibility, but some backup option should exist for completeness)
cmd
iconedit
lacer
memacs (don't use it or care about it, but why leave it out when it is PD?)
prepcard
TOOLS/COMMODITIES/crossdos
mouseblanker (couldn't care less. But then it is not difficult to implement, isn't it?)

Notes:

backwards compatibility´s sake that some AmigaOS components get replaced with other ones with different names. Can they be Just restore them to their original name or create placeholders/links to the actual structures.

in general you can easily add anything as long as it does not rely on internal structures that perhaps are not implemented or implemented differently. You can f.e. add anything shell related easily, add more libraries and so on. Partly you can even replace existing components. I did f.e. replace Zune with MUI38 because some software I wanted did not work (example is IBrowse). The only disadvantage is that prefs do not work anymore so I created workarounds like predefined prefs files that are copied.

crossdos does not exist and on Aros (except 68k) nobody needs it and no sources are available so chance is pretty slim. Missing disk components. As I wrote you can add almost anything and as long as it not relys on unimplemented low-level components it works. I cannot remember f.e. "cpu" but I have added many components so it might be there. Also you do not need to include "ed" or similar because you can simply define it in shell-startup. I f.e. define it and execute annotate. Datatype system is different in aros so you cannot simply add or replace datatypes from 3.X (I have tested it). Datatypes would be certainly a candidate for a bounty. In Aros Vision I have created small Hollywood-programs for that and use filetype system of Magellan to execute them. Audio.device missing? It should be there but certainly using AHI that is standard on Aros. Printing and Printing to file works (at least on UAE, not tested it on real hardware). 68040.library can be added easily I think. I use Waitforport in Aros Vision, it is working with Rexxmast from Aros.

Debugging

68k based Monitor Debugging

Some monitors work

Serial Debugging

Serial debugging requires software on each machine that needs communicating between as well as a physical lead of some kind (usually early prolific or FTDI USB based).

Software PC or otherwise - Putty, TeraTerm, minicom, etc

Software Amiga - Term

Direct output to serial so that it can arrive at the other end.

Serial 9pin -> 25pin

What you need is a Serial Null-modem cable. It is just a Serial cable, but with RX and TX lines crossed.

9pin DB9F female end for PC and 25 pin DB25F female end for Amiga.

If you have a standard RS232 serial cable you can buy a null modem adapter, attach it to the standard serial cable and connect the 2 computers.

Second option is to just buy an RS232 null modem cable and connect the 2 computers.

Just do a quick search for "Amiga serial null modem cable". However, a lot of cables come with one or two male ends instead and so an additional female to female adapter(s) is needed.

Use add44k or whatever to drop your screen depth, you'll be able to get a little bit more speed that way. More planes = more dma load = less time available for your beloved serial port. RTG will help, but you must configure it to not display a custom chip screen at all when you have an RTG screen visible.

Here are some tips:

1. Ensure you have a null-modem adapter in your cable setup. Somewhere in your cable chain. A null-modem adapter will say "NULL MODEM" somewhere on the device.

2. Right-click the amiga explorer icon & make sure the correct serial port for your PC (COM1:, COM2:) is chosen... I believe it defaults to COM1. Make sure that the serial port is listed in Device Manager under "Ports (COM & LPT)". Make sure there is no (!) or (x) mark on the device's icon in Device manager.

3. Test the cable setup: Load up hyperterminal on the PC, and a terminal program on the Amiga. Set both to 9600baud, 8 data bits, no parity, 1 stop bit, no handshaking. Typing characters on one system should show up on the other. If not, you have a cable or configuration issue.

4. Test handshaking: enable hardware handshaking on both ends and check connectivity by typing on each machine. If you passed #3 and fail here, then you have a miswired serial cable (or, less likely, miswired nullmodem adapter).

Some people use baud bandit on 68000 machines (A500/600) and new8n1 on 020+ ones but AROS has its own serial driver which is untested with the following serial hardware expansions

VarIO
HyperCOM +3
SilverSurfer
Twister 1200

USB Serial

Using a serial to USB adapter and RealTerm 115200baud, port70 parity:none, data bits:8, stop bits:1.

Using TeraTerm on the PC (adjusting the port and baud rate to 115200) you can catch the boot log and supply it to aros-dev list or Aros-Exec. Feedback always welcome.

I have been told USB adapter for serial are problematic, or do not always work, but was denied detailed explanation? Some of them are problematic for use in EEPROM programmers, because they need 12V on the serial cable, but USB adapters do not provide such voltage. For use in data transfers and basic communications the cheapest USB adapter is still good.

Subway USB Controller for the Amiga 1200 Clockport

Deneb USB for Amiga 3000/4000

Since it is not possible to use larger than 512 kb rom images in deneb, I don't think I can start AROS kickstart from flash. if i try to initialize the first half with algor kick the computer hangs in endless boot loop. Therefore I am using blizkick to load the first part of the kickstart at the very beginning in my aros startup-sequence. All i have been able to capture this way follows. blizkick is supposed to manage 1MB roms, but elf files are apparently not accepted. Otherwise, it would be ideal to have an 512KB kickstart file as accepted by algorkick.

Logs needed

ALWAYS include full logs. (You may have multiple hardware configurations, it is very important to know exact hardware).
ALWAYS describe how harddrive(s) are connected.. Sometimes a log will hint that there is no IDE drives connected and possibly something on 3rd party SCSI board. Note that debugging non-AROS-builtin HD driver (=3rd party expansion + boot ROM) compatibility is practically impossible without having the same hardware. (Nothing is logged because everything is handled by boot rom, including drive detection, RDB parsing etc..)

Here is for example log from my real A1200/68060 (using USB serial adapter).

[reset]
[SysBase] fakebase at: 0000020c
RAM lower: 00001000
RAM upper: 001fffff
BSS lower: 00135620
BSS upper: 0013577f
Protect: : 00001000
    bss: : 00135620
    rom: : 00135788
    ext: : 001a2e10
[prep SysBase]: 00001000
[new  SysBase]: 00001508
CPU: 68060 FPU: 68060
[ColdCapture] Ignoring AOS->AROS trampoline
[start] InitCode(RTF_SINGLETASK, 0)
configchain
Found board: mfg=8512 prod=17 size=00020000 serial=00000000
diag=00000080
configchain done
adding ram boards
ram boards done
coolcapture=00000000 kickmemptr=00000000 kicktagptr=001fe7a8
kickchecksum=001fe78a
* 00195afc:  127 02   3 "kernel.resource"
* 0013e380:  120 42  41 "exec.library"
* 00154e1c:  110 82  41 "expansion.library"
* 00151798:  105 82  41 "utility.library"
* 00154f3a:  105 01  41 "diag init"
* 0015a930:  104 81   2 "partition.library"
* 001413d8:  102 81  41 "aros.library"
* 0019d028:  100 81  41 "potgo.resource"
* 00196118:   99 01   2 "processor.resource"
* 00153af0:   94 81  42 "oop.library"
* 0017cb64:   92 81   1 "hiddclass.hidd"
* 0019ce50:   80 01   0 "cia.resource"
* 0019d864:   80 01   1 "FileSystem.resource"
* 0019469c:   70 81  41 "battclock.resource"
* 001894ac:   66 81   1 "graphics.hidd"
* 001b5e3c:   65 81  41 "graphics.library"
* 001bb4d0:   60 81  41 "layers.library"
* 0015dd4c:   50 81  41 "timer.device"
* 00168784:   50 81  41 "audio.device"
* 0019dcac:   50 81  41 "m680x0.resource"
* 0018a698:   45 81   1 "keyboard.hidd"
* 0018afb4:   45 81   1 "mouse.hidd"
* 0019dadc:   45 01  41 "misc.resource"
* 0015f7f0:   44 81  41 "keyboard.device"
* 0016746c:   44 81  41 "gameport.device"
* 0018b88c:   40 81   1 "amigakbd.hidd"
* 0018c2b8:   40 81   1 "amigamouse.hidd"
* 001a390c:   40 81  41 "keymap.library"
* 0019d634:   39 81  41 "disk.resource"
* 00166988:   35 81  41 "trackdisk.device"
* 0015ecb0:   30 81  41 "input.device"
* 001dee48:   15 81  50 "intuition.library"
* 0018ffe8:    9 81   1 "amigavideo.hidd"
* 00193b20:    8 81   1 "uaegfx.hidd"
* 001644f8:    4 81  41 "console.device"
* 0016d8ac:    4 81  41 "ata.device"
* 001ea1a4:    0 81  41 "gadtools.library"
* 00178bcc: -   1 81  41 "afs.handler"
* 001fcfee: -  45 01  41 "alert.hook"
* 00155ba2: - 119 01  41 "Boot Strap"
* 0014e6fc: - 120 00  41 "dos.library"
* 00156394: - 120 80  41 "mathffp.library"
* 001f2f60: - 120 80  44 "workbench.library"
* 0015ae60: - 121 04   1 "FSLoader"
* 001ef89c: - 122 84  44 "icon.library"
* 0014fb0e: - 123 04  41 "LDDemon"
* 001f8fa0: - 123 04  41 "shellcommands.resource"
* 001fc5d4: - 123 04  44 "workbook.resource"
* 001fcc52: - 123 00  40 "workbench.task"
* 00171f74: - 124 84  41 "con.handler"
* 0017c476: - 125 04   1 "amberram.handler"
* 00197704: - 128 04  41 "dosboot.resource"
KickTag residents:
* 001fe78a:  110 00   0 "1234-BootPrefs0"
Resident modules after KickTags merge:
+ 00195afc:  127 02   3 "kernel.resource"
+ 0013e380:  120 42  41 "exec.library"
+ 00154e1c:  110 82  41 "expansion.library"
+ 001fe78a:  110 00   0 "1234-BootPrefs0"
+ 00151798:  105 82  41 "utility.library"
+ 00154f3a:  105 01  41 "diag init"
+ 0015a930:  104 81   2 "partition.library"
+ 001413d8:  102 81  41 "aros.library"
+ 0019d028:  100 81  41 "potgo.resource"
+ 00196118:   99 01   2 "processor.resource"
+ 00153af0:   94 81  42 "oop.library"
+ 0017cb64:   92 81   1 "hiddclass.hidd"
+ 0019ce50:   80 01   0 "cia.resource"
+ 0019d864:   80 01   1 "FileSystem.resource"
+ 0019469c:   70 81  41 "battclock.resource"
+ 001894ac:   66 81   1 "graphics.hidd"
+ 001b5e3c:   65 81  41 "graphics.library"
+ 001bb4d0:   60 81  41 "layers.library"
+ 0015dd4c:   50 81  41 "timer.device"
+ 00168784:   50 81  41 "audio.device"
+ 0019dcac:   50 81  41 "m680x0.resource"
+ 0018a698:   45 81   1 "keyboard.hidd"
+ 0018afb4:   45 81   1 "mouse.hidd"
+ 0019dadc:   45 01  41 "misc.resource"
+ 0015f7f0:   44 81  41 "keyboard.device"
+ 0016746c:   44 81  41 "gameport.device"
+ 0018b88c:   40 81   1 "amigakbd.hidd"
+ 0018c2b8:   40 81   1 "amigamouse.hidd"
+ 001a390c:   40 81  41 "keymap.library"
+ 0019d634:   39 81  41 "disk.resource"
+ 00166988:   35 81  41 "trackdisk.device"
+ 0015ecb0:   30 81  41 "input.device"
+ 001dee48:   15 81  50 "intuition.library"
+ 0018ffe8:    9 81   1 "amigavideo.hidd"
+ 00193b20:    8 81   1 "uaegfx.hidd"
+ 001644f8:    4 81  41 "console.device"
+ 0016d8ac:    4 81  41 "ata.device"
+ 001ea1a4:    0 81  41 "gadtools.library"
+ 00178bcc: -   1 81  41 "afs.handler"
+ 001fcfee: -  45 01  41 "alert.hook"
+ 00155ba2: - 119 01  41 "Boot Strap"
+ 0014e6fc: - 120 00  41 "dos.library"
+ 00156394: - 120 80  41 "mathffp.library"
+ 001f2f60: - 120 80  44 "workbench.library"
+ 0015ae60: - 121 04   1 "FSLoader"
+ 001ef89c: - 122 84  44 "icon.library"
+ 0014fb0e: - 123 04  41 "LDDemon"
+ 001f8fa0: - 123 04  41 "shellcommands.resource"
+ 001fc5d4: - 123 04  44 "workbook.resource"
+ 001fcc52: - 123 00  40 "workbench.task"
+ 00171f74: - 124 84  41 "con.handler"
+ 0017c476: - 125 04   1 "amberram.handler"
+ 00197704: - 128 04  41 "dosboot.resource"
SS  lower: 00131620
SS  upper: 0013561f
callroms 10
Read boot ROM base=00ea0000 type=d2
bus=80
size=4f2
Call boot rom @00013a84 board 00ea0000 diag 000139b8 configdev 000036c8
callroms done
[ATA--] ata_init: ata.device Initialization
[ATA--] Gayle ID=d1. Possible IDE port=00da0000
[ATA--] Status=00
[ATA--] ata_init: MemPool @ 68084178
[ATA--] ata_init: BootloaderBase = 00000000
[ATA--] Gayle ID=d1. Possible IDE port=00da0000
[ATA--] Status=00
[ATA>>] ata_RegisterBus: Analysing bus 0, units 0 and 1
[ATA>>] ata_RegisterBus: IRQ 2, IO: da0000:da1010, DMA: 0
[ATA  ] Approximate number of iterations per 100 nanoseconds: 1
[ATA  ] ata_InitBus(0)
[ATA00] ata_InitBus: Device type = 0
[ATA01] ata_InitBus: Device type = 0
[ATA  ] ata_ResetBus(0)
[ATA  ] ata_InitBus: Finished
[ATA>>] ata_RegisterBus: Bus 0: Unit 0 - 0, Unit 1 - 0
[ATA--] ata_Scan: Initialising Bus Tasks..
[ATA  ] ata_setup_unit(0,0)
[ATA  ] ata_setup_unit(0,1)
[ATA--] ata_Scan: Waiting for Buses to finish Initialising
[ATA--] ata_Scan: Finished
romtaginit
initresident 139c6 '1230scsi.device'
romtaginit done

Include also KS3.1+/OS3.1+ tools/showconfig output

PROCESSOR:      CPU 68060/68060fpu/68060mmu
CUSTOM CHIPS:   AA PAL Alice (id=$0023), AA Lisa (id=$00F8)
VERS:   Kickstart version 45.57, Exec version 45.20, Disk version 45.3
RAM:    Node type $A, Attributes $505 (FAST), at $8000000-$CFFFFFF (80.0 meg)
       Node type $A, Attributes $505 (FAST), at $7000000-$7F7FFFF (15.5 meg)
       Node type $A, Attributes $703 (CHIP), at $80000C8-$1FFFFF (~3970.0 meg)
BOARDS:
Board (phase 5):   Prod=8512/34($2140/$22)
    (@$40000000, size 64meg, subsize same)
Board + ROM (HD?) (phase 5):   Prod=8512/12($2140/$C) (@$E90000 64K)

GDB

The C:GDBStub for amiga-m68k is ready for general consumption. Configuration file only:

win32.serial_port=tcp://localhost:1234

Add /wait if you want emulator to delay startup until someone connects first.

To enable the GDBStub, do:

AROS> Run C:GDBStub

The next time AROS crashes with a trap (or you run 'C:GDBStop'), the GDB stub will wait on the (real or virtual) serial port for a GDB connection

Use the following .gdbinit with m68k-elf-gdb to connect to the GDB stub under AROS:

---- .gdbinit ---
file  ../AROS.amiga-m68k/distfiles/aros-amiga-m68k-rom.elf
cd ../AROS.amiga-m68k/bin/amiga-m68k/AROS
source .gdbinit
## Uncomment for WinUAE connection
# target remote localhost:1234
## Uncomment for serial connection
# target remote /dev/ttyS0
## Fix up Debug_ModList
set variable Debug_ModList = &KernelBase->kb_Modules
--------------

Then all the regular AROS GDB debugging macros work, like 'loadseg', 'modlist', 'showtask', etc.

I've been able to get nice full backtraces through kernel and user code with full GDB support with this. It's making m68k debugging a lot easier.

You can get the m68k-elf-gdb.

The upshot of this, is that PARANOIA_CFLAGS is now gone. If you want to enable a '-Wall -Werror' build, just add '--with-paranoia=yes' to your configure, and the while tree will be built such that any compiler warning stops the build.

Errors

You need to watch out for certain issues

log is eating some lines and line feeds. (or expecting linefeed+formfeed instead of single linefeed).

[ColdCapture] Ignoring AOS->AROS trampoline [start]
InitCode(RTF_SINGLETASK, 0)

For example above line should have linefeed after trampoline and few other lines seem to be completely missing (truncated because of too long line?) and early configchain lines.

Most confusing are missing expansion/autoconfig related lines. ("configchain"). Missing ATA lines are normal in some logs because A4000 IDE no-drive detection is simpler than A1200.
Does early startup menu work? (Keep pressing both mouse buttons even if it appears to be hung, for example Blizzard SCSI init takes ~10s). Yes, it works. I remember blizzard scsi to be a little troublesome. Reboot with holding lmb+rmb to early boot screen

Another try with drive attached directly to ide port has succeed to boot me from the hd into a screen with only red cursor but nothing else. anyway it seems to boot the current nightly. On following try, I have been able to boot into aros with no startup-sequence. commands working.

[reset]
[SysBase] fakebase at: 0000020c
RAM lower: 00001000
RAM upper: 001fffff
BSS lower: 00135be8
BSS upper: 00135de3
Protect: : 00001000
   bss: : 00135be8
   rom: : 00135df8
   ext: : 001a14b0
[prep SysBase]: 00001000
[new  SysBase]: 00001500
CPU: 68060 FPU: 68060
[ColdCapture] Ignoring AOS->AROS trampoline
[start] InitCode(RTF_SINGLETASK, 0)
SS  lower: 00131be8
SS  upper: 00135be7
[ATA--] ata_init: ata.device Initialization
[ATA--] Gayle ID=d1. Possible IDE port=00da0000
[ATA--] Status=50
[ATA--] ata_init: MemPool @ 6807f338
[ATA--] ata_init: BootloaderBase = 00000000
[ATA--] Gayle ID=d1. Possible IDE port=00da0000
[ATA--] Status=50
[ATA>>] ata_RegisterBus: Analysing bus 0, units 0 and 1
[ATA>>] ata_RegisterBus: IRQ 2, IO: da0000:da1010, DMA: 0
[ATA  ] Approximate number of iterations per 100 nanoseconds: 1
[ATA  ] ata_InitBus(0)
[ATA00] ata_InitBus: Device type = 1
[ATA01] ata_InitBus: Device type = 1
[ATA  ] ata_ResetBus(0)
[ATA00] ata_ResetBus: Wait for Device to clear BSY
[ATA00] ata_ResetBus: Wait left after 0 ms
[ATA  ] ata_ResetBus: Wait DEV1 to allow access
[ATA  ] ata_ResetBus: DEV1 1/2 TimeOut!
[ATA  ] ata_ResetBus: DEV1 1/2 Wait left after 50 ms
[ATA01] ata_ResetBus: Wait for Device to clear BSY
[ATA01] ata_ResetBus: Wait left after 0 ms
[ATA  ] ata_ReadSignature(00)
[ATA 0] ata_ReadSignature: Status 50 Device a0
[ATA 0] ata_ReadSignature: ATA[PI] device present. Attempting to detect specific subtype
[ATA 0] ata_ReadSignature: Subtype check returned 00:00 (0000)
[ATA 0] ATA_EXECUTE_DIAG sent
[ATA 0] ata_ReadSignature: Further validating ATA signature: 1 & 0x7f = 1, a0 & 0x10 = unit
[ATA 0] ata_ReadSignature: Found *valid* signature for ATA device
[ATA  ] ata_ReadSignature(01)
[ATA 1] ata_ReadSignature: Status 00 Device b0
[ATA 1] ata_ReadSignature: ATA[PI] device present. Attempting to detect specific subtype
[ATA 1] ata_ReadSignature: Subtype check returned 00:00 (0000)
[ATA  ] ata_InitBus: Finished
[ATA  ] ata_init_unit(0)
[ATA>>] ata_RegisterBus: Bus 0: Unit 0 - 2, Unit 1 - 0
[ATA--] ata_Scan: Initialising Bus Tasks..
[ATA1654092] IRQ: Checking busy flag: device still busy. ignoring irq.
[ATA  ] ata_setup_unit(0,0)
[ATA  ] ata_setup_unit: Enabling IRQs
[ATA00] ata_Identify: Executing ATA_IDENTIFY_DEVICE command
[ATA00] IRQ: Checking busy flag: device still busy. ignoring irq.
[ATA--] ata_Scan: Waiting for Buses to finish Initialising

Since every expansion been physically removed from this machine and still getting the same log missing "configchain" and friends?

Perhaps possible cyberstorm 0x00f00000 mapped ROM does something strange..

Download http://aminet.net/dev/moni/mon165.lha
AOS coldstart (power off, power on), boot without startup-sequence. (coldstart is important, it is possible strange residents are active after warm start)
Run "mon"
type "] f00000 10000 dump.rom" to save rom data. (now you can reboot normally)

Zip and email the file.

Screen mode prefs crashing after selecting mode has been happening since the beginning. Tried to debug this long time ago but never found anything interesting. Now I just ignore the crash and reboot when need to change modes :)

m68k Native Environment Sources

If you want to set up a m68k build environment, just run the 'arch/m68k-amiga/doc/build-toolchain.sh' script. It'll download and compile all the m68k crosstools, and install them to /opt/m68k-elf (or wherever else you want them to go)

Jason's typical m68k ./configure is:

$ configure—target=amiga-m68k \
            --with-optimization="-Os" \
            --with-paranoia="-Wall -Werror" \
            --with-serial-debug \
            --enable-debug=all

None of the AROS regcall macros have been extensively tested with -O2. Some don't have a m68060 to test with. The default optimization is '-Os', which on systems with no or small instruction caches usually gets you better performance than -O2 anyway.

Older method for compiling your own version....

arch/m68k-amiga/doc/README.txt - add GCC/Binutils fetch/compile/install script

The regcall config (target amiga-m68k). Note The stackcall configuration (target amiga-m68k-eabi) is obsolete.

NOTE: To use the regcall config, you *must* apply the patch, at the bottom of this page, to GCC 4.5.1 to get GCC to *not* trample on A6. Actually, I checked in a fix for my macros that got A5 working. I have another fix that should allow an unpatched GCC (one that wants to use A6 as the Frame Pointer) to work.

Since the nightly AROS m68k build is designed to run, unmodified, on *all* Amiga architectures (m68000 - m68060), I always compile with -m68000. Feel free to compile your own custom build with different ./configure—with-optimization=... options.

Compiled m68k-elf binutils

./configure—prefix=/opt/m68k-elf—target=m68k-elf

Compile gcc-4.5.1 as follows:

$ cd gcc-4.5.1
$ ./configure  \
        --without-headers \
        --disable-threads \
        --disable-libssp \
        --disable-nls \
        --disable-shared \
        --without-pic \
        --prefix=/opt/m68k-elf \
        --target=m68k-elf \
        --program-prefix=m68k-elf- \
        --enable-languages=c

—program-prefix=m68k-elf - is not needed, it seems prefix is added automatically.

Build and install gcc-4.5.1 (to /opt/m68k-elf, or whatever you set—prefix to)

lib directory needs to be created manually

mkdir bin/amiga-m68k/AROS/Development/lib

$ export PATH=$PATH:/opt/m68k-elf/bin
$ cd AROS
$ autoconf
$ ./configure --target=amiga-m68k \
              --with-optimization="-Os" \
              --with-serial-debug
$ make

(wait for zune/betterstring to kill the build)

$ make kernel-link-amiga-m68k

(wait a bit) You'll end up with the following files: Finally finished successfully! (total time something like 4 hours..)

bin/amiga-m68k/AROS/aros-amiga-m68k.elf
bin/amiga-m68k/AROS/aros-amiga-m68k.rom

The .elf is useful for feeding to GDB to attach to a UAE serial port when debugging...

The .rom, which you can feed to UAE like so:

uae -s kickstart_rom_file=bin/amiga-m68k/AROS/aros-amiga-m68k.rom

Tested with UAE running as a 'stock' A1200 AGA

Clean AROS build, using this configure line:

../AROS/configure—target=amiga-m68k—with-optimization="-Os"—with-serial-debug

Try also building from scratch, sometimes all files won't get automatically rebuilt.

https://gitorious.org/aros/aros

Things to note for m68k 'ROM'able code:

No global variables - There is no .data nor .bss section in the ROM!
Global -constants- are ok - We do have .rodata

If you need to open a library, you have to do it explicitly - you can't use the AROS autopen feature.

VBCC supports some C99 and all C89. Both GCC and LLVM work with all levels up to from C89 up to C++14. VBCC doesn't even support C++ at all. I'm afraid Volker doesn't have as much time to update his compiler as PHX does with VAsm and VLink. Also, LLVM and GCC both have huge teams behind them: Apple and Linux respectively. There's a better license situation for LLVM (BSD equivalent vs. GPL3) and VBCC requires written permission for any commercial use, as do VAsm and VLink.

VBCC doesn't support GNU extensions found in GCC. Clang does but is almost as heavy as GCC. Frankly, I doubt that getting the backend up-to-date on GCC would be any less work than finishing the LLVM 68k backend on my GitHub account.

GCC generates bad 68K code, so it means that AROS' binaries are bigger, and the execution speed is slower than the Amiga 3.x binaries. The problem with GCC isn't the compiler framework itself, it's the backend that translates from the intermediate representation to the final binary. The backend produces suboptimal 68k code from optimal intermediate code. Ultimately we need a new or updated backend regardless of whether GCC or LLVM is used.

The Amiga 3.x o.s. has large parts written in assembly code, where in AROS this is a very small portion (the strictly needed to interface the o.s. to the hardware).

Linux Hosted Builds

debian7 build, acquiring the sources please refer to the "building aros68k"

as for the dependencies for x86 hosted build you will additionally need

-x11-dev headers and link libs

for compiling contributions (you will first need to cop the contribs folder into the aros folder and then "make contrib" you will need cmake and gperf package for aros-owb.

first of all configuring: building from the parallel folder you need to specify

../AROS-source/AROS/configure—enable-x11-shm—enable-x11-hidd—enable-debug—with-serial-debug=yes

first both options are supposed to give you integration with x11 system to get just any graphical output. the lest two options are due to debugging, they can be omitted in plain user builds.

whoever encounters following error:

   Making     country files...
   /home/wawa/x86-build/bin/linux-i386/gen/workbench/locale/countries/makecountry: System locale is invalid

temporarily solved it with "dpkg-reconfigure locales" setting en_GB.UTF-8 as default. otherwise compiling as root has worked around it

first of all aros dependency packages that need to be installed on your (cross)compiler host:

    binutils-source
    libcloog-ppl-dev (adds lots of other dependencies)
    g++ (may be necessary too look for gnu-c++ compiler package)
    libelf-dev
    bison
    flex
    gcc-4.5-source (doesn't seem to be necessary anymore since the compiler version has been upgraded)
    libmpfr-dev
    libmpc-dev
    libecm-dev
    netpbm
    automake
    libpng-dev (libpng12-dev)
    libc6-dev-i386

acquiring the V1 sources:

the sources can either be downloaded under below link: http://aros.sourceforge.net/de/download2.php or via git (assuming you have this package installed):

    mkdir AROS-source
    git clone git://gitorious.org/aros/aros.git AROS-source
    cd AROS-source
    git checkout ABI_V1

now actually building aros in a separate build directory created at the same level as AROS-source dir:

    mkdir build
    cd build
    ../AROS-source/AROS/configure --target=amiga-m68k --with-serial-debug=yes
    make

here is another method: building aros 68k crosstools in a separate directory:

we are starting over. directory structure (note this differs from previous example)

<some dir>
- aros (clean aros sources here, no binaries!)
- build-m68k-tools (cross compiler will be built here)
- yet another directory where aros-m68k will be build (I just use "build")

    <some dir>
    cd build-m68k-tools
    ../aros/configure --target=amiga-m68k --with-aros-toolchain-install=/opt/aros-m68k
    sudo make -s crosstools

(sudo is necessary because toolchain will be installed in /opt/aros-m68k. otherwise the build will fail)

the crosstools should now be built successfully.

now we go back to our main dir:

cd ..

building aros in yet another separate directory:

change to the build directory, configure and build aros there.

    ../aros/configure --target=amiga-m68k --with-aros-toolchain-install=/opt/aros-m68k --with-aros-toolchain=yes --with-serial-debug=yes
    make -s (-s to keep it less verbose)

aros is now to be found under /build/bin/amiga-m68k/AROS the executables are all in elf format, so if we want aros to softboot from an amiga kiskstart we need to convert boot/amiga/AROSBootstrap to a hunk executable which can be done with a tool compiled for the host architecture, in this case ubuntu which is to be found under /build/bin/linux-i386/tools/elf2hunk

the boot/amiga/AROSBootstrap needs to be replaced with the resulting file. and the s:startup-sequence needs to be modified to load the aros.elf:

boot/amiga/AROSBootstrap ROM  boot/amiga/aros.elf

now copy the contents of /build/bin/amiga-m68k/AROS directory to an amiga bootable partition. you should be able to boot aros with it either on uae or on an actual amiga computer. :)

some additional make options:

make distfiles - should automatically convert elf executables to hunk (to be confirmed)

make kernel-link-amiga-m68k - builds the kickstart rom file aros.elf

make (module name to find in the mmakefile.src in the source dir of particular module)-quick - builds the desired module with a quick option to spare some tome.

Note that in order to rebuild module after editing the source, the compiled binaries have to be deleted first in the build target dir. in order to work on and build some modules it might be necessary to compile the complete build first.

ELF to HUNK and back

It does use Amiga hunk files, and you can mix and match to some degree (AROS components are ELF files), But AROS can load both :) Works both ways, not just Amiga files in an AROS environment, but AROS executables in an Amiga environment. The tool to use is ELF2HUNK by Jason McMullan. There are some limitations. Most notably, AROS apps using arosc.library (sort of ixemul) won't work (at least not yet), and arosc.library itself won't work so moving that over won't do you any good. But apps that stick with purely the AmigaOS API will work. This restrictions makes it quite limited at the moment. To get AROS components working on AmigaOS you're better off looking AfA.

Remember that still, Amiga68k is much more optimised/faster than AROS on the same hardware, but we are working on that.

The fact that we plan to switch to ELF executables in the future and not relocatable objects. We still need relocation info in the file. If you call strip on an ELF executable with relocation data you keep the relocation data but loose the SysBase symbol. But a wrong "strip" would make any current executable unusable anyway: we need a symbol table and reloc info in order to load up executables.

History

First ever attempt?

Late 2008: Heron aka Gregory John Casamento decided on take on the m86k port.

Monday, January 5, 2009: ARaNyM Configuration woes... Currently trying to get ARaNyM working so that I can proceed with the build of AROS on 680x0.

This port sadly ended a few months after this post, it proved difficult to retrieve reference material and also old hardware as well in order to complete the bounty (material such as Rom Kernel Manuals, technical newsletters, developers kit,etc.)..

2010

January 4, 2010: Gary Pearman wrote Welcome to my first blog post. This blog is here primarily for me to collect my thoughts, and to keep all the AROS folks updated with my progress on the Kickstart ROM replacement bounty. Cheers, Gaz.

January 12, 2010: After chatting to a number of people on the AROS dev list and #aros, I’ve decided to change tact on the bounty and try a different approach. The idea is to forget about the stuff in .unmaintained, and try to get AROS compiling for m68k-hosted. For work to begin, I’ll need to get debian m68k installed and running on Aranym (yes, an Atari ST virtual machine).

January 23, 2010: Progress - OK, so I decided to scrap the Aranym route and face my fear of the AROS build process! Basically I’ve started the m68k-amiga build files from scratch, and based them on the ppc-sam440 build files, which are nice and new and clean. I’ve removed pretty much everything that was in unmaintained, and am just trying to get the kernel compiled.

March 21, 2010: Work Work Work - I’ve been really busy recently with other work, so I’ve not had time to look at the (now overdue) bounty.

As of April 2010: work has halted again on the motorola 68k port of AROS.

Initially the port, which will not depend on a MMU being present, will target UAE first Phase 1. Certain dedicated amiga hardware support (goal of being able to boot most KS1-3 disks including games and demos and cover processors 68000, 68020, 68030, 68040 and 68060) is to follow in Phase 2. Then follows alpha testing with a low level debugger with a full bug report. Optimizations and then finally general testing.

to make it actually compile correctly (that was very big task - Jason in Phase 1 2010)
add low level kernel code (task switching, interrupt handling etc.. Jason in Phase 1 2010)
add hardware drivers (mouse, keyboard, graphics P96 RTG, disk etc..) Toni has done these for Phase 2 2011
some further hardware support (Gary IDE, afs handler, etc.) Toni has done these for Phase 2 2011

Phase II is to provide a *baseline* kickstart replacement. Please do not expect drivers for non-official Amiga hardware (e.g. Natami or Replay FPGA Arcade), only real Amigas or UAE. All timings and display settings currently assume PAL configuration at the moment. Recommended using RTG modes, custom chipset driver is just a proof of concept (It is not going to be optimized or improved until more important features work).

Sunday 10 October 2010: Jason S McMullan (ezrec) wrote on Finally, after 3 weeks first light on my m68k port of AROS to m68k-amiga. Doesn't work, crashes pretty soon, but I have gotten past the 'compile it', 'compile it with Amiga ABI', and 'get into Exec Init' phases. Very happy.

17 October 2010: the m68k-amiga core has been checked in.

Mon Oct 18, 2010: at 6:10 PM, Jason McMullan wrote: finished my (minimalist) gcc patches that bring in Fred Fish's asm() tags for register parameters (regcalls), and am working on getting AROS to compile with that. Mostly reshuffling variable declarations to be all at the top of functions and such.

Wednesday, 20 October 2010: my GCC 4.5.1 troubles are over. Using the trivial patch to GCC 4.5.1 that moves the default FP register from A6 to A5, and the new 'gencall.c' I checked in to generate the libcalls, I can now do proper Amiga-style register libcalls! because of AROS stub design you can run into problem, when you call an amiga function that use the same register that you have put into register variable e.g. when you tell GCC to use register a2 as foo. This is solved by macros. I take care of all of these issues. The toolchain I am using will only generate ELF binaries. The *ROM* will be able to load and run both ELF and HUNK (eventually), but I do not plan to add HUNK support to the toolchain.

Monday, 1 November 2010: Toni Wilen wrote - disk.resource (trackdisk.device) - cia.resource (cia interrupts) - potgo.resource (mouse 2nd/3rd button) - trackdisk.device (currently read-only, based on PC driver, large rewrite required, no disk.resource use, was very PC controller specific) - amiga mouse hidd - amiga keyboard hidd. Jason wrote AWESOME! All we need now is 'just' graphics.hidd and disk block read and we'll be able to boot AROS w/out frankenrom!

Wednesday, 3 November 2010: Jason wrote KS 3.0: Getting there! Exec will now get to the boot screen via OS3 libraries! I need to make a disk with *just* the Install boot block now.

Wednesday, 3 November 2010: Toni Wilen assigned KS Bounty Phase 2. Main missing driver appears to be gfx hidd, my first attempt will be UAE-only Picasso96 HIDD, remaining updates should be quite simple when display is working. (mainly hunk loader, expansion.library autoconfig?). I am not against custom chipset HIDD but UAE Picasso96 HIDD (using native UAE Picasso96 helper routines that AmigaOS(TM) side Picasso96 uses) would be much easier and faster to implement and also would make non-HIDD parts much faster and simpler to debug. (no shared VRAM, less code, 1:1 framebuffer mapping etc..). I also don't really see the point in custom chipset gfx HIDD if it is only a dummy framebuffer, losing all custom chipset features (hardware sprites, user copper lists etc..), it would be worst of both worlds :). Some kind of simple custom chipset gfx HIDD that shows possible CLI messages when booting games would is of course needed in future but that should come later when everything else is working and provide a 'base level' of functionality for someone who would be interested in providing OCS/ECS/AGA support.

Mon, 8 Nov 2010: Jason wrote The ROM is now split. The 'rom' image will contain everything needed to boot from disk, and the 'ext' image will contain everything that is not needed for that task. Ideally, the libraries and resources on the 'ext' disk could be on the AFS filesystem. For now, intuition, graphics, and layers live on 'ext'.

0xf80000-0xffffff: a-m-a-rom.bin - 0xe00000-0xe7ffff: a-m-a-ext.bin.

Sun 7 Nov: Toni wrote I need to check in the non-hacky code changes, then some sleep.

Jason then wrote Just woke up so I guess it is my turn now :D - Tag team programming.

Thu, 12 Nov 2010: Jason wrote Shell is up and running

Tue, 16 Nov 2010: Phase 1 considered complete. Some Amiga hunk support included as well.

Mon, 22 Nov: Toni wrote

only tested using WinUAE, requires latest WinUAE beta (2.3.1b6) which re-adds years ago removed "old-style" RTG interface, should work in all UAE versions that have Picasso96 support.
paletted 8-bit mode only tested and chunky 640x480x8. 16-bit and 32-bit PC-style modes included but not tested.
most native blitter functions used = fast. But it will be really slow if your UAE port does not support any P96 blitter functions, current driver simply falls back to megaslow get/putpixel mode. Report this and I'll add "software accelerated" CopyBox() and friends.
afaik only WinUAE have hardware sprite emulation and only in D3D mode (for some reason aoHidd_Gfx_SupportsHWCursor = FALSE does nothing?)
Z3 32bit fast RAM boards work now properly.
UAE directory filesystem hanging issue is solved (volume label/name is still weird... can't be used)
most stuff in startup-sequence work (biggest exception being workbench). We decided to improve WB/OS usage first, it also makes debugging much faster and easier.

Tues 23 Nov: Jason wrote So, here's my post-Kickstart Bounty I task list, in priority order: Priority 0: Assist Toni Wilen.

Get AROS KickStart to be able to use LDDaemon to pull the AROS graphics, workbench, gadtools, etc. libraries from the boot drive's Libs/ directory - cleaning up various issues, and testing. Trying to fix the hyperlayers/graphics circular dependency.
Get AmigaOS 3.1 + AROS Libs/ on HD0: booting - AmigaOS workbench.library from disk - BCPL work, as needed - Figure out what to do about ConClip
Get AmigaOS 3.0 + AROS Libs/ on HD0: booting - More BCPL work
Get AmigaOS 1.3 + AROS Libs/ on HD0: booting - Even more BCPL work, compatibility fixes

Tues 07 Dec: Toni wrote dos.library compatibility has improved greatly (and it is also much faster). For example original WB2/3 disks boot now without warnings, errors or crashes. Note that Workbench won't work because there isn't one included in ROM yet, Wanderer which is AROS WB replacement is too big. BCPL support is coming soon (Jason is doing this). Jason wrote With Toni's DOS Packets patches, and my recent checkins tonight, I currently have C:Echo from WB 1.3 (BCPL!) working. Now that the BCPL and Packet support infrastructure is here, full AmigaOS 1.3 support for BCPL CLI applications is just a Small Matter of Programming. I expect to have 95% of the Workbench 1.3/3.0/3.1 BCPL apps working by mid-January 2011. Does anyone know of any 'major' BCPL applications out there that I should test with other than those on the Workbench/Install disks for 1.x/2.x/3.x?

Sun 19th Dec: Toni added most common parts of the dos packet mode AFS handler... Toni added more missing dos packet AFS handler commands...

Monday 27 December 2010: Toni wrote m68k-amiga AROS port now boots AROS original startup-sequence without any weird side-effects (no insert disk requesters or boot shell not closing etc.). Most utilities run and most preferences programs at least open.

prefs/screenmode shows random (uninitialized variable?) values in width, height and depth string gadgets. (and system crashes when selecting any mode, I will debug this later) GUI issue is too high level stuff for my debugging tastes. (I also have personal issues with MUI)
WB "Information" menu does not open, TextEditor.mcc does not init. (MUI again, argh)
WB doubleclick detection is very unreliable.
compiler/alib/timedelay.c and compiler/include/clib/alib_protos.h does not match. I tried adding AROS_UFP3 () macro to alib_protos.h but then intuition/menutask_aros.c refuses to compile. (nothing too serious, currently it only makes all TimeDelay calls to fail due to UnitNum being some large number)
finally, WB1.3 startup-sequence runs quite nicely now. Remaining problems: FastFonts (ff) corrupts all fonts and system/setmap expects LONG return type from OpenDevice(). Is it ok to change OpenDevice()/WaitIO()/DoIO() return type to LONG? it should have no effect to existing programs.

Friday, 31 December 2010: Toni wrote SYS:Extras/Zune/ MCC_NList/s/Package-Startup can't work (is it even needed? SYS:Classes has already been assigned at this point). Assign opens boot console window and prints "can't find Classes" because startup-sequence SYS:Packages part CD:s to package directory before executing the script. Either Package-Startup (and Shutdown) should be removed or command should be "Assign LIBS: SYS:Classes ADD". Also C:Assign is broken, it calls NameFromLock() inside doslist lock which can be bad idea (probably not a problem in non-dos-packets mode). And finally, the final year 2010 status report:

Wanderer PNG icons now render correctly (needs truecolor UAE RTG mode, note that screenmode change crashes, you must select save + cold reboot), WinUAE-only truecolor hardware sprite colors fixed.
Shell CTRL+D and CLI faillevel checks implemented (at least works in dos packets mode, something still wrong because >NIL: swallows some error output that should not be swallowed)
UAE mousewheel keycodes don't repeat forever anymore.
Titanics cruncher pseudo-overlay executables supported :) (real/full overlay executables not yet supported)
WB1.3 C:FF does not corrupt fonts anymore. WB1.3 startup-sequence now works perfectly. (minus workbench)
and more.

2011

Friday, 7 January 2011: Jason wrote Just got my ACA 1230/56, which will allow me to start testing AROS on my Amiga 1200 (need to pick up a gender-bender tomorrow for serial!), and am well on my way to see if I can get AROS m68k working on real hardware. Wish me luck! First boot log on my A1200 - hung during initialization, will add some debugging tomorrow. Toni wrote Probably something to do with autoconfig. Could you run Scout and attach autoconfig details from each autoconfig device in your system. Expansion autosize z3 ram board support committed. Also exec relocation works now and is enabled.

Thursday, 13 January 2011: Jason wrote AROS on the A1200 is mighty slow, but I think that is mostly due to the unoptimized AGA interlace mode that I'm getting by default. I reset all the '#define DEBUG 1's that have been left on in the amiga-m68k (and a few other places) to '#define DEBUG 0', and we can now disable—enable-serial-debug (and yet still get SAD on the serial port). Reducing the serial debugging (and putting the OOP MID .bss in Chip RAM, which turned out to by only 512 bytes or so) did little to improve the graphical performance, so I'll let Toni worry on that for now. The mouse works fine on AROS on the A1200, but I'm getting no keystrokes. I'll debug that tomorrow night, unless Toni beats me to it. It has to be something else If it is slow even when display is idle. Toni wrote Perhaps it is related to non-working keyboard, badly working keyboard handshake can steal too much interrupt time. Compare to WinUAE quickstart A1200 cycle-exact most compatible mode, if it is as slow or even slower: it has to be hardware compatibility problem. Gayle compatible ata.device status: drive detection partially working, should be "fully" working today or tomorrow. (It is currently huge mess of ifdefs, will be cleaned up after it is confirmed working).

Saturday, 15 January 2011: Toni wrote m68k-amiga ata.device is now done. (should it be called "scsi.device"?). I separated pc hardware specific code and amiga specific code (ata_pc and ata_amiga), ata.device maintainer can merge this back to rom/devs/ata.device if interested (I don't mind if Amiga version breaks, I just don't want to break "PC" version or cause accidental data corruption.. IDE is too weird, too easy to break). A600 and A1200 Gayle interface and A4000 Gayle-like interface supported. (A1200 real Amiga tested only).

hardware specific parts separated
some CF cards (maybe others?) seem to return 1 as multiple transfer size. Only set values listed in ATA spec (2,4,8,16,32,64,128)
added ATAF_DRDY wait after execute diagnostics ATAF_BUSY wait, above CF card seem to hang if new command is sent after execute diagnostics but before DRDY is set.
#ifdef DMA support and other stuff that Amiga port does not need.
do not initialize device driver if no drives detected. (quick'n'ugly test only)
do not start ATAPI media check task if no ATAPI devices detected.
and something I forgot..

WinUAE note: that you need 2.3.1 beta 11 (release later today) or newer because execute diagnostics was not emulated. (I don't emulate commands that appear to be unused, not even m68k linux or netbsd used it)

Sunday, 16 January 2011: Toni wrote AROS ROM loader is finally working on my A1200 (Blizzard 1260 + SCSI kit + SCSI-IDE + 8G CF card). Blizzard 1260 Fast RAM and 1230scsi.device also seem to work properly, even boot partition mounts (PFS3ds) and autoboots (but second partition does not mount, which is SFS formatted. Don't ask.). Display is painfully slow and flickers, I guess native chipset driver optimization is needed sooner or later.. Loader and instructions how to build relocatable rom image will be released later. I am also going to do A3000 tests first. (It must work before public release). Only requirement is 1M or more MEMF_LOCAL fast RAM (RAM that does not disappear during reset) or 2M chip RAM (in this case upper 1M will be used by ROM). MMU is not used or needed (I don't want to touch anything MMU related). Everything is handled by loaded AROS "ROM", including autoconfig. Debugging this thing took ages when you only have serial output.. I think I'll have to include HRTMon debugger with ROM loader :)

Thu 27 January: Jason wrote does anyone have any interest in Alpha-testing AROS m68k? Right now we (Toni and I) would need testers to:

Attempt to run AROS on A1200 and other Amiga hardware
Have at least 2M of chip ram and 4M of fast ram
Be able to debug by themselves any issues they find
Submit patches that fix those issues, or at least a small C or m68k assembly test case that demonstrates the defect.

We are not ready for general testing. If you don't know m68k assembly and your way around low level debuggers, please wait until the next phase in AROS m68k development. These early releases of AROS are guaranteed only to crash, destroy your data, and/or release all the magic smoke in your Amiga. You have been warned.

Thursday, 3 February 2011: Toni wrote time to check Kickstart ROM Replacement (Phase II) status.

Only missing part is creating AmigaOS binary compatible executables (ELF vs HUNK). Do we really need some kind of (really boring to code) ELF to HUNK converter? It is probably guaranteed that gcc will never directly create hunk binaries. (Jason, did you already do some work with conversion?)
And then there is part 4: where is this Michal's so called tool and who is going to use it? :) start Sys:Tools/Screengrabber, do screenshot and save the resulting file.
IMO this needs to be closed before starting ABI v1 (and dos packet?) merge because it probably breaks many things for (too) long time..

Tuesday, 15 February 2011: Jason wrote I think that ELF2HUNK is sufficient for letting people compile non arosc.library apps under AROS and get them to run under AOS, but getting AROS to run under AOS is a much larger task. I'll leave SetPatchAROS in for now - it's sufficient to run non arosc.library ELF apps under AOS 3.1. arosc.library is a pain, but what is worse are the extended functions in Intuition and Exec, which are difficult to cleanly add to the running libraries.

Wednesday, 16 February 2011: jason wrote that's why we're near the end of Phase II of the m68k Amiga KickStart *Replacement* bounty. My todo list after I get AROS-Contrib building again, is 'Wanderer Lite' as Toni's deadline for KS Bounty II is coming up, and I've promised him an in-ROM version of Wanderer that will fit on a A1200 with 2M of RAM, gdb with the GUI in a windows task and to give the math libs some attention.

Saturday, 26 February 2011: Jason wrote I've been working on cleaning up BGUI to work on m68k and hosted x86_64, with some good progress. The major BGUI demos now work on both m68k and x86_64, with the following issues and I should have these last issues cleaned up by the end of the weekend. $(PARANOIA_CFLAGS) has been enabled for those of you who ./configure with—with-paranoia.

LayoutGroup fails (m68k & x86_64)
Nested views (alignment issues) (m68k & x86_64)
Drag&Drop crash (m68k & x86_64)
PrefMX checkboxes (works on m68k, fails on x86_64)
bgui_calculator (works on m68k, fails on x86_64)

Tuesday, 8 March 2011: Toni wrote try it with latest winuae, it has built-in AROS rom image. Note that WB programs that use undocumented features or other weird things won't work (mainly 2.0+ c:setpatch and c:iprefs). 1.3 stuff works nicely. Native Display ModeIDs are not correct, they are using some generated IDs at the moment. (AROS graphics subsystems has some native graphics related limitations that need to be fixed before this can be 100% working, this is not my problem). Audio.device does nothing. (I haven't bothered with it yet, rarely needed for anything else than allocating channels).

Wednesday, 9 March 2011: Jason wrote Workbook Super lightweight Workbench/Wanderer replacement

Workbook is a BOOPSI based Workbench replacement, designed for very light weight systems, namely Amiga m68k.
This is the initial prototype checkin, which can (before it crashes due to some memory corruption I haven't fully diagnosed yet) open the disk volumes, drawers, and launch applications
TODO: Stop crashing, snapshots, copy, paste, rename, info, etc etc.

Total compiled size is 20k on m68k. This is *not* meant as a replacement for Wanderer on full systems. It is for low memory/slow cpu systems, and as an exerciser for workbench.library. I plan to use as many of the workbench.library hooks as possible. Once I get Workbook stable, and able to do some simple file management (delete, rename, copy, format), I plan to make it the ROM resident version of 'LoadWB', so that KS 1.3-3.x can use it as their 'Workbench'. Workbook, again, is completely optional for all other architectures, and will reside in SYS:System/Workbook/.

Wednesday, 9 March 2011: Toni wrote It is few weeks left before deadline. Anything else still needed before it is considered done? Things I am planning to do (not sure when):

Paula audio.device
Optimize native chipset gfx driver (it is currently painfully slow)
HIDD wrapper that supports Picasso96 *.card driver files. (already partially done but that was only the easy part..)

This is getting annoying, "not working" "bug reports", expecting everything to be done by me or Jason quickly, even if it is something that has nothing to do with the bounty, mainly changes in core code that can't be done without discussion and planning. Most of this stuff is something that only m68k-amiga port needs, you can't just add it and break all ports (I'd like to but that's not how it works). WinUAE stuff is much more relaxing because I can freely choose what I do and when I do without asking anyone. That's why I want this bounty done asap because only then I can do AROS stuff just for fun again without being held hostage. ("You still need to do this and that OR ..."). Debugging and enhancement will be ongoing.

PHASE 2 CONSIDERED COMPLETED.

25 March 2011: Toni wrote

2.x-3.1 WB disks should boot without problems, now also includes correct palette and mouse cursor settings.
fully compatible with WB2+ C:IPrefs now.
1.x works except C:Run (which only outputs errors) and AROS resident Run requires T: -> WB disk must be write-enabled.. Will be fixed later.
devs:system-configuration is loaded and used (1.x boot disk correct colors etc..)
reset proof programs supported (kicktags, coldcapture etc)
ArosBootStrap comes with source tree, Aros softkick loader that works on any Amiga that has either 2M of chip or 1M or more local fast RAM. (*)

Known problems:

do not use OS3.5+ setpatch, it is never going to work without specific setpatch detection.
system patches like FBlit etc can't be compatible. Do not use.
Scalos does not work, reason unknown.

3 April 2011: Toni wrote Most games that only use boot block to load hardware loader should work fine unless they assume KS1.x like memory allocation and overwrite OS structures or do something stupid that only works on 1.x accidentally. (which is not rare, unfortunately). 100% compatibility is impossible. There is no way to make ROM that is both 1.3 and 3.0/3.1 compatible at the same time. Even 3.1 compatibility can't be 100% because it would require implementing all known and unknown bugs 100% exactly! (it is guaranteed there is at least one program that only works because of some OS bug..)

some update notes:

real audio.device implemented but only minimal testing done (audio.device is rarely used for sound, usually only for channel allocation)
first part of aros graphics modeid updates done, modeid and depth separated. Next part is to replace generated modeids with real AOS modeids.

15 April 2011: Toni Wilen wrote Random status report.

UAEGFX RTG/custom chipset screen switching is finally working properly. Even whdload works perfectly now.

Thu, 26 May 2011: Toni wrote PutTemplate() blitter accelerated, should greatly improve native chipset speed, no more slow planar getpixel/putpixel "blits".

Sunday, 19 June 2011: Toni wrote ArosBootStrap now accepts more parameter(s), one or more extra resident files (similar to BlizKick). For example "arosbootstrap aros.elf.gz scsi.device_40.12(A3000)" allows AROS to boot from SCSI on my real A3000. (scsi.device is extracted from A3000 ROM using romsplit that comes with remus package).

Next phase is to support RTG boards using AOS Picasso96 .card and .chip files. (I think I already mentioned this few months ago).

"arosbootstrap aros.elf.gz libs:picasso96/CirrusGD542X.chip libs:picasso96/PicassoII.card scsi.device_40.12(A3000)" already loads on my PicassoII expanded A3000, PicassoII.card FindCard() and InitCard() functions already succeeded and works. Boot menu, boot animation and boot shell quickly tested. (It is time for break now, moving aros.elf.gz from PC to A3000 SCSI-IDE using Amiga formatted bootable CF will get quite annoying after 30 or so swaps..)

320x240, 640x480, 800x600 only supported, using hardcoded more or less standard timing variables.
All card supported color depths available, at least in theory.
Does not check most card capabilities like supported width/height/depth/pixelclock combinations.
Puts all bitmaps in VRAM, VRAM probably runs out very quickly or gets fragmented if program(s) allocate and free lots of bitmaps.
Uses driver's blitting functions if available.
Card's passthrough switching supported (if available).

Will be improved later, when/if I feel like it, debugging using real hardware wastes lots of time compared to emulation which is nearly instant. Also btw, other RTG cards and an A4000 would be nice to have, hint, hint :D

Find P96 driver(s) that your RTG board requires, note that some come in pairs (.card and .chip files), order of files is not important. Use arosbootstrap to load rom image and driver file(s), check serial log. Note that currently there is no supported method to directly merge driver files to ROM image. No serial log = no help.

Advanced chipset, A3000 SCSI. ("WD33C93 in use" appears in winuae's log when SCSI chip is used) But you don't need SCSI emulation to test it, it will work if you see InitResident('scsi.device') in AROS serial log :)

Link/merge utility also needs some extra functions:

set RTF_COLDSTART or RTF_AFTERDOS (needed to use RTG drivers or non-ROM modules, for example normal libs or devs*)
change resident priority (for example RTG drivers need to have higher priority than uaegfx.hidd)
RTG drivers need patching (they have OpenLibrary() paths like "libs:picasso96/something.chip" that won't work if physical file does not exit)
most normal libs/devs probably won't work after second reboot because they generally aren't "pure".

This is feature that I probably do some day, link it as a relocatable (or even compressed) file and relocate it to RAM during InitResident() time. Current plan is to have separate resource that includes all support routines and relocatable resident only has small routine that does OpenResource("relocstuff.resource") and if found, calls it to unpack/relocate it. Very little space wasted. Too many plans, not enough time..

Motorola 68040/68060 missing instruction emulation library is also working now, but it isn't yet rom built-in. It is quite big (~60k) so I guess it should be only included in arosbootstrap file at this point? (official 68040/68060 libraries may not be used because for example they need to update FPU stack frame handling = touch exec internals that shouldn't be touched).

Autoconfig support has been partially rewritten, most boards should now configure properly.

Tues, 5 July: Toni wrote - Lots of changes since last time..

AROS is now fully dos packets converted (all platforms)
Motorola 68040/060 support library ROM built-in
CDFS rom built-in (does not automount yet but probably in future)
Boot menu is now more useful (shows boot devices and expansions)
ArosBootStrap (softkick) mode AOS driver support. Allows use of any AOS ROM resident modules. For example A3000 ROM scsi.device can be used to enable real A3000 built-in SCSI in AROS. Also added support for Picasso96 driver files (.card and .chip files) to enable RTG support in AROS. Even boot menu and boot image uses RTG mode automatically.

Sat, 6 Aug 2011: Jason wrote Now actually comes up to Workbook, and used HUNK instead of ELF for the executables. This system disk boots under both AROS and AOS 3.x. Ideally, it should be extended with the AROS Install routine and CDROM drivers, to allow installation of AROS from an AOS kickstart.

Tues, 23 August: Jason wrote Things I've found out about the CLI/Shell from KS 1.3 and 3.x

Under KS 3.x and later, the "CLI" resident can't be replaced via C:Resident with other segments.
L:Shell-Seg is not by any means a 'normal' program:

- Like DOS BCPL fs handlers, you have to set up the Shell's pr_GlobVec yourself, including installing its segments. Fun.

- Unlike CLI applications, A0 MUST be NULL. A5/A6 are BCPL_jsr and BCPL_rts.

- It expects me->pr_CLI to be BNULL, and sets up its own CLI structure

Like DOS Handlers, it expects its startup packet in D1, and uses that to determine what CliInit* routine to call.

If D1 == 0, it uses the BCPL_cliInit at GlobVec offset 0x214 (which should probably map to DOS/CliInitNewshell or something)
If D1 != 0, it uses dp_Type (HAH!) as the BCPL function to call to call to set up the pr_CLI structure, and D1 is passed to it.

/* Return codes from the DOS/CliInit*() family
*/

#define FNF_VALIDFLAGS  (1 << 31)      /* Valid flags */
#define FNF_ASYNCSYSTEM (1 <<  3)      /* Async System() call */
#define FNF_SYSTEM      (1 <<  2)      /* If this a System() call */
#define FNF_USERINPUT  (1 <<  1)      /* User provided input stream */
#define FNF_RUNOUTPUT  (1 <<  0)      /* C:Run provided output stream */

/* Shell startup packets.
*
* In truth, only dp_Res1 and dp_Res2 are 'public' - the rest of
* the arguments here are private, and are decoded by the
* DOS/CliInit*() routines.
*
* ---- CliInitNewcli() decoded
*
* NewCli/NewShell:
*
*  dp_Type = 1
*  dp_Res1 = 1
*  dp_Res2 = 0
*  dp_Arg1 = BPTR Lock of directory (shell must close)
*  dp_Arg2 = BPTR to StandardInput
*  dp_Arg3 = BPTR to StandardOuput
*  dp_Arg4 = BPTR to CurrentInput
*
*  dp_Arg5..dp_Arg7 are unused, and have junk data
*
* ---- CliInitRun() decoded
*
* L:Shell-Seg, Run:
*  NOTE: KS 1.3: bfunc is a BCPL CliInit function
*  NOTE: L:Shell-Seg is passed a NULL packet for the Boot Shell,
*          and uses BCPL Function (APTR)(me->pr_GlobVec + 0x214)
*          as the CLIInit() routine to call.
*  dp_Type = bfunc
*  dp_Res1 = 0
*  dp_Res2 = 0
*  dp_Arg1 = BPTR to the old CommandLineInterface
*  dp_Arg2 = BPTR to StandardInput
*  dp_Arg3 = BPTR to StandardOuput
*  dp_Arg4 = BPTR to CurrentInput
*  dp_Arg5 = BPTR to Lock of directory (shell must close)
*  dp_Arg6 = 0
*
*  dp_Arg7 is unused, and has junk data
*
* Execute: (mostly guessed, may change)
*  dp_Type = -1
*  dp_Res1 = 0
*  dp_Res2 = 0
*  dp_Arg1 = BPTR to the old CommandLineInterface
*  dp_Arg2 = BPTR to StandardInput
*  dp_Arg3 = BPTR to StandardOuput
*  dp_Arg4 = BPTR to CurrentInput
*  dp_Arg5 = BPTR to Lock of directory (shell must close)
*  dp_Arg6 = 0
*
*  dp_Arg7 is unused, and has junk data
*
* System (SYS_Async == FALSE)
*  dp_Type = -2
*  dp_Res1 = 0
*  dp_Res2 = 0
*  dp_Arg1 = BPTR to the old CommandLineInterface
*  dp_Arg2 = BPTR to StandardInput
*  dp_Arg3 = BPTR to StandardOuput
*  dp_Arg4 = BPTR to CurrentInput
*  dp_Arg5 = BPTR to Lock of directory (shell must close)
*  dp_Arg6 = 1
*
*  dp_Arg7 is unused, and has junk data
*
* System (SYS_Asynch == TRUE):
*  dp_Type = -3
*  dp_Res1 = 0
*  dp_Res2 = 0
*  dp_Arg1 = BPTR to the old CommandLineInterface
*  dp_Arg2 = BPTR to StandardInput
*  dp_Arg3 = BPTR to StandardOuput
*  dp_Arg4 = BPTR to CurrentInput
*  dp_Arg5 = BPTR to Lock of directory (shell must close)
*  dp_Arg6 = 1
  */

#define CLIINIT_NEWCLI  1
#define CLIINIT_RUN      0
#define CLIINIT_EXECUTE  -1
#define CLIINIT_SYSTEM  -2
#define CLIINIT_ASYSTEM  -3

Wed, 15 August: Jason wrote I was surprised. As of today, AmigaOS 3.9 mostly works out-of-the-box so long as you remove/rename SYS:Libs/workbench.library - there seems to be some incompatibility with AROS's build-in icon.library. Some math libraries were missing from the AROS ROM, they should be in tomorrow's build (fixes the 'missing resource.library' popup).

Fri, 14 October: Jason wrote that Special aros m68k AmiWest package produced and sent.

2012

Wed, 14 March: Jason added rescale icons to match the display resolution, it the icon supports it. If an icon's MutalExclude bit 31 is set, treat the lower 16 bits as X and Y Amiga Tick resolutions, and rescale the icon to the display's resolution. Fixes the 'icons are too large' on small screens issue.

Fri, 16 March: Toni added support for non-MEMF_KICK fast ram boards (Mainly Blizzard A1200 accelerators). Most of the rom image loads to fast RAM now. Replaced with ForceCHIP that forces all modules to chip RAM. Mainly for debugging. Only kernel.resource, exec.library, expansion.library and diag init modules require MEMF_LOCAL RAM (RAM that never disappears during reset), in worst case it means Chip RAM. (Requires only about 80k, will become smaller in future). ForceFAST option forces complete ROM image to fast RAM, even if RAM type is not MEMF_LOCAL. (A3000/A4000 mainboard fast is most common MEMF_LOCAL Fast RAM). This only works with some non-autoconfig RAM expansions, one example is Blizzard 1260 Fast RAM.

Tues 21 August. Jason wrote was working on the rellib support for 'normal' libraries that is ROMable.

For my next major m68k change, all normal libraries (except exec.library, of course) will have a rellib SysBase. In theory, the only time 0x00000004 will need to be read will be when a new m68k task starts (since, for AOS compatibility, new m68k tasks can't assume that SysBase is passed in A6 on CallEntry())

I'm working on a 512K AROS ROM image, that autoloads the 'missing' portions from the boot media. One feature I'd like to have is autoloading of the *.hidd drivers, in a similar fashion to how BindDrivers works. Any ideas? Or should I just extend BindDrivers to cover Amiga chip functions and PCI devices, and load them that way? BindDrivers already supports a probe mechanism. You'd only need to supply enough tooltype information to cause the load to occur, and if InitResident() fails (which would have the probe function in it), then the device is unloaded. For example, I would propose the following tooltype API extensions: (the existing 'PRODUCT' tooltype stays as it is)

PROBE=zorro:2206/31     <= Zorro, vendor 2206, product 31
PROBE=zorro:2206        <= Zorro, vendor 2206, any product

PROBE=USB:$1234/$abcd     <= USB, vendor 0x1234, product 0xabcd
PROBE=usbclass:3/1/1    <= Any USB endpoint, class 1, subclass 1,
protocol 1  (USB keyboard)

PROBE=pci:$10de/$040c     <= Nvidia G84M
PROBE=pci:$10de          <= Any NVidia device
PROBE=pciclass:3/20/3   <= Any EHCI device

PROBE=platform:ide/$170/15    <= secondary IDE device
PROBE=platform:ocs/0xdff000   <= OCS chipset at 0xdff000

The InitResident could probe via the Expansion/GetCurrentBinding() mechanism, or just blindly add the module (as is current practice with *.hidd devices). The ConfigDev->ExpansionRom field could be extended by adding 'OOP_Object *HiddPCI' and other fields to the 'er_' union, indicated by a Manufacturer code of 0xFFFF, and the subtype (PCI, USB, etc) by AROS-defined Product codes.

Sat, 19 October Jason at AmiWEST 2012

Thursday, 1 November 2012 Jason wrote So, does anyone have any objection to 'all BPTRs/BSTRs are just like AmigaOS/MorphOS'?

Undef 'AROS_FAST_BPTR' and 'AROS_FAST_BSTR' for all architectures
Verify all ISAs compile (linux-xxx and amiga-m68k)
Add comments to bptr.h indicating that the AROS_FAST_* macros are deprecated
If either are defined, a '#warning' is issued that AROS ABIv1 does not support AROS_FAST_BPTR/AROS_FAST_BSTR

Here's the Top Ten slowdowns:

>> Exec IPrefs - 42 seconds (why???)
>> Exec C:RexxMast- 24.18 seconds (probably library loading)
>> Exec AddDataTypes - 17 seconds (library loading)
>> Exec Copy ENVARC:... 10 seconds
>> Exec SetClock LOAD - 5 seconds
>> Exec Mount - 5 seconds
>> Exec List ENV:SYS/Packages .. - 5 seconds
>> Load boot/AROSBootstrap - 4 seconds
>> Load C:RexxMast - 2 seconds

2016

27 July 2016: attempts made to fix AHI support for the Apollo Core

2 August 2016: Sidewinder mness starts work on the SAGA superAGA graphics HIDD, other thing is to optimize an animation viewer application written in Assembly bounty for Apollo Core / Vampire boards

2017

May 2017

21:39 Changeset in AROS [54753] von NicJA If setpatch is present, run it. 
20:56 Changeset in AROS [54752] von neil Better MUI compatibility for Window class: - Return zero for current … 
19:33 Changeset in AROS [54751] von neil Better MUI compatibility: don't use MUIV_Window_TopEdge_Delta, which … 
16:10 Changeset in AROS [54750] von NicJA drop the copymem patching since it is handled in exec. 
13:29 Changeset in AROS [54749] von twilen ModelStringBuffer? was too small for Apollo, fix FPU strings if EC CPU … 
13:25 Changeset in AROS [54748] von twilen ADDR32 changed. 
04:04 Changeset in AROS [54747] von NicJA show the ec version of 030 
04:01 Changeset in AROS [54746] von NicJA Show the correct cache sizes for the apollo core. 
03:10 Changeset in AROS [54745] von NicJA fix the format template so that the cpu model is shown correctly. 
03:09 Changeset in AROS [54744] von NicJA remove some whitespace 02:33 Changeset in AROS [54743] von NicJA typo 
01:24 Changeset in AROS [54742] von NicJA check if the CPU has the Apollo 68080 addiw.l instruction. If it has, … 
01:19 Changeset in AROS [54741] von NicJA tidy formatting 
01:17 Changeset in AROS [54740] von NicJA bump the copyright notice. 
01:16 Changeset in AROS [54739] von NicJA # always default to 68000 # show the EC version of 020 and EC/LC … 
01:14 Changeset in AROS [54738] von NicJA use USER_INCLUDES 
00:24 Changeset in AROS [54737] von NicJA Add AttnFlags? for the Apollo'080, and MMU presence. Use the bit …

Results

Amiga Hardware

Attempt to run AROS on A1200 and other Amiga hardware
Only requirement is 1M or more MEMF_LOCAL fast RAM (RAM that does not disappear during reset) or 2M chip RAM (in this case upper 1M will be used by ROM if not redirected to FAST). MMU is not used or needed
Be able to give detailed logs and descriptions of the issue see previous sections

Model	Video	Audio	Glue	IDE / PCMCIA	SCSI	Opinion
A1000	OCS Daphne	Paula	Agnus 0.25MB chip RAM	n/a
A500	OCS Denise	Paula	Agnus 0.5MB chip RAM	n/a
A2000/B1500	OCS/ECS Denise	Paula	Agnus 0.5MB chip RAM	n/a
A500+	ECS Super Denise	Paula	Fat Agnus 1MB chip RAM	n/a
A3000	ECS Fat Denise	Paula	Super Agnus 1MB chip RAM	Fat Gary
A600	ECS Denise	Paula	Fat Agnus 1MB chip RAM	Gayle
A1200 Technical	AGA Lisa	Paula	Fatter Alice 2MB chip RAM	Gayle
A4000	AGA Lisa	Paula	Fatter Alice 2MB chip RAM
Amiga CD32	AGA Lisa	Paula	Fatter Alice 2MB chip RAM
Model	Graphics	Audio	Glue	IDE	SCSI	Opinion
DCE VIPER 520						untested
DCE VIPER 530						untested
CSA Derringer 030						untested
ICD AdSpeed						untested
GVP GVP-M A530						untested
ACT Apollo 620						untested
ACT Apollo 630						untested
DCE VIPER 630 (M-Tec T-630 / E-Matrix 630)						untested
ACA 630/25						untested
ACT Apollo 2030						untested
DKB Wildfire 68060						untested
Fusion Forty 040						untested
GVP 2620 020						untested
GVP G-Force 030/50						untested
GVP G-Force 040/33						untested
GVP TekMagic G-Force 68060 for A2000						untested
Progressive Peripherals Zeus 68040 for A2000						untested
Model	Graphics	Audio	Glue	IDE	SCSI	Opinion
MBX 1200z 4 & 8MB RAM						untested
A1207 4 & 8 MB RAM						untested
GVP30 MKIV 50Mhz 4MB RAM						untested
DCE VIPER 1230/28Mhz LC						untested
DCE VIPER 1230 MkIV 030 33/42Mhz 32MB RAM (CSA Magnum 1230?)						untested
Phase 5 Blizzard 1230-II						untested
Phase 5 Blizzard030 MKIII 50Mhz 32MB RAM						untested
Phase 5 Blizzard030 MKIV 50Mhz 32MB but untested 64MB RAM						Works - How long did you let it sit for? Also as soon as the machine resets get the softkick floppy out of the drive (the faster you can do this the better)!
Phase 5 Blizzard030 mkIV 50Mhz 68882 50 MHz 64MB						Works. Emergency floppy boots. Can't move icons in Workbook. AGA is extremely slow: Can see screen clearing line by line when resizing or opening windows or using menus (CPU does it all?). Boot menu is very fucked: Couldn't select what I wanted from the + options, as some A-J range keys didn't work and after a while all keys switched 50/60 Hz. Wanderer is completelly unusable on AGA. Octamed IV crashed after clicking on its banner screen in startup. Booted some games just fine.
ACT Apollo 1230 Mk-II						untested
ACT Apollo 1240 040						untested
Phase 5 DCE(reworked) Blizzard 1240 68040	AGA	Paula	Fatter Agnus 2MB chip RAM			untested
Phase 5 DCE(reworked) Blizzard 1260 68060 + 1230scsi	AGA	Paula	Fatter Agnus 2MB chip RAM		1230scsi works	Works
ACA 1230/28	AGA	Paula	Fatter Agnus 2MB chip RAM			untested
ACA 1230/56	AGA	Paula	Fatter Agnus 2MB chip RAM			Works
Model	Graphics	Audio	Glue	IDE	SCSI	Opinion
ACT Apollo 4060 060						untested
GVP-M 4060						untested
MacroSystems Warp Engine 040						untested
Model	Graphics	Audio	Glue	IDE	SCSI	Opinion
FastATA	-	-	-	-	-	Does not work. The ATA3.driver fails with the following message: "Cannot find A1200!". - The Allegro CDFS does not work either.
IDE fix '97						untested
IDE fix '99						untested
						untested
GVP Spectrum 110/24						untested
MacroSystems Retina Z2 Z3						untested
Phase 5 (DCE) Cybervision 64 3D						untested
VillageTronic PicassoIV RTG						untested
DCE G-Rex PCI						untested
Elbox Mediator LT						untested
Micronik A1200 PCI						untested
Model	Graphics	Audio	Glue	IDE	SCSI	Opinion
						untested
Blizzard PPC with 060						As of March 2012, not working but new ForceFAST option added but untested
Apollo CyberStrom CSPPC060 (A4k)	AGA	Paula	Fatter Agnus 2MB chip RAM		cyberscsi needs to be disabled	Working if PPC chip disabled
Model	Graphics	Audio	Glue	IDE	SCSI	Opinion
Minimig
Replay FPGA Arcade B0						boots Mon 6 June (Ezrec)
Macrosystem DraCo						untested
Natami						untested

now starting to test aros and in particular my build on real hardware again im beginning whats supposed to be a detailed supported hardware list.

a4000 rev. d (16mb onboard ram) - cs060/50 ppc (128mb ram) - mediator4000di - fastata4000 mk3 (bootcontroller) - full boot
a4000 rev. b (16mb onboard ram) - cs060/50 mk1 (no ram) (no scsi) - fastata4000 mk3 (bootcontroller) - full boot
a4000 rev. b (16mb onboard ram) - cs060/50 mk1 (no ram) (no scsi) - internal ide (bootcontroller) - no boot: timing issue
a1200 - apollo (?) 040 (16mb ram) - internal ide (bootcontroller) - foll boot (random crashes after setpatch disappeared after clean nightly install)

A1200 has a Blizzard '060/PPC accelerator and 64 MB ram along with a 4-way IDE splitter off which is a CF card plus optical CDRW and OS 3.1 rom. The A500 has a B5000 accelerator ('020 with 4 MB fast ram) along with the fat Agnes hack to give 1 MB chip ram, another I MB slow ram in the trapdoor and OS2 rom. It also has a 'dodgy' A570 CD drive off the side expansion slot ('dodgy' because some years ago it stopped being able to boot the machine from a CD).

The A1200 has never booted AROS 68k and there was the same result last night. I booted from the AROS boot floppy but after the reset the machine just died - no boot activity and a blank screen with a power cycle required to bring the machine back (to a normal AmigaOS boot). To be honest, that was no great surprise. More disappointing was the A500, which has booted AROS 68k in the past (but was too slow to be usable). It ran the boot disk fine, but then immediately on reboot threw up an 'illegal instruction' error. It was consistent on every reboot tried)

Old School Macs

Most Macs with a 68030, 68040 or better processor would be a viable target. A 68020 CPU with 68851 PMMU should work also. Older 68000-based Macs might be more problematical.

The best place to start would be to define a specific Mac 68k emulator to target, and use that as the development environment.

Then, write a Macintosh m68k bootloader that uses the Mac Toolbox A-Line instructions to load the AROS kernel into RAM, and pass control to that.

We may wish to retain the Mac Toolbox vectors and globals (from 0x100 to 0x1000) to use for screen drawing and device access - each Mac model has its own bizarre peculiarities, and the Toolbox would be a good way to eliminate the need for coding all that ourselves.

Would imagine that we could use a 'MacFloppy.device' and 'MacHd.device' that would simply be a shim over the Toolbox ROM calls.

 
Centris 610 (also Workgroup Server 60)
Centris 650
Centris 660av
Color Classic (also Performa 250)
Color Classic II (also Performa 275)
Classic II (also Performa 200)
II
IIci
IIcx
IIfx
IIsi
IIvi (also Performa 600)
IIvx
IIx
LC
LC II (also Performa 400, 405, 410, 430)
LC III (also Performa 450)
Performa 460 (also LC III+ and Performa 466, 467)
Performa 475 (also LC 475 and Performa 476)
Performa 520 (also LC 520)
Performa 550 (also LC 550 and Performa 560)
Performa 575 (also LC 575 and Performa 577, 578)
Performa 588 (also LC 580 and Performa 580)
Performa 600 (also Performa 600CD)
PowerBook 140
PowerBook 145 (also PowerBook 145B)
PowerBook 150
PowerBook 160
PowerBook 165
PowerBook 165c
PowerBook 170
PowerBook 180
PowerBook 180c
PowerBook 190 (also PowerBook 190cs)
PowerBook Duo 210
PowerBook Duo 230
PowerBook Duo 250
PowerBook Duo 270c
PowerBook Duo 280
PowerBook Duo 280c
PowerBook 520 (also PowerBook 520c, 540, 540c, 550c)
Quadra 605
Quadra 610
Quadra 630 (also LC 630 and Performa 630, 631, 635, 636, 637, 638, 640)
Quadra 650
Quadra 700
Quadra 800 (also Workgroup Server 80)
Quadra 840av
Quadra 900
Quadra 950 (also Workgroup Server 95)
SE/30
TV

m68k Hosted Environment Binaries

There is no hosted version so far but if anyone is interested...

What are the system requirements for hosted operation? i.e. memory model (does each process need a separate virtual memory space originating from 0?) All processes are in the same memory context. Can this also be the same memory context as the host OS? While FreeMiNT has memory protection, it has no virtual memory model (i.e. all free mint processes have the same memory context too). Yes, it can. The whole AROS runs in a single host OS process.

Do I need thread support in the host OS? (this is a very funny chapter in the FreeMiNT kernel...)

"ready/write capability to low memory (in particular, trap vectors and 0x00000000-0x00000007) m68k assumes that it can read a specific constant value (the location of the SysBase data structure) at address 4. All other low memory below 0x1000 should never be accessed."

No, you just need the host OS to be able to cause a timer exception (signal) to the AROS context, and the AROS scheduler will do all the process/task management for itself. I guess a timer interrupt would save me quite some processing time compared to the whole signal shebang, and I also get supervisor mode for free (which I suppose is good in this case, since the scheduler most likely needs it?). m68k software really reads SysBase from 4. You can either map this memory in order to make it readable, or catch host OS exception (trap, signal, whatever), and simulate this access. Look at PPC native kernels for an example, they also support it.

m68k assumes that it can read a specific constant value (the location of the SysBase data structure) at address 4. All other low memory below 0x1000 should never be accessed. Can it be sufficient to virtualize accesses to this area in user mode? Yes, sufficient and recommended! (denying writes to 0 catches lots of bugs!) The OS will do this for me already, since it's already protected.

What about writes to 0x4? I guess the kernel sets up this once - but I need to catch that too. Ideally it shouldn't even attempt to write to 0x4, but rather to the variable I plan to return on reads from 0x4.

Does AROS and the general AROS binary use something like supervisor mode? AROS kernel yes, AROS drivers sometimes, and AROS applications almost never. Maybe this is a stupid question, but... why do the switch to supervisor? On an Amiga, hardware registers aren't supervisor-protected, and all memory can be accessed in user mode. Is it for stuff like cache control etc? (on 030 this is achieved by accessing the CCR, which is privileged)

Does the kernel access 0x4 in Supervisor? The reason I ask is because that means I have to virtualize most of supervisor mode. Ideally I'd like to just virtualize accesses to 0x4 in user mode (Because that's an easy thing to do. Virtualizing supervisor is definitely possible too though, there's some useful code for that in Basilisk 2 (MacOS needs supervisor mode, but is executed in user mode on the Amiga)).

Yes, AROS m68k device drivers use interrupts. Hosted probably won't need to, since it should be providing its own device drivers. What kind of tools do I need? VBCC/VASM and GCC 2-4 is available. I would suggest using the gcc 4 as compiled by the arch/m68k-amiga/doc/build-toolchain.sh script. Is there any particular port that can serve as a starting point for this stuff? arch/all-hosted, arch/all-linux, arch/m68k-all, and arch/all-unix should be useful. Copy arch/all-linux to arch/all-mint, s/linux/mint/ in all the mmakefile.src under there, and start work from there. Real CPU interrupts, are, in fact, needed only for native ports. For hosted port you will probably need some equivalent, implementable in host OS. For example, in Windows-hosted port interrupts are WinAPI event objects (somewhat reminiscent to AROS signals). They are used to communicate with I/O threads. In UNIX-hosted interrupts are actually signals. SIGALRM is used as timer and SIGIO as host I/O interrupt. SIGUSR1 and SIGUSR2 are used for calling scheduler, because signals are the only way to get CPU context in UNIX.

In fact, currently i can form up only one mandatory requirement. There must be a possibility to interrupt a running host OS thread, get and modify its CPU context. That's all. Will there be context switches in Supervisor mode too (i.e. will I need to take care of the SSP too)? No. Scheduler (core_Schedule()) needs to be called only when you're exiting into user mode (i. e. leaving the last nesting level). It's a very bad idea on AROS too to have nested context switching.

The macros SC_ENABLE() and SC_DISABLE() (cpu_xxx.h). I'm not 100% how this is used; but I suspect it's to avoid different signal handlers from clashing with each other somehow? No. These macros are used to set signals (i. e. AROS interrupts) state on a task context to be dispatched. It's an equivalent for restoring "interrupt enable" flag on the CPU in native ports. There's no field in AROSCPUContext to save interrupts state, they are assumed to be in sync with task->IDNestCnt, for simplicity. Anyway, these macros use some variable in the signal context which I don't have right now. It's a signal mask of the interrupted process.

i.e. to prevent or delay other signals while handling the current one?). No. There's no such problem in UNIX. When a signal arrives, it automatically gets blocked until i leave its handler. It's a pretty good equivalent of native CPU interrupts. However, any signal (except traps) really disables all other interrupts. This is done in order to prevent nested context switching (and messed up scheduler state), in case if the second (nested) signal happens between entering first signal's handler and incrementing of PlatformData->kb_Supervisor.

Currently there are two different flavors of hosted AROS: Windows and UNIX. Linux, Darwin, etc, are all UNIXes, and differences are very minimal there.

UNIX-hosted kernel is built around signals. They are very good equivalents for CPU interrupts. There's SIGALRM used as system timer, and there are SIGUSR1 and SIGUSR2 used as syscalls (in points where a running task needs to give up CPU time). SIGIO is an equivalent of external hardware interrupt, it is signalled when a host OS file descriptor is ready for I/O. A special component, unixio.hidd, is responsible for de-multiplexing a single SIGIO on per-fd basis. Some signals (SIGILL, SIGSEGV, etc) are CPU traps.

Windows-hosted kernel is quite different. This port makes use of Windows threads. AROS consists of minimum of two threads. One thread runs user-mode code (tasks), another thread is a supervisor. A special measures are taken in order to sync them up, so that actually only one of them is running. Supervisor thread is looping in WaitForMultipleObjects() call, where waitable objects are AROS interrupts. The first of them is a periodic timer, others are I/O interrupts from more Windows threads, contained in drivers.

When an interrupt happens (object is signalled), supervisor thread halts user thread, gets its CPU context, executes interrupt handlers, then resumes it. There is no mechanism similar to SIGALRM in UNIX, so a separate thread is needed to simulate it. I/O is also done via separate Windows threads. WinAPI is mostly synchronous by nature, especially GUI handling, where you have to sit in message loop. Every driver contains an associated .dll, which starts up own thread. Every thread can create own waitable event object, thus creating new interrupts. AROS code communicates to I/O threads in a way similar to a real hardware, it fills in some structure then triggers "go" event. I/O thread does its job and triggers its IRQ event, causing interrupt back to AROS side. For windows-hosted port, started with interrupts and task scheduling. After this task was solved, we already had a good model of how AROS can run inside Windows process.

The GUI on FreeMiNT is also synchronous and needs a message loop. My intention is to run away from this and make it a fullscreen application instead, because the alternative would be very very messy on this OS (since there are no non-expensive and useful threads. Is there any function to poll the event loop without blocking? X11 and SDL drivers use this approach. They just poll the loop 50 times per second using VBlank interrupt. Windows doesn't allow to poll the loop, this is why i had to deal with threads. In fact this appears to be slower and have larger latency than with polling.

Checked hd-rec under my aros68k compile in uae and it seems to be working properly. Loaded some project, didn't even play as there is no ahi units set up yet, but it seems to accept the genuine amiga 68k camd.library. There is 2 different versions of camd.library on aminet for the original m68k. camd.lha (2.0) works but camd40.lha was unstable as it crashes when pressing stop after some play of midi data. Recording of audio works in hd-rec under winuae amiga os3.9. The aros68k version of camd didn't seem currently to initialize properly, maybe some overseen endian bug.

Developer Compiler
Developer Exec
Developer HIDD
Developer Libraries