31 Aug
2014
31 Aug
'14
3:58 p.m.
Quick update - I made the changes described under "use in non-SD Systems
environments", to no obvious effect. I still cannot deposit / examine any
memory locations.
But one thing I did notice, I'm getting the sense that the front panel is
no longer a (significant) issue. It really does seem to behave in a sane
and predictable way, despite the fact that the rest of the hardware doesn't
play along. Some strong hints of a sane mind down in there somewhere.. it's
starting to look encouraging.
I'll use some more 'wait time' to see about improving and finalizing the
grounding & power schemes, maybe actually fasten down the mainboard.. It's
all kind of flying in the breeze at the moment..
On Sun, Aug 31, 2014 at 12:50 PM, drlegendre . <drlegendre at gmail.com> wrote:
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.