Hyper, Hyper, Hyperion!

Setting up AmigaOS 3.1.4 on the A1200 using MapROM and the ACA1233n

Preliminary remark

I’ve decided to write and publish this piece in English rather than German for a couple of reasons. It’s kind of a tutorial that only addresses a relatively small and technically savvy audience. And I suspect there are way more Germans among this group who have a good command of the English language than the other way around. 😉

I ask all readers who may be disappointed by my decision for their understanding. And please forgive my mediocre English. Thank you!

An announcement with a boing

On September 30, 2018, Hyperion Entertainment, a Belgian-German software company, shook up the Amiga community or at least the part of it that still is in love with their m68k based machines from the good old Commodore days.

With the release of AmigaOS 3.1.4 they announced the first major upgrade for the (m68k) Amiga operating system in almost 18 years, when OS 3.9 hit the shelves in December 2000.

Why OS 3.1.4 when there was 3.9 already eighteen years ago, you may ask. The answer is because Hyperion does not hold the rights nor the sources to OS 3.9 – those lie with Haage&Partner. However, they do hold the rights to the original Amiga OS 3.1 and the team of programmers and contributors spent several years on what was planned as a bug-fix release but in the course of time grew the size of a major upgrade that „surpasses OS 3.9 in stability and robustness“ according to Hyperion.

The 3.1.4 release also comes with a couple of very nice and, one might add, long overdue features. Above all, at least to me, the support of large hard disks is to be mentioned – finally, the annoying „4GB barrier“ has been broken, meaning you can create partitions way larger than 4GB using the Amiga’s Fast File System (FFS) – no more fumbling around with other file systems such as PFS.

I also found the „off-screen dragging of windows“ feature very appealing, given the comparatively low screen resolutions and the limited amount of desktop space on your average Amiga system.

In my opinion, there’s more than enough in the package to justify a purchase. In addition, I am more than happy to support everyone who tries so hard to support the Amiga platform. So I decided to buy one license for my Amiga 1200, which I deemed perfectly fit for the new system.

Okay, let’s do this!

Heading to the digital store over at Hyperion’s website, you’ll notice there are five different AmigaOS 3.1.4 packages available, so choose carefully:

• Amiga 500/600/2000
• Amiga 1200
• Amiga 3000
• Amiga 4000 (Desktop)
• Amiga 4000 (Tower)

The reason for this is that each of these machines needs its own ROM to run OS 3.1.4. The Kickstart ROM is an essential part of every AmigaOS, containing most of the system-relevant libraries and modules.

Speaking of ROMs – Hyperion only provides Kickstart (KS) 3.1.4 in form of binary- and image files, so you can either burn your own KS 3.1.4 ROMs, provided you have an EPROM programmer and the necessary skills, or you can use the KS image file to either run AmigaOS 3.1.4 within an emulator such as WinUAE or to map the ROM file into the memory (Fast RAM) of your Amiga.

But alas! Your Amiga unfortunately can’t do this out of the box. The MapROM option is supported by only a handful of accelerator boards, such as the aged Blizzard 1230/40/60 series from Phase5 (defunct since 2000) or the much more recent ACA12xx series from Individual Computers.

For those of you who don’t have an accelerator board supporting MapROM and also can’t or don’t want to burn ROMs for themselves – there will be AmigaOS 3.1.4 bundles available including ROM chips in the near future. As far as I know, they will be sold through specialised retailers, not Hyperion.

Just for the sake of completeness I would also like to mention that it is possible to install OS 3.1.4 on systems with the old KS 3.1 in ROM, but only at the expense of RAM, which is a scarce and valuable resource on a stock Amiga. I wouldn’t recommend that approach.

For more than two years now I have an ACA1233n working in my A1200. She is equipped with a Motorola 68030 processor running at 40MHz and 128MB RAM – of which 1MB is reserved for Kickstart re-mapping. Why should I bother burning ROMs when I can use the MapROM feature of my ACA board, I figured.

The AmigaOS 3.1.4 package for the A1200 is a small download weighing only 3.5MB. Let’s take a look at the contents of the zip archive.

So by and large, what we have here is the classic AmigaOS floppy disk set we all know so well for more than thirty years – only in form of .adf disk image files, fairly obvious.

The only exception that immediately catches the eye of the experienced Amiga user is the image file labeled ModulesA1200_3.1.4.adf. Now this disk contains all the libraries, modules and devices you’d need when you choose to install the OS on a machine with the old Kickstart 3.1 – this would be the so called „disk based“ (as opposed to ROM based) installation. In other words: we won’t need this disk – with only one small but fine exception I’ll come back to later.

Now let’s have a look into the „ROMs“ directory.

The subfolder „to_burn“ contains, as its name suggests, the two binary files that are needed to burn both A1200 KS 3.1.4 ROMs into actual EPROMs to replace the old Kickstart ROMs with. The other subfolder called „unsplit_unswapped“ contains the kick.a1200.46.143 image file we can use in emulation and also to map into RAM using the MapROM feature of our accelerator board.

Setting up the Compact Flash HD

Okay, before we start the installation process I’d like to remind you that all roads lead to Rome and that my road might not necessarily be the best nor the path others prefer. But it’s the path I grew accustomed to during many, many Amiga system installations and that proved best for me regarding the possibilities of control and manipulation.

To sum it up briefly – I’m doing the complete installation of AmigaOS 3.1.4 onto my CompactFlash „hard disk“ from within WinUAE and only at the very end fire up the system on the real Amiga 1200. My PC and WinUAE act as a second Amiga so to speak, only that it’s way easier to handle disks and transfer files and programs to the system compared to the original hardware. By the way, it is highly recommended to always work with the latest version of WinUAE.

I’m using an 8GB SanDisk Ultra (30MB/s) CF as the target media for my OS 3.1.4 installation. In order to mount it, I found this really cheap Hama USB 2.0 Card Reader to be perfectly suited for the job.

Before we can use it as an Amiga hard disk, we’ll have to set the card up and erase all of its data and file system information. Most CompactFlash cards come preformatted out of the box, but with a file system the Amiga would not recognize. We’re using DiskPart to erase it, as it comes built into Windows. Just type in „diskpart“ into the Windows search bar and right click on it to launch the tool as administrator.

diskpart.exe (German version, but you’ll get the picture)

Typing in „list disk“ will show all the storage media connected to our system – be very careful identifying the right one to erase, I really mean it!

„Select disk x“ selects the media we want to erase (in our case #2) and typing in „clean“ erases it without further warning nor ado! „Exit“ exits the tool. 😉

Now I assume that you have at least to a certain extent some experience in dealing with WinUAE, otherwise this tutorial would simply go beyond scope. The emulator should always be run as administrator and set up to match the original Amiga hardware, in which you want to eventually run the system on as close as possible.

Of course, it is particularly important to use the new ROM (KS 3.1.4) right from the start – after all, a ROM based installation is our goal. To make things easier for me, I’ve put a copy of kick.a1200.46.143 in my WinUAE ROMs folder and renamed it Kickstart_v3.1.4_rev_46.143_(2018)(Hyperion)(A1200).rom to match the nomenclature there.

Now we’re adding our CF hard drive to the system.

It should look very similar to the picture above – the prefix [UNK] is exactly what we expected because WinUAE wasn’t able to find a valid file system on the CF, awesome! We also want to make sure that Read/write is enabled by all means. Last but not least, let’s insert the OS 3.1.4 install disk in our internal disk drive – in this case of course the Install3_1_4.adf into WinUAE’s DF0 slot.

It takes a little while to load from disk, even within the emulation, but as soon as it’s finished we’re greeted by the all too familiar Amiga Workbench screen, only this time it says „Copyright (c) 2018 Hyperion Entertainment CVBA.“ in the menu bar. 2018, let that sink in for a while. 🙂

To prepare our CF card as an Amiga hard disk, we need to run HDToolBox from the Install disk that is still inserted into DF0. The tool is located in the HDTools folder of the disk.

But don’t be too quick launching it! Since we are working in an emulated environment, we first need to tell HDToolBox to use uaehf.device instead of scsi.device. To do this, click once on the HDToolBox icon and choose Information from the Icons menu. There, the corresponding entry can be found under Tool types:.

Replace scsi.device with uaehf.device and save.

You may notice one of the many improvements of AmigaOS 3.1.4 here – we no longer have to confirm each and every input by pressing the enter key, just clicking Save is enough! Now did I already mention some features were long overdue?! 😉

No we’re ready to run HDToolBox. After checking some addresses and units of several devices, the tool should find and show one (as yet unknown) hard drive.

The only option we’re left with to continue is Change Drive Type – click on it and in the following window, choose Define New. This is where the drive’s definitions and parmeters are determined. Luckily HDToolBox does this work for us automatically – all we have to do is to select Read Configuration followed by Continue et voilà!

8 Gigabyte! That’s 8000MB! Back in 1994, we were dreaming of 80MB hard disks.

Once again a premiere for 68k AmigaOS! For the first time ever, HDToolBox correctly recognizes the size of an 8 Gig hard disk. Well done, Hyperion, well done. 😉

It’s safe to confirm those definitions by clicking Ok twice and then Continue to return to the main menu of HDToolBox. Note that the status of the drive is now Changed. Let’s save the changes we just made by clicking (yeah, you guessed it) Save Changes to Drive before we continue partitioning our drive.

Make sure to rename your partition devices to DH0, DH1, [DHx] here – otherwise you’ll always have to refer to GDH0 and so on when using the shell later on. Also make your DH0 partition bootable (check).

Partition 1 (DH0, Bootable) – 1012MB

Partition 2 (DH1, Non Bootable) – 6598MB

This is how I chose to partition my hard disk, one bootable partition (DH0) for the OS with roughly 1GB of space (that’s more than enough for your average Amiga system, believe me) and a second, non bootable partition (DH1) for the rest (media files, games, demos etc.) which offers about 6.5GB of disk space.

A few good tips

At this point it is advisable to point out something fundamental. Though we’re going to set up our system to kick the new ROM (3.1.4) into RAM via MapROM, our machine will still boot from its built-in ROM (v3.1 in the case of my A1200) until MapROM, which loads from HD, steps onto the scene. This means that we have to live with a few restrictions regarding the file system that would not stand in our way if we had KS 3.1.4 in our built-in ROM.

For example, our boot partition (DH0) may still not be larger than 4GB because it would not be recognized by the built-in ROM. Every other partition benefits from the new Kickstart though and can therefore be larger.

Also, I strongly recommend leaving all other values in the partitioning window at their defaults. Changing the file system or selecting Long Names in the File System Characteristics window will lead to the same result as described above.

Based on my own experience I can also only recommend to leave the file system block size at 512 bytes. I have noticed that higher values lead to an error while mapping the ROM file into RAM causing the system to not boot at all.

After we have finished partitioning the hard disk, we once again confirm the changes by clicking Save Changes to Drive and exit HDToolBox – the Amiga then reboots from our install floppy disk.

As soon as the system has rebooted we can go on and format both of our new HD partitions (via pulldown menu Icons/Format disk…) – choose a volume name of your liking, resist the temptation to select Long File Names and go for Quick Format.

Installing AmigaOS 3.1.4

Now we finally come to the fun part. Head over to the Install directory of the floppy disk, choose a language and off we go. 🙂

Yes, we do! By all means!

The installation process is self-explanatory, even if you choose Expert User, which I would recommend to do because who really needs to have all languages, keyboard layouts or printer drivers?! Keep your system lean. 🙂

Every now and then the installer asks you for one of the floppies from the OS 3.1.4 floppy disk set, with the only exception of the Modules disk mentioned above – these are already in our ROM.

At the end of the installation process, the installer tells us that it detected a 32-bit CPU (in our case a 68030 of course) which might require specific libraries to be installed in the LIBS: directory of our newly installed system.

We’ll get to these right in the next chapter. In the meantime, click on Proceed and finish the installation. Finally, we eject the diskette out of our virtual DF0 drive and hit Reset in WinUAE’s control window (Properties).

Our 68030 has an MMU, so we should make use of it!

For the first time AmigaOS 3.1.4 now boots from our CF hard disk. In fact Workbench now loads so fast that you probably only saw the message in the AmigaDOS window during the boot process from the corner of your eye. But don’t worry, in the screenshot below you can read through the message at your leisure.

Sounds complicated? You would have preferred not to be able to read the message? Do not despair, I can assure you we will deal with all of this step by step in the following sections.

Ex factory the Amiga 1200 came equipped with a Motorola 68EC020 microprocessor running at 14MHz. The EC020 is a lower cost version of the 32-bit 68020, but its address bus is reduced to 24-bit and it can therefore only address a maximum of 16MB of memory.

In comparison, the ACA1233n accelerator sports a full blown 32-bit MC68030 processor, which was introduced in 1987 – three years after the MC68020. Apart from higher possible clock rates of up to 50MHz, the biggest significant difference is the presence of an integrated memory management unit (MMU) – which was a first for the 68000 series. Until then, external MMUs were only optionally provided for the m68k processors, but Commodore never used them for their Amiga computers – with the only exception of the A2620 expansion board for the Amiga 2000 series.

Nowadays it is impossible to imagine computer- and operating systems without an MMU, since it is not only responsible for virtual memory management but also for memory protection within the system. Without memory protection, an error in a single task or process would affect others or even cause the entire OS to crash. Multitasking operating systems would be a nightmare if there were no MMU.

However, the lack of an MMU did not stop Dale Luck, RJ Mical and Carl Sassenrath from developing a preemptive multitasking OS for their Amiga computer in 1984/85. The original Amiga was based on the MC68000 processor, the first of the series, introduced in 1979 and therefore had no hardware memory protection at all.

For years to come, it was simply way too expensive to provide a consumer oriented computer like the Amiga with an MMU. In fact, the first Commodore Amiga to feature one ex works did not arrive until 1989, in form of the A2500. As a result, AmigaOS itself still does not natively support an MMU today – i.e. there’s no known documented interface for it.

This does not mean, however, that the potential presence of an MMU in Amiga systems has not been exploited, quite the contrary. Very early on, brilliant minds started to develop tools and programs that make use of it – SetCPU by Dave Haynie or the Amiga Enforcer by Michael Sinz, just to name two out of many.

But the underlying problem remained – without a consistent MMU interface, these tools would remain at least partly incompatible with each other, rendering a stable system a matter of luck.

Another brillant software engineer, Thomas Richter, who is also part of the AmigaOS 3.1.4 developers group, devoted himself to this fundamental problem by setting about to create such an interface with the mmu.library towards the end of the nineties. And he is constantly developing the interface further. The latest version (46.16) at the time of writing this article was dated 6 October 2018.

Enough with theory – let’s get the MMU interface installed for our 68030. First we download the package to our PC – you can do so right here. Extract the .lha archive (WinRAR should do the job) to your computer’s hard drive and press F12 in WinUAE to open the Properties window. There, go to CD & Hard drives and click Add Directory or Archive…

Enter the path to your MMULib directory you just extracted by clicking Select Directory and assign DH2 as Device name and Volume label – and make sure to deselect (!) Bootable. Then hit OK and Reset your Amiga.

If everything went smoothly during the reboot, there should now be a DH2 drive icon on the Workbench. Double click on it and you should find the MMULib installation package there.

As you can imagine, the installation script is located in the Install subfolder. Double click on the Install icon to launch it.

I’m not trying to pretend to be some kind of proven Amiga expert. On the contrary, I consider myself to be a normal user with a small Commodore related blog. 😉 There are so many people out there who know the machine a hundred times better than me and who thankfully share their knowledge with others.

One of them, who goes under the username of ‚Rotzloeffel‘ in the a1k.org community has written a very detailed tutorial about what is behind the mmu.library and how to install the software package correctly so that it works the way it should.

Unfortunately I cannot link to it here, because it is only accessible for registered users. Besides, it’s written in German anyway.

I will not adorn myself with borrowed plumes by reproducing his tutorial here. Rather, I will only share with you the conclusions I have drawn for myself from Rotzloeffels work. In any case a big „thank you“ is due, Sir. 🙂

Immediately after launching the installation script, we have an important selection to make. Please choose Expert User as installation mode – otherwise we will miss out on some important tools and / or patches.

Proceed with the installation and of course choose Install for Real – after all that’s what we’re here for.

Make sure to have MuLib installed to the SYS: drawer (default) and let it backup the files it is going to alter into the SYS:OLD directory – better be safe than sorry.

In the next step, leave the source directory as is („/“) and confirm MultiView to bring up the ReadMe First! – feel free to browse through it before you proceed, there’s a lot of stuff worth reading in it. When you’re ready to continue with the installation, simply close the window by clicking on the icon in the upper left corner.

The path to the startup-sequence should already be correct (SYS:S) so it’s safe to just click Proceed. The installer then asks us if there is a Phase 5 accelerator board in our Amiga – you know, one of those Blizzard boards mentioned above. So if you really have such a card in your Amiga instead of the ACA1233n, you should of course answer the question with Yes. All other users continue by choosing „No“.

Now we’re asked whether we have an older ACA board in our Amiga. Unfortunately, I cannot say with certainty which cards from Individual Computers are exactly meant by „older“ – I can however say that the ACA1233n certainly doesn’t belong in that category, as it’s still one of the latest ACA accelerators available.

Of course we want to Install the mmu.library – again that’s why we’re here for – and SYS:LIBS is exactly the place it should be installed to.

The SetPatch command should be located in SYS:C (default) – you can scroll down the list to make sure. And yes, we would want to have the installer update SetPatch. Again, choose SYS:LIBS as the target directory for the 680×0.library and be prepared NOT TO PANIC at the sight of the following dialogue box.

Everything is all right and correct! The SetPatch version in AmigaOS 3.1.4 is already up to date and therefore does not need to get patched. The only small problem here is that the installer unfortunately does not copy the processor libraries to SYS:LIBS. But we’ll do that manually as soon as we have finished the installation. So just click Proceed here.

We continue with the installation process by choosing to build the MMU-Configuration file now and then install it to the default drawer (SYS:PREFS/ENV-Archive).

BPPCFix is only required if you have a Blizzard PPC board, so we just click No. The same applies to the BVisionPPC monitor driver – this is only needed for CybervisionPPC or BVisionPPC graphic boards.

In the next step, we select the MuTools that we want to install on our system. To start with, I chose to only install four of the thirteen tools available from the list.

Let’s just call it a user-oriented configuration from which almost every Amiga benefits. The other tools are more suitable for developers, for debugging purposes or other special cases, which I will not go into further here.

MuFastROM copies our ROM all the way to the very end of the existing FastRAM and prevents it from being overwritten at the same time. This also works with a ROM that has already been mirrored into memory by another program like ACAMapROM. Sounds vital, doesn’t it?! Indeed it is!

MuScan displays the configuration of the MMU as well as the memory map in the shell on request. Most users can’t do much with it directly, but if you are looking for help, for example in a forum, then this information is very helpful.

MuLockLib prevents the mmu.library from being deleted or overwritten in memory and therefore is an essential tool.

MuProtectModules protects individual Kickstart modules that are
subsequently loaded by LoadModule (we’ll get to that later) from being overwritten, even during a reset, which contributes greatly to a stable system.

Now we have to decide in which directory we want to install MuTools. Personally, I like it tidy and therefore create my own „MuTools“ subfolder in the Tools directory.

The same applies to the documentation, which I also have installed in a separate subfolder.

After we have defined the installation path, the installer asks us if we want to load MuFastROM, MuProtectModules and MuLockLib when booting the Amiga. We should acknowledge these questions by choosing Yes.

The installation script also asks whether it should install the so called FastIEEE speedup. Now this only applies to 68040 and 68060 based systems and it is also very likely that the affected libraries in OS 3.1.4 have already been equipped with the corresponding functionalities anyway. So we choose No here.

We’re then asked if we’d like to Replace popular MMU hacks by the MuTools. We should definitely choose Yes here.

At the end of the whole process, the installer wants to create a user-startup file. Choosing the default path is the right thing to do at this point.

Finalizing the installation takes a little time, so just be patient. After a while, the installer tells us that the installation is 100% complete.

Unfortunately, that’s not the whole truth. Remember the CPU libraries mentioned above that the installer failed to copy to our hard drive?! We’re going to copy those over manually right now.

To do this, we need to open an AmigaShell window. You can either find the shell in the System drawer of your Workbench or launch it from the drop down menu via Workbench/Execute command…/’newshell‘.

First, let’s take a look inside our LIBS: directory and see what we can find there.

Next to various system libraries we can find the mmu.library which we have just installed. However, two CPU-related libraries and the memory.library, which provides the support of virtual memory for the AmigaOS environment, are still missing.

We find these libraries in the LIBS: directory of our MMULib package (DH2) – so let’s head right over there and have a look inside.

Just as we expected, we find the mentioned libraries there. We can now copy one by one into our system’s LIBS: directory using the following syntax: copy xxx.xxx libs:xxx.xxx clone. The screenshot shows it again exactly.

Using the clone argument at the end of each command line is particularly important, because then not only the respective file is copied but also its protection bits, which allow for Read, Write, Execute, Delete and some other permissions. Without the appropriate permissions, the system cannot fully access the libraries. In other words, simply copying the libraries over by drag and drop does not lead to the desired result.

Now let’s check if the copy process was successful and have a look into our LIBS: directory on DH0.

Look at this, they’re all there, beautiful! Let’s close the shell window now and restart the Amiga with a reset.

You will notice that the Workbench now boots faster and the message no longer appears. More importantly though, our Amiga system is now perfectly tuned to the 68030 processor and its integrated MMU.

Now we have to create the prerequisites to be able to mirror the OS 3.1.4 ROM file into the FastRAM of our ACA1233n accelerator board.

Installing the ACA1233n software package

Before we can install the software for our ACA1233n, we have to download it first, of course. To do so, head over to the download section of the ACA1233n wiki page.

As of writing this article, the software is still in beta state, but that’s not gonna be a problem. The tool we’re going to need (ACAMapROM) has been running stable and without problems on my system for quite a long time now.

We proceed in the same way as with the MMULib package, i.e. we unpack the .lha archive to our hard disk and integrate the folder as DH2 into our emulated Amiga environment. Once this is done, we reboot the system once again. The content of our DH2 drive should now look like this.

Double click the Install icon and select Install for Real in the following dialog box. Since we’re going to install the software package on a newly installed AmigaOS, we can simply acknowledge the note in the following dialog box with Proceed.

In the next step the installation script is going to copy the heart of the ACA1233n software package into the LIBS: folder of our system – the ACA1233n.library. Confirm this by choosing Proceed with Copy.

After this is done, we are asked for the desired installation path for the ACA1233n tools. The choice is of course up to you – I have decided, analog to the MuTools, to go for System(DH0):Tools/ACA1233n.

The following note we can confirm again with Proceed and then we are presented with a selection of tools to install.

Although we’re only going to need ACAMapROM, I recommend to install all of the tools listed, because there are some very useful ones among them. For example, there’s a tool to display the current settings of the turbocard (ACAInfo) as well as one used to turn off the accelerator completely, thus handing over the Amiga to its original 68EC020 CPU (ACASwitchCPU).

You will find a detailed functional description of all tools in the ACATools.guide, which is displayed during installation later on and also copied to our hard drive.

After all of the tools have been installed, we have to define the path for the documentation files – as with the MuTools, I have decided to create a new subfolder for them.

The following dialog box explains why we chose to install the ACA1233n software after the MuTools and not vice versa.

A single additional line now gets added to the very end of the mmu-configuration file in PREFS/ENV-ARCHIVE, which was just created during the installation of the MMULib package.

After this step, the installation script reminds us that we should add ACAMapROM as first command to our startup-sequence. Don’t worry, we’ll get there soon enough. 😉

If you like, you may now read through the ACATools guide or simply close it to finish the installation.

Setting up ACAMapROM to kickstart 3.1.4

Now we get to the exciting part and closer to the first test run on the real Amiga 1200.

In order to copy the Kickstart 3.1.4 ROM into the memory of the Amiga, ACAMapROM of course needs access to the ROM file itself, so we have to put it on the hard drive first.

As usual, mount the folder containing the KS 3.1.4 ROM file (kick.a1200.46.143) as drive DH2 in WinUAE and reboot the Amiga afterwards.

Don’t be surprised if you can’t see the file in the DH2 drawer at first after the reboot. You will have to select Show All files from the Window pull down menu to be able to view the file.

Basically, it doesn’t matter where we put the Kickstart file on the hard disk, as long as we remember the path afterwards. I personally prefer to store the file in a Kickstarts subfolder of the Devs directory as this is also exactly the folder where the kickstart images for WHDLoad are stored.

But since WHDLoad is not installed on our system and the folder therefore does not exist yet, we will have to create it now. To do this, open the Devs drawer on the Workbench and choose New drawer from the Window pull down menu.

In the following dialog box simply name the folder Kickstarts, press Enter and that’s it.

Next, open up a new shell window, switch to DH2 where the Kickstart ROM file is located and copy it into our newly created Kickstarts folder using the following syntax.

copy kick.a1200.46.143 to dh0:devs/kickstarts/kick.a1200.46.143 clone

We can immediately make sure the copy operation was successful by checking the Kickstarts folder on the Workbench. Don’t forget to also use Show All files on the new drawer.

Now close the shell and all other windows and then select Execute Command… from the Workbench pull down menu. Now enter the following in the command line.

ed s:startup-sequence

This will launch the editor in which we can now edit the startup-sequence so that ACAMapROM can work its magic.

Remember the kindly reminder of the ACATools installer to add ACAMapROM as the first command of the startup-sequence?! Let’s do it the favour and insert the following line there.

SYS:Tools/ACA1233n/ACAMapROM/ACAMapROM Devs:Kickstarts/kick.a1200.46.143

The screenshot below illustrates where exactly this line should be inserted.

Of course you would have to change the paths for ACAMapROM and the Kickstart ROM file, should you have copied them elsewhere before.

Now hold down the right mouse button to bring up the editor’s pulldown menu and close it by choosing Save & Exit from the Project menu – and we’ve practically completed the setup!

A reboot under WinUAE now leads to an error message by ACAMapROM.

This is because WinUAE may emulate the Amiga 1200 almost perfectly, but not the ACA1233n accelerator board and all its fancy features.

Despite the error, the system continues to boot into Workbench – as long as you are using Kickstart ROM 3.1.4 in WinUAE – which is very convenient because you can continue working with the hard disk in the emulator without having to edit the startup-sequence.

The Real Thing

Now, of course, we’re dying to learn if our carefully set up system works on the real Amiga 1200 with the ACA1233n.

For this purpose I created a small video showing the boot process with our AmigaOS 3.1.4 system we just created. You can see the CompactFlash hard disk to the left of the Amiga 1200 – the CF adapter card also features a small LED signalling disk access.

Admittedly, the video is not particularly spectacular, but it serves its purpose of showing the booting process quite well.

When switching the Amiga 1200 on (you can clearly hear the clicking noise) the computer initially boots from its built-in OS 3.1 ROM.

After almost exactly five seconds it starts processing the startup-sequence – you can tell by the very short colorful flickering on the screen. This indicates ACAMapROM writing the OS 3.1.4 ROM file into the memory of the accelerator board.

As soon as this is done, ACAMapROM resets the Amiga and after another few seconds, it begins to process the startup-sequence once again – only this time ACAMapROM informs us that it’s already active, which of course is correct.

A couple of seconds later the Workbench appears on the screen and – lo and behold – we have AmigaOS 3.1.4 running on our A1200. \o/

Wait a minute, didn’t you mention off-screen dragging of windows?!?

You really don’t miss a thing, do you?! 😉

Don’t worry, Hyperion didn’t embezzle that feature. But according to the readme, the corresponding reworked library unfortunately is incompatible with the CyberGraphics system so they couldn’t put it in the installation by default.

Instead, they decided to include the corresponding file (intuition-v45.library) on the Modules disk and leave the installation to the users.

Thankfully, the Modules disk also contains the LoadModule utility, which is needed to integrate the new library into the system, so you don’t have to download it from Aminet.

So let’s plug our CF hard disk into the card reader once again and boot the system in WinUAE. As soon as the Workbench is loaded, insert the .adf of the Modules disk (ModulesA1200_3.1.4) and open a new shell window afterwards. Enter the following commands to copy the two files one after the other.

copy df0:c/LoadModule to c:LoadModule clone
copy df0:Libs/intuition-v45.library to Libs:intuition.library clone

Note the different name of the target file (intuition.library) on the second command line, that’s important!

Now close the shell and also eject the floppy disk at this point. Finally, launch the editor exactly as before to edit the startup-sequence and delete the lines colored in red from the file.

Replace the block you’ve just deleted with the following single line.

C:LoadModule Libs:intuition.library

After editing, the header of our startup-sequence should look like this.

Save the changes on exiting the editor.

From now on the system will be restarted twice during the boot process – once after the Kickstart ROM has been copied into memory and the second time after LoadModule has replaced the intuition.library in the ROM.

This of course extends the boot process by a few seconds, but it’s really worth the wait. Being able to move windows outside of the visible screen to gain more space on the Workbench is a priceless feature you wouldn’t want to miss anymore. Oh, and it also was long overdue. 😉

Addendum

If you are looking for an elegant solution to install AmigaOS 3.1.4 on a real Amiga 1200 (and the ACA1233n) without taking the detour via WinUAE, I recommend watching the video by Bill Winters, known to many as AmigaBill from TheGuruMeditation. These guys are awesome and truly commited to all things Amiga – it’s well worth checking out their website and YouTube channel.