[P] MECB Z80 CPU Card

[epaell]

More progress ... the MECB VDP card now also works with the Z80 card and RomWBW.

With the addition of a keyboard this is one step away from being a stand-alone system capable of running CP/M and writing software in a vast variety of languages.

[Editor]

More progress ... the MECB VDP card now also works with the Z80 card and RomWBW.

Fantastic work! I think this confirms that my own focus should now be on peripheral cards, as you seem to have the more immediately desired Z80 CPU Card covered.

So, I'll continue with looking into my WDC I/O Card, with YM2149 sound, and also my plans for a PS/2 keyboard interface (borrowing / building on my Creativision re-creation project).

But, in the meantime, I'm supposed to be focussing on my next video!

[epaell]

Version 1.0 of the card arrived so I soldered it up and it appears to be working fine without any modifications!

Here it is booting up from a Compact FLASH card via the IDE adapter. Terminal I/O is via the MECB Motorola I/O card. There is also a prototype IO/RTC card showing boot status (and allows configuration via switches):

https://www.youtube.com/watch?v=qjI1ptOSyM0

The CPU is running at 10 MHz and ROM contains an MECB specific version of RomWBW.

I've updated my GitHub for this project over here with the schematics, PCB, Gerber files and PLD software. I haven't uploaded the RomWBW updates yet - I may check with the original developer to see if he is happy to include it as part of the standard package to save me having to replicate the code.

https://github.com/epaell/MECB/tree/main/MECB_Z80

Cheers,

Emil.

[djrm]

Great to see a super new platform to running RomWBW, looks like you have a useful set of cards already with non-volatile settings storage too, nice.

edit:
After looking at your schematics I see you have done all the work I needed to do to map the Z80 MECB bus to the equivalent RC2014 bus - getting around to this is what stopped me finishing my RC204 to MECB adapter interface. So I may now soon have my own Z80 MECB thanks to your work.

Another thing, Ive been looking at memory paging schematics and have just recently discovered the possibility if using the 74670 registers, I hadn't realised that the 512k ram/rom board used these as well. I have even bought some chips into experiment with. On the other hand I could just build one of your boards.

I hope Wayne adopts your changes into the RomWBW codebase, it will be a really useful resource.
Best regards, David.

[epaell]

Hi David,

Wayne has been absolutely fantastic - I posted mention of the board on the "show and tell" discussion page and mentioned that I made some slight changes to RomWBW and without me even asking (or begging ) he was already willing to incorporate these into RomWBW. I've passed on the changes I made so hopefully it will be an official system very soon.

The IO board (AKA "front panel" in RC2014 speak) works fine but I'm struggling a bit with the RTC. For some reason RomWBW is not recognising that it is installed (it has the right port address - which I had to shift otherwise it would conflict with the Motorola I/O board - I've verified that the latch is holding data sent to it- so it is mostly working). Strangely, I extracted the code from RomWBW into a separate test program so that I can check step-by-step what it is doing and that does seem to recognise the board and I "think" I can read and write the non-volatile memory but I need to double check it again when I have time as I was playing with this very late last night and there was a lot of code needed to get this running (a lot of bit bashing and manipulation - particularly for the time side of things) so maybe I was doing something wrong that made me think it was working. One thing that worried me was that I wasn't seeing any oscillation on the crystal and after looking at the data sheet for the DS1302 I note that there are very specific mentions regarding PC board layout around the crystal (which I didn't know about and have likely violated).

BTW, I have four spare boards - I'd be happy to mail you one if you are interested. I really only needed one and they all come in 5's ... including the prototype IDE and RTC/IO board (so far the only error I've found is that my fancy LEDs seem to have the pins the opposite to what KiCAD defined so I had to mount them on the rear side of the board ... and also the header for the 44-pin IDE is the wrong way around - again not really an issue because the while the right-angle header I have has the notch guide on it the Compact FLASH adapter doesn't have a notch i.e. it uses blocked pins in the socket as a key, so I can simply plug it in upside down ... I've taken out the appropriate pin in the header so that the adapter can't be plugged in incorrectly).

Cheers,

Emil.

[djrm]

Hi Emil, thanks for your kind offer of a board, but I expect the shipping cost would be more than me buying and shipping a board myself. But yes I'm interested. I just now ordered your Z80 card as one off special offer for USD 4.20 from JLCPCB
I had trouble with an rtc chip once when I didn't have the battery connected during testing. I thought it would be ok on the main power input - it wasn't. I see the SC126 I have also uses a DS1302 and it is a bit-bash type interface iirc. David.

[epaell]

Hi David,

I would've been happy to do so nonetheless ... although with the current state of the world you may get it faster from the JLCPCB than from Australia anyway

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).

I do have a battery installed on the DS1302 - I should actually check whether the values I stored last night are still in the NVM ... that might be another good check. Yes, the DS1302 requires a serious amount of bit bashing to get data in and out (which makes the initial testing more challenging than I would've liked). As I mentioned the latch seems to work fine and that controls most of the signalling - the only other bit I changed was moving the tri-state buffers into the GAL just to save on chip count and make better use of the GAL. It's possible I messed something up in my logic there - although that should also break the NVM access as well (so if I can demonstrate that works then I think it should be pretty much right). The main thing that concerns me is the lack of signal on the crystal - I'll need to confirm that (I would've thought this would only affect the RTC part of the device so I'm still not certain why RomWBW didn't detect my device).

Cheers,

Emil.

[djrm]

Hi, looking at the z80 schematic I wonder if it would be possible to incorporate the 7474 into the pld, Im not sure if it could but it would be nice if it could, it's simpler already without the other glue chips. D

[epaell]

I had considered that but the clocking of the 7474 isn't with the system clock and I "think" the GAL can only clock with pin 1 ... if I did that then I wouldn't be able to do the clock division. I think GAL I had also used all the available pins. It might be possible to change the design a bit to do something similar to what I had in the original 68008 board (using a set/reset flip-flop) but it would require a bit of thought to get right and to understand if there would be implications for RomWBW (as it may change the behaviour). At least for now, I just wanted to keep it as simple and as compatible as possible.

BTW, I made a quick program to dump the DS1302 NV RAM and it seemed to keep all the values even when powered off. Well, interestingly, the last value (address 30) is fine until I restart the system. Coincidentally this is the one that RomWBW uses to test for the DS1302. At boot up it should read this value, invert it, store it, read it back, invert it and check with the original value. It should then restore the original value. Given that this value is the only byte that changed I suspect my issues relate to that part of the code in RomWBW - I guess that gives me a few more hints of where to look.

[epaell]

I've just tested manually using routines to write to and read from the DS1302 clock and it appears that the clock is ticking and continues to tick even when it is switched off. So it really seems to be something associated with RomWBW initially trying to detect the device.