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?
(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.
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
I am making some progress, changing the filename in a structured way and monitoring the changes.
// 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
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.
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:
8091: Chr2 b1,b0; Chr1 b7-b0.
8092: Chr4 b5-b0; Chr3 b7-b4.
8093: Chr7 b1,b0; Chr6 b7-b0.
8094: Chr3 b3-b0; Chr2 b7-b2.
8095: Chr5 b7-b0; Chr4 b7,b6.
8096: 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.
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 ; . . . . . . .
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
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.