Troubleshooting the EZ-Retro Apr 2017

Here is the eZ80 chip, hand-soldered on the new EZ-Retro v2 PCB:

The trouble is: something is very wrong: with my lab power supply set to 3.3V and a 30 mA maximum current limit, the voltage drops to 0.06V - whoops!

This low voltage points to a short, since there’s not even a diode drop left. This was actually the second build. In the first one, I had already mounted everything at the same time - which is a nice act of optimism, but not such a great idea for a non-trivial new and untested PCB …

After some head-scratching, I found my mistake: pin 72 was labeled Vcc, where it should have been labeled GND. And so EAGLE dutifully connected it to Vcc, along with all the other pins. Of course, internally this pin was still connected to GND, so this created a direct short between Vcc and GND. Luckily, pin 72 is a corner pin and was very easy to lift up with a soldering iron:

Now, the current consumption is 25 mA, which is about right according to the eZ80 datasheet.

Another problem, is that while desoldering the F103, I accidentally damaged pin 55 on the eZ80, which is the hardware RESET. Here is the nasty damage, seen through a microscope:

Barely a shred left to connect to (!), but with some very careful soldering (first to the pad, then to the remaining stub), I was able to attach an AWG 30 wire to restore the connection:

On to the next error (some bugs tend to hide other ones!): the ZCL/ZDA wires which connect to the eZ80 in a JTAG-like fashion, need to be on pins 67 and 69, respectively. And guess what happened (see above image): I misread the schematics and connected them… off by one - oops!

More fixing, although these two corrections were not nearly as difficult. I merely had to cut two traces and then carefully solder two bypass wires to the correct pins:

A full-size overview should give you an idea of the minute scale involved in all this fiddle-fixing:

For completeness: there was one more hardware error on this board, caused by a bad solder joint on the SRAM “D0” signal (pin 9). This was easily diagnosed once the PokeMon software had been installed on the STM32F103 board. A little heat and solder was enough to fix that.

Sooo… on to the software side of things: redefining a few pins in the software (the v1 design differs slightly in some of the signal connections between F103 and eZ80), loading the USB-console version of Mecrisp via SWD, and then loading PokeMon into flash memory.

Then I uploaded the “disk2.fs” disk image (the same as the recent v1 build) into the eZ80’s on-board flash, and – yippie!it all started working as intended, with 2 MB of SRAM this time:

A: R/W, Space: 350k
B: R/W, Space: 208k
C: R/W, Space: 1432k

Needless to say, having had a fully working setup before made all the difference in the world.

As check that the new 2 MB SRAM chip does indeed work properly, a wr1280k.c test was written in C and compiled with BDS C 1.60, which writes out 1280 KB of pseudo random data and then reads it back to verify that the data file contains exactly what was written out:

Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes
WR1280K COM    4K
1 File(s), occupying 4K of 1432K total capacity
255 directory entries and 1428K bytes remain on C:

C>b:stat data.tmp

 Recs  Bytes  Ext Acc
10240  1280k   80 R/W C:DATA.TMP
Bytes Remaining On C: 148k

This worked perfectly, but … it did take over half an hour to complete on the eZ80 @ 8 MHz.

The µSD card hasn’t been connected yet, that’s still waiting for a matching µSD socket to fit on the F103 board (bottom side). But so far so good, after this tricky hardware debugging cycle.

This is well on the way to becoming the smallest & most powerful CP/M setup I’ve ever owned. Which isn’t such a big deal in 2017, of course, but hey - it’s all about the retro-computing fun!

Weblog © Jean-Claude Wippler. Generated by Hugo.