FBUG68K

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.

Cross-tools

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[];

Then, when running make install,

as.texinfo:3609: @itemx must follow @item

#SUBDIRS = doc po
SUBDIRS = po

#INFO_DEPS = ld.info
INFO_DEPS =

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"

Also:

$ /opt/m68k-elf/bin/m68k-elf-as -v
GNU assembler version 2.33.1 (m68k-elf) using BFD version (GNU Binutils) 2.33.1.20200119
$ /opt/m68k-elf/bin/m68k-elf-gcc -v
gcc version 10.5.0 (GCC)

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.

Filenames

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.

Archaism

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.

Assembler-fu

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

start:
    mov.l	&0x1,(SYSRAMLOC+0x1000)

And then I ran into

    movm.l	([RD0]),&0x7fff 

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.

Winmerge

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

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.

Heritage

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,

Startup

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.