HP-71 Compu-LS module

[rprosperi]

(03-23-2017 09:49 PM)Dave Frederickson Wrote:  Obviously this is incorrect, but what are the consequences?

It likely adds a zero nibble during export, which is irrelevant as that nibble is never executed.

Try exporting the same file via :DOSLINK, strip the header with aLIFhdr /x, then add another back on again using aLIFhdr with /L, and import it via :DOSLINK. I imagine the new version is 1 nibble larger, but still runs properly, since no code ever addresses the final nibble.

[twa14]

Dave, I see that you are correct on the basic file, I seem to have lost the bottom, Ill have another go tomorrow and add keywait.

[Dave Frederickson]

What a disaster!

DOSLINK created a 256 byte file! I stripped the header, then recreated it using aLIFhdr.

Code:

41 4c 50 48 41 33 20 20 20 20 e2 08 00 00 00 00 
00 00 00 01 00 00 00 00 00 00 80 01 00 02 00 00

The file header now shows the file to be 0x0200 nibbles in size. That's 512 nibbles, or 256 bytes.

Dave

[rprosperi]

(03-23-2017 10:37 PM)Dave Frederickson Wrote:  What a disaster!

DOSLINK created a 256 byte file! I stripped the header, then recreated it using aLIFhdr.

Code:

41 4c 50 48 41 33 20 20 20 20 e2 08 00 00 00 00 
00 00 00 01 00 00 00 00 00 00 80 01 00 02 00 00

The file header now shows the file to be 0x0200 nibbles in size. That's 512 nibbles, or 256 bytes.

Dave

It's not a disaster, it's exactly what it should be doing.

After you export the file to :DOSLINK (which creates 256-byte sector files due to LIF limitations) you simply strip the header using "aLIFhder outfile.dat alphanum.lex /x" which produces a 96-byte DOS file.

Then, add a header back onto that 96-byte file using "aLIFhdr alphanum.lex infile.dat /L" and then import it from :DOSLINK and it re-creates the same 96-byte LEX file we started with.

Make sense?

[Dave Frederickson]

(03-23-2017 11:04 PM)rprosperi Wrote:  After you export the file to :DOSLINK (which creates 256-byte sector files due to LIF limitations) you simply strip the header using "aLIFhder outfile.dat alphanum.lex /x" which produces a 96-byte DOS file.

What "LIF limitations"? LIFUTILS had no problem creating a 96-byte DOS file.

I tried your suggestion, twice, and each time it created a 4MB output_file, not 96 bytes.

Frankly I doubted this would work as the /x option is supposed to remove the LIF file header, but there's no mention of it stripping garbage from the end of the file.

Now I think you're just messing with me.

Dave

[rprosperi]

(03-23-2017 11:31 PM)Dave Frederickson Wrote:  What "LIF limitations"? LIFUTILS had no problem creating a 96-byte DOS file.

I tried your suggestion, twice, and each time it created a 4MB output_file, not 96 bytes.

Frankly I doubted this would work as the /x option is supposed to remove the LIF file header, but there's no mention of it stripping garbage from the end of the file.

When using DOSLINK as a virtual IL device, the file is being written by the 71B itself (COPY FILENAME TO :DOSLINK), which believes it is writing to a LIF device, hence the 256-byte 'sector' size.

As soon as you have used a command like above to copy the file, remember to CLEAR :DOSLINK, to close the output file.

I did the test using EMU71/Win and IL-Per v2.23 connected by virtual HP-IL. Results were as described, I didn't just make it up.

/X removes the header, but it also reads the header to know the proper file size to create (info stored in the LIF header). The extra 'garbage' is just irrelevant filler needed to make up the full 256-byte sector size and is removed.

Clear any existing infile.dat and outfile.dat (or whatever you may have called them) files and re-do the process closing the files after each copy and I believe you will get the suggested results.

[Dave Frederickson]

(03-23-2017 11:53 PM)rprosperi Wrote:  As soon as you have used a command like above to copy the file, remember to CLEAR :DOSLINK, to close the output file.

Isn't that what the 'C' button is for?

After achieving inconsistent results the 96-byte output file was finally produced. A new LIF file header was then created using aLIFhdr and it incorrectly set the file size to 96 bytes, not 95.5.

It seems that it is for this reason that the other tools don't support this feature.

Dave

[rprosperi]

(03-24-2017 12:18 AM)Dave Frederickson Wrote:  After achieving inconsistent results the 96-byte output file was finally produced. A new LIF file header was then created using aLIFhdr and it incorrectly set the file size to 96 bytes, not 95.5.

Not sure why it took several tries, I've found it consistent.

When it SAVES the '71 binary file to DOS, if it's an odd number of nybbles, it must round up to full bytes, a DOS file system requirement. When then having a new header added, the size is based on the now 'larger' size, as the actual (original) cannot be determined.

There is no other possibility, no matter how clever the DOS side s/w is, the original file length info is not available.

But it doesn't matter since the, now possibly 1-nybble larger, file imported this way, works just fine.

[Dave Frederickson]

(03-24-2017 01:47 AM)rprosperi Wrote:  There is no other possibility, no matter how clever the DOS side s/w is, the original file length info is not available.

What are you doing with 71 binary files in the DOS/Windows environment in the first place?
1. File comparison or duplicate search
2. Assembly

If your assembling files, then you do know the length of the original file and that value could be passed to the program that prepends the LIF file header.

I really don't care 'cause I'm using LIFUTILS. That is except for formatting blank media. pyILPER won't accept blank media.

Dave

[rprosperi]

(03-24-2017 02:15 AM)Dave Frederickson Wrote:  What are you doing with 71 binary files in the DOS/Windows environment in the first place?

You're the one who asked about this, I'm just answering your question how to do this with aLIFhdr, LOL!

I only do this when I need to do a comparison of binary (LEX) files after assembling from source on the '71 using the FORTH/Assembler ROM. One long-term (read slow, low-priority) project is to recreate a source file for the NIBBLEX LEX file. Source for the various earlier PEEKLEX, UTIL, etc. versions exist, but I've not been able to find source for the later, HP-approved NIBBLEX, so I'm rebuilding it from a disassembly listing; once completed, I need to do a byte- (or nybble-) level comparison to ensure it's an exact (not just functional) match.

[twa14]

Hi Guys, I hope that my crashing around isn't going to lead to fisticuffs between you! I have been scanning the manual today and have just saved half of it as a PDF. Its 40mb which I believe exceeds my allowance on the site. I can email directly to those interested? If there is a better solution pls let me know.

Tom

[Dave Frederickson]

(03-24-2017 02:34 AM)rprosperi Wrote:  

(03-24-2017 02:15 AM)Dave Frederickson Wrote:  What are you doing with 71 binary files in the DOS/Windows environment in the first place?

You're the one who asked about this, I'm just answering your question how to do this with aLIFhdr, LOL!

I only do this when I need to do a comparison of binary (LEX) files after assembling from source on the '71 using the FORTH/Assembler ROM. One long-term (read slow, low-priority) project is to recreate a source file for the NIBBLEX LEX file. Source for the various earlier PEEKLEX, UTIL, etc. versions exist, but I've not been able to find source for the later, HP-approved NIBBLEX, so I'm rebuilding it from a disassembly listing; once completed, I need to do a byte- (or nybble-) level comparison to ensure it's an exact (not just functional) match.

Well, it was a rhetorical question. I just wanted to discuss something I've been thinking of for a while and then Christoph mentioned aLIFhdr, so I brought it up.

Recently I extracted the entire OLDP in order to identify duplicates. It now occurs to me that it's possible that some duplicates may have gone undetected if they differed in only the last (garbage) nibble (for odd nibble sized files). Compared to the large number of duplicates in the archive this is probably a small number, so it's not a great concern.

Dave

[Dave Frederickson]

(03-24-2017 03:21 PM)twa14 Wrote:  I have been scanning the manual today and have just saved half of it as a PDF. Its 40mb which I believe exceeds my allowance on the site. I can email directly to those interested? If there is a better solution pls let me know.

Tom

Hi Tom,

I've PM'd you my email address.

Google Drive and Dropbox offer file hosting services. For large images, TinyPic also offers free services.

Dave

[twa14]

Hi Dave

Bob sent me the complete Basic text file (to line 9996). I converted it to DAT using Christophs "alihdr32" program and loaded it into EMU71/Win. On transform to basic I get the same error "Line 295" which doesn't exist. Could the original hex file be incomplete? the checksums were a bit dodgy?

Tom

[Dave Frederickson]

(03-25-2017 08:16 PM)twa14 Wrote:  Bob sent me the complete Basic text file (to line 9996). I converted it to DAT using Christophs "alihdr32" program and loaded it into EMU71/Win. On transform to basic I get the same error "Line 295" which doesn't exist. Could the original hex file be incomplete? the checksums were a bit dodgy?

Hi Tom,

This is one of the valid techniques for importing a BASIC file. What is your 71's configuration, ROM, RAM, and version?
The hex file is complete, other wise we wouldn't have been able to list the BASIC file. The checksums were 'dodgy' because Titanchk is intended for ROM images. IRAM images don't have ROM checksums.

Dave

[twa14]

I followed J_F's advice and put it on the EMU71/win. HPIL in port 0, 32k port 1, 64k port 2. Memory with the text file loaded is still 32k. I haven't loaded it on the physical 71B

Tom

[Dave Frederickson]

Works for me.

Code:

>COPY COMPU:2
>CATALL
  NAME   S TYPE   LEN    DATE    TIME PORT
workfile   BASIC     0 01/01/00 00:00 
COMPU      TEXT  47104 03/25/17 17:19 
>TRANSFORM COMPU INTO BASIC
>CAT ALL
  NAME   S TYPE   LEN    DATE    TIME PORT
workfile   BASIC     0 01/01/00 00:00 
COMPU      BASIC 32649 03/25/17 17:19 
>LIST COMPU,9996
9996 SUB E @ CALL A(ERRM$) @ RUN 
>

[rprosperi]

(03-26-2017 12:33 AM)Dave Frederickson Wrote:  Works for me.

Code:

>COPY COMPU:2
>CATALL
  NAME   S TYPE   LEN    DATE    TIME PORT
workfile   BASIC     0 01/01/00 00:00 
COMPU      TEXT  47104 03/25/17 17:19 
>TRANSFORM COMPU INTO BASIC
>CAT ALL
  NAME   S TYPE   LEN    DATE    TIME PORT
workfile   BASIC     0 01/01/00 00:00 
COMPU      BASIC 32649 03/25/17 17:19 
>LIST COMPU,9996
9996 SUB E @ CALL A(ERRM$) @ RUN 
>

I got same results, with final BASIC program the exact same size as yours (which btw, is different than the original, but this is not uncommon for large complex programs).

Interestingly, my '71 TEXT version of the file is not the same size as yours (46,848 vs, your 47,104) your file is 1 record longer - perhaps there was an extra blank line at top or bottom? Likely it's something like that since the processed results are the same.

[twa14]

Hi Dave\Bob

Have you both done this on EMU71/Win or the physical 71B?

Tom

[twa14]

Hi Dave\Bob

I see that you are using a COMPU.TXT file and not a COMPU.DAT File. Both of you have a size of 47104 bytes. My text file has a 50011 bytes size and 53248 bytes "size on disk" using explorer. I am using the file that Bob sent me so how can this be happening?

Its working !!!, I followed Bob's advice in his email to me. I did get an "error syntax" following the transform but the basic program is in EMU71\win memory. I have no idea what I did wrong the first and second times. Anyway thanks again to both of you for all your help. The text file is 46848 bytes and the Basic file 32670 bytes


Tom