Threaded Mode | Linear Mode

Dave Britten · (This post was last modified: 04-20-2021 05:55 PM by Dave Britten.)

I needed to swap/charge the batteries in my 71B, and upon doing so, got the MEMORY LOST message. I made sure I didn't hit any keys while swapping the batteries. On further experimentation, it seems to happen even with the power jumper removed from the MultiMod. Only when I completely remove the MultiMod from the computer am I able to remove any of the batteries for even a few seconds without losing memory. Is this expected behavior?

I'm pretty uptight about copying everything to my computer via PIL-Box, so I didn't really lose anything, it's just a nuisance. Smile

mfleming · 04-20-2021, 06:12 PM

Dave, I did add a warning to the documentation (though obviously I should have posted it as well!) The MultiMod remains active for 2-1/2 minutes after you turn the 71B off before it goes into deep sleep mode. This is to allow you to flip the 71 over and connect a serial cable for programming. Once in deep sleep the processor is stone cold until awakened by the Daisy-In signal.

If you're going to swap batteries then wait a few minutes after turning it off. I usually replace one battery at a time to minimize disconnect time. I just tried a little test - pulled a battery for 10 seconds, no loss, 30 seconds and I did get a memory lost message. Obviously safest when the charger is connected, but for those without, one quick battery swap at a time.

Memory lost with the J2 power jumper removed is a puzzle. I'll try that out for myself to see what happens, but the processor shouldn't present a power load with the jumper removed.

Thanks for the report, others will benefit from the warning!
~Mark

Sylvain Cote · (This post was last modified: 04-20-2021 06:22 PM by Sylvain Cote.)

I also see this on my side, Memory Lost is very easy to get when the MultiMod module is plugged in.
I plug an 82059D adapter on the 71B before changing the batteries now.

edit: thank you Mark for your answer, I saw it after my post was sent.

Dave Britten · 04-20-2021, 06:21 PM

Ahh, okay, I think I saw that in the docs, just didn't put 2 and 2 together. Smile

The memory loss with J2 removed may have been a fluke (e.g. bumped a bottom row key, or maybe something was out of sorts from the previous power loss). Probably worth testing on your end though to make sure. I'd try it again, but I just reloaded all my files and don't want to tempt fate. If the safe procedure is to simply yank J2 before changing batteries, then I have no problem with that.

mfleming · 04-20-2021, 10:49 PM

Very interesting playing around with the J2 jumper and battery replacement process. With the J2 jumper out, I didn't see a Memory Lost condition when turning the 71B on and off. So, I next tried simulating battery replacement with and without the J2 jumper in place.

With J2 in and the processor asleep, I lifted one battery at a time, counted to three, reseated the battery and counted to three again before lifting the next. No Memory Lost condition, and this matches the way I normally replace batteries (I probably fumble a little longer between battery pulls in real life).

With J2 out however, I get a Memory Lost repeating the same steps above, whether the 71B was just turned off or whether I waited several minutes for the processor to go into deep sleep before disconnecting power. So, counterintuitively, it's better to leave the jumper in when changing batteries.

I've yet to lose memory changing batteries this way, but that's not to say you won't. As Sylvain notes, it's better to have the adapter connected. Meanwhile, I'll look into forcing the processor into sleep mode after power-on reset, and only allow Daisy-In to wake the processor. That could conserve charge to power the rest of the 71B during battery replacement.

~Mark

Dave Britten · 04-20-2021, 10:58 PM

Very strange! I wonder where the power draw is going with J2 out.

Maybe a future firmware update could add a new POKE bit that tells the MultiMod to immediately deep sleep next time the computer is turned off? Would be a good option to have when you need to change batteries.

In any case, I took this as a good excuse to order one of Mark Hoskins' USB 82059D replacements. Wink

teenix · 04-21-2021, 02:49 AM

(04-20-2021 10:58 PM)Dave Britten Wrote: Very strange! I wonder where the power draw is going with J2 out.

Maybe a future firmware update could add a new POKE bit that tells the MultiMod to immediately deep sleep next time the computer is turned off? Would be a good option to have when you need to change batteries.

In any case, I took this as a good excuse to order one of Mark Hoskins' USB 82059D replacements.

I don't know the J2 function, but I gather removes power to the MultiMod board. Wiith the PIC powered down, if the 71 holds any of the PIC pins HI via the data pins etc, this may be a source of current draw.

cheers

Tony

Dave Britten · 04-21-2021, 02:24 PM

(04-21-2021 02:49 AM)teenix Wrote: I don't know the J2 function, but I gather removes power to the MultiMod board. Wiith the PIC powered down, if the 71 holds any of the PIC pins HI via the data pins etc, this may be a source of current draw.

cheers

Tony

Yeah, I was wondering if it might be a stray pull-up/down somewhere, but I don't know nearly enough about electronics engineering to go much further than that.

teenix · 04-21-2021, 03:08 PM

(04-21-2021 02:24 PM)Dave Britten Wrote: Yeah, I was wondering if it might be a stray pull-up/down somewhere, but I don't know nearly enough about electronics engineering to go much further than that.

It is only a guess as I don't know much about the project, but the PIC IO pins have protection diodes from each pin to Vcc and one to Gnd. If the PIC is powered down, but an IO pin has (say) 5V applied, the 5V will go through the diode and out of the Vcc pin to the circuits power rail.

cheers

Tony

**rprosperi** · 04-21-2021, 03:25 PM

Unrelated to the MMod, this behavior varies a lot among various 71B machines (I have several). Some machines will let me casually change batteries (always one at a time) with no ML (when powering-on), others will ML after even < 1 sec of removal.

Installation of additional RAM modules (in both front and CR ports) also can affect this, though not always as simply 'more modules = less time'. Some cannot withstand ANY time with modules installed, others seem OK.

As a general rule, I suggest you always connect a power supply before changing batteries, and also, once new batteries are installed, I recommend you 'roll them' in place, by simply rubbing across the 4 batteries with you fingers, which seems to ensure better contact, before powering on.

Note: If you're new to the 71B, it's important to know that most often when an ML occurs, the contents of IRAM ports are not lost and are preserved intact. I point this out because if you assume that all RAM is lost (as the ML message would seem to imply) you may remove a RAM module, or make other configuration changes, which would then in fact lose the IRAM contents, which otherwise were OK.

Dave Britten · 04-21-2021, 03:54 PM

(04-21-2021 03:25 PM)rprosperi Wrote: Unrelated to the MMod, this behavior varies a lot among various 71B machines (I have several). Some machines will let me casually change batteries (always one at a time) with no ML (when powering-on), others will ML after even < 1 sec of removal.

Installation of additional RAM modules (in both front and CR ports) also can affect this, though not always as simply 'more modules = less time'. Some cannot withstand ANY time with modules installed, others seem OK.

As a general rule, I suggest you always connect a power supply before changing batteries, and also, once new batteries are installed, I recommend you 'roll them' in place, by simply rubbing across the 4 batteries with you fingers, which seems to ensure better contact, before powering on.

Note: If you're new to the 71B, it's important to know that most often when an ML occurs, the contents of IRAM ports are not lost and are preserved intact. I point this out because if you assume that all RAM is lost (as the ML message would seem to imply) you may remove a RAM module, or make other configuration changes, which would then in fact lose the IRAM contents, which otherwise were OK.

What does the 71B use to power the RAM while the batteries are removed? Is it a plain electrolytic cap, a "super-cap", or something else? A few months ago, I bought an old Handspring Visor Neo that couldn't withstand battery removal, and I had to solder in a new super-cap to fix it. I wonder if the same is possible or necessary on the 71B.

Regarding IRAM, it's not possible to edit programs unless they're in main memory, right? Can you merge multiple RAM modules to create one big IRAM? (e.g. I have 3x 4K modules, can I use them as a single 12K IRAM?)

If there's ever a MultiMod 2.0 that also incorporates a nice chunk of battery-backed SRAM, you can definitely put me down for one. Wink

Sylvain Cote · (This post was last modified: 04-21-2021 05:00 PM by Sylvain Cote.)

(04-21-2021 03:54 PM)Dave Britten Wrote: What does the 71B use to power the RAM while the batteries are removed? Is it a plain electrolytic cap, a "super-cap", or something else?

Look in the HP-71B Hardware Design Specification documentation, it should be there.

(04-21-2021 03:54 PM)Dave Britten Wrote: Regarding IRAM, it's not possible to edit programs unless they're in main memory, right?

Wrong, you can create/modify/delete a file in RAM or in IRAM.

(04-21-2021 03:54 PM)Dave Britten Wrote: Can you merge multiple RAM modules to create one big IRAM? (e.g. I have 3x 4K modules, can I use them as a single 12K IRAM?)

Merging is not done at the module level but at the chip level, that is how the FRAM71 module does it.

**rprosperi** · 04-21-2021, 05:15 PM

Adding to Sylvain's comments... (and this applies to real devices, emulators can be more flexible)

You cannot merge multiple physical modules into a single IRAM. In fact a 64, 96 or 128KB RAM module, while able to merge into the single 'system RAM' space, are constrained to be 32KB IRAMs.

For example, if you install a 64KB RAM module into port-1, it must be 'freed' in 32K ports chunks, as in:

FREE PORT(1.00) - Note: FREE PORT(1) and FREE PORT(1.0) are equivalent
FREE PORT(1.01)

yielding 2 x 32KB IRAM ports.

As for 'what retains the RAM?' it seems to be inherent capacitance in the overall system, which is likely why it varies from device to device and with differing modules installed.

No doubt some of the h/w pukes will comment on options to install caps, etc. but as far as I can tell, it's just inconsistent magic. I'd risk a Neo, but not a 71B... Wink

Dave Britten · 04-21-2021, 05:33 PM

(04-21-2021 04:59 PM)Sylvain Cote Wrote:
(04-21-2021 03:54 PM)Dave Britten Wrote: Regarding IRAM, it's not possible to edit programs unless they're in main memory, right?
Wrong, you can create/modify/delete a file in RAM or in IRAM.

Oh nice, sounds like I assumed wrong. So you can just EDIT MYPROG:PORT(1) and you're off to the races?

(04-21-2021 05:15 PM)rprosperi Wrote: No doubt some of the h/w pukes will comment on options to install caps, etc. but as far as I can tell, it's just inconsistent magic. I'd risk a Neo, but not a 71B...

What I lack in EE knowledge I make up for in daring with my soldering iron, as my 32 KB 42S can attest. Wink

Though I'd only attempt a cap swap/installation on a 71 if it's a fairly straight-forward opening of the case, with nice big solder pads for a reasonably large cap, and no mucking around with heat stakes.

Sylvain Cote · 04-21-2021, 05:47 PM

(04-21-2021 05:33 PM)Dave Britten Wrote:
(04-21-2021 04:59 PM)Sylvain Cote Wrote: Wrong, you can create/modify/delete a file in RAM or in IRAM.
Oh nice, sounds like I assumed wrong. So you can just EDIT MYPROG:PORT(1) and you're off to the races?

yep!

Easy to test, free up one internal 4K RAM module and try it.

Code:

FREE :PORT(0)    [ENDLINE]  // free up the first internal RAM module

EDIT ABC:PORT(0) [ENDLINE]  // create the BASIC program ABC in port 0.00 and make it the active file

10 REM TESTING   [ENDLINE]  // edit the basic program

CAT :PORT(0)     [ENDLINE]  // show port 0.00 content

CLAIM :PORT(0)   [ENDLINE]  // reclaim the port

Dave Frederickson · 04-21-2021, 06:28 PM

(04-21-2021 05:15 PM)rprosperi Wrote: You cannot merge multiple physical modules into a single IRAM. In fact a 64, 96 or 128KB RAM module, while able to merge into the single 'system RAM' space, are constrained to be 32KB IRAMs.

For example, if you install a 64KB RAM module into port-1, it must be 'freed' in 32K ports

Both the CMT and HHP 32k modules have a signal pin that corresponds to the Last-Chip-In-Module bit in the FRAM71 configuration nibble. It's possible to open the modules and reconfigure how the LCIM pins are connected to create RAM ports greater that 32k. There is a bug with the 1BBBB firmware and 64k ports, so be aware.

**rprosperi** · 04-21-2021, 09:14 PM

(04-21-2021 06:28 PM)Dave Frederickson Wrote:
(04-21-2021 05:15 PM)rprosperi Wrote: You cannot merge multiple physical modules into a single IRAM. In fact a 64, 96 or 128KB RAM module, while able to merge into the single 'system RAM' space, are constrained to be 32KB IRAMs.

For example, if you install a 64KB RAM module into port-1, it must be 'freed' in 32K ports

Both the CMT and HHP 32k modules have a signal pin that corresponds to the Last-Chip-In-Module bit in the FRAM71 configuration nibble. It's possible to open the modules and reconfigure how the LCIM pins are connected to create RAM ports greater that 32k. There is a bug with the 1BBBB firmware and 64k ports, so be aware.

FRAM71? Did you just mean 71B config table? Maybe I'm not following you about FRAM71?

I was referring to vanilla CMT & HHP modules as sold, but yes, this can be done, if you're intrepid and have a steady hand. One of my HHP 96K modules has been so converted to 64K/32K RAM module, which is handy for mastering 64K EPROM images, though Emu71/DOS and Emu71/Win are likely just as easy to use.

Dave Frederickson · 04-21-2021, 11:38 PM

(04-21-2021 09:14 PM)rprosperi Wrote:
(04-21-2021 06:28 PM)Dave Frederickson Wrote: Both the CMT and HHP 32k modules have a signal pin that corresponds to the Last-Chip-In-Module bit in the FRAM71 configuration nibble. It's possible to open the modules and reconfigure how the LCIM pins are connected to create RAM ports greater that 32k. There is a bug with the 1BBBB firmware and 64k ports, so be aware.

FRAM71? Did you just mean 71B config table? Maybe I'm not following you about FRAM71?

I was referring to vanilla CMT & HHP modules as sold, but yes, this can be done, if you're intrepid and have a steady hand. One of my HHP 96K modules has been so converted to 64K/32K RAM module, which is handy for mastering 64K EPROM images, though Emu71/DOS and Emu71/Win are likely just as easy to use.

The FRAM71 LCIM bit in the config nibble corresponds to the pin on the memory module used to configure the 3 modules in the HHP module. We discussed this at length before I attempted to replace the RAM chips on your 96k module.

Dave

**rprosperi** · 04-22-2021, 12:39 AM

(04-21-2021 11:38 PM)Dave Frederickson Wrote:
(04-21-2021 09:14 PM)rprosperi Wrote: FRAM71? Did you just mean 71B config table? Maybe I'm not following you about FRAM71?

I was referring to vanilla CMT & HHP modules as sold, but yes, this can be done, if you're intrepid and have a steady hand. One of my HHP 96K modules has been so converted to 64K/32K RAM module, which is handy for mastering 64K EPROM images, though Emu71/DOS and Emu71/Win are likely just as easy to use.

The FRAM71 LCIM bit in the config nibble corresponds to the pin on the memory module used to configure the 3 modules in the HHP module. We discussed this at length before I attempted to replace the RAM chips on your 96k module.

I understand about the PIN, just did not originally follow the FRAM reference, but yes indeed I now follow what you're saying here. Thanks.