Dungeon on A/UX
I know it’s been a while since I’ve done one of these, but now that I’ve been playing with A/UX on Shoebill, I noticed that A/UX comes with a Fortran compiler!
So I downloaded dungeon, and took a few minutes, mostly making a GNU Makefile, and I was able to produce a working binary!
For anyone who cares it’s here. Â I guess f2c is kind of pointless, seeing that the OS already comes with a F77 compiler.
(note this is a guest post by Tenox)
In previous posts from ASV series I have explained why I got hooked on Atari System V UNIX and what I had to do to get a decent resolution out of Atari TT. Having built the VGA monitor adapter, the next challenge was to replace the internal SCSI hard disk with a flash storage of some sort. I really don’t like spinning hard disks and especial the old ones.
I have mentioned that there are two surviving ASV disk images. The better one was made out of a rather large old, loud and obnoxious Maxtor. I’m definitely not having this monstrosity inside of my beloved Atari!
Maxtor LXT340SY
So how can you replace an old SCSI hard disk with a modern flash device? There actually are several different ways.
If you have the money you can go industrial route, which is a SCSI disk replacement for various machinery and embedded systems produced by ReactiveData. You can buy one of these for a little over $1000 USD. The good part is that they substitute a specific real hard disk model and are exceptionally good in quality of emulation. However, spending a lot of money on my TT and TenoxVGA already, this really wasn’t an option without getting a divorce.
Another approach is to use SCSI to IDE bridge combined with IDE to CF adapter or possibly SCSI to SATA bridge and SATA SSD disk. These are widely used by Atari / Amiga / Mac 68k community. The most popular bridge come from a company called Acard. I actually had one of these at hand, AEC-7220U which I used for TOS/GEM work.
acard front
Did it work? As you can guess – of course it didn’t! The initial boot loader errors out unable to read disk capacity.
Atari SYS V failed to boot
Atari ST/TT, somewhat similarly to 68k Macs require a hard disk driver, present on the hard disk itself. There are several 3rd party implementations, some of them, like HDDRIVER maintained up to present date. Unfortunately these drivers are TOS specific and obviously don’t work with Atari Unix. The system comes with it’s own hard disk driver which seems to be obsolete and with limited hardware support.
The next step was to research and try out some other SCSI to IDE bridges in hope one would just work. And surprisingly there are several to choose from.
The second on the line was I-O Data R-IDSC21-E/R. No longer produced and supported, however still fairly popular. Usually regarded as the ultimate bridge with most fancy options bells and whistles. It has most jumpers and modes of all tested devices. For instance ATA PIO and DMA modes. Unfortunately this didn’t help at all and same error was observed.
idsc21e
Another device tried was Yamaha v769970. This bridge was conceived to allow use IDE CDROM and Hard Disks with Yamaha samplers. No longer produced and obsolete, it’s somewhat most easy to set up, robust and stable. It’s actually my favorite bridge for day to day use, except for ASV where it just doesn’t work.
v769970
More recent kid on the block is an integrated SCSI2IDE + IDE2CF in one device called Aztec Monster. Recently designed and currently produced in Japan (you can buy one on eBay) is a fairly decent choice, which I recommend to every one. I had a lot of luck with these, except for ASV of course…
CF_AM_r1_1
I also looked in to SCSI to SATA bridges, like this one, but they have additional issues, like need to convert LVD to SE on one end and SATA to IDE to CF on the other. Little bit too complex for what I wanted.
Being out of luck I started researching if it would be possible to build an open source version, which can be easily diagnosed and fixed. Doing so I found out that there in fact is one open source SCSI adapter called SCSI2SD.
SCSI2SD_V3.0_plain
I was bit skeptical in the beginning but then I though that being open source it can be debugged and fixed if it needs to be. So I immediately ordered one.
Once it arrived, I plugged it in, applied the image to the card and BAM! It worked! The system booted fully and worked flawlessly!
Atari Unix System V – Boot Sequence from Antoni Sawicki on Vimeo.
Over time SCSI2SD proven stable and flawless. One feature that Mac users will appreciate:
--apple Set the vendor, product ID and revision fields to simulate an
apple-suppled disk. Provides support for the Apple Drive Setup
utility.
In the next article I will write about my first steps in the system post boot and then bringing it to a more or less usable state. Stay tuned!
Shoebill!
Good news, as mentioned here, the Shoebill emulator was recently given some much needed SDL love, and ported to Linux.
Well that’s great and all, but the vast majority of people who run anything these days do it with Windows. Â So I decided to try to get it to compile with MinGW to see how far I could get.
And the short version is that I got it working!
The long version is that in the first pass there is some SIGUSR2 stuff that is undefined. Â And for a good reason, since it won’t work. Â So I just commented them out. Â The next minor problem was the lack of bzero. Â Honestly I don’t know why bzero is missing from MinGW, but who knows why.
Shoebill also processes some internal macros with a perl script that for some reason was dropping in binary values into the source, making GCC mad. Â I just commented out a line that was adding in more comments into the header. Â This let me compile with a simple pass.
There was some issues reading the ROM file, since the 68000 is a BIG ENDIAN processor, and the 8086 is LITTLE ENDIAN, Shoebill makes extensive use of hotns and hotnl, ntohl, and ntohll.  These can be found in the winsock library, and even better they dont need any winsock initialization, they work right away.  I just have to make sure I include winsock2.h, and link against the winsock library.
However when trying to boot, the checksum was 0x00000000, not the expected value! Â Luckily there was an assert to catch that and crash. Â This led me to notice that in Linux files are opened in binary mode by default, while on Windows, they are opened in ASCII mode. Â A quick change of all the fopen calls, and I was reading the ROM, but now crashing on the disk.
As it turns out newer versions of GCC go all crazy when it comes to structs, and try to automatically align to boundaries for quick access. Â Which sound nice, until you try to read in some binary data, and expect things to be in certain locations and find out that your structure is larger than expected, and data is read in the wrong place.
The solution is to force the compiler to leave it alone with
__attribute__ ((__packed__))
HOWEVER as luck would have it, Microsoft apparently packs structures a different way, and you have to either make a macro to do a bunch of work to force it to make the structure 1:1 of what you expect, or use the CFLAG option of
-mno-ms-bitfields
And now MinGW’s GCC will build something along the lines of what it’d build on Linux.
Putting it all together, I amazingly got this!
Shoebill on Windows
Phew! Â So for those interested, here is the source code drop(Use the updated one here!), and here is the binary.
If you ever wanted to see the “OS X” of the 1980’s, now is your chance!
No really, you read that right! Â You may remember my post about this emulator a while back, with a small mention how it’ll boot the diagnostic disk, and fail from there.
Well now, thanks to Andrew Warkentin’s hard work, the system now boots!
3B1 time check
Using the 3.51 installation set from bitsavers, and the IMDU program to decompress the disk images the emulator can install UNIX onto a hard disk image (be sure to check the debug version, and the stderr.txt for the emulated geometry for your supplied hd.img).
I’ve got to say, it’s pretty cool! Â Although building the exe for Windows needed a little nudge, but my compile seems to be working, although the ‘release’ version still outputs far too much information.
blank
At this point it’s stuck “working” .. I thought it’d be able to do more, but it did take down the new root password, and then say it’s “setting up the screen”. Â I ran a second copy on wine for the heck of it, and it’s doing the same thing.
Apparently if you ‘X’ the modem panel, you’ll get a desktop
I’ll update as I can, but I wanted to get this out there. Â For those who want to try, you can download my work here. Remember F10 will capture/uncapture the mouse.
The floppy disk file is called ‘discim’.  Simply copy the RAW 409,600 byte file onto this filename, and freebee will pick this up as a disk change.  You can make a hard disk file by simply creating a blank file (I used qemu-img create -f raw hd.img 65M) by providing a file of that size called hd.img .  When freebee starts, if you look at stderr.txt it will tell you the geometry that it is going to use:
WD2010 initialised, 1040 cylinders, 8 heads, 16 sectors per trackDisc image loaded.
Which you then pass onto the diagnostic disk to format the hd.img.
(boot with the diagnostic/setup disk, 01.RAW)
Option #2 (Format Disk), then Option 12 (Others). Â Then using my information, 1040 cylinders, 8Â tracks, 16 sectors per track (I guess it figures out heads on it’s own from the tracks?) Â I then let it setup the disk as multi-user and it’ll format the disk. Â It should only take a few seconds.
Format the disk from the diagnostics floppy
Installation of the OS starts with 02.RAW and it’s pretty self explanatory.
Apparently the best way to login the first time is to move the mouse frantically around, and it may let you into the system. Â Logon as root and try doing this:
remove the /dev/ph0 and /dev/ph1 files
make a new /etc/inittab
is:2:initdefault:
rc::bootwait:/etc/rc > /dev/null 2>&1
vid:2:respawn:/etc/getty window 9600
remove the files
/etc/.modeminit
/etc/.phclr
/etc/.phinit
I did that to my disk (download), and I can now boot up.
3B1 booted up!
I found vi and the C compiler on the bitsavers archive, but the C compiler currently doesn’t work.
panic: pagein
Which is no doubt something else up with the MMU.
(note this is a guest post from Tenox)
Christmas came early this year. An emulator able to run Apple A/UX has been developed. It’s called Shoebill. See also Screenshots and Discussion. Hurray! I can finally get rid of my old Macs!
Also, A/UX documentation is available here.
A/UX on OS X!
Â
Update: latest dev snapshot runs A/UX 3.0
(note this is a guest post from tenox)
A long long ago, my father had a printing business. An emerging technology called Desktop Publishing (DTP) was just taking to the mainstream. I have been involved in migration from Linotronic typesetting machines (see above) to more modern and GUI driven Atari TT with Calamus. Those were fun times. Long story short, I became an avid fan of Atari. Unfortunately as time progressed, Ataris got in turn obsoleted by Macs with Quark Xpress and Photoshop. I myself started exploring world of Unix and ended up selling my Atari to be able to run Linux. Bit of shame from time perspective as there were plenty of Unix flavors for the Atari: Minix, Linux, NetBSD and MiNT. Unfortunately they were released after I parted with the platform.
Fast forward 20 years, Atari own UNIX version surfaced the earth. It was originally released in mid 1992 but died shortly after, no one ever heard about it. It has been lost to humanity. Only two good souls had working versions of the system and under pressure of the community finally made disk images of their installations. Some time after a documentation set has been found and digitized. Now I’m in process of trying to restore last existing set of damaged installation tapes. You can find little bit more history of the efforts on this thread.
Out of nostalgia and the fact that Atari TT has been designed as a Unix Workstation, but never got a chance to play with it in this role, I decided to purchase one for myself. I have turned to Best Electronics who is a local Atari dealer around the corner. They sell Ataris like brand new, assembled from spare or reconditioned parts. I paid a small fortune for it, but I got myself a brand spanking new Atari TT, factory sealed and smelling like new after 20 years. It was fitted with latest motherboard revision, TOS, 1.44 MB FDD, 4 MB ST RAM and 16 MB TT RAM.
I was told to just hook it up to a VGA monitor and viola, it will work. Which it did… except to my utter shock in a whopping resolution of 640×480. It looked absolutely horrible stretched on a 19″ LCD panel. I don’t have any pictures but it looked like this. For games maybe OK but not for Unix or any sensible applications.
Using TTs professionally in DTP I certainly didn’t remember them suffering in the resolution department. So what was I doing wrong? Aha! In the old days we used to use special high resolution VME graphic cards. So I went to search for one on eBay and Atari Forums. These obviously proven to be impossible to find… obviously. Additionally I learned that Atari UNIX does not support any of these as they required special TOS/NVDI drivers. In order to run ASV X11 with a decent resolution, one needs a special high resolution monitor called either TTM 194 or 195. These were “professional” 19″ monitors specifically for DTP work. They worked with the built-in graphics card in a special black and white mode at 1280×960, which is actually decent even in modern standards. In a fact we did have these monitors at the printing shop.
Unfortunately these are very old, bulky CRTs and weight 50 lbs. My wife would kill me if I brought one home and even if she didn’t I would hate having one of these on my desk. So why won’t the “TT High” mode work on a standard VGA LCD which normally supports 1280×1024? Well back in a day VGA standard didn’t support such resolutions and Atari had to make the monochrome monitors using ECL signal similar to old SUN/3 and HP monitors. Higher resolution modes were only added later by VESA BIOS extensions.
Researching the topic a lot of people were actually looking for an ECL to VGA signal converter but one did not exist. Some managed to use old EIZO CRTs with ECL support and with decent results, but still these are 50 lbs CRTs and I wanted to run ASV on a LCD panel. An adapter to convert ECL signal to a real VGA has actually been tried before but with rather awful results. Something had to be done!
TenoxVGA was born. And this will be covered in the next post… 😉
This is probably the most significant Xenix post I’ve made since the old days when I managed to get Xenix running in Qemu all those years ago.
3comB network card
What has long been a frustration with the beleaguered Xenix community is that although there was a TCP/IP package for Xenix (and a much required streams package…) it only worked with a handful of ethernet cards. Â And all of them were early 3com’s. Â While the world was using NE2000’s on just about everything, the most common ethernet board Xenix would talk to was the 3c503, which is getting harder and harder to find as the years go on by.
But right now none of this matters.
I was looking at this article on setting up Apollo Domain UNIX, on MESS. Â And apparently it will do networking! Â Which is cool, so I poke around MESS, and what do I see? 3c503.c. Could it be true?
Now I ended up having to download the source to mame 0.151Â (mame0151s.zip) and building it on OS X. Â Of course remembering to alter the makefile to include the ‘USE_NETWORK=1’ statement, and build for Mess. Â And just as it looks like something out of SIMH, Mess makes use of libpcap which means that you are *unable* to send/receive on the host computer. (OS X & Win32 binaries). Â And of course you’ll need a ROMÂ & Xenix diskettes.
Installing Xenix is pretty straightforward as long as you know your system key, and how to navigate the mess UI without rebooting mess or exiting by mistake (scrolllock on the PC, function/Delete on OS X).
First create a hard disk, and as always it should be ~500MB max.
chdman.exe createhd -o xenix.chd -chs 1015,16,63
chdman – MAME Compressed Hunks of Data (CHD) manager 0.149u1 (Aug 10 2013)
Output CHD: xenix.chd
Compression: none
Cylinders: 1015
Heads: 16
Sectors: 63
Bytes/sector: 512
Sectors/hunk: 8
Logical size: 523,837,440
then with the disk in hand, I just setup a 486 like this:
./mess64 at486 -harddisk1 xenix.chd -isa2 3c503 -ramsize 8388608Â -floppydisk1 xenix/n1.vfd
Naturally you’ll need to setup the CMOS, for your memory size, and the hard disk. Â The BIOS I’m using didn’t autodetect the IDE drive, but it doesn’t matter as I know it’s characteristics as I created it.
From there Xenix was a pretty straight forward deal. Â Mess has good floppy drive emulation so it just worked. Â Adding TCP-IP was just as involved, and all went well. Â When it came time to install TCP & the network driver, remember to use thinnet, as the thicknet transceiver isn’t connected (as it would seem). Â The 3c503 is softset, so I went with IRQ 5, port 0x300, and thinnet, and it works fine for me!
Xenix TCP/IP in action, inside of MESS!
Remember you will not be able to attach to it from your computer. Â Instead you must attach from another computer.
Also MESS tries to emulate true to hardware so it’ll be just as slow on MESS as it was on the real hardware. Â I suppose you could go with the at386 driver, but yeah it’ll be slow. Â The current at586 driver has issues booting from the hard disk, and I didn’t mess with it too much as Xenix is known to have issues with some Pentium systems.
Although I think the next place for adventure is the emulated Adaptec 1542CF.
So while googling around, I came across the source code to Iris 3.7!  SYSV for the old 680×0 based boards.  And in there, of course is the source to rogue 3.6 .. And a little more googling I came across rogue.rogueforge.net, which includes cleanups to the source, and binaries for Win32, Linux and DJGPP (MS-DOS!)..
Happy Rogueing!
SunOS 4.1.4 was the last version of the BSD based SunOS for the SPARC platform. Â I had received an email earlier asking if Qemu could run SunOS. Â Earlier it was ‘capable’ however there were issues with the serial ports. Â And the framebuffer stuff that the SUN Proms recognized was never mainlined (please tell me I’m wrong?).
But then with a quick google search I came across this wikibook page with detailed instructions on how to install SunOS 4.1.4.
SunOS on Qemu 1.7.0rc2
So I quickly built a sparc version of Qemu 1.7.0rc2, and followed the instructions. Â I was amazed that now we are able to boot off the CD (still attached as a HD though) but label the main hard disk, and install SunOS. Â I have to say it is very impressive.
Another hint I came across is the more correct way to boot the Sparc Station 20’s
-bios /usr/local/share/qemu/ss20_v2.25_rom -M SS-20 -smp 2,cores=4 -cpu “TI SuperSparc 60”
Sadly there is no graphical output, but the PROM won’t crash. Â I think you can have 512MB of ram on the SS-20.
AMIX Ad
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 amigaunix.com 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.
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
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.