On 8/10/16 7:04 AM, Tor Arntsen wrote: congratulations, you reinvented .tap format.. badly. how did you handle unreadable blocks.

On 8/10/16 7:51 AM, Mouse wrote: sorry, too early in the morning. that is the main difference between the original DECUS .tpc format and the emulator .tap format

On 8/10/16 8:43 AM, Chuck Guzis wrote: Even though the file size of a picture of the label may be bigger than the data itself, it is incredibly important, especially wgt provenance of the media (original disk, etc.) I keep forgetting to shoot the backs of 3.5" floppies for the manufacturing part numbers :-(

It's too bad that the Time Capsule File System invented more than twenty years ago at MIT never took off: http://www.boogles.com/local/papers/tcfs-thesis/thesis.html Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:RichA at LivingComputerMuseum.org http://www.LivingComputerMuseum.org/

I guess I'm not with the rest. I'd prefer ascii HEX format. SIMH may not be around in 50 or 100 years. Dwight ________________________________ From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Chuck Guzis <cclist at sydex.com> Sent: Wednesday, August 10, 2016 12:38:51 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Tape imaging On 08/10/2016 11:34 AM, Rich Alderson wrote: Yup, I recall seeing that. In my case, I append (after the .tap EOI marker) my metadata records, including a transfer log generated in real time. Most SIMH software doesn't look past EOI if reading, so that's okay. --Chuck

On 8/10/2016 9:30 PM, Chuck Guzis wrote: Richard Swingwood has ported my Microdata 1600 emulation into simh, and every bit of software I have so far survives because of half inch tapes. That which was on punched card source form was read to disk and is backed up on tape, so TAP is what we are using. I also have a converter to go to AWS for mainframe Hercules stuff. The Microdata M1621 Ascii is a weird ascii with the high order bit on in the character set, similar to EBCDIC, so the representation is important. I think the OS you are on dictates that to some degree as far as sequencing the records as I did initially, but it is all moved to TAP once that is done. No real concensus on metadata, though I think there was discussion about dumping it after the logical EOT, either two or three tape marks in the container, either TAP or AWS tape format. YMMV

I didn't. I didn't have any unreadable blocks. I have CCTs that I made (and sometimes got elsewhere) going back to the eighties. No read errors. I simply needed a way to a) get a copy that I could use to later write a new tape, with original records, and b) extract the content when the original minicomputers were gone. And that format worked for that, and saved all my data. Incidentally it made for an easy way to create a DLT tape duplicator (via disk) later, when I suddenly needed one. In short, it served my purpose perfectly and didn't need any research, finding software somewhere, port it, blabla. It's a very simple format which can be implemented and tested in a day, and does the job, unlike trying to e.g. 'dd' a tape. I don't even need to look up the 'protocol' if I need to write a new tool later. It can't possibly be simpler, and yet it does the job. On 10 August 2016 at 17:43, Chuck Guzis <cclist at sydex.com> wrote: Paper labels are short. The output file of the above process was stored together with a 'label file', a short text file with what's written on the label. And I would sometimes add some extra info if I looked through the content (with some other software I wrote, and depending on what the original format was). I didn't see any need for storing info about the physical tape itself, e.g. 1600 or 6250 bpi, or reel size. I have yet to find a need for that. When I could, I would note (with the label) what kind of software was used to write the tape (e.g. VMS ANSI tape, or Norsk Data backup-system format, or whatever). But the important aspect was simply to have a disk file in a format which reflected the original written tape, so that the disk file itself could be used to later extract the content, with other tools. That can't be done with any format that doesn't store the original record information, except for record-less formats like 'tar' (record-less in the sense that the physical record size isn't part of the format, unlike e.g. ANSI tapes). For my purposes I also haven't found any need of further equipment information, e.g. which tape drive was used to read the tape (I only own one anyway, and I can't see that it would make any difference if I had more than one). And I also don't need info about what kind of drive was used to write the tape, there's no way to find out anyway (other than investigating what was installed at each site at the time the tapes were originally written).

On 08/10/2016 09:45 AM, jim stephens wrote: I did something similar. I already had some tape container unpackers for other systems. I had some old VMS BACKUP tapes that I wanted to unpack. First, I extracted the save set from the container file, just turning it into a byte stream. Then, I fed it to the vmsbackup program, available The command is : vmsbackup -xe -b 8192 -f <filename> and it will build the directory tree where you currently are. (If blocksize is not 8192, substitute in above command.) It was REALLY COOL to have my entire VMS home directory tree magically appear on my Linux system! I believe I had to compile vmsbackup from source, there were some executables online but they were out of date. Jon

http://www.brouhaha.com/~eric/software/tapeutils/ On 8/10/16 8:22 AM, Paul Koning wrote:

On 08/11/2016 07:15 AM, Mark Linimon wrote: Indeed, Much, if not all, of the early 1604/160A/3000/6000 stuff is going to be 7-track clear through the 1970s. Hope someone has a decent drive to read the tapes that come up. --Chuck

603? My manuals don't go back that far. What kind of drive is that, and what does the controller connect to? If it's a 6000 series channel interface, then that's very easy to deal with. Channel to PCI-e interfaces have been built (out of FPGAs) and hooked up to DtCyber. If it's some other type of channel, the same sort of answer would apply; none of those old channels are all that complex. paul

On 08/11/2016 07:36 PM, Al Kossow wrote: I've always wondered how far someone would go to retrieve data from media that's really off the beaten path. Suppose someone found a box of tapes from an old Honeywell Datamatic mainframe. Huge reels, 3 inches wide with heaven knows how many channels... --Chuck

On 8/11/16 9:21 PM, Chuck Guzis wrote: http://www.computerhistory.org/collections/catalog/X660.86 we actually got a full reel a couple years ago, but there aren't any pictures of it yet. it's HEAVY

physical is a .1 grid of square pins coming off of a flex cable to the head stack. electrical is you supply a bias current and directly read magnetic flux with an opamp I traced all of that out the last time I made a run at this windmill. John used an FPGA development board with an 18 channel A/D, which also controlled modified firmware on the motor driver and digitizes the tach pulse to get actual tape speed. Unfortunately, he never sent me the FPGA code, so I have to come up with my own digitizer and figure out how to drive the transport. Fortunately, it's a 9914V (vertical mount), so it isn't auto-loading. I did get a tape to move to loadpoint from the front panel, so the mods might not be too bad. He did send me a disassembly of the microcontroller code with the patches he made. Reading this presentation, I think he switched to 3490 36 track heads at some point. http://storageconference.us/2008/presentations/3.Wednesday/5.Bordynuik.pdf MANY years ago, I bought a dozen 3480s in Chicago and stripped them for the heads at my parent's farm in Wisconsin, so I could try grafting one onto another transport if I had to. I've been unsuccessfully trying for years to get the schematics for a 9914 or 9914V (they aren't inlcuded in the service manual). On 8/12/16 12:29 AM, emanuel stiebler wrote:

On 8/12/16 10:14 AM, emanuel stiebler wrote: had to dig up my notes from 2013 the drive I have is 18 track (3480 head) with 18 NE5592D differential amps the A/D is a AD7322 2 channel 12 bit 1msample I have no idea what the actual sample rate used is and I can't really tell from the picture in the presentation I would be happy just to get this one running. I'm not too keen on digging for more head stacks right now.