On 2014-Aug-26, at 1:12 PM, Eric Smith wrote:
On Tue, Aug 26, 2014 at 1:43 PM, Brent Hilpert
<hilpert at cs.ubc.ca> wrote:
A niggling question I have in the back of my
head, is whether or not some/many memory boards will work with the Altair front panel.
As stated in my previous message the front panel expects a memory board to be putting
data onto the DI bus to be observable on the LEDs when idle, the front panel does not
latch the data from a last memory cycle.
I suspect many memory boards don't do this, they may only put (strobe) data onto the
bus during the active portion of a memory cycle. The bus lines would then revert to the
high state and all you would see is ON LEDs.
I'm not terribly familiar with the details of the S-100 bus, and not
at all with the Altair, so please excuse my ignorance, but surely even
a static RAM board won't drive the bus for any significant length of
time after the bus read cycle is over. This suggests that for the
front panel without data latches to be able to examine memory, the
front panel (or something related to it) would have to keep the bus
read cycle active indefinitely, perhaps by driving a ready line false.
I would think that even a DRAM board would have to hold the read data
on the bus as long as the bus read cycle hasn't terminated, because it
has no other way to know when the bus master has actually accepted the
data.
I'm just in the process of examining docs and several mem board schematics in relation
to this issue and the Altair.
I've worked on a few S100 machines and some variety of S100 boards for hardware level
repairs.
We have to keep in mind that the first Altair was something of a seat-of-the-pants design,
so things don't always work as one might expect or hope
(witness the forced-instruction mem-examine technique).
For purposes at this point, there are 3 primary control signals involved with a mem read:
- address lines of course.
- MEMR or SMEMR: an indication from the bus master (processor board) of a memory read
cycle.
MEMR is a *latched* status sig from the 8080.
- DBIN or PDBIN: a strobe from the bus master to a bus slave (e.g. mem board) to
put data on the data input bus.
DBIN is a buffered sig right out of the 8080.
The Altair 4K mem board schematic indicates it puts data on the bus when the board is
addressed and MEMR asserted. It appears to ignore DBIN.
From what I've been able to discern so far from the
8080 datasheet, DBIN is a pulsed signal, I haven't seen anywhere that the proc would
leave it asserted.
The front panel seems to rely on:
- the proc board leaving the address asserted on the bus,
- AND the MEMR latch on the proc board to have left MEMR asserted on the bus (dr
indicated the MEMR LED was ON on the front panel)
- AND the mem board to be ignoring DBIN
Depending on the semantics one wishes to apply, rather than having something extend the
mem cycle as you suggest, it appears the front panel is relying on a 'degenerate'
mem board design that ignores DBIN. From one perspective ignoring it doesn't matter,
as MEMR will be de-asserted when the proc starts another type of cycle.
(Of course calling it degenerate is hindsight, as it was was the earliest S100 design.)
Other mem board schematics that I've examined so far show the data from the boards to
be additionally mediated by DBIN, even a simple 70's 8K Godbout SRAM board, suggesting
they wouldn't work with the Altair front panel.
Or my understanding of DBIN is off or I've missed something in perusing the docs.
dr could measure the state of DBIN to see if it's asserted when idle, as opposed to
being just pulsed.
DBIN doesn't seem to have a state LED on the front panel (with does suggest it is just
pulsed).
It would be interesting to hear from someone else with an original-rev Altair and what mem
boards they use.