28 May
2008
28 May
'08
10:08 p.m.
So I've got my "hacked-up" PET powering up after redoing a bit of wiring
on the power supply. I replaced a couple of obviously bad 74LS157's in
the video generator section (legs were corroded and some had fallen
off/cracked) and reflowed a couple of suspicious looking joints.
The machine now powers up, the display is bright and crisp but I just
get garbage characters on the display. Using my logic probe I've
verified that the CPU is running, voltages appear nominal (4.9V at the
CPU & RAM). The CPU seems to be running something, in that about 1-2
seconds after power up a few characters on the screen will change (not
where you'd expect the COMMODORE BASIC banner to be printed, but always
in the same places). Typing on the keyboard produces no effect.
I've reduced the board to 4K of 2114s and tried swapping around the
2114s used for the display, but the only effect this has is to change
the pattern of garbage characters displayed (interestingly (at least to
me) each RAM chip produces a different pattern, which is reproducible).
If I run without any video RAM installed, I just get a checkerboard
pattern onscreen, which would make sense since character FF is the
checkerboard tile. Unfortunately I have no idea if any of the 2114s I
have are good or not, though I'd wager that they can't ALL be bad. I
don't have any other machines that use them and I don't have any spares.
Any suggestions on logical places to start looking from here?
Thanks,
Josh
29 May
29 May
2:59 a.m.
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.
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.
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...
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?
Thanks,
Josh
Josh Dersch wrote:
So I've got my "hacked-up" PET powering
up after redoing a bit of
wiring on the power supply. I replaced a couple of obviously bad
74LS157's in the video generator section (legs were corroded and some
had fallen off/cracked) and reflowed a couple of suspicious looking
joints.
The machine now powers up, the display is bright and crisp but I just
get garbage characters on the display. Using my logic probe I've
verified that the CPU is running, voltages appear nominal (4.9V at the
CPU & RAM). The CPU seems to be running something, in that about 1-2
seconds after power up a few characters on the screen will change (not
where you'd expect the COMMODORE BASIC banner to be printed, but
always in the same places). Typing on the keyboard produces no effect.
I've reduced the board to 4K of 2114s and tried swapping around the
2114s used for the display, but the only effect this has is to change
the pattern of garbage characters displayed (interestingly (at least
to me) each RAM chip produces a different pattern, which is
reproducible). If I run without any video RAM installed, I just get a
checkerboard pattern onscreen, which would make sense since character
FF is the checkerboard tile. Unfortunately I have no idea if any of
the 2114s I have are good or not, though I'd wager that they can't ALL
be bad. I don't have any other machines that use them and I don't
have any spares.
Any suggestions on logical places to start looking from here?
Thanks,
Josh
30 May
30 May
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
5:49 a.m.
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.
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.
Assuming that it is clocked and has been reset correctly, there are
generally only two reasons that a CPU stops running (fetching opcodes):
1) It is being held in a hardware wait state.
Check the state of the RDY line on the 6502 and if it
is asserted, backtrace through the circuit to find out why.
2) It executes an instruction which causes it to stop
Usually a HALT instructionor of some sort or other, there are sometimes
undocumented opcodes which cause this behaviour as well - A bit of
net searching should turn up details on the undocumented opcodes.
There are generally two reasons why a processor would execute an opcode
to shut itself off:
1) On purpose
Usually while waiting for an interrupt - given that you PET hasn't
even cleared it's screen, I doubt this is the case.
2) By executing "random" code
Can be caused by:
- Bad ROM - actual code gets corrupted
- Bad RAM - stack failure results in "return" to random address
- Bad bus buffers - hardware failure resulting in corruption in the
address or data buses.
- Bad decode logic - no device or multiple memory devices being
selected when only one should be.
I've seen a least two 2001's with bad ROM chips. And a number of PETs
with bad RAM - I'd suspect one of these two.
If you have a storage scope, you should be able to trigger on the
SYNC signal at the CPU and catch the last few opcode fetches - walking
the data and address bus signals and writing them down will reveal
the last opcode executed and the address from which it was executed.
Look at the opcode that was executed to see what exactly caused the
CPU to stop.
Try this a couple of times and see if the CPU is always stopping in
the same place. Scope the select lines and note *which* ROM was
selected for the last opcode fetch, or in the case of a "wild" access,
which ROM was selected last before it stopped.
If the address where that opcode was fetched in within the ROM, get
the PET rom binaries and see if it's "supposed" to be there - a bit
of disassembly around that address should tell you if the code is
real code, or some random bit of data that the processor wandered
off into. If you can read the PET ROMs (I made an adapter to stuff
them into my homebuild EPROM programmer) you can compare against the
binaries to check the entire ROM content - The PET roms are not standard
pinouts - but you can make an adapter to put a normal ROM in the
socket - IIRC I needed a TTL chip to provide an extra select - I've
got photos on my site of a PET that I had to repair this way.
If the address is NOT within the ROM, trigger on the ROM select and
see what the last opcode executed from ROM was - if it was RTS or
RTI I would strongly suspect a RAM problem. It might also be a jump
indirect (same suspicion). As above, look at the code contained at
this address and see it if "makes sense" as a valid place to be
executing.
With a decent scope you can get several fetches on the screen, and
therefore determine the opcode/address for the last few instructions
executed - If you can't get any of that to make sense, try single-
shot trigger and capture the first few instructons executed - see if
they make sense and match the ROM.
With a bit of poking around you should be able to determine what the
processor is doing at the time it went insane - hopefully at some point
the "ah-ha" light will go on.
Regards,
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
9:52 p.m.
Dave Dunfield wrote:
RDY is being held high, which I believe is correct (my understanding
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.
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.
Assuming that it is clocked and has been reset correctly, there are
generally only two reasons that a CPU stops running (fetching opcodes):
1) It is being held in a hardware wait state.
Check the state of the RDY line on the 6502 and if it
is asserted, backtrace through the circuit to find out why.
from reading 6502 specs indicates this is held low to
halt the CPU...)
2) It executes an instruction which causes it to stop
Usually a HALT instructionor of some sort or other, there are sometimes
undocumented opcodes which cause this behaviour as well - A bit of
net searching should turn up details on the undocumented opcodes.
There are generally two reasons why a processor would execute an opcode
to shut itself off:
1) On purpose
Usually while waiting for an interrupt - given that you PET hasn't
even cleared it's screen, I doubt this is the case.
2) By executing "random" code
Can be caused by:
- Bad ROM - actual code gets corrupted
- Bad RAM - stack failure results in "return" to random address
- Bad bus buffers - hardware failure resulting in corruption in the
address or data buses.
- Bad decode logic - no device or multiple memory devices being
selected when only one should be.
I've seen a least two 2001's with bad ROM chips. And a number of PETs
with bad RAM - I'd suspect one of these two.
On a whim, I ran the machine without any of the ROMs installed and I get
identical behavior to what I was already seeing (brief CPU activity,
then nothing). I suspect the CPU is just reading garbage and
something's broken between the CPU & RAM. The CPU's probably halting
on a bogus instruction... I'm going to do some investigation in that area.
Thanks for the suggestions...
Josh
If you have a storage scope, you should be able to
trigger on the
SYNC signal at the CPU and catch the last few opcode fetches - walking
the data and address bus signals and writing them down will reveal
the last opcode executed and the address from which it was executed.
Alas, I don't. My 'scope's an ancient Tektronix 561A. Works great,
but
it's pretty simple. (And maybe a bit underpowered for this particular
task...)
Look at the opcode that was executed to see what
exactly caused the
CPU to stop.
Try this a couple of times and see if the CPU is always stopping in
the same place. Scope the select lines and note *which* ROM was
selected for the last opcode fetch, or in the case of a "wild" access,
which ROM was selected last before it stopped.
If the address where that opcode was fetched in within the ROM, get
the PET rom binaries and see if it's "supposed" to be there - a bit
of disassembly around that address should tell you if the code is
real code, or some random bit of data that the processor wandered
off into. If you can read the PET ROMs (I made an adapter to stuff
them into my homebuild EPROM programmer) you can compare against the
binaries to check the entire ROM content - The PET roms are not standard
pinouts - but you can make an adapter to put a normal ROM in the
socket - IIRC I needed a TTL chip to provide an extra select - I've
got photos on my site of a PET that I had to repair this way.
If the address is NOT within the ROM, trigger on the ROM select and
see what the last opcode executed from ROM was - if it was RTS or
RTI I would strongly suspect a RAM problem. It might also be a jump
indirect (same suspicion). As above, look at the code contained at
this address and see it if "makes sense" as a valid place to be
executing.
With a decent scope you can get several fetches on the screen, and
therefore determine the opcode/address for the last few instructions
executed - If you can't get any of that to make sense, try single-
shot trigger and capture the first few instructons executed - see if
they make sense and match the ROM.
With a bit of poking around you should be able to determine what the
processor is doing at the time it went insane - hopefully at some point
the "ah-ha" light will go on.
Regards,
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
1 Jun
1 Jun
5:36 a.m.
If you have a
storage scope, you should be able to trigger on the
SYNC signal at the CPU and catch the last few opcode fetches - walking
the data and address bus signals and writing them down will reveal
the last opcode executed and the address from which it was executed.
Alas, I don't. My 'scope's an ancient Tektronix 561A. Works
great, but
it's pretty simple. (And maybe a bit underpowered for this particular
task...)
5815
days inactive
5818
days old
5 comments
3 participants
participants (3)
-
dave06a＠dunfield.com -
derschjo＠msu.edu -
ethan.dicks＠usap.gov