NOTE from Zik - the files you want for KludgeMach are KludgeMach-x.xxx.tar.Z (the normal distribution) and SIM.lha (if you want the special kernel debugger). This is seriously hackerware, be warned! The rest from Bryan: -------------------------------------------------------------------------- Requirements ~~~~~~~~~~~~ I'm running on a 25MHz A3000 with 2.04 in RAM with four megs of fast memory, two of chip. This version of Mach ('KludgeMach') should work with any amount of fast memory as long as you have some. (The microkernel _only_ knows about the fast memory; chip memory is not paged or even kept track of by it.) Mach probably requires an A3000, but may work with other 68030-based Amigas. (If it doesn't work for you the first time, try turning Enforcer on.) It probably works with any Kickstart version. To work with KludgeMach, you'll need Markus Wild's GCC 2.1 port (later versions will probably also work), plus some other tools which I've included in the 'bin' directory. I'm using ixemul.library version 39.26; you will probably need that version or later. Installation ~~~~~~~~~~~~ OK, hold tight, this is rather messy... First, find a partition with plenty of space, and un-tar The File into it. Be sure you use GNU tar (which should be available the same place you get the archive), or a newer version built with ixemlib. It will create a directory called 'mk74'. Then do these assigns, making them permanent if you wish (in your startup-sequence or whatever): Assign Mach: mk74 Assign MK: Mach:kernel Now add the 'bin' directory to your path, or otherwise make the programs in it accessible. Now create a bunch of directory links with the following commands: ln -d mk:mach mach:include/mach ln -d mk:amiga/include mach:include/machine ln -d mk:amiga/include mk:mach/machine ln -d mk:device mach:user/libmach/device ln -d mk:mach mach:user/libmach/mach ln -d mk:amiga/include mach:user/threads/machine You should now have an environment in which you can build KludgeMach. To do so, go into mk: and type 'dmake'. (Other makes will probably work too.) To run it, type 'mach:mach' (or '/mach' from the MK: directory). If all goes well, a green-on-black machSIM screen should be displayed with the PC at $40000000, which is the virtual memory address where Mach is currently loaded. You can step through it to examine the boot process (though note that there are some places you _cannot_ step through, such as load_context - you must use a breakpoint afterwards). To quickly see if Mach will successfully bootstrap itself, type 'b_idle_thread_continue' and then . If you again get the machSIM display with the PC at _idle_thread_continue, then it's gotten through the whole kernel bootstrap sequence - if you continue to step through this function, you will notice it goes into an infinite loop waiting for something to do. (Also take a look at the console output at this point, as explained below.) I have managed to build libmach, but it is completely untested. (Nothing to test it with...) I had to coax MIG through most of the C-file generation by hand, but as it's set up you should be able to 'dmake' in the user/libmach directory and get a 'libmach.a', a 'libmach_sa.a', and a 'crt0.o'. I have included pre-made versions of these in the 'lib' directory. The situation is the same with libthreads. Working with KludgeMach ~~~~~~~~~~~~~~~~~~~~~~~ First, you'll need to learn how to use SIM, if you don't already know how. I've included the manual in this directory; like the author says, "read it or die." The version of SIM included, which I have dubbed "machSIM", is a version specially modified by me to work with Mach. As such, the manual is not completely accurate, and some features may have been broken by my changes. However, all of the necessary functions seem to work. Note that SIM is normally a Shareware product, and does not come with source code, but I have received special permission from the author to distribute machSIM in binary form for the purpose of getting Mach going. To reboot back to AmigaDOS from , run the code at absolute address 0. (In SIM type 'A0' .) Rebooting by the keyboard doesn't work for some reason. To see the console output at any time, look at the buffer starting at the symbol '_console_buf' (i.e. 'm_console_buf' in SIM). I have 'illegal' instructions sprinkled around most of the Amiga code that I haven't tested, so if SIM traps because of one of those, you can NOP it out and see what happens. The interrupt vector table is set up at 0 for SIM's benefit. (SIM 1.x has never been fully adapted to 68010+ processors; the authors is currently working on the "next-generation" SIM that will fully work on all processors.) Most of the interrupt vectors come pre-initialized to trap into SIM; you can see the exceptions in trap_init() in kernel/amiga/trap.c. However, the vector table is also mapped into kernel address space by pmap_bootstrap; this is where the VBR actually points to. I currently have memory configured in a rather weird configuration for debugging purposes: $00000000-$0fffffff Transparently translated in supervisor mode $10000000-$3fffffff User address space $40000000-$ffffffff Kernel address space I haven't yet figured out completely how AST's and interrupt scheduling work, so I have the clock interrupt and such disabled. Thus, right now Mach is not preemptive. Otherwise it seems to work fine to the limited extent to which I've been able to test it. One small but important module, kernel/amiga/takeover.asm, requires a commercial 680x0 assembler (or a freely distributable assembler that I don't know about) to assemble. I'm using an as-yet-unreleased assembler, ProAsm, by Daniel Weber. To assemble this module with another assembler, you'll probably have to make some changes. In any case, you shouldn't need to reassemble this module unless you want to change the way KludgeMach is booted. Where do we go from here? ~~~~~~~~~~~~~~~~~~~~~~~~~ We'll need three main things before we have something workable: * A basic console device driver. A serial-based driver may be simplest and easiest to work with, if most of the people who will be doing the initial work have access to a second computer or a dumb terminal. That way we can debug with SIM locally while viewing your session on the remote terminal - quite a reversal of standard OS debugging procedure. :-) We'll need a regular graphical console driver. I've got some code to copy the topaz font out of ROM (in a system-friendly way), if anyone wants it. * SCSI device drivers: either specially written drivers to run under Mach, or a way to run standard Exec device drivers under Mach. The first, "brute-force" method is probably what we should start with, probably for the A3000's built-in SCSI chip first. But to support a large percentage of capable Amigas we may need a way to run Exec drivers eventually anyway. * An operating system. :-) Michael Saleeba may be able to get the BSD Single Server working, but since that requires a Unix source license it will probably not do most of us much good (including me). I'm looking into the possibility of porting the higher-level parts of 386bsd or Linux onto Mach. Any other ideas are more than welcome. Contact Addresses ~~~~~~~~~~~~~~~~~ You can contact me at the following addresses (in order of preference): bryanf@hpmcaa.mcm.hp.com bryan.ford@m.cc.utah.edu You can contact Stefan Walter, the author of SIM, at the following addresses: stefan@pegasus.ch swalter@avalon.physik.unizh.ch Note that any problems you find with machSIM are likely to be _my_ fault, not Stefan's, due to my hacking of his code to work with Mach. Also, unless you find something really seriously wrong with machSIM, please don't complain to either of us about it - machSIM is only a temporary hack, and we should be spending our time getting Mach going, not perfecting machSIM.