Retro 68000 computer designs

Are there any retro 68000 single board computers out there with
512kb ram/rom,rs232 serial i/o and dual compact flash cards?

There are many in various guises:

Some examples:

that’s SD card though. Another:

Also SD.

Searching with the popular search engines brings up:

and many, many others. Just use google or duckduckgo, etc.

-Gordon

1 Like

This one looks promising (68K nano), but it still needs hacking on the schematic for 2 CF cards. This way I can backup the system.

Backup - in hobby retro systems…

It’s an interesting point, but I really feel the requirements of 2 devices (be they physical drives, CF, SD cards, SSD, whatever) is overkill for a small hobby project.

Especially if you use a common file format on the device - e.g. FAT or one of its variants.

Or just use serial with xyz modem, kermit, etc.

FWIW: When I started my own retro system I designed a filing system for it - although it ended up being a somewhat modified version of something based on the Apple ProDOS documentation… And subsequently regretted wasting all the time on it. I did have serial file transfer but while usable not as convenient as pulling the SD card and sticking it in a PC to do bulk file copy.

I had fully intended to write a file system module for my Linux desktop to run under FUSE, but that never happened, so one day I just bit the bullet and re did the while thing using FAT. I’ve not regretted it. Lifes too short.

-Gordon

1 Like

And subsequently regretted wasting all the time on it. I did have serial file transfer but while usable not as convenient as pulling the SD card and sticking it in a PC to do bulk file copy.

I tend to look at computers from the programing side, makiing backups
and duplicating floppies are important as well as ease of programming.
I need a stable 16/32 bit hardware platform and I don’t want to reinvent the
wheel again. Self hosting and stand alone are important to meI don’t want to spend time revising PCB layouts, just to get a working machine.
Most designs seem to be “Penny wise, pound foolish”.

I am not fond of the 68000 but what other real ( as in for sale) 32 bit chips are out there to build with. Load/store cpu’s are too complex hardware and software wise for a DIY project.

Not really sure what to suggest here … I know you’ve gone through the loop(s) of making your own CPU, etc. various bit widths too, but making backups and duplicating, etc. I see that more as “operations” than programming. If you want a retro backup system, then tape might be where it’s at.

Self hosting - well, Fuzix has been around, also One Man Unix and a few others - I’ve pointed out OS-6 (In BCPL for the 16-bit Modular 1) My own RubyOS:BCPL took inspiration from that.

I started with real CPUs - the 65C02 then the 65C816. I did (and still do) want to make my own CPU but it’s a bit beyond my means right now, however I have identified a platform that may make it easy to at least make a virtual version of it - The PiTubeDirect system on the old BBC Micro - a combination of the very new with a “properly” old/retro system of the 1980s.

I’ve been through this loop too, and posted about it in a few places. The 68K is still there - new, hobby friendly in leaded SMT packages in the form of the ColdFire CPUs. But NOS originals are still available too - as demonstrated by the multitude of 68K systems available now.

For me - after the 6502 (or 816) what was there? (Other than 68K and Intel) - very little. The TMS9900 which seemed a little limiting to me. The Inmos Transputer (expensive on the 2nd hand market), NS32016 or …

I went for RISC in the form of RISC-V - while relatively new has its roots in the original Berkley RISC of the early 80s and I’d used Sparc and i860 RISC systems in the past so the concepts were easy to grasp… It turns out that I couldn’t (still can’t) get a nice hobby friendly 32bit system with 512KB to 1MB of RAM but I did emulate it and get my OS running on it and ran it on limited, but real hardware. (The closest I’ve found is the ESP32-C3 and now C6 systems)

After that - ARM. I was resisting ARM for many reasons, but ARM it currently is. Sort of as that’s what the PiTubeDirect project is and I already had a bare-metal framework for a popular ARM system - the Raspberry Pi (Original version 1B). In theory I can get the PiTube to emulate the virtual CPU my system needs and make it look like a real CPU to the BBC Micro host computer. One day.

But there is the same issue with ARM as RISC-V - hard to get small systems with just 1MB of RAM unless I get an original Acorn Archimedes system - As with RISC-V, it’s either modern microcontroller variants with typically KB of RAM or multi-core GB systems designed to run Linux.

Everything really did change mid-late 80s.

I think you have to be realistic with your own ideas - carry on with your own CPUs and so on or adopt a relatively “period authentic” system and work on the software.

An intermediate stage might be FPGA. This was a route I looked at for my RISC-V solution. Small board, existing RISC-V core and subsystem I could put inside the FPGA with a couple of MB of RAM and (in theory) off I go… It wasn’t that easy, but a few things changed when I was looking at it some time back. Maybe I ought to revisit it…

However I lucked out in that when I ported my OS to RISC-V then ARM, I could just run the original binaries. They just went faster. All I had to write was the bytecode interpreter again (and again - it gets easier every time)

-Gordon

There are industrial 68040 VME boards still available, though probably so spendy I’m afraid even to look: CM Computer | CM-CPU-40/60

1 Like

A few more options to consider:
https://retrobrewcomputers.org/doku.php?id=boards:sbc:tiny68k
https://retrobrewcomputers.org/doku.php?id=builderpages:plasmo:t68krc_r01

1 Like

Net was down, so I am looking at that now.
Can one get OS/9 (68000) for this instead of CP/M?
Ben.

Interesting query. It is very difficult to find someone who know what it is OS-9 (68000), and know how to use it… most users are using OS-9 for COCO = NitrOS-9

Whether this link would help?

and also post here: DangerRuss Things: Resurrecting the OS-9/68K (OSK) kernel using the FAME 68K Emulator

OS-9 works or should work on ROSCO board… but no official ports are available…
I am interested in learning OS-9…

1 Like

I picked up the ROSCO board, and plan to use it to emulate some of my design ideas. I also ordered a National 32016 cpu for later development.
Ben.
PS: I hope the Royal Mail package does not get lost coming to Canada.

There are a number of new 68K designs out there, but dual CF is an unusual requirement. 1 meg RAM is fairly common and few do have RS232 interface to serial port, but USB-serial is more common and less expensive.

I have ten 68K SBC designs mostly revolving around single CF disk, USB-serial port, 2-16 meg memory and CP/M68K. Processors are 68040, 68030, 68020, 68000, 68012, 68302, and P90CE201 (a 68000 clone)

https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:start

I can live with single CF but I would like this system to be self hosting,
and that means duplicating disks. My design goal here is emulation
of 1970’s era computer system, something more powerfull than a IBM 1130
but less than a IBM-370 and the same IBM 2310 disk drive.

PCB board layout is not my strong point, and 2 sided pcbs don’t work
for the larger hardware designs I want to build. My last project ; memory
works from the front panel, but I can’t run any programs.
I also can’t find any National 32K projects, online, a buggy but better CPU in my mind.

Real retro designs also need a floppy disk of some kind.
Ben.
PS. A 9 track magnetic drive would also be period hardware.

The Interdata 7/32 (and 8/32) might also fit your criteria. I used one for a while as a pesky school kid getting in the way of it’s serious use for the Education departments work in Edinburgh - it had (from memory) a single top-loading “washing machine” disk and a tape drive. It was self hosting with a home-designed operating system. It also had a line printer and card reader.

I don’t know how the new operating system was actually bootstrapped into the system to replace the manufacturers supplied one though (although I know how it was booted). I suspect a lot of the initial binaries were cross compiled on another system then loaded by tape. Maybe.

Maybe that’s because they were (a) rubbish, (b) expensive, (c) buggy, etc.

Acorn did make both a 32016 2nd processor and a Workstation based on one - a BBC Micro with a 32016 2nd processor + monitor. It ran an OS written in Modula 2 and came with FORTRAN, Modula 2, C, Lisp and Pascal compilers. It wasn’t the best, so Acorn designed ARM…

http://chrisacorns.computinghistory.org.uk/Computers/ACW.html

G.

Here in Canada we have the CBC. I can’t get any thing BBC. :slight_smile:
Even Dr Who was on PBS from the US. The early 80’s had a lot of computing ideas,that never lasted long sadly.
What was rubbish about the 32016?

The original computer for the Oberon system, called Ceres, used this processor.

I have FPGA card floating around somewhere with Oberon on it I picked up a few years back. He is using a RISC cpu of his own design on it.
I never liked Pascal or similar Algol type languges, because of the nested
data structures needs the use of displays. Computer Science tends to ignore just how impliment the run time code, or convert stack based code (p-code) to a register based code.

Struggling to work out what you mean here… “displays” ?

So, Forth? There are systems that have (or make like they have) native Forth. There is at least one CPU I’ve used that has a 3-deep register stack that more or less works like Forth - load a value, load a 2nd value, ADD, store value and so on. See the Inmos Transputer.

The BCPL system I use (so “Pascal or similar Algol type language” as per your definition above) compiles into a data and register stack based intermediate code. Here is an example:

GET "libhdr"
LET start() = VALOF
{
  LET z = ?
  FOR i = 1 TO 10 DO
  {
    z := i * 2
    writef ("Z is %d*n", z)
  }
  RESULTIS 0
}

Which compiles to this code:

// Entry to:   start    
  20: L1:                       // Label L1
  20:     L1                    // regB := regA ; regA := 1 (Load constant 1)
  21:    SP4                    // Stack [4] := regA
  22: L3:
  22:     L2                    // regB := regA ; regA := 2
  23:    LP4                    // regB := regA ; regA := stack [4]
  24:    MUL                    // regA := regA + regB
  25:    SP3                    // stack [3] := regA
  26:    SP9                    // stack [9] := regA
  27:    LLL  L1920             // regB := regA ; regA := address of Local Label L1920
  29:    K5G   94               // Call function 94, adding 5 to the stack pointer (writef)
  31:     L1                    // regB := regA ; regA := 1
  32:    AP4                    // regA := regA + stack [4] 
  33:    SP4                    // stack [4] := regA
  34:    L10                    // regB := regA ; regA := 10
  35:    JLE  L3                // Jump if <=
  37:     L0                    // regB := regA ; regA := 0
  38:    RTN                    // Return
  40: L1920:                    // The string for writef
  40:  DATAW #x69205A08
  44:  DATAW #x64252073
  48:  DATAW #x0000000A

Now I really haven’t a clue if this is the sort of thing you’re after but I suspect it’s not impossible that a CPU could be created to execute this natively - right now it’s a bytecode that’s fairly easily interpreted on a modern RISC based system (about half the speed of a native C compiler in some very crude tests I’ve done) also able to be interpreted on a hybrid 8/16 bit old CPU too. On ARM with it’s 13 usable registers I can hold all the state for the bytecode VM entirely in those registers. A 68000 should be able to interpret this with relative ease too.

-Gordon

1 Like

C and BCPL don’t have proper lexical scopes while Algol and Pascal do. That means that besides local and global variables, you have local variables of a function inside of which you declared another function. This means you have to reference each variable as a pair: relative lexical level, offset.

The “display registers” in the old Burroughs B5000 family and many software runtime implementations form a kind of tiny stack of pointers into the various stack frames.

That was the word I was looking for.
I say keep goto and get rid of proper lexical scopes.
(The same could be said for sets and objects)
They all look as good ideas on paper or with computer science concepts,
but are they useful in real world programming as of 1980’s.
Punched cards,Word processing and spreadsheets and having cp/m is what I remember from back then, not Pascal.
Computer hardware has changed so much that I have not studied any new stuff since then. C keeps changing too fast for me. Hardware is more complex and less documented.
People I think are going retro because you don’t need a PHD to under stand
the older stuff. I know ,I have a hard time with modern stuff because it is too hard remember all the details.