Go To in Woodstocks

[teenix]

Hi all,

My first post :-)

I used to own a HP-45 back in the 70's onwards and I saw one some months back and it inspired me to have ago at creating my own. After delving into it, I had no idea there were so many people interested in such things, but I can understand why.

Anyway I get some free time working in remote areas and after many headaches and relying on other talented peoples past efforts I finally got it working. Afterwards I got the "HP bug" well and truly and decided to carry on with other models and now have the 6 Classic Series models working as a Windows application. It also has a compiler and debugger.

I also have all of them working as a real operating calculator complete with bubble LEDs and hardware memory cards for the HP-65.

I am doing this only as a personal challenge to stop my diminishing old grey matter from turning into don't matter and I would like to try the 67 next.

I have found code segments that appear to jump across ROM boundaries and as the instructions are only 10 bits with 8 for the target address I cannot see how this is accomplished. If this is indeed the case then having delayed select ROM n instructions would seem unnecessary.

I am obviously missing something but with limited resources I have ground to a halt.

Any insights for this problem are surely appreciated.

many thanks

cheers

Tony

[d b]

Tony; I am constantly astounded at the amount and quality of gery matter on this site. Welcome.

[PANAMATIK]

(05-17-2016 05:16 AM)teenix Wrote:  I have found code segments that appear to jump across ROM boundaries and as the instructions are only 10 bits with 8 for the target address I cannot see how this is accomplished. If this is indeed the case then having delayed select ROM n instructions would seem unnecessary.

I am obviously missing something but with limited resources I have ground to a halt.

Any insights for this problem are surely appreciated.

many thanks

cheers

Tony

Hello Tony,

The delayed ROM instructions can access only up to 16 ROM pages, which is 4k address range. The bank switch instruction 01060 was invented after 4k was not any more sufficient memory for the HP-67 and HP-97 code and extends the address range to potentially 8k.

The bank switch instruction toggles between the two 4k ROM banks 0 and 1 each time it is invoked. Additionally whenever an address within the first 1k is jumped to the bank 0 will be selected. If a ROM switch 01060 occurs, the next instruction will be fetched from the following address but in the other bank.

In the real calculators, some of the ROM chips contain two banks, others only one. Normally a bank switch instruction occurs only at ROM addresses of chips, which contain both banks, otherwise the opcode would be ignored. In fact, the HP-67 ACT ignores all 01060 instructions executing it as a nop instruction, only the ROM chips itself listen to this code and toggle their bank, if they have both. The first ROM chip at address 0 always has only one bank.

In an emulation it is usual to place the code of bank 1 behind the 4k code of bank 0, thus your emulator code in C could look like this.

Code:


void op_bank_switch () // bank switch instruction 01060
{
  bank=!bank;  // toggle between 1 and 0
}

When executing any instruction you have to get the opcode from the actual selected ROM bank like this:

Code:


uint16_t address = act_pc; // 12-bit program counter can address only 4k

  if (bank!=0)
  {
    if(act_pc<0x400)
      bank = 0;  // reset bank if address is  < 1k
    else
      address |= 0x1000; // bank 1 is used in HP-67 HP-97 with more than 4k ROM
  }
  opcode = Getopcode(address);

// now execute opcode

I hope this could help you to understand bank switching in the HP-67/97.

By the way, if you emulate 6 classic calculators, you have the complete set 35/45/55/65/70/80. I would be interested in having the HP-70 microcode. As far as I know this code has never been extracted? Do I miss something?

Bernhard

[teenix]

Hi Bernhard

Thanks for the response.

I'm still not sure if I get it tho...

This is part of key press code that confuses me, I think after pressing '7' key.

01547 load constant 10
01550 c + 1 -> c[x]
01551 if n/c go to 01531 // this seems ok - in same ROM page
01531 p + 1 -> p
01532 if 0 = s 4
01533 then go to 0412 // this seems odd - jumps to ROM 1 from ROM 3
....
00412 c + 1 -> c[x]

There are 2 [go to] instructions without any bank switching but jump to different ROMs in the same 8K bank. I have observed this behaviour when I ran an emulator on the web, but I thought a general [go to] was limited to the 8 bits in the instruction, assuming no delayed select or bank switch previous.

Yes, I got all 6 models working. lots of late nights over many months after my work shift. There were some interesting problems to solve as even the code listings seemed to have errors. I suspect maybe HP put some odd 'bugs' in the patent listings to fool those who might want to take advantage of them :-)

You are right I could not get the HP70 code as it doesn't seem to be available anywhere, so I reasoned it out and wrote what I thought it should be using the simulator/compiler I created. I based it loosely on the HP80 as much of the functionality was the same, but I had to create new code for the other stuff. It won't be exact code from HP but it seems to work correctly as per the documentation that I have available.

If you would like to visit the page, the Classic project is freely available at http://www.teenix.org and you can simulate and experiment with the code for each model.

It also has all the details to build a real calculator. The one circuit can run all 6 models plus I'm sure others as well. The PC software handles the communications with the calculator to change models via the USB port and can upload HP-65 programs to the memory cards.

These cards also work like the real HP-65 but I couldn't design the complicated original setup, so the cards are based on a miniature I2C memory chip. I originally had 1 program per card to try and be more realistic but they would be too expensive so the memory chip holds 64 programs and you can store a whole library like EEpac1 on the one card. They slide in the usual position under the display to be read/written to and can be removed and swapped for others.

cheers

Tony

[PANAMATIK]

(05-17-2016 10:36 AM)teenix Wrote:  Hi Bernhard

Thanks for the response.

I'm still not sure if I get it tho...

This is part of key press code that confuses me, I think after pressing '7' key.

01547 load constant 10
01550 c + 1 -> c[x]
01551 if n/c go to 01531 // this seems ok - in same ROM page
01531 p + 1 -> p
01532 if 0 = s 4
01533 then go to 0412 // this seems odd - jumps to ROM 1 from ROM 3
....
00412 c + 1 -> c[x]

There are 2 [go to] instructions without any bank switching but jump to different ROMs in the same 8K bank. I have observed this behaviour when I ran an emulator on the web, but I thought a general [go to] was limited to the 8 bits in the instruction, assuming no delayed select or bank switch previous.

the if n/c instruction can jump within the same 8-bit page. This goto is limited to 8-bit

All "if" instructions, like "if 0 = s 4", are followed by "then", which is a 10-bit jump address. This goto is not limited to 8-bit, but limited to 10-bit, because the instruction word is 10-bit wide.

Your work is very impressive!

Bernhard

[teenix]

Bernhard,

That makes sense now, you have made my day, many thanks.

I think your work tops the cake a bit. I can't imagine how much effort was put in.

cheers

Tony

[teenix]

Just a quick note..

It worked :-)

cheers

Tony

[PANAMATIK]

(05-17-2016 02:58 PM)teenix Wrote:  Just a quick note..

It worked :-)

cheers

Tony

It's a pleasure to hear that.

cheers
Bernhard

[bshoring]

(05-17-2016 09:19 AM)PANAMATIK Wrote:  By the way, if you emulate 6 classic calculators, you have the complete set 35/45/55/65/70/80. I would be interested in having the HP-70 microcode. As far as I know this code has never been extracted? Do I miss something?

Bernhard

Bernhard,
I don't know if this is helpful, but Willy Kunz, of Cuvée Software, created a beautiful emulator of the HP-70 for iPad & a separate one for iPhone.

[PANAMATIK]

(05-19-2016 06:52 AM)bshoring Wrote:  Bernhard,
I don't know if this is helpful, but Willy Kunz, of Cuvée Software, created a beautiful emulator of the HP-70 for iPad & a separate one for iPhone.

Thank you for this hint. I own his RPN-70 calculator already since long time for my iPhone. According to the description it is a perfect simulation of the HP-70, not an emulation. It doesn't run the original microcode, but makes the same calculations with a modern math library. Normally the calculation results of a simulation differ slightly from the original. Please Willy, correct me if I'm wrong.

If I owned a real HP-70 I would be able to extract the ROM microcode, which make an emulation possible. But they are very rare.

Bernhard

[teenix]

Hi,

I set up the 67 compiler and emulator to work as follows for the [if..go to] scenario.

I may be wrong, but I cant see any reason for the CPU to work out what type of [go to] instruction is executed as the binary code is the same. Eg (go to, then go to, if n/c go to)

It would seem logical then that the [if] statement is the key.

I'm sure the original designers would have expected that programmers after adding an [if] statement, would follow up with a [go to] statement, otherwise the [if] becomes redundant.

The [67] compiler on detecting any [if] statement (eg. if c[x] = 0), sets an [IF_Detect_Flag]. The next instruction is read and assembled and if the flag is set will test for a [go to] instruction. If it is not, the compiler will generate an error message and exit, otherwise the next CPU code will be the 10 bit value from the [go to] statement.

The [if..go to] sequence can only work within a 1K block of code (10 bit addressing) so the compiler will generate an error if a [go to] target address is outside the current 1K block.

The CPU works similar. If it detects an [if] instruction, it too sets an internal flag.

After any instruction fetch, this flag is tested. If = 0 then the code is treated as an instruction, if = 1, then the 10 bit data is treated as a new PC address and the lower 10 bits of the PC are replaced by the code value and the flag is reset.

This approach seems to work ok in the emulator.

cheers

Tony

[PANAMATIK]

(05-19-2016 11:46 PM)teenix Wrote:  I may be wrong, but I cant see any reason for the CPU to work out what type of [go to] instruction is executed as the binary code is the same. Eg (go to, then go to, if n/c go to)

Actually there is no unconditional goto in the CPU instruction set. Therefore the opcode of "goto" and " if n/c goto" are the same. If you want to jump unconditionally, the previous instruction must clear the carry flag like any instruction other than add sub etc. does.

(05-19-2016 11:46 PM)teenix Wrote:  The [67] compiler on detecting any [if] statement (eg. if c[x] = 0), sets an [IF_Detect_Flag]. The next instruction is read and assembled and if the flag is set will test for a [go to] instruction. If it is not, the compiler will generate an error message and exit, otherwise the next CPU code will be the 10 bit value from the [go to] statement.

The [if..go to] sequence can only work within a 1K block of code (10 bit addressing) so the compiler will generate an error if a [go to] target address is outside the current 1K block.

The CPU works similar. If it detects an [if] instruction, it too sets an internal flag.

After any instruction fetch, this flag is tested. If = 0 then the code is treated as an instruction, if = 1, then the 10 bit data is treated as a new PC address and the lower 10 bits of the PC are replaced by the code value and the flag is reset.

This approach seems to work ok in the emulator.

This is the correct approach. Congratulations!

You could add a compiler warning if a "if n/c goto" points to an instruction which is a 10-bit jump, because it is preceded by an " if" instruction. But this does never occur in any original HP code.

Bernhard

[teenix]

That might be difficult due to the delayed rom/group select as you would have to track these before any [go to]'s, and probably wouldn't be reliable.

Might be better to flag a debugger run time error if a [go to] lands at an address word.

cheers

Tony

[Alejandro Paz(Germany)]

Hello teenix.

I've been testing your HP67 Emulator and noticed some issues with the display.

1. The / segement display doesn't show the segment 'd', an '8' looks like an 'A'.
2. In the debugger, register A shows half a zero on the left of the 14th digit.
3. The memory bank buttons don't seem to work all the time. They light up but the
bank display below doesn't show the new selected bank. Pressing Bank1 then Bank2 shows bank 2 but pressing Bank3 produces no change.

This is a fantastic collection with very nice documentation, very good !

Note: just to unpack a couple of files in a directory, you do not need an installer that needs admin rights. A packed file that you could unpack where you want is, imho, enough.

[teenix]

I've been testing your HP67 Emulator and noticed some issues with the display.

1. The / segement display doesn't show the segment 'd', an '8' looks like an 'A'.

Works ok on my PC, which OS are you using.

2. In the debugger, register A shows half a zero on the left of the 14th digit.

You might have a larger font size selected for your PC and the text is extending past the boundaries of the display. I will widen them slightly.


3. The memory bank buttons don't seem to work all the time. They light up but the
bank display below doesn't show the new selected bank. Pressing Bank1 then Bank2 shows bank 2 but pressing Bank3 produces no change.

Look under Options menu (right click calculator) you will have Auto RAM bank switching selected to ON. I will change to OFF = Default.

This is a fantastic collection with very nice documentation, very good !

Thanks


Note: just to unpack a couple of files in a directory, you do not need an installer that needs admin rights. A packed file that you could unpack where you want is, imho, enough.

Too true, zipped files are probably easier to deal with. Next upload perhaps.

cheers

Tony

[Alejandro Paz(Germany)]

I'm using win10.

I haven't selected any fonts, I'm using whatever it defaults to. The thing is that only register A shows a half zero, the other registers show 14 digits of the exact same size. Register A is shown in a slightly larger fornt. All 14th digits start exactly on the same x coordinate, except on register A. This seems to disappear after a run/stop.

Maybe is that auto-bank feature, but the bank buttons light up confusing things, I think.

[Dieter]

(07-02-2016 06:55 AM)teenix Wrote:  I've been testing your HP67 Emulator and noticed some issues with the display.

I bet you have been testing your own HP67 emulator. ;-)
But this is not what you wrote, it's a quote of someone else.

Tony, your posts often look quite confusing as you are mixing your answer and quotes from previous posts. So noone can say what you say and what someone else did. Please use the big QUOTE button below the post you want to reply to. Then edit your post by putting [/quote] and [/quote] tags around the quoted text. Thank you.

BTW:

(07-02-2016 06:55 AM)teenix Wrote:  Too true, zipped files are probably easier to deal with. Next upload perhaps.

I'd strongly recommend this, too.

Dieter

[teenix]

Hi Dieter,

> Tony, your posts often look quite confusing as you are mixing your answer
> and quotes from previous posts.

Sorry, my mind may be a little warped

I will try harder in future.

cheers

Tony

[Alejandro Paz(Germany)]

As I posted somewhere else, I'm working on a HDL implementation of the woodstock circuitry, not an emulator , there are already many of them.