Retrocomputing, part 2

[slburris]

Here are some links to high resolution PCB images.

There are each about 5MB in size:

front - http://www.electroscott.com/images/P1000918.JPG

back - http://www.electroscott.com/images/P1000919.JPG

Scott

[slburris]

Here's the first serious errata.

The symbol for the MCP131 voltage monitor is backwards.
So as installed, it holds the RESET line low permanently and
the processor doesn't operator.

The fix is to ignore the silkscreen on the board and turn
the TO-92 package around.  Then it's connected properly.

I did that and now my Z80 CPU free runs.  Monitoring M1,
I can see machine cycles being run.

Next up, I need to make a diaignostic EPROM of some sort and
program the GAL, then test the outputs of the GAL to make sure
they are doing the right thing.

Scott

[slburris]

So here's what I'm going to do for diagnostics.

I'm going to read from each of the SIO, CTC, PIO, and Compact Flash
ports in a loop.  The first port I will read once per loop, the second port
I will read twice, and so on.

Then, by monitoring both IORQ and a particular chip select line, I should see
the correct burst of 1, 2, 3, or 4 selects per cycle, if the GAL is programmed
correctly.  If not, I'll have to figure it out.

If needed, I'll pull out the Tektronix 1240 logic analyzer, but I'm hoping this will
go well enough to make that unneeded.

Here's the program I'm going to put into the EPROM:

0000                1   org     0
0000                2
0000                3 siobase   equ     $00
0000                4 ctcbase   equ     $20
0000                5 piobase   equ     $40
0000                6 cfbase    equ     $60
0000                7
0000                8 loop:
0000 db 00          9   in      a,(siobase)
0002 db 20         10   in      a,(ctcbase)
0004 db 20         11   in      a,(ctcbase)
0006 db 40         12   in      a,(piobase)
0008 db 40         13   in      a,(piobase)
000a db 40         14   in      a,(piobase)
000c db 60         15   in      a,(cfbase)
000e db 60         16   in      a,(cfbase)
0010 db 60         17   in      a,(cfbase)
0012 db 60         18   in      a,(cfbase)
0014 18 ea         19   jr      loop
22 bytes code generated and 5 labels defined

Scott

[slburris]

Picked up a bunch of 27C256 EPROMs from my collection and put them
in the EPROM eraser.  Can't remember how long they are supposed to be
in there, so let's try 1/2 hour.

I'm having flashbacks to how I built stuff like this in the mid 1980's! :-)

Scott

[slburris]

So I programmed an EPROM, programmed a GAL, plugged them
in, and ..... nothing.

No IORQ cycles at all, which means not even the part of the GAL
dealing with memory address decoding is working properly.

Back to debugging...

Scott

[slburris]

Uh oh, I grabbed a Lattice GAL20V8 instead of an Atmel ATF20V8 and
I made the fuse map with Atmel's version of WinCUPL.

It's been so long since I programmed GALs, that I can't remember if the
fuse maps are identical between different manufacturers...

Scott

[slburris]

Poking around with my trust Rigol scope, it appears that the GAL isn't working.
I can't seem to find any Atmel 22V10's, but I have plenty of Lattice Semiconductor
22V10's.  So I'm now downloading their "classic" software and I'll have to figure out
how to generate a fuse map all over again.

Turns out even though the software is free, they *still* require a license.  So I'm
awaiting a license key in email.

Maybe I should have done all the memory and I/O decoding in discrete logic, but the
board already has so many chips on it to do so little.

When I built my first CP/M computer from scratch after the Altair, I wirewrapped a
ton of chips together.  It worked, as long as you didn't breathe too heavily on the board.
I learned over time if the system didn't boot to press just so in a certain area on the
board.  Must have been an intermittent wire wrap.

This PCB should be much more reliable, once I get past these early startup problems....

Scott

[slburris]

Well, that was pretty stupid.  I actually pulled a GAL20V8 instead of a
GAL22V10 and programmed it with the fuse maps of a 20V8.  Uh, that's
not going to work....

I picked a 22V10 and now things are looking much better.

Remember how I was going to do one I/O read from the SIO, two
from the CTC, and so on?  Here are capatures of !siosel, !ctcsel, !piosel,
and !cfsel.  See how the groupings increase each time?

This verifies that the GAL is at least mostly working, plus the EPROM
is working, woohoo!

Now I have to get the serial port to print "Hello World!" :-)

Scott

[slburris]

Here's a shot of the power input jack that's too close to the polyfuse
and input diode.  Kinda hit it with the soldering iron....

Scott

[slburris]

My attempt to solder the tiny FTDI chip.  It looks slightly
off, but should still work, I hope.

Scott

[slburris]

And I'm currently stuck trying to get the USB chip to be
recognized.  For awhile I had convinced myself that I had
wired the mini USB-B connector backwards, but comparing
to some commercial products, it's OK.  I did have a bad
solder joint connecting the GND pin, so that had me
scratching my head for a bit.

But when I plug it in to a computer, the FTDI chip seems to
immediately go into SUSPEND mode.  The computer doesn't
see it as a USB uart chip, and FTDI's EEPROM setting utility
doesn't see it either.  I'm following the self-powered diagram
in the FT232R datasheet, but no joy.

I must be doing something stupid wrong, but I'm not seeing
it tonight.  Maybe tomorrow will be a better day.

On another note, I had forgotten how hot these NMOS chips
got.  And the Lattice GAL chip is the hottest of them all, even
though I'm using an LP (low power) version.  Even the LP version
draws 90ma at 5v, that's almost 1/2 watt!

Scott

[slburris]

Well, things are still not going well in USB land.

I found a bad solder joint at the USB connector such that the
USB D+ line wasn't making contact.  That's now been repaired.

So when I plug the board into windows, it now says that's
it's detected a new device, yea!

Then it says this USB device is broken, boo!  I can't seem
to see the device with FTDI's programming utility either.

Am I going to have to capture what's going on with the USB data
lines to figure out what's going on?  I hope not -- this would take
me far off my field of expertise.  The whole point of using the FTDI
chips is to not have to really know anything about USB.

Scott