DigicoolThings Forum

epaell wrote: Tue Mar 24, 2026 11:08 pm BTW, I realise that I didn't really label the "mysterious" J2 header on the Z80 board very well. I use the GAL to divide the CPU clock by 2 and 4 and use the J2 jumper to select between the full CPU clock, or the /2 or /4 alternative. With anything too high (e.g. I currently have a 10 MHz CPU) it tends to prevent the 6840 timer from operating so I normally add a jumper in the middle of the 2x3 header to select the /2 clock (top two pins select the highest clock rate, middle two the /2 clock and the bottom two the /4 clock).

This is helpful, as I was just about to query the requirement for the CLK2 / CLK4 pins.

I had noticed that the bus MREQ isn’t implemented (in the PLD logic). Presumably, because all of the memory is on-board, so the bus is just being used for I/O?

It had occurred to me that you are not using the generated MA20 & MA21, so I just thought it would have been nice if these (MA16 - MA21), could be wired into the bus (for a 4MB memory address space), which would also require wiring MA20 & MA21 into the PLD (hence my question about the need for the CLK2 & CLK4 pins)

This would allow the 1MB for on-board memory, and the remaining 3MB to be available via the bus (via the bus MREQ), for memory mapped expansion cards (or simply bus based memory expansion).

In terms of the problem of 6840 PTM IORQ clock speed capability, perhaps the solution to this would be to instead use the upcoming WDC I/O Card (specifically the VIA’s timer), as these modern WDC peripheral chips are cable of faster speed? Assuming a 65C22 timer could be supported in place of a PTM?

Just some thoughts…

Also (seperate note)…
I’ve just been made aware of MicroChip AN0484 “Selecting Decoupling Capacitors for PLDs”, which highly recommends the use of 220nf bypass capacitors with their PLDs (instead of my usual 100nf go to).

https://www.microchip.com/en-us/applica ... tes/an0484

Having read the recommendation, I’m now changing my PLD specific bypass capacitor use to 220nf.

Note that I’ve never experienced (or measured), any issues with power line noise on my MECB systems, but when you read a manufacturer application note than has a specific recommendation, it’s usually worthy of note.

Therefore, I’ve already updated the PCBs of a couple of my Cards (for future PCB orders), and I will be using 220nf for PLD bypass, in future.

I was trying to make this first board as simple and compatible as possible to the RC2014 set up so that I could re-use as much of the software there for testing. I did feel it was a bit of a waste to leave those MA20 and MA21 pins unused and had considered directing them to the bus but I didn't have a chance to consider what effect that might have in terms of compatibility. I did leave provision for the MREQ (which enters pin 2 of the PLD from the processor and out to pin 16 of the PLD which then goes to the bus) although as you pointed out I neglected to add the logic for it in the PLD (I should at least add that). As far as I could tell the extra memory might only help by expanding the RAM drive (which is where much of the additional memory currently goes) - the Z80 itself can't easily make use of it and it requires lots of careful paging to make code work across different pages (and I'm not sure if RomWBW can easily accommodate the extra memory ... but it is not something I have really looked into).

It would be interesting to see how the WDC versions of the various I/O devices work with the higher clock rates. The 6840 issue was more of an annoyance than anything else (RomWBW and CP/M don't really need it) but I really wanted to make sure that it would work with the board.

It's interesting regarding the Application Note for the PLD - I was not aware of that ... although at least that is an easy change (albeit annoying because I can barely read the text on those capacitors and it's a lot easier for me if they are all the same value and I don't need to look at what I've picked up when wiring the boards together ).

Some of Emil's Z80 boards arrived in the post today. I found I had everything I needed to build one and set about it. Then headed over to the RomWBW github and copied the instructions to patch the build with the modifications needed to support the 6850 ACIA etc. Everything seemed to fall into place without undue problems and I burned a flash chip. At present I have only the MECB Motorola I/O card and the new Z80 card installed but I'm happy to report it worked first time.
Here is a sample of terminal data showing CP/M booting of the ROM image at 38400 bps.
Well done Emil for making an easy to use board design. Looking forward to making more for this platform, and then recreating my Z180 system one day too.
Best regards, David.

That's fantastic news - so relieved to hear that it worked! BTW, I have also had the board running with 115Kbps but it requires a different crystal on the I/O board and slightly different settings - I ultimately decided to keep the "std" build of RomWBW set up for the default I/O card configuration just to make life a bit easier for anyone building the board.

I received my revised (v1.0) IDE and IO/front panel board literally minutes before a planned road trip from Sydney to Brisbane so I haven't been able to confirm whether those are all operating as intended. Hopefully I can confirm that next week when I return home. While away, I was reading a bit more about FujiNet and was wondering if that might be an interesting addition.

I forgot to mention, I'm using a standard 4MHz Z80 with speed jumper set for straight through. I do not have a faster one.

I use CP/Net on my Z180 system with a wiznet module connected via spi on the SC126 board. I'd like to get that working on the MECB platform too. Here are the notes showing how it is installed on the SC126: https://github.com/durgadas311/cpnet-z8 ... 180CSIO.md

I shall be having a play to see what boards I can get working with the Z80 board next ...
Perhaps a simple character LCD for starters.
David.

I had not heard of Fujinet until you mentioned it here. It looks ideal for a multi processor platform like the MECB. Here is an interesting development interface for Fujinet https://github.com/FozzTexx/fujiversal-pcb-prototype
There is an active community with a discord and other presences, David

It must be a year or two since I started this MECB to RC-Bus adapter board, but today its performed its first task. It allows my RC2014 8042 keyboard adapter to work with the TMS to form a CP/M terminal using Emil's Z80 configuration together with a small edit to the tms.asm to enable the keyboard. My adapter is being used here with a SC702 RC-Bus bus extender kit from Steve Cousins. I havn't soldered the full complement of pins yet, just enough for this simple keyboard board to work. CP/M can now use the TMS/Keyboard combination as a terminal by selecting 'I 2' at the boot menu.
It would probably make more sense to pathc thr Motorola I/O card PS/2 keyboard into the system but hey-ho.
hth David.

That is very cool David!

(Sorry for the slow response, I was travelling over the past few days and only just got back)

Having a bus converter like that would be great for testing alternate devices that are already available on the RC2014 system on the MECB system! Funnily enough, I just received a 8048 in the mail as I was considering whipping up a PS/2 adapter (mainly to simplify interfacing with RomWBW ... though I would like to eventually get the currently existing PS/2 adapter that goes via the Motorola I/O card at some point).

I've only recently become aware of Fujinet - I like the fact that it is targeting a lot of retro-computing systems and I think it would be a great fit for the MECB. I'm just a bit unsure how to proceed with it in terms of interfacing to maximise compatibility and minimise effort. I saw a version that used an 82C55 (much like the PPIDE card) but for the HeathKit system ... but the schematic was in ASCII text and it was unclear to me if it was every taken any further (or even completed). It just appealed to me because the design was very simple (and most importantly didn't require any surface mount devices). I'll need to do a bit more reading to understand how it all works ... and whether or not the RC2014/RomWBW system supports it yet.

David, Seeing as you are familiar with RC2014 ... is there a trick to getting XM.COM working? I was able to send a file from the CP/M system to my laptop but for the life of me I can't seem to go in the opposite direction i.e. send a file from my laptop to the CP/M file system (which is the direction I would find most useful). I've searched high and low and read some mention of hardware handshaking and/or reducing the BAUD rate all the way down but neither of these seemed to help (well, assuming that I did actually get the hardware hand-shaking working properly - at least from a terminal point-of-view it seemed to be working and if I didn't enable it on the terminal software then the terminal would stop transmitting/receiving).

I'm just curious if it is something peculiar with the MECB implementation or just plain and simple user error on my behalf. I'm using minicom on under Mac OS as a terminal.

Hi Emil, it's a long while since I tried, but I remember having to use one of the Kermit implementations to get a reliable transfer. I have found some usb/serial adapters just don't work well for handshaking. I have an old ftdi based one which seems good if others fail

I have used John Hanson's t-net successfully on rc2014 before switching to cp/net. T-net is quite easy on the cp/m side, I'll see if I can make it work. Sadly I'll need to transfer some files to get started. ATM I have not got an idea interface working properly, new boards arriving any day now. David