+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: Found these inside a non-working 71B (/thread-10300.html)
RE: Found these inside a non-working 71B - Dave Frederickson - 03-13-2018 04:02 PM
(03-13-2018 03:39 AM)Paul Berger (Canada) Wrote:(03-13-2018 02:55 AM)Dave Frederickson Wrote: 64k or 2x32k?What Mike has looks very much like 2 CMT 32K modules sandwiched together.
We know that the CMT 64k RAM module is comprised of two 32k modules and gets configured as two 32k ports. The CMT EPROM programmer also contains two 32k modules, but it can be configured as a single 64k port by flipping the switch on the front. FRAM71 accomplishes this by manipulating the Last Chip In Module (LCIM) bit in the Config Buffer entry.
I presumed that the 64k "module" in the 71 came from a 64k front-port module, but I'm curious if/how it's possible to configure as a single 64k port?
Dave
That's what I said back in Post: #2, but my question wasn't specific to Mike's modules.
RE: Found these inside a non-working 71B - Paul Berger (Canada) - 03-13-2018 05:41 PM
In the document of the proceeding of the 1985 HHC Atlanta conference there is an article written by Jim De Arras who appears to have been from Hand Held Products and he states that they originally made 64K memory modules, but ran into a bug in the original OS. What they found was that when freeported a 64K module when there is no hard configured module such as hard FORTH installed the free space routine would report no free memory because of the way the code worked that checked for space. All of the gory details are in that document. It is possible this may have been fixed in later levels of OS. So this would suggest that you can configure 64K of RAM in a single module. After reading this I went and looked at the IDS where they describe the memory configuration process and the table in that section indicates that the maximum size for a RAM module is 64K nibbles or 32K bytes.
RE: Found these inside a non-working 71B - Paul Berger (Canada) - 03-13-2018 06:19 PM
Reading a little more about the memory configuration you could have a RAM module that contains more than 32K bytes the 64K nibble limit is for an individual chip but a module could contain more than one chip, for instance the the 4K modules used for the base memory contain four 1K byte chips, so when they are polled by the configuration routine, they report 0000E 0000E 0000E 8000E where each group of 5 characters (nibbles) represents on chip in the module the "E" indicates it is a 2K nibble chip and the "8" in the last one reported indicates it is the last chip in the module. The OS as far as freeport and claimport are concerned still treat it as a single unit of memory. For a 64K module you could have it composed of two 32K chips and it would report as 00009 80009. The last nibble in the string indicates the size and is equal to 15-log2(size in nibbles). When you run the RAM diagnostics from the diagnostic module it reports for each chip in the module.
RE: Found these inside a non-working 71B - MikeSD - 03-13-2018 07:00 PM
More progress
I decided to put the RAM back in the original since its working now, just in case there is a mod we forgot about. It worked.
Looks like I
* either wired something wrong or
* there is a mod we forgot about.
The chain is as before. Port 0 RAM, then Math, then 64K, pin 9 unconnected.
Now to the FORTH module. Things looking good.
![[Image: 64K.jpg]](http://www.ipscone.com/photos/71B/64K.jpg)
RE: Found these inside a non-working 71B - Dave Frederickson - 03-13-2018 07:09 PM
(03-13-2018 06:19 PM)Paul Berger (Canada) Wrote: Reading a little more about the memory configuration you could have a RAM module that contains more than 32K bytes the 64K nibble limit is for an individual chip but a module could contain more than one chip, for instance the the 4K modules used for the base memory contain four 1K byte chips, so when they are polled by the configuration routine, they report 0000E 0000E 0000E 8000E where each group of 5 characters (nibbles) represents on chip in the module the "E" indicates it is a 2K nibble chip and the "8" in the last one reported indicates it is the last chip in the module. The OS as far as freeport and claimport are concerned still treat it as a single unit of memory. For a 64K module you could have it composed of two 32K chips and it would report as 00009 80009. The last nibble in the string indicates the size and is equal to 15-log2(size in nibbles). When you run the RAM diagnostics from the diagnostic module it reports for each chip in the module.
The question isn't if ports >32k can be created. The EPROM programmer, FRAM71, and the Emu71 emulators can all be easily configured for modules >32k.
The question is can two 32k modules be configured as a single 64k port and if so, how?
Dave
RE: Found these inside a non-working 71B - Dave Frederickson - 03-13-2018 07:17 PM
(03-13-2018 07:00 PM)MikeSD Wrote: More progress
I decided to put the RAM back in the original since its working now, just in case there is a mod we forgot about. It worked.
Looks like I
* either wired something wrong or
* there is a mod we forgot about.
The chain is as before. Port 0 RAM, then Math, then 64K, pin 9 unconnected.
Now to the FORTH module. Things looking good.
So when you run the improved SHOWPORT or Paul's MEMBUF, does the 64k "module" show up as one port or two? I suppose you could also execute FREEPORT(.05) then MEM(.05) to make that determination.
Dave
RE: Found these inside a non-working 71B - J-F Garnier - 03-13-2018 07:17 PM
(03-13-2018 05:41 PM)Paul Berger (Canada) Wrote: In the document of the proceeding of the 1985 HHC Atlanta conference there is an article written by Jim De Arras who appears to have been from Hand Held Products and he states that they originally made 64K memory modules, but ran into a bug in the original OS.Yes, this is a bug of the ROM 1BBBB. It is mentioned in the Soft Forth documentation (since Soft Forth requires a 64k port for application development).
(03-13-2018 06:19 PM)Paul Berger (Canada) Wrote: Reading a little more about the memory configuration you could have a RAM module that contains more than 32K bytes the 64K nibble limit is for an individual chip but a module could contain more than one chip, ...The HHP card reader RAM modules (made of 32K boards) can be configured to create a 64K port from two boards. See here for instance (the link to the file is dead, use this instead).
Unfortunately, it is not possible (or not known) to do the same with 32K CMT modules -well it should be possible since the CMT01 programmer does it.
BTW, I'm still interested by any information on the 1LQ4 chip. Somebody once said that a documentation exists but never shared.
J-F
RE: Found these inside a non-working 71B - Paul Berger (Canada) - 03-13-2018 07:21 PM
If they are individual modules I would say no the 71B will always treat them as separate blocks of memory. It would seem that the OS treats each module as a port and there does not appear to be any way to merge ports, least none that I know of.
RE: Found these inside a non-working 71B - Dave Frederickson - 03-13-2018 09:03 PM
(03-13-2018 07:17 PM)J-F Garnier Wrote: BTW, I'm still interested by any information on the 1LQ4 chip. Somebody once said that a documentation exists but never shared.
Tony Duell says he has a copy of the datasheet.
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv006.cgi?read=11509
RE: Found these inside a non-working 71B - Paul Berger (Canada) - 03-13-2018 09:58 PM
(03-13-2018 09:03 PM)Dave Frederickson Wrote:(03-13-2018 07:17 PM)J-F Garnier Wrote: BTW, I'm still interested by any information on the 1LQ4 chip. Somebody once said that a documentation exists but never shared.
Tony Duell says he has a copy of the datasheet.
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv006.cgi?read=11509
All of the HHP modules I have use a chip 1LJ4 and if this is the chip that HHP has always used it would be capable of supporting 64K of RAM. Maybe if I play around with the pins that appear to be for configuration and then observe what it reports, I can learn more about it.
Paul.
RE: Found these inside a non-working 71B - J-F Garnier - 03-13-2018 10:22 PM
(03-13-2018 09:58 PM)Paul Berger (Canada) Wrote: All of the HHP modules I have use a chip 1LJ4 and if this is the chip that HHP has always used it would be capable of supporting 64K of RAM. Maybe if I play around with the pins that appear to be for configuration and then observe what it reports, I can learn more about it.
All my HHP modules have interface IC with erased labels. I took the 1LQ4 reference from this HP part number list.
But yes, a 1LJ4 can be seen in a picture in Sylvain's compendium.
May did 2 versions exist (like the 1LB3 and 1LR4 HP-IL chips)?
J-F
RE: Found these inside a non-working 71B - rprosperi - 03-13-2018 11:35 PM
(03-13-2018 07:00 PM)MikeSD Wrote: I decided to put the RAM back in the original since its working now, just in case there is a mod we forgot about. It worked.
Good news that it works Mike, congrats on a successful repair!
But that number (82437) still seems odd. A 1BBBB machine usually has about 17.5 KB free after a reset. Adding 64K => 83456, 1019 bytes more than it's reporting.
Did the machine have any files installed (e.g. a test program?) when you got that result using MEM ? Also, "DESTROY ALL" will remove any variable storage.
RE: Found these inside a non-working 71B - MikeSD - 03-14-2018 02:17 AM
Quote:But that number (82437) still seems odd. A 1BBBB machine usually has about 17.5 KB free after a reset. Adding 64K => 83456, 1019 bytes more than it's reporting.
Did the machine have any files installed (e.g. a test program?) when you got that result using MEM ? Also, "DESTROY ALL" will remove any variable storage.
After Destroy All", i get a slightly diff number, 82415. Any chance it has something to do with Math ROM. Repeated Init3 and MEM is consistently reporting 82427. Bu oddly, everytime I do Desroy All. it changes to 82415. Repeatable. I see similar behavior on another 1BBBB machine.
INIT3, MEM =16955
DESTROY ALL=16943 12 bytes different, same dif as above. I don't see 17.5 on either.
And 65535+16955 is roughly what I see above. Should be identical but maybe Math overhead affects numbers. Plus, I don't think i've ever seen 17.5k with mem
RE: Found these inside a non-working 71B - rprosperi - 03-14-2018 03:19 AM
(03-14-2018 02:17 AM)MikeSD Wrote: After Destroy All", i get a slightly diff number, 82415. Any chance it has something to do with Math ROM. Repeated Init3 and MEM is consistently reporting 82427. Bu oddly, everytime I do Desroy All. it changes to 82415. Repeatable
Indeed, the manual confirms the MATH ROM allocates 43.5 bytes for internal use. It seems some of that is allocated for default variable storage, as the DESTROY ALL removes 22 bytes (82437 => 82415).
But this does not account for all of the missing RAM, it still seems like almost 1000 bytes is "missing". Perhaps there is some overhead required for the extra 64K System RAM.
Not directly related, but lets see how the 64K was allocated. Can you try FREE :PORT(0.04) and if it succeeds, then try MEM(0.04)? It should be just under 32KB. You can return the IRAM to SysRAM by CLAIM :PORT(0.04). The same process should also work for :PORT(0.05).
RE: Found these inside a non-working 71B - MikeSD - 03-14-2018 03:28 AM
rprosperi ' Wrote: But this does not account for all of the missing RAM, it still seems like almost 1000 bytes is "missing". Perhaps there is some overhead required for the extra 64K System RAM.
Not directly related, but lets see how the 64K was allocated. Can you try FREE :PORT(0.04) and if it succeeds, then try MEM(0.04)? It should be just under 32KB. You can return the IRAM to SysRAM by CLAIM :PORT(0.04). The same process should also work for :PORT(0.05).
I will try those later but I have other 1BBBB and none of them show 17.5 with MEM. 16955 and 16943, depending on how cleared. I actually wouldn't expect MEM to report sys RAM as its used by OS not user
RE: Found these inside a non-working 71B - Dave Frederickson - 03-14-2018 03:29 AM
(03-14-2018 02:17 AM)MikeSD Wrote:Quote:But that number (82437) still seems odd. A 1BBBB machine usually has about 17.5 KB free after a reset. Adding 64K => 83456, 1019 bytes more than it's reporting.
Did the machine have any files installed (e.g. a test program?) when you got that result using MEM ? Also, "DESTROY ALL" will remove any variable storage.
After Destroy All", i get a slightly diff number, 82415. Any chance it has something to do with Math ROM. Repeated Init3 and MEM is consistently reporting 82427. Bu oddly, everytime I do Desroy All. it changes to 82415. Repeatable
Typing commands begins to fill up the Command Stack and take away from available memory. Thats why the results of MEM changes as you type commands.
RE: Found these inside a non-working 71B - Sylvain Cote - 03-14-2018 03:30 AM
HP-71B / OS:1BBBB / SN:2707A00223
After INIT 3
Code:
A) Plain : MEM = 16955
B) CMT-64R : MEM = 82481
C) B-A : 82481-16955 = 65526 RAM usable from CMT-64RAfter INIT 3 & DESTROY ALL
Code:
A) Plain : MEM = 16943
B) CMT-64R : MEM = 82469
C) B-A : 82469-16943 = 65526 RAM usable from CMT-64RRE: Found these inside a non-working 71B - MikeSD - 03-14-2018 03:39 AM
That's similar to what I see
Regarding FREE:PORT (0.04) That doesn't work but .05 and .06 do.
I get 32763 for both.
Tomorrow I will test the FORTH Assembler. If that's also good, I'll install and secure them, button it up, and begin some more thorough testing. After I photograph the final assembly.
Can't believe I almost threw this out. Marked it hopeless. Actually wouldn't have thrown it out but nice to have checked it again. I have another near mint one that isn't working either. It'a 2CCCC version. The zebra strip is trashed.
RE: Found these inside a non-working 71B - rprosperi - 03-14-2018 03:47 AM
(03-14-2018 03:30 AM)Sylvain Cote Wrote: HP-71B / OS:1BBBB / SN:2707A00223
After INIT 3
Code:
A) Plain : MEM = 16955
B) CMT-64R : MEM = 82481
C) B-A : 82481-16955 = 65526 RAM usable from CMT-64R
After INIT 3 & DESTROY ALL
Code:
A) Plain : MEM = 16943
B) CMT-64R : MEM = 82469
C) B-A : 82469-16943 = 65526 RAM usable from CMT-64R
Thanks for testing and these numbers Sylvain.
To Dave's point, the 12-byte difference is the same length as "DESTROY ALL" plus a length byte. Coincidence?
As the gap (btwn a stock machine and Mike's with MATH ROM) is smaller than I recalled, it appears the MATH ROM likely actually uses a bit more than manual claims, so all is likely as it should be.
Good news and some of us have learned something too.
RE: Found these inside a non-working 71B - rprosperi - 03-14-2018 03:56 AM
(03-14-2018 03:39 AM)MikeSD Wrote: Regarding FREE:PORT (0.04) That doesn't work but .05 and .06 do.
Interesting. Perhaps the IL Mailbox (usually hidden port 0.04) must stay at that port address, and the added RAM picks up at the next available port (0.05 & 0.06).
Can you try SHOW PORT (after FREE-porting both 32K banks)? This should confirm the HP-IL ROM is 16KB, type=2, PORT(0.07) which should clarify all remaining unknowns.