NetBSD 1.0 on the Amiga

NetBSD's old logo

NetBSD’s old logo

So while I was on the path of running some ancient Linux on the UAE Amiga 3000 emulator but without any real luck.  So for the heck of it I figured I’d give NetBSD a whirl.  Much like Linux, the first platform other than the i386 to get some mainstream love.

While 4.4 BSD had been adding support for the m68k via the HP 9000-300 series based workstations, the Amiga was something that was sold retail, and could be put in the hands of hackers, rather than lab rats..

So yeah, NetBSD started to integrate Amiga patches as of NetBSD 0.9 as it says from the install notes:

This version is strictly for the kernel hackers among you, there’s no sense in `normal’ users trying to install it, possibly killing their other partitions, facing kernel panics and not knowing what to do. Please keep that in mind, if you feel like going on…

So maybe I’ll try to bring it back to life some time now that I can at least run NetBSD 1.0 .. Or maybe I’m getting ahead of myself.

Installing NetBSD 1.0 on the Amiga is somewhat straight forward, providing you are doing this from a new Amiga.. First just create a small-ish (15MB? lol) partition for AmigaDOS, and make sure it is bootable.  The work partition should be big enough to hold the compressed packages of NetBSD, I went with 60MB, while NetBSD 1.0 is a mere 15MB, well compressed of course.  After that you’ll want to create a ‘root’ partition of say 65MB, a 32MB swap partition and a giant /usr partition.  I created a 384MB virtual hard disk, so my remainder is 209MB which is more than enough.  From there you have to make sure that they are not set to auto mount, and edit the filesystem type to be the following:

root partition  : 0x4e425207
swap partition  : 0x4e425301
other partitions: 0x4e425507

Where the ‘other’ is of course the /usr partition.  Then with that in hand it is a simple matter of loading the boot loader from within AmigaDOS.  The one weird thing I found is that while this part goes all fine,  later on under NetBSD you can only mount AmigaDOS partitions read only, so how do you get a new kernel back onto the Amiga side?  I suppose a working network, and a 2nd machine.. Which would make sure, and of course NetBSD was built with the idea that everyone was collaborating over the internet so people would have net access.

So basically from within AmigaDOS you kick off the bootloader, kernel, and shove in a ‘root filesystem‘ diskette.  Next thing you know we are going through the install where it’ll pick up the partition tags, format the disk, and go ahead  and install..  Again another ‘trick’ is the partitioning scheme where NetBSD maps in the AmigaDOS partitions into NetBSD space.  My install looks like this form the NetBSD side:

NetBSD slices

NetBSD slices

It may not seem too obvious but back here the ‘a’ partition is the root, ‘d’ is the AmigaDOS operating system partition while ‘e’ is the work partition where our install was saved. From there it really is NetBSD and it just acts like any other NetBSD.  So of course I could prattle endlessly about this, how historic it is that NetBSD on the Amiga shows that the older hp300 port could not only be adapted to new platforms, but even eventually extended to support the 68040 processor which had a different and incompatible MMU.

For those of you are are impatient, you too can run NetBSD 1.0!  You can find a pre-installed image here. And just use the prior exe & config from the WinUAE beta that included MMU support.  Just alter the config so that it picks up the NetBSD disk.

NetBSD 1.0

NetBSD 1.0

The only catch I’ve seen so far is that trying to bring up the ethernet adapter hangs the system.  Sadly I don’t have any fix for this as of yet…. (edit: yes beta 4 and beyond work fine!)

le Retour des AMIX de l’impact Amiga..

Screen Shot 2013-01-21 at 5.31.43 PM

I thought it was cool, but a French Amiga fan site, linked me and sent a bunch of traffic,  Now I know what you are saying, I can’t read French! .. Well it is 2013, and google translate doesn’t do such a bad job of mangling les Francais..

Something like this.  I know, despite all the French I took in school, I’m lucky enough if I can get directions, or order food…

Sad day for Atari fans

ATARI US files for Chapter-11. Atari Consumer Electronics Division, the Jaguar & ST people pretty much died off in 1996, while the arcade people prospered on.. Or so it would seem.

The company has a valuation of just 25.4 MM Euros… But is it enough for 2600 legacy game lore?  I don’t think missle command nostalga is really worth that much.  The last big hit of theirs, was publishing rollercoaster tycoon..

Even looking through the highstreet today, anything Atari was in the bargin bin, the problem being that 30 year old games just don’t hold anyone’s interest for more than a few minutes today.. Their catalog is just.. old.

Oh well, it is chapter 11, which means ATARI gets time to pay creditors, take on new debt, and do a reorganization.  They may pull through this, although the world is a much different place than 1972, only time will tell.

Fun with QNX 4 Networking under VMware

(This is a guest post by Antoni Sawicki aka Tenox)

Over the years I have heard a lot of fairy tale stories about the awesome networking capabilities of QNX. There is this particular one about dragging windows across virtual desktop created out of multiple networked PCs. Unfortunately I’ve never got a chance to see it with my own eyes, so I finally decided to take things in to my own hands. I want to see it!

Interestingly QNX 4.25 released in 2011 includes VMware drivers, so the choice of virtualization engine was obvious. You can download QNX4 Product Suite 2011 here:

I have created a standard 32bit virtual machine in VMware and booted with QNX4CD.110614.iso. The installation is straight forward, it detects VMware network and graphics cards with no problem. The setup will actually ask you for a QNX Node ID, this will be needed later to create the network. You can simply install few VMs with different Node ID at this point. I wanted to use linked clones so I opted Node ID 1 and changed that later. I’ve enabled to run Photon at boot and went with TCPIP v5.

For simplicity I’m going to run the nodes as DHCP clients. To enable that after first boot:

  • edit /etc/config/bin/tcpip.1 and add /usr/ucb/dhcp.client en1 after ifconfig, before inetd,
    remove node$NODE from the ifconfig en1 line.
  • add /usr/ucb/hostname node$NODE.
  • edit /etc/config/sysinit.1 and remove extra parameters from line with /bin/Net.ether2100 so it only has the & sign.
  • reboot, check the nameserver in /etc/resolv.conf,


After that I was able to browse web with Voyager. The little OS is pretty fantastic, but as I’m interested in dragging windows, and the OS is covered nicely elsewhere I’m not going to go through all cool features of a single node. Let’s build a network!

I have shut down the virtual machine and created two linked clones. Powered them up. The two clones were able to ping each other over the virtual LAN. I’ve grabbed MAC addresses of both nodes and created a file /etc/config/netmap with entries for both nodes where one is marked with ID 1 and one with ID 2. The file should be identical on both nodes. You can use telnet or ftp to copy it across. Use netmap -f to reload the file.

In the next step I went to work #2 clone exclusively as I needed to change Node ID. Briefly following steps are required:

  • cp /.boot /.altboot
  • cd /boot
  • cp build/install.1 build/install.2
  • edit build/install.2 and change $ /boot/sys/Proc32 -l 1 to -l 2 – this is the Node ID.
  • make b=install.2
  • cp images/install.2 /.boot
  • cp /etc/config/sysinit.1 /etc/config/sysinit.2
  • cd /etc/config/bin
  • copy each of .1 files to .2 as above
  • shutdown -f

The configuration steps are documented in more details in this howto.

Also going back to the .iso install you can just specify the Node ID during setup. Much easier.

Type sin net to display list of nodes and their capabilities. If you issue sin info command you should see Node = 2. If you issue sin -n 1 info you should see Node 1 as the sin command was executed remotely on node 1.


You can list remote file systems like this: ls //<nodeid>/ for example: ls //2/. You can execute remote commands using on -n <nodeid> command, for instance on -n 2 who. Impressive, but still not what I wanted to see.

Let’s have look have look at a feature called Jump Gate. Sounds like Stargate and actually works pretty similar. Jump Gates, Ditto and other features are documented pretty well here.

Note the videos are best viewed in 1080p or “original” quality, full screen.

Impressive, but still not what I wanted to see…

This document sheds a little bit of light how you can extend desktop using phditto. After some experimentation, assuming my screen resolution is 1024×768 I figured this, on node 2 run: phditto -n 1 -x 1024 -w 1024 -h 768 -k. The parameter -x is the horizontal screen extension at offset x, –k is kiosk mode aka full screen. You can enter and exit from kiosk by pressing Ctrl+Alt+K. Here are the results:

(Note that these are two separate VMs talking to each other over the network)

Now this is exactly what I wanted to see! Show me another OS that can do that… Note that not all of the nodes have to be QNX OS. You can extend display by using Phwindows for Microsoft Windows or X11 as well!

Update: 4 node network!

Ancient Amiga Linux

So for some reason I though I would have luck with this super old m68k port of Linux running on UAE, now that it can run AMIX.  Sadly it cannot.

From what I can tell the 0.06 strain was the first to boot and do something, so this archive that includes 0.7 along with 0.08 & 0.09 is a good find.  While it may not seem that immediately obvious, the m68k port to the Atari ST & Commodore Amiga were the first community port of Linux to a different processor.  At the time Linus was working on a Dec Alpha port from what I recall.

For what it is worth.

For what it is worth.

Sourceforge’s project of the month: DOSBox!

Sourceforge has been running ‘project of the month’ for a while now, and  DOSBox won out!  It is the second time they have actually won.  For those of you living in a cave, DOSBox is a fantastic PC emulator geared at emulating not only early PC’s of the 1980’s and early 1990’s but also includes its own MS-DOS like operating system for running ancient video games.  It also has been ported to numerous platforms, including Java, Android, OS X, Linux and of course Win32.

DOSBox is also used by some big companies (steam, gog) for the continued sale of old MS-DOS games.  Who says old won’t sell?

Anyways there is an interview with the primary authors on the sourceforge page.




Back in 1990 Commodore took the Amiga in a new direction with it’s new Amiga 3000, by commissioning a port of A&T SYSV Unix to the Amiga. Taking advantage of the 3000’s 68030 CPU and 68881 Math coprocessor, along with its integrated SCSI controller. It certainly was the hallmark of typical UNIX machines of the time.

When originally announced there was some big interest in the platform by SUN, as their original SUN-1, SUN-2 & SUN-3 lines of workstations were all 68000 based machines, and being able to rebrand a mass produced Commodore model would have been a good thing, however the deal ultimately fell through.  The machine would have been the Amiga 3500, which later became the Amiga 3000T.

Another thing to keep in mind is that SUN’s SYSV (Solaris) was targeted to the SPARC processor, and it is unlikely that they would benefit from selling a 68030 based machine in 1991.

Typical of the time, AMIX installs from a set of boot floppies, and then pulls the rest of the installation from a tape drive, such as the A3070.

AMIX was released at a time when the UNIX world was rapidly moving to RISC processors, SUN had their SPARC, SGI had their MIPS, IBM and their POWER, Motorola built UNIX machines around their 88000 RISC processor, NeXT was also going to move to the 88000 until they gave up making their own hardware and shifted to a software company.  So who would want a then dated 68030 based machine when the industry had made their first steps into the world of RISC computing.

So how does it measure up?  Well it is SYSV, and if you’ve seen one, well honestly you’ve seen them all.  What is kind of neat is that AMIX includes OpenLook and a C compiler, which is kind of a rarity for the period.

Another flaw was that when the 68040 processor was released it’s MMU was incompatible with the 68030, and the VM subsystem for any UNIX would have to be rewritten.  While NetBSD can run on both the 68030 and 68040, AMIX never was updated, and so it can only run on 68030 based machines.

AMIX never did get any critical traction, and slipped into oblivion with the death of Commodore.

Up until recently it was impossible to run AMIX in any emulator, but there has been a lot of work on the ARANYM and Pervious emulators which included doing 68030 MMU support for the possibility of running early versions of NeXTSTEP. Toni Wilen was able to adapt their work onto WinUAE and it is not possible to run AMIX.!

Reading through this thread,  I was able to put together the needed bits, and get it running under CrossOver, by using the pre-configured settings for WinUAE, and replacing the exe with the new beta exe, the supplied hard disk image from and I was up and running in no time!  The only real change from the config was to change the SCSI ID of the hard disk from 0 to 6.

Screen Shot 2013-01-13 at 8.48.54 PM

AMIX starting up on WinUAE

The default password is wasp.  I thought it was kind of interesting that AMIX includes ‘dungeon’.  really cool!

Open Look on AMIX

Open Look on AMIX

I am unsure of how to enable the high resolution graphics, but sadly the Amiga known for its multimedia capabilities, AMIX with stock graphics runs in monochrome.  Such a major underwhelming thing.

Oh well, for anyone inclined you can now run AMIX, and enjoy another dead SYSV.

Floppy emulation on the Commodore Amiga

Well for some unknown reason the floppy drive in my Amiga just stopped working.  I managed to find a drive out of an Amiga 500, but it too didn’t work.. I really don’t know if it is the controller or if it is the drives.  And I’m hesitant to sink £100 into a machine that for all I know could have a dead controller.

So this means while I do have the Compact Flash working as a hard disk, I am unable to load an old favorite Captain Blood.  Maybe I am more of a sucker for the Jean-Michael Jarre resampled sound track ethnicolor. Or maybe there is just something redeeming about blowing up random planets.

Then while digging around DICE, I looked at its examples, and one of them was the exec_dev one, FMS a floppy emulator!  I built the example installed the driver, and using it resulted in a nice crash in both AmigaDOS 2.04 and 2.1 .. I had to wonder if this was more so geared to AmigaDOS 1.3 ..?  A bit of googling around and I found an updated version, fms_20.lha.  Installation is a little cumbersome as you have to manually copy in the device driver, and then setup a mountlist describing the devices in question, which really reminded me the “fun” of 4.3 BSD’s disktab.

Another weird thing is that AmigaDOS 2.1 has the FastFileSystem driver built in, so I had to remove those lines…

Using an ADF I found (since there is no way I can read the physical disk now..) I was able to use DMS to make an image on an emulator, copy it onto the flash, then re-DMS it out on the emulated floppy diskette.  Thankfully this game doesn’t use any weird custom filesystem so it was easy enough to mount the disk, and run the game from the emulated floppy.. Or at least launch it.  Trying to use it however resulted in the game just crashing.

Some more digging with a hex editor showed that the string “DF0:” was strewn all through the executable, so a few minutes, and I changed them all to “FF7” and now the game plays properly.

Captain Blood on my Amiga 600

Captain Blood on my Amiga 600

I wonder if it is possible to load the bootblock from one of these custom filesystems then use a virtual void pointer in DICE C, and execute the bootblock directly?  I’ll have to experiment.

DICE C Compiler for the Amiga

So on my last adventure through some disk corruption on my Amiga, the natural thing to do is find some kind of MD5 checksum program to then compare signatures of files being copies to ensure that they are being copied correctly.

While there were several great C compilers for the Amiga when it was a viable platform, the one left standing today is GCC.  Which is fine and all, but it is rather large, and unwieldy.  And won’t run on a computer with 2MB of RAM (In the off chance that I want to run it on the 600).  But that is when I found out that the source code ( has moved!)  to old DICE compiler is available!  DICE, was originally a public domain compiler then turned commercial then finally turned freeware.  For its time it was thought as a highly capable compiler as reviewed here. Also of note is that is was written by  Matt Dillon, who later went on to DragonFLY BSD fame.

So I thought I’d try something completely different.

So after extracting the 3.15 binary distribution (which also included cross compiling from linux/i386), and following the install notes I tried to build a md5 program that I had found into an AmigaDOS binary.  And it didn’t work.  It turns out that it is missing include files related to AmigaDOS.  And I was further unable to build DICE C from within DICE C.

So after a lot of searching, I came across this, a cut down “Mini DICE” that was bundled with Amiga Shopper, meaning it has the following limitations:

  • Only small library modules are included.
  • No Bitfields
  • No floating point
  • No pragmas
  • No register variables/arguments
  • The maximun executable program size is 40K
  • Each source file can only have up to 4 procedures


Wow that is.. limiting.  But it does have several of the needed include files, and a nice setup program to get going.  At first I tried doing a full-sale overlay of the ‘3.15 binary’ version but I broke something to do with REXX and how DICE links.  So instead I just overlaid the core compiler, namely dcc, dc1, dccp, das, dlink, dmake, fdtolib & fdtopragma.

I was then finally able to compile md5.  I went ahead and started to build some of the source, and so far using a combination of dmake & vmake I was able to rebuild das, dcc, dlink, dc1 and dccp.  I went ahead and created backups of my somewhat improved dice, and dice with source code.  Some programs build fine from the command line, others you need to invoke the visual build tool.

So how is the environment?  I tried to build Dungeon ( for the heck of it, but the visual makefile tool couldn’t handle a project with 33 files.  I suppose I could have made a library and gone through with some linking hell but that seemed like work.  Instead I just typed in all the C files from the command line, and compiled it that way.  Taking care of a warning and a few errors and I actually got a binary!

Dungeon on the Amiga

Dungeon on the Amiga

Even better, it runs!


Some fun with my “new” Amiga 600

Compact Flash in Amiga 600

Compact Flash in Amiga 600

So after getting this Amiga 600, I did get some games on diskette, but using any computer in 2013 without a hard disk is just unimaginable.  So a Compact Flash card & IDE adapter I had ordered had finally arrived!  Thankfully it was sold as an “Amiga formatted” Flash disk, being already partitioned as that can be a major ordeal through emulation on OS X.

Of the few disks I do have, I don’t have a full copy of the OS so I don’t have the “install” disk with the partitioning tool, so I kind of had to improvise.. So like I said, I got lucky as the Flash disk had been partitioned on an Amiga before it was sent to me.  Sadly the Amiga emulator FS-UAE doesn’t seem to honor the “IDE0” controller settings and won’t mount the flash directly.  So on a whim, I dd’d the Compact Flash and worked with that.

dd if=/dev/disk1 of=compactflash.hdf bs=512

dd if=compactflash.hdf of=/dev/disk1 bs=512

Surprisingly this worked pretty well.  I was able to format the disk image, and install the OS from disk images. Slapping the whole thing into the Amiga and it booted up, and all was well!  Or so it seemed.  I then wanted to play Frontier: Elite II, of which I was able to locate a copy of the “shareware” version, and use DMS to convert the ADF to a DMS file which I could then extract onto a physical disk on the Amiga.  So everything was going fine, but then today disaster struck.  It seems the floppy drive has either gone bad, or the disk I was using went bad.  Either way it is very maddening.

Frontier Box

Frontier Box

So the natural solution is either to replace the floppy drive, and try to score some decent floppy disks, and repeat the procedure.  The better solution, of course is to just run the game from the Compact Flash.  The good thing is that Frontier doesn’t have any disk based copy protection, instead it relies on some in game reading from the manual, and the shareware & various pirate versions have removed the checks.

After re-dding the image onto the flash I ran it, and it immediately crashed.  Even worse, I copied the game into the RAM disk, and it wouldn’t launch as the file was corrupted.  Clearly something was wrong or corrupting with the ROM version.  Now there is some conflicting information on Wikipedia regarding this, as 37.299 ROMS don’t include PCMCIA drivers, nor any IDE support.  37.300 has support for IDE & PCMCIA but Wikipedia lists it as only support disks up to 40MB.  I’m using a 128MB flash card, so at first I had figured this was the source of my problems regarding disk corruption.  Wiki lists another version 2 ROM, 37.350 which can apparently support disks & filesystems up to 4GB.  Of course there is also Kickstart v3.0 & 3.1 which run on the 68000’s.

After googling around it seems that 37.300 can work fine, and the ROM version, along with the version 2.1 of AmigaDOS should be enough to get this working.  That is when I found out about the MaxTransfer and Mask in HDToolBox.  Apparently the default values don’t work so well with things like PCMCIA disks, and Compact Flash drives.  Setting the MaxTransfer to 0x0FE00 and the Mask to 0x0FFFFFC did the trick!

HDToolBox in action

HDToolBox in action

Of course I found out the hard way that you have to press enter after entering the values, otherwise it won’t save your changes.

Wow what a convoluted process! But mass storage on the Amiga has always been a trying process even at the best of times.  Oh and here is it in action!

Next I’ll try to tackle WHDLoad, although I don’t think 2MB of ram will be enough.