HP97 The journey begins

[teenix]

Hi all,

One of those nights where your brain is not really sleeping, but mulling over a niggly problem that you should have seen already.

I should have looked a bit deeper into how the PIK chip detects an Out Of Paper (OOP) situation. It is not as simple as the home switch setup, even though both methods just ground a switch terminal.

The OOP switch shorts the base of transistor Q11 to ground forcing it to turn off and thus stops the motor moving forward. This ground is also connected to the PIK chip FWD drive output pin.

Still more complicated, in that this OOP setup is bypassed when the Paper Advance button is pressed so that the motor can work to restore a new paper roll.

There must be some trickery inside the chip to be able to drive the motor transistor but not be affected by the direct short to ground - maybe just a resistive setup.

The test for the OOP condition is a PIK1220 instruction. This can execute from ROM both when the printer is idle and when it is printing. While printing however, the FWD pin has a Pulse Width Modulated signal coming out to control the motor speed. There must be some other trickery to detect the OOP condition when this is happening also.

A couple of other things are happening too with the printer which I thought were controlled by the ROM code, but is not the case.

More thinking required....??

cheers

Tony

[teenix]

Hi all,

I've been delayed due to work but have managed to put together the power supply, charger input and over volt circuits. So far so good.

I was hoping to make a solderless changeover, but I don't think it is possible. I cannot find replacement PCB pins for the wiring connectors to the print advance switch and battery. These are easy to remove from the failed board and re-solder to the new board. The battery charge connector is not available any more either, but is easy to swap over.

I obviously cannot replace the 21 connectors between the CPU board and the printer board, so these will have to be changed over also. These may be able to be replaced with home made pins and am looking into it now - but very fiddly though.

I have only managed to find a 13 way instead of 12 way connector to the card reader ribbon cable. 2.54mm connector spacing seems to be old technology now with FFC cables. The new PCB can accommodate this anyway.

If someone wants a replacement CPU board and cannot solder, I am happy to change the parts over if the old board is sent to me, and I will send both boards back.

I am waiting on the PIC controller chips as they have not been available until now and once delivered I should be able to finish populating the board.

cheers

Tony

[BobVA]

Fantastic news! Thanks for the update!

[teenix]

Hi all,

I've just created a new version of the HP-67 replacement CPU board and this one has Constant Memory. This change in hardware should also suit the HP-97 CPU board.

The main problem with adding this feature was that due to the original 67 hardware design, a wire would have to be added to connect the CPU board to the battery so the memory can stay alive. Unfortunately, this method means the PIC processor also has to stay "alive", although in sleep mode. Even so, some current from the battery would always be drawn. The wire connection also interferes with board removal, although a connector could be used. I didn't really want to solder a wire to the keys circuit board either.

To avoid those issues, the new CPU board can keep its memory alive indefinitely without a battery. I just have a bit more testing to do to make sure the HP microcode can work with it under all working conditions, but so far it seems ok.

cheers

Tony

[Paul Dale]

FRAM? EEPROM?


Pauli

[teenix]

(05-27-2021 08:30 AM)Paul Dale Wrote:  FRAM? EEPROM?
Pauli

It is a busy environment, EEPROM is too slow for the job :-)

cheers

Tony

[teenix]

Hi all,

Having a bit of fun ironing out a few quirks with the Constant Memory 67 CPU board, but it seems fine at the moment. To minimize manual handling of the 67 while testing, it has an external power supply, and I gave it a remote keyboard which operates from PC mouse clicks. It also has an isolated serial interface which means the 67 can be powered up or down with no chance of unwanted external voltages appearing on the circuitry and also allows re-programming. The re-programming cycles can be repetitious during testing so only changes in code are actually reprogrammed instead of the whole chip. All this was a bit fiddly setting up, but in use it saves a lot of time.

I tried a read/write from a card and from internal storage and all good. Turn the power off, turn it back on and all data is still there. I loaded and ran the HP-67 diagnostic cards and it all worked ok. Turn the power off then on and press [A] and it works again.

[f] [P<>S] works as expected even after a power cycle, so I think all memory actions are working. The display also shows the last contents of the C register, and the display is formatted the same as prior to power down.

The 67 Microcode is still original and the new PIC code is still compatible with the earlier CPU board. The Constant Memory will be detected automatically and can be switched on, off or reset as desired from the internal menu system.

Still a few more tests to go, but encouraging :-)

cheers

Tony

[Massimo Gnerucci]

Tony, this is simply astonishing!

Ready to order...

[aurelio]

Hi Tony, good news, time ago when I asked about the possibility to do something to avoid hand-compiling all the lines of a complex program on a real 67, using a connection with PC, I was told to build a robot that would do it for my , I'm so lazy I thought of myself ....
but now, maybe with your project soon the dream could become true. Men at first started by flying in the space, then they landed on the moon

[Harald]

This is really impressive Tony!!!!

[teenix]

Hi all,

While fiddling with the Continuous Memory for the 67, I thought I would try and implement more memory as well. This is not an easy task if you delve into the Microcode, as all sorts of problems and gremlins come into play, so (for me) the best way is to leave that code as is.

I was experimenting with this idea using the 67 emulator as a guide, and I noticed that there appears to be 3 RAM registers that are not used by the 67 - addresses 58, 59 and 60 in the last RAM bank. They never seem to be written to no matter what function is used by the 67. I imagine that all ROM/RAM chips are basically the same except for the ROM code in each of them. Maybe there was not enough ROM available to make use of these registers.

Anyway, using the emulator and without modifying the original Microcode, I found that I could expand the RAM 4 fold, increasing the storage from 26 to 104 registers.

The trick is that this RAM is not contiguous and sort of mimics the way the P<>S key works. That is, you only have access to a selected bank.

There are some unused programming codes available, so I used one to create a new code which is the [h] key followed by the [E] key. This is a "RAM Swap" instruction. It can be used in RUN mode, entered into a program, and executed during a running program. It can also be stored and read from magnetic cards.

To select one of the 4 banks, you key in 0, 1, 2 or 3 so that this value is in the C register, and then press [h][E] and the bank swap takes place. The actual 67 memory still works exactly the same, so you still have STO n, RCL n, P<>S, WDATA, (i), etc.

The downside is that you have to manage the RAM usage.

This should easily work in the new 67 CPU board but only when Continuous Memory is selected. Unfortunately, the original CPU board does not have enough RAM to implement this.

The next stage is using the available resources to bank swap the Program Memory, giving 896 steps but there are a different set of gremlins involved, one of which is you cannot bank swap during a subroutine :-)

cheers

Tony

[Paul Dale]

Would a merge from RAM be more useful?
Or some kind of PC reset when bank switching.

Pauli

[teenix]

(05-30-2021 05:58 AM)Paul Dale Wrote:  Would a merge from RAM be more useful?
Or some kind of PC reset when bank switching.

Pauli

You can still merge programs and data as normal. The 67 runs business as usual, it isn't aware of the extra memory, only the user, so all the original operational rules still apply. With the extra memory though, you might not have to merge.

I guess you could do a return from a subroutine in a different PGM bank but execution would continue from the calling address + 1 in the new PGM bank. Might be useful if you keep track of what you are doing though.

Bank switching program memory will have a mechanism to jump to any label or continue from the current PC address in the new bank.

cheers

Tony

[Paul Dale]

(05-30-2021 07:04 AM)teenix Wrote:  Bank switching program memory will have a mechanism to jump to any label or continue from the current PC address in the new bank.

This is sufficient. The idea behind the merge suggestion was to allow control over where execution continues. Being able to branch to a label in the new program is better.

Pauli

[teenix]

Hi all,

We've been put into Covid lockdown again for awhile so I thought I'd use the downtime to keep playing.

So far with the emulator, I've implemented the 67 Continuous Memory and RAM swapping, which increased the storage register count to 104. To make it a bit more flexible, I added the ability to do a simple STO and RCL to/from any register in any bank. Normal STO and RCL still works within a single bank.

Due to the complexity of the 67 Microcode, (which I am loathe to change), other 67 functions like STO+, RCL(i) etc are still standard and can only be used within a single bank.

The 67 Microcode is still running as original, but accessing a bank function requires a stack lift as the info for the access comes from data entered into the X register. However, after the bank access executes, the calculator will be in a state where a new number entry will not lift the stack, as for example, if you just pressed CLx. This way, the access data in the X register will be overwritten. It should be possible to use DZ(i) etc, and the I register to bank swap and do STO or RCL to different banks also, as long as the I register is loaded into X.

I'll try to implement memory banking for the PRGM memory next, then port it all to the newer 67 CPU board.

cheers

Tony

[teenix]

Hi all,

I uploaded the emulator at teenix.org and the 67 now supports the extended Continuous memory.

The 67 is still running original Microcode, but you can swap RAM and PGM banks individually, STO RCL to and from different RAM banks, and jump to any label in any PGM bank. You can execute the mods either in Run mode normally or when a program is running. In W/PRGM mode, the key codes are stored in normal HP-67 memory and can be used with the emulator cards with no modification.

On power up, all memory is retained as well as the X register, display formatting and selected deg/rad/grd setting.

It may have a bug that I missed, but time will tell.

Here is a code example to jump to LBL E in PGM Bank 3 and from there load register R0 from RAM Bank 2 into X. First, data is loaded in X and the key sequence [h][E] executes the command. The key sequence [h][E] is stored as 1 program step.

7 ; swap to PGM bank 3
4 ; jump to LBL E
h
E ; execute


PGM Bank 3

LBL E
9 ; RCL
2 ; from RAM bank 2
0 ; Register R0
h
E ; Execute

These type of key sequences can be keyed in directly as well.

This idea should port to the 67 and 97 CPU boards reasonably easy by using the emulator as a template, which I'll start soon. It looks like Covid shutdown is being extended another week so at least I have some idle time.

The 97 CPU replacement board has had a set back as the PCB design had an unknown design flaw and some components did not line up properly and had to be scrapped. This turned out to be a rather expensive mistake :-(

cheers

Tony

[teenix]

Hi all,

I was having one of the sleepless nights where you lie there thinking of the most unlikely things.

I am no mechanical wizard and I was wondering how the eccentric cam works on the card reader drive roller shaft to set the 180mA motor current.

The shaft is inserted into two fixed holes on the card reader frame assembly. If the shaft is offset with respect to the larger end piece with the screw slot, wouldn't turning it do nothing for shaft eccentricity? I would have thought in this situation the larger end piece would experience the offset while turning.

I cannot see any offsets on the shaft itself, but if it did it would suggest that the shaft is oval shaped but that doesn't make sense for the drive roller.

It is definitely not bent to give an offset, so my mechanical aptitude has failed me :-)

cheers

Tony

[teenix]

Hi all,

I'm still toying around with the 97 PIK chip but it still manages to offer some confusion while trying to figure out the intricacies of the print head speed control.

It is a fairly simple set up, a varying PWM signal drives the motor forward. During each time the PWM signal is turned off, the motor still spins due to inertia and briefly turns into a generator. The voltage created is sampled by a comparator and the output signal changes depending on how fast the motor is spinning. This signal is fed to the PIK which (I assume) uses the width of this signal to determine the mark to space ratio of the PWM and thus keep the speed relatively constant as the printer prints a line. As far as I can tell that's all there is to it.

What I cannot seem to understand is how the PIK varies the mark space ratio from the comparator output.

The image below shows the PWM drive to the motor transistors (top line), followed by the output from the comparator (2nd line) and finally the motor voltage appearing at the comparator input. It the motor voltage exceeds 1 volt, the comparator switches high, otherwise is low. Thus the faster the motor spins, the narrower the output pulse will be from the comparator and this tells the PIK to slow the motor down. Sounds feasible.

You can see the motor voltage mirroring the drive signal as it goes HI and LO. The motor voltage drops sharply at switch off but rises (slowly) due to the generator effect. Once this voltage goes higher than 1 volt, the comparator output switches HI, otherwise LO.

What is hard to sort out is how the PIK figures out how to vary the motor PWM signal. It does vary, but it is hard to see what is causing the change. On the second line, you can see a glitch which seems to trigger the motor drive to switch on. This pulse is only about 1-2uS wide and it does not always change the state of the motor drive so is a bit mysterious. You can see the top line PWM vary but not much from line 2 to suggest why.

My feeble brain must be low on sugar, or perhaps beer, but I cannot see anything logical in the waveforms.





cheers

Tony

[PANAMATIK]

(06-13-2021 07:31 AM)teenix Wrote:  I'm still toying around with the 97 PIK chip but it still manages to offer some confusion while trying to figure out the intricacies of the print head speed control.

I didn't even try to find out/imitate the exact same speed regulation inside the original PIK chip. There could be a hidden PI regulation involved, which is normally used for speed control. I remember that I used the HCTL1100 chip from HP for motor control in the 80s, HP offered sophisticated motor regulation chips.

Therefore my approach is different and very simple. I sample the Feedback VM signal as often as possible asynchronously to the PWM cycle, and build the mean value. Then it is easy to drive the motor faster when the mean value is too low, and slower if the mean value is too high. It gives quite a fair result as you can see in this video Motor Video (16s 5.5MB)

Bernhard

[teenix]

Thanks Bernhard,

Food for thought.

cheers

Tony