Debugging a CP/M 2.2 program

[Derry UK]

I may have asked this before, forgive me, I am oldish <cough>, but I would like to debug a program I am writing.
I need a VT100 type display separate from the debugger, ie my program display won't be overwritten by debug output.
I would like the usual register display and edit, single step, set a breakpoint etc.
and ......

It must be usable by an old programmer that has lost a cell or two but still enjoys writing Z80 code (it keeps me off the streets at night.)

Any ideas?

Thanks,

Derry.

[Bill McMullen]

Although I developed them for a different reason, my solution to that debugging issue is to use one of my eZ80 systems.  The eZ80 supports the ZDS debugger via a hardware interface totally independent of CP/M and other software.  Another unique benefit is that it can put breakpoints on flash or ROM addresses.

[Ed Silky]

Hi Derry,

I am getting close to being done with my Z80 In-circuit Debugger (ZID). It has a probe that plugs in in place of the Z80. It gives you full hardware debugging independent of the system it is plugged in to. If you want to read a description, the GitHub README has an overview (link below). I designed the original version for the company I worked for in the late 70's, 80's, and early 90's. I still have one of those original units and I decided to create an updated version. I've been running a prototype for a couple months and I have PCBs arriving next week. It will take me a little bit to adjust my current debug monitor from the prototype to the real PCB, but once I have the real thing working I'll be looking for someone that would be willing to do some testing.

The GitHub is here: https://github.com/AESilky/sd-zid

I'm kinda hoping that I can find someone that debugs both hardware and software, or at least software on a number of different hardware configurations, to really give it a good workout, but it can certainly be used to just debug CP/M programs.

Here are a couple pictures of the prototype with my original version plugged in to allow me to get it working.

 

The board that I used to wire up the prototype is a Z80 SBC that I designed, I just used the Z80, Flash, RAM, and Expansion Header on it (kept me from having to breadboard all of those signals). The board at the top is an Atmel/Microchip ATF15xx Dev Kit with an ATF1508 module plugged on it. The board on the right is my Z80-Emulator-Debugger (ZED) from the early '80s. Most of the connections to/from the ATF1508 are through the expansion bus connector on my SBC board. The second photo shows it running on its own Z80 and also shows the RP2040 module being debugged. The RP2040 module runs the debug monitor user interface and provides the connection to a terminal (using TeraTerm, PuTTY, etc.). Running most of the debug monitor on the RP2040 module keeps interruptions to the target system at a minimum. Of course, when a breakpoint is hit the target is completely interrupted, and when a single-step is performed, only the single instruction (and any of its affects) is executed.

Where are you located? I'm in Western Washington near Seattle. If you're interested, I'll keep you in mind as a beta tester.

-Ed

[Ed Silky]

It doesn't seem like the images came through on that (I had copy-pasted them). Here is a 2nd attempt with just the images.

Image1: 1980's ZED on left plugged into the Z80 socket on my Z80 In-circuit Debugger (ZID) prototype for debug, test, and development of the debug monitor.

Image 2: Prototype further along. Now running on its own Z80 with the RP2040 module being debugged (it provides the Debug Monitor User Interface and terminal connection - the actual RP2040 module can be seen on the work surface in the upper right).

[Ed Silky]

BTW... During development of this (using 2 highly utilized ATF1508 CPLD's) I found, reported, and got acknowledgement of 3 separate Microchip issues. One was with the Cupl assembler/compiler. The other two were with the Fitter. I made note of them in the PLD files (for Cupl and one of the Fitter issues) and the Makefile (for the 2nd Fitter issue).

-Ed

--
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 visit https://groups.google.com/d/msgid/retro-comp/19957337-95a6-441b-aced-fde48bc91553n%40googlegroups.com.

[Doug Jackson]

I have a ICE made by Nicolet.  Its called Z80 NICE.  

Its trivial to use.  Simply plugs into the CPU socket instead of the CPU.

Plug in a VT100 terminal and get register level debugging.

It even includes Intel Hex upload/download and memory tests...

Somebody reverse engineered it years ago.

Doug

--

[Alan Cox]

I just build emulators for the systems I am debugging and work from those. It's not 100% authentic but they were used by people who could afford the CPU resources at the time and by the later end of the 1980s people were also using hardware boards that could stop, read/write memory and the like to do game development on 8bit machines so I don't feel it's that unauthentic except it no longer involves running Fortran emulations over a 300 baud modem to compu$erve or similar on a 36bit DEC box. I'm sure with a bit of work and SIMH you could replicate that experience too 8)

With DDT it's can be possible to modify your own program to use AUX not CON so that your program output is on the aux serial port and the DDT session the console. There are also some later rather fancier tools like Z8E (https://github.com/hperaza/Z8E) which could run off the aux port themselves.

Alan

--

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 visit https://groups.google.com/d/msgid/retro-comp/7e4f0f07-7ec8-4226-a279-f9ddaabf37f7n%40googlegroups.com.

[Ed Silky]

I have a ICE made by Nicolet.  Its called Z80 NICE. 

@Doug, I remember that. The company I worked for (TRIAD System) bought one to compare to the one I designed. It was a nice little unit, but (as I remember) we couldn't use it due to some speed constraints and also with how it handled HALT. We also traded units with Zilog. The Zilog unit was too large/limited in how it could plug in (some of our boards were buried well within system enclosures). In total, about 30 of my units were made for use by our programmers and hardware engineers.

-Ed