Datum MDP-1/MCU front panel

[jim stephens via cctalk]

Anyone have an information on a system that Datum built?

Found their headquarter was at 1363 S State College, Anaheim, CA., so 
may be why it turned up in scrap around here (Orange, Country, CA)


location if anyone is interested
https://goo.gl/maps/Kf888FEdZYH2

http://bitsavers.informatik.uni-stuttgart.de/pdf/datum/C-31001_Datum_General_Catalog.pdf

Photos of the board as found.

https://jimsoldtoys.blogspot.com/2017/07/datum-mdp1-mpu.html

There is an instrumentation system in the catalog on bitsavers that has 
a Nova 800 or 1200 looking system incorporated.


Thanks
Jim

Re: Announcing: VCF PNW

[Brad H via cctalk]

Ooh.  That might be one to bring my TVT and Mark-8 stuff to, provided we don't 
have another winter like we did last year.  I'm up in BC and we just got 
pounded this year with snow and bad weather.. if it's like that again I'll have 
to pass.. BC drivers are terrible on snow.


Sent from my Samsung device

 Original message 
From: Michael Brutman via cctalk  
Date: 2017-07-07  12:56  (GMT-08:00) 
To: "General Discussion: On-Topic and Off-Topic Posts"  
Subject: Announcing: VCF PNW 

Vintage Computer Federation is pleased to announce an expansion of the
Vintage Computer Festival series to the Pacific Northwest.

The first VCF PNW will be held at Living Computers: Museum + Labs in
Seattle, Washington on February 10-11, 2018.  Seattle is a rich and vibrant
tech hub with beautiful scenery and every variety of rain possible, but it
has been missing the Vintage Computer Festival experience.  With the
cooperation of the LCM+L we are fixing that by providing a weekend full of
interesting exhibits and even more interesting people in what is already a
great destination.

In the next few weeks we will put out more formal calls for exhibitors,
volunteers, and speakers.  If you would like to chat feel free to reach out
to me at mich...@vcfed.org.

Vintage Computer Federation is a national user group serving collectors,
hobbyists, and anyone interested in the history of computing.  More
information about the Vintage Computer Federation can be found at
http://vcfed.org/.  Living Computers: Museum + Labs provides a
one-of-a-kind, hands-on experience with computer technology from the 1960s
to the present.  The LCM+L is online at http://www.livingcomputers.org/.


Thanks,
Michael, on behalf of the Vintage Computer Federation

Re: Any 7 track drives available?

[Chuck Guzis via cctalk]

On 07/07/2017 05:26 PM, Ethan Dicks wrote:
n't know of how much time you want to spend on it
>> 
>> (Offlist)
> 
> It wasn't off-list...
> 
> -ethan


I realized that just after I hit "send".

My apologies to the list--I really don't want to clutter things up.

--Chuck

Re: Any 7 track drives available?

[Ethan Dicks via cctalk]

On Fri, Jul 7, 2017 at 8:20 PM, Chuck Guzis via cctalk
 wrote:
> On 07/07/2017 04:39 PM, Al Kossow via cctalk wrote:
>> Don't know of how much time you want to spend on it
>
> (Offlist)

It wasn't off-list...

-ethan

Re: Any 7 track drives available?

[Chuck Guzis via cctalk]

On 07/07/2017 04:39 PM, Al Kossow via cctalk wrote:
> Can you come up with any HP 7970 drives?
> I have spare 7/9 track read-only combo head stacks
> Don't know of how much time you want to spend on it

(Offlist)

I don't know, Al.  I've got 6 tapes in a batch of 50 that are 7/556 and
are labeled with "Lunar Orbiter" labels.  I suspect that all 5 missions
are covered, but I don't know if I want to even submit a bid on getting
these read.  These are all from the JPL warehouse.  Probably just
digital survey data, but who knows?

The remainder are all late 70s and 80s 9 track.   But these are 66-69
vintage.

Suggestions on how to proceed would be appreciated.

--Chuck

Re: Any 7 track drives available?

[Al Kossow via cctalk]

Can you come up with any HP 7970 drives?
I have spare 7/9 track read-only combo head stacks
Don't know of how much time you want to spend on it

On 7/7/17 2:32 PM, Chuck Guzis via cctalk wrote:
> Hi Gang,
> 
> I just got another batch of tapes.  While the customer specified 9
> track, there are a bunch of 7 track/556 bpi tapes in the mix.
> 
> Anyone have a drive that they're willing to part with/loan for these things?
> 
> Thanks,
> Chuck
> 

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: Announcing: VCF PNW

[geneb via cctalk]

On Fri, 7 Jul 2017, Michael Brutman via cctalk wrote:


Vintage Computer Federation is pleased to announce an expansion of the
Vintage Computer Festival series to the Pacific Northwest.


Finally! :)

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

Any 7 track drives available?

[Chuck Guzis via cctalk]

Hi Gang,

I just got another batch of tapes.  While the customer specified 9
track, there are a bunch of 7 track/556 bpi tapes in the mix.

Anyone have a drive that they're willing to part with/loan for these things?

Thanks,
Chuck

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: tape baking

[Rob Jarratt via cctalk]

> I long to hear again the sound of the line printer that was attached to
the
> DECSYSTEM-20 I used to use. I think it was a drum printer but I don't know
the
> model (I may have some materials around that mention the model, not sure
> where they are now though). I could never house one of these though, if
any
> still exist.
> 


I looked it up, it was a DEC LP20H that they had. I'd love to hear one of
those running again. Do any still exist?

Regards

Rob

Announcing: VCF PNW

[Michael Brutman via cctalk]

Vintage Computer Federation is pleased to announce an expansion of the
Vintage Computer Festival series to the Pacific Northwest.

The first VCF PNW will be held at Living Computers: Museum + Labs in
Seattle, Washington on February 10-11, 2018.  Seattle is a rich and vibrant
tech hub with beautiful scenery and every variety of rain possible, but it
has been missing the Vintage Computer Festival experience.  With the
cooperation of the LCM+L we are fixing that by providing a weekend full of
interesting exhibits and even more interesting people in what is already a
great destination.

In the next few weeks we will put out more formal calls for exhibitors,
volunteers, and speakers.  If you would like to chat feel free to reach out
to me at mich...@vcfed.org.

Vintage Computer Federation is a national user group serving collectors,
hobbyists, and anyone interested in the history of computing.  More
information about the Vintage Computer Federation can be found at
http://vcfed.org/.  Living Computers: Museum + Labs provides a
one-of-a-kind, hands-on experience with computer technology from the 1960s
to the present.  The LCM+L is online at http://www.livingcomputers.org/.


Thanks,
Michael, on behalf of the Vintage Computer Federation

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 
> 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

Elan 5000 Eprom Programmer someone?

[Holm Tiffe via cctalk]

Hi,

I've got an Elan 5000 Epromer from a friend in the past.
The Prommer has an ZIFPAC-523 installed which seems to be the same as
the ZIFPAC-932 but with only five Textool Sockets populated on the PCB.

I've cleaned it up a little ans since the ROM moule is missing I've
build my own following the information available from here

http://baddinsbits.altervista.org/e5000.html

and there

http://matthieu.benoit.free.fr/ELAN_5000_turbo_programmer.htm

I've tried all the firmware versions (2.05, 6.04, 7.03 and that 4.0I)
but I get after RAM Check "MISMATCH S/W H/W", a repeated display "spi"
or simple a "POWER OFF".

The Faceplate says that I have an HDWR. ISS 2.00, the main PCB says 
"EF PER MCU PCP 393 ISS 4".

Has someone a similar programmer and can read out the Firmware from
the firmware plugin module (which contains an 27C010)?

Thanks in Advance,

Holm

-- 
  Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, 
 Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
i...@tsht.de Fax +49 3731 74200 Tel +49 3731 74222 Mobil: 0172 8790 741

Re: DEC TRAX documentation set for sale

[Paul Koning via cctalk]

> On Jul 6, 2017, at 5:53 PM, Alan Frisbie  wrote:
> 
> On 07/06/2017 02:01 PM, Paul Koning wrote:
>> 
>>> On Jul 6, 2017, at 4:20 PM, Alan Frisbie wrote:
>>> 
>>> ...
>>> TRAX was designed around a modified version of RSX-11M-Plus,
>>> v1.0, yet no mention of it survives today. Indeed, a year after
>>> its announcement, it appeared to have sunk without a trace.
>> 
>> I don't remember the exact timing, but my recollection is that
> > TRAX was cancelled within a few weeks of when it first shipped.
> 
> That's pretty fast to kill a product!   Do you have any idea what
> the reason was?   (Both the real reason and what was announced?)

No to both.  I only remember TRAX at all because I saw some of the manuals 
sitting around, nice binders with a picture of a fast train on the cover.  And 
I remember the special terminals built for TRAX (VT62).  But that was in the 
DEC office in Merrimack (MKO) which wasn't where TRAX or RSX development was 
done, so I wasn't close enough to where the action was to get more details.

> It seems to me that a product would have been a good match for
> the VAX, which was announced about the same time.   I wonder why
> that never happened?

VAX/TRAX, neat.  It may be that initially VMS wasn't all that efficient or 
responsive.  There were over the years a number of cases where VAXen were 
pushed by management into roles that customers didn't believe they were ready 
for.  Timesharing, for example -- DEC tried to kill RSTS several times, but it 
lived on much longer than they wanted.  (IAS was the first "RSTS killer", hah.) 
 And I still have an "RT32" button, part of an effort among some engineers to 
create a fast thin real-time OS for VAX, in the spirit of RT11.  Nothing came 
of that, though, apart from some unauthorized buttons.

paul

Re: OMNI to USB Interface

[Ed via cctalk]

Wow- I can use a paper tape version  too...
but thought the  usb would be  good  for quickly loading  anything?
 
 
 
 
In a message dated 7/6/2017 11:56:42 P.M. US Mountain Standard Time,  
cctalk@classiccmp.org writes:

Hello  Ed,
I don't know a lot about the project or interface and am waiting to  hear 
if it is still available before I spend time researching it. Why would  you 
need it to load FOCAL?
I think I have FOCAL on paper tape if that is  any use.
Regards,   Baz


Sent from my  iPad

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: tape baking

[Ron Pool via cctalk]

Thanks, Chuck!

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

> On 07/06/2017 11:43 AM, Paul Koning via cctalk wrote:
>
> > EBCDIC is easy, just grab an IBM Green Card.  I'd recomment not using
> > a translation if possible, since translations are likely to be lossy.
> > There are EBCDIC characters that have no ASCII analog.
>
> All else being equal, I'd agree--but you can either work with a .tap
> file or the individual filemark separated files, which means that you'll
> also have read the label records and interpret them to get the file name
> and blocking.
>
> All in all, if you're not used to this, the ASCII should do.
>
> --Chuck
>
>


-- 
Ron Pool 

OMNI to USB Interface

[Barry via cctalk]

Hello Ed,
I don't know a lot about the project or interface and am waiting to hear if it 
is still available before I spend time researching it. Why would you need it to 
load FOCAL?
I think I have FOCAL on paper tape if that is any use.
Regards,   Baz


Sent from my iPad

Re: tape baking

[Ron Pool via cctalk]

I'd love to also get a copy.  ASCII would be my preference.

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

> On 07/06/2017 11:09 AM, Mark J. Blair via cctalk wrote:
>
> > Did you apply it to the whole tape prior to reading it, or did you apply
> it in place on the tape drive while reading the tape?
>
> The whole tape--I ran my tape cleaner at low speed and used a strip of
> 1/2" thick synthetic felt glued to a large PVC pipe fitting as the
> applicator.  Needless to mention, it was on the supply side of the
> cleaner, or else the tape wouldn't have made it through.   The
> lubrication lasted for two reads of the tape.
>
> I think I did a moldy tape of Noel's last year this way also and got the
> whole thing.
>
> > Are they online anywhere? I wouldn't mind taking a look at them.
>
> No, but I can put a copy up on my Box account.  Do you want the original
> EBCDIC .tap image or the ASCII-translated files?
>
> --Chuck
>
>


-- 
Ron Pool