Re: Line printer art: (was Re: tape baking)

[Charles Anthony via cctalk]

On Mon, Jul 10, 2017 at 4:19 AM, Martin Hepperle via cctalk <
cctalk@classiccmp.org> wrote:

> For those interested in viewing those line printer files but without a
> suitable printer I have hacked together a small Java program for viewing
> and
> exporting the files. Nothing great, but it does the job.  Try SMALLCAT
> first.
>
> I understood that the first column contains FORTRANish line advance
> characters, but I am not sure what the "-" means.
> Nevertheless the result looks reasonable.
>

Triple space (https://en.wikipedia.org/wiki/ASA_carriage_control_characters)

-- Charles

Re: Line printer art: (was Re: tape baking)

[Keven Miller(rtt) via cctalk]

Thanks for the fun exercise!
Nice job. I viewed SPOCK, MOON, ASTRONAUT.

I had to recompile (at moment I'm set for java 6; and still novice at java)

"-" means triple space.

Keven Miller

- Original Message - 
From: "Martin Hepperle via cctalk" <cctalk@classiccmp.org>

To: <cctalk@classiccmp.org>
Sent: Mon 10 Jul 2017 05:19 AM
Subject: Re: Line printer art: (was Re: tape baking)



For those interested in viewing those line printer files but without a
suitable printer I have hacked together a small Java program for viewing 
and

exporting the files. Nothing great, but it does the job.  Try SMALLCAT
first.

I understood that the first column contains FORTRANish line advance
characters, but I am not sure what the "-" means.
Nevertheless the result looks reasonable.

A zip archive with a runnable jarchive and the source can be found at:
http://www.mh-aerotools.de/downloads/LineArtPrinter.zip

Martin

Re: Line printer art: (was Re: tape baking)

[Martin Hepperle via cctalk]

For those interested in viewing those line printer files but without a
suitable printer I have hacked together a small Java program for viewing and
exporting the files. Nothing great, but it does the job.  Try SMALLCAT
first.

I understood that the first column contains FORTRANish line advance
characters, but I am not sure what the "-" means.
Nevertheless the result looks reasonable.

A zip archive with a runnable jarchive and the source can be found at:
http://www.mh-aerotools.de/downloads/LineArtPrinter.zip

Martin

Re: Line printer art: (was Re: tape baking)

[Jeff Woolsey via cctalk]

You know, I have about four different tapes with those Harbison posters
on them.  Different formats, too.  They're probably ubiquitous by now.

For those of you without printers who still want to see the posters,
asciitopgm from the netpbm package can be coaxed to do this.  See
http://netpbm.sourceforge.net/doc/asciitopgm.html .   Coals to
Newcastle, anyone?

-- 
  Jeff Woolsey
  j...@jlw.com

Re: Line printer art: (was Re: tape baking)

[Alan Frisbie via cctalk]

Al Kossow  wrote:

> Need to update my reader anyway soon, so I'm going
> to append something similar to what you did the new
> images I create, probably just a ascii text record
> and a label picture.

For the many hundreds of 9-track tapes I'm turning into
image files, I am also including an ASCII text file of
whatever information I can read from the paper label and
any related notes, plus several photographs of the reel
of tape and any labels.

Some of the labels are so faded that the only way I can
read them is to put them on the flatbed scanner, then
manipulate the color & contrast to bring out the writing.

Of course, the photos are many times larger than the
data file!

I'm trying to figure out how to best organize all this
data.   The best I've come up with so far is to put all
the files for one tape in a single directory, all with
similar names.   Suggestions would be welcome.

Before I got side-tracked with other projects, I had
imaged some 600 1600 bpi tapes.   Now I have about 400
800 bpi tapes to do.   The delay is that the room with
the 800 bpi drive (Cipher 910) is so full of "stuff"
that I can barely see the drive at the far side of the
room.   I'm sure than none of you people have this
problem!  :-)

Alan Frisbie

RE: Line printer art: (was Re: tape baking)

[Dave Wade via cctalk]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Peter
> Coghlan via cctalk
> Sent: 07 July 2017 23:32
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk@classiccmp.org>
> Subject: RE: Line printer art: (was Re: tape baking)
> 
> >
> > >
> > > If anyone's running Hercules or some other uses-EBCDIC emulator,
> > > here's the link to the .tap image file.
> > >
> > > https://app.box.com/s/8rxbihjjnw5zdkesym4cjwqswekufagh
> > >
> > > --Chuck
> >
> > Sadly I don't think that's much use on Hercules as it needs an AWS or
> > HET file. Is there a format converter any where?
> >
> 
> I think I recall managing to do that sort of conversion with VTAPECP which is
> part of something called VTAPEUTILS.  It looks like I used version 0.2.
> 
> Regards,
> Peter Coghlan.

Thanks Peter, 

Found those in SourceForge and managed to compile on Windows. Tape copied to 
.aws and first file loaded into VM...

Dave

RE: Line printer art: (was Re: tape baking)

[Peter Coghlan via cctalk]

>
> >
> > If anyone's running Hercules or some other uses-EBCDIC emulator, here's
> > the link to the .tap image file.
> > 
> > https://app.box.com/s/8rxbihjjnw5zdkesym4cjwqswekufagh
> > 
> > --Chuck
>
> Sadly I don't think that's much use on Hercules as it needs an AWS or HET
> file. Is there a format converter any where?
>

I think I recall managing to do that sort of conversion with VTAPECP which is
part of something called VTAPEUTILS.  It looks like I used version 0.2.

Regards,
Peter Coghlan.

Re: Line printer art: (was Re: tape baking)

[Chuck Guzis via cctalk]

On 07/07/2017 12:46 PM, Al Kossow via cctalk wrote:

> It is literally "you can't save everything, where would you put it?"
> 
> You can be completely buried by piles of unknown data on magnetic
> media.
And yet, I'll venture that it's a pretty safe bet that all of the data
recorded between 1955-1980 would occupy only a tiny part of what's being
lost on the web every week.

Brewster Kahle has an ambitious goal (and I'm grateful for the effort),
but I think it'll eventually come to bailing the Titanic with a teaspoon.

The NSA does a bit better, I'm sure.

--Chuck

Re: Line printer art: (was Re: tape baking)

[Al Kossow via cctalk]

yup

On 7/7/17 12:33 PM, Chuck Guzis via cctalk wrote:
> On 07/07/2017 12:04 PM, Al Kossow via cctalk wrote:
> 
>>
>> The way JBI did it was to digitize the capstan encoder as a clock
>> reference for tape motion obliquely referenced in 
>> http://storageconference.us/2008/presentations/3.Wednesday/5.Bordynuik.pdf
> They mention a 36-track tape head.  Were those pretty much stock 3490E
> heads?
> 
> --Chuck
> 

Re: Line printer art: (was Re: tape baking)

[Al Kossow via cctalk]

On 7/7/17 12:28 PM, Chuck Guzis via cctalk wrote:

> It brings up another aspect.   I've done a batch of tapes that had
> nothing more that the originator's name and an inventory number.   Upon
> recovering data, the customer had no idea what it meant or how it was
> created or even the system used to create it.

> 
> We're coming onto the "Linear B" era in computing I think, where
> knowledge is passing out of human memory. 
We have a VERY large collection of paper tapes from Whirlwind. They have
nice numbers on the outside of the boxes. We have no catalog. The best I've
been able to do is piece together a guess as to what non-secret projects they
were associated with based on the periodic MIT project reports. What is data
and what are programs, who knows? oh.. and they were stored in a basement and
the boxes are moldy.

There is a water mark where if something isn't of value enough to someone
to save and continue to pay for its preservation, it's dumpstered. While
it is nice to say things need to be preserved, if there isn't manpower or
space it won't be.

It is literally "you can't save everything, where would you put it?"

You can be completely buried by piles of unknown data on magnetic media.

Re: Line printer art: (was Re: tape baking)

[Chuck Guzis via cctalk]

On 07/07/2017 12:04 PM, Al Kossow via cctalk wrote:

> 
> The way JBI did it was to digitize the capstan encoder as a clock
> reference for tape motion obliquely referenced in 
> http://storageconference.us/2008/presentations/3.Wednesday/5.Bordynuik.pdf
They mention a 36-track tape head.  Were those pretty much stock 3490E
heads?

--Chuck

Re: Line printer art: (was Re: tape baking)

[Chuck Guzis via cctalk]

On 07/07/2017 12:17 PM, Al Kossow via cctalk wrote:

> I'm much less hopeful on any other parallel tape formats, since there
> are so few and the desire to recover any of that has been low.

It brings up another aspect.   I've done a batch of tapes that had
nothing more that the originator's name and an inventory number.   Upon
recovering data, the customer had no idea what it meant or how it was
created or even the system used to create it.

We're coming onto the "Linear B" era in computing I think, where
knowledge is passing out of human memory.  I noted that some years ago
with the mention of the Zodiac system.  Something like $200M initially
spent on it, when that was a lot of money.  Few documents remain and no
(AFAIK) data samples. I've heard estimates of 3M lines of code, all of
it gone.

I'll wager that there are hundreds of cases of this kind of thing.

--Chuck

Re: Line printer art: (was Re: tape baking)

[Al Kossow via cctalk]

On 7/7/17 12:08 PM, Paul Koning wrote:

>> And I'm moving towards flux-level archiving and away from using
>> stock tape transports.
>>
>> But then, I've been saying that for 15+ years now and haven't done it.
> 
> It would be great to have that capability, after the company that had it 
> before seemingly vanished.  Better yet if you can handle not just plain 7 and 
> 9 track 1/2 inch tape but also other formats.  3/4 inch tape would come to 
> mind (DECtape and friends).  There's one inch tape (CDC 626) though I'm not 
> sure if any has been preserved.  There's 1/2 inch 10 track tape 
> (Electrologica X1 and others).
> 
> Stuff like error correction data makes sense for such low level capture.  
> It's not so obvious if you're working with a conventional tape transport, 
> which simply tells you "read error, you're SOL" if the checksums are no good. 
>  


I guess you've tried contacting John then about the Xelctrologica tapes?

He sent me a prototype drive with 18-track (IBM 3480) head that I still haven't
gotten to work. Most of the code lives on a Virtex FPGA board with the A/D 
converters
attached and he never gave me the source or adequate instructions on how to 
talk to it

This only works because the 3480 and 90 still used 1/2" width tape.

DECtape recovery hasn't been a problem. It's pretty rugged stuff.

I'm much less hopeful on any other parallel tape formats, since there are so 
few and the desire
to recover any of that has been low.

Re: Line printer art: (was Re: tape baking)

[Paul Koning via cctalk]

> On Jul 7, 2017, at 1:29 PM, Al Kossow via cctalk  
> wrote:
> 
> 
> 
> On 7/7/17 10:26 AM, Al Kossow via cctalk wrote:
> 
>> I stopped beating that horse years ago.
> 
> And I'm moving towards flux-level archiving and away from using
> stock tape transports.
> 
> But then, I've been saying that for 15+ years now and haven't done it.

It would be great to have that capability, after the company that had it before 
seemingly vanished.  Better yet if you can handle not just plain 7 and 9 track 
1/2 inch tape but also other formats.  3/4 inch tape would come to mind 
(DECtape and friends).  There's one inch tape (CDC 626) though I'm not sure if 
any has been preserved.  There's 1/2 inch 10 track tape (Electrologica X1 and 
others).

Stuff like error correction data makes sense for such low level capture.  It's 
not so obvious if you're working with a conventional tape transport, which 
simply tells you "read error, you're SOL" if the checksums are no good.  

paul

Re: Line printer art: (was Re: tape baking)

[Al Kossow via cctalk]

On 7/7/17 11:10 AM, Chuck Guzis via cctalk wrote:

> I've puzzled over how to do tape flux-transition recording in any
> meaningful way.

The way JBI did it was to digitize the capstan encoder as a clock reference for 
tape motion
obliquely referenced in
http://storageconference.us/2008/presentations/3.Wednesday/5.Bordynuik.pdf

--

Thanks to the current administration, all of the NASA Nimbus data reports 
appear to have
dissapeared from the web.

mentions in
http://www.sciencedirect.com/science/article/pii/S2214242815000212#bb0035

"An examination of these 7-track tapes revealed they were in poor shape. The 
tapes iron oxide media was falling off the
acetate film backing. Fortunately, GSFC had just learned of a Canadian company, 
JBI Incorporated that had developed a
tape recovery process that could read the bits from magnetic tapes with a high 
degree of certainty. The JBI recovery
process involved using specially developed tape drives with 36 magnetoresistive 
(MR) heads, tape baking (10 h at 175°),
bit detection and processing techniques to read the 800 bit-per-inch, 7-track 
tapes. Based on the original Nimbus HRIR
system documentation, GSFC was then able to recover and rescue the observations 
from thousands of Nimbus HRIR digital
data tapes"

M. Hobish, D. Gallaher, G. Campbell, W. Meier
Dark data rescue: shedding new light on old photons
The Earth Observer May–June 2014, 26 (3) (2014), pp. 4-10


for example

gsfc.nasa.gov/nimbus/documentation/documents/N7_Recovery_Report_Jul16.doc

Re: Line printer art: (was Re: tape baking)

[Chuck Guzis via cctalk]

On 07/07/2017 10:26 AM, Al Kossow via cctalk wrote:

> I stopped beating that horse years ago. They also assume that all of the data
> blocks read correctly, they don't save the error correction data if the block
> had it, etc etc.
> 
> Need to update my reader anyway soon, so I'm going to append something 
> similar to
> what you did the new images I create, probably just a ascii text record and a 
> label picture.

I currently add 2 records (in TAP prefix/suffix format).   The first
starts with CR-LF "LOG" CR-LF;the second is identifiable as a JPEG
"JFIF" file.  Nothing more complicated than that.

At least the log identifies bad blocks and what the problem was insofar
as the reading software can determine.  That may be all that's available
on some SCSI drives.  Pertec-interface drives can pinpoint the frame in
error much of the time.

I've puzzled over how to do tape flux-transition recording in any
meaningful way.  One of the problems is encoding skewing information as
well as tape speed--unlike floppies, you have parallel tracks and tape
speed (reading and writing) isn't constant.  A good deal of the data
recovery circuitry in a 9 or 7 track drive involves deskewing and speed
compensation.

I recall looking at customer samples back in the day from CDC 669 drives
using a low-power microscope and developer and being gobsmacked at how
crowded things were at the start of a tape block.  The customer was
running the Navy Audit COBOL tests and the short block stop-start tape
I/O suite was giving the drives fits.  Spence Preston eventually flew in
and reworked the firmware over about two weeks so that things held
together--I didn't get any detail on the specifics of his fix.

I suppose that one could simply oversample the tape, recording
sub-frames every 100 nsec or so, but I haven't thought that one through.
 But it would be easy enough to do with a medium-power MCU.   Writing
the code to make sense of the data, perhaps not so much.

--Chuck

Re: Line printer art: (was Re: tape baking)

[Al Kossow via cctalk]

On 7/7/17 10:26 AM, Al Kossow via cctalk wrote:

> I stopped beating that horse years ago.

And I'm moving towards flux-level archiving and away from using
stock tape transports.

But then, I've been saying that for 15+ years now and haven't done it.

Re: Line printer art: (was Re: tape baking)

[Al Kossow via cctalk]

On 7/7/17 9:35 AM, Chuck Guzis via cctalk wrote:

> I've voiced my opinion before of being a bit surprised that neither AWS
> nor TAP makes any provision for metadata.   The tape data bits don't
> tell the whole story.


I stopped beating that horse years ago. They also assume that all of the data
blocks read correctly, they don't save the error correction data if the block
had it, etc etc.

Need to update my reader anyway soon, so I'm going to append something similar 
to
what you did the new images I create, probably just a ascii text record and a 
label picture.

Re: Line printer art: (was Re: tape baking)

[Chuck Guzis via cctalk]

On 07/07/2017 08:25 AM, Dave Wade wrote:

> The header is six bytes long. Two are the length of the current
> block. Two of the bytes are the length of the previous block, so you
> can do read backwards, two of the bytes contain flag bits. One of the
> flags says this chunk  is the first part of a real block, another the
> last part, so typically both are set for blocks less than 64K. For
> blocks, bigger than 64K they the  first chunk flag is set for the
> first 64K, the last chunk has the last chunk bit set, and any
> intermediate chunks have no bits set. Again this facilitates read
> backwards

Okay, that fills in a few gaps that the reference I cited didn't address.

Contrast with the SIMH .tap structure, where all blocks are prefixed and
suffixed with a 32-bit byte count, with certain high-order bits serving
as flags for error and EOI indicators, with a single 32bit word of zero
serving as tapemark.   Read-backward is straightforward.

The AWS format seems overcomplicated to me, but perhaps it's an artifact
of a 16-bit memory-limited implementation.  It's curious that, like TAP,
the byte counts are little-endian.

In any case, not a big deal to translate between the two.

My own implementation of TAP keeps the same basic structure as the SIMH
version, but appends a few records of metadata, including the log
session of the read of the physical tape and a JPEG of the original
tape.  I usually trim those off when I make tape data available for
other than the customer.   Almost all of my work is done with archivists
and the metadata is much appreciated.

I've voiced my opinion before of being a bit surprised that neither AWS
nor TAP makes any provision for metadata.   The tape data bits don't
tell the whole story.

--Chuck

RE: Line printer art: (was Re: tape baking)

[Dave Wade via cctalk]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Chuck
> Guzis via cctalk
> Sent: 07 July 2017 08:11
> To: CCtalk <cctalk@classiccmp.org>
> Subject: Re: Line printer art: (was Re: tape baking)
> 
> On 07/06/2017 10:42 PM, Dave Wade wrote:
> 
> > Sadly I don't think that’s much use on Hercules as it needs an AWS or HET
> file. Is there a format converter any where?
> 
> Dunno, but it should be pretty simple.  TAP is discussed with the SIMH
> documentation and the AWS format is discussed here:
> 
> http://www.cbttape.org/awstape.htm
> 
> Mostly a matter of reworking headers.   The surprising thing is that I
> know that some IBM tapes can have 128KB records--I don't know how AWS
> accommodates this with only 2 bytes for a record length.
> 
> And "long block" tapes can theoretically have a single block that's the length
> of the physical tape, although one would be an idiot to do such a thing.  (cf.
> CDC CYBER NOS/BE 1LT driver)


The header is six bytes long. Two are the length of the current block. Two of 
the bytes are the length of the previous block, so you can do read backwards, 
two of the bytes contain flag bits. 
One of the flags says this chunk  is the first part of a real block, another 
the last part, so typically both are set for blocks less than 64K. For blocks, 
bigger than 64K they the  first chunk flag is set for the first 64K, the last 
chunk has the last chunk bit set, and any intermediate chunks have no bits set. 
Again this facilitates read backwards

> 
> --Chuck

Dave

Re: Line printer art: (was Re: tape baking)

[Chuck Guzis via cctalk]

On 07/06/2017 10:42 PM, Dave Wade wrote:

> Sadly I don't think that’s much use on Hercules as it needs an AWS or HET 
> file. Is there a format converter any where?

Dunno, but it should be pretty simple.  TAP is discussed with the SIMH
documentation and the AWS format is discussed here:

http://www.cbttape.org/awstape.htm

Mostly a matter of reworking headers.   The surprising thing is that I
know that some IBM tapes can have 128KB records--I don't know how AWS
accommodates this with only 2 bytes for a record length.

And "long block" tapes can theoretically have a single block that's the
length of the physical tape, although one would be an idiot to do such a
thing.  (cf. CDC CYBER NOS/BE 1LT driver)

--Chuck

RE: Line printer art: (was Re: tape baking)

[Dave Wade via cctalk]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Chuck
> Guzis via cctalk
> Sent: 06 July 2017 21:03
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk@classiccmp.org>
> Subject: Re: Line printer art: (was Re: tape baking)
> 
> On 07/06/2017 12:41 PM, Ethan Dicks wrote:
> 
> > I got it from the Box link.  Thanks!
> 
> If anyone's running Hercules or some other uses-EBCDIC emulator, here's
> the link to the .tap image file.
> 
> https://app.box.com/s/8rxbihjjnw5zdkesym4cjwqswekufagh
> 
> --Chuck

Sadly I don't think that’s much use on Hercules as it needs an AWS or HET file. 
Is there a format converter any where?

Dave 

RE: Line printer art: (was Re: tape baking)

[Dave Wade via cctalk]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Ethan
> Dicks via cctalk
> Sent: 06 July 2017 20:02
> To: Chuck Guzis <ccl...@sydex.com>; General Discussion: On-Topic and Off-
> Topic Posts <cctalk@classiccmp.org>
> Subject: Line printer art: (was Re: tape baking)
> 
> On Thu, Jul 6, 2017 at 1:59 PM, Chuck Guzis via cctalk <cctalk@classiccmp.org>
> wrote:
> > It worked--I retrieved a tape of line printer art from Princeton quite
> > successfully.  Oddly, nobody was interested in a copy of the files.
> 
> I'm interested!  I'm about to read a card deck for an old work associate who 
> is
> reasonably sure it has some ASCII art on it (it's unlikely to be a "lost" 
> picture,
> but there's always a chance).

Me too. A few sites on-line have copies of these pics...

> 
> > Go figure.  Perhaps nobody owns a line printer that takes continuous
> > forms any more.
> 
> I still have at least one LA180, some LA100s, and probably several more
> tractor-feed wide-carriage printers including one medium-sized
> DataProducts line printer.  What I don't have is an abundance of paper
> - I have some, but not like 30 years ago when it was easy to get partial boxes
> for free or cheap.

I also have an LA100 plus a wide carriage daisy wheel...
... I got a few boxes when some showed up on E-Bay in the UK..

> 
> Feel free to PM me a link to where I could get a copy of these art files or
> reply here with it.

Thanks for the link.

> 
> -ethan

Dave

Re: Line printer art: (was Re: tape baking)

[Charles Anthony via cctalk]

On Thu, Jul 6, 2017 at 3:18 PM, Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> You know, I do a fair amount of this stuff.  The confidential/secret
> stuff I keep that way (e.g. 100 tapes that I'm doing for NASA this
> summer), but there's also a fair amount of public stuff that I do have
> permission to share.   I've done the hard work in translating the data
> to something recognizable (e.g. CDC 6-bit display code) but don't have a
> clue as to what to do with it, if anything.
>
> I'll occasionally post an offer over at VCFed, but have never gotten
> much interest going there, so I don't bother nowadays.
>
> Much of the data is already known; for instance, yet another set of AT
> Unix SysVR4 tapes.  (One wonders how many copies of this were made).
>
> But there are some tidbits that I haven't seen anywhere else.
>
> Any interest in this?
>
>
We are always looking for Multics software; especially the unbundled
network stack tapes.


-- Charles


>
>

Re: Line printer art: (was Re: tape baking)

[Paul Anderson via cctalk]

Just passing it on. If anyone is interested, last I heard Devon has 2
nice printers for sale in Florida.

On Thu, Jul 6, 2017 at 5:48 PM, Rob Jarratt via cctalk <
cctalk@classiccmp.org> wrote:

> > -Original Message-
> > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Chuck
> Guzis
> > via cctalk
> > Sent: 06 July 2017 23:19
> > To: General Discussion: On-Topic and Off-Topic Posts <
> cctalk@classiccmp.org>
> > Subject: Re: Line printer art: (was Re: tape baking)
> >
> > You know, I do a fair amount of this stuff.  The confidential/secret
> stuff I keep
> > that way (e.g. 100 tapes that I'm doing for NASA this summer), but
> there's also
> > a fair amount of public stuff that I do have
> > permission to share.   I've done the hard work in translating the data
> > to something recognizable (e.g. CDC 6-bit display code) but don't have a
> clue as
> > to what to do with it, if anything.
> >
> > I'll occasionally post an offer over at VCFed, but have never gotten much
> > interest going there, so I don't bother nowadays.
> >
> > Much of the data is already known; for instance, yet another set of AT
> Unix
> > SysVR4 tapes.  (One wonders how many copies of this were made).
> >
> > But there are some tidbits that I haven't seen anywhere else.
> >
> > Any interest in this?
> >
>
>
> Perhaps it could be posted to a special area on BitSavers?
>
> Regards
>
> Rob
>
>
>

RE: Line printer art: (was Re: tape baking)

[Rob Jarratt via cctalk]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Chuck Guzis
> via cctalk
> Sent: 06 July 2017 23:19
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk@classiccmp.org>
> Subject: Re: Line printer art: (was Re: tape baking)
> 
> You know, I do a fair amount of this stuff.  The confidential/secret stuff I 
> keep
> that way (e.g. 100 tapes that I'm doing for NASA this summer), but there's 
> also
> a fair amount of public stuff that I do have
> permission to share.   I've done the hard work in translating the data
> to something recognizable (e.g. CDC 6-bit display code) but don't have a clue 
> as
> to what to do with it, if anything.
> 
> I'll occasionally post an offer over at VCFed, but have never gotten much
> interest going there, so I don't bother nowadays.
> 
> Much of the data is already known; for instance, yet another set of AT Unix
> SysVR4 tapes.  (One wonders how many copies of this were made).
> 
> But there are some tidbits that I haven't seen anywhere else.
> 
> Any interest in this?
> 


Perhaps it could be posted to a special area on BitSavers?

Regards

Rob

Re: Line printer art: (was Re: tape baking)

[Chuck Guzis via cctalk]

You know, I do a fair amount of this stuff.  The confidential/secret
stuff I keep that way (e.g. 100 tapes that I'm doing for NASA this
summer), but there's also a fair amount of public stuff that I do have
permission to share.   I've done the hard work in translating the data
to something recognizable (e.g. CDC 6-bit display code) but don't have a
clue as to what to do with it, if anything.

I'll occasionally post an offer over at VCFed, but have never gotten
much interest going there, so I don't bother nowadays.

Much of the data is already known; for instance, yet another set of AT
Unix SysVR4 tapes.  (One wonders how many copies of this were made).

But there are some tidbits that I haven't seen anywhere else.

Any interest in this?

--Chuck

Re: Line printer art: (was Re: tape baking)

[Ethan Dicks via cctalk]

On Thu, Jul 6, 2017 at 3:01 PM, Ethan Dicks  wrote:
> On Thu, Jul 6, 2017 at 1:59 PM, Chuck Guzis via cctalk
>  wrote:
>> It worked--I retrieved a tape of line printer art from Princeton quite
>> successfully.

I reviewed the ASCII copy.  Several of the files, including JOHNDEAN
and MOON (I did not check 100% of them) are also in David Gessewein's
copy of line printer art from Princeton at:

http://www.pdp8online.com/ftp/ascii_art/ppt/

For MOON, as an example, once I trimmed the first 2 lines and the
trailing "form feed" line (a lone '1' in the first column), and
converted it to UNIX line terminators, was a 100% match.  The file
names are slightly different, but the picture body and even the
comments are the same.

> I'm about to read a card deck for an old work
> associate who is reasonably sure it has some ASCII art on it (it's
> unlikely to be a "lost" picture, but there's always a chance).

Thus my comment... it would be surprising to find a lost work at this
point, so it's worth looking, just in case.

I need to fire up my LA180 again - it will do the overstrike pictures.
I used it 30 years ago to print the high-detail photo of the cat that
was popular then.  Took a long, long time to print.

Thanks!

-ethan

Re: Line printer art: (was Re: tape baking)

[Chuck Guzis via cctalk]

On 07/06/2017 12:41 PM, Ethan Dicks wrote:

> I got it from the Box link.  Thanks!

If anyone's running Hercules or some other uses-EBCDIC emulator, here's
the link to the .tap image file.

https://app.box.com/s/8rxbihjjnw5zdkesym4cjwqswekufagh

--Chuck

Re: Line printer art: (was Re: tape baking)

[Ethan Dicks via cctalk]

On Thu, Jul 6, 2017 at 3:01 PM, Ethan Dicks  wrote:
> Feel free to PM me a link to where I could get a copy of these art
> files or reply here with it.

I got it from the Box link.  Thanks!

-ethan