[Simh] Some TAP image files aren't quite right
Larry Baker
baker at usgs.gov
Sat May 24 18:36:09 EDT 2014
Tim,
The RSTS TAP image is definitely not a TPC image -- it is valid SIMH format except for the strangeness at the end. (My MTD image format is the same as the TPC format description I found at ftp://ftp.mrynet.com/operatingsystems/simulators/simtools/mtcvtv23/mtcvtv23.txt, but using Fortran unformatted file format instead of an unstructured byte-stream file format.) Do you think the likely culprit that created the flawed TAP image might have been mtcvtv23?
Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov
On 24 May 2014, at 3:18 PM, Shoppa, Tim wrote:
> Whenever I imaged a tape using VMSTPC I named the TPC image ".TPC" and then (decade or later in the 90's) often converted to SIMH .TAP.
>
> Others name the TPC as ".TAP" which can be a little vague. If it was made in early 90's or earlier it is likely TPC even if it ends with .TAP.
>
> There is a SIMH utility program for converting TPC to TAP, it is called mtcvtv23 (or similar)
>
> Tim
>
> From: Larry Baker [mailto:baker at usgs.gov]
> Sent: Saturday, May 24, 2014 05:42 PM
> To: simh <simh at trailing-edge.com>
> Subject: [Simh] Some TAP image files aren't quite right
>
> While I've been helping Cory to copy his TAP mag tape image file to a real TK50, I've discovered that the TAP image he's been using does not correctly follow Bob Supnik's SIMH Magtape Representation and Handling document (http://simh.trailing-edge.com/docs/simh_magtape.pdf). I don't know how SIMH TAP images get created. But, if there is a common tool that is being used, it might need some tweaking.
>
> The SIMH TAP image Cory is using is rstse_v10_1_install_sep10_1992.tap. I downloaded it from ftp://ftp.trailing-edge.com/pub/rsts_dists/rstse_v10_1_install_sep10_1992.tap.bz2. The SIMH2MTD conversion program I wrote for Cory converts a SIMH TAP file to my own MTD magtape image file format, with which he can then run my MTD program to make a real TK50 from the MTD image. The conversion program validates the SIMH TAP format and returns a Fatal Hardware Error pseudo-magtape status when the format is incorrect. This happens at the end of the rstse_v10_1_install_sep10_1992.tap SIMH TAP file. Running a debugging version of SIMH2MTD shows that there is an illegal metadata marker after the two tape marks at the end of the tape:
>
>> DO_CONVERT: Metadata = 00000050, ierr = 0 <--- This is an ANSI EOF1 label
>> DO_CONVERT: Metadata = 00000050, ierr = 0 <--- This is an ANSI EOF2 label
>> DO_CONVERT: Metadata = 00000000, ierr = 0 <--- Tape Mark
>> DO_CONVERT: SIMH Tape Mark
>> DO_CONVERT: Metadata = 00000000, ierr = 0 <--- Tape Mark
>> DO_CONVERT: SIMH Tape Mark
>> DO_CONVERT: Metadata = 0000FFFF, ierr = 0 <--- Looks like a recl for a 65535 byte data record, but there are not 65536 (incl. padding) + 4 (recl copy) bytes left in the file
>> Fortran Run-Time error: 140
>> %SYSTEM-F-DRVERR, fatal drive error
>> %TRACE-F-TRACEBACK, symbolic stack dump follows
>> module name routine name line rel PC abs PC
>>
>> DO_CONVERT DO_CONVERT 1509 0000021E 00011496
>> SIMH2MTD SIMH2MTD 1424 00000017 00010E17
>
>
> Sure enough, if I dump the file from my Mac, where I downloaded it and uncompressed it, I can see there's garbage at the end of the file (ffff 0000 ... ffff 0000):
>
>> savaii:Downloads baker$ ls -l rstse_v10_1_install_sep10_1992.tap
>> -rw-r--r-- 1 baker GS\domain users 24096588 Oct 30 2004 rstse_v10_1_install_sep10_1992.tap
>
>
>> savaii:Downloads baker$ od -A d -x -j 24085504 rstse_v10_1_install_sep10_1992.tap | more
>> 24085504 addf acba abba addf abba adaa dfb1 b0bc
>> 24085520 babb f6f6 dfdf dfdf dfdf d9df f5f2 f6a3
>> 24085536 baab aba7 dfdb dfc2 bab3 abb9 b7d7 4c2f
>> 24085552 2e44 4554 5458 2c24 3432 2534 2029 2020
>> 24085568 2021 4553 444e 4620 5249 5453 3220 3534
>> 24085584 4320 4148 4152 5443 5245 0953 2020 0030
>> 24085600 0000 0000 0000 0000 0000 0000 0000 0000
>> *
>> 24085648 0000 0000 0000 0000 0000 0000 0000 2000
>> 24085664 0000 0000 0000 0050 0000 4f45 3146 3233
>> 24085680 3137 422e 4b43 2020 2020 2020 2020 4220
>> 24085696 4341 554b 3050 3030 3031 3430 3036 3030
>> 24085712 3031 2030 3239 3232 2033 3239 3232 2033
>> 24085728 3030 3030 3630 4544 5243 5453 2f53 2045
>> 24085744 2020 2020 2020 2020 2020 0050 0000 0050
>> 24085760 0000 4f45 3246 3046 3138 3239 3830 3931
>> 24085776 2032 2020 2020 2020 2020 2020 2020 2020
>> 24085792 2020 2020 2020 204d 2020 2020 2020 2020
>> 24085808 2020 2020 3030 2020 2020 2020 2020 2020
>> 24085824 2020 2020 2020 2020 2020 2020 2020 2020
>> 24085840 2020 0050 0000 0000 0000 0000 0000 ffff
>> 24085856 0000 0000 0000 0000 0000 0000 0000 0000
>> *
>> 24096576 0000 0000 0000 0000 ffff 0000
>> 24096588
>
> Not all SIMH TAP images are like this. The RSX-11M-Plus SIMH TAP I downloaded from http://bitsavers.trailing-edge.com/bits/DEC/pdp11/magtapes/rsx11mplus/BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap has its Unix EOF in the right spot:
>
>> savaii:Downloads baker$ ls -l BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap
>> -rw-r--r-- 1 baker GS\domain users 9966532 May 18 22:12 BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap
>
>> savaii:Downloads baker$ od -A d -x -j 9966500 BB-3077D-SC_RSX-11M+_V3.0_SRC_1985.tap
>> 9966500 2020 2020 2020 2020 2020 2020 2020 2020
>> 9966516 2020 2020 0050 0000 0000 0000 0000 0000
>> 9966532
>
>
> The 0050 0000 is the 80 decimal recl copy from the last data record (as ANSI EOF2 label), which is followed by two tape marks (0000 0000), and the Unix EOF.
>
> I can deal with this, but if anyone knows where the buggy SIMH TAP images come from, that should be fixed.
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> baker at usgs.gov
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140524/30784c06/attachment-0002.html>
More information about the Simh
mailing list