HP-71B MultiMod ROM Emulator - Issues ?

[Sylvain Cote]

Hello Mark,

First impression, pcb is clean, solder joins are impeccable, superb quality, nicely done, congratulations.
Daniel has also done a great job on the MultiMod casing, it's way better than the ones from CMT and HHP.

All three modules works.
I was confused at first because PEEK$("2C000",1) always report "0" even after doing a POKE "2C000","1".
I am using VER$ to validate that the module is active, PEEK$ would have been better thought.

It seems that there is a compatibility issue with some 71B.
All three modules work on S/N: 2713A00041 but none works on S/N: 2410A00146.
I know the card reader port works on S/N: 2410A00146 because it usually hosts a working FRAM71 module.
I will be testing the MultiMod modules on more machines tomorrow.

I am still using the default configuration on all three MultiMod modules.

Sylvain

[mfleming]

(03-27-2021 03:35 AM)Sylvain Cote Wrote:  Hello Mark,

First impression, pcb is clean, solder joins are impeccable, superb quality, nicely done, congratulations.
Daniel has also done a great job on the MultiMod casing, it's way better than the ones from CMT and HHP.

Thanks Sylvain! Only headers are hand soldered, components are reflow soldered. Dan is indeed to be congratulated on the enclosure design. Pictures don't do justice.

Quote:All three modules works.
I was confused at first because PEEK$("2C000",1) always report "0" even after doing a POKE "2C000","1".
I am using VER$ to validate that the module is active, PEEK$ would have been better thought.

Only the ROM data are mapped into the Read address space. Never occurred to me to map the CR I/O address range into the Read rather than just the Write. There are obvious possibilities for status presentation though. Could be done, I'll look into it.

Quote:It seems that there is a compatibility issue with some 71B.
All three modules work on S/N: 2713A00041 but none works on S/N: 2410A00146.
I know the card reader port works on S/N: 2410A00146 because it usually hosts a working FRAM71 module.

Thankfully I was dumb-lucky enough to to acquire a second 71B during development, an early 2406A metal back model (original model I was using was 2724A). These very early models have a significantly different bus access timing profile compared to the published HW IDS specs. My early 71B failed or locked up when first used, so I had to adjust emulator timing to match. J-F has some 'scope traces illustrating the differences in timing vs. later models. Timing compensation could likely be possible for these early, I believe slower clock models, but it would need to be a separate code branch. A fix for this would present a timing headroom risk for the bulk of the later models, so would need to be managed and distributed separately. A change wouldn't be hard but you'd have to be the test guinea pig on this one Best to see if any others are affected first.

Quote:I will be testing the MultiMod modules on more machines tomorrow.

Thank you very much for doing so!

Quote:I am still using the default configuration on all three MultiMod modules.

Here's a bit of fun. Try poking a "1" to the 2C000 address so that uLib52 isn't enumerated, then execute a uLib command. It works, at least for me, despite the fact the uLib ROM doesn't show in VER$, SHOW PORT, or CAT :PORT(5.03). Ack! Code hairball.

~Mark

[J-F Garnier]

(03-27-2021 06:22 AM)mfleming Wrote:  

Quote:It seems that there is a compatibility issue with some 71B.
All three modules work on S/N: 2713A00041 but none works on S/N: 2410A00146.
I know the card reader port works on S/N: 2410A00146 because it usually hosts a working FRAM71 module.

Thankfully I was dumb-lucky enough to to acquire a second 71B during development, an early 2406A metal back model (original model I was using was 2724A). These very early models have a significantly different bus access timing profile compared to the published HW IDS specs. My early 71B failed or locked up when first used, so I had to adjust emulator timing to match. J-F has some 'scope traces illustrating the differences in timing vs. later models.

For anybody interested here is the document I shared with Mark some time ago, with the timing difference on last slide.
The difference seems to be related (at least on my machines) to the CPU type: 1LF2 on first HP-71B generation, then 1LK7 (same as in the 28C) in the latest HP-71B.
It could be interesting to correlate the problems with the CPU type, I wrote a small LEX to identify the CPU type, it can be found here.

Quote:Here's a bit of fun. Try poking a "1" to the 2C000 address so that uLib52 isn't enumerated, then execute a uLib command. It works, at least for me, despite the fact the uLib ROM doesn't show in VER$, SHOW PORT, or CAT :PORT(5.03). Ack! Code hairball.

No that's not possible, if the ULIB52 keywords are working, the VER$ should also.
It may just that you're also using the FORTH Pac revision B that already includes STRUTIL which provides a part of the User Lib keywords. Try with a ULIB52 function that is not in STRUTIL, such as COMP$(" ").

J-F

[edited to correct CPU ref 1LK7]

[Sylvain Cote]

Hello Mark,

These are the test results with the machines that was easy to reach, I surely have other 71B elsewhere, I have to dig deeper.
Fortunately, my limited testing sample shows this timing problem seems affecting very few units.

Sylvain

Test cases:

Code:

Test #1: POKE "2C000","0" → Expected: HP71:xxxx
Test #2: POKE "2C000","1" → Expected: HP71:xxxx FTH:1B EDT:A KBD:C STRU:A MATH:2B JPC:F05
Test #3: POKE "2C000","3" → Expected: HP71:xxxx FTH:1B EDT:A KBD:C STRU:A MATH:2B JPC:F05 ULIB:c

Test results:

Code:

Serial     : Back    : Battery : VER$  : Status
2845A00123 : Plastic : Foam    : 2CDCC : All tests passed
2724A00900 : Plastic : Foam    : 2CCCC : All tests passed
2713A00041 : Plastic : Foam    : 1BBBB : All tests passed
2707A00223 : Plastic : Foam    : 1BBBB : All tests passed
2530A00247 : Metal   : Spring  : 1BBBB : All tests passed
2527A00330 : Metal   : Spring  : 1BBBB : All tests passed
2451A00286 : Metal   : Spring  : 1BBBB : All tests passed
2410A00145 : Metal   : Spring  : 1BBBB : Only test 1 passed
2401A00190 : Metal   : Spring  : 1BBBB : All tests passed

Note: SN:2410A00145 → all three MultiMod modules failed to work but the FRAM71 module is working with this unit

[mfleming]

My initial assumption that the failure of the one unit you have is due to a bus timing issue might be weakened by the fact the the unit (2410A) is bracketed by earlier (2401A yours, 2406A, mine) and later models in your list. If it is a late output settling time issue then your CPU may be a real outlier. Makes sense that hardware (FRAM71) would have no issue while software-emulating-hardware does.

The fact that all three boards don't work in that unit pretty much rules out the microcontroller is getting stuck in the boot loader, but you might try this to verify: Insert the board, cycle the 71 on then off so it probes the Port, go into the serial monitor and use the Plug command (PLUG YES) to plug in the ROMs, then Quit the monitor and see if a VER$ command reports anything. Unlikely, but worth confirming.

Quote:No that's not possible, if the ULIB52 keywords are working, the VER$ should also.
It may just that you're also using the FORTH Pac revision B that already includes STRUTIL which provides a part of the User Lib keywords. Try with a ULIB52 function that is not in STRUTIL, such as COMP$(" ").

J-F

That explains it! I was using ROT$ as a test that the ROM was really present in the address space.

BTW, congratulations Sylvain on such a collection of 71's. Perhaps you could arrange them in an HP-IL loop and mine Bitcoin

[Dave Frederickson]

(03-27-2021 03:35 AM)Sylvain Cote Wrote:  All three modules work on S/N: 2713A00041 but none works on S/N: 2410A00146.
I know the card reader port works on S/N: 2410A00146 because it usually hosts a working FRAM71 module.

This could still be a contact problem. You might try giving the card reader port pins a good cleaning with DeoxIT "D" formula or a pencil eraser.

[dmh]

(03-27-2021 06:22 AM)mfleming Wrote:  Thankfully I was dumb-lucky enough to to acquire a second 71B during development, an early 2406A metal back model (original model I was using was 2724A). These very early models have a significantly different bus access timing profile compared to the published HW IDS specs. My early 71B failed or locked up when first used, so I had to adjust emulator timing to match. J-F has some 'scope traces illustrating the differences in timing vs. later models. Timing compensation could likely be possible for these early, I believe slower clock models, but it would need to be a separate code branch. A fix for this would present a timing headroom risk for the bulk of the later models, so would need to be managed and distributed separately. A change wouldn't be hard but you'd have to be the test guinea pig on this one Best to see if any others are affected first.

Just to clarify, does this mean my MultiMod (which is still on its way) won't work in my 1BBBB 71B or probably won't or 50/50?

TIA, dmh

[mfleming]

(03-28-2021 07:11 AM)dmh Wrote:  

(03-27-2021 06:22 AM)mfleming Wrote:  Best to see if any others are affected first.

Just to clarify, does this mean my MultiMod (which is still on its way) won't work in my 1BBBB 71B or probably won't or 50/50?

TIA, dmh

Impossible to answer based on a single datum. The cause itself is still a WAG, but seems to be statistical in nature. Given the number of boards out there (20+), the number of 1BBBB models that run ok, it seems unlikely you'll have a problem. There's always the return for full refund option though if you throw craps. You should know soon enough according to tracking

Your item departed a transfer airport in KINGSFORD SMITH, SYDNEY, AUSTRALIA on March 26, 2021 at 8:43 am. The item is currently in transit to the destination.
Tracking Number: LZ994291511US

Cheer up!
~Mark

[Diego Diaz]

Hi all,

Just to confess my envy about all this testing/config/debugging process I'm missing while in Caribbean.

Hopefully it will still be some fun left by the time I get back home by en May. :-D

Meanwhile, I'll keep an eye on this thread...

Congrats Mark for this outstanding new device.

Keep on ejoying guys!

Diego.

[mfleming]

Hey Diego,

Enjoy the good weather there, hurricane season is only a couple of months away. They broke records last year!

If you're that bored, check the code in the github repository. The result of timing risk analysis is in the timing considerations and timing failure point sections near the bottom of the header commentary in the rommain.asm file. More detail is in the header of the LOADREG macro in the macros.inc file. Given the tight timing constraints I had to decide between favoring hosts with fast clocks versus those with slow bus settling times. I went with fast clock, so some fraction of slow machines may fall off their far end of the bell curve. Those would be the early models with the Saturn 1LF2 CPU by J-F's analysis.

Them's the breaks,
~Mark

[Sylvain Cote]

(03-27-2021 03:49 PM)Dave Frederickson Wrote:  

(03-27-2021 03:35 AM)Sylvain Cote Wrote:  All three modules work on S/N: 2713A00041 but none works on S/N: 2410A00146.
I know the card reader port works on S/N: 2410A00146 because it usually hosts a working FRAM71 module.

This could still be a contact problem. You might try giving the card reader port pins a good cleaning with DeoxIT "D" formula or a pencil eraser.

You were right Dave, I cleaned up the contacts and the three modules are now working.
But there is something fishy here between the card reader port contacts of that machine and the MultiMod module.
About half the time, if I plug any of the three modules it is not working, then I remove the module, re-insert it again, then it will work or not, redo the same thing and at some point it will work.
This is one of two main 71B machines were I plug and unplugged all kind of modules all the times and never had any issue with the card reader slot before, very strange.
Same machine, card reader port modules tested today and working on the first insertion time: FRAM71, FRAM71B, CMT-CR-96R #1, CMT-CR-96R #2 & HHP-71M/M-32K/32K.
Maybe the pins are little bit smaller on that machine and it is having difficulties creating a contact with the module pins, I do not know, more investigation is needed on my part.
Still, this is good news, all the modules are now working on that machine.
Sylvain

[Dave Frederickson]

(03-29-2021 03:14 AM)Sylvain Cote Wrote:  Maybe the pins are little bit smaller on that machine and it is having difficulties creating a contact with the module pins, I do not know, more investigation is needed on my part.

Each pin socket has 4 electrical contacts. Portions of a card reader pin are not be wiped by the socket contacts so when a different module is plugged in with different socket orientations it's possible that a pin may not make good electrical contact and when all 4 contacts in a socket don't make contact you have a problem. Repeated insertion and removal of the module will wipe the pins and the contacts will begin to work. Eventually all 4 contacts will make contact with the pin and the connection will function reliably.
Note that if some, but not all of the socket contacts are not working, the resistance may be low enough for continuity, but the pin won't be able to carry the full rated current.

You can directly attack the problem by cleaning the card reader pins with solvent or a mile abrasive, like a pink eraser.

Dave