31 Aug
2014
31 Aug
'14
10:50 a.m.
Oops, forgot to mention - again, all docs including those for the SD
Systems DRAM card are available at http://nerp.net/~legendre/altair/ =)
On Sun, Aug 31, 2014 at 12:48 PM, drlegendre . <drlegendre at gmail.com> wrote:
Couple of questions have come up..
While waiting for the new SRAM card to arrive, I thought I'd see what I
could learn about the SD Systems 'Expandoram II' DRAM card I currently
have. One major difference that I immediately noticed is the lack of a
block-address assignment feature. The JTM board allows the user to
arbitrarily map each of the (4) 4K groups to any 4K boundary in the memory
space. But the SD card is organized into 4x 16K groups, and each group can
only be enabled or disabled.
Oddly, I can't find any info on the mapping scheme in the document. For
example, if only group 3 is enabled, where does it map? 0000-4000 or
C000-FFFF.. or elsewhere?
But here's my +real+ question.. the document has a section on operating
the board in non-SD Systems environments, and that would seem to apply,
here. They state that "Some CPU boards (they don't mention which) supply a
different phase of the system clock on pins 24 & 25. If one of these boards
is used with the Expandoram II, make the following changes...", and then go
on to describe the changes - basic cut & jumper stuff, two locations.
Does anyone know if this difference in clock signals is relevant to the
MITS 8080 CPU board? If the board isn't receiving the clock it expects,
it's no surprise that it seems to behave so badly, eh..? Perhaps just go
ahead and make the changes and give it a go? It's easy enough to revert it,
if it doesn't help.
Lastly, I also discovered that the SD board had Wait State enabled.. and
the doc says that's only required for 4MHz CPU operation. The 8080A runs at
2Mhz, so I've disabled the wait state. Not sure if that was screwing things
up as well, but +probably+ not - it would just slow down the RAM access,
wouldn't it? Phantom was also enabled, and it's certainly not needed in
this instance, so I disabled that as well.
Any ideas on the mapping issue? Or more importantly, the clocking issue?
On Sat, Aug 30, 2014 at 9:37 PM, drlegendre . <drlegendre at gmail.com>
wrote:
Yes, 'JTM' is in fact correct -
that's what the seller stated in the
listing. I was just following your lead, and didn't notice the typo.
And again, per the seller, that photo on my ~legendre site is supposedly
the selfsame board which I am receiving. Looks to be in very nice cosmetic
shape, hopefully it didn't suffer electronically at some point.
On Sat, Aug 30, 2014 at 8:04 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2014-Aug-30, at 1:36 PM, drlegendre . wrote:
On Sat, Aug 30, 2014 at 2:49 PM, Brent Hilpert
<hilpert at cs.ubc.ca>
wrote:
> Earlier in the thread:
Really, where? In this thread? Hmm.. don't see it.
Message from me of 2014 August 27 1:45:56 PM PDT.
> Nothing else in the system should be
asserting phantom so it
shouldn't
> matter whether the phantom jumper is
installed, but you could remove
it to
> be sure. (Sec 1.7)
I was wondering about Phantom.. as yes, it does seem to duplicate the
same
functions as banking. But it seems that Phantom
is only used upon
reset, or
power-up, to +temporarily+ overlay boot code
which then "disappears"
for
the remainder of the session once it's served
its purpose and the
phantom
line is released.
So then, asserting Phantom when the system is operating has no effect -
correct? It only acts after a reset event? It would be like the action
of a
J-K lfip-flop - the J/K lines cannot change the
state of Q on their
own,
they only determine what value Q will take on the
rising-edge of the
next
clock cycle (the reset event, for phantom).
Do I have that right?
Generally speaking yes. On system reset, some flip-flop on a PROM board
would be set, enabling the PROM and asserting phantom on the bus, to
disable a RAM board so the PROM can overlay it. Some subsequent action
during boot would trigger the PROM board flip-flop off and de-assert
phantom so you now had full RAM available.
But the RAM boards are passive responders to the phantom signal, there's
nothing prohibiting a system design or PROM board design from reasserting
phantom at a later time under some program action.
> Going from what I'm seeing you may have
to be careful to note the
> open/closed orientation of the switches, as it appears the installed
> switches aren't always consistent with the config diagrams in the
manual.
Yes, duly noted.. I saw that.
> I actually have the JTS version of that board
(same board marketed
under a
> different name).
> The board I'm receiving is marked JTS on
the rear.. so I guess we've
got
the same one!
Correcting myself .. JTM.
If that photo on your site is the actual instance which you are to
receive then yes, they look quite the same.
Except the 5 CTS switch blocks on the photo instance have reversed
on/off positions to the one I have (and from the manual).
I was just playing with the one here to get it working.