Threaded Mode | Linear Mode

lcwright1964 · (This post was last modified: 08-06-2015 12:26 AM by lcwright1964.)

Greetings all,

I am wondering if there is any way to "compile" text listings of keystrokes to listings in the appropriate format for the *.pck files used by Olivier de Smet's Android (and Windows) emulators of the HP67 and HP97.

I am interested even in a key that translates program steps to and from what looks to be the hexadecimal listings in the *.pck file.

For those interested in my queries about syntax, compiling, and decompiling, her is the link to the .pck file for the HP67 Standard Pac. It is a simple text file:

https://sites.google.com/site/olivier2sm...ects=0&d=1

Thanks in advance for any wisdom. I am very interested in programming for the HP67/97 emulators on the computer, just as I have done for ages with HP41 and HP42 programs.

Les

Bill (Smithville NJ) · 08-06-2015, 01:45 AM

(08-06-2015 12:23 AM)lcwright1964 Wrote: I am wondering if there is any way to "compile" text listings of keystrokes to listings in the appropriate format for the *.pck files used by Olivier de Smet's Android (and Windows) emulators of the HP67 and HP97.

I am interested even in a key that translates program steps to and from what looks to be the hexadecimal listings in the *.pck file.

Hi Les,

Some time ago, I played around with trying to create an translator that would take a text file and then convert it to a PCK file. I also thought about creating a reverse translation.

Unfortunately, I can't find my work I did on it. I may have lost it when my computer failed and I bought a new machine. I think I played around with PCK files for the GO65. I found one email where I discussed this with Olivier.

I had asked him:

Quote:I have a question about the format you're using for the Card Packs. I see from you notes that it's 103 words, 6 bits octal. But I'm having trouble relating the text file data to the actual key codes. Is there a translation going on?

And he replied:

Quote:All you need is a copy of PPC journal volume 2 number 1

There is a table of the Octal codes for the HP-65 at the top of Page 11.

I never found a table of codes for the HP-67. I seem to remember that I created a HP-67 program that used all the key strokes, wrote the program to a PCK file, and then looked at the PCK file in an attempt to create the code table.

Like I said, I seem to have lost all the work I did on this. I didn't even get close to a finished program.

Not sure if any of this is a help. Maybe I'll take another look at it if I get some free time.

Bill
Smithville, NJ

lcwright1964 · 08-06-2015, 01:53 AM

Thanks! I will look for that PPC journal on the Museum DVD. The idea of writing a program to provide a key seems tedious at first though ultimately helpful.

Jake Schwartz · 08-06-2015, 07:14 PM

(08-06-2015 01:45 AM)Bill (Smithville NJ) Wrote: There is a table of the Octal codes for the HP-65 at the top of Page 11.

I never found a table of codes for the HP-67. I seem to remember that I created a HP-67 program that used all the key strokes, wrote the program to a PCK file, and then looked at the PCK file in an attempt to create the code table.

Bill
Smithville, NJ

I'm not sure whether this is what your are looking for, but Louis Cargile's famous article "Zen and the Art of HP-67 Maintenance" in PPC Journal/65 Notes V4N5 starting on page 4 has a table on page 6 called "HP-67 Internal Codes"; plus a followup in V5N6 page 15-16 titled "More HP-67 Codes" sorts the same list as a keycode-versus-hex-code table.

Jake

lcwright1964 · 08-06-2015, 07:36 PM

Jake, thank you! I have discovered that the PPC Journal is not part of the MoHPC CD/DVD/flash drive collection, but there are scans over at TOS so I should go take a gander...

Thank you!

Les

**rprosperi** · 08-07-2015, 02:26 AM

(08-06-2015 07:36 PM)lcwright1964 Wrote: Jake, thank you! I have discovered that the PPC Journal is not part of the MoHPC CD/DVD/flash drive collection, but there are scans over at TOS so I should go take a gander...

ALL issues of PPC plus MUCH more is available on a DVD Jake sells available here.

Like the MoHPC USB drive, this resource is a must-have collection of almost all of the club publications from all the major Calculator clubs. PPC, CHHU, HPX, HPCC, plus dozens of other resources of interest. Check it out ASAP!

Bill (Smithville NJ) · 08-08-2015, 06:51 PM

I've spent a little time reviewing the layout of the PCK file and think I have it all figured out with the exception of the "Header Record" - the first record of the data stream. From reading the HP-67 manual and a HP Digest article, I see that the 28 bit record stores the data on whether it's one or two sided, data or program, status of Flags, status of Trig Mode, display format, etc. But I haven't found any reference to how the bits are stored and what each bit means.

And the Emulator may also be storing some data in this header.

Does anyone knows the format of the Header Record that is stored on a Card?

With that info, I could then create a program to read the PCK file to generate a text file program listing, and vise versa.

Appreciate the help.

Thanks,

Bill
Smithville, NJ

lcwright1964 · 08-08-2015, 07:02 PM

(08-08-2015 06:51 PM)Bill (Smithville NJ) Wrote: I've spent a little time reviewing the layout of the PCK file and think I have it all figured out with the exception of the "Header Record" - the first record of the data stream. From reading the HP-67 manual and a HP Digest article, I see that the 28 bit record stores the data on whether it's one or two sided, data or program, status of Flags, status of Trig Mode, display format, etc. But I haven't found any reference to how the bits are stored and what each bit means.

And the Emulator may also be storing some data in this header.

Does anyone knows the format of the Header Record that is stored on a Card?

With that info, I could then create a program to read the PCK file to generate a text file program listing, and vise versa.

As I just suggested to you in our emails, I am learning that a program that not only translates the program steps to hex code but also generates the correct checksum is necessary. I tried to fiddle with Olivier's provided .pck files myself, or with my own generated files of very simple programs, and found quickly that if I edit the hex code directly, translating manually according to the key in the PPC journal, trying to use the revised card in the emulator throws an error--presumably because the old checksum doesn't match my changes.

As I admitted to you, I probably don't really understand the basics of a checksum in this context...

Les

Bill (Smithville NJ) · 08-08-2015, 09:40 PM

(08-08-2015 07:02 PM)lcwright1964 Wrote: As I just suggested to you in our emails, I am learning that a program that not only translates the program steps to hex code but also generates the correct checksum is necessary. I tried to fiddle with Olivier's provided .pck files myself, or with my own generated files of very simple programs, and found quickly that if I edit the hex code directly, translating manually according to the key in the PPC journal, trying to use the revised card in the emulator throws an error--presumably because the old checksum doesn't match my changes.

As I admitted to you, I probably don't really understand the basics of a checksum in this context...

Les

Hi Les,

The Checksum in this case is pretty simple. Sum up the first 33 records (Header plus 32 data records) and then MOD with 10000000H. That will give the Checksum Record. I have sent you an Excel spreadsheet showing the checksum calculation for the first few cards in the Standard Pack.

We now just need to get the Header Record decoded.

Bill
Smithville, NJ

lcwright1964 · 08-09-2015, 02:04 AM

(08-08-2015 09:40 PM)Bill (Smithville NJ) Wrote:
(08-08-2015 07:02 PM)lcwright1964 Wrote: As I just suggested to you in our emails, I am learning that a program that not only translates the program steps to hex code but also generates the correct checksum is necessary. I tried to fiddle with Olivier's provided .pck files myself, or with my own generated files of very simple programs, and found quickly that if I edit the hex code directly, translating manually according to the key in the PPC journal, trying to use the revised card in the emulator throws an error--presumably because the old checksum doesn't match my changes.

As I admitted to you, I probably don't really understand the basics of a checksum in this context...

Les

Hi Les,

The Checksum in this case is pretty simple. Sum up the first 33 records (Header plus 32 data records) and then MOD with 10000000H. That will give the Checksum Record. I have sent you an Excel spreadsheet showing the checksum calculation for the first few cards in the Standard Pack.

We now just need to get the Header Record decoded.

I am so glad my query inspired you to reactivate this old project. I wish that Olivier would chime in. I have emailed him through Google Play but get no reply, and other commenters there have mentioned that he hasn't been replying to bug reports (e.g., go71b crashes under the new Android OS, though it works gorgeously under previous ones).

I mentioned also in email to you there must be something coded in the pck files to specify whether a "card" is protected, and whether it is white with black font (user blanks) or brown with gold and white font (factory manufactured software). That is a lot of info to pack into that header line, esp. if we must also account for display setting, deg/rad/grad, and flags...

Les

PANAMATIK · 08-09-2015, 08:43 AM

(08-09-2015 02:04 AM)lcwright1964 Wrote: I mentioned also in email to you there must be something coded in the pck files to specify whether a "card" is protected, and whether it is white with black font (user blanks) or brown with gold and white font (factory manufactured software). That is a lot of info to pack into that header line, esp. if we must also account for display setting, deg/rad/grad, and flags...

Les

According to the HP-67 manual the information in the header contains:

Quote:Besides the actual program memory step numbers and instructions,
the HP-67 also records the following information on a program card
on both the first pass and the second pass through the card reader:
1. The fact that a program (not data) is being recorded.
2. The fact that this is side 1 (or side 2).
3. Whether or not two passes are required.
4. Current status of flags FO, Fl, F2, and F3 within the calculator.
5. Current status of trigonometric mode (i.e., DEG, RAD, or
GRD) within the calculator.
6. Current display format of the calculator.
7. A checksum (a code to verify that the program is complete
when it is reloaded).

It should be possible to find the structure of the header by generating pck files with different settings.

I don't have the Go67 emulator, so I cannot test it.

Following the 7 digit header in line 0, 112 program steps are coded in lines 1-32
Every two lines represents a 7 byte register for 7 program steps. The 7 program steps are coded in reverse order in the two lines. The first program step is coded the last two digits in the second line.

For comparing the codes you can download the HP-67 table of program step codes

http://www.panamatik.de/ProgramCodes.pdf

Bernhard

lcwright1964 · 08-09-2015, 09:40 AM

(08-09-2015 08:43 AM)PANAMATIK Wrote: It should be possible to find the structure of the header by generating pck files with different settings.

I don't have the Go67 emulator, so I cannot test it.

Following the 7 digit header in line 0, 112 program steps are coded in lines 1-32
Every two lines represents a 7 byte register for 7 program steps. The 7 program steps are coded in reverse order in the two lines. The first program step is coded the last two digits in the second line.

For comparing the codes you can download the HP-67 table of program step codes

http://www.panamatik.de/ProgramCodes.pdf

Bernhard

Thank you so very much for all of that. Yes, I suspect Bill will attempt to decode header info in such an incremental way.

The bee in my bonnet remains about where in the .pck files card font/colour and protection status is encoded. Those features are specific to the emulators. In the really calculator and cards, colour is immaterial and protection is conferred by snipping the corner.

Les

lcwright1964 · (This post was last modified: 08-09-2015 10:32 AM by lcwright1964.)

(08-09-2015 09:40 AM)lcwright1964 Wrote: The bee in my bonnet remains about where in the .pck files card font/colour and protection status is encoded. Those features are specific to the emulators. In the really calculator and cards, colour is immaterial and protection is conferred by snipping the corner.

Solved!

Protected status is conferred by a P in the line just before the header line for a card side. "S1 -" means side one is NOT protected. "S2P-" means side 2 is protected.

Card colour and font is also tagged simply. Beneath the first line labelling an individual card that reads "@ Card 0" for the first card, "@ Card 1" for the second, etc., there is a line with a single digit. If the digit is 1, the card is white with black font. If the digit is 2, the card is brown with white and yellow font. This is set using the "Kind" property in the Windows emulator, on which I am testing this. I am assuming these PCK files are perfectly compatible with the phone and tablet emulators.

I should emphasize that in Olivier's Google Code pages for this work, he is very specific that lines and spaces must be respected in these ASCII files, so when edits are made nothing should be subtracted, only substituted. Given the plethora of white space in these files, I thought it important to note that.

Les

Bill (Smithville NJ) · (This post was last modified: 08-09-2015 02:37 PM by Bill (Smithville NJ).)

(08-09-2015 10:20 AM)lcwright1964 Wrote: Solved!

Protected status is conferred by a P in the line just before the header line for a card side. "S1 -" means side one is NOT protected. "S2P-" means side 2 is protected.

Card colour and font is also tagged simply. Beneath the first line labelling an individual card that reads "@ Card 0" for the first card, "@ Card 1" for the second, etc., there is a line with a single digit. If the digit is 1, the card is white with black font. If the digit is 2, the card is brown with white and yellow font. This is set using the "Kind" property in the Windows emulator, on which I am testing this. I am assuming these PCK files are perfectly compatible with the phone and tablet emulators.

Fantastic!

This should mean that the Header Record is just how the HP-67 would store it without any other emulator data. That should make it somewhat easier to decode (I hope).

After thinking about this, a well written program should be setting most of the items in the Header Record when it executes. For example DEG/RAD/GRAD, Display Format, Flags. If we ignore them in the Header, then all we really need to worry about is Card Side (1 or 2), number of passes (1 or 2). Should be able to decode those items by playing around with various bits in the Header.

Bill
Smithville, NJ

Bill (Smithville NJ) · 08-09-2015, 04:54 PM

I'm starting to think of how I want the Utilities to work.

The first Utility (cause it's the easiest to do) would take a PCK file and create multiple text files, one text file for each program in the PCK file. Each of these programs would have a header section that would be Program Title (two lines), Titles for Program Keys A-F, Titles for Program Keys a-f. Then the Listing for the complete program would follow.

I prefer to have each programs a separate file - I find it easier to work on it that way - rather than all 15 programs in one big file.

The Second Utility would take a list of Program Text files and create a PCK file converting the Program Listings into HEX records. This would allow for creating personal PCK files that could include programs from multiple locations (ie, you could combine programs from the Standard Pack with Programs from the Math Pack.)

The Translate Table from HEX to Program Step is pretty straight forward. Just use an Array of HEX versus Program STEP (ie, LBL A, GTO 1, SIN, etc)

The reverse, going from a text source listing to a hex code, needs a little more thinking through. For example, do we accept variations of a step? Is "ROLL UP" R^ or RUP? Or do I accept both variations? Is Arc Sin ASIN or SIN-1? There are several other similar questions. Most of this is settled by what was done with the HP-41 emulator listings and I'll follow that mostly.

Since I am "Old School". I will be creating the utilities in Turbo Pascal for DOS. These will be pretty crude, but hopefully work for my purposes.

Bill
Smithville, NJ

lcwright1964 · 08-10-2015, 01:22 AM

(08-09-2015 04:54 PM)Bill (Smithville NJ) Wrote: The reverse, going from a text source listing to a hex code, needs a little more thinking through. For example, do we accept variations of a step? Is "ROLL UP" R^ or RUP? Or do I accept both variations? Is Arc Sin ASIN or SIN-1? There are several other similar questions. Most of this is settled by what was done with the HP-41 emulator listings and I'll follow that mostly.

I recall that with the wp34s assembler-disassembler (Perl scripts, which I have used on Mac, and Windows executables) there is a file that handles variations, so that somewhat complicated by common key sequences can be rendered by one (or occasionally more than one) simpler text instruction. I used to have it open when I was port HP41/42 programs I wrote to wp34s compatible text listings.

Les

lcwright1964 · 08-10-2015, 01:26 AM

(08-09-2015 10:20 AM)lcwright1964 Wrote: Solved!

Protected status is conferred by a P in the line just before the header line for a card side. "S1 -" means side one is NOT protected. "S2P-" means side 2 is protected.

Noticed that the hyphen does not seem to be present in files generated by the Android emulators, compared with the Windows ones.

I don't know if this will affect cross-platform compatibility. I should give it a whirl...

lcwright1964 · 08-10-2015, 06:48 PM

(08-10-2015 01:26 AM)lcwright1964 Wrote:
(08-09-2015 10:20 AM)lcwright1964 Wrote: Solved!

Protected status is conferred by a P in the line just before the header line for a card side. "S1 -" means side one is NOT protected. "S2P-" means side 2 is protected.

Noticed that the hyphen does not seem to be present in files generated by the Android emulators, compared with the Windows ones.

I don't know if this will affect cross-platform compatibility. I should give it a whirl...

The hyphen doesn't seem to matter either way.

On fiddling with display parameters, it seems that digit number is indicated in the third byte (from the right, of course) of the header word. So that digit is 6 for SCI 6 or FIX 6, say, as far as I can say. Didn't experiment much more, as I got confused when I saw other bits change (the sixth one going from 0 to 1, for example) and I couldn't back-engineer what I did.

Bill (Smithville NJ) · 08-10-2015, 10:33 PM

I have the utility working that will take a HP-67 PCK file and then create program listings. Each program listing is in a file named: PROGXX.LST where XX is the card number.

I still need to clean it up.

Next step to create the utility to take the Program listing files and generate a PCK file. That will have to wait for awhile, since real work is starting to interfere with my fun stuff.

Bill
Smithville, NJ

lcwright1964 · 08-10-2015, 11:08 PM

(08-10-2015 10:33 PM)Bill (Smithville NJ) Wrote: I have the utility working that will take a HP-67 PCK file and then create program listings. Each program listing is in a file named: PROGXX.LST where XX is the card number.

I still need to clean it up.

Next step to create the utility to take the Program listing files and generate a PCK file. That will have to wait for awhile, since real work is starting to interfere with my fun stuff.

Bill
Smithville, NJ

Wow! I look forward to seeing that.