Threaded Mode | Linear Mode

Dave Frederickson · 05-15-2016, 06:51 PM

It looks like there are two corrupt files on the SS/80 Exerciser disc image from HPMuseum.net. Can anyone confirm this and/or have a good copy?

Dave

Martin Hepperle · (This post was last modified: 05-18-2016 11:35 AM by Martin Hepperle.)

(05-15-2016 06:51 PM)Dave Frederickson Wrote: It looks like there are two corrupt files on the SS/80 Exerciser disc image from HPMuseum.net. Can anyone confirm this and/or have a good copy?

Dave

Dave,
which exerciser do you mean? I think there are at least two (HP-85, HP-110, others?).
I tried the HP-85 version and unpacked the TD0 to a LIF image file. A CAT worked fine.

Code:

[ Volume ]:

Name        Type  Bytes   Recs

MANUAL      PROG    256    105

RW-TES      PROG    256    108

OPER        PROG    256    112

REVID       PROG    256    106

Autost      PROG    256     27

The first file (MANAUAL.PROG) came out fine. I can read and list the file on my HP-86 (using this machine because my HP-85 is not on my bench right now). The HP-86 translated the code properly. The remaining files did not load (even after waiting a long time for the translation).
Inspecting the image file shows that the directory entries of the remaining files point to wrong starting records and there seem to be errors in the program control blocks (e.g. wrong file sizes) and probably more in the actual PROGs. I have not yet tried to recreate the disk using TELEDISK, so these errors may be the result of converting the TD0 to the raw image file or they may be already in the TD0 image.

Martin

Dave Frederickson · 05-18-2016, 03:14 PM

Hi Martin,

I was referring to the 85 version. As many of these programs are recovered from tape I'm not surprised that some of the files are corrupt.

Dave

Martin Hepperle · 05-19-2016, 07:07 AM

Dave,

to complete my test I used Teledisk to create a 3.5" disk and was able to read the files "MANUAL", "REVID", and "Autost" — "RW-TES" and "OPER" cannot be read.
I also checked with HPs LIFUTILS HEX editor and it stops halfway in "RW-TES" saying "not a LIF formatted disk". There seems to be something wrong with the low level sector formatting in the TD0 file. Using the HP-86 to copy the created disk to another HP initialized disk copied maybe two tracks and then stopped with a "ERROR: DISC". I guess you obtained the same result.
One could try to patch the file length information in order to read up to the unreadable part, but that would only produce a partial program.

Maybe someone has a readable original copy of the "SS80 Exerciser" disc or tape?

Martin

magore · 07-24-2017, 05:39 AM

Track 11 has sector number 116 instead if sector 8 in the Teledisk image.

Dave Frederickson · 07-26-2017, 06:08 PM

(07-24-2017 05:39 AM)magore Wrote: Track 11 has sector number 116 instead if sector 8 in the Teledisk image.

If the image is edited, are there any more readable files?

magore · 07-28-2017, 01:37 AM

I now have the files on my github page: github.com/magore/hp85disk under the lif folder
I found two errors 1 on track 11 and another on track 13
On track 11 sector 8 was missing but instead there was a unique sector numbered 116
On track 13 sector 11 was missing but instead there was a unique sector numbered 116
I put a bit of code in my teledisk lif image converter code to translate the numbers.

On my github project site the folder lif contains linux versions stand alone tools to manage LIF and TELEDISK LIF images (They can be compiled under cygwin or gnu for windows, etc)

I have included a copy of 85-SS80.LIF - I still need to check it - but I think it explains the
problem. Perhaps the original file had an error that when teledisk was used to create the original. The 85-SS80.TD0 file had a sector 116 on track 11 and 13 while missing a sector - unfortunately there is no way to be sure why that sector number exists (for example a read error when the person saved the original?) What is clear is that in both cases there was a missing sector in the 16 sector sequence that could be filled in by assuming that sector 116 was the missing one.

Code:

./td02lif 85-SS80.TD0 85-SS80.LIF

TeleDisk image file 85-SS80.TD0

image:[85-SS80.TD0], size:[117642]

TeleDisk version: 21

TeleDisk Normal compression

TeleDisk date: 01/04/2008 12:47:51

TeleDisk Comment:[HP-85 S/W, SS/80 EXERCISER, 5010-0310/2537. DOES NOT INCLUDE THE SERVC F]

81 tracks, 2 side(s), sectors(17),bitrate:250000

LIF image size in sectors:474

LIF IMAGE Done

LIF image:[85-SS80.LIF] wrote:[474] used sectors

Volume:[<EMPTY>] Date:[<EMPTY>]

NAME         TYPE   START SECTOR        SIZE    RECSIZE   DATE

MANUAL      E020h            10h       26880        256   <EMPTY>

RW-TES      E020h            79h       27648        256   <EMPTY>

OPER        E020h            E5h       28672        256   <EMPTY>

REVID       E020h           155h       27136        256   <EMPTY>

Autost      E020h           1BFh        6912        256   <EMPTY>

       5 Files

       0 Purged

     458 Used sectors

       0 Free sectors

**rprosperi** · 07-28-2017, 09:34 PM

(07-28-2017 01:37 AM)magore Wrote: ...On my github project site the folder lif contains linux versions stand alone tools to manage LIF and TELEDISK LIF images (They can be compiled under cygwin or gnu for windows, etc)

Thanks for sharing this news Mike, seems like quite a useful set of tools.

If anyone reading this speaks Linux, git, and Windows, and could build Windows versions of Mikes new tools to share with the community, I think many (at least several!) folks here would be very appreciative. A general-purpose utility that can convert TD0 <==> LIF images would be very handy and save much time as compared to either dredging out the vintage PC, or using the multi-step procedures available with other conversion utilities.

Many (most) of the Series-80 disk images are available only in TD0 format, while new ways to consume those files (Everett's EMU85 and FDIO (to write LIF media) are good examples) depend on having LIF volumes.

Martin Hepperle · 07-31-2017, 11:41 AM

(07-28-2017 01:37 AM)magore Wrote: ...
On my github project site the folder lif contains linux versions stand alone tools to manage LIF and TELEDISK LIF images (They can be compiled under cygwin or gnu for windows, etc)
...

Code:

./td02lif 85-SS80.TD0 85-SS80.LIF TeleDisk image file 85-SS80.TD0 image:[85-SS80.TD0], size:[117642] TeleDisk version: 21 TeleDisk Normal compression TeleDisk date: 01/04/2008 12:47:51 TeleDisk Comment:[HP-85 S/W, SS/80 EXERCISER, 5010-0310/2537. DOES NOT INCLUDE THE SERVC F] 81 tracks, 2 side(s), sectors(17),bitrate:250000 LIF image size in sectors:474 LIF IMAGE Done LIF image:[85-SS80.LIF] wrote:[474] used sectors Volume:[<EMPTY>] Date:[<EMPTY>] NAME TYPE START SECTOR SIZE RECSIZE DATE MANUAL E020h 10h 26880 256 <EMPTY> RW-TES E020h 79h 27648 256 <EMPTY> OPER E020h E5h 28672 256 <EMPTY> REVID E020h 155h 27136 256 <EMPTY> Autost E020h 1BFh 6912 256 <EMPTY> 5 Files 0 Purged 458 Used sectors 0 Free sectors

I tried to compile the files with MINGW under Window 7/64. I had to revert the calls to time/date functions with "..._r" to the "unsafe" traditional ones and add a -DEFINE to the Makefile then I could compile the code.
At runtime my version aborts and shows a memory exception in Windows. The output file xx.lif is identical to the one provided on github, so the conversion seems to work but afterwards, when trying to read the directory a problem seems to occur. Needs a bit of further investigation. Nevertheless the file is attached for further testing.

Code:

$ lif td02lif 85-SS80.TD0 xx.lif

TeleDisk image file 85-SS80.TD0

image:[85-SS80.TD0], size:[117642]

TeleDisk version: 21

TeleDisk Normal compression

TeleDisk date: 01/04/2008 12:47:51

TeleDisk Comment:[HP-85 S/W, SS/80 EXERCISER, 5010-0310/2537. DOES NOT INCLUDE THE SERVC F]

81 tracks, 2 side(s), sectors(17),bitrate:250000

LIF image size in sectors:474

LIF IMAGE Done

LIF image:[xx.lif] wrote:[474] used sectors

lif_read: read:[xx.lif] offset:[640] write:[29] expected:[32]

lif_open_volume:[░J9] error directory check failed

Martin Hepperle · (This post was last modified: 08-02-2017 07:13 AM by Martin Hepperle.)

(07-28-2017 01:37 AM)magore Wrote: I now have the files on my github page: github.com/magore/hp85disk under the lif folder
I found two errors 1 on track 11 and another on track 13
On track 11 sector 8 was missing but instead there was a unique sector numbered 116
On track 13 sector 11 was missing but instead there was a unique sector numbered 116
I put a bit of code in my teledisk lif image converter code to translate the numbers.

...

I used the disk image provided by Mike and tried to recover the files. As in my first attempt I came across still errors. but this time I was more persistent and was abled during two night sessions to untwist the tangle. My conclusions are that there is still is one single record missing in the image file. I do not know whether this record is in the TD0 file in the wrong place or lost. I was able to reconstruct a best guess of the missing record and the attached ZIP file has the BASIC programs which can be read e.g. into Everett's emulator. There is also a file with my notes explaining some bits and pieces of my forensic analysis.

Martin

magore · 08-02-2017, 04:22 PM

I have updated the LIF standalone tools part of my github.com/hp85disk project to compile under MinGW - the code conditionally checks for MinGW and includes some missing POSIX functions that MingW does not have. I have done limited testing.

magore · 08-02-2017, 04:30 PM

Regarding the memory error. When creating the MingW version of the code I had to make all of my fopen calls include "b" in the mode for binary. Under windows this matters - it does not matter under linux or under the avr code "b" ok to add but does nothing else. The error happens when ready LIF directory records - the read expected 32 bytes but returned 29 - closing the LIF structure and causing the error down stream.

magore · 08-03-2017, 01:08 AM

While looking at the 85-SS80.LIF files I found a few bugs in the AVR LIF code when adding to an existing image (looks like an int overflow). I will fix this and post an update when it is fixed. The bug causes the lif file header to be overwritten (oops).

magore · 08-03-2017, 02:15 AM

When I set the debuglevel option in lifsup.c to 0x401 I see the following odd sector maps
on cylinders 20,25,26,27 and 29.
They should all be numbered sectors 0 to 15.
On cyl:20 we are missing cylinder 8 but have 16 instead.
I think I will add debugging code to verify we have the correct number and check sequence.
I already ignore sector 17 using the fact that it is not 256 bytes like the rest.
Another really odd issue is the interleave - it makes no sense.
This matters because I write the new LIF file in sector number order - not in the order in the TD0 image itself anyway that is why we have odd holes in the data..

cyl:20,hd:0 map: 0 4 9 13 1 5 10 14 2 6 11 15 3 7 12 16
cyl:25,hd:0 map: 0 4 9 13 1 5 10 14 2 7 11 15 3 8 12 16
cyl:26,hd:0 map: 0 4 8 13 1 5 9 14 2 6 10 15 3 7 11 16
cyl:27,hd:0 map: 0 5 9 13 1 6 10 14 3 7 11 15 4 8 12 16
cyl:29,hd:0 map: 7 11 15 2 8 12 16 3 9 13 0 5 10 14 1 6

magore · 08-03-2017, 02:19 AM

FYI: here is the full sector map listing - cyl 15 is missing a sector
(I will update the code to report missing sectors)
cyl: 0,hd:0 map: 0 4 8 12 1 5 9 13 2 6 10 14 3 7 11 15
cyl: 1,hd:0 map: 10 14 2 6 11 15 3 7 12 0 4 8 13 1 5 9
cyl: 2,hd:0 map: 4 8 12 0 5 9 13 1 6 10 14 2 7 11 15 3
cyl: 3,hd:0 map: 14 2 6 10 15 3 7 11 0 4 8 12 1 5 9 13
cyl: 4,hd:0 map: 8 12 0 4 9 13 1 5 10 14 2 6 11 15 3 7
cyl: 5,hd:0 map: 2 6 10 14 3 7 11 15 4 8 12 0 5 9 13 1
cyl: 6,hd:0 map: 12 0 4 8 13 1 5 9 14 2 6 10 15 3 7 11
cyl: 7,hd:0 map: 6 10 14 2 7 11 15 3 8 12 0 4 9 13 1 5
cyl: 8,hd:0 map: 0 4 8 12 1 5 9 13 2 6 10 14 3 7 11 15
cyl: 9,hd:0 map: 10 14 2 6 11 15 3 7 12 0 4 8 13 1 5 9
cyl:10,hd:0 map: 4 8 12 0 5 9 13 1 6 10 14 2 7 11 15 3
cyl:11,hd:0 map: 1 2 3 4 5 6 7 8 0 9 10 11 12 13 14 15
cyl:12,hd:0 map: 8 12 0 4 9 13 1 5 10 14 2 6 11 15 3 7
cyl:13,hd:0 map: 1 2 3 4 5 6 7 8 9 10 11 0 12 13 14 15
cyl:14,hd:0 map: 12 0 4 8 13 1 5 9 14 2 6 10 15 3 7 11
cyl:15,hd:0 map: 5 9 13 1 6 10 14 2 7 11 3 8 12 0 4
cyl:16,hd:0 map: 0 4 8 12 1 5 9 13 2 6 10 14 3 7 11 15
cyl:17,hd:0 map: 10 14 2 6 11 15 3 7 12 0 4 8 13 1 5 9
cyl:18,hd:0 map: 4 8 12 0 5 9 13 1 6 10 14 2 7 11 15 3
cyl:19,hd:0 map: 14 2 6 10 15 3 7 11 0 4 8 12 1 5 9 13
cyl:20,hd:0 map: 0 4 9 13 1 5 10 14 2 6 11 15 3 7 12 16
cyl:21,hd:0 map: 2 6 10 14 3 7 11 15 4 8 12 0 5 9 13 1
cyl:22,hd:0 map: 12 0 4 8 13 1 5 9 14 2 6 10 15 3 7 11
cyl:23,hd:0 map: 6 10 14 2 7 11 15 3 8 12 0 4 9 13 1 5
cyl:24,hd:0 map: 0 4 8 12 1 5 9 13 2 6 10 14 3 7 11 15
cyl:25,hd:0 map: 0 4 9 13 1 5 10 14 2 7 11 15 3 8 12 16
cyl:26,hd:0 map: 0 4 8 13 1 5 9 14 2 6 10 15 3 7 11 16
cyl:27,hd:0 map: 0 5 9 13 1 6 10 14 3 7 11 15 4 8 12 16
cyl:28,hd:0 map: 8 12 0 4 9 13 1 5 10 14 2 6 11 15 3 7
cyl:29,hd:0 map: 7 11 15 2 8 12 16 3 9 13 0 5 10 14 1 6

Martin Hepperle · (This post was last modified: 08-07-2017 10:32 AM by Martin Hepperle.)

(08-03-2017 02:19 AM)magore Wrote: FYI: here is the full sector map listing - cyl 15 is missing a sector
(I will update the code to report missing sectors)
cyl: 0,hd:0 map: 0 4 8 12 1 5 9 13 2 6 10 14 3 7 11 15
...
cyl:13,hd:0 map: 1 2 3 4 5 6 7 8 9 10 11 0 12 13 14 15
cyl:14,hd:0 map: 12 0 4 8 13 1 5 9 14 2 6 10 15 3 7 11
cyl:15,hd:0 map: 5 9 13 1 6 10 14 2 7 11 3 8 12 0 4
...

Mike,

thank you for your interesting work.

I would have expected an interleave of 4 for all tracks, but some (#13) are weird.
My analysis of the LIF image shows that one sector is missing after file offset 0xFA00. 0xFA00 is 64000d which is 240d sectors resp. 15 tracks and 10 sectors.

Now: 15 good tracks means tracks #0...#14. In track #15 there are 10 good sectors (#0...#9) and #10 is missing. In your list #10 occurs but #15 is missing. So #10 should be #11, etc. up to #14 would become #15.

There is probably no automagic way to fix such problems, but it would be important that a conversion software shows inconsistencies to the user and if odd sector numbers occur (e.g. 116) they should never be thrown out but saved to extra files (e.g. track#-sector#.lif). Thus one could at least inspect them and as a last resort patch into the LIF image by hand hex-editor)
Martin

magore · 08-06-2017, 04:10 AM

I have been taking some time to read the spec on TD0 format.

For what David and other wrote you can have holes in sector sequences with teledisk images.
So the tracks with a the odd sector 16 have the correct number, assuming the sector number are in order I just have to write them in that order. So I have updated the code to do that and pad blank sectors if there are too few sectors.

The one interesting thing is that with cylinder 11 and 13 the sector numbers are in sequence and not interleaved - I still need to verify that sector 116 is really the last sector or not - hopflly it is.

What I find very odd is that I can see no internal crc errors in the TD0 file and the interleave changes in odd ways that can not be easily explained..

magore · 08-08-2017, 05:13 AM

Given that I was not 100% not sure how teledisk encoded and managed with errors I have been rereading documents and I have been working through teledisk_loader.c (the main teledisk decoder) to examine the decoding process more carefully. I have rewritten much of teledisk_loader.c and now plan to merge it into my td02lif.c wrapper. It will be much easier to patch up bad tracks with missing or bogus sectors.

I noticed while doing this rewrite that images created by the old TELEDISK dos program did not store CRC values for the sector header information itself at all - just a 1 byte CRC for the much larger sector data. The 1 byte data CRC makes no sense - the lack of checking the CRC for the sector header is a bug. They used 2 byte CRC with the teledisk comment and 1 or 0 bytes for most of everything else. The smaller size vs 2 byte CRC would only save a few percent on image sizes. Well perhaps this may reflect as to why we can have broken teledisk images with no hint as to how.

Fortunately I can do a number of sanity checks - verify we have all of the sectors on all tracks.
Eliminate all sectors whose size does not match those on the track 0. Parse the LIF data while reading and stop after the last record - not at the end of disk, etc...

I hope to have my updated code on github in a few days...