Godbout Econoram X control settings

From: Richard Erlacher <edick_at_idcomm.com>
Date: Mon May 20 08:09:34 2002

I have some Econoram boards that use 4Kx1 SRAMs, and use them to comprise a
64K-byte memory. The devices on my boards are 2147's though the board works
fine with TMS4044's and other pin-compatibles.

I haven't looked at the boards of the doc's in quite a while but if you check
back with me in a week or so, I may well have the data for you. If I
remember, of course, I'll contact you.

regards,

Dick

----- Original Message -----
From: "Jim Battle" <frustum_at_pacbell.net>
To: <cctalk_at_classiccmp.org>
Sent: Sunday, May 19, 2002 11:51 PM
Subject: Godbout Econoram X control settings


> After my most recent round of Sol emulator enhancements, I'm finally
> getting down to adding emulation for the Helios disk system.
>
> Part of that effort is going to require me to get some binary disk images
> in order to make the emulator do something useful.
>
> Luckily, I happen to have a Sol stashed away along with a Helios disk
> system. It was kindly donated to me last summer, but it has been in
> storage waiting for me to have the time to rehabilitate it.
>
> I bought a used varactor and ramped up the power on the Sol itself. No
> caps blew, and it is now working just fine. At least, it plays TARG
> OK. I've also replaced the key pads and it is now much a happier than it
> was. I haven't tried messing with the helios system yet as it is going to
> require a lot more work (dusting it out, cleaning things, sanity checking
> it, praying like hell it doesn't need calibration after 20 years of
idleness).
>
> The system has two "Econoram by Godbout" boards, specifically "Econoram
> X". Doing some probing of memory locations, it appears that only 48KB of
> the available 64 KB of SRAM is enabled (each card has 64 4Kx1 SRAM
> chips). 0x0000 to 0xBFFF is enabled, and the rest is disabled. Of course,
> part of it must be disabled because 0xC000-0xCFFF is taken up by the
> monitor ROM, display RAM, and scratch RAM. However, the higher parts
> should be OK to use.
>
> The dip switches on the boards have suggestive labels, but are too terse
> for me to be confident what is going on.
>
> Does anybody have docs on this or similar boards, or perhaps is better at
> guessing what is going on than I am? I think I understand most of it, but
> I'm sure I don't understand all of it.
>
> First board's dip switch settings:
>
> S1:
> 1: WE A = on
> 2: WE B = on
> 3: WE CL = on
> 4: WE CH = on
> 5: DIS A = off
> 6: DIS B = off
> 7: DIS C = off
> 8: WS = off
>
> S2:
> 1,2,3 = A = off, off, off
> 4,5,6 = B = off, off, on
> 7,8 = C = on, off
>
>
> Second board's dip switch settings:
>
> S1:
> 1: WE A = on
> 2: WE B = on
> 3: WE CL = on
> 4: WE CH = on
> 5: DIS A = on
> 6: DIS B = on
> 7: DIS C = off
> 8: WS = off
>
> S2:
> 1,2,3 = A = on, on, on
> 4,5,6 = B = on, on, off
> 7,8 = C = off, on
>
> So it looks like the 32 KB on each board is broken up into three
> banks. I'm guessing banks A and B control 8 KB blocks, and bank C is a 16
> KB block (since S2 has three switches for A and B but bank C has only two
> switches). WE A/B/C is write enable for each bank, and DIS A/B/C is
> read&write enable/disable for each of the three banks. Perhaps WS is to
> enable a wait state.
>
> Sounds good so far, so let's collect the bank settings:
>
> 0 0 0 A1 = 0- 7, enabled
> 0 0 1 B1 = 8-15, enabled
> 1 0 C1 = 32-47, enabled
>
> 1 1 1 A2 = 56-63, disabled
> 1 1 0 B2 = 48-55, disabled
> 0 1 C2 = 16-31, enabled
>
> Does this sound reasonable? At least it is consistent with my
interpretation.
>
> Does anybody know for sure what WS stands for?
>
> One disturbing thing is that the I would have expected one board to
> implement 0-31KB, and the other board to be used to map 32-47KB. Instead,
> one board does 0-15 and 32-47, while the other board does 16-31. Any idea
> why this might be?
>
> Finally, does anybody know if this board respects phantom disable (some
> other resource can claim a block of addresses and the board will silently
> just map out that RAM location)?
>
> Thanks.
>
> -----
> Jim Battle == frustum_at_pacbell.net
>
>
Received on Mon May 20 2002 - 08:09:34 BST