I started my “career” in computing with an Apple II+, at first only with a tape recorder and then a single disk. What it did get next were a language card, a 80-column card and the Z80 “coprocessor”.

But while I learned a lot from that combination, the processor I enjoyed programming most (in assembly language) was the Motorola 68000, the processor in my next computer, an Atari ST.

Components

• The M68000 processor (obviously)
• Some RAM (since I only have 8-bit RAM and the M68000 has a 16-bit databus that means two), at least 2 * 62256, which should give it a whopping 512MB
• some I/O processor (I know I don’t want to play around with the hoops M68k hardware developers had to jump through to get all that stuff working with discrete logic or even GALs), I’m thinking maybe a bluepill should work.
• I/O should be (in prioritized order): serial I/O for terminal, SD-card for storage, sound (have eg. AY-3-8910 and YM3428), and maybe even a display

Basic “how it works”

At startup RAM is disabled for reading, enabled for writing, and the I/O coprocessor copies either something in its own memory or something from an eeprom (have 2816-28256, so 2k to 32k which translates to 4k or 64k). After that RAM is enabled for reading as well, and the processor is reset, so it begins operation at whatever the content of RAM from 0 upwards are now.

This process could be reimplemented the way it was in “the olden dayes”, that is, with a counter IC and some simple logic, but since we have the I/O processor, why not use it.

As for communication between the I/O processor and the mail processor I’m still in the thinking box, one possibility would be to communicate through a shared memory space, but that wouldn’t be too responsive (I think). A better way would be to map some I/O into the main processor’s memory space that can generate interrupts for the I/O processor. Vice versa there should be a way to generate IRQs (traps) for the main processor from the I/O processor. That is why I chose the bluepill (well, maybe, if there isn’t another board with a similar amount of I/O pins), every input/output line can be connected to an interrupt.

Software

At the very least the “boot ROM” should have the following:

• a machine language monitor, with disassembly
• a BASIC interpreter (because that’s how those old-school retrocomputers roll)
• maybe a FORTH interpreter/compiler
• maybe some other small language suited for embedded computing
• ability to boot CP/M 68k
• if I can find it - that RTOS I had on my Atari, with a language called “Pearl” (no, not Perl, Pearl)