27 Aug
2014
27 Aug
'14
1:45 p.m.
On 2014-Aug-27, at 10:58 AM, drlegendre . wrote:
On Tue, Aug 26, 2014 at 11:58 PM, Brent Hilpert
<hilpert at cs.ubc.ca> wrote:
--- DBIN:
(eric:) Scratch all my conjecturing about DBIN and inadequate memory boards.
Found a more complete 8080 processor manual with better timing diagrams (at bitsavers of
course), and going through the machine cycle in more detail it seems the front panel is
halting the processor part way into the first machine cycle of an instruction, at which
point DBIN should be asserted, and should remain asserted through the idle / front panel
display period. This makes more sense inasmuch as the alternative would have left very few
memory boards to work with the front panel. Was led down a wrong path by the distinction
in use/nonuse of DBIN by different memory boards.
dr: you might measure the state of the bus PDBIN line while in the halt/stop state and
let us know.
--- Memory board :
So back to your memory board, the configuration of that board should be confirmed for
operation as required in your system.
It could be helpful to know which board you have there.
In addition to the typical address-range enable, S100 memory boards could commonly have
two additional enabling schemes:
- Bank enable/disable - allowed memory sizes greater than 64K by allowing memory boards
to be enabled/disabled by writing to a dedicated I/O port.
Your board/bank needs to be enabled as bank 0 or bank operation disabled.
- Phantom disable - allowed a memory board to be disabled at reset and later enabled
under program control,
to allow initial overlaying by boot ROMs.
The phantom function should be disabled (the board should ignore phantom, so its always
enabled)
--- Mem protect :
Most of the mem protect facility is an optional function of memory board(s). The front
panel just buffers the state of the prot/unprot switch out onto the bus.
--- A5 :
It makes sense that the problem occurs when A5 is off, if by off you mean down. When it
is up, the switch is open and shouldn't affect the bus, when down it connects a 7405
output to the proc data line. It sounds like it could be a bad 7405 on the front panel.
This is all addressed in the previous messages,
but in short:
- the CPU card is required to be able to 'set' the address LEDs,
- with no memory board you can expect the D0-D7 LEDS to be all 1s
(on), not 0s.
Thanks for condensing that info, very helpful.
So in that case, the DRAM card is clearly not doing what one would expect -
the data LEDs are perma-lit irrespective of DRAM presence.
I have also nailed-down some of the crazy behavior wrt the address
switches.. it all seems to be related to A5. If A5 is on, I can stop/start
the cpu and perform semi-sane stepping operations with ex/ex next. But set
A5 off, and the machine goes out of control.. and so far, it seems that A5
and only A5 has this odd control effect. This smells like a good hint, so
next step is to check my address line wiring work, and A5 in specific, as
well as whatever ICs / components play a role in that signal chain,
FYI, I have tried two different CPUs (well, actually three) and also a
second 8212 on the CPU board. These changes had no effect on behavior that
I could notice.
Another possible clue - the prot/unprot function is totally dead. I don't
know how the prot scheme / circuit works, but it does seem to signal a lack
of communication & control between the DRAM and the CPU/front panel. Any
info on how that circuit works would be helpful - meantime, I'll see what I
can figure out on my own from the schematic.
Thanks again for the assistance, I'm learning this stuff as we go along.