HP Forums

in my FRAM71 project, i am currently investigating the possibility of running 2CDCC firmware on a machine that has a 1BBBB ROM version. i succeeded in loading 1BBBB into a ROM-parallel RAM segment, and OD-ing the internal ROM. the machine boots up just fine and is functioning as expected.
however, after changing the contents of that RAM segment to 2CDCC, the machine boots up, has a blank display, and doesn't respond to any keyboard entries, including [on][/].
does anybody have a clue as to whether and how 2CDCC machines differ in internal hardware from 1BBBB ones?
any help is very much appreciated!
best regards,
hans

Edited: 27 Apr 2012, 1:37 p.m. after one or more responses were posted

+1, interesting. :)

Hi.

What are the chances of simply internal resources' address remapping? AFAIR, vintage equipment used to be address dependent, I mean, all hardware were designed to work in a pre-defined I/O address. The simpler example I can recall for now is the RPN-based stack registers address. In the HP41 all five stack registers (I always include the LASTx as a stack register...) have fixed addresses, but in the newer machines, like the HP42S, they may simply not exist in RAM, being just pointers. If you copy the contents of the X-register into Y, Z and T in the HP42S, the copies do not occupy extra space, you'll just have pointers to them. On the other hand, all stack registers in the HP41 (and any earlier calculator) always occupy the same RAM space.

If you consider the chance of having the same basic hardware with a different I/O addressing scheme, the 2CDCC will only work in a 1BBBB based hardware after 'correcting' all device's addresses. I guess this was the very reason all computers form that time had their O.S. already recorded in ROM (Sinclair, for example).

My thoughts, though.

Cheers.

Luiz (Brazil)

In later HP-71B units, the original 1LF2 Saturn processor was replaced by the 1LK7 (also used in the HP-18C and HP-28C). The 1LF2 was architecture level 0, while the 1LK7 was architecture level 1, adding a few instructions to the instruction set.

It is possible that 2CCCC and 2CDCC might use the new level 1 instructions. I don't think that they would have wanted to do that, because they'd have wanted to be able to use the new ROM in old units when repaired.

Other than that, I don't think there should be any hardware change that is visible to software.

You might try running 1BBBB on a machine with a 2CCCC or 2CDCC ROM.

Edited: 27 Apr 2012, 2:37 p.m.

good point! now looking for a 2CDCC testbed...

Edited: 27 Apr 2012, 3:35 p.m.

At least in the existing HP-71B emulators, it is possible to switch from 1BBBB to 2CDCC using the same hardware emulation layer as described in the HIDS documents.

Is your 64k segment at address 00000 write-protected, I mean emulating a ROM not a RAM? I think it was needed for my emulator to run correctly.

When can we get FRAM71's :-)

- Pauli

I just released an hp71b emulator for android.

I used the public nomas docs from hp based on 1BBBB machine, with level 0 cpu instructions. I had no troubles to use 2CDCC roms.

But on some docs about rom ic, it is said that the rom are always 'configured' on the bus at the 0x00000 address. Perhaps this behavior is due to bus contention.
(with RAM and ROM with same contents, no contention, with RAM and ROM with different contents, read can lead to contention)

I just look at docs about DO pins, so no contention ...

Perhaps, double check that RAM configured as ROM in this case is not 'unconfigured' ... the boot code begins by unconfiguring ALL. But in this case, system ROM (hard configured ones) and LCD RAM should stay configured !

Olivier

P.S. I just tested my emulator at cold start with 2CDCC roms, there is no write in rom space ...

Edited: 28 Apr 2012, 8:07 a.m.

I just made a hack to my Emu71/Win v1.01.

First off all I removed the two level 1 opcodes "rsi" and "PC=(A)" to emulate the 1LF2 CPU.

2nd I changed the read only state of the ROM to read/write so it looks like RAM.

The emulation with 2CDCC ROM and HPIL module 1BB is working properly in ths condition on Emu71/Win v1.01.

Christoph

Quote:

---

At least in the existing HP-71B emulators, it is possible to switch from 1BBBB to 2CDCC using the same hardware emulation layer as described in the HIDS documents.

---

Quote:

---

Is your 64k segment at address 00000 write-protected, I mean emulating a ROM not a RAM? I think it was needed for my emulator to run correctly.

---

10 DIM A$[64]

20 B$="00000" @ B=HTD(B$)

30 FOR I=0 TO 64*32-1

40 Y$=DTH$(B+I*64)

50 A$=PEEK$(Y$,64)

60 POKE Y$,A$ @ DISP Y$

70 NEXT I

80 END

1) configure intended SYSRAM as standard RAM (dev type 0)

2) after power-on, this part of RAM will be located at 30000h.

3) fill RAM at 30000h with new system code

4) re-configure RAM at 30000h to be soft-configured ROM (dev type 1)

5) power off

6) set SYSROM's OD to "high" (currently done by jumper)

7) power-on

thanks all for your help, will be keeping you posted!
hans
btw... that basic peek/poke loop is dead slow. somebody in the forum here pointed me already to using the FORTH module's "cmove" instead, but i can't get it to work. any hints as to what the code should look like?

Edited: 30 Apr 2012, 11:39 a.m. after one or more responses were posted

pauli, that will still take quite a while, maybe Q4/2012. i have a handful of unpopulated p.c.b.s here, and those that are populated for testing are working o.k. currently, i am not satisfied with the automatic translating transceiver (onsemi NLSX3018) between the FPGA and the HP-71B bus, because it is used beyond its max voltage ratings (5.5Vmax vs. 6V of the HP-71B), and it is at its limits driving the bus capacitances. still looking for a viable, and (!) small solution.
hans

To check your HP-71B system ROM, you can use the tool on Christoph's page .
Or you can compare to the ROM image here.

The system ROMs don't answer to the ID/RESET/CONFIG opcodes, they are hard-configured at 0 (unless disabled by OD line).

Regarding my remark about the write-protected status, I can't reproduce any issue with it, probably I introduced it in my emulator to just protect against a POKE to the system ROM space. Sorry for the wrong indication.

thanks J.-F.,christoph's titanchk.exe revealed some problems with the *.bin file, indeed. however, the problem persists. i also checked the data transfer between PC and HP-71B, i am using a 82164A that i modified to USB output, and an old TELIX for windows (don't laugh)on a windows 7 laptop. quite a reliable combo for ascii-transfers.

Quote:

---

The system ROMs don't answer to the ID/RESET/CONFIG opcodes, they are hard-configured at 0 (unless disabled by OD line).

---

Quote:

---

Regarding my remark about the write-protected status, I can't reproduce any issue with it, probably I introduced it in my emulator to just protect against a POKE to the system ROM space. Sorry for the wrong indication.

---