HP67 running

[teenix]

Hi all,

I managed to get the HP-67 emulator and compiler working. The CRC interacts with the PC ok and will read/write the data using the hard disk instead a card.

I stumbled around for awhile and couldn't get it all to work, but found the instruction [data register -> c 0] was the culprit. I expected it to behave like the other [c 1] to [c 15] codes but not so.

I thought it was a problem in the code listing as I have found errors in the published listings for other models. For example, the HP-55 could not access the RAM banks properly and the HP-65 code went into a huge delay loop when the R/S key was pressed. After many late nights, I found and fixed those problems, but the 67 code seems ok.

In the 67, there is a code loop activated from the [f] [P<->S] key sequence that has the [data register -> c 0] instruction used in quick succession while swapping the RAM banks. It was here that I concluded the [c 0] instruction is unique in that it doesn't appear to set the lower 4 bits of the RAM address latches like the others do.

Instead, it uses the complete 6 bit address that happens to be in the address latches at the time. So if those latches contain 101111 (Bank 2) (Addr 15), [data register -> c 0] loads C from that RAM address, not (Bank 2) (Address 0) as you logically might expect.

To access RAM 0 in any bank using this instruction means the lower 4 bits in the latches must have been set to [0000] previously.

Sorry if this has been hashed out before, but I haven't seen a reference to it, and of course, apologies if I am wrong.


Adding the 67 to the hardware calculator is going to take some time because I need a different model PIC to emulate it due to the extra ROM/RAM needed. The one I chose is cheap and pin compatible but has different internal architecture and I will have to rewrite the original assembler before adding the 67 code. My old PIC programmer that I created 10 years ago sadly will need a code tweak as well.

If anyone is interested it will be available to download at teenix.org when complete.

cheers

Tony

[PANAMATIK]

(05-27-2016 03:10 AM)teenix Wrote:  I stumbled around for awhile and couldn't get it all to work, but found the instruction [data register -> c 0] was the culprit. I expected it to behave like the other [c 1] to [c 15] codes but not so. .....

Hi Tony,

I can follow your joy of exploring the HP-67 code and finding the right solutions by analyzing the code very well, because I made very similar explorations. However the behavior of the [data register to c] instruction is well known since Eric Smith made the first HP emulator "nonpareil". He named the instruction register_to_c() 0 data_to_c(). You can download the source code of his emulator from http://nonpareil.brouhaha.com/.

My implementation of the register_to_c() instruction is very simple to read and is functionally identical to nonpareil.

Code:


void op_register_to_c ()
{
    if (opcode>>6) // opcode for register 1-15 ?
    {
        ram_addr &= 0xFFF0;
        ram_addr += (opcode >> 6);
    }
    register_to_c(ram_addr); // copy register from ram[ram_addr] to c
}

I'm impressed that your emulation also handles the card reader/writer. My ACT hardware is not capable to do so. Does it save and read the exact same magnetic card data format on disk?

Bernhard

[teenix]

Hi Bernhard,

Thanks for the link. I was aware of some of the people that laid a lot of the ground work for opening up these calculators and I certainly do find their efforts impressive. Because of limited resources I have had to rely on some of those efforts at times for my own emulator and am grateful for their hard work, although I have tried as much as possible to be my own detective otherwise the journey of discovery is quite bland.

The read/write was simpler to create than I thought it was going to be as the calculator code does all the hard work, although as usual there was a quirk. All you need to do is make the program data available or be ready to receive it when required.

Basically...

each cardArray element = array [0..13] of Integer

[Write - to card]
CRC 260 - motor on
index = 0

CRC 1700
if write
cardArray[index] = crc_Reg_$90
inc index

CRC 360 - motor off
if write...
save cardArray to disk


[Read - from card]
Load program file into cardArray
index = 7 // why this is so escapes me ???

CRC 1700
if read
Place cardArray[index] into crc_Reg_$99
inc index

CRC 360 - motor off
if read...
nothing to do

Data files, merge etc work exactly the same

The only thing I can't explain is that on a [read] the first 7 data elements which are supposed to be zero's cause a problem with the calculator firmware and the read fails. If I set the array index to 7, bypassing these bytes, it all works.


I got a bit carried away as I found a sound recording of a real card reader and activates on CRC 260 (motor on) - although there is a menu item to leave it off.

cheers

Tony

[teenix]

Hi all,

Thinking about the problem mentioned in the previous post, I've been going through the 67's card reader code trace from the simulator.

Data blocks on the cards consist of 7 bytes and 38 of these blocks are written to each card side. This was what the emulator expected the calculator code was going to want in its entirety, but this was not the case.

After a card has been detected by the calculator, the key wait loop exits, Read Mode is set and then the code makes its first CRC 1700 call 'before' turning on the card motor. This I assume, does some initialization before card reading actually starts. If a read error occurs during this process, S[3] is ignored because it is not tested for in this section of code.

As the card begins its journey through the card reader, there are 0's appearing in the first 3 blocks (bytes 0 - 20) of the card header and I am thinking these are used for syncing purposes inside the card reader chip. The first non zero value will be the first byte for the [PrevStatus] data block - (byte 21). It is here where I think valid data is assumed to start and 7 bytes of zero will be sitting in buffer ($9B) ready to be read.

The code then executes the 2nd CRC 1700 and this block of zeros is fetched from the card reader and makes room for the incoming block. The 3rd CRC 1700 then reads the [PrevStatus] block, then 32 blocks of program data and finally, 2 blocks for the checksum.

What this means is that the fist 2 blocks of data are ignored by the calculator, which is what my code failed to take into account.


cheers

Tony

[PANAMATIK]

(05-29-2016 05:17 AM)teenix Wrote:  Thinking about the problem mentioned in the previous post, I've been going through the 67's card reader code trace from the simulator......

Hi Tony,

It's wonderful to see you analyzing the HP-67 code. I'd liked to have the time today for a look at the code and more comments.

I liked also to have the newACT for HP-67 reading/writing cards. The problem for the chosen PIC processor is, it doesn't have a buffered SPI input (not mentioned in the data sheet!), this makes reading the DATA line in real time extremely difficult or impossible. I hope your hardware doesn't have this problem.

Bernhard

[teenix]

Hi Bernhard,

I looked at your HP-01 pics (excuse the pun) posted the other day and the PIC there is the same model as I chose to upgrade the calculator to host the 67 emulation - (16F1519).

I rewrote my PIC programmer code the other day code and it now handles this chip. I also rewrote the emulator code for it and it seems to simulate ok but haven't tested in the actual chip yet.

My setup has a bit banged I2C link to the memory card. When instructed, the code read/writes the chosen memory block in less time than the finger comes off the button but I purposely delayed it to blank the display briefly for user feedback.

This is a fairly easy approach and works for the 65 reader. I will incorporate the 67 CRC code once I know I have the new chip under control, but it still won't have to scan a real card.

I wouldn't expect a PIC to have much trouble bit banging the serial data in on any input pin unless logic level conversion is required which would require an external buffer. I've written a few duplex RS-232 applications at 19200 baud using this approach. An edge detect interrupt could be used to frame incoming data bits and shift them into a buffer easily enough.


cheers

Tony

[PANAMATIK]

(05-29-2016 10:37 AM)teenix Wrote:  I wouldn't expect a PIC to have much trouble bit banging the serial data in on any input pin unless logic level conversion is required which would require an external buffer. I've written a few duplex RS-232 applications at 19200 baud using this approach. An edge detect interrupt could be used to frame incoming data bits and shift them into a buffer easily enough.

As always the devil is in the details, i.e.DATA line from CRC must be read with 180000 baud, and the line must be bidirectional. But I admit, that I not yet tried everything what bits can do with a PIC. And only recently I found the key for communicating from PIC to PIK (excuse the pun).

My question is, how many HP-67s need a new ACT for repair. And would their owners also repair the card reader if the ACT would be able to read/write cards?

Bernhard

[teenix]

...As always the devil is in the details, i.e.DATA line from CRC must be read with 180000 baud

I'm a bit confused at the transfer speed here unless I am missing something - which wouldn't surprise me :-)

I'm not sure how the read transfer is triggered from the CRC, but only CRC 100 and CRC 1700 are utilised for reading. It looks like CRC 100 is used to test the ready state of the buffer, and if not ready the CRC flag line = 1. I guess the flag line sets S3 directly in the Status Register. The CRC 100 commands are in a small count down loop that executes while S3 stays = 1. If the buffer is not ready when this counter wraps around an error condition occurs. When the buffer is ready to transfer, CRC 100 sets the CRC flag line = 0, clearing S3 and breaks out of the loop. Then CRC 1700 soon follows and seems to transfer the buffer data to register $9B or sets S3 = 1 if an error occurs.

I believe the data stream to/from the cards is about 1KHz with 28 bits of information made available for each transfer. It would therefore take about 28mS for the CRC to shift these into one of its buffers ready to go and this provides a time slot of 28mS for the PIC to read them while the next buffer fills.

A PIC running at say 16MHz would be able to execute 4000 instructions per bit. Even allowing 5% of the available processor time would give 200 instructions to process each bit. Shifting the new bit into a 56 bit memory register would take a minimum of 10 instructions which would take about 0.4uS, (1/70th of 1 bit time).

As the PIC would be controlling the Sync line, which I think clocks the CRC chip, transferring the data or issuing CRC commands and polling would just be part of its main loop.

The only polling required may be just the CRC flag line.

cheers

Tony

[teenix]

I think I've been paddling in deep water. I assume the 180K baud is due to the system clock speed. If so, I see the problem now.

cheers

Tony

[PANAMATIK]

(05-31-2016 10:33 AM)teenix Wrote:  I believe the data stream to/from the cards is about 1KHz with 28 bits of information made available for each transfer. It would therefore take about 28mS for the CRC to shift these into one of its buffers ready to go and this provides a time slot of 28mS for the PIC to read them while the next buffer fills.

Hi Tony,

As you already stated in your next post, the timing is indeed 180kHz, because the card buffer must be read as 56-bit RAM register mapped at $9B from the real CRC chip, and reading RAM must be done serially via the DATA line with 180kHz directly after a data -> c instruction. this is the critical part for the newACT, because its dedicated serial inputs are already used for reading the next instruction at the same time, so I had to map the DATA line to a normal input pin.

But discussion is always very helpful and the more I defend my point of the difficulty of the task, the more I am wrong and see possibilities to get it working though, if I had the next time slot for more experiments.

Bernhard

[Harald]

Hi Tony,

After my holiday I now have acces to a windows computer again and downloaded your emulator. Very impressive! And thanks a lot for making it publically available!

Cheers,
Harald

[teenix]

Hi Harald,

Sorry for delay I am working in a remote area for a few weeks.

Thanks for the comments, they make the effort worthwhile.

The new 67 emulator is running ok. The hardware calculator is getting some final testing done in 67 mode and it had some minor PCB mods. I have also added some more functions for the simulator.

I'll post everything for downloading when I get home.

cheers

Tony