FBUG68K.ARC from the original Motorola freeware site. It's a DOS archive, so the filenames are truncated and there are other issues... read on.


To build this, you need a linux box and a 68000 cross-compiler. Google will point you at Marc's writeup for building gcc as a cross compiler, but don't be fooled. It's a disaster. For starters, binutils 2.15 gives

error: array type has incomplete element type extern struct relax_type md_relax_table[];
which is easily fixed, though of course you need to operate on gas/config/tc-m68k.[h|c].

Then, when running make install,

as.texinfo:3609: @itemx must follow @item
I could not be arsed to install a different version of texinfo so I diked out
#SUBDIRS = doc po
in gas/Makefile and
#INFO_DEPS = ld.info
in ld/Makefile.

And even then I got an assembler which segfaults when compiling gcc.

Can not recommend.

OK, so google some more. Ahah, gold! Stephen Moody of Y Ddraig fame made a script that downloads and compiles binutils, gcc and libgcc, as well as vasm, vbcc and vlink (portable tools by Volker Barthelmann and Frank Wille) and Cygnus newlib, all as 68000 cross-development tools, all automated, all unattended, all works.

OK, I had to

git config --global http.sslverify "false"
but I can live with that.


$ /opt/m68k-elf/bin/m68k-elf-as -v
GNU assembler version 2.33.1 (m68k-elf) using BFD version (GNU Binutils)
$ /opt/m68k-elf/bin/m68k-elf-gcc -v
gcc version 10.5.0 (GCC)
You get fairly modern tools. Woot.

Pesky ^M

As mentioned on verycomputer.com, lines are terminated with CR (\r or ^M) and not CR+LF (\r\n i.e. DOS) or LF (\n i.e. Unix). Notepad++ makes quick work of this.


Also as mentioned, all the filenames are mangled into DOS namespace. Nothing one can't fix with a bit of work. The true (long) filenames are in the Makefile.


With modern tools come modern responsibilities. You can't write code the way K&R used to, back in the day. The modern tools get upset -- things like assuming a function returns an int, implicitly declaring functions... yea, some work here, dragging this thing into the 21st century.


The assembler syntax is (to me) particularly baffling. I was muddling my way through the code, found

    mov.l	&0x1,(SYSRAMLOC+0x1000)
OK, so &0x1 should be translated to #$1. & means #, i.e. immediate. Cool. Gotcha.

And then I ran into

    movm.l	([RD0]),&0x7fff 
Which translates to movem.l (address),#$7FFF. WTF? Until I realised that the $7FFF is the mask, which would normally be specified as D0-D7/A0-A6 or some such. The assembler just inserts the value into the output stream.

This is where I reached out for help. Got hold of Holm Tiffe who is still working at the same place* as his .sig, 20 years later (OK, so am I, but still), and he was so kind so send me a whole bunch of stuff, including a sanitized version of FBUG68K which he compiled for the 68010 running on a KAT-Ce, a product of the German C't magazine.

That really helped. Thanks, Holm!

* Holm tells me this is not strictly true. But it was close enough for me to contact him, and that's good enough for me.


I want to send another shout out to the guys over at WinMerge. This is one excellent file / directory comparing tool. Open FBUG68K on the one side and Holm's 68000 directory on the other and compare. It tells you which files are different, shows you where they are different, allows you to edit either side... very useful.

It compiles

2023-08-19: I have code that compiles without too many warnings, and the output looks promising. If you want to get fbug68k running, this would be a good place to start maybe.

FBUG68K 2.0

(Working Title)

I'm not too sure this is going to be FBUG any more. Let's see where it goes. For starters, I'm stripping out everything >68000. It's in my way and I don't see a real chance of me building something 68030 and wanting to use FBUG on it. If I do, there's WinMerge.


Even though I currently feel that I'm going to keep a lot of FBUG, I'm also drawing heavily on DdriagDOS and dBUG for inspiration,


While most of FBUG68K and dBUG (and DdriagDOS for that matter) is written in C, the startup code has to be in assembler. The startup code:

  1. initialises the CPU, and stack, (See dBUG vectors.s, mcf5200_lo.s)
  2. copies the vectors from ROM to RAM, (see dBUG main.c
  3. initialise the .data segment from ROM
  4. zero the .bss segment
  5. initialize the hardware (UARTs etc)
  6. ...

In dBUG, only the first step is in assembler. In DdriagDOS, the C code in main only takes over halfway through 5, with the UART initialised in assembler but the RTC and other hardware initialised in C. It doesn't really matter I suppose. I'm initialising the EPCI and writing a message before calling main()

Exception Handling

FBUG68K handles exceptions through exception.s and handler.c. Unfortunately this relies on a "4-word stack frame" which is a 68010 and up thing, where the vector number is also stored on the stack. The 68000 does not do this, so my exception handling is somewhat more cumbersome.

[Image] Hit Count
hits since 2023-08-10.

Back (This page last modified 2023-12-14)