Best way to test HP-71B RAM modules (the 32K/96K ones etc.)?

[Philippe Lasnier]

Hi guys,

I know that the forum is currently swamped with Prime news, but I have a small task I'd like to get through: sorting out my heap of calculators.

I'm currently going through my 71Bs, and I've got two RAM modules, from Hand Held Products (the ones that you put in where the magnetic card reader goes): a 32K one, and a 96K one (32 KiB / 96 KiB, to be very precise).

The problem I've got is trying to make sure that the modules are sound, i.e. no fault.

I couldn't find any obvious built-in command to do such a diagnostic, but could there be something? or could there be programs already out there (published or not) that would do that?
Of course, failing all that, I'd write a small BASIC program that cycles through memory, writing various bit patterns and checking them, but that feels tedious and slow. I would have expected that many people in the distant past would have needed to check their RAM modules, and that there would be existing solutions out there...

Thanks,

Philippe

[Hans Brueggemann]

Hi philippe,
easiest way to test the RAM is using the DIAGNOSTIC module (quite a rare animal, though). another way of doing a simplistic RAM test is by using a function that can handle large arrays. you would then DIM an array to a size that it almost covers all the RAM, fill it with predefined values and do some calculations on it, where you know the correct results. the MATH module comes in very handy there. i've been using it for testing my FRAM71. the objective is to have most of the calculations being performed in machine code rather than on BASIC level, in order to keep testing time down.

best regards,
hans

Edited: 24 Sept 2013, 7:10 a.m.

[Philippe Lasnier]

Thanks Hans,

Unfortunately I have neither the DIAGNOSTIC module nor the MATH module. As for assembly, I would need to learn, get an emulator, an assembler, download the program... I'm sure it could be fun, but I've never done it, and for this exercise this is not worthwhile - I only need to test a couple of modules!
So, the slow way with a BASIC program. Oh dear...

Well, in a way this was fruitful: I wrote a small BASIC program that would ask for an integer array size, define the array, fill it with 88888, then check it was filled properly. I would have then added setting and checking for 0, or 11111, whatever, but as it turned out, just this was enough to detect that my 96 KiB module was broken: as soon as I ran the program asking for 38000 entries in the array (~111 KiB used), the HP-71B blinked, then displayed "Memory Lost". I re-entered the program, then slowly re-tested by entering larger and larger size values. 35000 was ok, 36000 was ok, 37000 - Memory Lost again.

I don't have a memory map for the HP-71B (I'm sure I'd seen it somewhere though...), but I would hazard that some stack memory ended up in that module's space, proving indirectly that the module was fried. Oh well.

My 32 KiB module on the other hand seems to be faring well: if I allocate the array with increasing sizes, it eventually politely tells me "ERR:Insufficient Memory"; it doesn't reset the machine! The program ran and successfully checked that each array entry is equal to 88888 (I'll run more tests with various values later).

That's not a full test really (checking for all bit changes and persistence etc.), but I guess that will have to do.

[Garth Wilson]

It seems like FREE PORTing the module (in 32K ports, like 5.00, 5.01, and 5.02 IIRC) ought to keep the computer from losing memory no matter what happens. I would just make it all one file, maybe a DATA or TEXT file, and have a program step through it, storing and reading back. Even if it takes hours in BASIC, it's no problem if you have it do it while you're sleeping or working or whatever.

[Philippe Lasnier]

Hi Garth,

Yes, thanks for the tip; that just shows you that I'm not familiar enough with the capabilities of the HP-71B.

Trying it on with my 96 KiB module, it was soon obvious that something was wrong: FREEing PORT(5.00) pretended to work, but SHOW PORT didn't report it as FREEed. After some fumbling around and FREEing some other ports, I eventually got 5.00 and 5.01 FREE, but although MEM(5.01) reported 32763 bytes, MEM(5.00) reported 293863 bytes - obviously incorrect. Then, creating a file in 5.01 worked fine, but creating a file in 5.00 immediately sent the 71B into a spin: the display went funny, then went blank, then I got "Memory Lost".

I haven't tried any of that with the 32 KiB module, but I suspect it will work properly.

Thanks for all the help.

Philippe

[Edited for proper number of bytes]

Edited: 25 Sept 2013, 10:00 a.m.