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 [email protected] 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:[email protected]] > Sent: Saturday, May 24, 2014 05:42 PM > To: simh <[email protected]> > 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 > [email protected] > > >
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
