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. 

[Christian Ruelke]

Hi Mark, i have been looking for a 68K design with the possibility to use expansion boards such as RC2014 and CP/M for a long time. Thanks to your efforts i have built up two sets with the CPU, RAM/ROM and serial boards and got this working with CP/M-68K.

For whatever reason the SC729 CF board doesn't work but the compact flash module v2 is fine. 
What i'm struggling is to download any files to the CF Card, i use XM68.REL but only the uploading files to the PC is working fine but downloading stops after a fer bytes sent. I tried it with the SIO and LBE board and other 68681 chips as well, no success.

Is there any other CP/M software or possibility to download files?  

[Mark Durham]

Good to hear that another retro hobbyist has found my boards useful - there's now 3 of us that I know of. The early boards - especially the SIO, PIO & MFP boards - were thrown together without much higher level brain function on my part just to experiment with and see what was possible with each chip. I've got a few more designs in the pipeline that I am hoping to share including a 68000 board with vectored interrupts and a 68020 board that hopefully will use dynamic bus sizing.

I'm not familiar with the "compact flash module v2", having only used Steve Cousins SC145 & SC729 CF interface boards. I'm surprised that the SC729 didn't work for you as Steve's design incorporates a more robust CF interface designed by Tadeusz Pycio. Having said that, there does seem to be the issue that not all CF cards are created equal and that some brands of CF card work more reliably than others. I suspect that I got lucky with the CF cards I had when both the SC145 & SC729 both worked.

Regarding downloading files, I think one of the issues will likely be that MON68K v1.3 didn't do hardware handshaking of the serial port but v1.4 did. However, v1.4 dropped support for CP/M-68K. I had a passing interest in CP/M-68K which is why it got dropped. I may have a look at reinstating it.

I never figured out how to download files onto the CF card via CP/M. There was a version of Kermit - called gKermit I think - that worked. I saw it as part of one of Bill Shen's disk images when he made them available as part of his reverse engineered 68302 board. I think it was all on the RetroBrew Computers website that now seems to have disappeared. The wayback archive has the project home page from the RetroBrew website here. You may get lucky if the associated files were also archived. I didn't really find any documentation on it and failed miserably to transfer any files in either direction - likely due to an incompatibility between the PC version of Kermit and that on the CP/M-68K system - or just my own stupidity! 

I still have an itch to scratch that may indeed reintroduce CP/M-68K in a new release of MON68K as I wanted to see if I could replicate the functionality of the DOWNLOAD.COM program that I think Grant Searle wrote for the Z80 CP/M system. That way the PC based drag and drop packaging utility could be re-used. 

Mark.

[Christian Ruelke]

Thanks for the quick reply and the hints for the CF Cards and to try gKermit. Those boards are very useful for me and a big compliment for designing those and making this available. 

I have built a few ROSCO-M68k and 68K-MBC boards but either programming on the board (ROSCO) was difficult or hardware expansion (MBC) was not easy. The RC2014 platform is ideal

with all those available expansion cards and having now a 68k for it really great!

One more question, i just set up the RAM/ROM Version 2 card with 39SF040's and AS6C4008's but it does not work. Are the 2 20k resistors and wires on the back side needed for the 68000 or just for the 68302?

Thank you so much

Christian 

[Bill Shen]

Definitely agree that not all CF are created equal.  You may want to try CISCO brand of CF disk in the range of 64MB to 512MB.  They are relatively slow and do not generate big ground spike that mess up file transfering.  Gkermit in cpm68k is what I used for file transfer.  Handshake is needed for 68000 at 38400 baud serial port.  You may try lower serial rate if you don’t have hardware handshake function.  I’ve not tried XM68.

Bill

[Mark Durham]

Christian,

I made a silly omission with the ROM/RAM V2 board. Two wire links are needed for the 68000 setup. The links are detailed towards the bottom of the GitHub page for that board. Essentially the ROM /CS and RAM /CS should also go to the LS125 to generate the /DTACK signal back to the 68000. I put a 10K pullup on those signals just in case a bank is left empty.

If you have built the 68302 board, then there are a further 2 wire links needed so that the 68302 /CS0 & /CS1 signals go directly to the Bank #0 and Bank #1 chip select signals. The LS138 and LS125 chips should be removed as they are not required - the 68302 will generate the chip selects and generate /DTACK internally.

Mark.

[Mark Durham]

Christian,

A couple of photos of the ROM/RAM v2 board I'm using.

Rear showing wire links and pull up resistors.

Top view showing jumpers - ROMs are in the left 2 sockets.

I'm using a small left or right handed PCB with a ZIF socket for each ROM which comes in very handy when developing the monitor program.