To: Only to Retro-Comp users of RCBus for Motorola 68000-Family CPU's Only

[Harry S. Speer]

=================================================================================== 

        

   17:28, 5:28 PM, Monday, July 27th, 2026 

   To: Only to Retro-Comp users of RCBus for Motorola 68000-Family CPU's 

     

   To All -

   I am working on a proposed "RCBus-68k" "standard", 

   strictly for use with Motorola 68000-Family CPU's, 

   and for peripheral cards using either MC6800 family 

   8-bit chips - EG: 68B50 UART - and for using peripheral 

   cards using the MC68000 family of chips like the 

   MC68681 DUART, MC68230 PI/T, MC68901 MFP, etc. on 

   RCBus Cards and Backplanes. 

    

   This concept is  ONLY  for RCBus users of Motorola 68000-family

   CPU's with MC6800 / mc68000 peripheral cards using Motorola chips. 

   

   This proposal DOES NOT affect the current RCBus-80 standard for

   use with Intel & Zilog CPU's and peripheral chips, Little-Endian.

    

   This new proposed "RCBus-68k" would be a Big-Endian Bus whereas

   the current RCBus-80 is a Little-Endian Bus. See this 

   wikipedia page for more details on "Endian" here: 

   https://en.wikipedia.org/wiki/Endianness

    

   My idea is to have a separate RCBus-68k specification  

   that is strictly regarding how to use the RCBus Cards and 

   Backplanes with Motorola CPU's & Peripheral Chips. 

   MC68k CPU Cards and MC6800 & MC68000 family of peripheral 

   chips on RCBus cards. 

     

   Why is this worth talking about ???  Say What ?? 

    

   We have already run into some problems as to how different

   builders are coming up with different ways of using the 

   RCBus that are incompatible with one another. 

     

   Examples: Mark Durham has his cards where he is using the 

   68000 CPU with address lines mapping 68000 Address Line A1 

   to the RCBus Address Line A0, RCBus Pin 16 on the 80-pins 

   RCBus. 

            

   Please See attached a copy of Mark's PDF from his 

   GitHub webpage. This PDF may not be up-to-date as

   the PDF on his webpage does not have a matching 

   version number. 

   https://github.com/MarkD833/RCBUS-68xxx

    

   Whereas I am working on a 68008 CPU Card that would map 

   the 68008 Address Line A0 to the RCBus Address Line A0, 

   pin 16 on the RCBus 80-pins Cards and Backplane. 

    

   Also, Mark's specs shows an /UDS - Upper Data Strobe 

   on RCBus Pin 42 and /LDS - Lower Data Strobe on RCBus 

   Pin 43. However the 68008 only has ONE [1] /DS Data

   Strobe, since it is always reading and writing Only 

   One Byte at a time. 

     

   By mapping the 68008 /DS to /UDS  or  /DS to /LDS,  

   the 68008 CPU would only be able to read & write HALF 

   of the memory chips - One Byte - of a 16-bit memory 

   card, on Mark's ROM+RAM card, for example.     

   So we see inconsistencies causing problems right away.

    

   For now, I will continue to work on creating a 68008 

   SBC that handles the RCBus one byte at a time, But I

   cannot use Mark's ROM+RAM card without modifications

   to make the card work with only one byte at a time. 

    

   There may end up being problems with IO cards too,

   but I have not yet gotten that far. 

    

   Also very important is that RCBus is a missing "Bus Width" 

   Indicator, Possibly coming from the CPU Card, that tells the  

   other cards whether the CPU is reading or writing an 8-bit Byte 

   or if it is reading or writing a 16-bit Word.  Huge Problem. 

   

   Something like +8-Bits / -16-Bits or (+Eight / -Sixteen). 

   I think this is needed and I don't see this issue as being

   addressed in the current RCBus-80 specifications.  

      

   I am planning and designing my own use of the RCBus

   in my own way, for the 68008 CPU, but sadly this means 

   that I may not be able to easily adapt one of Mark's  

   RCBus cards, which he has generously provided. I might be 

   able to make patches to his cards - bodge wires - or 

   possibly add-on logic chips, likely held on by hot-glue 

   or epoxy.    

    

   I welcome people's thoughts, feelings, ideas, proposals,

   and so on. I think the more we hash this out now, the better

   off we shall be in the future. 

                 

   For comparison, see how the S-100 Bus handled 8-bit

   Reads and Writes and also how they handled the 

   16-bit reads and writes, in the S-100 IEEE-696 Bus

   circa 1983. See attached a copy of the IEEE-696 PDF.    

   

   Regards, 

   Harry S. Speer

   cc: self, Mark Durham, Steve Cousins

   Attached 1. RCBus-68000 Mark Durham

   Attached 2. IEEE-696 S-100 Bus Specifications

   

==========================================================================   

[Alan Cox]

Endianness is irrelevant. There's nothing where endianness matters and it's always possible to swap bytes in software. The choice of A0 or A1 mapping for the low pin also really doesn't matter. It just moves the address of things
about which is fine and a software issue. Whatever works for a given system,
the I/O cards don't need to know - and that's the bit that matters.

M1 - you may need 2k2 if there are TTL devices in use.

Shouldn't need nAS - you have all the bits for that on the existing bus signals
if a card needed it for some reason it can calculate it.

UDS/LDS agree this isn't covered - but really a scheme that reflects 8086 as well would be useful. The only current 16bit wide build using 16bit data is the TMS9900 which indeed only does 16bit transactions. It's one of the things rcbus has never really addressed.

R/nW - should be in the same place as on the 6800 appendix as it's the same signal, likewise expose the E clock so 68xx and 65xx parts work unmodified on the same pins. You'd still need a way to generate the 6800 v 68000 bus VPA etc but thats trivially done on the CPU card by using two different memory ranges.

BUSACK and DTACK are very different things. You also don't need to put \DTACK on the bus as you can generate it on the CPU card either directly (anything below about 20MHz probably just wire it to ground) or you can use the existing wait signals to hold off an immediate DTACK and probably get the few cards that use it to work without any changes being needed. Even in S100 days 68K CPU cards generally just had DTACK configurable for ranges in number of clocks delay.

CS0 and CS1 on the 68302 and similar are really just address pins as far as the bus is concerned (or MREQ/IORQ depending how you look at or use them)

So I would suggest you actually put

37: One of your IRQ lines (it's used as FIRQ on 6502/680x and some other cards support INT1 on it - eg the Z180/Z280, 16x50 cards)

38: E clock (as per 650x/680x cards)

39: RW (as per 650x/680x cards)

That means all the 680x/650x cards will work if you have an address range for I/O on the CPU card that triggers 6800 compatibility. That means stuff like the 6522 VIA will just work

For interrupts
- The mapping of specific pins to the specific interrupt lines makes no sense
except that \INT7 and \NMI are obviously the same basic thing

- The existing boards generally just map \INT from the RCBUS to an autovector interrupt. As they tend to have multiple card slots on the CPU card they can just wire different slots to different lines anyway.

In other words the bus spec as such shouldn't be specifying which interrupt
line goes where or vectoring standard interrupts. As far as the I/O devices are concerned an rcbus slot has an interrupt and maybe an NMI. The rest is non portable magic on the CPU card or belongs on the user pins. This is doubly true when you consider the 68008 has only \IPL0 and \IPL2. That's why the current system really thinks of an interrupt from the I/O device end. It's a pin you waggle to indicate you want an interrupt. How it is mapped is entirely not its problem. That was something S100 got wrong IMHO.

Actually doing vectored interrupts is a mess. I ended up fudging this on the 801C86 card rather than tackle it, and similarly the 80C85 CPU card carefully uses a non vectored/IM0 interrupt line to avoid the hassle. So no particular opinion there. Z80 indicates it using the MREQ/IORQ/M1 state so the information is actually present on the standard rcbus and you could even emulate the signal but I'm not sure it's worth the hassle faking that.

Alan

[Dennis Burke]

I'd like to point out that on the 68000 the LDS is effectively A0. Adopting this thinking maintains more of the RCBus sensibility. Yes, you can always 'fix' things in software, but you shouldn't break them in hardware necessitating a software 'fix'. The RCBus spec stopped short on the 16-bit implementation details, recognizing the array of approaches, 6800, 8086, 9900, etc. You are constrained by real-estate making it unattractive to homogenize the bus to support multiple processors. My only issue with Durham's solution is how he dealt with DTACK. Granted, in a self-contained way, this is a non-issue, however, it makes the use of boards not designed/built to his spec 'difficult'.

--
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/CAK9X0%2Bsi2h4dOM%2Bz15j%3DpB-%3DPG7Sqg%3D1BxojiLXo4twCx3g7CQ%40mail.gmail.com.

[Alan Cox]

On Tue, 28 Jul 2026 at 19:43, Dennis Burke <den...@burkescience.com> wrote:

I'd like to point out that on the 68000 the LDS is effectively A0. Adopting this thinking maintains more of the RCBus sensibility. 

That's a very good approach for byte sized transfers. I agree entirely. And for a 16bit memory interface it can be decoded as LDS.

Alan

[Harry S. Speer]

===================================================================   

   19:45, 7:45 PM, Tuesday, July 28th, 2026

   Re: [retro-comp] To: Retro-Comp RCBus Motorola 68000-Family  

   

   Alan, You raised some good points.         

   Yes, On M1 having a 2k2  Pull-Up Resistor on the CPU board,

   on RCBus Pin 19. 

   Moving R/nW or +RD/-WRT or +READ/-WRITE away from the 

   current RCBus Pin 44 would break cards that are currently 

   working. I think that it is best left where it is now. 

        

   In regards to the 68000's "Compatibility Layer" for the  

   use of old MC6800 peripheral chips: "E" Clock, /VMA, /VPA.

   I suggest Pin 59 = /VPA    and 

             Pin 60 = /VMA    and 

             Pin 61 = "E" Clock from the 68000 CPU.   

   Put the "E" Clock on Pin 61, was "Clock2" on RC2014. 

   Note: The "E" Clock is 1/10th of the CPU Clock,

   thus a 10 MHz 68000 CPU Clock provides an "E" clock 

   at 1 MHz.  Also, the "E" clock has a 60/40 duty 

   cycle = 6 Clock ticks Low, 4 Clock ticks High. 

   Examples of the MC6800 Family chips include the 

   MC68B50 single UART and the MC68B45 CRT Controller.

   The "B" is for chips capable of running at 2 MHz.

   Probably better to use the faster "B" chips in 

   case the main CPU clock goes above 10 MHz. 
    

   

   As for /DTACK, it is where it is and moving it to a 

   different pin would break cards that are currently 

   working. In fact, that is a summary of most of the 

   signals that are "in the wrong place" / "On the wrong

   pin".  Moving any of them breaks cards that are working.

         

   Which pin is used for what signal on the RCBus-68000 

   was decided by Mark Durham. His cards are, currently,

   working. It might have been nice to be able to talk 

   about what goes where ahead of time but "Oh Well". 

    

   I have several of Mark's "Series 1" cards which he 

   kindly shipped me. Once I get the 68008 working, I can

   look at using them.  

    

   Please see attached a copy of Mark's spec's - Version 1.2 

   as of March 28th, 2026. He may have updated them since 

   then. I looked on his GitHub webpage: 

   

   https://github.com/MarkD833/RCBUS-68xxx/blob/main/RCBus-68000-Pinout.pdf

    

   While I am working on my 68008 SBC set, I will go ahead and

   implement Pin 61 = "E" Clock, Pin 60 = /VMA, & Pin 59 = /VPA 

   then build a Single UART 68B50 card and see if it works as 

   it should. We shall see. Also one of his ROM+RAM cards and

   a 68681 DUART card. See if I can get all of those working.

   The 68008 SBC will just be the MC68008 CPU, 512k x 8 Flash  

   as an EEPROM, a 512k x 8 SRAM, a 68681 DUART, and a  

   MAX249CQH PLCC-44 for TTL to RS-232 conversion with just 

   the +5V and Ground.  No +12v, -12V Required. 
   

   Well that's about it for now. 

   Tell me what you think.

   Harry     

===============================================================

[Mark T]

Is the plan to be able to use some of the existing modules designed for RCBUS-z80 on a bus driven by the 68k SBC?

I assume any module with z80 peripherals are eliminated.

From what remains, what could be used with the 68k without modifications?

It seems the proposal also eliminates the 68B50 module and not even Steve’s SC610 which has links to support E from the bus.

Should /IORQ be generated from inverse of E and use VPA cycles for all input/output?

[Mark Durham]

Just to chip in here, I came up with my RCBus-80 pinout with the intention of being compatible with as many non-Zilog chipped boards as possible. My 68000 design(s) have two windows in the memory space that activate /MREQ and /IORQ. The 68000 card generates an on-board /DTACK for these accesses.

My testing so far has worked with Steve Cousin's SC129, SC145, SC611, SC704, SC705 and SC729 boards.

I can also drive Shiela Dixons TMSEMU TMS9918A video board and Dean Nethertons HDMI for RC video board.

If there's another existing RCBus-80 68K design out there then I'm happy to change my signal mapping to be compatible with it.

Mark.

[Alan Cox]

On Wed, 29 Jul 2026 at 08:10, Mark Durham <mark...@gmail.com> wrote:

Just to chip in here, I came up with my RCBus-80 pinout with the intention of being compatible with as many non-Zilog chipped boards as possible. My 68000 design(s) have two windows in the memory space that activate /MREQ and /IORQ. The 68000 card generates an on-board /DTACK for these accesses.

My testing so far has worked with Steve Cousin's SC129, SC145, SC611, SC704, SC705 and SC729 boards.

I can also drive Shiela Dixons TMSEMU TMS9918A video board and Dean Nethertons HDMI for RC video board.

If there's another existing RCBus-80 68K design out there then I'm happy to change my signal mapping to be compatible with it.

The only one I know about is the 68008 card I did, and it just uses the standard 40 pin connector and doesn't do anything clever at all. no DTACK on the bus, I/O etc mapped to 8080 style bus signals, M1 pulled high, autovectored interrupt.

 

For the 6800 mode signals however the use and position of E and RW have been in the rcbus document since the start and in use since 2017 on the actual 6502, 65C816, 6303/6803, 6808, 6809, 68HC11 cards  so they are kind of set in stone, and as the 6800/6502 based cards are 8bit they are pretty much all 40pin.

If you have a 6800 style I/O space then the assignment will matter. If you are just driving Z80 compatible cards then it won't.

Alan

[Mark T]

I liked the suggestion to use LDS in place of A0 so I started looking a bit closer. I think this would mean that in order to access any odd numbered addresses the 8bit data between the RCBus modules and the cpu would need to be swapped from D0-7 to D8-15. 

Mark Durham’s approach shifting the address bus seems like a better method. It just means all z80 bus addresses are multiplied by two.

[7alken]

hi all, pls in relation to 68k, as I am playing with dragonballs, one thing where I scratche my head deeply... dragonball has UWE LWE, probably expecting only 2 (8bit) chip srams, so there was appnote for 16bit sram and they recreated the full uds/lds/rw  logic using 7408 and 7404...  
https://www.nxp.jp/docs/en/application-note/MC68EZ328SRAM16.pdf

I obviously dont know 68k bus, but for simple 16bit sram, when I peeked into schematic I think that single 7408 is enough... or am I wrong ??
P.

[Mark T]

It looks like that circuit is needed to drive UB and LB for read from the sram. You would need to read the sram spec to be certain.

[Harry Speer]

============================================

09:40,  9:40 AM,  Friday,  July  31st,  2026

Re: The RCBus Specification has 6800 and 6500 specs

All - 

Alan raises valid points - that there are RCBus Specs for 6800 

and 6500 chip interface - Already Existing in the Spec's Document.

I have my copy here and I will dive in and search those out.

Also, Mark Durham has expressed a willingness to change the pins

he uses for the RCBus 68000 cards.  If we agree on a new set of 

active pins, then Mark will have to setup a "Series 3 Boards" with

the new pins. Or At least I assume that he will. 

And I will integrate them into mine.

So I will dive into the document to see which pins go where per 

the specs. Having derived that, I can post new info here.

My thanks to Alan for raising this issue now instead of after 

I started soldering cards.  "An Ounce of Prevention ......".

Harry

====================================================

[Mark Durham]

I think the big question is what boards the end user wants in their system. The current RCBus spec shows pins 37-40, 42, 43 & 77-80 as having different functions depending on the type of processor being used which will determine the interoperability with the numerous boards out there.

 

My introduction to retro computing was via several of Steve Cousins boards (SC104 & SC108) and a few I/O boards (SC129 & SC145 etc) before I set off on my 680x0 voyage. I designed my own processor, memory, serial and parallel cards whilst trying to stick to as much of the RCBus spec as I could so that I could also read and write to Z80 memory space (via /MREQ) and I/O space (via /IORQ) boards. As it happens, all the existing boards I've chosen to experiment with live in I/O space

I didn't set out to interface with any 68xx boards as my design goal was to have a small 68000 system that could interface with several of Steve's SCxxx generic I/O boards. I decided to use pins 37-40 and 77-80 for interrupt and interrupt acknowledge signals which will conflict with signals for the 68xx or TMS9995 boards.

To quote the RCBus Spec introduction, "This guide therefore should be considered as a reference, not as law. Developers are positively encouraged to use the bus in innovative and bizarre ways."

Mark.

[Bill Shen]

I used CPLD programmable logic extensively in my retro designs.  One benefit of CPLD is bus interface can be redefined so the same board can work with different CPU family by change the CPLD equations.  An early example of this concept was G8PP (generic 8-bit processor prototype) that used the same physical baseboard to accommodate Z80, 6502, 8085, 6809, and 68008 by changing control signals in CPLD for the particular CPU.  The bus was classic 40-pin RC2014.  I continued this concept for several I/O boards based on the classic RC2014 bus such as quad-serial board and text-based VGA/PS2 board.  They were designed to work with Zx80, 6502, and 680x0 processors.  So instead of defining a bus with fixed signals, why not define a bus with fixed data/addresses but programmable controls plus a few user defined pins?

Bill

[Mark T]

For a bizarre way, how about a 68k board with two separate 8 bit RCBus backplanes. One to the right using LDS and one to the left using UDS. Then you can use existing memory cards. To allow for 16bit modules the one on the right could be 16 bit and include UDS control signals.

[Harry S. Speer]

=======================================================

   

   19:43, 7:43 PM, Friday, July 31st, 2026 

   Re: 68000 - Changing Signals and Pins on RCBus  

   

   As I said previously, My concern is / was that 

   "Moving (lines pins) would break cards that are 

   currently working".  

         

   And Now Mark has confirmed this, saying 

   "I decided to use pins 37-40 and 77-80 for interrupt and 

         interrupt acknowledge signals which will conflict with 

         signals for the 68xx or TMS9995 boards". 

     

   My knowledge of which signals are on which pins

   is limited so I could not quote specifics.  

     

   I have been doing my own SBC work and following

   the use of signals on pins that Mark had already

   created cards for. Mark blazed the trail and I am

   very much "following in his foot steps" here.

     

   Only difference is Mark's 68008 CPU Card never  

   made it to the "publishing" stage. Thus with  

   my 68008 SBC I am partly also following in 

   Alan's .aka. "Etched-Pixels", foot steps 

   with his 68008 CPU design. 

          

    I was also concerned specifically that the free 

    blank "Series 1 Boards" that Mark has 

   generously sent me might "break" with any 

   changes.  Apparently the Series 1 *might*

   not break with the changes, but Mark later  

   expanded the use of pins for interrupts 

   and IACK signals in his "Series 2 Boards" 

   with Vectored Interrupts.  

    

   So it's a toss-up since moving lines might

   break Mark's working 68k cards. 

   

   And here is a Very Pertinent question: 

   "Are there any RCBus Cards already in existence,

   which are actually assembled and working Now,

   which became "broken" because of Mark's 68k 

   Cards' Signal & Pin Choices ???"  Or is this 

   a purely hypothetical situation ??    

        

   I have "lurked" for years on the RC2014

   groups and on the Retro-Comp Group, and 

   specifically the RCBus posts in Retro-Comp.

   Reading, but not posting, as an observer.

    

   And I have  NOT  seen anyone other than Mark

   and very few others about cards that used 6500

   chips or 6800 chips, other than the Long-Lived

   68B50 Single UART Card, and Alan's 68008. 

    

   Have I missed something ??  Who else has been

   making these Cards ??  Alan posted about his 

   68008 CPU card that he seems to have abandoned

   in a "partially working" state.  I have looked 

   at one schematic of Alan's card but I did not

   glean much helpful info that I might include

   in my own 68008 CPU Card for RCBus-68k.    

    

   Mark mentions the "TMS9995 boards" and I am

   wanting to ask " Mark - Do any of your own cards

   interfere in any way with the RCBus Video cards

   you have tested ??  (I seem to recall you mentioning

   2 of them but that is the limit of my recall).              

   How well did your 68000-series cards work with those

   2 video cards ???  Were there any adverse interactions ???

    

   More questions than answers here. Perhaps 

   someone here can answer ?? 

    

   Regards,

   Harry       

=====================================================

On 7/31/26 10:45, Mark Durham wrote:

I think the big question is what boards the end user wants 

in their system. The current RCBus spec shows 

pins 37-40, 42, 43 & 77-80 as having different functions 

depending on the type of processor being used which 

will determine the interoperability with the numerous 

boards out there.

 

My introduction to retro computing was via several 

of Steve Cousins boards (SC104 & SC108) and 

a few I/O boards (SC129 & SC145 etc) before I set off 

on my 680x0 voyage.   I designed my own processor, memory, 

serial and parallel cards whilst trying to stick to as much 

of the RCBus spec as I could so that I could also read and 

write to Z80 memory space (via /MREQ) and

 I/O space (via /IORQ) boards. As it happens, all the existing 

boards I've chosen to experiment with live in I/O space. 

I didn't set out to interface with any 68xx boards as my 

design goal was to have a small 68000 system that could 

interface with several of Steve's SCxxx generic I/O boards. 

I decided to use pins 37-40 and 77-80 for interrupt and 

interrupt acknowledge signals which will conflict with 

signals for the 68xx or TMS9995 boards.

To quote the RCBus Spec introduction, 

"This guide therefore should be considered as a reference, not as law. 

Developers are positively encouraged to use the bus in innovative and 

bizarre ways."

Mark.

=====================================================

--
You received this message because you are subscribed to a topic in the Google Groups "retro-comp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/retro-comp/9Od6yaDga24/unsubscribe.
To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/3bd95666-2871-4396-acc8-fcecf97971a1n%40googlegroups.com.

[Mark Durham]

Harry,

There will be several boards out there that will not work with my choice of pin signal assignments

The boards designed for the 68xx processor probably won't work as they use some pins that I chose for my interrupts.

Some of the Z80 peripheral boards that use the IEI and IEO signals for interrupt priority won't work. That's not really an issue for me as for my 680x0 designs I didn't intend to support any Zilog chips (SIO, PIO, CTC & KIO). My 680x0 designs don't really need to support those devices as there are similar devices specifically for the 68k.

Regarding video, I've been using Shiela Dixon's TMSEMU (TMS9918A emulator) and Dean Netherton's HDMI for RC boards. Both only require D0-D7, A0-A7, /RD, /WR and /IORQ. Dean's board also uses the /INT signal on pin 22.

Do you need to support 68xx boards/devices? If so, then you need to design your processor card accordingly.

Mark.

[Harry Speer]

01:17,   1:17 AM,   Saturday,   August   1st,   2026

Re: [retro-comp] To: RCBus-68k  - Interface to Motorola 6800 Family Cards

I suggest that the interface between the 68k CPU Card or 68008 CPU Card 

should have the "E" Clock on RCBus-80 pin 61 ,  the /VMA on pin 60, 

and /VPA on pin 59.  Anyone dislike this ??  Put them elsewhere  ???

These three should be able to allow communication between the CPU Card and

any Memory-Mapped IO Chips on Cards - Serial Cards using MC68B50, and

Video Cards with MC68B45, and so forth.  

"E",  /VPA,  /VMA - are the three control signals from the CPU to a Card.

Pins 59, 60, and 61 should be there, unless someone wants them 

elsewhere ??

Harry
================================================================

[Alan Cox]

On Sat, 1 Aug 2026 at 09:17, Harry Speer <h.s....@gmail.com> wrote:

01:17,   1:17 AM,   Saturday,   August   1st,   2026

Re: [retro-comp] To: RCBus-68k  - Interface to Motorola 6800 Family Cards

I suggest that the interface between the 68k CPU Card or 68008 CPU Card 

should have the "E" Clock on RCBus-80 pin 61 ,  the /VMA on pin 60, 

and /VPA on pin 59.  Anyone dislike this ??  Put them elsewhere  ???

These three should be able to allow communication between the CPU Card and

any Memory-Mapped IO Chips on Cards - Serial Cards using MC68B50, and

Video Cards with MC68B45, and so forth.  

"E",  /VPA,  /VMA - are the three control signals from the CPU to a Card.

Pins 59, 60, and 61 should be there, unless someone wants them 

elsewhere ??

It depends what you are trying to achieve. If you want to run a 6845,  6821, 6840, 6522 etc on a 68000 CPU card then you want to put the lines in the same places as the existing 6502, 65C816, 6303/803, 6809, 68HC11 cards have put them for almost a decade, and you want to select the 6800 style bus cycles transparently via a range on the CPU card. Those cards are not going to move pins since they've existed for many years and also are generally 40 pin cards as it's an 8bit processor.

Thinking about it from the CPU end is really the wrong way around. CPU cards do all the magic in order to be compatible with the I/O devices, so the question is really "what cards do you want to be able to share with other processors".

My 68008 card doesn't implement the 6800 bus cycle support so I don't use those pins at all because it simply didn't matter. All the I/O I wanted is on standard rcbus cards anyway. Since then I've not worried about it at all because Bill did rather nicer 68000 based hardware and I've got several of his boards that just use rcbus as an I/O bus or have the I/O onboard.

So the real question is this - does your 68K board want to be able to use 8bit motorola bus cards that do not (or in some cases cannot) be mapped to the Z80 style bus properly. The 6850 can be glued to a Z80 bus so the E clock etc doesn't matter anyway. The 6522 needs the E clock really as do the 6821 and 6840. Do you need any of them or would you be using a 68230 or 68681 instead ?

The 6845 won't work easily with the 68000 over something like rcbus because you need to share memory and you need to do bus arbitration between the two. It will with a 6545 as it supports accessing non shared video RAM via an I/O interface but then you'd still want a custom card because you'll want a 16bit wide data path in order to do VGA speed. All the classic 68xx video chips rely upon the fact that the CPU accesses the bus on the other half of a 6800 E cycle so the 6845, 6847, 6883 all relied upon that behaviour. To use them with anything else without a lot of flicker problems you need to handle a clock domain crossing either with dual port RAM or a bunch of latches and muxes.

The non shared memory video is going to work fine either way - at least the TMS99xx stuff will, and the EF9845 should be fine. The propeller card you'll need to correctly respond to the Z80 style wait requests or stick delay loops in the right place.

Personally I'd stick E and RW where they are on the existing 68xx cards if you provide them and I'd put a second interrupt the same place everyone else has if you care about it. But it's ultimately about compatibility with a particular small set of peripheral cards.

Where you stick 68K specific lines I don't think matters as nobody else will use them but the 68K.

UDS/LDS definitely could do with an agreed behaviour and pinning so that things like 80186 become possible as well as the current 80188 cards, assuming more folks want to run stuff like DOS on rcbus ;)

Alan

[Mark T]

I’d also vote in favour of using the same assignment as 68xx for FIRQ, E, and R/W.

I think we could use FC0 - M1, FC1 - Rfsh, and FC2 - Page, which should be ok for input output modules requiring M1 pulled high.

[Mark T]

For the 68k 16bit bus processors we could use a common RD signal for all read cycles, for byte reads the processor ignores data on the unwanted 8 bits. The existing WR could be used as LWR and then a separate UWR on some other pin to be decided.

The common RD signal might be an issue if byte input/output modules are included on the high byte, but I think this can be avoided. There should be no issue for 16 bit input/output, if there are any.

Would this work for non-68k 16 bit processors?

[Alan Cox]

On Sat, 1 Aug 2026 at 16:52, Mark T <mark...@gmail.com> wrote:

I’d also vote in favour of using the same assignment as 68xx for FIRQ, E, and R/W.

I think we could use FC0 - M1, FC1 - Rfsh, and FC2 - Page, which should be ok for input output modules requiring M1 pulled high.

I'm not aware of any hardware using RFSH, page is used for 8bit wide ROM cards and I can't see anyone using that either on a 68K. M1 is used in odd ways on the Z80 PIO card but it's not something you'd use with a 68K or would work easily with one.

What you need to avoid though is M1 low and IORQ low because that will cause some peripherals to put an interrupt vector on the bus that you really probably don't want there. In theory you can map the FC0/1/2 high into a Z80 IM2 vector fetch but I am not sure that's actually useful or that the timing works.

FC2 in general is also useful because it's "supervisor" and that's a concept that translates to other processors too for memory management cards and the like.

Alan

[Mark T]

FC0 is low for program fetch so unless you try and execute code from IORQ there should be no problem with interupt vectors. Its unlikely that any z80 peripherals are going to work anyway.

FC2 on Page might be usefull to switch memory between user and system but would need some mods on the memory modules to provide ram in system mode and there needs to be some way for system mode to access user memory. I don’t think Page is used on any of the flat memory modules so it shouldn’t cause any problems.

FC1 on RFSH, as you said, I’m not aware of any module ever using this signal, maybe only something trying to implement ZX80/81 type display.

I think separate memory modules could be used for high and low bytes. Maybe a separate section of backplane or modify the modules data pins to connect to the second row on the backplane. The high byte memory module would need a different write enable but thats only one link or wire mod.