Contents

AROS is a choice/option of an open source, portable AmigaOS that is "source compatible" with OS3.1. Aros x86 apps would need to be recompiled for Aros 68k. However, system friendly 68K AmigaOS (AOS) binaries will run out of the box on Aros 68k. 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 and, in the future, possibly for Replay or Vampire/Apollo Core. You use as much of AROS as you need/require.

Most AROS programs are written in C using the Amiga API, some of them in C++. Every night these programs are compiled for a lot of CPUs: i386, AMD64, PPC, ARM and M68k.

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

aros IS amiga binary compatible ONLY in the 68k version, all the others are just source code compatible

"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"

aros68k is binary compatible with a range of amiga operating systems, kickstarts or workbenches, whatever you would call them from1.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 amiga 68k software on aros. its interchangeable. 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.

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.

if compiled for 68k it is from view of software like AmigaOS (TM) 3.1 with similar or identical API

Software does not need to be compiled for Aros, just that the libraries are compiled from Aros sources and not the original apps. 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 lived there only used by few people then Vampire/Apollo became reality and Aros offers many advantages there. At the moment limitations (f.e. in certain graphic areas) and bugs are removed then Aros will run on Vampire. It has many advantages compared to 3.1 and still only low hardware requirements, like AHI, USB-Support (Poseidon), Themeing, Network stack and much more

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.

To install aros on amiga you need a computer with enough ram. minimal amount is currently around 6mb afair, 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. i would recommend at least an 040. the experience may differ depending on what you will do with it, but generally aros is still very slow in comparison with the genuine os on a genuine amiga. this means executing binaries takes longer as they apparently need longer to load, even though once run are as fast as on the genuine system as long as not accessing operating system functions. the gui will generally be the most annoying part. running stuff from the shell instead - most rewarding ;).

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 seuence. remember you need to do it on aros68k/amiga side with an aros/amiga editor because the carriage return of windows text files doesnt correspond to the amiga format and scripts saved with windows editors are not executable on amiga. this isnt 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)

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.

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 this any disk swapping

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.

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

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 disk (hard hdf or floppy adf) is available.

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

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 existant (RAD)
No Overscan support
No PCMCIA ram support

Missing disk components:

C/cpu
ed
edit
magtape (I dont 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. eg.: 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 doesnt 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 unneccessary. 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 doesnt 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 (dont use it or care about it, but why leave it out when it is PD?)
prepcard
TOOLS/COMMODITIES/crossdos
mouseblanker (couldnt care less. But then it is not difficult to implement, isnt 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.

You can use Bray's Terminal, Termite, TeraTerm or RealTerm on Windows. They will work with Wine under Linux. CuteCom (qt based using dmesg to get device /dev/ttyS0 or /dev/ttyUSB0), picocom, minicom, or gtkterm on Linux. There are plenty of consoles and terminal emulators on the internet. Just download some of them to find the one which make you happy :-D

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

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.

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.

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

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.

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.

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

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)

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.

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.

If you need to open a library, you have to do it explicitly - you can't use the AROS autoopen 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).

(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 arhitecture, 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.

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.

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

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.

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)

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.

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.

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

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

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?

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:

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

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.

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.

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

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

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.

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

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)

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

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

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 extremelly 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.

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 requrired 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 useable). It ran the boot disk fine, but then immediately on reboot threw up an 'illegal instruction' error. It was consistent on every reboot tried)

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.

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.