Found these inside a non-working 71B

[MikeSD]

I just had to try one more thing. 71 still runs but MEM value not as expected. First try was just over 12k, 12,xxx or something. Three 4K working. i suspect the one i was hooked to was the problem not allowing it to configure.

Found a short and tried again. This time I got 15391. Should be 16927, based on another 16k machine I have. But i suppose that could be legit too if the installed RAM is causing some overhead. Reset and tried again. Same results. at least I didnt get any smoke. Better stop while Im ahead. or at least not behind.

The pic is how I attached it.
* I buzzed between pin 9 on bottom chip to verify it was chip in front of HPIL daisy chain.
* wired pins 1 - 7 straight across
* wired pin 9 Dout from bottom chip to front chip on dangling 32k module.
* its pin 9 is already wired to pin 8 of back 32k
* wire pin 9 of back 32k RAM pin 8
* Then finally pin 9 of back chip to hpil pin 8, with no HPIL module
* I also tried it with and without the pin 9 wire going to HPIL. No difference.

Seems right but didnt produce what I expected.

I've never had any internally installed RAM. Not sure how it should behave. Is MEM supposed to automatically show more RAM or do I have to execute some command to make it part of sys RAM. Show port doesnt show it so it's not port RAM, so Ibwas expecting it to be part of sys RAM.

Or I could still have a wiring error I better stop for tonight before I do see smoke Going to read and see if there is some configuration still needed. I suppose it could be there but just not part of sys ram yet. But I did some port commands and got "no devices found", so its not port RAM.

[Paul Berger (Canada)]

It looks like you have 8 sequential connections starting from the left there should only be 7 the 8th wire will be connecting Din on U9 to Din on one of the 32Ks that will mean that when Din goes high there both modules will try to talk at the same time resulting in chaos and likely neither module being configured, you want to remove that wire and the one you picked up under the resistor should go to Din on the 32K that has Dout wired to Din on the other 32K you don't need to connect Dout on the second one to anything.

Paul.

[MikeSD]

(03-12-2018 02:03 AM)Paul Berger (Canada) Wrote:  It looks like you have 8 sequential connections starting from the left there should only be 7 the 8th wire will be connecting Din on U9 to Din on one of the 32Ks that will mean that when Din goes high there both modules will try to talk at the same time resulting in chaos and likely neither module being configured, you want to remove that wire and the one you picked up under the resistor should go to Din on the 32K that has Dout wired to Din on the other 32K you don't need to connect Dout on the second one to anything.

Paul.

I'm sure uou are probably right but this is far fewer than the way it was, since I had a FORTH too.

I'm not sure you are understanding how the 32K are wired, assuming both b are the same.
* what are the 8 connections you are referring to. There are the original 5 chips and I'm adding 2. With forth and Math there are 2 more there. So I'm confused about the connections.
* that said, there was a daisy chain error. I had Pin9 from bottom chip to pin 8 of the front chip. Should have been back chip. Pin9 of back chip wire in module to pin 8 of front chip. Then Pin9 of front chip goes to HPIL. Same results.

update: Dang on way to Subway I realized there is another problem. I never cut a trace between the lower chip pin9 and the HPIL. My RAM was not inserted between. So when i ran U9-pin 9 to the RAM chip pin8 and it's pin 9 to the front RAM pin8, , its pin 9 is routed back to pin 9 on lower chip because I did cut the chain between U9 and HPIL Havent looked at why but i know its wrong. kind of a parallel connection. I think the 2nd RAM would prevent the first one from configuring.

If this was all working, would MEM return 82k. or would it look like a 64k port ram?

[Paul Berger (Canada)]

(03-12-2018 02:58 AM)MikeSD Wrote:  

(03-12-2018 02:03 AM)Paul Berger (Canada) Wrote:  It looks like you have 8 sequential connections starting from the left there should only be 7 the 8th wire will be connecting Din on U9 to Din on one of the 32Ks that will mean that when Din goes high there both modules will try to talk at the same time resulting in chaos and likely neither module being configured, you want to remove that wire and the one you picked up under the resistor should go to Din on the 32K that has Dout wired to Din on the other 32K you don't need to connect Dout on the second one to anything.

Paul.

I'm sure uou are probably right but this is far fewer than the way it was, since I had a FORTH too.

I'm not sure you are understanding how the 32K are wired, assuming both b are the same.
* what are the 8 connections you are referring to. There are the original 5 chips and I'm adding 2. With forth and Math there are 2 more there. So I'm confused about the connections.
* that said, there was a daisy chain error. I had Pin9 from bottom chip to pin 8 of the front chip. Should have been back chip. Pin9 of back chip wire in module to pin 8 of front chip. Then Pin9 of front chip goes to HPIL. Same results.

Assume that Vdd is pin 1 and ground is pin 13you should have Vdd and the next 6 (B3-B0, *str, and C/D) connected 1 for 1 with the U9 module plus pin 13 Gnd. The wire you connect to the via under the resistor is connected to the end of the chain it should go to pin 8 (Din) on the32K module that has that connection open, that same module should have a wire connecting pin 9 (Dout) to pin 8 of the next one and there is no need to connect Dout on the second one to anything.

The way this works is when initialized all the modules set Dout low, on this particular chain the first module has Din tied high. When the CPU send out a configure command the module with Din high answers with it information and when done it set its Dout high so then the next module in the chain gets configured and so on until no one responds at which time the memory configuration routine assumes it is done with that chain. The way it was wired in the picture with pin 8 of U9 connected to pin8 of one of the 32K modules Din would get raised on both of them at the same time and that will not work, so just remember Dout to Din all through the chain. Pins 1 to 7 and 13 get connected straight 3 and pins 10 to 12 are not used by RAM or ROM modules but they are there because the modules are designed so that they can be put into a front side plugin and those connection are on the 4 front ports and the HPIL port but are used by plugins other than normal RAM or ROM modules.

Paul.

[MikeSD]

(03-12-2018 03:20 AM)Paul Berger (Canada) Wrote:  

(03-12-2018 02:58 AM)MikeSD Wrote:  I'm sure uou are probably right but this is far fewer than the way it was, since I had a FORTH too.

I'm not sure you are understanding how the 32K are wired, assuming both b are the same.
* what are the 8 connections you are referring to. There are the original 5 chips and I'm adding 2. With forth and Math there are 2 more there. So I'm confused about the connections.
* that said, there was a daisy chain error. I had Pin9 from bottom chip to pin 8 of the front chip. Should have been back chip. Pin9 of back chip wire in module to pin 8 of front chip. Then Pin9 of front chip goes to HPIL. Same results.

Assume that Vdd is pin 1 and ground is pin 13you should have Vdd and the next 6 (B3-B0, *str, and C/D) connected 1 for 1 with the U9 module plus pin 13 Gnd. The wire you connect to the via under the resistor is connected to the end of the chain it should go to pin 8 (Din) on the32K module that has that connection open, that same module should have a wire connecting pin 9 (Dout) to pin 8 of the next one and there is no need to connect Dout on the second one to anything.

The way this works is when initialized all the modules set Dout low, on this particular chain the first module has Din tied high. When the CPU send out a configure command the module with Din high answers with it information and when done it set its Dout high so then the next module in the chain gets configured and so on until no one responds at which time the memory configuration routine assumes it is done with that chain. The way it was wired in the picture with pin 8 of U9 connected to pin8 of one of the 32K modules Din would get raised on both of them at the same time and that will not work, so just remember Dout to Din all through the chain. Pins 1 to 7 and 13 get connected straight 3 and pins 10 to 12 are not used by RAM or ROM modules but they are there because the modules are designed so that they can be put into a front side plugin and those connection are on the 4 front ports and the HPIL port but are used by plugins other than normal RAM or ROM modules.

Paul.

I think i have the wiring right now. The wire that was on pin8 of the front chip is now on pin8 of back chip. Pin 9 on back chip is connected to pin jumper to pin 8 of front chip. Pin 9 of front chip goes tp HPIL pin 8 line. A problem still exists because u9 pin 9 is also connected to HPIL line. This has the effect of tying both pin 9s together. Not sure i can just leave pin 9 open on last RAM chip. The calc this was on had the line between u9-Pin9 and HPIL pin 8 line cut. This 71b hasntnhad that line cut, yet.

This is what I was shooting for. But I haven't made that cut yet, so you see the problem. I just lifted the last wire, from Front RAM-9 but thst didnt help. Looks like I might have to make that cut on my test 71B.

Once this is done, and if it works, will the 64K be port RAM or system RAM after powering up?

[Paul Berger (Canada)]

For testing you don't need to cut anything as long as there is no HPIL module installed. Pin 9 (Dout) from #5 in your diagram by default goes to the HPIL port. The wire that you soldered into the via under the resistor taps into that connection, just connect it to 8 (Din) on the back RAM and leave 9 (Dout) on the front RAM unconnected. Taking another look at your diagram you could just remove the connection from 9 of the the front RAM and you should be OK as long as there is no HPIL module installed.

If you wish to make this permanent, or mount a module in the top left, where you found the math module.

The memory will show up as system RAM, when memory is converted to port RAM an identifying signature is written at the beginning of the memory in the module, and since RAM is volatile, when you power it on, the contents will be random.

Paul.

[MikeSD]

(03-12-2018 12:09 PM)Paul Berger (Canada) Wrote:  For testing you don't need to cut anything as long as there is no HPIL module installed. Pin 9 (Dout) from #5 in your diagram by default goes to the HPIL port. The wire that you soldered into the via under the resistor taps into that connection, just connect it to 8 (Din) on the back RAM and leave 9 (Dout) on the front RAM unconnected. Taking another look at your diagram you could just remove the connection from 9 of the the front RAM and you should be OK as long as there is no HPIL module installed.

If you wish to make this permanent, or mount a module in the top left, where you found the math module.

The memory will show up as system RAM, when memory is converted to port RAM an identifying signature is written at the beginning of the memory in the module, and since RAM is volatile, when you power it on, the contents will be random.

Paul.

Something is still wrong then. I removed the wire add mem still says 15,391. Consistent but wrong. I'll buzz everything out again when I get home. I'm going to spend a little more time on this, then go remove the FORTH and see if the 71B is working without these.

Even sys RAM can be made independent with FREE and CLAIM. How is this RAM referenced?

[Paul Berger (Canada)]

(03-12-2018 04:04 PM)MikeSD Wrote:  Something is still wrong then. I removed the wire add mem still says 15,391. Consistent but wrong. I'll buzz everything out again when I get home. I'm going to spend a little more time on this, then go remove the FORTH and see if the 71B is working without these.

Even sys RAM can be made independent with FREE and CLAIM. How is this RAM referenced?

When you you issue a free port command three things happen. First the whole module at the port address is zeroed, then an identifier is written into the first few nibbles of the modules memory, and it is reassigned an address closer to the top of memory with ROM modules and other port RAM. Freeport will only work if there is sufficient free memory to allow it and files in memory may be relocated. When you issue a claim port the the free port identifier is cleared, in fact I believe the whole module is cleared and the module is readdressed nearer the bottom of memory. That is just the basics of what happens there are a whole lot of memory management things that go on when either free port or claim port are issued.

Paul.

[rprosperi]

(03-12-2018 04:04 PM)MikeSD Wrote:  Even sys RAM can be made independent with FREE and CLAIM. How is this RAM referenced?

To free and access port 0.00 (the first 4K RAM of the 16K installed in a normal machine) as an IRAM:

FREE PORT (0.00)

Then you can do:

MEM(0.00) to see port RAM available space

COPY MYFILE TO :PORT(0.00) (in this case, you can actually use :PORT(0), but otherwise it would be :PORT(0.01), :PORT(2), etc.) - this copies with same filename

COPY MYFILE TO NEWFILE:PORT(0.00) - to rename during copy

CAT :PORT(0.00)

COPY NEWFILE:PORT(0.00) - no target defaults to copying to :MAIN with same name

To reclaim the IRAM back to SysRAM, do: CLAIM :PORT(0.00)

As I don't know which ports in this machine have what sized RAM chips, you'll have to explore. If the additional chips are indeed simply added to the 4 original 4K chips, you should probably use SHOW PORT before you begin to see how much is where. If the machine is 1BBBB ROM, you'll need to add the SHOWLEX file to extend SHOW PORT to include system RAM (by default, it only shows IRAM and ROM), but 2CCCC and 2CDCC ROM machines show all types (0 - SysRAM, 1 - IRAM, 2 - ROM).

In a normal machine (bank 4 is wired to daisy chain to the HP-IL port) the RAM banks are 0.00, 0.01, 0.02 and 0.03, (.04 is used by HP-IL but not shown) and then HP-IL is 0.05. If you add a RAM chip in between, I don't know if that one becomes 0.04 and 0.05 and 'pushes' the HP-IL port numbers up, or if it gets added as 0.06, but SHOW PORT should tell you this.

[Dave Frederickson]

(03-12-2018 04:04 PM)MikeSD Wrote:  Even sys RAM can be made independent with FREE and CLAIM. How is this RAM referenced?

If in the Port 0 daisy chain, as illustrated above, the 64k RAM will be configured as Ports 0.04 and 0.05. If the HP-IL module is installed, the HP-IL Mailbox should be configured as Port 0.06 and the ROM at Port 0.07.

Dave

[rprosperi]

(03-12-2018 05:20 PM)rprosperi Wrote:  In a normal machine (bank 4 is wired to daisy chain to the HP-IL port) the RAM banks are 0.00, 0.01, 0.02 and 0.03, (.04 is used by HP-IL but not shown) and then HP-IL is 0.05. If you add a RAM chip in between, I don't know if that one becomes 0.04 and 0.05 and 'pushes' the HP-IL port numbers up, or if it gets added as 0.06, but SHOW PORT should tell you this.

(03-12-2018 05:27 PM)Dave Frederickson Wrote:  If in the Port 0 daisy chain, as illustrated above, the 64k RAM will be configured as Ports 0.04 and 0.05. If the HP-IL module is installed, the HP-IL Mailbox should be configured as Port 0.06 and the ROM at Port 0.07.

Ok, so that answers that; I wasn't sure if the MB and IL ports are pushed up or retained during config. Thanks for clarifying that.

[MikeSD]

I'll get back to testing 64K RAM and FORTH later. Today I wanted to take the FORTH out and see if tbe 71B works.

WooHoo! it and Math are working

[Dave Frederickson]

I'm a bit confused by the daisy-chain diagram above. The "main 5 chips" are all daisy-chained, out to in, but according to the schematic, U5, the ROM, has it's DOUT unconnected and VDD is connected to DIN on both U5 and U6, the Port(0.1) RAM. Can you clairfy?

Dave

[Paul Berger (Canada)]

(03-12-2018 11:50 PM)Dave Frederickson Wrote:  I'm a bit confused by the daisy-chain diagram above. The "main 5 chips" are all daisy-chained, out to in, but according to the schematic, U5, the ROM, has it's DOUT unconnected and VDD is connected to DIN on both U5 and U6, the Port(0.1) RAM. Can you clairfy?

Dave

U5 is the OS ROM and is hard configured, it has to be that way as all the soft configured devices are given their address by the memory configuration routine, and that code would need to reside in a hard configured ROM. U6, 7, 8, and 9 are the base system RAM.

The connection between U6 Dout and U7 Din on the schematic extends on to a point W1 where it might be routed to the Din on the HPIL. I was under the impression that on the actual board it did not go any further that U7 Din but when I was looking at the actual board just now I saw the line that extends beyond U7 and ends up at an unconnected pad under U9. Who know what the purpose of that might have been.

Paul.

[Dave Frederickson]

(03-13-2018 12:42 AM)Paul Berger (Canada) Wrote:  

(03-12-2018 11:50 PM)Dave Frederickson Wrote:  I'm a bit confused by the daisy-chain diagram above. The "main 5 chips" are all daisy-chained, out to in, but according to the schematic, U5, the ROM, has it's DOUT unconnected and VDD is connected to DIN on both U5 and U6, the Port(0.1) RAM. Can you clairfy?

Dave

U5 is the OS ROM and is hard configured, it has to be that way as all the soft configured devices are given their address by the memory configuration routine, and that code would need to reside in a hard configured ROM. U6, 7, 8, and 9 are the base system RAM.

The connection between U6 Dout and U7 Din on the schematic extends on to a point W1 where it might be routed to the Din on the HPIL. I was under the impression that on the actual board it did not go any further that U7 Din but when I was looking at the actual board just now I saw the line that extends beyond U7 and ends up at an unconnected pad under U9. Who know what the purpose of that might have been.

Paul.

Precisely, Paul. DIN on U5 and U6 should be connected to VDD and DOUT on U5 should be unconnected. That's not what's illustrated no matter what reference designators you use.

By "clarify" I meant to confirm that the illustration is either wrong or the modules are wired contrary to the schematic.

Dave

[MikeSD]

(03-12-2018 11:50 PM)Dave Frederickson Wrote:  I'm a bit confused by the daisy-chain diagram above. The "main 5 chips" are all daisy-chained, out to in, but according to the schematic, U5, the ROM, has it's DOUT unconnected and VDD is connected to DIN on both U5 and U6, the Port(0.1) RAM. Can you clairfy?

Dave

I was justbguessing. Conceptually that was what I thought was going on. Likely there should be only 4 devices not 5. Pin 9 on that end chip went to the Math on the other 71B I think. I just ran it to my ram as the next device.

I'm still not sure what to expect if I insert a 64k there. MEM doesn't show 80k but I don't know that it should. I doubt it's defective because the other stuff works fine on the original 71B they came from.

What operations can I do to see if that RAM is actually there other than MEM which returns 15931 consistently? Any chance there is some other configured necessary? I do know it's not configured as port ram. Any chance it's there but not visible because of some limitation?

[Paul Berger (Canada)]

(03-13-2018 02:00 AM)MikeSD Wrote:  I was justbguessing. Conceptually that was what I thought was going on. Likely there should be only 4 devices not 5. Pin 9 on that end chip went to the Math on the other 71B I think. I just ran it to my ram as the next device.

Yes on a base 71B the memory chain 0 will only have 4 devices, the four built in 4K RAM modules. The fifth module, center bottom is the OS ROM and is hard configured so it does not show up in any chain.

(03-13-2018 02:00 AM)MikeSD Wrote:  I'm still not sure what to expect if I insert a 64k there. MEM doesn't show 80k but I don't know that it should. I doubt it's defective because the other stuff works fine on the original 71B they came from.

When it is wired up correctly I would expect that you would see 64K more of memory when you run the MEM command. I would be extremely surprised if it got configured as port RAM since that requires the first few nibble of the module to be a specific pattern, and SRAM being a volatile memory device it will lose its content when not power up, and then when power is reapplied the contents would be random. The 71B provides Vcc to the memory as long as there are good batteries installed or it is plugged in.

I have done this before I know that it works, the only difference is in my setup, Dout (pin 9) from U7 was disconnected and routed to Din (Pin 8) on the first 32K RAM and then Dout from 32K_1 was routed to Din on 32K_2 and since I was breaking into the middle of the chain Dout from 32K_2 is connected where Dout from U7 used to be so now the chain is U6 -> U7 -> 32K_1 -> 32K_2 -> U8 -> U9 -> 32K added on top of U9 -> HPIL.

If you add your modules at the end of the chain, in your test 71B which has just the base RAM, you would connect Dout from U9 (the via under the resistor is effectively the same point) to Din of the first 32K there is no need to connect Dout of the second 32K to anything and if the modules are good they should configure as system RAM.

(03-13-2018 02:00 AM)MikeSD Wrote:  What operations can I do to see if that RAM is actually there other than MEM which returns 15931 consistently? Any chance there is some other configured necessary? I do know it's not configured as port ram. Any chance it's there but not visible because of some limitation?

There is the showport command but it is broken in the 1BBBB version of OS but there is a LEX version of showport that works properly. Dave Frederickson put together a package of tools for use with the FRAM module that includes a modified version of a program that I wrote to dump the memory configuration called membuf. Of course to load any of these you will need access to mass storage which is going to mean you will need HPIL. I guess I should add that if you want to use HPIL on you test system with the 32K modules wired in you will need to properly break into the chain and route Dout from the second 32K to Din of the next module and that will require some wiring changes on the board.

[Dave Frederickson]

64k or 2x32k?

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

[Paul Berger (Canada)]

(03-13-2018 02:55 AM)Dave Frederickson Wrote:  64k or 2x32k?

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

What Mike has looks very much like 2 CMT 32K modules sandwiched together.


Paul.

[MikeSD]

This is puzzling. I'm still thinking the RAM might be ok and there is a connection issue. But since the 71B that this was in, is now working, I'm going to spend only a little more time in the test unit. If I can't figure out the problem, I'm going to put it back where it was in the original 71B.

Results later.