S-100 System Debugging for Beginners.
monahanz
S-100 system that is "dead" and ask for advice on how to get it going
again. Indeed over the years I have blown a few of my own systems and
had to resuscitate them.
Anyway I added to www.S100Computers.com, a page with things I found
helpful over the years to revive dead systems. Most are, I am sure
known to the hard core members of this group, but if you have other
suggestions please let me know. It's tough these days for a beginner
to get started!
Please see:-
http://s100computers.com/My%20System%20Pages/Debugging/Debugging%20for%20beginners.htm
Enjoy!
s100fan
hardware restorers, so this "Debugging for Dummies" will be very
helpful. I plan to follow it through step by step.
Unfortunately, my system has all RAM on a separate dynamic RAM board
and a dubious boot EPROM located on the i/o board, so getting to first
base has been elusive so far over several months of trying this and
that and in spite of advice from a number of experienced experts on
this list and off-line. A single-step approach makes sense. Here's
hoping!
Rick
On Nov 9, 5:40 pm, monahanz <mona...@vitasoft.org> wrote:
> From time to time I get calls or e-mails from people that have an old
> S-100 system that is "dead" and ask for advice on how to get it going
> again. Indeed over the years I have blown a few of my own systems and
> had to resuscitate them.
>
> Anyway I added towww.S100Computers.com, a page with things I found
> helpful over the years to revive dead systems. Most are, I am sure
> known to the hard core members of this group, but if you have other
> suggestions please let me know. It's tough these days for a beginner
> to get started!
>
> Please see:-http://s100computers.com/My%20System%20Pages/Debugging/Debugging%20fo...
>
> Enjoy!
monahanz
>
> - Show quoted text -
Rick, in such situations I have an old 4K RAM board and an old PROM
board to step by step get going. You can them for next to nothing on
the web. Always good to have. That way you can checkout your CPU card
first, then the Dynamic RAM, then the ROM etc. Try and step things
along starting from the most basic system first. Thats the advantage
on the S-100 bus.
All...@localhost.net
Generally the "divide and conquer" strategy is the best way to
progress.
In any S100 debug situation I've found having a know good memory on
hand or help from someone else to establish a known good memory
is critical.
If you can team up with someone that has a working system (or you have
one) then that makes the work easier as you can systematically test
and correct individual boards in the working system.
Experince has been, CPUs are least likely to fail, Memory most likely
and IO boards are most likely to be damaged closest to the external
connection (printers, punches and terminal IO).
The single most distructive then I've seen done is inserting or
removing a board with power on. Usually all the bus drivers on every
board take a hit. This is very common to new users as often they are
not aware that the big capactitors need time to discharge after the
power is turned off. They hit the switch and before a few seconds
elapse grab a board and pull. Very bad for the boards.
Another thing is found systems that haven't been run or are unknown
may have been used for a parts dog and all the boards have issues.
I had a machine like that, even bad chips were subbed on to boards
that also had bad sockets..
Allison
dke...@hotmail.com
> hardware restorers, so this "Debugging for Dummies" will be very
> helpful. I plan to follow it through step by step.
>
> Unfortunately, my system has all RAM on a separate dynamic RAM board
> and a dubious boot EPROM located on the i/o board, so getting to first
> base has been elusive so far over several months of trying this and
> that and in spite of advice from a number of experienced experts on
> this list and off-line. A single-step approach makes sense. Here's
> hoping!
>
> Rick
>
Hi
The first thing to do is to write some test code that you can blow an
EPROM.
Remove the RAM board.
The simplest test is to check the address line. This can be done with
just the
CPU board. Depending on the processor used, it will normally read 0FF
from the
bus ( if not, adding some simple pullup resistors will cause this ).
This generates continuous RST instructions. By triggering the M
states,
one can look to see if all the addresses are generated. One can also
check
that all the write data lines are working as well.
This is relatively easy to do. Progress to an EPROM test that only
uses the processor and EPROM. The one I like is a simple loop that
toggles some I/O bit I can see on a 'scope.
This first one should be a tight loop. If that works, fill the EPROM
with mostly
NOPs and put a jump to the beginning at the end. This will help to
make sure
that the entire EPROM gets addressed.
Continue to work towards more complicated operations. Adding the RAM
board
and doing simple write/read test. Start with a single location and
work up to
a more complete test.
Think in terms of the simplest test at each state and then move on to
the
next more complicated test.
Dwight
JackRubin
> and IO boards are most likely to be damaged closest to the external
> connection (printers, punches and terminal IO).
>
yep - having a few spare MC1488/1489 line drivers on hand is always
helpful.
Jack
monahanz
>
> - Show quoted text -
particularly easy to do during hardware repairs when there are few
boards in the system anyway. The +8 volts takes a longer time to drain
down and there are fewer lights as a reminder.
I had large 1W ten Ohms “bleed” resistors across the capacitors of the
linear power supply. Have not done it yet on my new switching power
supplies – is on my list.
A very good point Dwight! I will add this to the entry. Its
particularly easy to do during hardware