30 Aug
2014
30 Aug
'14
6:49 p.m.
On 2014-Aug-30, at 5:29 PM, drlegendre . wrote:
But the machine is still missing its marbles - bearing in mind that my only
references are the Altair32 emulator and the documentation check-out
procedure. On power-up, the panel LEDs match the pattern on the emulator,
so that's good. But still, I can't get any sanity out of examine / deposit
memory locations.. nada. The ex. next and dep. next will walk up the range,
as indicated by the address LEDs, but I can't get any kind of data from the
data LEDs. They're either all 'on' or all 'off', in most cases.
I've tried this with the termination power both enabled & disabled, no
difference.
Unless anyone has a suggestion, I don't know what to do other than wait for
the arrival of the new SRAM board, and see how it behaves when that's
installed. Thing is, I have no real reason to doubt the existing DRAM board
- other than the fact that I've been warned off of using DRAM with the
original 8080A CPU board. And again, I can't say that the DRAM board is any
more alive than the socket it's stuck in..
Any ideas? SRAM should be here on Tues or Weds.
Note the same bank configuration issue being discussed can be expected to apply to the
DRAM board.
A simple test of the data LEDs would be to:
- pull the DRAM board, upon power-up all data LEDs should be ON,
- find the DI0-DI7 lines on the S100 bus,
- and carefully short them to ground one at a time, the corresponding LED should
go out.
If the data LEDs are an unchanging all-ON with the DRAM board installed, even as the
address is changed, then some possible problem areas are:
- the board isn't configured correctly and so isn't being enabled
- a hardware problem in the board enable circuitry
- a hardware problem in the board DIn drivers, such that data isn't making it through
to the bus.
If the data LEDs are an unchanging mixture of OFF & ON with the DRAM board installed,
even as the address is changed, then some possible problems are:
- a hardware problem around the board DI drivers, such that the DI drivers always feed
the same data pattern to the bus
- a hardware problem around the RAM chips such that they always feed the same pattern to
the DI drivers.
(.. the above being necessarily vague given the symptoms presented so far.)
(.. and assuming sanity checks on such things as on-board power supply levels have checked
out as OK).