Re: Tape imaging

[Chuck Guzis]

On 08/11/2016 10:07 PM, couryhouse wrote:
> 
> 
> Chuck we have tape we also have one of the 30 something track
> heads at smecc. I guess  won would have to build  the  motorized
> wingaxas... to pull the tape. ... the electronics can be recreated...
> We figure the head is the hard part. ha!  and a empty take up
> reel! Anyone habe one?Ed www.smecc.org

31 tracks if I read the manual right.  The tape itself is a mylar
sandwich, so it should be plenty durable.  Reel motors should be no
great deal--maybe you could scavenge them from an old Ampex Quadruplex
VTR...

--Chuck

Re: Tape Imaging

[jim stephens]

On 8/11/2016 6:43 PM, Chuck Guzis wrote:

On 08/11/2016 02:08 PM, Stan Sieler wrote:


I've had a couple of tapes with "fooler" double file marks.  The first
was a zero-length file--had I thought to look at the block count
(00) in the HDR label, it would have been obvious.

The second was a bit more involved--the tape started off in 6250 GCR
mode and read to EOF just fine.  However, I picked up perhaps half a MB
of data, which seemed too little for a 10" reel.  Rewind, manually set
the density to 1600 and read, letting the drive skip over what was now
interpreted as erased tape.  What followed was a complete half-reel of
1600 data that would have been lost.  My guess is that someone had an
"oh sh*t" moment, reset the density manually and finished the tape off
in the lower density as intended.
That sounds like someone just set a Cipher 990 or such to 6240 GCR and 
overwrote it.  The 1600bpi was residue which was previous tape contents?


Sometimes the stars align and there are not any tape errors when you do 
what you do.  Only way to know is whether there is a PE burst at the 
start of the 1600bpi data, which would be there if they had done what 
you suggest.  And PE bursts should only appear @ the BOT I think as you 
say with streamers.


I don't know what the rack Pertec PE formatters did.  Those were the 4" 
high boxes with a couple of boards with the original twin 50 pin input 
IDC connectors on the back, and cabling out to the tape, which was a 
Pertec of some sort.


I also had a 6" 600' only Pertec formatted, with a builtin PE 
formatter.  I don't know if either wrote the PE Burst.


That was mainly useful on the Cipher 1600 / 3200 drives to figure out 
the density on read.  (I think).

thanks
Jim

   I don't know if this could be
recovered with most SCSI streamers, which don't allow density changes
except at BOT.

War stories...I love 'em.

--Chuck











(Yes, that begs the question...if you're archiving a tar tape ... do
you *want* the data past the first EOF?  (Which could be part of a
prior (and longer) tar, or something else.))  (And then there are the
people who put tar after tar after tar on the same tape :)

Stan

Re: Tape imaging

[couryhouse]

Chuck we have tape we also have one of the 30 something track heads at 
smecc. I guess  won would have to build  the  motorized  wingaxas... to 
pull the tape. ... the electronics can be recreated...  We figure the head is 
the hard part. ha!  and a empty take up reel! Anyone habe one?Ed 
www.smecc.org

Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Chuck Guzis  
Date: 8/11/16  21:21  (GMT-07:00) 
To: "General Discussion: On-Topic and Off-Topic Posts"  
Subject: Re: Tape imaging 

On 08/11/2016 07:36 PM, Al Kossow wrote:
> One of the highest projects I have in the queue is getting one of
> John's M4 9914V drives with 18 track MR heads running in my new lab
> at CHM.

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

Re: Tape imaging

[Al Kossow]

On 8/11/16 9:21 PM, Chuck Guzis wrote:
> Suppose someone found a box of
> tapes from an old Honeywell Datamatic mainframe.

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

Re: Tape imaging

[Al Kossow]

On 8/11/16 9:21 PM, Chuck Guzis wrote:
> On 08/11/2016 07:36 PM, Al Kossow wrote:
>> One of the highest projects I have in the queue is getting one of
>> John's M4 9914V drives with 18 track MR heads running in my new lab
>> at CHM.
> 
> I've always wondered how far someone would go to retrieve data from
> media that's really off the beaten path.

actually, that is to recover 7 or 9 track using an ibm 3480 head stack

maybe some day, i'll try respooling a Whirlwind tape and see if I can
pull any data off it. I did actually turn up info on the Raytheon drive
in the CHM archives, and we have at least one with a head to measure
track spacing

Re: Tape imaging

[Chuck Guzis]

On 08/11/2016 07:36 PM, Al Kossow wrote:
> One of the highest projects I have in the queue is getting one of
> John's M4 9914V drives with 18 track MR heads running in my new lab
> at CHM.

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

Re: the value of old test and repair equipment

[dwight]

The y have used Fairchild for their source.

If so, that explains the high rate of failure.

Years ago when at Intel, we disqualified Fairchild

as a source for parts because of the poor testing

and high failure rates.

Dwight



From: cctalk  on behalf of 
curiousma...@gmail.com 
Sent: Thursday, August 11, 2016 12:12:14 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: the value of old test and repair equipment

For some reason the 7474's have a higher failure rate than other TTL IC's in HP 
equipment. I don't know if it's true in general for 1970's TTL. Signetics MSI 
chips (counters and stuff) seem to be prone to failure too.
Marc


>
> All this talk of older test equipment reminds me of the HP 4261A LCR
> bridge I repaired a while back, last winter I think.
>
>
> My dad found the 4261A in the garbage years ago, and it seemed to work
> fine, until one day he powered it up and the display showed garbage.
> He decided to open it up, and noticed some uncovered windowed EPROMs.
> Knowing that EPROMs sometimes flip bits in their old age, we decided
> that was the first place we would look. We were also able to locate
> the full HP service manual in PDF form for the instrument which helped
> tremendously. In typical HP fashion, it had full theory of operation,
> schematics, state diagrams, etc.
>
>
> Now, I have an EPROM burner that does your typical JEDEC pinout parts,
> 27 series and such. The issue is that these were Intel i1702A's from
> the early 70's I think. Not only are 1702's a totally different
> pinout, but they run on 14V (a +5V, and a -9V rail, with no connected
> ground, this is how intel got TTL levels on a MOS chip at the time).
> The 4261A has a total of 4 1702's, two of which form a finite state
> machine which controls the instrument, while the other two perform
> display decoding.
>
>
> I had to pull out my dad's DeVry Console 80, which has adjustable
> positive and negative supplies, and I manually clocked out the data
> and compared the contents to a dump I found online. I started with the
> state machine EPROMs, and compared the data. I did find a few
> discrepancies, but there was too much difference to have been bit rot.
> Given the sudden nature of the issue, I would have expected one, at
> most a couple bit flips, or something much more drastic (like total
> chip failure). Upon reading through the state diagrams in the HP
> manual, I noticed that there was a change noted in the state diagram
> between certain minor revisions of the 4261A. I looked at what the
> changes were, and deduced that my ROMs were in fact correct for the
> serial number prefix.
>
>
> At a dead end with the EPROMs, I decided to see if the state machine
> was even running at all. I used a DVM in DC mode, and measured perfect
> TTL ones and zeroes on all the state number outputs, which means those
> outputs weren't changing: the state machine was stuck. I wrote down
> the state it was stuck in and referred to the state diagram. I noticed
> something interesting. The state machine in the 4261A is able to
> evaluate simple conditions and control flow based on those. The state
> path to get to the state that the FSM was stuck on meant the FSM was
> always taking one of the conditional paths (always true, or always
> false, I don't remember which). At that point, I started looking into
> the condition circuitry, tracing out the path, checking IC's as I
> worked my way back, until I made it back to 1/2 of a 7474 which had a
> set input that was stuck active (low). This pin went to a pullup
> resistor, and nothing else in our unit (certain options used this pin,
> but not ours). We desoldered the IC, and sure enough, that pin was
> shorted to ground internal to the chip. We replaced it with a 74LS74,
> and the 4261A has been working great ever since, even with the
> original 40 year old 1702's.
>
>
> Also, on the topic of interesting HP products, and perhaps my personal
> favorite so far, is the HP dynamic signal analyzer 35670A. This
> instrument can perform all sorts of cool measurements. It can produce
> a test signal, and measure two different points in the circuit being
> measured. The measurement input channels give you a complex number
> phasor of the measured signal, which means you can do all sorts of
> cool measurements of networks, especially since you can do complex
> number math with the equation support of the instrument. The signal
> generator will perform sweeps too, of course. This was very useful
> determining whether the speaker crossovers my dad built were working
> as intended (actually they weren't, and this instrument helped us
> uncover a problem). We also used this to do inductor and capacitor
> characterization. There are all sorts of applications this instrument
> is good for.
>
>
> Joe Zatarski

Re: VAX file format conversion

[Ian S. King]

On Thu, Aug 11, 2016 at 6:56 PM, Douglas Taylor 
wrote:

>
>> Ian ;
>
> I set the baud rate for 300, it was torture, but it worked. However, on
> the vax I had to make sure the terminal width was set to 132.
>
> The license file ran past 80 characters occasionally and screwed things
> up, because the Vax would 'wrap' those lines.
>
> The next hurdle is to get the networking functioning again.  Are there any
> tricks I should know about concerning the AUI to 10BaseT adapters?
>
> It has been about a dozen years since I last did this and at that time it
> was working.
>
> Doug
>
>
It's not so much the baud rate but the character rate, at least for
something like a VAX.  For a PDP-8, baud rate is important, too!

I have used (and continue to use) a lot of those AUI-TP adapters, and they
all seemed to be plug-and-play.  I've also used old network hubs with BNC
connectors to do thinnet networks - necessary for some of my machines.  Oh,
ISTR that a lot of VAXstations did have a button near the AUI and BNC
connectors asking you to choose.  Choose wisely, Grasshopper, and you shall
be rewarded with packet traffic.  Cheers -- Ian

-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School 
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

Re: Tape imaging

[Al Kossow]

One of the highest projects I have in the queue is getting one of John's
M4 9914V drives with 18 track MR heads running in my new lab at CHM.

On 8/11/16 8:52 AM, Chuck Guzis 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.
> 

Re: Tape imaging

[aswood]

 I do have two original CDC 603 tape drives with controller, but to be honest 
it would be quite a challenge to hook them to a modern system.

> Am 11.08.2016 um 17:52 schrieb Chuck Guzis :
> 
>> On 08/11/2016 07:15 AM, Mark Linimon wrote:
>>> On Wed, Aug 10, 2016 at 05:10:54PM -0700, Al Kossow wrote:
>>> Tom Hunter just got a release from CDC for the use of CDC software
>>> for non-commercial use, so any CDC tapes out in the wild are going
>>> to be of great interest.
>> 
>> Congratulations to Tom.
> 
> 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
> 

Re: Tape Imaging

[Al Kossow]

On 8/11/16 6:43 PM, Chuck Guzis wrote:
> I don't know if this could be
> recovered with most SCSI streamers, which don't allow density changes
> except at BOT.
>

I've not been able to figure how to do that out on any of the drives I've tried

Re: VAX file format conversion

[Douglas Taylor]

On 8/11/2016 4:47 PM, Ian S. King wrote:

On Thu, Aug 11, 2016 at 1:26 PM, emanuel stiebler  wrote:


On 2016-08-11 14:08, Douglas Taylor wrote:


I have a MicroVax 4000 that I am trying to update the license PAKs on,
the last time I had valid PAKs on this machine was in 2002 (Hobbyist
Licenses).

I registered and have received the new Hobbyist License PAKs.

I connected a laptop and transferred the text file using C-Kermit on the
VAX and hyperterminal on the laptop.

When I go to execute the file, I get an error:

$@hobbyist-use-only-va.txt

%RMS-W-RTB 512 bye record to large for user buffer

It appears that when the file was transferred it showed up on the vax
with fixed length records of 512 bytes, not variable length.

Can I convert the file on the VAX?

Is there a setting for C-Kermit that I need to change?

Is Hyperterminal screwing things up?


I usually just send it a textfile, so open the editor, put it in input
mode, download the file, save it. Don't forget, to make a dealy after every
 ...



I've always just set the terminal emulator to a slow per-character rate and
pushed it into the console.  As long as VMS can process each line before
the next one starts, you should be golden.  -- Ian


Ian ;

I set the baud rate for 300, it was torture, but it worked. However, on 
the vax I had to make sure the terminal width was set to 132.


The license file ran past 80 characters occasionally and screwed things 
up, because the Vax would 'wrap' those lines.


The next hurdle is to get the networking functioning again.  Are there 
any tricks I should know about concerning the AUI to 10BaseT adapters?


It has been about a dozen years since I last did this and at that time 
it was working.


Doug

Re: Tape Imaging

[Chuck Guzis]

On 08/11/2016 02:08 PM, Stan Sieler wrote:

> One important thing to do, depending upon your operating system and
> tape drive characteristics of course, is to issue read requests for a
> few bytes more than you expect ... because with some OSs and some
> kinds of drives, if you ask for X bytes and the record has more than
> X, you'll quietly get X and the rest will be discarded.   (That came
> up in a court case where I was an expert witness ... an alleged
> 'expert' had copied a 9-track tape (badly) and lost data because the
> records were larger than he expected, and his copying tool didn't
> have that simple safeguard in it.)

If you're using a SCSI drive, that's pretty simple to read the tape in
"variable" block mode, leaving a generous buffer--the result sense
status will tell how much was read.

Pertec drives are super-stupid, so you start reading and counting bytes
until the block ends.

> A second thing is to be somewhat aggressive in reading the 'end' of
> the tape. The backup tapes I frequently encounter supposedly end with
> two EOFs in a row ... except for a few that happen to have extra data
> past that point :) (Of course, with 9 track tapes, you run the risk
> of going off the end!)

I've had a couple of tapes with "fooler" double file marks.  The first
was a zero-length file--had I thought to look at the block count
(00) in the HDR label, it would have been obvious.

The second was a bit more involved--the tape started off in 6250 GCR
mode and read to EOF just fine.  However, I picked up perhaps half a MB
of data, which seemed too little for a 10" reel.  Rewind, manually set
the density to 1600 and read, letting the drive skip over what was now
interpreted as erased tape.  What followed was a complete half-reel of
1600 data that would have been lost.  My guess is that someone had an
"oh sh*t" moment, reset the density manually and finished the tape off
in the lower density as intended.   I don't know if this could be
recovered with most SCSI streamers, which don't allow density changes
except at BOT.

War stories...I love 'em.

--Chuck










> 
> (Yes, that begs the question...if you're archiving a tar tape ... do
> you *want* the data past the first EOF?  (Which could be part of a
> prior (and longer) tar, or something else.))  (And then there are the
> people who put tar after tar after tar on the same tape :)
> 
> Stan
> 


-- 
--Chuck
-

"The first thing we do, let's kill all the spammers."

SWTPC keyboard foil patterns

[Brad H]

Hey guys,
In Don Lancaster's 'Low cost keyboard and ascii encoder' article (Apr 1974), he 
mentions in the parts list that the SWTPC keyboard mentioned in the article had 
foil patterns available, full size, free on request.  I was wondering if anyone 
out there had them or knew where they might be found.  I checked SWTPC and 
Tinaja but they only have the article.  I've emailed Don in case he had them 
but probably doubtful.
Reason I ask is I was rather pleased with how my original TVT reproduction 
boards turned out, and I have a second CT1024 terminal here in need of a 
keyboard.  Rather than rigging something up I thought maybe I could just 
recreate the PCB.  I can already make the keycaps and the switches themselves 
are not beyond my ability either.
Many thanks in advance if anyone has these.
Brad

Sent from my Samsung device

Re: Tape Imaging

[Stan Sieler]

Joining the list of "my format" posts ...

Mine also records retry information (because MPE on the HP 3000
optionally reports if a retry was done to get a successful tape read),
and setmarks (which differ from EOFs), as well as error information.
(That retry information is important ... it could indicate a silent loss
of information.)

But, I must admit...it didn't occur to me to store metadata like
a photo of the tape, etc.  Nice!

When copying / archiving tapes ...

One important thing to do, depending upon your operating system
and tape drive characteristics of course, is to issue read requests
for a few bytes more than you expect ... because with some OSs and
some kinds of drives, if you ask for X bytes and the record has more than X,
you'll quietly get X and the rest will be discarded.   (That came up in a
court case where I was an expert witness ... an alleged 'expert' had
copied a 9-track tape (badly) and lost data because the records were larger
than
he expected, and his copying tool didn't have that simple safeguard in it.)

A second thing is to be somewhat aggressive in reading the 'end' of the
tape.
The backup tapes I frequently encounter supposedly end with two EOFs
in a row ... except for a few that happen to have extra data past that
point :)
(Of course, with 9 track tapes, you run the risk of going off the end!)

(Yes, that begs the question...if you're archiving a tar tape ... do you
*want*
the data past the first EOF?  (Which could be part of a prior (and longer)
tar,
or something else.))  (And then there are the people who put tar after tar
after tar on the same tape :)

Stan

Re: Spam [was Re: still looking for that stuff?]

[william degnan]

I remember the first time I encountered spam1995 or so using my old
CompuServe account.  One day I was like "what is all this crap?" Now that
was some serious spam going on then.  Today's is nothing like that if you
ask me.  I have a nice filter system on my private server.  Botta bing.
B

-- 
Bill Degnan

Re: VAX file format conversion

[Douglas Taylor]

On 8/11/2016 4:47 PM, Ian S. King wrote:

On Thu, Aug 11, 2016 at 1:26 PM, emanuel stiebler  wrote:


On 2016-08-11 14:08, Douglas Taylor wrote:


I have a MicroVax 4000 that I am trying to update the license PAKs on,
the last time I had valid PAKs on this machine was in 2002 (Hobbyist
Licenses).

I registered and have received the new Hobbyist License PAKs.

I connected a laptop and transferred the text file using C-Kermit on the
VAX and hyperterminal on the laptop.

When I go to execute the file, I get an error:

$@hobbyist-use-only-va.txt

%RMS-W-RTB 512 bye record to large for user buffer

It appears that when the file was transferred it showed up on the vax
with fixed length records of 512 bytes, not variable length.

Can I convert the file on the VAX?

Is there a setting for C-Kermit that I need to change?

Is Hyperterminal screwing things up?


I usually just send it a textfile, so open the editor, put it in input
mode, download the file, save it. Don't forget, to make a dealy after every
 ...



I've always just set the terminal emulator to a slow per-character rate and
pushed it into the console.  As long as VMS can process each line before
the next one starts, you should be golden.  -- Ian

Yes, I am using the console port and I do remember using that trick a 
long time ago.  I think I'll try that, and also the set file/attr method.


Earlier I tried the trick of going into the editor and blasting the file 
at the VAX, it didn't work at 9600 baud, I have to show more patience.


Doug

Re: Spam [was Re: still looking for that stuff?]

[Ian S. King]

On Thu, Aug 11, 2016 at 9:48 AM, ANDY HOLT  wrote:

>
> >> Spam will not stop until the last spammer is dead.
> >
> > Actually, it's really simple to stop spam.  Simple, not easy.
> >
> > You just need to delegate responsibility along with authority when
> > handing out netblocks, registering domain names, and the like.
>
> When there were only tens of thousands of mail nodes (few of which had
> more than a
> few thousand accounts it was practical to put the responsibility on
> postmasters.
> With tens of millions (often with millions of customers) that is no longer
> so.
>

"Every time you send a spam message, you kill a kitten.  Think of the
kittens.  Unless you're a dog person - then think of the puppies."

-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School 
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

Re: VAX file format conversion

[Ian S. King]

On Thu, Aug 11, 2016 at 1:26 PM, emanuel stiebler  wrote:

> On 2016-08-11 14:08, Douglas Taylor wrote:
>
>> I have a MicroVax 4000 that I am trying to update the license PAKs on,
>> the last time I had valid PAKs on this machine was in 2002 (Hobbyist
>> Licenses).
>>
>> I registered and have received the new Hobbyist License PAKs.
>>
>> I connected a laptop and transferred the text file using C-Kermit on the
>> VAX and hyperterminal on the laptop.
>>
>> When I go to execute the file, I get an error:
>>
>> $@hobbyist-use-only-va.txt
>>
>> %RMS-W-RTB 512 bye record to large for user buffer
>>
>> It appears that when the file was transferred it showed up on the vax
>> with fixed length records of 512 bytes, not variable length.
>>
>> Can I convert the file on the VAX?
>>
>> Is there a setting for C-Kermit that I need to change?
>>
>> Is Hyperterminal screwing things up?
>>
>
> I usually just send it a textfile, so open the editor, put it in input
> mode, download the file, save it. Don't forget, to make a dealy after every
>  ...
>
>
I've always just set the terminal emulator to a slow per-character rate and
pushed it into the console.  As long as VMS can process each line before
the next one starts, you should be golden.  -- Ian

-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School 
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

Re: VAX file format conversion

[emanuel stiebler]

On 2016-08-11 14:08, Douglas Taylor wrote:

I have a MicroVax 4000 that I am trying to update the license PAKs on,
the last time I had valid PAKs on this machine was in 2002 (Hobbyist
Licenses).

I registered and have received the new Hobbyist License PAKs.

I connected a laptop and transferred the text file using C-Kermit on the
VAX and hyperterminal on the laptop.

When I go to execute the file, I get an error:

$@hobbyist-use-only-va.txt

%RMS-W-RTB 512 bye record to large for user buffer

It appears that when the file was transferred it showed up on the vax
with fixed length records of 512 bytes, not variable length.

Can I convert the file on the VAX?

Is there a setting for C-Kermit that I need to change?

Is Hyperterminal screwing things up?


I usually just send it a textfile, so open the editor, put it in input 
mode, download the file, save it. Don't forget, to make a dealy after 
every  ...

Re: VAX file format conversion

[Ethan Dicks]

On Thu, Aug 11, 2016 at 4:08 PM, Douglas Taylor  wrote:
> $@hobbyist-use-only-va.txt
>
> %RMS-W-RTB 512 bye record to large for user buffer
>
> It appears that when the file was transferred it showed up on the vax with
> fixed length records of 512 bytes, not variable length.

Not an unusual occurrence with moving files to VMS.

> Can I convert the file on the VAX?

There may be an easy way to do that, depending if you've lost the line
terminators or not.  What does it look like when you TYPE the file or
EDIT it?

> Is there a setting for C-Kermit that I need to change?

http://www.columbia.edu/kermit/faq-c-bix.html

VMS C-Kermit ignores "SET FILE TYPE" on send and uses the RMS record
type (Fixed or Stream_LF) instead.  I used to use C-Kermit a lot and
remember having to SET FILE TYPE TEXT on both ends to get good files
through.  We also used a program named BACKPACK.EXE to encode
variable-length record filetypes (.OBJ, .OLB, etc.) into plaintext
files and back.  Much like uudecode/decode fits 8-bit binary data into
printable ASCII, BACKPACK.EXE also encodes the record length and the
RMS filetype metadata so that the reconstructed file is identical to
the original.

-ethan

VAX file format conversion

[Douglas Taylor]

I have a MicroVax 4000 that I am trying to update the license PAKs on, 
the last time I had valid PAKs on this machine was in 2002 (Hobbyist 
Licenses).


I registered and have received the new Hobbyist License PAKs.

I connected a laptop and transferred the text file using C-Kermit on the 
VAX and hyperterminal on the laptop.


When I go to execute the file, I get an error:

$@hobbyist-use-only-va.txt

%RMS-W-RTB 512 bye record to large for user buffer

It appears that when the file was transferred it showed up on the vax 
with fixed length records of 512 bytes, not variable length.


Can I convert the file on the VAX?

Is there a setting for C-Kermit that I need to change?

Is Hyperterminal screwing things up?

Doug

Re: Atlanta Open House Tomorrow

[Eric Christopherson]

How much for the LSI ADM-3A terminal (
https://drive.google.com/file/d/0BxqLDyoLYuCKekFoYnJqR1NBLWs/view?usp=sharing
)? Any idea on condition?

On Wed, Aug 10, 2016 at 6:25 PM, Jay West  wrote:

> I'm reposting this because I set the time on the classiccmp server
> incorrectly (forgot to add 12). Just in case the important post below
> showed
> up earlier in folks inbox, I wanted to make sure it showed up.
>
>
>
> I'm posting this on behalf of Cindy at Elecplus
>
>
>
> I can't post to cctalk when I am away from home. I am in Atlanta, and the
> owner of the warehouse hs agreed to let people come in tomorrow. Please can
> you post the following for me?
>
>
>
> First come first served, no shipping on the really cheap items. Model M
> 101/103 terminal keyboards $10 each, no cracked cases, may not have
> complete
> caps. Hundreds of keyboards for other terminals starting at $30 each,
> tested
> and complete. A full pallet of AEK 1 and 2 keyboards
>
>
>
> More expensive items include a Burroughs keyboard, complete and in good
> condition, a 1978 terminal in working condition, and the following
> terminals/keyboards, tested, no screen burn, keyboards are complete. DEC
> VT100 (no keyboards), 220, 320, 420.Wyse 50 and 60 with keyboards. Qume 62
> and 101+ with keyboards.Link MC2 and 3 with keyboards. ADDS 4000 with
> keyboards. HP 700/22, 700/43, 700/60, 700/90, 700/92, 700/94, 700/96 with
> keyboards.
>
>
>
> LOTS of working vintage test equip. Some pics are here:
> 
> https://drive.google.com/open?id=0BxqLDyoLYuCKbkEwdmlST2lKaUU
>
>
>
> Thank you!
>
>
>
> Cindy
>
>
>
>
>
>


-- 
Eric Christopherson

Re: Spam [was Re: still looking for that stuff?]

[ANDY HOLT]

>> Spam will not stop until the last spammer is dead.
>
> Actually, it's really simple to stop spam.  Simple, not easy.
>
> You just need to delegate responsibility along with authority when
> handing out netblocks, registering domain names, and the like.

When there were only tens of thousands of mail nodes (few of which had more 
than a
few thousand accounts it was practical to put the responsibility on 
postmasters. 
With tens of millions (often with millions of customers) that is no longer so.

Re: Spam [was Re: still looking for that stuff?]

[Fred Cisin]

On Thu, 11 Aug 2016, geneb wrote:
I think it would be more effective to stuff the spammer into a Brazen Bull 
and then force his children/family members to light the fire.  Televise it 
across all media outlets.  Spam should slow to a tiny, tiny, trickle after 
one or two of these little events...


Spam should reduce when word gets around that spammers are being tortured 
to death.


Decriminalize spammercide.


Spread the word - "spammers are already being murdered."

Re: Spam [was Re: still looking for that stuff?]

[geneb]

On Wed, 10 Aug 2016, Mouse wrote:


Spam will not stop until the last spammer is dead.


Actually, it's really simple to stop spam.  Simple, not easy.

You just need to delegate responsibility along with authority when
handing out netblocks, registering domain names, and the like.

I think it would be more effective to stuff the spammer into a Brazen Bull 
and then force his children/family members to light the fire.  Televise it 
across all media outlets.  Spam should slow to a tiny, tiny, trickle after 
one or two of these little events...



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

Re: Tape imaging

[Mark Linimon]

On Wed, Aug 10, 2016 at 05:10:54PM -0700, Al Kossow wrote:
> Tom Hunter just got a release from CDC for the use of CDC software for
> non-commercial use, so any CDC tapes out in the wild are going to be of
> great interest.

Congratulations to Tom.

mcl

Re: Atlanta Open House Tomorrow

[Ethan Dicks]

On Wed, Aug 10, 2016 at 8:15 PM, Al Kossow  wrote:
> If anyone goes there would you PLEASE look for a Qume 201 and Televideo 965 
> keyboard for me

Likewise, I'm looking for a couple of AT/Teletype keyboards for my
5620/Blit and my 730+.  They do _not_ have a round DIN plug, which
distinguishes them from 98% of what's out there.  They have an 8p8c
connector ("RJ-45").

There are several matching keyboards with different numbers of keys
(~98-103).  56K-341-AAN is one part number.  Keyboards that will work
are the same ones used on the AT 4410 and Teletype 5410 terminal.

I'm also seeing part numbers in the technical drawings
(http://www.brouhaha.com/~eric/retrocomputing/att/5620/att5620_eng.pdf
pp 87-95) like:
 56K224
 56K229
 56K230
 410896
 410967

It appears to have 6 of the 8 pins in use - serial in, serial out,
+5V, -12V, signal GND, and frame GND (it makes its own -5V for the MCU
from a zener diode on the -12V line).  All of this plus the 1.8432MHz
crystal, suggest to me a simple async protocol.  This would make a
keyboard emulator simple to construct once someone has sniffed the
protocol.

One is good.  Two is better.

Thanks,

-ethan

Re: Spam [was Re: still looking for that stuff?]

[Todd Goodman]

* Mouse  [160810 21:59]:
[..SNIP..]
> I suppose that's what happens when you put the Department of Commerce
> in charge of something.  As long as it doesn't collapse far enough to
> stop concentrating money in the hands of large corporations, there's
> nothing wrong with it.
> 
> /~\ The ASCII   Mouse
> \ / Ribbon Campaign
>  X  Against HTML  mo...@rodents-montreal.org
> / \ Email! 7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

That's what happens when you put a government in charge of anything.

My $.02,

Todd

Re: Tape imaging

[couryhouse]

Have the tape sets from the phx univac operations center that need to be imaged 
some day!Ed#


Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Al Kossow  
Date: 8/10/16  17:10  (GMT-07:00) 
To: cct...@classiccmp.org, "General Discussion: On-Topic and Off-Topic Posts" 
 
Subject: Re: Tape imaging 

Related, since it hasn't been mentioned on this list.
Tom Hunter just got a release from CDC for the use of CDC software for 
non-commercial use,
so any CDC tapes out in the wild are going to be of great interest.

On 8/10/16 6:22 AM, asw...@t-online.de wrote:

> Now I do have a big pile of CDC, DEC, HP, Convex and IBM tapes and I'd like 
> to create tape images to file to save the tapes content.

Re: Tape imaging

[Tor Arntsen]

> On 08/10/2016 07:42 AM, Al Kossow wrote:
>
>> congratulations, you reinvented .tap format.. badly.
>>
>> how did you handle unreadable blocks.

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  wrote:
> Additionally, how was the metadata handled?  (i.e. information about
> equipment used, paper labels, maybe a photo of the tape reel itself?).

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

Re: the value of old test and repair equipment

[curiousmarc3]

For some reason the 7474's have a higher failure rate than other TTL IC's in HP 
equipment. I don't know if it's true in general for 1970's TTL. Signetics MSI 
chips (counters and stuff) seem to be prone to failure too. 
Marc


> 
> All this talk of older test equipment reminds me of the HP 4261A LCR
> bridge I repaired a while back, last winter I think.
> 
> 
> My dad found the 4261A in the garbage years ago, and it seemed to work
> fine, until one day he powered it up and the display showed garbage.
> He decided to open it up, and noticed some uncovered windowed EPROMs.
> Knowing that EPROMs sometimes flip bits in their old age, we decided
> that was the first place we would look. We were also able to locate
> the full HP service manual in PDF form for the instrument which helped
> tremendously. In typical HP fashion, it had full theory of operation,
> schematics, state diagrams, etc.
> 
> 
> Now, I have an EPROM burner that does your typical JEDEC pinout parts,
> 27 series and such. The issue is that these were Intel i1702A's from
> the early 70's I think. Not only are 1702's a totally different
> pinout, but they run on 14V (a +5V, and a -9V rail, with no connected
> ground, this is how intel got TTL levels on a MOS chip at the time).
> The 4261A has a total of 4 1702's, two of which form a finite state
> machine which controls the instrument, while the other two perform
> display decoding.
> 
> 
> I had to pull out my dad's DeVry Console 80, which has adjustable
> positive and negative supplies, and I manually clocked out the data
> and compared the contents to a dump I found online. I started with the
> state machine EPROMs, and compared the data. I did find a few
> discrepancies, but there was too much difference to have been bit rot.
> Given the sudden nature of the issue, I would have expected one, at
> most a couple bit flips, or something much more drastic (like total
> chip failure). Upon reading through the state diagrams in the HP
> manual, I noticed that there was a change noted in the state diagram
> between certain minor revisions of the 4261A. I looked at what the
> changes were, and deduced that my ROMs were in fact correct for the
> serial number prefix.
> 
> 
> At a dead end with the EPROMs, I decided to see if the state machine
> was even running at all. I used a DVM in DC mode, and measured perfect
> TTL ones and zeroes on all the state number outputs, which means those
> outputs weren't changing: the state machine was stuck. I wrote down
> the state it was stuck in and referred to the state diagram. I noticed
> something interesting. The state machine in the 4261A is able to
> evaluate simple conditions and control flow based on those. The state
> path to get to the state that the FSM was stuck on meant the FSM was
> always taking one of the conditional paths (always true, or always
> false, I don't remember which). At that point, I started looking into
> the condition circuitry, tracing out the path, checking IC's as I
> worked my way back, until I made it back to 1/2 of a 7474 which had a
> set input that was stuck active (low). This pin went to a pullup
> resistor, and nothing else in our unit (certain options used this pin,
> but not ours). We desoldered the IC, and sure enough, that pin was
> shorted to ground internal to the chip. We replaced it with a 74LS74,
> and the 4261A has been working great ever since, even with the
> original 40 year old 1702's.
> 
> 
> Also, on the topic of interesting HP products, and perhaps my personal
> favorite so far, is the HP dynamic signal analyzer 35670A. This
> instrument can perform all sorts of cool measurements. It can produce
> a test signal, and measure two different points in the circuit being
> measured. The measurement input channels give you a complex number
> phasor of the measured signal, which means you can do all sorts of
> cool measurements of networks, especially since you can do complex
> number math with the equation support of the instrument. The signal
> generator will perform sweeps too, of course. This was very useful
> determining whether the speaker crossovers my dad built were working
> as intended (actually they weren't, and this instrument helped us
> uncover a problem). We also used this to do inductor and capacitor
> characterization. There are all sorts of applications this instrument
> is good for.
> 
> 
> Joe Zatarski

Re: Tape imaging

[Chuck Guzis]

On 08/10/2016 10:40 PM, jim stephens wrote:

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

Just like the PRIME PRIMOS convention.  Makes it easier to pick out
strings from a MAGSAV archive.

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

There is an EOM record in the .tap format = 0x - all ones.   No
need for extra filemarks.  After that just add standard 32-bit bytecount
headers and trailers to bracket each set of metadata and put whatever
you want between them.

Add a final EOM flag just for completeness' sake.

My gripe with .tap has been mentioned before--there's no standard way to
specify the *type* of error encountered--just that the high-order bit is
an error flag with  the lower 24 bits corresponding to the length of the
error block. Perhaps the unspecified 7 bits between the error flag and
the length could be put to this purpose.

Again, we're caught with the problem of those who just want data and
those who want more than the raw data.

--Chuck