RCBus compliant designs

[Steve Cousins]

I have 3 designs that I believe fully comply with the RCBus specification.

I know Tadeusz has some designs. Anyone else working on anything?

Steve

[Tadeusz Pycio]

I have two new modules in the pipeline (friends are asking me for a simple computer) CPU+SIO and ROM-RAM 64kB, and I was waiting for the release of the specs to fix my CPU+MMU module, because I made a mistake in the decoder and interrupts in IM2 mode modified the MMU registers. The corrected bugs found in the Z280 will also be released as RCBus. That is, another 4 RCBus modules will be built in the near future.

PS. Interesting designs. I think the SC701 will become the best foundation of RCBus computers available on the market.

[Steve Cousins]

I have another RCBus design nearing completion. SC704 is an I2C bus master module.

[Steve Cousins]

I'm in the process of designing a serial ACIA module that is fully compliant with the RCBus specification. Schematic attached.

My design has these features:

Jumpers for all signals connected to the extensions pins (eg. USER pins)

Jumpers to select ACIA control signals from either the 'minimal' RCBus signals (nIORQ, nWR) or from extension signals (E, RW for RCBus-68xx compatible devices)

Jumper to allow TXD to be connected to TX or TX2

Jumper to allow RXD to be connected to RX or RX2

Jumpers to select onboard oscillator or bus CLK signal as ACIA serial clock source or both (so onboard clock provides CLK signal)

Jumper to select where ACIA interrupt goes (INT or extension pins /INT1 or /INT2 or /FIRQ)

Tight address decoding

I believe this design should work across a range of processors as described in the RCBus specification.

Comments appreciated?

Steve

[Steve Cousins]

Here's the serial ACIA module PCB. It seems that full compliance with the RCBus will often need extra jumpers to allow for the different processor uses of the extension pins.

Steve

[Tadeusz Pycio]

Today I received the PCB with the W65C816 module in the RCBus standard. It is time for a physical verification of the assumptions made.

[Steve Cousins]

I have a few more RCBus designs ready for production.

[Tadeusz Pycio]

Very nice and clear descriptions, documentation will not be required for configuration. I need to improve in this regard.

[Steve Cousins]

First build of two new RCBus designs

[Tadeusz Pycio]

The RCBus family is growing rapidly. :)
I'm in the process of checking out the module and have to wade through the assembler for this processor to run the monitor program, so I'm having a bit of fun.

[Ronny Ribeiro]

Red is the new green for retro :D

--
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 on the web visit https://groups.google.com/d/msgid/retro-comp/39f1ccb5-bab3-4518-a461-c8531d1b0fa6n%40googlegroups.com.

[Tadeusz Pycio]

It occurred to me today that I took too conservative an approach to the design of this module by keeping jumpers for signals specific to this architecture. They are now redundant, I need to pay closer attention that we have a new standard that natively supports these signals. Habit, it is said, is a second nature.

[Bill Shen]

Tadeusz,
I'm curious to see how you interface W65C816 to RCBus.  Can you share the schematic?
  Bill

[Tadeusz Pycio]

Somewhere here on this group there is a thread about this module, the actual schematic on which the physical implementation was created attached.

[Mark T]

Hi Tadeusz,

Did you see this thread on 6502.org? It seems to suggest Clk1 should be from the input of U4a.

Mark

[Tadeusz Pycio]

Did you see this thread on 6502.org? It seems to suggest Clk1 should be from the input of U4a.

Hi Mark,

No, I haven't read it. What thread on 6502.org are you referring to? I followed the datasheet to negate the CPU clock signal (delaying it at the same time), but maybe this is a mistake.

[Alan Cox]

This one does work up to 7.3MHz at least although it's probably not perfect 8)

Pre WDC 6502's are nice to work with , the WDC ones are a pita.

[Mark T]

Sorry, looks like I missed out the link, 

http://forum.6502.org/viewtopic.php?p=75769#p75769

[Tadeusz Pycio]

Hi Mark,

Thank you for this intriguing information, I will check it out as I embrace the basic software for this module. I generally didn't envisage using those extra address lines, I'm using memory from the MMU (Karl's module #65a) because the built-in mechanisms in the processor are inconvenient. There is space left on the PCB so I added this latch, but it would be worth it to make it work too  :-)

[Interocitor Steve]

Hi Steve C.

It has been quite a while.

What is an RCBus?  Is it like the Z50Bus by LiNC (Langseth)?

=Steve.

[Dave White]

Steve,

Take a look here

RCBus Spec. v1.0 | Small Computer Central

[Brad Hines]

Steve,

It appears that you will be offering both Z50Bus and RC Bus products in the near future.  I am curious as to what your recommendation would be for how to adapt a project-in-process to the new technology.

As shown in the photo, I have finished the updates to my 8080A mainboard to allow interface to Z50Bus.  In practice, though, the work I've done so far can be adapted to any of Z50Bus, RC2014, RC Bus.  

As shown in the photo, I bring a 40-pin cable to a SC510 adapter board and then onto the Z50Bus, and then further have a SC517 extension to allow plugging RC2014 cards should I decide to go that route.  I have not yet built up my SC510, but once I do, I'll have started down the road to being tied to Z50Bus.

I have a few options to choose from.

1) Continue on my current path and

   a) Ignore RCBus.  But I'd rather not, because I like some of the new features it has, esp the Bus Ack stuff, or

   b) Assume there will be a Z50Bus to RC Bus backplane module, a la the SC517 (although then the Bus Ack stuff would have to be manually bridged to the RC Bus backplane), or

   c) Assume that there will be a card adapter to convert a Z50Bus card to RC Bus (would be like a short extension riser, would increase height slightly)

 2) Abort the build of my SC510 adapter and abandon my SC513 and instead wait for RC Bus equivalents
 3) Go ahead and build my SC510 and then build a RCBus replacement for it later.

In some ways, 1c would be my ideal, but strikes me as least likely to come to fruition.  (Unless I decided to fab it myself.)  But maybe there are many folks that would find such an adapter useful.

#2 could make sense if you think those items would be ready for prime time soon, although it means that my recent purchase of Z50 backplanes and protocards goes to charity.

#3 could make sense, although I plan to also start building a couple of my own cards and they'd end up being Z50Bus cards.

My inclination, barring any comment, is to go ahead and make my SC510 and a memory card and one device on the Z50Bus, incorporating the SC513 as a permanent part of my system, and assume that a SC517-like Z50Bus-to-RC Bus adapter will appear at some point.  I could then manually jumper the BusAck chain to the RC Bus backplane.

Any advice?

Thanks,

Brad

[Steve Cousins]

Hi Brad,

That's a great project and you've raised an important question.

It is my plan to continue developing Z50Bus designs. I really like the Z50Bus. The standard size cards are big enough to fit, for example, a Z180 SBC (eg. SC503) which means less cards, greater reliability, lower cost, and no need to bring out some of the design specific extra signals to the bus, such as A16 to A20, and SPI for SD cards etc. The biggest advantage though, for me personally, is the ease of removing cards from backplanes. The short bus connector leaves room to get your finger tips under the PCB to wiggle the card out of the socket. I can't say enough how much nicer that is than enhanced bus RC2014 modules and now also the RCBus modules. The Z50Bus does not however have BAI/BAO and only has a few user pins to add any extra functions you may need. I don't think the BAI/BAO is a big issue as I doubt many people will use them and you can add flying leads if absolutely necessary.

If there are enough cards available in Z50Bus format for your needs I'd stick with it. If you are going to develop your own hardware as well then even better.

My current Z50Bus to RC2014 bus backplane section (SC517) doesn't support the IEI/IEO chain in the way specified for RCBus. I see two options to solve this.
1/ Use something like SC702 on the end of the backplane section (SC517) shown in you photo. SC702 is an RCBus compliant backplane section which should be available soon. This is not ideal as the IEI/IEO signals on the Z50Bus are not then connected to the IEI/IEO pins on the RCBus, although a couple of wire links on SC517 would fix that.
2/ Wait for an RCBus version of SC517. I think I will design one of those in due course. It shouldn't take much effort to modify the SC517 design to achieve this.

The Z50Bus does not support BAI/BAO so to implement these functions on RCBus modules:
1/ Connect BAI/BAO directly to the RCBus with a flying lead, bypassing the Z50Bus that does not have these signals.
2/ Use one of the Z50Bus user pins to get the BAI/BAO signal to the RCBus section.
In both cases any module requiring BAI/BAO would need to be implemented as an RCBus module, not a Z50Bus card.

Could support for BAI/BAO be added to the Z50Bus?
It could be implemented off the Z50Bus with a flying lead between modules. Alternatively, a couple of user pins could be repurposed with jumpers on the backplane. I'll give some further thought to the latter idea.

I think the best thing to do to implement your design with the backplanes you have is this:
Any module requiring BAI/BAO should be implmented as either a Z50Bus or RC2014 bus module, with pins on the module to connect a BAI/BAO flying lead to the next module requiring it. If the module uses the RC2014 bus, include jumpers to connect BAI and BAO to the pins assigned in the RCBus specification so you can later move to an RCBus backplane if you wish. If the module uses the Z50Bus bus, then include jumpers to connect BAI and BAO to user pins in the hope there will be support on future backplanes. We'd have to think about which user pins would be the best choice.
For RC2014 modules that need IEI/IEO, do the same thing as described for BAI/BAO.
For Z50Bus modules that need IEI/IEO, use the Z50Bus IEI/IEO bus pins.

Steve

[brade...@gmail.com]

Steve,

Thanks so much for this detailed response.  I am delighted by your approach – I like Z50Bus a lot as well.

 

I will proceed with building my early cards on the Z50Bus on the SC513 backplane, and will use flying leads or user pins to bridge BAI/BAO to RCBus.

 

Then I’ll sign up for the waiting list for the RCBus version of SC517.  I imagine you’ll have it ready before I’m ready for it.  :)

 

Thanks,
Brad

[Steve Cousins]

I have two RCBus modular backplanes complete and the designs are now available.

Details here: (including Schematics and Gerber files)

https://smallcomputercentral.com/sc701-rcbus-backplane/

https://smallcomputercentral.com/sc702-rcbus-backplane/

Steve

[Kurt Pieper]

Hi,

I just ordered the SC701 board.
I'm looking forward to some soldering work.

I wish you every success with the project.

Kurt

[Steve Cousins]

My RCBus I2C bus master module seems to be working well. I'll publish the design soon.

Three more PCB designs also arrived today so more soldering and testing over the next few days.

[Bill Shen]

Have you tried driving 1.3" 128x64 OLED display with I2C?  Your I2C pin out of Gnd-Vcc-SCK-SDA is compatible with 1.3" OLED, but not with 0.96" OLED.  There are no standard pin out, Vcc and Gnd are frequently swapped. 
  Bill

[Kurt Pieper]

Hello Steve,

yeah I like it. The presentation with the RCBUS is very good.

It reminds me of the period 1983-1988. New products appeared with every new issue of the trade journal. The US editions in particular were in great demand.
I already owned Kaypro and IBM compatible computers at the time. It was programmed with BASCOM and KSAM as well
BASIC compiler and BTRIEVE under DOS.

Today everything has become much more open. The users can familiarize themselves well with the electrical engineering of retrocomputers.
Anyway, I learned a lot and had a lot of fun.

I was able to program and test I2C with your boards and display results with a Rigol DS100Z/Plus and Rigol MSO5104.

They make excellent products and I've had a lot of fun with the Z80/Z180 for a number of years.

I wish you much success.

Greetings from the Rhine
Kurt

[Steve Cousins]

Thanks Kurt,

I too have fond memories of those early years of microcomputers when every month there was a new computer advertised - which was totally incompatible with any other. Very exciting days to be learning about computers.

Steve

[Steve Cousins]

Hi Bill,

I can't say I have tried the display you mentioned. 

What I'd really like is a display capable of 80x25 text that can be driven easily from a Z80 and be large enough to use as a terminal display. Oh, yes, and low cost.

Steve

[Alan Cox]

On Tue, 11 Apr 2023 at 22:00, Steve Cousins <steve...@gmail.com> wrote:

Hi Bill,

I can't say I have tried the display you mentioned. 

What I'd really like is a display capable of 80x25 text that can be driven easily from a Z80 and be large enough to use as a terminal display. Oh, yes, and low cost.

It's the fact that the display probably needs to be VGA that makes it tricky. 80 column composite or rgbi ttl isn't very hard with a bunch of the old chips. Marco's propeller graphics card is close but whilst it can do an 80 char wide screen it's got no option to show more than 40 at a time. Not sure if someone who has a pointy hat in propeller could make it do the 80 col modes (at least on vga) or not. Certainly there are other boards that do 80 column with a prop - I've got one of the hobbytronics ones on one box.

Alan

[Bill Shen]

The backup displays are reasonably priced.  They support VGA or SVGA resolution.

I2C is too slow for VGA communication.  The monochrome 128x64 OLED only need 1K byte of data per screen so screen refresh can be instaneously with I2C.  There are inexpensive 320x240 TFT LCD module with ILI9341 controller which accept I2C/SPI/parallel interface, but I have not tried I2C interface with it; it is probably too slow.
   Bill

[Alan Cox]

On Wed, 12 Apr 2023 at 12:44, Bill Shen <coinst...@gmail.com> wrote:

The backup displays are reasonably priced.  They support VGA or SVGA resolution.

I2C is too slow for VGA communication.  The monochrome 128x64 OLED only need 1K byte of data per screen so screen refresh can be instaneously with I2C.  There are inexpensive 320x240 TFT LCD module with ILI9341 controller which accept I2C/SPI/parallel interface, but I have not tried I2C interface with it; it is probably too slow.

The 9341 is painfully slow even in 8bit mode with an 8bit 8MHz processor. It's RGB565 at best so clearing an area even at 320x240 is visibly slow. Some of the other controllers have a text mode and/or colour expansion (ie you feed it a mono bitmap and colour) so are a bit better - eg the RAIO that a lot of the newer panels use. A lot of them are also 3v3, or at best 5v tolerant so the moment there is a bit of wire between them and a 5v board the drop is enough to break everything.

Alan

[Steve Cousins]

My RCBus power supply and reset module is finished and the design files are available.

[Tadeusz Pycio]

Today I can present the finished Backplane4 RCBus, after a long wait for 100nF capacitors with 2.54mm spacing. I did not expect that temporary stock shortages could occur here as well.

I bought a whole pack (1,000pcs), so I won't have such problems anymore. ;-)

[Steve Cousins]

That's great news. 

We now have proven designs for 3 modular RCBus backplanes:

4 slot with 5V input and reset

6 slot with 5V input and reset

6 slot 'extension'

I have designs but not sent off for PCBs yet:

12 slot with 5V input and reset

12 slot 'extension' 

My personal preference actually is to use an 'extension' backplane and a power supply module (12V input)

Other news: 

I've just about finished the documentation for my I2C bus master module. 

I have the first PCBs to test for:

Serial ACIA module

Z80 CPU module

Z80 memory module (128k RAM, 128k FLASH)

Z80 SBC module

Steve

[Tadeusz Pycio]

Preliminary design of the 16C450/550 UART module for RCBus. I chose not to add the /INT signal (this requires changes to open collector/drain gates) leaving only the connection of this signal to IRQ1 or IRQ2.

[Tadeusz Pycio]

I'm also thinking of a CF module, this time with full decoding of the /CS1 registers and the addition of a second card slot (Attend also produces these in mirror image) at address 0x20. So far I'm not convinced of the usefulness of this addition, so work is moving slowly.

[Steve Cousins]

A CF interface is also on my TO DO list. I have an RC2014 style module with two CF card headers using the master/slave approach but I don't have any software for it.

My I2C bus master and my serial ACIA modules are complete.

[Steve Cousins]

I have a few more RCBus compliant modules completed:

Z80 CPU

Z80 memory (128k)

Z80 SBC

[Tadeusz Pycio]

Congratulations, it's all developing nicely. I'm watching your progress with envy, as I'm in a complete slump - my wife has come up with a major house renovation, so I'm sitting on suitcases ;-) I haven't written a line of code for my 65C816 module - I don't even know if it works.

[dhen...@gmail.com]

Hey Steve, Do you use the standoff on the left to physically link each board?  I can't imagine trying to extract multiple boards at the same time from the bus. :D

[Steve Cousins]

No, the standoffs don't physically link to each board. They are just there to ensure the boards stay properly spaced and thus can't cause any shorts. I think they work well.

Steve

[Steve Cousins]

I've got a few more RCBus designs built:

SC709 Backplane, 12 vertical slots, 1 horizontal slot, 5 volt power in with voltage supervisor

SC711 Prototyping module (size "large")

PCB here but not yet assembled:

SC710 Backplane,  12 vertical slots, 1 horizontal slot, 1 horizontal bus extension header

I'll soon have a good basic range of open source designs that are RCBus compliant and RCBus styled.

Steve

[Kurt Pieper]

Hello

I have successfully soldered the SC701 RCBus Board.
Very good work! Congratulations to the developer Steve.

My Z280 (from Karl) works very stable on it.
Unfortunately 'xm r inkey.z80' only with 9600 baud.
I haven't been able to solve it yet.

back to the SC701. Unreservedly recommended.

Kurt

[Wayne Warthen]

On Friday, April 28, 2023 at 5:24:32 AM UTC-7 kurt....@web.de wrote:

I have successfully soldered the SC701 RCBus Board.
Very good work! Congratulations to the developer Steve.

Yes, Steve's new RCBus work looks great.

My Z280 (from Karl) works very stable on it.
Unfortunately 'xm r inkey.z80' only with 9600 baud.
I haven't been able to solve it yet.

Bill Shen reported a subtle hardware bug in the Z280 serial ports.  I don't remember the specifics, but it seemed to manifest itself by occasional character duplication or loss.  I don't think that file transfers will be reliable on the built-in Z280 ports.   He describes it briefly near the end of this thread: https://groups.google.com/g/retro-comp/c/5sJDPVfEZgI.  Bill found a way to work around this, but it is not incorporated in Karl's Z280 module.

Additionally, the Z280 will struggle to do a file transfer at 115200 with the RomWBW bank switching overhead.  It just struggles to keep up.  I am getting reliable transfers at 57600 baud using Bill's zz80mb which works around the hardware bug.

Thanks,

Wayne

[Kurt Pieper]

Hello Wayne,

thanks for your information.

Thanks again for the new RomWBW master.

We tried two years ago.
Please refer
https://groups.google.com/g/retro-comp/c/0Ei-hU5w104/m/_NdROfkGCQAJ

It's enough to have a say with a Z280. Hoax!

Greetings from the Rhine.

Kurt

[Bill Shen]

Z280's UART bug is subtle; it will intermittently transmit the same character twice IF the UART clock is asynchronous to Z280 CPU clock.  My early Z280 designs (ZZ80RC) had separate clock for UART and Z280 resulting in unreliable XMODEM file transfer.  I ultimately abandoned ZZ80RC and replaced it with ZZRCC which has the same clock source for UART and Z280.

I just powered up a ZZRCC and confirm it can transfer file at 57600 using XM in RomWBW environment.  This is with hardware handshake enabled.
  Bill

[Steve Cousins]

I now have a basic range of 18 RCBus specific designs. See attached picture.

They are all open source so Gerber files etc are freely available.

The backplanes meet the full requirements of RCBus specification v1.0

All meet or exceed the RCBus-2014 specification.

All meet the RCBus-Z80 specification (where applicable)

The 68B50 ACIA module also meets the RCBus-68xx specification.

Steve

[Wayne Warthen]

That is a lot of boards Steve.  They look really nice.  Congrats!

-Wayne

[Tadeusz Pycio]

Two enhanced RCBus standard modules are being developed.
The UART module, however, will have the ability to signal interrupts over the INT line due to the use of open drain gates.
Bugs have been corrected in the Z80+MMU module and it now releases the address bus depending on the state of the /BUSACK signal.

I am in the process of correcting the Z280 module.

[Kurt Pieper]

Hello Steve,
is a Z180 board planned for the RCBus?

I'm thinking of one here
Z180 CPU Module Kit for RCBus.

greeting
Kurt

[Alan Cox]

On Fri, 30 Jun 2023 at 12:47, Kurt Pieper <kurt....@web.de> wrote:

Hello Steve,
is a Z180 board planned for the RCBus?

I'm thinking of one here
Z180 CPU Module Kit for RCBus.

Probably going to need to have a surface mount variant given the PLCC Z180 has been discontinued. That or some kind of Z180 breakout that can be assembled at pcbway or jlcpcb somewhere.

Alan

 

[Kurt Pieper]

Hello Alan,
Thanks for the info.
Then we'll see.
I still have the SC126 board.
This board is outstanding.
Kurt

[Steve Cousins]

Hi Kurt,

I have been thinking about a Z180 module for the RCBus but with the increasing problems finding PLCC parts I'm not sure if I will make one. The existing Z180 CPU and memory modules (SC111 and SC119) should work on RCBus backplanes.

Alan's suggestion of a breakout board for a surface mount version of the Z180 is a possible way forward. I would like to avoid surface mount components and retain the true retro look of through hole parts, but eventually that may not be possible.

Steve

[John Scherer]

Just a thought but maybe offer RCBus Z180 PLCC PCB only and leave the sourcing of the Z180 to the builder?  I have 3 or 4 of them here, and they seem to be available on eBay from a lot of US vendors with quantity > 10 available.  More if one is willing to venture to China for them.

[Tadeusz Pycio]

Final version of the Z80 module with the 74HCT612 MMU. Fixed all bugs, added support for bus takeover by other devices, MMU status and diagnostic led on port 0x00 and meeting RCBus specification.

The next step is to adapt MP/M to use interrupts and queues for serial ports (which I didn't do, I always put it off).

[Mark T]

It might be best not to ground D0-D3 if there is any chance you might be reading from the 74HCT612 registers.

If you are only writing to the 74HCT612 you could connect D0 to D3 to A8-A11, to allow 12 bit output from the z80. If not used for adressing these could be used to write protect memory.

[Tadeusz Pycio]

It might be best not to ground D0-D3 if there is any chance you might be reading from the 74HCT612 registers.

I assumed that the first operation on the MMU registers is a write, so they can be read later, as D0-D3 are zero.

 

If you are only writing to the 74HCT612 you could connect D0 to D3 to A8-A11, to allow 12 bit output from the z80. If not used for adressing these could be used to write protect memory.

Interesting idea of memory protection. Although it would be troublesome because of the extended I/O addressing.

[Steve Cousins]

Hi Tadeusz,

Your RCBus CPU with MMU module is rather nice. The MMU is extremely flexible.

I'm curious why you use a transistor for the LEDs. The 74HCT74 should be able to drive the LEDs directly. 

Steve

[Steve Cousins]

Kurt asked if there is a Z180 board for RCBus.

While you can use SC111 (and SC119 for memory) I'm in the process of creating boards specifically to meet the full RCBus specification. I've attached schematics and PCB renders. I'd appreciate any thoughts on these designs and particularly anything relating to full compliance with the RCBus specification.

SC722 is a Z180 CPU module providing the clock, CPU, two serial ports, SD card (SPI) interface. Jumpers allow various signals to be connected to the bus: DMA (matching Tadeusz's CPU module assignments), INT1 and INT2, serial transmit and receive in various combinations.

SC721 is a 1MB memory module. This has a two 512kB FLASH chips selectable with a toggle switch, 512kB RAM. These are organised as a flat memory (no memory management). Jumpers allow memory to be organised with ROM low / RAM high or ROM high / RAM low. An optional pull up or pull down resistor network can terminate the high order address lines if required.

Steve

On Friday, 30 June 2023 at 12:47:14 UTC+1 kurt....@web.de wrote:

[Kurt Pieper]

Hello Steve,

I'm there.
Already looks very good.
I don't know any different from you.

I hope you still have some z180s in stock.

Greetings from the Rhine.
Kurt

[Tadeusz Pycio]

I'm curious why you use a transistor for the LEDs. The 74HCT74 should be able to drive the LEDs directly. 

Hi Steve,
Why? I had some space left on the PCB, so I added this retro-style LED control. There is no other reason :)

I can see that great modules for Z180 and memory will be created. Very good idea Flash-RAM mapping, the only thing missing to complete happiness is the ability to disable RAM access via the RAM_EN pin, but this is a requirement expected by few.
I don't know if you've seen, but a module with RTC and SD for your SC111 has been created, I found it on FB.

[Dylan Hall]

Hi Steve, a bit of a tricky suggestion.

I modified your SC111 design to mount the SD Card daughter board directly onto the module. I cheated and replaced the logic with a PLD to free up space.

I wonder with the SC722 if something similar would be possible if the SD Card sat over the top of other parts?

Thanks,

Dylan

--
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 on the web visit https://groups.google.com/d/msgid/retro-comp/2f39cf71-1dea-4737-8c98-05e7ff4299cbn%40googlegroups.com.

[Tadeusz Pycio]

Another version of the Z280 module with bootstrap. If anyone has comments then please comment. The /BUSACK line is not connected to pin 43 in order to be fully compliant with the RCBus v1.0 specification, but I do not anticipate using another DMA chip.

[Steve Cousins]

Hi Tadeusz,

"Why? I had some space left on the PCB, so I added this retro-style LED control. There is no other reason :)"

That's as good a reason as any I guess. A good array of resistors is good for the retro look.

Good point about RAM_EN. I could add this with the addition of only one resistor, as I have a suitable spare input on the RAM enable logic. I can't make up my mind if this is worth doing. The RAM_EN function is quite specific to paging out the ROM to enable RAM in its place. I don't think this is relevant here. I think it might have been you that mentioned previously that this pin would be better used to disable all memory on the board, thus enabling a window to be created in memory by another module. I don't see how to add a memory disable function to my design without major rework.

I am aware of the PCB you mentioned. It is a very nice add on to SC111.

Steve

[Steve Cousins]

Hi Dylan,

That's a good suggestion. My SC131 design mounts the SD adapter card a bit that. In the case of SC131 the SD adapter is mounted further above the PCB as there are ICs under it. I think the same can be done with SC722 although there are no mounting holes to secure it. All that is required I think is to fit a straight/vertical socket in the holes provided and straighten the pins of the SD adapter. There is not enough space on SC720 to mount it close to the PCB as you have.

Steve

[Bill Shen]

RAM_EN maybe an interesting feature.  I have a front panel prototype board and thinking of making it my first RCBUS compliant board.  It receives user input via PS2 keyboard and display address/data on six 7-seg displays.  It needs to take over WAIT, BUSRQ, and RAM_EN.  RAM_EN in particular to replace flash with RAM.  For it to work with SC108, I have to remove the ROM and bodge 74HCT74 to enable RAM.  It would be nice to have a RAM_EN jumper.

This is what the front panel prototype looks like.
  Bill

[Tadeusz Pycio]

I made unnecessary confusion with this RAM_EN signal. Please note that this is an optional signal in the specification. Steve would have to completely change his design to add it. I will soon be projecting a similar module based on an existing one (picture below) where I intend to add this signal there. The module will provide 128/512/640kB RAM depending on the memory added.

[Tadeusz Pycio]

I have redesigned the memory module, need to check for errors and have the PCB manufactured.

[Brian Cockburn]

Hi, I may be a bit of a noob here, but on the SC722 why is the CS signal for the SD card made active by a RESET?  It seems a bit counterintuitive.

[Steve Cousins]

Hi Brian, 

Thanks for the feedback. You are correct, it doesn't look sensible that the SD card /CS is low at reset. With the SC722 it could indeed be 'corrected' as the the 74HCT74 has a  present input (/PRE). This basic design of SD card interface dates back  some way. My first implementation was SC126 where the /CS signal is generated with a 74HCT273 and I had no spare gates to invert the signal. Fortunately the software initialises the /CS signal correctly before use and this arrangement works fine. My later designs maintain compatibility of port and bit numbers, and also signal polarity. I think that's why I did not 'correct' the reset state of /CS on designs where it was easy to do. I guess I probably should correct it where possible just to be tidy. 

Steve

[Steve Cousins]

Hi Tadeusz,

Good to see more new RCBus compliant designs. Keep up the good work. 

Steve

[Tadeusz Pycio]

New version of the 16C450/550 module, already in RCBus standard. Interrupt system to be checked.

[Steve Cousins]

That looks like another nice addition to the range Tadeusz.

I should have a few more designs to test in a week or so, including an SIO+CTC module. See attached render and schematic.

Steve

[Tadeusz Pycio]

I was looking forward to this module, I thought you had given up on building it which prompted me to design a similar one - unnecessarily :/
I needed it for my MP/M computer with the CPM+MMU previously shown. I'm glad it will be built, as sometimes such a connection is missing.

[Steve Cousins]

I should have the first PCBs for these designs in a couple of days:

SC721

Linear memory suitable for Z180. 512k bytes RAM, 512k bytes Flash (two 512k byte  Flash chips fitted, selectable with a switch). Jumpers to set RAM hi / ROM lo, or RAM lo / ROM hi.

SC722 

Z180 CPU with SPI header for SD card.

SC723

3-slot backplane with 5 volt input and reset/supervisor. This is a cut down SC701 for minimal systems.

SC724

Breakout prototyping module, rather like SC115. Uses RCBus "large" module form factor.

SC725

Serial plus timer module including Z80 SIO and Z80 CTC.

This set of boards pretty much completes the conversion of my range to the 80-pin RCBus format. Most of my SC700 series designs have refinements over the older SC100 series versions.

Time to start thinking about some new designs.

[Brian Cockburn]

Re: SC725.  I am only following this, I'm not really an active user, nor am I likely to purchase.  However, with other retro systems in mind and looking generally at serial chips, I note that the SIO comes in /0, /1, and /2 variants.  These chips are what pop up in the NOS and second-hand market.  Is your card able to cope with the /0 or /1, or just the /2 ?  Is this flexibility of interest to others on this forum (or am I making a fuss about nothing)?

Cheers, Brian.

[Steve Cousins]

Hi Brian,

SC725 only supports SIO/2. I agree that a few extra jumpers would allow the module to support the other variants, but it wasn't a priority for me. There is a down side in complexity and possible confusion if a module has lots of jumpers and this module already has quite a few.

Steve

[Tadeusz Pycio]

Hi Brian,

If complete kits are offered then uncertain sources cannot be relied upon. Admittedly, there are some people who look for bargains at NOS sales, as I do, which is why I designed such a universal SIO module. However, in this case it is difficult to guarantee continuity of supply to offer such a kit. I have noticed that it is now possible to buy the SCC Z80C30 cheaply, so I am working on such a module that will be able to use interrupts in IM2 mode. However, this will be a niche module that will be of interest to very few people.

[Tadeusz Pycio]

From time to time, cheap Z85C50 ICs appear, so I designed a module using these SCCs. The circuit for tuning the Z80 bus to meet the requirements of the Z8500 series chips was based on recommendations from Zilog. I wonder if it is possible to shorten the WAIT cycle by one clock, since CMOS chips have a better interrupt response than the NMOS chips that are described in these Zilog recommendations.

[Tadeusz Pycio]

I have completed the design of several RCBus modules and both have gone into production:
1- CF Module with the addressing fix proposed by Steve Cousins
2- Z280 MPU module: added the missing pull-up resistors for the DMA channels
3- Z85C30 SCC module: added a jumper to change the WAIT signal duration
4- Linear memory module: ROM - 512kB,RAM - 128kB/512kB/640kB allowing ROM to be mapped to the beginning or end of the address space, with the possibility to disable RAM using the MEM_EN signal.

I am currently working on a new version of the Z80+MMU 74HCT612 which has a system clock and allows safe reading of MMU registers, and on a new version of the XR88C681 module which will work with interrupts in IM2 mode and will have an RTC.

RCBus will add several new modules. :-)

[Steve Cousins]

Hi Tadeusz,

They look good. The RCBus 80-pin range is growing nicely.

I've recently released SC721 to  SC725. Nothing new on the drawing board at the moment but I doubt it will be long! 

Steve

[Wayne Warthen]

Hi Tadeusz,

I can't seem to remember where to purchase your boards or download your designs.  Can you refresh my memory?

Thanks,

Wayne

[Tadeusz Pycio]

Hi Wayne,

Your memory is good, as I don't generally sell my modules, only at my local surplus market. I have time issues and rarely update my website and GitHub account. If there's something you're interested in and it's a project I've checked out, just email me and I'll send you the production files. Maybe one day I will have more time available, then I will sort out the shortcomings.

[Tadeusz Pycio]

The boards have arrived and, as a start, I will check the operation of the Z85C30 SCC in an RCBus environment (with emphasis on compatibility with IM2 interrupt mode).

[Andrew Young]

Hi all,

Just ordered a backplane kit. 

I'm working on an m68k CPU board. 

I'm starting with a 68008, but the signals should work for a 68000 or 68010 too. 

This is the mapping I'm using, let me know what you think.

RCBus 68k

------------------

19 - nM1 is not used. The CPU card will hold it high.

22 - nINT is mapped to IPL0. (The 68k has a 3-bit interrupt number.)

37 - nINT1 is mapped to IPL1.

38 - E (follows 68xx convention)

39 - RW (follows 68xx convention)

40 - nBGACK (Input, active when another bus master is holding the bus)

41 - nAS (Active when A0..A23 are valid)

42 - nUDS (Active when D8..D15 are valid)

43 - nLDS (Active when D0..D7 are valid)

44 - FC0 (processor mode, user vs supervisor, etc.)

45 - FC1 (processor mode, user vs supervisor, etc.)

46 - FC2 (processor mode, user vs supervisor, etc.)

47 - nDTACK (Input, active when the device on the bus is ready for the CPU to read or write.)

48 - nBERR (Input, active when the device on the bus raises an error.)

59 - nRFSH is not used. The CPU card will hold it high.

60 - PAGE is not used. The CPU card will hold it high.

77 - INT2 is mapped to IPL2

78 - nVPA (Input, sent by 68xx ICs.)

79 - nVMA (Ouput, sent to 68xx ICs when E is synchronized.)

- Andrew

[Mark T]

NDTACK could possibly be inverted from NWAIT on the bus.

I think M68k reset is both input and output, is it safe to connect this to reset on the z80 bus. Page was also labelled as reset2 on the RC2014, so maybe that could be used for reset output.

Are you planning to generate Iorq, Mreq, Rd and Wr to allow interface to some of the existing RC2014 modules, or is the plan for a complete new set of modules specific to the M68k.

[Doug Jackson]

Andrew,

While likely not helpful, the presence of the discussion of DTAK reminded me of an esoteric magazine called "DTAK grounded", by a fellow who designed an interesting 68000 board in the very early 1980's, where his starting premise was to ground DTAK as you could get memory and peripherals that were fast enough that you didn't need it. :-)

It was always a fun read.

I include a reference to the magazine series for your general humor :-)

A wikipedia page:  https://en.wikipedia.org/wiki/DTACK_Grounded

The archive.org wayback machine archive of the site:  https://web.archive.org/web/20171216172700/www.easy68k.com/paulrsm/dg/

Kindest regards,

Doug Jackson

em: do...@doughq.com

ph: 0414 986878

Follow my amateur radio adventures at vk1zdj.net

--

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 on the web visit https://groups.google.com/d/msgid/retro-comp/1fcc60fe-c596-4a3c-99de-e212fd120056n%40googlegroups.com.

[Bill Shen]

Interesting.  I’ve done a number of M68K to classic 40-pin RC2014 bus.  I’m interested to see what RCBus can offers to accommodate the 68K processors.

  Bill

[Andrew Young]

Good catch with the reset signal! This is my first time implementing a 68k system, and I hadn't realized yet that reset is bidirectional. There's a similar issue with the m68k's halt signal. In that case I used a buffer to split the signal between the RCBus WAIT and HALT signals. My thought process was that when the processor is driving the signal I only want HALT to be driven on the bus, not WAIT. For reset, maybe it's enough to do something similar, or add a diode, so that we never drive the bus signal from the CPU. What do you think? I do have 1 open pin still, pin 80.

I do plan to generate IOREQ, MREQ, RD, and WR. I really want to allow mixing of modules as much as possible. The primary goal is for me to build a little m68k machine, but the reason I went with RCBus was for compatibility with other hardware. :) 

--
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/XAmVsfJ-wPo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.

[Andrew Young]

Thanks! I'll definitely check it out. :)

--

[Rob Gowin]

On Tuesday, September 19, 2023 at 10:08:20 PM UTC+2 and...@vaelen.org wrote:

Hi all,

Just ordered a backplane kit. 

I'm working on an m68k CPU board. 

Hi Andrew,

That's cool. I think we need more 68K designs. (More importantly though we need better software options than CP/M-68K for 68Ks without MMUs.)

 

I'm starting with a 68008, but the signals should work for a 68000 or 68010 too. 

This is the mapping I'm using, let me know what you think.

One question: where do you plan to put RAM and ROM for your system? On the same card as the CPU, or on a different card? 

The 68000 and 68010 with their 16 bit data bus would require quite a different design if the memory is on a separate card. 

Have you decided what the physical size of your CPU card will be? That will determine how much logic you can put on the card.

 

RCBus 68k

------------------

19 - nM1 is not used. The CPU card will hold it high.

For the RCBus, nM1 is involved in interrupt acknowledgement, along with nIORQ. 

 

22 - nINT is mapped to IPL0. (The 68k has a 3-bit interrupt number.)

37 - nINT1 is mapped to IPL1.

This interrupt scheme won't work. (Hint: what happens when nINT and nINT1 are asserted at the same time?) The usual method is to have the interrupt lines go through an 8-to-3 priority encoder like the 74LS148 to generate the IPL lines on the 68K CPU card. Note that you can also support nNMI with this priority encoding scheme.

 

38 - E (follows 68xx convention)

39 - RW (follows 68xx convention)

40 - nBGACK (Input, active when another bus master is holding the bus)

41 - nAS (Active when A0..A23 are valid)

42 - nUDS (Active when D8..D15 are valid)

43 - nLDS (Active when D0..D7 are valid)

You mentioned that you want compatibiliy with existing hardware by generating MREQ, IOREQ, RD, WR, etc. In that case nAS and nLDS will be part of the logic that generates those signals and don't need to be directly on the bus. The group hasn't yet really determined what is needed for for 16-bit data bus support, so I would not allocate a pin to nUDS yet. It may be that an A0/BHE scheme would be better. (Note that the 16 bit 68K CPUs don't generate A0, but the 68008 and 68020/030 do.)

44 - FC0 (processor mode, user vs supervisor, etc.)

45 - FC1 (processor mode, user vs supervisor, etc.)

46 - FC2 (processor mode, user vs supervisor, etc.)

I don't think these need to be directly on the bus.  The RCBus doesn't really have a notion of supervisor vs user level access (I think). The other use for these signals is in interrupt acknowledge, but I think the CPU card should handle that. Since the 68K has more interrupt levels than the RCBus has interrupts, I think autovectoring is sufficient. For vectored 68K interrupts, existing hardware would have to be able to decode the interrupt level number on A3-A1 during IACK, and no RCBus hardware I know of does this. 

 

47 - nDTACK (Input, active when the device on the bus is ready for the CPU to read or write.)

48 - nBERR (Input, active when the device on the bus raises an error.)

A agree with Mark that nDTACK is just inverted nWAIT, so no need for a separate pin.

I would not allocate a line for nBERR until there is a proven use case for it to be on the bus. Your CPU card will need to implement a watchdog timer, which is the usual cause of bus errors. If there was a desire to put this watchdog on a separate card, then an nBERR pin would be needed. 

 

59 - nRFSH is not used. The CPU card will hold it high.

60 - PAGE is not used. The CPU card will hold it high.

When booting from reset, the 68K gets it reset vector and stack value from locations 0 and 4 respectively, so this usually has to be ROM. But it is also preferred to have RAM starting at address zero. The usual practice is to map ROM to address 0 for the first few cycles (exact number depends on the actual chip) then map RAM thereafter. I haven't thought it all the way through, but if RAM/ROM is on a separate card, I think PAGE could be use to communicate this mapping from the CPU to the memory card.

 

77 - INT2 is mapped to IPL2

78 - nVPA (Input, sent by 68xx ICs.)

79 - nVMA (Ouput, sent to 68xx ICs when E is synchronized.)

I'm not convinced nVPA and nVMA deserve to have their own pins, but I need to think about that some more.

I hope this helps. If you are new to 68K design, I heartily recommend Alan Clemens' "Microprocessor Systems Design: 68000 Hardware, Software, and Interfacing", third edition. https://archive.org/details/microprocessor-systems-design-68000-hardware-software-and-interfacing-3e

Regards,

Rob

- Andrew

[Bill Shen]

68000/68010 CPU card for RCBus would be challenging, but interestingly using 8-bit dynamic bus sizing, 68020/68030 may work out, although their performance improvement through wider bus won't be realized unless there are space on board for wider memory.

I, too, struggled with the idea of 68K on RC2014 that reuses the existing RC2014 boards.  One approach is a 68020 motherboard that has local 32-bit memory and decoding logic to convert 68020 signals to Z80 signals; the Z80 signals are connected to standard RC2014 expansion slots that can be populated with ROM, I/O, and CF disk.

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

  Bill

PS, definitely agree that RC2014-68K needs better software than CP/M-68K

[Andrew Young]

Thanks Rob! This is great feedback. It's very helpful and greatly appreciated.

The book you suggested is exactly the one I have (though I haven't finished reading it yet). :) My only experience implementing a system from scratch like this was with a 6502. My original plan with the 68k was just to put all the CPU pins on a bus so I could build some quick prototyping cards without needing to put everything on a breadboard, but when I found the new RCBus specification I figured it would be better to extend that if possible.

For the RCBus, nM1 is involved in interrupt acknowledgement, along with nIORQ.

I didn't realize this. I don't have any experience with the Z80, which probably puts me at a disadvantage here. The RCBus specification doesn't mention this either, it just says that it can be held high by non-Z80 CPUs.

One question: where do you plan to put RAM and ROM for your system? On the same card as the CPU, or on a different card?
The 68000 and 68010 with their 16 bit data bus would require quite a different design if the memory is on a separate card.

I was planning to put the memory on a separate card. The 68008 only supports 1MB, but the 68000 supports up to 16MB and I'd like to be able to add more memory later on as needed. The RCBus spec includes 24 address lines and 16 data lines, so I figured that reading / writing 16 bits at a time should work ok. I'd like to hear your thoughts on why this would be difficult because I'm sure I'm missing something.

This interrupt scheme won't work. (Hint: what happens when nINT and nINT1 are asserted at the same time?) The usual method is to have the interrupt lines go through an 8-to-3 priority encoder like the 74LS148 to generate the IPL lines on the 68K CPU card. Note that you can also support nNMI with this priority encoding scheme.

I had planned to have nNMI pull all 3 IPL lines low. I understand why you're saying this scheme won't work though. As an aside, the layout I suggested doesn't support chained interrupts either.

A agree with Mark that nDTACK is just inverted nWAIT, so no need for a separate pin.

I misunderstood what nWAIT is used for in a Z80. One of my goals though is to be able to send the 68k WAIT signal to the CPU to enable stepping with a debugger, so if nWAIT is actually nDTACK and nHALT is unidirectional, then I'll need another signal to actually pause the CPU.

The RCBus doesn't really have a notion of supervisor vs user level access (I think)

That's true, but one of my goals for this project is to port unix over to it, so I need to support supervisor mode if possible. I'd also like to eventually have an MMU to provide memory protection for the 68010.

 It may be that an A0/BHE scheme would be better.

I'm not familiar with this. Can you elaborate a bit?

For vectored 68K interrupts, existing hardware would have to be able to decode the interrupt level number on A3-A1 during IACK, and no RCBus hardware I know of does this. 

I'm not familiar with vectored interrupts. I'll have to look into this more. 

 I would not allocate a line for nBERR until there is a proven use case for it to be on the bus. 

This is a good point, thanks!

When booting from reset, the 68K gets it reset vector and stack value from locations 0 and 4 respectively, so this usually has to be ROM.

I was planning to use a microcontroller as a first stage bootloader and have it load an initial program into RAM on boot and then reset the CPU instead of having ROM in the system.

If RAM/ROM is on a separate card, I think PAGE could be use to communicate this mapping from the CPU to the memory card.

Yeah, that's a great point too.

My plan was to put RAM in the first 64k and IO in the second 64k followed by more RAM. That would make it relatively easy to access bit devices on the bus. What do you think?

I'm not convinced nVPA and nVMA deserve to have their own pins, but I need to think about that some more.

I have no idea about these beyond the description I read in the book. The 68008 doesn't even generate nVMA.

 

Thanks again for your help!

--
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/XAmVsfJ-wPo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/8901f1e1-a4bf-4b20-82cb-a1b3612e22b2n%40googlegroups.com.