PDA

View Full Version : Z80 cpu plug-in diagnostic



pavery
September 5th, 2010, 03:09 PM
I struggled with the heading for this post. I want to investigate using a Z80-based microcomputer (say a Kaypro II or TRS-80 Model I-IV) to diagnose another (faulty) Z80-based system. I envisage unplugging the CPU of the faulty system and plugging in a header cable & performing RAM/ROM checks using the 'diagnostic' computer. This would provide quick troubleshooting.

Further, I could see a different header cable being used to diagnose 6502 systems (or other CPU types), making a great tool for those with large & varied hardware collections.

I've spent time trolling the net for some homebrew solution to this, but with no success. Has anyone done something like this? Any pointers would be appreciated, particularly for the hardware side. I'd be fine with the assembly language side of things.

Many thanks
Philip

Chuck(G)
September 5th, 2010, 03:33 PM
There were gizmos to do this in the arcade world. Not only could you emulate the whole CPU, but you could operate it somewhat like an ICE box or use it to check out RAM. Alternatively, you could use a full-blown Z80 ICE. Here's a very modest one that you can build (http://www.tauntek.com/Z80-In-Circuit-Emulator.htm). Or you can google for "Z80 in-circuit emulator".

kyeakel
September 5th, 2010, 07:33 PM
I have reciently completed the modest one Chuck is referring to. It works great, has a nice rom / ram identifier program. Allows you to enter machine code and execute or single step that code. It's fairly easy to build but you need a xilinx programmer cable, and a pic chip programmer to get all the code installed in it. If anyone wants to build one and needs help with the programming, I'd be glad to program the chips.

Kipp

Chuck(G)
September 5th, 2010, 07:47 PM
If someone wants to use through-hole technology, Futurlec still has the XC9536 in PLCC.

pavery
September 6th, 2010, 01:13 PM
There were gizmos to do this in the arcade world. Not only could you emulate the whole CPU, but you could operate it somewhat like an ICE box or use it to check out RAM. Alternatively, you could use a full-blown Z80 ICE. Here's a very modest one that you can build (http://www.tauntek.com/Z80-In-Circuit-Emulator.htm). Or you can google for "Z80 in-circuit emulator".

Thanks Chuck & Kipp. That's given me a good start - I've checked out the NICE Z80 emulator. I am really looking for an old-school solution, hopefully using an 8-bit microcomputer system - I'm sure I could adapt it to whatever I have around here. Also, if I'm willing to settle just for RAM/ROM checking, not full emulation, then that should cut the job down in size. I'll have a poke around in the arcade world.

Thanking you
Philip

tezza
September 6th, 2010, 01:29 PM
This device as described by Philip would be a boon to those of us with many different types of 8-bit micros. I've found on-going repairs are necessary just to keep them up and running. The hardest ones to diagnosis are RAM and ROM issues where things are going wrong on the address or data bus.

Apart from having a few spare "junk" micros which I can offer for local testing (I'm thinking of my spare Z80 System 80 boards and spare Apple 6502 clones) I probably can't contribute much, but it's a great idea.

Tez

MikeS
September 6th, 2010, 04:05 PM
Thanks Chuck & Kipp. That's given me a good start - I've checked out the NICE Z80 emulator. I am really looking for an old-school solution, hopefully using an 8-bit microcomputer system - I'm sure I could adapt it to whatever I have around here. Also, if I'm willing to settle just for RAM/ROM checking, not full emulation, then that should cut the job down in size. I'll have a poke around in the arcade world.
Thanking you
PhilipHi Philip; I was thinking about something like this when we had those posts about PETs with probable bad ROMs or RAMs and no way to read them; shouldn't take much more than a couple of buffers and latches to connect a parallel port to the target CPU socket and read/exercise the memory and I/O ports from there.

pavery
September 7th, 2010, 01:49 PM
Hi Philip; I was thinking about something like this when we had those posts about PETs with probable bad ROMs or RAMs and no way to read them; shouldn't take much more than a couple of buffers and latches to connect a parallel port to the target CPU socket and read/exercise the memory and I/O ports from there.

Hi Mike. Well if we pull a Z80 CPU isn't there refresh for DRAMS to consider too? Anyway I like what you're saying - I'll chat offline with you if I may.

If I have any success with this project, I'll post here a link to a blog covering it.

Philip

Chuck(G)
September 7th, 2010, 02:13 PM
I was wondering about he refresh issue myself with Mike's suggestion. Doable, sure, but adds a level of complexity (e.g. keeping a refresh counter and gating it onto the address lines with the proper status signals). I suspect that a fair amount of the CPLD on the ICE mentioned above is dedicated to just that task.

MikeS
September 7th, 2010, 02:49 PM
I was wondering about he refresh issue myself with Mike's suggestion. Doable, sure, but adds a level of complexity (e.g. keeping a refresh counter and gating it onto the address lines with the proper status signals). I suspect that a fair amount of the CPLD on the ICE mentioned above is dedicated to just that task.Yeah, at the time I was just thinking about a static RAM PET. Still, doable but definitely more complicated; would just writing and reading memory not be enough to keep them refreshed? We're not really concerned with long-term retention after all.

I haven't followed it in detail, but didn't Andrew (N8VEM) come up with a Z80 "shim" adapter/board? Maybe we can steal some ideas from that?

dave_m
September 7th, 2010, 08:57 PM
Yeah, at the time I was just thinking about a static RAM PET.
Mike,
I do not know about the Z80 hardware, but I'm pretty sure refresh is a not problem with the dynamic PETs in your scheme. The refresh circuitry is external to the CPU and operates on the opposite phase of the clock on a non interference basis with separate address lines multiplexed to the RAMs.
-Dave

Chuck(G)
September 7th, 2010, 09:19 PM
Yeah, the Z80 has the feature of a refresh counter that can be used to freshen DRAMs when the CPU isn't using the bus. The problem is that if one tries to stop the CPU using WAIT or BUSRQ, the address bus is tristated and the refresh counter isn't available.

Schemes to halt the CPU and keep refresh going get pretty complicated. I suppose you could supply your own refresh signal while the CPU was put into a WAT state, however.

MikeS
September 7th, 2010, 09:48 PM
Steve,
I do not know about the Z80 hardware, but I'm pretty sure refresh is a not problem with the dynamic PETs in your scheme. The refresh circuitry is external to the CPU and operates on the opposite phase of the clock on a non interference basis with separate address lines multiplexed to the RAMs.
-DaveYeah, I didn't think it was an issue with the PETs and we were mostly just concerned with validating the ROMs anyway, but Philip wants a more universal solution, especially for/with a Z80 system, which adds a little complexity.