HP-71B: Trying to run 2CDCC on a 1BBBB machine



#14

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


#15

+1, interesting. :)

#16

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)

#17

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.


#18

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

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

#19

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.


#20

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

#21

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.

good. that's pointing to maybe some byte error inside the 2CDCC dump that i'm using.

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.


hm... your question implies, that "write-protected" status is read during the "ID" phase also for the system ROM. i never saw that during logic analysis of the boot phase, hence i did not configure the intended RAM portion to be visible to the configuration code. maybe, that's exactly the problem.

let me describe, how i got the 1BBBB into the RAM. i simply put a block of read-dis-, write-enabled RAM at the same address (00000) as SYSROM. SYSROM was output-enabled. then, a simple basic-loop
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


copied SYSROM into the "parallel" SYSRAM. after that, SYSROM was set to output-disabled, and SYSRAM was set to output-enabled. after a further power-on, the calculator comes up normally and works just fine.
i am going to verify the 2CDCC code one more time. if that proves to be ok, i will include the SYSRAM portion as two 32KB blocks, that are visible to the configuration routine. the complete process of swapping the system area would then be as follows (all configuration of FRAM71 is done by poke-ing bytes into the card-reader MMIO area at 2C000h):
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


#22

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.


#23

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).

understood.

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.
no worries. your input finally nailed down some of the problems!

thx!

hans
#24

When can we get FRAM71's :-)

- Pauli


#25

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

#26

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.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime : Galton's machine Mic 0 317 11-15-2013, 04:23 AM
Last Post: Mic
  HP Prime: run a program in another program Davi Ribeiro de Oliveira 6 803 11-11-2013, 08:28 PM
Last Post: Davi Ribeiro de Oliveira
  HP PRIME: Hide return value from program and swap Edit with Run vrrr 2 560 11-09-2013, 04:04 PM
Last Post: vrrr
  Convergence Dream Machine anetzer 11 1,040 04-12-2013, 07:16 AM
Last Post: David Hayden
  Make PIL-Box ILPer program run on OS X Juergen Keller 6 775 09-07-2012, 04:38 PM
Last Post: Hans Holzach
  O.T. - A pristine machine Palmer O. Hanson, Jr. 4 485 08-08-2012, 12:16 AM
Last Post: Dave Shaffer (Arizona)
  HP48SX seems fully functional won't run SELF TESTS? Bruce Larrabee 5 657 07-16-2012, 11:04 PM
Last Post: Luiz C. Vieira (Brazil)
  HP-35A Production Run Questions Matt Agajanian 0 250 07-02-2012, 09:02 PM
Last Post: Matt Agajanian
  The Turing Machine Comes True Gilles Carpentier 1 324 06-26-2012, 09:26 AM
Last Post: Rory Molinari (USA)
  (OT) Lego Turing machine BruceH 9 787 06-22-2012, 08:14 AM
Last Post: Bill (Smithville, NJ)

Forum Jump: