30 May
2008
30 May
'08
12:39 a.m.
On Thu, May 29, 2008 at 02:59:33AM -0700, Josh Dersch wrote:
Got out my ancient oscilloscope and did a bit of
probing and got a
little more info:
On power up, the CPU reset line is held low for ~1 sec, then goes high.
I don't know the RC constants, but that doesn't sound bad.
At this point if I look at the address/data lines, I
can see a very
brief burst of activity and then nothing at all (it's during this
activity that a few characters on screen change). After this activity,
all address lines are high. IRQ & NMI lines are high. CPU is being
clocked throughout all of this, clock rate seems to be correct.
Hmm... if there's a flurry of activity, it sounds like the CPU is getting
out of RESET, then fetching the reset vector, jumping to the code above
$F000 and trying to run.
I found an old S-100 static ram board which is
populated with TI
TMS4045-45NLs -- from the datasheets I was able to find, these look to
be 2114 compatible, am I correct in this assumption? If they're
compatible I'll try them in the PET and see if it makes any difference...
Are they the same width? I have a dim memory that TMS4045s are wide DIPs
(0.4") not narrow DIPs (0.3").
Real 2114s do fail, and should be easy pick up from plenty of places
like BG Micro. The original static PET used a 0.4"-wide 1Kx4 SRAM
with something like a 450ns access time - really, really slow. I don't
think any 2114s were as slow (more like 350-200ns). Any 2114 should
do the trick.
There's an LED on the PET logic board which does
not light up when power
is applied. Is this supposed to be on at powerup, or is it activated by
some hardware/software activity?
That is the "diagnostic LED". It's only lit when you ground the diagnostic
pin on the User Port (see any set of vintage C= PET docs for the exact pin)
_and_ you are running with the "diagnostic clip" (IIRC)... it's a 40-pin
test clip with an attached plastic box with some active circuitry. You
should also have keyboard and (I think) tape interface loopback connectors.
I have such a rig at home, but not with me.
As for where to go... the behavior you describe (tries to start up but
goes into the weeds) - it's consistent with bad zero page RAM. I have
a Fluke 9010A at home with a 6502 pod - that would pin down your problems
in seconds. Barring that, you could have anything from a problem getting
good ROM results (bad chips from $F000-$FFFF or bad selectors, etc) to
bad RAM chips or bad RAM decode logic, etc.
With a newer (ROM 2.0) PET, you can ground the diagnostic pin and it
will dump you into the TIM monitor rather than BASIC. Unfortunately,
ROM 1.0 PETs lack TIM in ROM (it was supplied on tape). I remember the
joy with my first PET, since all of my experience was with 4K PETs
at the library - somehow I was fiddling with SYS calls and ended up
in TIM - and was *shocked* it was in ROM.
Sort-of worst case, if you have the ability to burn 2K EPROMs or don't
mind building an adapter for a standard EPROM emulator, you could always
write your own code to do *something* that doesn't depend on zero-page
RAM working and see if you could toggle a User Port pin or something
simple. If that works, your ROM works - you could then test RAM and
see how it behaves. Of course, if you have access to a Fluke 9010A
and 6502 pod, _that_ can be used to test RAM, checksum ROM, read random
locations, twiddle I/O ports, etc. It's a _really_ versatile device
for bare-metal debugging (mine came from Software Results and was used
extensively for poking around dead MC68000-based COMBOARDs). If you
don't have a Fluke, the base unit can be had cheaply, but the money
is in the pods (I'd love to find a Z-80 pod and maybe one or two others
to round out my set).
Another useful tool is a 6502 with the D0-D7 pins bent up and wired to
force a NOP... it will fetch $EAEA (ISTR) and start executing there and
free-run through the memory map - no matter what's really happening on
the bus, the address pins should count up as the CPU endlessly fetches
NOPs. Unlike the Apple II board, the PET won't do strange things on
read accesses - i.e. no "side effects" - you can watch A15 and see it
toggle at half the rate of A14, etc. From there, you can check various
/CS pins on RAM, ROM and I/O chips, and they should show a regular
pattern that corresponds to the memory map - any obvious deviations
(like no RAMSEL) should help narrow down what isn't being selected.
It won't help find bad SRAM chips, but that's what a RAM tester can
do for you.
The other thing about PETs is that the sockets are notoriously crappy.
even just reseating all the socketed chips can help. I have a 32K
Dynamic PET I got new in 1978 that seems to need new 40-pins sockets
for the I/O chips - it was working before I stopped using it, then
in (indoor) storage, the IEEE port "went out". I've tried new 6520s
and 6522s, but no go - the next time I crack it open, I'll replace the
sockets with machined-pin sockets and then continue debugging.
Keep us informed as to your progress. It's a great machine!
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 30-May-2008 at 07:20 Z
South Pole Station
PSC 468 Box 400 Temp -77.6 F (-60.9 C) Windchill -113.4 F (-80.8 C)
APO AP 96598 Wind 9.4 kts Grid 96 Barometer 671.8 mb (10939 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html