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(a)pacbell.net>
To: <cctalk(a)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(a)pacbell.net