EMU71 JPCROM Image

[Howard Owen]

Some of you may have seen this thread in which I had to pull the battery out of my CMT 64K RAM module to recover from copying EMU71's JPCROM image to the module, configured as an IRAM. Now that Mike is providing CMT 32K and 64K EPROMs burned with bits you supply, I need to understand better why the RAM experiment failed. I imagine JF would be one guy with authoritative answers, but perhaps some others on this forum might know. Is the JPC ROM image available on JF's site modified for use in EMU71? Or should you be able to write it to EPROM and have it work? Looking at Mike's process, the penultimate step is to copy the image to the burner's RAM, configured as an IRAM. That step blew away the internal LEX chain on my 71B, so that no keywords (including PURGE 8) would work. I don't think Mike would appreciate that if it happened on his burning set up.

Thanks for any insight you can offer.

Regards
Howard

[Howard Owen]

I ought to stop replying to my own posts like this, but I keep finding the answers shortly after posting. 8) (Perhaps if they weren't essentially dumb questions, I would have to wait longer for an answer. 8)

I knew from reading the HP-71 IDS Vol 1 that IRAMs and ROMs both have their own file chains. So my efforts were directed towared understanding this chain using a hex editor. What I neglected to do was a simple "CAT :PORT(3)" in emu71 with the JPCROM image loaded in the virtual port 3. That yielded a listing for a file called "JPCLEX" which was 26K, or more than twice the size of the JPCLEX found on the swap disks. Copying that file to RAM on my real 71 worked just fine, and yielded a working JPCROM environment.

So the "JPCROM.BIN" image is a container. When you plunk that down into the file system, (which is only possible if you munge the file type, like I did with my LIF tools) the file chain in the header completely blows up the 71's processing of the internal file chain, leading to the lockup described in my original posts. If you copy the file contained in the image, then of course it works just fine.

Regards,
Howard

Edited: 7 May 2006, 5:48 p.m.

[Mike]

You say:

"burned with bits you supply"

Yes, I expect the software to be loaded be provided by the user.

This is primarily because I haven't figured out how to get files of the format (xxxx.l71, yyyy.b71, zzzz.t71, etc) from the internet to my 71B, via a 3.5" disc. I don't have a physical interface like HP-IL from PC and even if I did, I'm not sure that would help. Seem to not understand this whole process. :-)

I've been trying to use the LifUtil but it doesn't seem to work for me. Don't know if I have an old version, don't know how to use it, can't be done, or all three.

As a test, to try and understand how this works, and by starting with files on a 71B, I...

1. formatted a low density disc on my 9114B.
   
2. copied various LEX and BASIC files to the disc
   
3. inserted the disc in my Win98 system and executed LifUtil
   
4. A catalog showed the files on the disc ok, BUT the TYPE was just a number instead of LEX or BASIC.
   
5. Anyway, I continued
   
6. Copied files from disc to PC (LIF to DOS) and that process went ok. Files were created but in what format?
   
7. Initialized the disc, to erase the file
   
8. Did the reverse process and copied DOS to LIF. But in what format?
   
9. Took the disc back to my 9114B and it still was able to CAT and read the names.
   
10. Tried to COPY files and I get a "Invalid TYPE" error. The types are shown as HP-UX.

I have tried about every combination of conversion options, to no avail.

So, can anyone summarize the exact steps, if it's even possible, to take SomeFile.b71 or SomeOtherFile.l71 or even a SomeTextFile.t71 and then using LifUtil or some other program, write these to a 9114B formatted file, using a Win98 PC so that my 71B can load those files from the disc? Whew! That was a long sentence.

Edited: 8 May 2006, 2:15 a.m. after one or more responses were posted

[Howard Owen]

Ah, I see. The issue is the LIF file type.

The trick there is to change the option "File Format Conversion" from "Binary Copy - No Format change" to the next option (press F1) which says "Binary Image: Preserve DFS File Header". That's on LIF to DOS. If you then change the same option in the DOS to LIF copy to be "DFS to LIF. File Type Preserved" instead of the default. It will preserve the file type.

The files have to have their LIF headers, though. Where are you getting the files from? The ones on my site have the LIF headers removed. The ones in ftp://ftp.hpmuseum.org/lif/swap have the headers intact, as I recall.

So the drill would be to format a 9114 disk, place it in the PC's floppy drive, run LIFUTIL, copy the files as you have already, but change the "File Format Conversion" option as described above.

Regards,

Howard

[Mike]

UPDATE (correction):

I re-read your comment and it turns out I didn't try that on the 9114B-->PC-->9114B. I tried it with the InternetLIFforDOSfile-->PC-->9114B. That might require a slightly different process. I'm going to retry this tonight for creating my own LIF files and back to 9114B. That might work. But the problem I'm working on is going from the SwapDisc Files that have been created for DOS world back to 9114B disc.

Original comment below

I already tried that and it didn't work. None of the available selections knows of the types used by the 71 or 41, apparently. One of the first things I tried was changing the conversion to "DOS to LIF, Preserve File Type" but it failed.

I've been reading an article by Dan McDonald that says I have to remove the first 32 bytes, from the LIF (which have already been converted for DOS machine and contain these extra 32 bytes) and then use the "user defined" type and manually key in the TYPE and SPECIAL IDENTIFYIERS. This info is in the 32 bytes and is copied into these two fields in the "user defined" type.

I'm using files at: ftp://ftp.math.jyu.fi/pub/hpil/ but I think they are the same as on HP Museum. I was using those because they were the ones referenced in the article.

The problem I was having was the file type was not recognized, before I removed those 32 bytes and before I entered the data into the TYPE and IDENTIFYIER fields.

Sure enough, when I remove the 32 bytes and enter this data, the correct type shows up when I CAT the 9114B disc with 71B. It even loads now, when I load the files. There is still a problem.

The programs don't run. They hang the system up after loading, so there is still something wrong I'm missing.

I removed the 32 bytes with a HEX Editor. I don't think that's where the problem is but I'm going to look there tomorrow. But I'm getting closer.

BTW, I'm working with the same two files, to get some consistency. I'm trying to convert a "CLONE.b71" file and "COUNTLEX.l71" on CHHU06.

Specific steps:

1. Use HEX Editor to note TYPE and SPECIAL Identifiers (record these)
   
2. Delete the first 32 bytes
   
3. Use LifUtil to copy DOS to LIF
   
4. Change conversion to "user defined"
   
5. Use F6 to change the TYPE and Special Identifiers
   
6. START

This produces a disc with contents I can read on the 9114B and in fact, I can see the correct file and type. It even loads but hangs up the computer, if I try to execute. Sometimes on loading. I still think something might be corrupted. Tomorrow I'll try a different disc and see if that makes a difference. These discs have been INITIALIZED on the 9114B. But I'll try others.

Getting late, calling it an evening for today.

Edited: 8 May 2006, 11:18 a.m. after one or more responses were posted

[J-F Garnier]

Hi,

I noticed several years ago that some individual files (*.b71, *.l71, etc) are corrupted, so I recommend to start from the disc LIF images on ftp://ftp.hpmuseum.org/hpswap/ that seem OK.

Emu71 can help to load files from a LIF disc image, and to tranfer them to a HP71 using a floppy disc.

Regarding JPC Rom: the bin file on my site is an exact copy of the ROM binary content (no special change for Emu71). Keep in mind that JPC Rom is still copyright PPC-Paris, even if it is now freely available on the Web. Although I'm not the copyright owner (but who is, as PPC-Paris disappeared years ago?) I'm considering myself as the moral guardian of the spirit of the JPC Rom project... So selling blank modules with a free programming service (even with the JPC Rom) is OK, but selling copies of the JPC Rom module would be different...

J-F

Edited: 8 May 2006, 6:52 a.m.

[Mike]

You say
"I noticed several years ago that some individual files (*.b71, *.l71, etc) are corrupted, so I recommend to start from the disc LIF images on ftp://ftp.hpmuseum.org/hpswap/ that seem OK."

I reply
I am going to start over, now that I have learned a bit about this process. I have checked and it looks like the files I'm using are the same as on the HP Museum site. But I'll try the HP Museum images and see.

You say
"Emu71 can help to load files from a LIF disc image, and to tranfer them to a HP71 using a floppy disc."

I reply
Can the Emu71 transfer them to a floppy, without an HP-IL interface? I don't have one on my PC and likely won't get one any time soon. I need a means to make the 9114B disc, without any physical interface between the PC and 9114B.

You say
"So selling blank modules with a free programming service (even with the JPC Rom) is OK, but selling copies of the JPC Rom module would be different...:"

I reply
That is why I say the person I will make an EPROM for must supply the software. Anything they can legally posess, I can program for them. And the programming service doesn't have to be free. It's fair to charge for the EPROM and it's fair to charge for the service. I just don't provide any software.

Edited: 8 May 2006, 10:55 a.m.

[J-F Garnier]

Can the Emu71 transfer them to a floppy, without an HP-IL interface? I don't have one on my PC and likely won't get one any time soon. I need a means to make the 9114B disc, without any physical interface between the PC and 9114B.

Yes, Emu71 is able to write on LIF disc using the PC floppy drive. It has the same limitation than other LIF tools, namely this feature runs on DOS and Windows9x, but not on modern OS like Win2000, XP, etc. Note also that the disc must be first formatted with a HP9114.

For more details, refer to the Emu71 manual. BTW I just released an improved version of Emu71, now with a pdf documentation!

It's fair to charge for the EPROM and it's fair to charge for the service

Yes, I agree. I was just a little bit concerned because you wrote:
"Yes, I expect the software to be loaded be provided by the user. This is primarily because I haven't figured out how to get files ..." I'm going to release new material about the JPC Rom, and I would like to keep the non commercial spirit.

J-F

[Gene]

Is it version "X" that Rodger debugged?

Gene

[Howard Owen]

I love the JPC ROM!

The "X" version is only 26K in size. So a 64K EPROM can hold the math ROM, the JPC ROM, and a few other goodies besides. W00t!

Regards,
Howard

Edited: 8 May 2006, 8:34 p.m.

[Mike]

I tried the COPY "FileName:FDRIVE1" command it worked ok, except after copying, the CAT ":FDRIVE1" doesn't show the copied file. I went outside of Emu71 and use LifUtils and the copied file is actually there. Just can't be seen by Emu71.

Also, the type wasn't right for the file type.

What might I be doing wrong, that I can't see files copied with Emu71? BTW, I can see other files on the same floppy that were copied with LifUtils. It's almost as if the fact the TYPE isn't right, prevents it from being seen.

Is there anything to put in *.ini file besides: FDRIVE1 A

How does one COPY from Emu71 to FDRIVE1, and maintain the TYPE?

Edited: 8 May 2006, 10:06 p.m.