HP97 The journey begins

[Paul Dale]

(11-13-2021 11:05 PM)teenix Wrote:  I did furniture removals for a job once, worst ever. My hat is off to the people that do it but I wouldn't go back there again.

I'm paying for most of the packing and lifting but there is still an huge amount to get done.

Removals is definitely a job for the young and fit. Neither of which I am anymore.


Pauli

[dmh]

I can drop a couple of cards round if you like Tony.

(11-13-2021 01:00 AM)teenix Wrote:  Hi all,

I had a bit of trouble with the card reader, but it appeared to be because of the transferring of code from the other processor to this one. The sense chip operates from different IO pins on this processor and I found a bug there. Also the code works in a different way in the new processor because it has to work independent of the printer and vice versa. As such, a few variables that were used in the card process did not work anymore but once they were altered the card read/write seemed to come to life.

It is a bit difficult to test this part of the board. It looks like the motor coupler slips intermittently so it will need replacing and I'm not sure if the single magnetic card I have works properly or not. If they play up unnoticed, it can lead to a long chase into complex code for faults that may not exist.

Still some testing to go and once that is complete, I will add code for the IR printer and 97S interfaces.

I think HP probably designed the whole 97 in less time than it has taken me to do the main board, but it has been a trip.

cheers

Tony

[teenix]

(11-14-2021 07:17 AM)dmh Wrote:  I can drop a couple of cards round if you like Tony.

An extra card would be nice, if you get a chance to find and drop off another motor for your 65

cheers

Tony

[teenix]

Hi all,

I thought I might post a picture of the 97 CPU board in situ.

Still progressing.

cheers

Tony

[Paul Dale]

Looks great.

Pauli

[Chr Yoko]

(11-15-2021 09:34 AM)teenix Wrote:  Hi all,

I thought I might post a picture of the 97 CPU board in situ.

Still progressing.

cheers

Tony

You seems to have managed the mechanical tolerances pretty well as the assembly looks super-hyperstatic !

[teenix]

Hi all,

I thought Murphy was popping in again. It seems as soon as I post a picture showing progress, he decides to throw in a bug. Maybe if I stop grinning when I get something working, he won't be tempted to drop by.

The motor driver IC has built in protection for overheat and over current etc and the processor monitors the fault output while printing. If a fault is detected the printer motor and heads are shut down immediately and will not resume until a power off/on cycle has been performed. The display will show a Motor Error message and if the beeper is enabled, a beep will sound.

Until I fitted the board properly into the 97 chassis, everything appeared to work fine. Then on odd occasions, a print fault would occur. I assumed overheating of the motor IC. This chip has 10 pins and is only 3mm square and not easy to work with. Underneath it has a small metal pad which is supposed to be soldered to the circuit board copper area which acts as a heat sink. I cannot solder the IC to the board like this, that needs professional and costly assembly and removal also becomes difficult. However, I have large copper areas feeding in and out underneath the IC and I used some thin double sided tape between the IC and circuit board. This tape is purposely designed for thermal transfer.

After printing quite a few wide lines of text, I could not feel any heat emanating from the IC so I assume it is doing the job.

I connected the oscilloscope to the fault output and discovered that when the motor is first activated, the fault pin would activate for about 10uS. This signal was picked up by the processor and halted the print process. Obviously the relatively high motor start up current causes a small blip in the IC error circuits. I modified the software to be a little bit tolerant of the fault conditions and now it appears to work ok.

At least I know the printer shut down protection works. There is also printer protection in case the processor has a spaz attack and goes astray. In this case it will shut down the printer and do a full restart.

cheers

Tony

[hpux735]

(11-15-2021 10:29 PM)teenix Wrote:  This chip has 10 pins and is only 3mm square and not easy to work with. Underneath it has a small metal pad which is supposed to be soldered to the circuit board copper area which acts as a heat sink. I cannot solder the IC to the board like this, that needs professional and costly assembly and removal also becomes difficult.

Hi Tony

I've had good luck with solder paste and a toaster oven for these kinds of ICs.

https://housedillon.com/posts/toaster-oven-reflow-oven/
https://housedillon.com/posts/qfn-reflow-soldering/

[teenix]

It might be worth a look. I usually just use flux paste and a chisel solder tip which works ok.

I don't want to solder the underside of the chip though if I can help it.

Thanks

cheers

Tony

[teenix]

Hi all,

More progress...

I have the basic 97S interface working. The connection is via an electrically isolated RS232 port at the top rear of the circuit board.

This can be directly connected to any 5V device that can accept a serial port, examples are: PIC or other processor, Arduino, Raspberry Pi, even PC via FTDI USB or similar. The user would be expected to know how to program these devices so that they can process whatever it needs to and convert that into a simple data stream to the 97. The serial protocol is very simple, so far only 3 commands, and operates at 19200 baud [8N1].

I programmed a small PIC to read the voltage on one of its pins when a button was pressed. The pin was connected to a trimpot that can adjust the voltage between 0 and 5 volts. I put some simple code together that converts the voltage to BCD values with a units digit and three digits after the decimal point.

When the button was pressed the PIC read its A2D converter and produced a 10 bit result of $294. The simple code converts this to a BCD value which is 3229.

The 97S has digit values for a decimal point [10] and Continue at A [13] so those were added. Therefore for a BCD voltage of 3229 with a fixed decimal point, the data created is [3][10][2][2][9][13].

If the 97S module is enabled on the 97 by the user, and it can accept new data, it is sent (in this case) as 3 packed bytes -> 3A 22 9D.

The 97 will receive this data then convert it to keycodes and add them to the [PIK] key buffer.

The 97 had a simple program created - [LBL A] [FIX 3] [PRINT X] [RTN]

The result of all this is that when a button press occurred, 3.229 was displayed and printed.

At some future time, the printer may also be used to append a message so that, it might print "3.229 VOLTS" or "WEIGHT: 3.229 KG".

cheers

Tony

[hpux735]

Shutup and take my money!

[TomC]

Tony:

Excellent Progress!!!

Cost and Delivery Time?

TomC

[teenix]

(11-18-2021 01:55 PM)TomC Wrote:  Tony:

Excellent Progress!!!

Cost and Delivery Time?

TomC

So far every time I get close to the end something happens, so all I can say is soon (I hope). The board seems to be functional. The printer seems a bit feint which I cannot account for, so might just be aged paper, but still checking

Due mainly to the large circuit board, the cost will be in the vicinity of $Aus140.00, a bit cheaper if the clock is not required. Like the other boards I'm not interested in making a profit, just enough to help a bit with further developments and keep the web site active as long as I can. The 97 has been a bit of a drain to get this far, so if I can get a little back to compensate great, if not, so be it :-)

On a side note, one thing I noticed on the original 65 and 67 as compared to the 97 is that HP routed high current devices like the card motor and display direct to the battery. In the 97, including the thirsty printer, they all go through the power switch and the interconnections between boards, which I thought would be a nasty sources of voltage drop. Time seems to have served them well though.

cheers

Tony

[teenix]

Hi all,

I think I have finished the 97S interface and there were only 2 commands used. Just like the original interface, it is up to the user to determine how the data is to be represented. As far as the 97S is concerned, it only expects up to 10 BCD digits of data to act on.


COMMAND SET
1: cmdReqStatus
2: cmdDigits

-----------------

1: cmdReqStatus
This command can be sent from the interface to the 97S to interrogate the Status Flags Register.

CMD Value: $F0
Returns: 1 Byte = Status Info

Status Bit Definitions:
7 FlagChg 1 = 97 Flags changed state
6 Reserved
5 Reserved
4 Ready 1 = Ready
3 Flag 3 1 = Set
2 Flag 2 1 = Set
1 Flag 1 1 = Set
0 Flag 0 1 = Set

The Ready Flag is cleared to 0 as per the states listed in the 97S manual.

If the 97 Microcode changes its internal flags (Flag 3 for example) or the user changes the flags by pressing something like [f] [STF] [0], the Status Register will be automatically sent to the interface with bit [7] set = 1. This tells the interface that a flags change occurred and if the interface has output pins for the flag states, then they can mirror the change.

-----------------

2: cmdDigits
This command should be sent from the interface to the 97S when ready to send digits.

CMD Value: $F1
Returns: 1 Byte
$F1 - Acknowledges command and the 97S is ready to receive up to 10 digits
- Any other value, means the 97S will not accept new digits

The 4 bit digit values are the same as listed in the 97S User Manual.

0
1
2
3
4
5
6
7
8
9
10 - DP
11 - EEX
12 - ENTER
13 - [A]
14 - Change Sign
15 - NOP

The digit data stream needs to be terminated by a NOP if < 10 digits are to be sent, otherwise the 97S will standby expecting more data and will timeout after a second or so.

Example:

Read a weight gauge -> 34.27Kg
Send digits
Then run program [A] to process the data and reset Flag F3

Send [cmdDigits] $F1
if $F1 returned, send digits...
1 3
2 4
3 10 (DP)
4 2
5 7
6 13 (A)
7 15 (NOP)

When the [A] program runs, as soon as Flag 3 is cleared, the Status Register will be sent to the interface with Bit7 = 1. The Ready flag will be clear because the program would have been running.

The incoming digits are stored in a buffer and when ready they will be transferred to the PIK key buffer one at a time whenever that buffer is empty. It is done this way because the PIK key buffer only holds 7 keys and it could overflow and ignore some of the incoming digits.

The digits can be entered in any order, but because the Run [A] digit will start a program running, all subsequent digits will be ignored because the Ready flag will have been cleared.

Errors are shown on the 97 display for buffer overrun and receive data timeouts.

cheers

Tony

[teenix]

Hi all,

Now that the 97S interface seems ok, I will move on to the last part which is the IR print interface.

I have written some code which looks ok on the oscilloscope, but until recently I had no way of testing it.

I have to say, the generosity of some Forum members that have helped with this project is quite humbling. The other day a package arrived at my door with some donated HP 82240A/B printers which will provide the means to complete this part of the project. TC a HUGE thanks.

The only problem I can foresee is the timing for the link. Looking at the old Journals, this seems to be critical. It appears that the calculator mentioned in the article was a HP-18C which has an inbuilt 32KHz crystal oscillator from which to base the timing. The IR print signal is also used by the printer firmware to adjust for small discrepancies with its less stable RC oscillator.

The 97 CPU board timing is based on an internal time base generated by the PIC. This is also relatively unstable as the frequency will drift a bit with temperature and supply voltage fluctuations. An external crystal could be used, but adds cost and there are no free OSC pins available. Hopefully the printer software can still sync itself to a slightly varying signal.

If the interface works, I might be able to add an IR printer link to the 65 and 67 boards. These will be a bit difficult because there was no printer to start with.

Edit:

The world wide semiconductor shortage has caught up to me now. The PIC CPU used in the 97 board is now not available until late 2022. Others that might be used as substitutes are also not available.
I only have a few on hand so I can only make up that many until new devices become available. This is also affecting the other CPU boards. :-(


cheers

Tony

[Paul Dale]

Marcus did wonders with the printing on the WP 34s. His code (in C) is available. I've a recollection that a crystal was needed to get the required stability.


Pauli

[teenix]

(11-21-2021 02:55 AM)Paul Dale Wrote:  Marcus did wonders with the printing on the WP 34s. His code (in C) is available. I've a recollection that a crystal was needed to get the required stability.


Pauli

Hi Pauli,

Thanks for that.

I was thinking of using a similar technique to what HP did in the printer. The clock chip used in the 97 board has a 5ppm output over a large temperature range, so I might be able to use that as a reference to create a time scale for the IR signal.

I'm not even sure it is needed. From what I read, the printer firmware continually adjusts itself from the incoming IR signal and tries to stay in sync. If the IR pulse width varies a bit, then the printer might be able to adjust itself to suit. It would depend on how far the signal can deviate before it cannot compensate.

cheers

Tony

[Paul Dale]

I'm pretty sure Marcus tried the non-crystal oscillator.

Marcus, any recollections here?

My memories are dim at best and this was tangential to what I was doing for the project.


Pauli

[teenix]

Hi All,

I had some trouble with the IR print link and none of my efforts would get it to work. I then rewrote the IR code to a more simpler version although it does have a very small amount of bit jitter in the data stream, but this didn't work either. I opened the printer and looked at the output from the IR conditioning IC and the data was being received ok, so the IR LED link was working.

I was reading the printer manual again, and "Derrrr" each print line needs a Line Feed at the end or the data just stays in the print buffer. I added that to the print character string and Woolah!! the IR printer interface now seems to work.

The small amount of jitter doesn't appear to worry the printer.

Woo Hoo (Go away Murphy)

I got out a hair dryer to heat up the 97 CPU board and see if the link fails due to timing changes, but it still printed ok when the board was hot. Perhaps as I mentioned earlier, the corrections applied in the printer firmware create a bit of error margin.

Now the fun part, and maybe the last thing to do, diverting the original 97 print data to the IR link. This I hope won't be too hard, but the 97 print data comes in spurts for each line due to the way the HP Microcode sends the data to the PIK chip, so will see. The difficult part is that the print lines cannot be sent as ASCII codes but will have to be output in graphical format because the IR printer does not support all of the 97 PIK character set.

The IR led is only 3mm round, so if one wants to drill a small hole in the rear bottom of the case, there is a small flat vertical area just below the metal locking tab and is where the 97S cable to the interface would have been.

cheers

Tony

[Paul Dale]

Great work once again!

The 34S had to switch to graphic mode quite a bit.

As for sending lumps of data, that should be fine. The printer does some buffering.


Pauli