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.

This entry was posted in 68000, cross compiler, gcc, x68000 by neozeed. Bookmark the permalink.
avatar

About neozeed

What is there to tell? I've loved UNIX like things since I was first exposed to QNX in highschool (we had the Unisys ICONS!), and spent the better time of my teenage years trying to get my own UNIX... I should have bought Coherent in retrospect.. Anyways latched onto Linux in 1992, and then got some old BSD admin books and have been hooked on the VAX BSD & other big/ancient things since...!

4 thoughts on “Cross compiling to the Sharp x68000

  1. Hey there. After finding your mac human68k gcc binaries I’ve been wanting to migrate my windows xp based build environment over to OSX, which is my OS of choice.

    There are a couple of things are less than ideal though. Specifically the process of going from a compiled .x file to actually running it in some emulator.

    On windows there are program to edit xdd floppy images that I could use to copy executables over, and run on my emulator of choice by just booting off of the disk. Seems there is no such x68000 floppy image editor on OSX, and the shared folder trick you showcase in your post seems to be windows only.

    If you have the process figured out on OSX then do share. In addition, any idea of a better way to debug programs, short of using printf?

    • You could use wine, it’s pretty good at generic stuff like this. Also it turns out that there was an ancient GCC 1.x port to the x68000 back when it was a viable platform. I’m still trying to gather the pieces. But otherwise it’s basically printf. Debug your program logic on a machine that has a proper debugger.

      The real problem is the libc, and I didn’t rely see clear way to deal with it’s missing functions.

      • Ah, debugging my program logic can only be done on the actual x68000 since my project is a game, and I make heavy use of x68000’s excellent game specific hardware.

        I remember back in 2013 when Lydux was still doing working on his toolchain I had conversation with him about getting debugging to work. There is certainly a way to do full debugging, but it goes way above my head.

        I believe you can boot the x68000 up in a debugging mode or some such, and the idea was to use some sort of emulation piping to connect the executable running in the emulator with gdb running on on the build machine.

        Is the GCC port that official C compiler for the x68000 that there are images of here and there?

        Back before I had started on my project I briefly considered doing the coding on an actual x68000 using that compiler, but quickly gave up on the idea as being impractical.

        As for Wine, well, I’ve never used it. I suppose it could be used to run the floppy image writer on a mac. But the most ideal scenario would be an automatic compile to execution in emulator build environment.

Leave a Reply

Your email address will not be published.

Notify me of followup comments via e-mail. You can also subscribe without commenting.