RCBus-68000 Some progress at last

[Mark Durham]

I've been wanting to attempt to put together an RCBus Motorola 68000 system for a while now and after some success with the prototype set of boards, I'm at the point where I'm just about confident enough to share my creation(s)!  I've made a few changes since the prototype boards such that my next set of boards are a bit more "acceptable" as can be seen in the photo (SC729 in the background):

Now, I need to caveat all this by saying that I'm not a hardware designer by any means and there may well be issues with my design that will come back to bite me in the ass.

There are 5 board designs that I've been playing with - the processor, memory and serial i/o can be seen in the photo above. The parallel i/o and a multifunction boards both need building.

The processor board hosts a 68000 and supports autovector interrupts, bus error generation as well as DTACK generation for the RCBus Mem and I/O spaces. There are no programmable logic devices used.

The memory board provides 128K of ROM using a pair of W27C512 EEPROMs and 1M of RAM using a pair of AS6C4008 RAM chips. The ROM is fixed at address $0000.

The serial i/o board hosts a pair of 68681 DUARTs providing 4 serial ports. The parallel i/o board hosts a pair of 68230 PI/Ts providing digital i/o and 2 timers. The multifunction board hosts a pair of 68901 MFPs. These boards are accessed via normal 68000 memory space - not RCBus i/o space.

In order to generate some confidence in my setup, I've been experimenting with some of Steve Cousins boards with a better than expected degree of success.

• The SC129 basic digital i/o board works as expected.
• The SC145 & SC729 CompactFlash boards are both working with a ROM version of CP/M-68K v1.3.
• The SC611 MicroSD board is working with a 25LC256 EEPROM as the SPI test device.
• The SC704 I2C bus master board is working and can detect the SC402, SC403 & SC406 devices with an I2C scan.
• The SC705 ACIA board appears to have basic serial functionality too.

On the software side, I have a simple ROM monitor running that can load and execute S-records, run CP/M-68K direct from ROM and run EhBASIC direct from ROM as well.

I've recently purchased a TMSEMU video board from Sheila Dixon to have a play with to see if I can add video functionality to my setup.

My next step is to build and test the parallel i/o and multifunction boards and then setup a GCC 68K environment on my PC to develop code in C.

Hopefully, attached are the schematics for each of the boards in case there's interest along with the RCBus-80 pin assignments which, with the limited RCBus experience that I have, hopefully don't cause too many clashes with other existing designs.

Any feedback is appreciated, good or bad, as I'm fairly new to the RCBus ecosystem.

Mark.

[Ronny Ribeiro]

Wow! Congratulations, Mark!

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/b2afc284-172f-4dd4-94f1-3cffc1d5c3c8n%40googlegroups.com.

[Steve Cousins]

Hi Mark

Great work. You may not consider yourself a hardware designer but you could fool me.

A few observations....

Your RCBus pinout drawing says:

"Note #1 : Pin 19 (nM1) unconnected or pulled up to +5V via 4K7 resistor on CPU card."
I can't see any sign of a connection on the CPU module so I assume M1 is floating. M1 is required to be high during read and write to SC729 and SC705, so I'm surprised they work reliably. SC129, SC145, SC611 and SC704 should be fine without M1 connected. Many RCBus modules require M1 to be high during read and write.

For 68xx systems the RCBus specification recommends pin 39 be used for R/W and pin 38 for the E. I know these pins have multiple potential functions, so using them seems like it may be problematic. That is why my RCBus 80-pin backplanes have jumpers to isolate these signals between modules. I don't think your choices of pins will cause conflicts with many (if any) modules, but it may limit compatibility at some point. Perhaps you have good reasons for your choices here.

Sheila's TMSEMU module is a great module. Good choice for support in your system.

Connecting TX and RX signals to the bus would allow the TMSEMU module to act as a terminal. Again, my RCBus 80-pin backplanes have jumpers to isolate these signals between modules. In this case they allow a terminal module to be left connected while using the serial port for something else.

This is a really nice project.

Steve

[Mark Durham]

Both, thank you for your encouraging comments.

Steve,

Good spot on the M1 signal. I'll add a 4K7 pullup to the CPU board and note the omission so it gets included in the next revision.

The next revision of the SIO board will hopefully include jumpers to optionally route Serial #1 to TX & RX and Serial #2 to TX2 & RX2, but for now I'll just run a couple of wire links to TX & RX to allow experimentation with Sheila's TMSEMU board.

I also need to slightly reduce the width of the RCBus-80 medium board footprint in my Kicad library so that the board size falls into the cheap category at JLCPCB.   

Mark.

[Mark T]

The size limit for jlcpcb was 102.4mm, rounded down to 102 by their online quote, though they may have changed it recently.

[Mark Durham]

Thanks Mark.

[Mark T]

I should probably mention that 102.4mm does not fit the low cost offers from other pcb manufacturers, so if you use 102.4 you won’t get the cheap price from the other suppliers.

Allpcb seems to give low cost for 150x100, but only in green and don’t have a cheaper option for shipping. It might be worth checking if you need a larger board.

On Thursday, May 15, 2025 at 11:53:07 AM UTC-4 mark...@gmail.com wrote:

Thanks Mark.

[Alan Cox]

Nice - I never felt confident enough to try doing that with 16bit width and rcbus.

With the 68008 board the only compat problems I hit were with the Zilog specific parts as with all processors even though the 68000 timings to the CF are differently wrong to the Z80 ones, and I didn't even bother with DTACK and wait state support.

When it comes to trying to get gcc work be aware that

- The "m68k gcc" shipped with several Linux distributions supposedly to a uclinux configuration is broken and has been for years

- The standard gcc and binutils for 68K is also broken for some configuration options

https://github.com/EtchedPixels/FUZIX/blob/master/README.68000.md

for the binutils I think it breaks if you specify a specific CPU option rather than build for all. The failure case is that it embeds coldfire branch ops in the support library code.

Should be able to run CP/M68K or a Unix clone on that nicely.

[Dave White]

I use Ashware compiler for 68K code. The site says runs under NT and XP, and Windows 7 in compatibility mode, but I run it succesfully under Windows 11 with no special settings.

GNU 68K/Coldfire C/C++ Compiler | ASH WARE

It's an easy install and setup.

[Harry Speer]

Mark - Well Done !!!

[Tom Storey]

I have a m68k gcc toolchain that I've been working on over the years. There's a script to build it on Mac and Linux, and it works just as well under WSL on Windows 10+. 

It has a libc style library with a bunch of familiar functions, although floating point support is still a bit questionable. 

A simple makefile allows building your project and outputting a binary image at the end which can be programmed into a ROM.

You can mix C and assembly source files, and the linker script allows you to easily cater for interrupts and specify ROM and RAM sizes and locations. 

https://github.com/tomstorey/m68k_bare_metal

I've used it for the 68000, 68030, and CPU32 family of processors.

Happy to help answer any questions, and maybe it happens to offer you a solution for building software.

Tom

[Mark Durham]

Tom, nice to hear from you. I discovered your bare metal project a week or so ago and have been making a bit of progress under Win10 without any additional Linux type environment. I did run into an issue which I don't think I can get around - possibly due to my basic knowledge of makefiles but I suspect is a W10 issue.

The issue relates to the build directory when I try and build libmetal. Under W10 it seems that md (or mkdir) can create the required paths but it throws an error if the path exists already. There doesn't seem to be a way to check if the path already exists or a command switch to tell md to not throw an error either. I think the CMD function EXISTS only works on one directory level at a time.

I have a small setup that essentially creates something similar to your libmetal using the source files that came with my ancient book about the Standard C Library.

I think that after a bit of fiddling about I will have a W10 native version of your bare metal configuration.

Mark.

[Mark Durham]

After my issues yesterday trying to build Tom's M68K bare metal suite, I switched to using MSYS2 and the msys64 shell. I'm happy to report that Tom's suite built without any errors and I'm looking forward to tweaking the crt0 and linker script for my RCBus 68000 setup.

[7alken]

very nice :-) here yet another newbie, but I only returned to drawing board, you are far ahead  ... ))

[Mark Durham]

I'm not that far ahead really. I joined this group around 18 months ago and learnt (or maybe that's re-learnt!)  a lot just from reading previous posts. I used to work with some of the 68K family in my old job and wanted to see if it were possible to introduce a 68000 to the RCBus ecosystem. I also got a lot of starter ideas by looking at some of Bill Shen's designs over on the RetroBrew Computers site.

[Ronny Ribeiro]

I'm very interested in this design.

I have a spare MC68HC000 and it would be nice to throw some electrons at it.

I'll be watching this developmet closely.

Thank you, Mark.

Em dom., 18 de mai. de 2025 14:13, Mark Durham <mark...@gmail.com> escreveu:

I'm not that far ahead really. I joined this group around 18 months ago and learnt (or maybe that's re-learnt!)  a lot just from reading previous posts. I used to work with some of the 68K family in my old job and wanted to see if it were possible to introduce a 68000 to the RCBus ecosystem. I also got a lot of starter ideas by looking at some of Bill Shen's designs over on the RetroBrew Computers site.

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/36952c8d-9bf0-4925-a0ad-0cf055fb0b36n%40googlegroups.com.

[Mark Durham]

Ronny, there's a bit more detail over on my github repo that may interest you. There's the basic Kicad files for the 5 boards in the set along with images of 3 of the completed boards (front & rear) - excuse the flux residue as I'm experimenting with cheap at-home ways of cleaning it off. There's also various pieces of assembler code (assemble with EASy68K) for my simple monitor, CPM-68K BIOS and code that I used to interact with the various RCBus boards I've played with.

I'm also not a github expert either so please forgive the layout etc, but hopefully there's something of interest in there for you.

Mark. 

[Ronny Ribeiro]

Thanks for the info, Mark!

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/9af21889-214b-4a06-98ef-fff0488a1a0en%40googlegroups.com.

[Mark Durham]

And some more progress to report:

I've got hold of one of Shiela Dixons TMSEMU RCBus video cards and have successfully ported over some of the examples from J.B. Langstons TMS9918a repository in both assembler and C code.

I've also bagged myself one of Dean Netherton's HDMI video board kits that emulates a Yamaha V9958 VDP. It's currently assembled and is at the 68000 code writing stage.

And, today, I completed some very basic testing of my new RCBus-68302 processor board:

The design negates the need for a separate serial board as it breaks out 2 of the internal Serial Comms Controllers. It also includes a hardware SPI port linked to the internal Serial Communication Port, autovector interrupts and address decoding for the RCBus memory and i/o spaces.