Threaded Mode | Linear Mode

MeindertKuipers · 01-13-2021, 03:34 PM

One of my current little projects is to expand my HP41 disassembler with support for the HEPAX RAM images. With the help of Ángel I now have the details of the files structure. What is lacking is how the file names are coded. According to the available documentation 7 characters are compressed in 6 10-bit words. After some attempts I am still pretty much in the dark as to how this is compressed. It appears that two-bit pairs are spread over the 6 available ROM words, but I fail to see any logic in the patterns.
Next task would be to understand how Register Files are compressed, one 7-byte HP41 register is compressed is 6 10-bit ROM words. Most logical would be if the same compression as the filenames are used, but who knows ...
Does anyone here have any detailed info about this?

Howard Owen · 01-13-2021, 03:52 PM

(01-13-2021 03:34 PM)MeindertKuipers Wrote: It appears that two-bit pairs are spread over the 6 available ROM words, but I fail to see any logic in the patterns.

Perhaps if you posted several examples of the 60 bit patterns someone could take a crack at decoding them. It would be especially helpful if you knew what strings the 60 bit patterns encoded for, though it might be possible to do it without knowing the plaintext.

I'm not saying I'm likely to get the answers, but it strikes me that the mathematically inclined users of this forum might enjoy the challenge.

Ángel Martin · (This post was last modified: 01-13-2021 04:18 PM by Ángel Martin.)

Here's a couple of examples"

Code:

434        

4D4        

54C    Compressed File Name    

395    "ELEMNT4"    

115    

C11

and:

Code:

254    

0D4    

14C    Compressed File Name

153    "ELEMENT"

115    

011

and:

Code:

420    

494    

045    Compressed File Name

3D1    "PERIOD"

549    

814

and:

Code:

020    

202    

E4D    Compressed File Name

808    "NM"

480    

813

MeindertKuipers · 01-13-2021, 05:03 PM

I am making some progress, changing the filename in a structured way and monitoring the changes.

Sylvain Cote · (This post was last modified: 01-13-2021 05:19 PM by Sylvain Cote.)

// HEPAX is padding the filename with spaces

Code:

0x20202020202020 -> [8092] 020 202 020 008 080 008  <-  CLA  32 XTOA 20 HCRFLD [memory dump] HPURFL

Code:

0x01202020202020 -> [8092] 020 202 120 008 080 000  <-  CLA   1 XTOA 20 HCRFLD [memory dump] HPURFL

0x02202020202020 -> [8092] 020 202 220 008 080 000  <-  CLA   2 XTOA 20 HCRFLD [memory dump] HPURFL

0x03202020202020 -> [8092] 020 202 320 008 080 000  <-  CLA   3 XTOA 20 HCRFLD [memory dump] HPURFL

0x04202020202020 -> [8092] 020 202 020 008 080 001  <-  CLA   4 XTOA 20 HCRFLD [memory dump] HPURFL

0x07202020202020 -> [8092] 020 202 320 008 080 001  <-  CLA   7 XTOA 20 HCRFLD [memory dump] HPURFL

0x08202020202020 -> [8092] 020 202 020 008 080 002  <-  CLA   8 XTOA 20 HCRFLD [memory dump] HPURFL

  ˆˆ                               ˆ            ˆˆ

Code:

0x0F202020202020 -> [8092] 020 202 320 008 080 003  <-  CLA  15 XTOA 20 HCRFLD [memory dump] HPURFL

0x10202020202020 -> [8092] 020 202 020 008 080 004  <-  CLA  16 XTOA 20 HCRFLD [memory dump] HPURFL

0x7F202020202020 -> [8092] 020 202 320 008 080 01F  <-  CLA 127 XTOA 20 HCRFLD [memory dump] HPURFL

0x80202020202020 -> [8092] 020 202 020 008 080 020  <-  CLA 128 XTOA 20 HCRFLD [memory dump] HPURFL

0xFF202020202020 -> [8092] 020 202 320 008 080 03F  <-  CLA 255 XTOA 20 HCRFLD [memory dump] HPURFL

  ˆˆ                               ˆ            ˆˆ

Code:

0xFF012020202020 -> [8092] 020 202 301 008 080 03F  <-  CLA 255 XTOA  01 XTOA 20 HCRFLD [memory dump] HPURFL

0xFFFF2020202020 -> [8092] 020 202 3FF 008 080 03F  <-  CLA 255 XTOA 255 XTOA 20 HCRFLD [memory dump] HPURFL

    ˆˆ                              ˆˆ

I will let you complete the test ...

edit 1: [memory dump] = HEXEDIT 8092 SST SST SST SST SST SST ← ←
edit 2: my tests assumed an empty HEPAX RAM at the start

MeindertKuipers · 01-13-2021, 07:13 PM

Thanks for your support, I figured it out. Just a lot of tedious typing and checking to find out. I still need to verify if this works in my disassembler, but here it is (only one file assumed in HEPAX RAM):

Code:

              bit in word  

              9-8   7-6    5-4    3-2    1-0

   [C092]     t24   t25    t26    t27    t28

   [C093]     t14   t15    t16    t17    t18

   [C094]     t4    t5     t6     t7     t8

   [C095]     t19   t20    t21    t22    t23

   [C096]     t9    t10    t11    t12    t13

   [C097]     -     -      t1     t2     t3

   If the filename is (assuming a 7-character filename):

   t1.t2.t3.t4 / t5.t6.t7.t8 / t9.t10.t11.t12 / t13.t14.t15.t16 / t17.t18.t19.t20 / t21.t22.t23.t24 / t25.t26.t27.t28

where txx is always a pair of bits (2 bits)

The filename seems to be delimited with a <space> (when shorter than 7 characters), a non assigned file (the first empty in the system) seems to have a name of all spaces.

It is not entirely logical to me, so it would be nice if somehow the background of this choice of coding could ever be available. Now work to verify this en then check if this also applies to the packing of a register in 6 10-bit words.

Strange enough, it is possible to rename a HEPAX file to a name with only one space, or to have a filename with spaces between character, so the delimiting space is not very strict.

Diego Diaz · (This post was last modified: 01-14-2021 02:43 AM by Diego Diaz.)

Hi all,

Assumed single program file, seven chr. filename (eg. "ABCDEFG") Chr1="G", Chr7="A".

Taken from the notes and test I did several years ago, I have not double checked this again.

Indeed it's anything but "intuitive", and certainly not easy to figure out.

Code:

 Chr2 b1,b0; Chr1 b7-b0.

 Chr4 b5-b0; Chr3 b7-b4.

 Chr7 b1,b0; Chr6 b7-b0.

 Chr3 b3-b0; Chr2 b7-b2.

 Chr5 b7-b0; Chr4 b7,b6.

 Void b9-b6; Chr7 b7,b2.

Hope this helps.

Best from Caribbean.

Diego

EDIT: I've now realized that there is some 'logic' in this encoding method.
The filename is inserted (bitwise) following the sequence: 8091, 8094, 8092, 8095, 8093, 8096. LSB -> MSB.

MeindertKuipers · 01-17-2021, 11:28 AM

This HEPAX compression format is now confirmed, and is also valid for the packed registers (DA, WA and KE file types). It is real fun to dive this deep in the HEPAX file structure, respect to the makers of HEPAX!

Next task is to clean up some things in the disassembly listings and add support for multi-block files. Below is a sneak preview of a disassembled HEPAX ASCII file. I intend to make the listing a bit more text focused for readability, and indicate <EOL> and <EOF> plus the record pointer. The ASCII files are not compressed.

Code:

_HPX_FL03   A460 003          .HEPAX      003                         ; type = AS   ASCII

_HPX_NM03   A461 020 145 153  .HEPAX      "ASCTST "                   ; FileName "020 145 153 0D5 10D 010 091"

_HPX_SZ03   A467 091 000      .HEPAX      0091                        ; HEPAX Filesize 140 words / 20.0 regs

_HPX_BS03   A469 010 000      .HEPAX      0010                        ; HEPAX words in this block 11

_HPX_PT03   A46B 000 000      .HEPAX      0000                        ; HEPAX Filepointer 

_HPX_CH03   A46D 00F          .HEPAX      00F                         ; HEPAX char pointer (ASCII files)

_HEP_ASC03  A46E              .L000       00F 054 045 053 054 020 041 ; . T E S T   A 

            A475              .L001       04C 050 048 041 020 044 041 ; L P H A   D A 

            A47C              .L002       054 041 0FF 002 064 000 000 ; T A . . d . . 

            A483              .L003       000 126 314 150 056 000 000 ; . & . P V . . 

            A48A              .L004       126 314 150 056 000 000 000 ; & . P V . . . 

            A491              .L005       200 000 000 000 000 000 300 ; . . . . . . . 

            A498              .L006       000 000 000 000 000 000 000 ; . . . . . . . 

            A49F              .L007       000 000 000 000 000 000 000 ; . . . . . . . 

            A4A6              .L008       000 000 000 000 000 000 000 ; . . . . . . . 

            A4AD              .L009       000 000 000 000 000 000 000 ; . . . . . . . 

            A4B4              .L010       000 000 000 000 000 000 000 ; . . . . . . . 

            A4BB              .L011       000 000 000 000 001 000 100 ; . . . . . . . 

            A4C2              .L012       000 000 000 000 000 000 000 ; . . . . . . . 

            A4C9              .L013       000 000 000 000 000 000 000 ; . . . . . . . 

            A4D0              .L014       000 000 000 000 000 000 000 ; . . . . . . . 

            A4D7              .L015       000 000 000 000 000 000 000 ; . . . . . . . 

            A4DE              .L016       000 000 000 000 000 000 000 ; . . . . . . . 

            A4E5              .L017       000 000 000 000 000 000 000 ; . . . . . . . 

            A4EC              .L018       000 000 000 000 000 000 000 ; . . . . . . . 

            A4F3              .L019       000 000 000 000 000 000 000 ; . . . . . . .

SteenPetersen · 01-18-2021, 08:54 PM

Thank you for the kind words. Interesting that you are making a disassembler for the HEPAX RAM - cool!

I do not remember how the file names were compressed, but as I had a tendency to reuse existing code, then the encoding and decoding must be something I called in a sub-routine. I for sure could never think of a coding like that.

In one of the other threads there was a reference to a presentation I made in Corvallis in 1988 about the HEPAX File System - I have attached it here for your reference.

Keep up the good work with the HEPAX RAM disassembler!

Best regards,
Steen

MeindertKuipers · 01-19-2021, 06:06 PM

Thank you Steen,

It is really good to have you here in the forum and getting the dust of your old stuff. I did have access to your presentation, and it was really helpful. I now need to understand how multi-block files are linked in detail. I never had a real HEPAX, but today have 4 different platforms for testing, although now my DM41X is slightly favourite.