Cross compiling to the Sharp x68000

While looking for some stuff on the x68000, I came across this package Lydux, which features GCC setup as a cross compiler from either Windows or Linux to Human68k.

So I downloaded the Windows version, set it up according to this guide, and set on trying to build a simple EXE.  I did install CodeBlocks, but I ran into a problem while trying to build a running executable.  For some reason objcopy doesn’t work correctly unless it is in verbose mode.  I found that by accident, but much to my surprise it does work!

Hello World cross compiled from Windows to the x68000

Hello World cross compiled from Windows to the x68000

In the script for CodeBlocks, changing

oc_x = _T(“human68k-objcopy -O xfile $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_FILE).X”);

to

oc_x = _T(“human68k-objcopy -v -O xfile $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_FILE).X”);

did the trick, and now it’ll generate working executables.

I’ve found the emulator XM6 TypeG version 3.13 L21 the easiest to deal with as it has English translated menu’s and lets you mount a folder on your PC as a virtual drive.  This makes loading cross compiled stuff much easier.

Since finding this stuff is getting harder and harder, and that most of the xm6 forked emulators are closed source, I thought I’d at least upload what I’ve been able to find.  It’s a shame the 68030 stuff is closed off, but there isn’t anything I can do about that.  Apparently there was some feud between some dev groups.  I’m not really sure as it seems.

All my work on this is here.

WindrvXM settings

WindrvXM settings

Be sure to set the shared directory under Tools -> Options to be able to map a shared directory.  In the disks sub directory there is a HUMAN302 disk image which contains the needed device driver to map into the directory.  You can run either the 68000 or 68030 model depending on what you like more.  If you have no emulated SCSI or SASI disk, the shared directory will appear as your ‘c’ drive.  And as always the keyboard will be mapped to a Japanese keyboard, so that is why the : * = keys seem in the wrong place.

On the OS X front I went ahead and built a cross compiler.  I ran into this fun error building GCC on OS X:

Makefile:142: ../.././gcc/libgcc.mvars: No such file or directory

So yeah it turns out you really should configure/compile gcc in a separate directory from the source. Bad old habits die hard. Anyways my tool chain is here. I’m running 10.10 so I’m not sure about older versions of OS X.

I just played with NeXTSTEP 0.8

NeXTSTEP 0.8

NeXTSTEP 0.8

And I have to say, it’s pretty impressive!  Previous flies on my system, having owned a cube, I can say that the 68030 on this is WAY faster.  And I’ve always read about 0.8, and kind of figured it was basically lost to the winds of time.  It’s really cool to see it boot up!  And the emulated disks are so much faster than the magnetic optical drives of the day.

It’s amazing to think that in 1988, the current world of iThings had just started.

CP/M-68K Simulator

I found this last night, and thought it was worth sharing.

This simple CP/M-68K simulator, is built around the famous Musashi MC68000 simulator core.  So it’s a little more well debugged than the SIMH CP/M-68k. Namely that COM works!

COM running Zork1 on CP/M-68K

COM running Zork1 on CP/M-68K

I managed to build this under Window with MinGW, the only caveats were that it opens the disk files without explicitly in binary so on Windows it opens everything in ASCII and nothing works.  Also MinGW doesn’t emulate a vt100 or provide termios so all of that had to be commented out.  But for the full experience you’d want to run it on *NIX.

I suppose you could write an ANSI intercept, and manipulate the NT Console, but that is a lot of work.

On the plus side, this solution is more stable, faster and feels more robust with a 16MB hard disk, and a standard IBM 3740 floppy disk in the ‘a’ position.

One thing that was a snag to me, was the windows version of cpmtools is built to default to the apple-do type, aka Apple II CP/M skew for DOS 3.3 … So I was trying to setup a floppy image with too much work.  Also the default size of the 3740 disk is 256,256 bytes.

For example:

 

C:\temp\cpm\cpmtools>cpmls -f ibm-3740 zork1.cpm

0:
bye.com
zork1.com
zork1.dat

But if you find z80/8080 CP/M too mainstream, give the 68k a shot!

SAGE CP/M disk fun

Wow this was without a doubt one of the more confusing things I’ve ever done.

So here is the problem. I want to delete some files from an IMD disk image, and then copy some new ones in.  Easy right? .. maybe.

Ok first up the easiest tool I’ve found to manipulate CP/M disk images is cpmtools.  Even better their pre-compiled binary is for Win32, so I’ll run it with Wine on OS X.  which works fine. Â Although there is one slight problem, cpmtools doesn’t read the IMD disk format.  So you will have to download imd118.zip from a backup of the late author’s computer.

Now using IMD you need to convert the OS disk into a ‘raw’ or ‘binary’ file.  Naturally IMD is a MS-DOS program so firing up DOSBox, I ran:

Screen Shot 2013-12-05 at 8.35.58 PM

Uncompressing, so easy!

IMDU CPM68K12.IMD CPM.RAW /B

And a few seconds later I had my raw file.  Now the next thing was to manipulate the image in cpmtools.  cpmtools has a database of disk drive types, and naturally there is no definition for the SAGE2.  However thanks to a friend of mine (hi Lorenzo!) I took a look at 22disk, and found their demo version did in-fact have a definition for the SAGE:

BEGIN SAG2 Sage IV – DSDD 96 tpi 5.25″
DENSITY MFM,LOW
CYLINDERS 80
SIDES 2
SECTORS 8,512
SIDE1 0 1,2,3,4,5,6,7,8
SIDE2 1 1,2,3,4,5,6,7,8
ORDER SIDES
BSH 4 BLM 15 EXM 0 DSM 315 DRM 63 AL0 080H AL1 0 OFS 2
END

Which is great, however it took a bit of experimenting to work out how to format this information for cpmtools.  I compared a bunch of known formats, and then managed to work this out:

diskdef sage2
seclen 512
tracks 160
sectrk 8
blocksize 2048
maxdir 128
skew 1
boottrk 2
os 2.2
end

And now I can look at the image file!

$ wine cpmls -f sage2 CPM68K12.RAW
0:
ar68.68k
armath.sub
as.sub
as68.68k
as68symb.dat
asgo.sub
brwnies.txt
copy.68k
core.sub
cpm.sys
ddt.68k
ddt68000.68k
dump.68k
e.sub
find.68k
halt.68k
init.68k
linkcore.sub
lnk.sub
lo68.68k
m.sub
mcc.sub
mince.68k
mince.swp
mind.sub
orbit.sub
p.sub
pe.sub
pip.68k
print.68k
red.sub
redasm.sub
sage4utl.68k
sagebios.sys
screen.68k
setenv.68k
setprntr.68k
sig.txt
space.sub
spacem.sub
startup.sub
stat.68k
tlnk.sub

So, I tidy up the image and copy it back to the IMD program for compressing.  And this was, without a doubt the most difficult to figure out, until after a bunch of searching, and Lorenzo once more again pointed me in the direction of bin2imd

not intuitive!

not intuitive!

So yeah.

BIN2IMD X.RAW X.IMD DM=2 N=80 SS=512 SM=1-8 /2

And the best part is that it worked!  So now I was able to transfer over a binary version of com.68k, com2.68k, along with Zork, and fire it up!

8080 Zork on 68k CP/M

8080 Zork on 68k CP/M

Unfortunately, the interpreter doesn’t work right.  It could be the disk transfers fault, maybe the SIMH SAGE emulator, or even the 8080 emulator.  But it worked this far.

SAGE CP/M 68k on SIMH

Somehow, I missed this as a ‘beta’ driver for the last public release of SIMH.

68k CP/M 1.2

68k CP/M 1.2

What makes the 68000 version of CP/M different from the i8080 version is that it was coded in C.  And of course 68k CP/M suffered the same problem every other processor incompatible ‘same os’ OS has ever suffered which is no applications.  But that is when I remembered the COM, which started out it’s life as an 8080 emulator for the 68000.  With a LOT of creative googlling, I managed to find the source, mysteriously labelled 8088M.ZIP.  I also found a binary here. But unfortunately that is as far as I got.  I haven’t managed to figure out a way to inject files into the SAGE CP/M IMD disk images.

So this is where I’m stuck, and this is my call for help.  If anyone knows how to get files in/out of these IMD files give me a shout.  For anyone interested in 68k CP/M this is your chance to get it running.

The one funny thing I found in a hex editor of the disk image was this:

Screen Shot 2013-12-05 at 12.20.20 AM

Cryptic message

Oh well.

 

***EDIT***

Never mind, me and a friend of mine (hi Lorenzo!) got the disk image thing figured out!

AMIX

AMIX Ad

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.

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.

AmiDevCpp

Antoni sent me a link to this project, AmiDevCpp. It is a nice little wrapped up IDE for cross compiling applications for the following platforms:

  • AmigaOS (m68k)
  • AmigaOS4 (PPC)
  • MorphOS(PPC)
  • AROS (i386, ppc and x86_64).

Naturally it doesn’t work correctly on Wine.. .Oh well, but for you Windows users out there that haven’t installed Cygwin this is an easy way to cross build stuff for the ancient Amiga platform.

Apparently he was able to rebulid the infamous aclock using this cross compiler…

More fun with Janus!

Frontier Elite, on Janus

Frontier Elite, on Janus

So, I came across this great page, Frontierverse, which has download links for all the versions of Frontier Elite which were released out as shareware.  So what is cool, is that using the AROS Kickstart replacement ROM, it’ll boot up and work!

Just be sure to increase the default amount of chip memory, as it seems the AROS Kickstart ROM consumes more RAM than the Commodore ROM.  But heck the AROS ROM is opensource, and free!

Pretty cool, and more interesting than say the normal, yippie a view of the AROS cat..

 

AROS Kickstart ROM

AROS Kickstart ROM

Again very cool stuff!

And lastly, I slapped together a disk that’ll boot up aclock, although it works only with a Kickstart 2 or higher ROM.. 1.3 kinda freaks out, and I didn’t feel the need to go all over the top on this one.  Booting the aclock disk with the Aros ROM though loads up, but the clock doesn’t tick..

On OS X, I’ve been using the FS-UAE emulator to some degree of success, I’ve found it a tad cumbersome for swapping floppy disks, and I’ve had a major issue where making updates on an ADF that while they all look like the changes are reflected, going to the filesystem proved otherwise.  So I wound up having to make DMS disk images, and running some ancient MS-DOS program to convert DMS to ADF‘s.  Naturally the compression programs were in turn.. compressed.  So with enough fooling around with various archivers I found here, I was finally able to get where I needed to be.

At the same time, looking at how the AROS kickstart replacement ROM is quite capable, it may be time to revisit AROS, and I would imagine it has become far more capable than that last time I had looked at it.

25 years of GCC!

In 1987 the first announcement went out that Stallman had introduced perhaps the most important piece of GNU software ever:  GCC.

I haven’t been able to locate the 1.0 release or even the 0.9 beta (*Edit as an update, yes I’ve found it, and installed it!), as close as I could find was 1.21 from May 1st, 1988. Even at this time, GCC supported the following CPUs:

  • m68k
  • ns23k
  • spur
  • vax
Amazingly GCC at this point is pretty snappy, and very ANSI compliant unlike PCC.  At this point it still relies on native assemblers, linkers, librarians it still was pretty versatile. Back then there was no auto configuration tools you have to link configuration scripts by hand but even on VAX BSD it builds somewhat straightforward (providing you read the documentation)..

GCC 1.21 on 4.2 BSD

I don’t know if it serves any practical value but I went ahead and built a source package for GCC 1.21, along with a 4.2 BSD binary package.. I suspect it’d only be an interest to a select few.. Although if anyone has 1.0 or 0.9 I’d be interested!

By 1991 GCC 1.40 supported not only the i386, but Linux kernel.. And as they say the rest is history.

And finally a video summation of all the changes to GCC…