Gotek with the HxC on an HP1652B

[arpruss]

In case anybody else is interested in manipulating files on the images, I should note that the common lifutils package doesn't work with the special reserved track 79 of the HP16xx disks.

I made a few quick and dirty scripts for manipulating things.

First, I convert HFE to LIF by doing:

Code: Select all

hxcfe -finput:filename.hfe -conv:RAW_LOADER -foutput:filename.lif

I can then manipulate the filename.lif image with:

Code: Select all

python lifutils.py dir filename.lif
python lifutils.py rm filename.lif NAME_TO_DELETE
python lifutils.py get filename.lif NAME_TO_FETCH
python lifutils.py put filename.lif NAME_TO_UPLOAD
python lifutils.py pack filename.lif

The lifutils.py file is here.

Finally, I convert the lif file to xml with this script, and then to hfe:

Code: Select all

python lif2xml.py filename.lif
hxcfe -finput:filename.xml -conv:HXC_HFE -foutput:filename.xml

It would be nice if raw lif images worked with hxc, but I can't get that to work.

[siredward]

Wow quite nice. I tried the 'dir' and 'get' options on the Python file so far. It seems to work quite well.

A typical output portion is :
0 ADAP_6808C,C120,24,19,90/02/14 02:06:00,8001534f544f
1 SNICKR_SER,C120,252,76,90/02/14 02:06:00,8001534f544f
2 WPC_CPU,C120,404,76,90/02/14 02:06:00,8001534f544f
3 WPC_J20102,C120,480,18,90/02/14 02:06:00,8001534f544f

I recognize the name of the file on the left. What are all the numbers? I see a date and a checksum perhaps.
Also how can I tell how full the disk is?

I am not clear on what the purpose of the xml file is.

Edward Cheung

[arpruss]

1. I just managed to create a layout file for the HP165X units. With the layout file, you don't need lif2xml.py, but you can just do:

Code: Select all

hxcfe -uselayout:hp.xml -finput:NAME.LIF -conv:HXC_HFE -foutput:NAME.HFE

to turn a LIF volume into an HFE volume.

2. Here's the output of lifutils.py dir on my usual boot disk:

Code: Select all

Volume: A165X
Directory start: 2
Directory length: 18 blocks
Directory version: 0
Tracks: 80
Sides: 2
Blocks per track: 20
0 SYSTEM_,C001,20,2593,90/02/14 02:06:00,8001534f544f
1 AUTOLOAD,C301,2613,1,90/02/14 02:06:00,8001534f544f
2 SCOPE_ONLY,C120,2614,67,90/02/14 02:06:00,8001534f544f
3 ARDUINO,C120,2681,67,90/02/14 02:06:00,8001534f544f
4 TTL2,C120,2748,67,90/02/14 02:06:00,8001534f544f
5 LOW_LEVEL,C120,2815,67,90/02/14 02:06:00,8001534f544f
6 SERIAL,C120,2882,67,90/02/14 02:06:00,8001534f544f
7 SCOPE_DEF,C120,2949,67,90/02/14 02:06:00,8001534f544f
Last block 3016

For instance entry 0 is for the unit's operating system:
Filename: SYSTEM_
File type: C001
Starting block in LIF file: 20 (blocks are 256 bytes long)
File length in blocks: 2593
Date: 90/02/14 02:06:00
Miscellaneous data: 8001534f544f

3. My main reference for LIF is: https://www.finseth.com/hpdata/lif.php . Based on that infromation, the miscellaneous data indicates a password (8001) for a file marked private, the password being "SOTO" (534f544f).

[siredward]

So looks like the XML file is a way to tell hxcfe how to prepare the .HFE file using the .LIF as input.

Thank you for your time and effort! I no longer need to use LIFUTILS.EXE as it is really old.

Edit.. I see parallels with your python script and work I did with my HP-41 calculator. Those files are also in LIF format.
That blog is here:
https://www.edcheung.com/job/hp41/hp41.html#pilbox

Edward Cheung

[arpruss]

**UPDATE:** lifutils.py now automatically chunks and unchunks when putting and getting files.

I just noticed that the LIF files have a chunk structure. Each chunk starts with a two-byte length (big-endian), then the data follows (number of bytes equal to the length). After the last chunk is a length of FFFF.

Normally the chunks have lengths of 254, except for the last one which may be shorter.

I noticed this when trying to disassemble PVTEST_ (the system diagnostic program). I was having terrible results with Ghidra until I de-chunked the file. FYI, the actual 68000 code for PVTEST_ and SYSTEM_ begins at offset 0x2C in the de-chunked file, and at least in PVTEST_ it is loaded at 0x984500. I am hoping to be able to write my own code that runs on the unit.

[arpruss]

I am posting a variety of things for the HP165X on: https://github.com/arpruss/hp165x_software_development

In particular, I can now run simple 68K assembly language programs on my 1653B. For instance, dumperkey shows the keycodes of all the keys.

[siredward]

Wow truly impressive hack.

(Meant in the original sense of the word where one finds a machine’s back door and runs custom code on it).

I will explore more when I get home from travel.BTW my general 1652B blog is here:
https://www.edcheung.com/album/album15/ ... p1652b.htm

Dr Edward Cheung

[arpruss]

You might want to see if the software.hfe from my github works on your HP1652B. If you boot it, you should get a loader letting you choose between a memory browser (DUMPER) and my falling blocks game (WIZTRIS).

[siredward]

As impressive as it would be to try the code, I think this is a bit over my head. I am really happy with the way my Logic Analyzer is working and I don't really see a reason to experiment with the firmware of the unit at this time. So thank you, but I don't really understand all the files well enough to start changing things. Thank you again for your efforts on this.

Dr. Edward Cheung.

[arpruss]

I've been playing around with trying to make larger virtual disks work. I successfully generated an HFE file with 8 sectors per track, which gave a 60% greater capacity, and I successfully booted from such a virtual disk, but when I had the HP write to the virtual disk, the write was corrupted. (Using 9 sectors per track, it also booted, but took more than twice as long as usual so I didn't test that further. Using 10 sectors per track, the ROM disk reading code crashed.) I am now experimenting with 254 track virtual disks using the standard HP 5-sectors-per-track format, with an extra magic track 79 side 0 sector 98, but it will require a patch to the OS to read beyond track 76.

(By the way, even though the disks are formatted to 80 tracks, the OS only allows LIF data in the first 77 tracks. And there is, I think, an off-by-one bug, either in the ROM or the SYSTEM_ software, where the last 256 byte block of the second side of track 76 does not count towards disk capacity.)

In case anybody is curious, I do have more information about the magic track 79, based on reverse engineering of the ROM. Track 79 side 0 must have a sector numbered 98 which contains information about the disk format. The default value is:

Code: Select all

50 02 88 05 03 01 02 01 A3 01 A3 E6 32 16 32

I know what a few of the values mean. The "50" in byte 0 is a marker for the magic sector. Byte 3 specifies the number of sectors per track. Byte 4 specifies sector size, with 03=1024 being the default (smaller sector sizes as possible, but why bother?). AS far as I can see, the ROM ignores all the other values. In standard HP formatting, the data is duplicated on side 1 of the track, and there is a small header on sector 97 of both sides of the track, but this is all ignored by the ROM. So if anybody wants to experiment with custom disk layouts, just make sure you put have a track 79 side 0 sector 98 with the correct values for bytes 0, 3 and 4, and the ROM should recognize it.

After reading 79.0.98, the ROM reads the first sector of the disk (0.0.1) which has the standard LIF header, but it ignores all the data there (including the number of tracks, etc.) except for checking that there is a 0x8000 LIF header, and I think saving the volume name.