Re: Restoring a NorthStar Horizon, problems with SRAM board
- From: lynchaj@xxxxxxxxx
- Date: 16 May 2007 19:34:52 -0700
On May 16, 10:47 am, Dave.Dunfi...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
(Dave Dunfield) wrote:
Last night I spent some time capturing the state of the machines
configuration, reading, and re-reading the manuals. I wrote down all
the configuration information and compared it to the manual. The
machine has non-standard IO port configurations. If I can establish
the CPU board is working, one idea I am mulling over is to build a
2708 PROM replacement circuit and write a simple debug monitor to
communicate over the unused right serial port.
I was about to ask if you have prom programming abilities - even if
you can't program 2708, you can do a more modern device and build
an adapter. (See note below)
Dave, Thanks for the reply. Yes, that is the plan. I cannot read or
program a 2708 EPROM with my EPROM programmer. The earliest device it
does is a 2716 which is quite different to the 2708 with all its extra
voltage requirements.
My plan is to build an adapter using a 27C16 or 27C64 and wire it up
based on a circuit I found here:
http://home.scarlet.be/~nb010944/zaccpu/e2708.htm
The pinouts mostly match up except for the 2708's extra voltage pins.
I can just ground the unused address lines.
I can give you a handly little 8080 debug monitor that works without
requiring ANY ram - it occupies about 500 bytes of ROM, and will
let you "poke around" with only the CPU and serial port working.
Even if they are not working, you can track the ROM accesses by
the CPU, and once the ROM functions, you can trace the accesses
to the uart from the main polling loop. A scope is most helpful
here, but your logic probe would do.
That would be very nice. Thank you. I have a ROM monitor on the Z80
home built project I did earlier and it works but having a very small
ROM only monitor would help a lot.
Once you get the CPU, ROM and serial port working, then you can
use your console to read/write RAM, detect bad bits, see if the
disk controller registers can be read etc... Very helpful on a
faceless (no front panel) system.
Agree. Once you can use the computer as its own test tool, I think
things will improve dramatically.
I'd recommend bringing up the debugger on your main console
port, not the AUX one - after all that is the one you need to have
working to boot up the system, and knowing it works with the
debugger is a very good sign (default N* drivers are also polled).
Yes, I agree. I will be getting some 14 and 16 pin headers and
building some new configuration units this weekend after I get some
parts.
The biggest hurdle is getting SOMETHING to communicate, once
you get that working, finding the remaining problems will be a lot
easier.
Actually, following in the vein of Herb's comments earlier, I have
been doing some debugging with my VOM and the test procedures in the
manual. I have found some very interesting voltage measurements I
thought I would share:
Checking the clock signal propagation:
PHI (Z80 pin 6, clock input, expected voltage 2.5v for a 50% duty
cycle clock) actual 2v (probably OK)
PHI 2 (MB pin 24, should be similar to above out of phase 180 degrees)
actual 1.89v (probably OK)
PHI 1 (MB pin 25, should be about 50% of above since it is 25% duty
cycle signal) actual .85v (probably OK)
2MHz CLOCK/ (should be about 2.5v for a 50% duty cycle clock) actual
NEARLY 0v (something is broken)
Checking the RESET system logic:
RESET/ (MB Pin 75, button pressed -> LOW expect about .5v, button not
pressed -> HIGH expect 4v) actual button pressed -> LOW -0.05
(practically zero) button not pressed -> HIGH 1.66v (high is less than
logic ONE state so something is definitely broken here)
RESET/ (7G pin 6, button pressed -> HIGH expect about 4v, button not
pressed -> LOW expect .5v) actual button pressed -> HIGH 4.42v, button
not pressed -> LOW 0.17v (seems OK)
RST/ (5G pin 6, button pressed -> LOW expect about .5v, button not
pressed -> HIGH expect 4v) actual button pressed -> LOW 0.17v, button
not pressed -> HIGH 4.35v (seems OK)
POC/ (MB pin 99, button pressed -> LOW expect about .5v, button not
pressed -> HIGH expect 4v) actual button pressed -> LOW 0.17v, button
not pressed -> HIGH 3.38v (seems OK maybe HIGH is just a tad low)
So I am looking into why the 2 MHz CLOCK/ signal voltage is so low and
why the RESET/ pin voltage on the S-100 bus is so low. My logic probe
is not available right now so I am going forward with the static
signals using the VOM. I will save the 2 MHz clock for later.
Doing the RESET/ issue first, looking at the schematic makes me very
suspicious of C21, a 39uF Tantalum capacitor. When I checked it out
with my VOM, it seemed to have quite low resistance for a capacitor
(consistently ~400 ohms in circuit with power off -- I would expect it
be small at first and then grow infinite). I would expect RESET/ on
the S-100 bus to normally be about 4v.
I did some more testing and R17 has nearly zero voltage across it in
the HIGH state. R16 and CR1 are dropping about 3.25v across them
which seems unusual for a pull up resistor and drain diode. C21 is
looking more and more suspicious besides the fact it is tantalum which
are notorious for going bad in old computers. BUT, if C21 is bad, why
didn't it just burn up?
Checking some more lines, with the S-100 chassis reset button not
pressed, the voltage on the CPU /RESET pin is 4.35v which is where
you'd expect it to be for a active low signal. With the reset button
pressed, the voltage drops to 0.2v which is also normal range.
Just out of curiousity, I swapped the CPU board out of my test S-100
chassis and back into the NorthStar motherboard. Oddly enough, the
RESET/ line HIGH is a full 5v there but on the test chassis RESET/
HIGH is only 1.66v. That seems odd but I suspect the NorthStar
motherboard has better termination and is helping the signal out.
Also, I do not think this is a root cause problem since when the reset
button is pushed on either chassis, the CPU board responds correctly.
Tomorrow, I will have to check the 2MHz CLOCK signal on the NorthStar
motherboard and I'll bet the signal will be much higher than the
reading I was getting tonight on the test chassis. The test chassis
is a 16 slot motherboard with just plain resistors for termination so
I bet some CPU cards will have a hard time with it.
Well, that's it for tonight. Maybe we'll get to the bottom of this
mystery yet.
Thanks!
Andrew Lynch
Regards,
Dave
NOTE: A useful gadget that is easily constructed is to take one
of the Dallas NVRAMS like the DS1230 and make a "ROM adapter"
for it - stuff it in something with a RAM socket to put your code into
it, and move it to the adapter to simulate a ROM for your target.
--
Dunfield Development Services http://www.dunfield.com
Low cost software development tools for embedded systems
Software/firmware development services Fax:613-256-5821
.
- References:
- Restoring a NorthStar Horizon, problems with SRAM board
- From: lynchaj
- Re: Restoring a NorthStar Horizon, problems with SRAM board
- From: Herb Johnson
- Re: Restoring a NorthStar Horizon, problems with SRAM board
- From: lynchaj
- Re: Restoring a NorthStar Horizon, problems with SRAM board
- From: Dave Dunfield
- Restoring a NorthStar Horizon, problems with SRAM board
- Prev by Date: Re: Restoring a NorthStar Horizon, problems with SRAM board
- Next by Date: Re: Restoring a NorthStar Horizon, problems with SRAM board
- Previous by thread: Re: Restoring a NorthStar Horizon, problems with SRAM board
- Next by thread: Re: Restoring a NorthStar Horizon, problems with SRAM board
- Index(es):
Relevant Pages
|
