• Please review our updated Terms and Rules here

Z80 cpu plug-in diagnostic

P

pavery

Experienced Member
Joined
Dec 29, 2008
Messages
160
Location
New Zealand
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
 
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) said:
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. Or you can google for "Z80 in-circuit emulator".
Click to expand...

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
 
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
 
pavery said:
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
Click to expand...
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.
 
MikeS said:
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.
Click to expand...

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
 
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.
 
Chuck(G) said:
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.
Click to expand...
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?
 
MikeS said:
Yeah, at the time I was just thinking about a static RAM PET.
Click to expand...
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
 
Last edited:
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.
 
dave_m said:
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.
-Dave
Click to expand...
Yeah, 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.
 
You must log in or register to reply here.
Back
Top