Author Topic: Archiving LIF formatted 3.5 inch Disk  (Read 3193 times)

0 Members and 1 Guest are viewing this topic.

Offline garrettmTopic starter

  • Frequent Contributor
  • **
  • Posts: 267
  • Country: us
Archiving LIF formatted 3.5 inch Disk
« on: March 01, 2022, 01:28:16 am »
I recently acquired a HP 8175A "digital signal generator" which came with two floppy disks that have inverse assembler files for the HP 1630G and 1631D logic analyzers. These inverse assembler files are for the 68xx, 680xx, 80xx, 80xxx microprocessors common in older electronics. Around the late eighties to early nineties, the 8175A and 163xx logic analyzers were paired together as a "stimulus-response" system (for details, see pg 6 of the attached datasheet).

Since I don't have a 163xx logic analyzer I really don't know what to do with these disks; however, my inner archivist would like to back these up so someone else can have access to these likely hard to find files.

At first, I naively attempted to use my Windows PC to read the disks with a USB floppy drive. I quicky realized Windows can't read them. I then remembered that HP liked to use LIF rather than the more popular DOS format.

With the above in mind, I fired up my HP 89410A VSA, which has a floppy drive and FTP connectivity. I then connected to the instrument over the network and attempted to read the contents of the disks. Surprisingly, the disks could be read and the contents looked to be okay!

Now knowing that the disks are good, and actually have useful contents, I looked online for some software to create an image of the disks. Turns out Keysight still provides the MS-DOS LIFUTIL software for working with LIF disks (see Lifarc.zip attachment).

Using a Windows XP virtual machine and a USB floppy drive, I attempted to read the disks again. Unfortunately, I couldn't get the software and/or my floppy drive to work with these disks.

Is my floppy drive the problem here? Or should I use another utility to save the contents?
« Last Edit: March 20, 2022, 11:20:52 pm by garrettm »
 

Offline Halcyon

  • Global Moderator
  • *****
  • Posts: 5760
  • Country: au
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #1 on: March 01, 2022, 01:56:19 am »
For archival/data recovery, I use the KryoFlux device. https://kryoflux.com/?page=kf_features

The LIFUTIL should work, maybe you need an older machine to run it? I've never used it.

 

Offline garrettmTopic starter

  • Frequent Contributor
  • **
  • Posts: 267
  • Country: us
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #2 on: March 01, 2022, 02:47:06 am »
Hi Halcyon,

I would prefer not buying anything extra if I can help it. The 89410A can read the disks, but when I attempt to copy the contents to my PC over FTP I get "No CSI structure available" during transfer... I assume this has to do with the disk being in LIF format?

Does anyone know how to get the files over FTP?

I have an older PC with XP and a "normal" 3.5 inch floppy drive I can try with LIFUTIL. I'm starting to think my USB floppy drive is the problem.
« Last Edit: March 01, 2022, 04:02:34 am by garrettm »
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8331
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #3 on: March 01, 2022, 04:01:09 am »
Yes, the controller on USB floppy drives might not be tolerant of anything much beyond the standard IBM PC formats. A "real" (i.e 765-compatible) controller in a PC should work.
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #4 on: March 01, 2022, 08:03:18 am »
I would try this way

Using dd to dump a raw bit image..
And after analysis... may be copyqm driver can read it... freedos can do the trick and load the TSR if not possible to do it any other way

Paul
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #5 on: March 01, 2022, 02:21:02 pm »
Actually i made a review of (now defunct) SYDEX tools..

It seems a piece of cake ...

Get yourself a fully functional QEMU distro with floppy base raw images available
floppy imgs are regular images defined under QEMU settings...
It can boot reformat and make **ANYTHING** just as a regular floppy
the hardware is just brilliant emulated..

Fire your preferred DOS or winXXX  under QEMU and directly handle you image just like it would..
I made myself SEVERAL SAVINGS from old stuff this way...

Including CP/M formats and COPYQM extended formats...
yes it can load TSRs as well..

Paul


PS> for the sake of completion.. creating a raw floppy where you can put your stuff

dd if=/dev/zero  of=floppy.raw bs=1440k count=1 status=progress
or
dd if=/dev/zero  of=floppy.raw bs=2880k count=1 status=progress

where typical hardware limits would be 1474560 to max 2949120 bytes
from a classic CP/M to an enhanced double-density floppy

it is also possible to retrieveparticular sectors (like boot sector) from your disks..
just using dd properly...

this way get yourself a raw image of your disks and get them out these formats..

and ditch DOS MS and all that
« Last Edit: March 01, 2022, 02:41:50 pm by PKTKS »
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2171
  • Country: us
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #6 on: March 01, 2022, 03:59:02 pm »
HP used a different low-level format on their floppies.  "fdio.exe" is probably what you need.  Please read here:

  https://www.eevblog.com/forum/testgear/searching-for-a-hp-1630-hp-1631-inverse-assembler-files/msg2119792/#msg2119792

I have a 3.5" HP LIF formatted disk I was never able to read on Linux using dd or any other method.  I was able to finally get the data off it with access to an HP-UX system (a 16702B logic analyzer mainframe).
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #7 on: March 01, 2022, 04:16:36 pm »
Just load FDREAD from excellent FDFORMAT  applet...

It can read custom formats transparently for any program once configured...

FreeDOS  will do the trick natively loading the configured TSR.

dd will not require anything like that.. will dump a raw image..
which in turn will require that to be used by the DOS applet..

Code: [Select]
FDFORMAT - Format Disks with higher Capacity

SYSTEM REQUIREMENTS
-------------------

IBM or compatible Computer
DOS 3.20 or above

FEATURES OF FDFORMAT
--------------------

FDFORMAT is a replacement for the DOS-Format program, which has the
following advantages:

1) Supporting 3«"-1.44 MB drives with any BIOS-Versions in ATs and
   Clones. This saves you a lot of money, you would need for a new
   BIOS-Version.
2) Formatting and using of 720/820 kByte disks in AT 5¬"-1.2 MByte
   Drives using cheap double-density (DD) disks.
3) Increasing the capacity of your disks up to 300 kByte additional
   storage.
4) Supporting 3«"-360 kByte format. This is useful, when you want to
   make copies of 5¬"-disks to 3«"-Disks using DISKCOPY
5) Enhance speed of your diskette I/O up to 100% with sector sliding.
   This is a method of physical ordering sectors in a  way, that your
   drive is ready to read the next logical sector, when your head
   advances one track.
6) Improved BOOT-Sector, which automatically boots from harddisk, if
   the diskette in drive A: is not a system disk. This allows you to
   leave the diskette in drive A:, when you reboot the system.


OPTIONS USED IN FDFORMAT
------------------------

The most important option is the F-Option. The F-Option determines the
general Format, which is used for the target diskette.

The following table shows, which parameters are allowed for the F-
Options and for which type of Disk-Drive:

F-Opt Format          360k-Drive 720k-Drive 1.2M-Drive 1.44M-Drive
----- --------------- ---------- ---------- ---------- -----------
F160  160 kByte Disk  yes        FDREAD     yes        FDREAD
F180  180 kByte Disk  yes        FDREAD     yes        FDREAD
F200  200 kByte Disk  FDREAD     FDREAD     FDREAD     FDREAD
F205  205 kByte Disk  FDREAD     FDREAD     FDREAD     FDREAD
F320  320 kByte Disk  yes        FDREAD     yes        FDREAD
F360  360 kByte Disk  yes        FDREAD     yes        FDREAD
F400  400 kByte Disk  FDREAD     FDREAD     FDREAD     FDREAD
F410  410 kByte Disk  FDREAD     FDREAD     FDREAD     FDREAD
F720  720 kByte Disk  no         yes        FDREAD     yes
F800  800 kByte Disk  no         FDREAD     FDREAD     FDREAD
F820  820 kByte Disk  no         FDREAD     FDREAD     FDREAD
F120  1.2 MByte Disk  no         no         yes        yes
F12   1.2 MByte Disk  no         no         yes        yes
F144  1.44 MByte Disk no         no         FDREAD     yes
F14   1.44 MByte Disk no         no         FDREAD     yes
F148  1.48 MByte Disk no         no         FDREAD     yes
F16   1.6 MByte Disk  no         no         no         FDREAD
F164  1.64 MByte Disk no         no         no         FDREAD
F168  1.68 MByte Disk no         no         no         FDREAD
F172  1.72 MByte Disk no         no         no         FDREAD

FDREAD in the above table means, that this format will work only, if
FDREAD (or FDR88) is installed. You may find out, that this table will
not be valid for your table and that you can use certain diskette
formats without FDREAD (or FDR88), that are listed to work with FDREAD
(or FDR88) only.

The other options are:

1    : Format single sided Disk (provided for DOS-FORMAT
       compatibility).
4    : Format Standard 360 kByte Disk (provided for DOS-FORMAT
       compatibility).
8    : Format 8 sector Disk (provided for DOS-FORMAT compatibility).
A    : Use BIOS-Calls only to switch to different diskette types.
Bnnn : Use Disk-Type Byte nnn (for use with older BIOS Versions).
Cnnn : Use nnn Sectors per Cluster (nnn = 1 or 2).
Dnnn : Use nnn Root-Directory-Entries (nnn = 1-224).
Gnnn : Use Gap-Length of nnn (for use by experts only).
Hnnn : Use nnn heads (nnn = 1 or 2).
Innn : Use an Interleave of nnn (for use by experts only).
K    : Do not wait for any keyboard input, when starting FDFORMAT.
       (Useful, when starting FDFORMAT from batch files).
Mnnn : Use Media Byte nnn (Useful for ATARI formats).
Mnnn : Use Media-Descriptor-Byte nnn. (Useful when formatting ATARI ST
       disks).
Nnnn : Use nnn Sectors.
O    : Format 720 kByte disk for use with AT&T/Olivetti M24/M28.
Q    : Quick Format. Only rewrite the System-Area.
R    : Do not verify disk (and save 33% time).
S    : Make System-Disk.
Snnn : Use nnn Sectors.
Tnnn : Use nnn Tracks.
U    : Unconditionally format the diskette.
V    : Write Label to Disk.
W    : Format with erase. Physically reformat diskette without data
       loss
Xnnn : Slide nnn Sectors, when head changes.
Ynnn : Slide nnn Sectors nnn, when track changes.

Examples:

FDFORMAT A: /4                                    (format 360 kB disk)
FDFORMAT A: /F:1.72                              (format 1.72 MB disk)
FDFORMAT A: /T:80 /N:9                            (format 720 kB disk)
FDFORMAT A: /O                    (format 720 kB disk for AT&T M24/28)
FDFORMAT A: /F:720 M$F7 B$54         (format 720 kB disk for ATARI ST)
FDFORMAT A: /F:12 D64                (format 1.2 MB disk with 64 RDEs)
FDFORMAT A: /F:410 R               (format 410 kB Disk without verify)



Abandonia or other legacy forums have plenty...  ::)

Paul
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2171
  • Country: us
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #8 on: March 01, 2022, 04:56:38 pm »
...
dd will not require anything like that.. will dump a raw image..
which in turn will require that to be used by the DOS applet..
...
The Linux floppy driver does not know how to read these 256 bytes/sector disks, regardless of LIF, DOS, or other higher level format.  dd will not work.  Please refer to posted link.

I don't know about FDREAD.  I don't see an option for bytes/sector.
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #9 on: March 01, 2022, 05:27:32 pm »
i never tried to do anything on LINUX really beyond the plain safe 1.44 format.

And even these disks were really a problem because the way the kernel handle the disks is too much picky and it does not accept minimum problems... leading to the classic sector read loop.. which is less likely to happen only in pristine hardware and new disks...  :-\

BUT. I succeeded using  both.. DD , under a good CYGWIN install, and FDREAD to read all those nasty old formats ... usually FDREAD was smart enough to track sectors..
and the results were very good ..

For the time ... and a lot of time passed .. I saved all my stuff and ditched whole thing...
Under CYGWIN if I remember correctly early win2ks ..  ::)

At the time even the cygwin xserver was rough but functional but all GNU tools were very good.

I would risk a try hoping for the better..
Note that the TSR intercepts INT13H and the BIOS no longer access the flops.
So chances are good on  a real hardware even with alien formats..

On QEMU emulated I have no idea .. but all supported formats worked fine for me.

Best shot I had and worked... saved a lot of stuff and ditched the disks.
I have all the images just fine ..

Only problem with FDREAD is that no BOOT is possible once it is a TSR....  :o

The mileage will vary...

Paul
« Last Edit: March 02, 2022, 12:38:38 pm by PKTKS »
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #10 on: March 01, 2022, 05:42:00 pm »
ALAS.... I remembered..  that I started to save my flops to images...
just BEFORE the win2k changes...

Just when I was ready to deploy all linux machines and got rid of MS...
So I started that on some 98 machines which still happens to had the config.sys autoexec.bat handy tools.. and when I was about to finish i had some problems in 2k machines...

They dropped the crucial configuration delegating the boot to some sort of systemd .. no longer true intercepting the BIOS properly...

in other words they decided to deprecate real  mode BIOS

Nevertheless I succeed 100% and ditched the whole MS panacea..

and moved on
Paul  :-+
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2171
  • Country: us
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #11 on: March 01, 2022, 07:03:02 pm »
garrettm (OP): If there's nothing further that you want with the disks, I have the means to read them and I can post the contents to the HP 1630/1631 thread that I posted above.  Although I no longer have my 1631D (gave it away to another eevblog member), these disassemblers may still come in handy for others.

If you're inclined to do so, you can drop them in a padded envelope and send them to me via US snail mail.  Please PM me if interested.
 
The following users thanked this post: garrettm

Offline garrettmTopic starter

  • Frequent Contributor
  • **
  • Posts: 267
  • Country: us
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #12 on: March 01, 2022, 10:16:46 pm »
Hi Mark,

I may end up doing that. But I like the challenge of trying to get the data off, and from what I have read, it should be possible with lifutil on an older XP/Win9x machine, though I may need to boot into a DOS environment first.

https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=24

Quote
[regarding lifutil sw] This is a super software product that will allow you to read and write to a LIF disk from your DOS computer. Despite what HP says about it, it has worked fine for me on Intel 486 and Pentium Processors.

An alternative to lifutil (for making the disk image) is teledisk.exe that runs under DOS. Though it uses a custom image format which is incompatible with lifutil.

https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv015.cgi?read=79389

If that fails, I may give lif_utils a try under linux. (while testing, though, I did get some compiler error messages when making lif_utils...)

http://www.hpcc.org/datafile/hpil/lif_utils.html


PKTKS,

I appreciate your help, but I'd like to try and stick with "known" working methods (lifutil (win9x/dos), teledisk (dos), lif_utils (linux), etc.). I'd rather not spend hours learning to use something that hasn't been proven to work with LIF disks. And if I can't get those to work, I'll just send the disks to Mark since he has a working setup to archive the files and get them to people who can actually use them.

I should emphasize (for anyone reading this thread) I'm not archiving these disks for myself. I just want to get the files off so people who actually own a 163xx series logic analyzer can use them.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2171
  • Country: us
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #13 on: March 02, 2022, 12:45:47 am »
Hi Mark,

I may end up doing that. But I like the challenge of trying to get the data off, and from what I have read, it should be possible with lifutil on an older XP/Win9x machine, though I may need to boot into a DOS environment first.
...
Ok, good luck and please let us know what works!

I agree that an old system with a floppy drive directly connected is the best shot.  The utility may need to try different sector sizes and it will need direct access to the controller to do that.  If on XP, fdio has a special driver to deal with controller access.

Linux can't read a floppy that's anything other than 512 bytes/sector.  I've tried many times in the past, and verified again today with a LIF floppy from 1987.  (And still reads fine on HP-UX after 35 years.)  Maybe there's a magic ioctl() to do it, but I haven't found it.

If of any use, here are the low-level formats understood in the old HP universe:

      The following table shows some useful flexible disk media geometries
      (without density information).  The right-most column indicates which
      mediainit -f option should be used to format media to the indicated
      geometry (see mediainit(1M)).

      +--------------+----------+-----------+----+-----+------+------+----+
      | Media Type   |   Use    |  Capacity | hd | trk | sect | size | -f |
      +--------------+----------+-----------+----+-----+------+------+----+
      | 3.5in DS DD  |          |   630,784 |  2 |  77 |  16  |  256 |  1 |
      | 3.5in DS DD  |          |   655,360 |  2 |  80 |  16  |  256 | 21 |
      | 3.5in DS DD  |          |   655,360 |  2 |  80 |   8  |  512 | 26 |
      | 3.5in DS DD  |          |   709,632 |  2 |  77 |   9  |  512 |  2 |
      | 3.5in DS DD  | DOS 720K |   737,280 |  2 |  80 |   9  |  512 | 16 |
      | 3.5in DS DD  |          |   788,480 |  2 |  77 |   5  | 1024 |  3 |
      +--------------+----------+-----------+----+-----+------+------+----+
      | 3.5in DS HD' | DOS 1.2M | 1,228,800 |  2 |  80 |  15  |  512 | 26 |
      | 3.5in DS HD' |          | 1,261,568 |  2 |  77 |   8  | 1024 | 22 |
      +--------------+----------+-----------+----+-----+------+------+----+
      | 3.5in DS HD  |          | 1,261,568 |  2 |  77 |  32  |  256 |  1 |
      | 3.5in DS HD  |          | 1,419,264 |  2 |  77 |  18  |  512 |  2 |
      | 3.5in DS HD  | DOS 1.44M| 1,474,560 |  2 |  80 |  18  |  512 | 16 |
      | 3.5in DS HD  |          | 1,567,960 |  2 |  77 |  10  | 1024 |  3 |
      | 3.5in DS HD  |          | 1,638,400 |  2 |  80 |  10  | 1024 | 23 |
      +--------------+----------+-----------+----+-----+------+------+----+
      | 5.25in DS    | DOS 360K |   368,640 |  2 |  40 |   9  |  512 |  2 |
      | 5.25in DS DD |          |   655,360 |  2 |  80 |   8  |  512 | 26 |
      | 5.25in DS HD | DOS 1.2M | 1,228,800 |  2 |  80 |  15  |  512 | 16 |
      | 5.25in DS HD |          | 1,261,568 |  2 |  77 |   8  | 1024 | 24 |
      +--------------+----------+-----------+----+-----+------+------+----+

A LIF file system could ride on top of any of these combinations.

The fdio web site has a huge amount of info on the various floppy low-level formats (http://www.hp9845.net/9845/projects/fdio/).  If you get stuck, fdio also has an analysis option where it will tell you everything about the floppy (-analyze).
 
The following users thanked this post: garrettm

Offline garrettmTopic starter

  • Frequent Contributor
  • **
  • Posts: 267
  • Country: us
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #14 on: March 02, 2022, 02:46:09 am »
Oh wow, that hp9845 project site is a treasure trove of information! I need to read through all the documentation, but it looks like HPDir can work with normal 3.5in floppy drives on Windows (not just vintage HPIB/GPIB floppy drives). That could be a real time saver since I have a Windows based Pentium III logic analyzer that should make this easy (we'll see!).

I have no doubt that the default Linux tools won't work with LIF disks. That said, have you ever tried the lif_utils from hpcc.org? Dispite the similarity in naming (and version!), these tools are completely separate from HP's lifutil. I'd be curious if lif_utils would work for the diehard Linux folks.

I had no idea there were so many awesome projects out there to support these old formats! Just need to see if I can get any of them to work with what I have on hand...
« Last Edit: March 02, 2022, 11:56:10 pm by garrettm »
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #15 on: March 02, 2022, 08:23:04 am »
Ok... i dont do flops anymore - real hardware  ones for a looong time...

But all images saved work fine under qemu.

In case you need those classic bios tools drop me a pm.. we can arrange... you get them

Paul
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #16 on: March 02, 2022, 09:51:08 am »

If of any use, here are the low-level formats understood in the old HP universe:
(..)

BTW judging by overlooking this table..
If you see the FDFORMAT capacity table (and customizable formats)....

FDREAD It should be able to read some...
the TSR is very smart and can read anything customized by FDFORMAT..
so...

Paul
« Last Edit: March 02, 2022, 10:10:01 am by PKTKS »
 

Offline garrettmTopic starter

  • Frequent Contributor
  • **
  • Posts: 267
  • Country: us
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #17 on: March 02, 2022, 02:24:38 pm »
So it worked! I have the inverse assembler files from the disks and did a hex comparison between all common files with no differences except for a single file that couldn't be fully read. Ironically, the data for this file is missing in the middle, but the start and end match the file on the other disk, so I'm fairly sure the other copy is good. With that in mind, I feel confident about sharing what I've recovered from the disks.

I ended up using my TLA5202B as a Windows 7 machine with a normal 3.5in floppy connected to the "new" motherboard (D946GZIS) I installed with a E7300 core 2 duo (better than the old P4 Celeron D!). I used this system since it was already pulled apart and ready to go. No need for Linux, DOS, Win9x or even XP. That said, you do need an older computer that still has a floppy connector since the software needs to access the controller directly (i.e., can't be done through USB, FireWire, etc.).

It took some figuring out but hpdir and fdio (in tandem with fdrawcmd by Simon Owen) are great tools to have for reading old disks. The hpdir plugins for Total Commander make reading LIF disks on modern Windows installations trivial. That said, I still did everything via command line with hpdir and fdio as I like to see all the details of each transaction--which became very important because each disk had bad areas that did and did not affect recovering the contents of each disk!

The L1631D disk had read errors starting at record 256, but the actual files were stored between records 10 and 252 so this had no effect on recovering the stored data. Pretty lucky if you ask me.

Code: [Select]
L1631D

C:\Users\TLA\Desktop\Hpdir>hpdir -info 0:
Info:  FDC sense: Windows NT/2000/XP/VISTA/Windows7 detected
Info:  FDC sense: National controller detected
Info:  FDC get drives: drive 0 = DS/HD 3.5" (1440k)
Info:  FDC get drives: drive 1 = not installed
Info:  FDC get drives: drive 2 = not installed
Info:  FDC get drives: drive 3 = not installed
Info:  FDC autodetect: LIF 3.5 SS/DD found.
-- Floppy drive info --
Media type: LIF 3.5 SS/DD
Media capacity: 280 bytes
Number of cylinders: 70
Number of heads: 1
Sectors per track: 16
Sector size: 256

Info:  No valid cylinder/head/sector data in system record, using device data

-- File system info --
Image format: Logical Interchange Format (LIF) id=$1000 version=0
Image size: 286720 bytes
Volume label: "L1631D"
Creation date & time:
Sectors per track: 16
Number of heads or surfaces: 1
Total number of user accessable tracks: 70
Total number of user accessable records: 1120
System area starts at record #0
Directory starts at record #2
Directory size: 8 records
File area starts at record #10
Total number of system tracks: 1
Total number of usable data tracks: 69

213504 bytes of 282624 free.


C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -list 0:
0:
VOLUME LABEL: L1631D
FILE NAME PRO TYPE  REC/FILE BYTE/REC   ADDRESS     DATE     TIME

COPYFILEx     #fffe       28      256        10    21-Dec-84 10:24
I68000I3i     #fffe       17      256        38    13-Jun-84  8:40
I68000I8i     #fffe       17      256        55    13-Jun-84  8:41
I68000P3i     #fffe       17      256        72    13-Jun-84  8:43
I68000P8i     #fffe       17      256        89    13-Jun-84  8:45
I6800Ii       #fffe       14      256       106    13-Jun-84  7:45
I6800Pi       #fffe       14      256       120    13-Jun-84  7:46
I6809EPi      #fffe       21      256       134    13-Jun-84  8:11
I6809Pi       #fffe       21      256       155    13-Jun-84  8:15
I6809Ii       #fffe       21      256       176
I68008Ii      #fffe       18      256       197
I68008Pi      #fffe       17      256       215
SATCOM1c      #fffe       21      256       232

213504 of 282624 bytes free.


C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -dup 0: L1631D.hpi
Warning: Read error at record 256 (ignored)
Warning: Read error at record 257 (ignored)
Warning: Read error at record 258 (ignored)
Warning: Read error at record 259 (ignored)
Warning: Read error at record 260 (ignored)
Warning: Read error at record 261 (ignored)
Warning: Read error at record 262 (ignored)
Warning: Read error at record 263 (ignored)
Warning: Read error at record 264 (ignored)
Warning: Read error at record 265 (ignored)
Warning: Read error at record 266 (ignored)
Warning: Read error at record 267 (ignored)
Warning: Read error at record 268 (ignored)
Warning: Read error at record 269 (ignored)
Warning: Read error at record 270 (ignored)
Warning: Read error at record 271 (ignored)
Warning: Read error at record 272 (ignored)
Warning: Read error at record 273 (ignored)
Warning: Read error at record 274 (ignored)
Warning: Read error at record 275 (ignored)
Warning: Read error at record 276 (ignored)
Warning: Read error at record 277 (ignored)
Warning: Read error at record 278 (ignored)
Warning: Read error at record 279 (ignored)
Warning: Read error at record 280 (ignored)
Record 1119 (100%)


C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: COPYFILEx
Extracting COPYFILEx

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I68000I3i
Extracting I68000I3i

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I68000I8i
Extracting I68000I8i

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I68000P3i
Extracting I68000P3i

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I68000P8i
Extracting I68000P8i

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I6800Ii
Extracting I6800Ii

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I6800Pi
Extracting I6800Pi

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I6809EPi
Extracting I6809EPi

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I6809Pi
Extracting I6809Pi

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I6809Ii
Extracting I6809Ii

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I68008Ii
Extracting I68008Ii

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I68008Pi
Extracting I68008Pi

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: SATCOM1c
Extracting SATCOM1c


Code: [Select]
L1631D

C:\Users\TLA\Desktop\fdio-22>fdio -info a:
Medium in drive a: looks like LIF 3.5 SS/DD (280 kBytes)

Media id:      LIF 3.5 SS/DD
Form factor:   3.5"
Track density: high
Capacity:      280 kBytes
Cylinders:     70
Heads:         1
Sectors:       16
Blocks:        1120
Start sector:  0
Sector size:   256
Data rate:     250 kBytes/s
R/W gap3:      32
Format gap3:   50
Interleave:    2:1
Head skew:     0
Cylinder skew: 2
Modulation:    MFM

Note that these values only reflect the standard settings for this preset.
Use the -analyze function to get the characteristics of the current medium.


C:\Users\TLA\Desktop\fdio-22>fdio -analyze a:
Analyzing disc
FDC analyze: --- testing sector geometry for side 0 ---
FDC analyze: testing modulation & data rate...OK
FDC analyze: testing sector size, start sector and sectors/track...OK
FDC analyze: testing interleave...OK
FDC analyze: testing intra-track consistancy...OK
FDC analyze: --- testing sector geometry for side 1 ---
FDC analyze: testing modulation & data rate...OK
FDC analyze: testing sector size, start sector and sectors/track...
FDC analyze: --- testing track geometry ---
FDC analyze: testing cylinders...
FDC analyze: testing track integrity & media density...OK
FDC analyze: testing cylinder skew...OK
FDC analyze: testing R/W GAP3...OK

Analysis summary:
-----------------
Rotational speed:  301 RPM
Form factor:       3.5"
Track density:     135 tpi (high density)
Capacity:          208896 bytes (204k)
Data rate:         250 kbit/s
Modulation:        MFM
Sector size:       256 bytes
First sector ID:   0
Sectors total:     816
Sectors per track: 16
Cylinders:         51
Heads:             1
Interleave:        2:1
Minimum R/W GAP3:  0 bytes (32 recommended)
Format GAP3:       43 bytes (50 recommended)
Cylinder skew:     10

Remarks:
- 1 unused tracks detected, maybe from previous formatting
- Tracks contain 1 extra sector(s) with junk data

Errors:
- Found 10 unreadable track(s) on side 0 (maybe spares)

Recommended preset data for fdc.ini:
0x10,1,204,51,1,16,816,0,256,2,0x20,0x32,0xdf,2,0,10,0x40


C:\Users\TLA\Desktop\hpdir_fdio>fdio -verify a:
Using presets from fdc.ini
Verifying disc
Verifying cylinder 69
Verify completed without errors.


C:\Users\TLA\Desktop\fdio-22>fdio -dup a: L1631D.hpi
Using presets from fdc.ini
Dumping disc to image
Error: Disc read failed (abnormal termination /data error /data error in data field)
Reading cylinder 69



The L1630G disk had two read errors at records 96 and 97. This affected the I68000I3i file stored between records 96 and 112. Thankfully, a copy of this file was also on the L1631D disk.

Code: [Select]
L1630G

C:\Users\TLA\Desktop\Hpdir>hpdir -info 0:
Info:  FDC sense: Windows NT/2000/XP/VISTA/Windows7 detected
Info:  FDC sense: National controller detected
Info:  FDC get drives: drive 0 = DS/HD 3.5" (1440k)
Info:  FDC get drives: drive 1 = not installed
Info:  FDC get drives: drive 2 = not installed
Info:  FDC get drives: drive 3 = not installed
Info:  FDC autodetect: LIF 3.5 SS/DD found.
-- Floppy drive info --
Media type: LIF 3.5 SS/DD
Media capacity: 280 bytes
Number of cylinders: 70
Number of heads: 1
Sectors per track: 16
Sector size: 256

Info:  No valid cylinder/head/sector data in system record, using device data

-- File system info --
Image format: Logical Interchange Format (LIF) id=$1000 version=0
Image size: 286720 bytes
Volume label: "L1630G"
Creation date & time:
Sectors per track: 16
Number of heads or surfaces: 1
Total number of user accessable tracks: 70
Total number of user accessable records: 1120
System area starts at record #0
Directory starts at record #2
Directory size: 8 records
File area starts at record #10
Total number of system tracks: 1
Total number of usable data tracks: 69

162048 bytes of 282624 free.

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -list 0:
0:
VOLUME LABEL: L1630G
FILE NAME PRO TYPE  REC/FILE BYTE/REC   ADDRESS     DATE     TIME

SETUP02c      #fffe       22      256        10
SETUP02Ac     #fffe       22      256        32    29-Oct-84 13:38
I6809EPi      #fffe       21      256        54    13-Jun-84  8:11
I6809Ii       #fffe       21      256        75    13-Jun-84  8:06
I68000I3i     #fffe       17      256        96    13-Jun-84  8:27
I68000I8i     #fffe       17      256       113    13-Jun-84  8:28
I68000P3i     #fffe       17      256       130    13-Jun-84  8:32
I68000P8i     #fffe       17      256       147    13-Jun-84  8:34
I6800Ii       #fffe       14      256       164    13-Jun-84  7:45
I6800Pi       #fffe       14      256       178    13-Jun-84  7:46
I6809Pi       #fffe       21      256       192    13-Jun-84  8:15
COPYFILEx     #fffe       27      256       213    13-Jun-84  8:22
I8086Ii       #fffe       22      256       240
I8088Ii       #fffe       22      256       262
I80186Ii      #fffe       23      256       284
I80186IEi     #fffe       24      256       307
I80188IEi     #fffe       24      256       331
I80188Ii      #fffe       24      256       355
I80286Ii      #fffe       24      256       379
I6809Ic       #fffe       22      256       403
SETUP03JOc    #fffe       21      256       425
SETUP03JOs    #fffe       17      256       446
SETUP03JOt    #fffe        9      256       463
SETUP03JOa    #fffe        9      256       472

162048 of 282624 bytes free.

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -dup 0: 1630G.hpi
Warning: Read error at record 96 (ignored)
Warning: Read error at record 97 (ignored)
Record 1119 (100%)

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: SETUP02c
Extracting SETUP02c

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: SETUP02Ac
Extracting SETUP02Ac

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I6809EPi
Extracting I6809EPi

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I6809Ii
Extracting I6809Ii

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I68000I3i
Extracting I68000I3i
Error: Disc read failed (drive 0 at cylinder 6)

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I68000I8i
Extracting I68000I8i

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I68000P3i
Extracting I68000P3i

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I68000P8i
Extracting I68000P8i

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I6800Ii
Extracting I6800Ii

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I6800Pi
Extracting I6800Pi

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I6809Pi
Extracting I6809Pi

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: COPYFILEx
Extracting COPYFILEx

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I8086Ii
Extracting I8086Ii

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I8088Ii
Extracting I8088Ii

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I80186Ii
Extracting I80186Ii

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I80186IEi
Extracting I80186IEi

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I80188IEi
Extracting I80188IEi

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I80188Ii
Extracting I80188Ii

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I80286Ii
Extracting I80286Ii

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: I6809Ic
Extracting I6809Ic

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: SETUP03JOc
Extracting SETUP03JOc

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: SETUP03JOs
Extracting SETUP03JOs

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: SETUP03JOt
Extracting SETUP03JOt

C:\Users\TLA\Desktop\Hpdir>hpdir -s 1000 -extract -c 0: SETUP03JOa
Extracting SETUP03JOa


Code: [Select]
L1630G

C:\Users\TLA\Desktop\fdio-22>fdio -info a:
Medium in drive a: looks like LIF 3.5 SS/DD (280 kBytes)

Media id:      LIF 3.5 SS/DD
Form factor:   3.5"
Track density: high
Capacity:      280 kBytes
Cylinders:     70
Heads:         1
Sectors:       16
Blocks:        1120
Start sector:  0
Sector size:   256
Data rate:     250 kBytes/s
R/W gap3:      32
Format gap3:   50
Interleave:    2:1
Head skew:     0
Cylinder skew: 2
Modulation:    MFM

Note that these values only reflect the standard settings for this preset.
Use the -analyze function to get the characteristics of the current medium.


C:\Users\TLA\Desktop\fdio-22>fdio -analyze a:
Analyzing disc
FDC analyze: --- testing sector geometry for side 0 ---
FDC analyze: testing modulation & data rate...OK
FDC analyze: testing sector size, start sector and sectors/track...OK
FDC analyze: testing interleave...OK
FDC analyze: testing intra-track consistancy...OK
FDC analyze: --- testing sector geometry for side 1 ---
FDC analyze: testing modulation & data rate...OK
FDC analyze: testing sector size, start sector and sectors/track...
FDC analyze: --- testing track geometry ---
FDC analyze: testing cylinders...
FDC analyze: testing track integrity & media density...OK
FDC analyze: testing cylinder skew...OK
FDC analyze: testing R/W GAP3...OK

Analysis summary:
-----------------
Rotational speed:  301 RPM
Form factor:       3.5"
Track density:     135 tpi (high density)
Capacity:          77824 bytes (76k)
Data rate:         250 kbit/s
Modulation:        MFM
Sector size:       256 bytes
First sector ID:   0
Sectors total:     304
Sectors per track: 16
Cylinders:         19
Heads:             1
Interleave:        2:1
Minimum R/W GAP3:  0 bytes (32 recommended)
Format GAP3:       43 bytes (50 recommended)
Cylinder skew:     10

Remarks:
- 2 unused tracks detected, maybe from previous formatting
- Tracks contain 1 extra sector(s) with junk data

Errors:
- Found 10 unreadable track(s) on side 0 (maybe spares)

Recommended preset data for fdc.ini:
0x10,1,76,19,1,16,304,0,256,2,0x20,0x32,0xdf,2,0,10,0x40


C:\Users\TLA\Desktop\hpdir_fdio>fdio -verify a:
Using presets from fdc.ini
Verifying disc
Error: Disc verify failed (drive 0 cylinder 0 head 0)
Error: Disc verify failed (drive 0 cylinder 6 head 0)
Verifying cylinder 69
Verify completed without errors.


C:\Users\TLA\Desktop\fdio-22>fdio -dup a: L1630G.hpi
Using presets from fdc.ini
Dumping disc to image
Error: Disc read failed (abnormal termination /data error /data error in data field)
Reading cylinder 69


I ended up preferring fdio for making the disk images since it has configurable reading presets (such as cylinder skew) that can be fine-tuned using analyze. If you compare images made using fdio and hpdir there will be some minor differences, but a hex comparison of the extracted files was the same. Of note, fdio will attempt to read bad files, which can be useful, while hpdir gives up as soon as an error occurs.

The HP163xx zip has the combined inverse asembler files and is likely what you want.

The LIF Disks zip has the archived disk images, hpdir and fdio logs and extracted/converted (LIF to DOS) files from the images for anyone who wants to double check my work.
« Last Edit: March 20, 2022, 11:11:05 pm by garrettm »
 
The following users thanked this post: oPossum, MarkL

Online MarkL

  • Supporter
  • ****
  • Posts: 2171
  • Country: us
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #18 on: March 02, 2022, 04:00:34 pm »
...
I have no doubt that the default Linux tools won't work with LIF disks. That said, have you ever tried the lif_utils from hpcc.org? Dispite the similarity in naming (and version!), these tools are completely separate from HP's lifutil. I'd be curious if lif_utils would work for the diehard Linux folks.
...
I tried the utilities at hpcc.org in the past, and to make sure I tried it again just now.  The code does appear to have a few ioctl() calls that try to set the disk geometry, but all attempts fail on my system (a very old Fedora 11 system, but appropriately aged for this task and that old code).  I remember burning a lot of time on this years ago, and I seem to be doing it again.  I don't like giving up, but I think a more pragmatic approach is unfortunately non-linux.

If you or anyone gets it working on linux with these 256 byte/sector disks, please post.  I'd love to know.

At any rate, I'm glad you got the disks read!  Thanks for posting the procedure and the bits!
 

Offline m k

  • Super Contributor
  • ***
  • Posts: 2226
  • Country: fi
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #19 on: March 02, 2022, 06:40:40 pm »
There really doesn't seem to be a Linux solution.
That's a pity, it should be the last one to fail.

BIOS INT 13h Format Track(AH=05h) has bytes/sector as 0=128, 1=256, 2=512 and 3=1024.
So it should be possible.

But here your best buddy is obviously the old and famous Commodore Amiga.
It can read anything and everything the drive can physically read.
It reads from index to index and does the rest with software.
Equal writing is not possible, it's a copy protection.
Advance-Aneng-Appa-AVO-Beckman-Danbridge-Data Tech-Fluke-General Radio-H. W. Sullivan-Heathkit-HP-Kaise-Kyoritsu-Leeds & Northrup-Mastech-REO-Simpson-Sinclair-Tektronix-Tokyo Rikosha-Topward-Triplett-YFE
(plus lesser brands from the work shop of the world)
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2171
  • Country: us
Re: Archiving LIF formatted 3.5 inch Disk
« Reply #20 on: March 03, 2022, 07:52:40 pm »
Ok, here's how to read these 256 byte/sector floppy disks on linux.

First, there appears to be a bug with lifutils, and I'm going to guess it's with later versions of linux since it's reasonable to assume that lifutils worked when it was written.  lifutils works fine when dealing with floppy image files.  It just can't deal with the floppy controller directly.

The problem I tried to solve was reading the physical floppy media and getting it into an image file.

The LIF disk I've been using has the following characteristics (courtesy of the FLOPPY_GET_GEOMETRY ioctl() in HP-UX):

            heads:  2
           tracks:  77
          sectors:  16
      sector_size:  256
    transfer_rate:  250
    track_density:  135
    data_encoding:  2
         capacity:  630784

You will need the linux fdutils package which has fdrawcmd.  This allows you to talk directly to the floppy controller.

The only thing I could get to work, eventually, was the "read" command in fdrawcmd, which will read data from the floppy and send it to stdout.  Fortunately, fdrawcmd is a friendly program and if you ask it to read more than a sector of data, it will increment the sector count and head selection to read out the number of bytes you specify up to a full cylinder.  A short loop to increment the cylinder and seek to that track before each read is all that is needed to read the whole disk.

This snippet of code will put a LIF floppy disk image in "fd.img" (using bash):
Code: [Select]
rm fd.img
for ((cyl = 0; cyl < 77; cyl++)); do
  echo "reading cylinder $cyl..."
  fdrawcmd rate=2 seek 0 $cyl
  fdrawcmd rate=2 length=8192 read 0 $cyl 0 1  1 16 32 0xff >> fd.img
done
For the magic parameters on the "read" command, see the fdrawcmd man page.  fdrawcmd prints the three controller registers and other status data each time it completes a request.  To understand the bits in the registers, you will need to consult the Intel 82078 floppy controller manual.  But in short, you need to know that anything other than 0 in the high order nibble of register 0 is an error.

Here are more details on the lifutils failure if anyone wants to continue to dig:

lifutils first fails in lif_phy.c when it is trying to do FD_RECALIBRATE via a raw ioctl() to the floppy controller.  Perhaps additional fields need to be set in the ioctl() data structure in later versions of linux.  Commenting out the recalibrate and doing it manually via fdrawcmd still does not allow lifutils to work, so there may be some consistent error that's being made in other ioctl() calls.  (I gave up here.)

I only ever had one LIF disk I've been trying to read for years.  From garrettm's analysis logs from fdio, those 1630/1631 disks have a different geometry from mine.  So, some tweaking to the above fdrawcmd parameters will be needed.  The main stumbling block was (and always has been) the sector size, at least in my experience.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf