Re: LGP-30 Update

[CuriousMarc via cctalk]

Sweet!
Marc

> On Mar 19, 2017, at 2:39 PM, Cory Heisterkamp via cctalk 
>  wrote:
> 
> Hey guys, figured it was time for an update on the LGP-30 resuscitation. 
> 
> Some further detective work found a leaky 1500uF cap in one of the B+ 
> supplies which was causing the 'surging' issue on the scope. For good measure 
> I replaced all six 1500 and 3000uF caps even though ripple was low. Better 
> safe than sorry and if it means pulling that chassis and its covers again, 
> all the better. I attempted to weigh it on my shipping scale, but it only 
> registers to 100 lbs and the indicator flew right past that. 
> 
> There had been a small thermal event in the AC junction box that the twist 
> lock connector mounts to, and I suspect it occurred pre-60's refurb. It's not 
> too surprising as the wiring on the computer side is aluminum and the feed is 
> copper. The box needed replacing but was a unique Hubbell variation of a std 
> 4" box with special ears. I couldn't find anything even close to that at any 
> of the supply houses online, probably because it violates today's conductor 
> fill rules (it's only 1" deep but the socket consumes most of that depth and 
> 75% of the area). I eventually settled on drilling/tapping a standard box and 
> cleaned up the wiring.
> 
> The sequencer unit is now working correctly after I found an NOS relay to R&R 
> contacts with. The blower is still steady and quiet with its new bearings, 
> and no issues (knock on wood) with the drum after greasing the end bearing, 
> belt and 'tightening' up the tolerances on the timing and short register 
> heads.
> 
> Some good news- I now have three horizontal lines on the scope, rock solid 
> and where they should be. I can get the occasional pattern for Instruction 
> contents, but Order and Accumulator still aren't reading/writing/displaying. 
> All in good time.
> 
> http://radar58.com/LGP30/wp-content/uploads/2017/03/lgp.jpg
> 
> Even better news is that the three timing tracks appear to be intact on the 
> drum and the supporting hardware is working.
> 
> http://radar58.com/LGP30/wp-content/uploads/2017/03/scope-e1489957963176.jpg
> (1, 2 and 3 correspond to S1, S2 and S3)
> 
> Now to investigate those short registers...  -Cory

MUMPS in the news

[Shoppa, Tim via cctalk]

http://www.politico.com/agenda/story/2017/03/vista-computer-history-va-conspiracy-000367

Re: 8085 RESET

[Brent Hilpert via cctalk]

On 2017-Mar-19, at 4:01 PM, Adrian Graham via cctalk wrote:
> On 19/03/2017 19:59, bhilpert wrote:
>> On 2017-Mar-18, at 5:21 PM, Adrian Graham via cctalk wrote:
>>> 
>>> 8085-based phone system weirdness continues and I'm beginning to wonder if
>>> the PSU rails are all coming up in time for RESET to go high - given there's
>>> 4116 DRAMs in there isn't there supposed to be a proper power up order?
>>> 
>>> While I look at using a 20-pin ATX PSU to run this machine temporarily I
>>> need a safe way to reset the CPU rather than constantly power cycling. The
>>> RESET line comes from an ICL7611 op-amp via an MC14081B through pins 1-4 of
>>> a 74LS04 and I need to pull it low for longer than 3 clock cycles.
>>> 
>>> I wish I had a schematic to show!
>> 
>> Recalling the messages from December, it looked like proper operation of the
>> reset circuitry at power-up
>> expected the presence of the battery to power the reset circuitry with 12V
>> prior to the 5V bus coming up.
>> 
>> It looks like you could add a reset switch to the unit by paralleling R406
>> (11K) with a NO pushbutton switch and ~ 4.7 uF cap (all 3 in parallel).
>> Closing the pushbutton switch simulates the absence of 5V. The cap provides a
>> little debounce delay, but may not even be necessary.
> 
> I've just checked the image you're referring to and the resistor numbers are
> offset so it looks like R406 is the top one of three where it's actually the
> middle one. Here's an up-to-date version:
> 
> http://www.binarydinosaurs.co.uk/STCExecutelResetOpamp.jpg

Yes, I did notice that in viewing, so it remains R406 / 11K / the one going to 
ground, to parallel with a switch.

Re: LGP-30 Update

[william degnan via cctalk]

> 
>
> http://radar58.com/LGP30/wp-content/uploads/2017/03/lgp.jpg
>
> Even better news is that the three timing tracks appear to be intact on
> the drum and the supporting hardware is working.
>
> http://radar58.com/LGP30/wp-content/uploads/2017/03/scope-
> e1489957963176.jpg
> (1, 2 and 3 correspond to S1, S2 and S3)
>
> Now to investigate those short registers...  -Cory
>
>
great news!
Bill

Re: 8085 RESET

[Adrian Graham via cctalk]

On 19/03/2017 19:59, "cctalk"  wrote:

> On 2017-Mar-18, at 5:21 PM, Adrian Graham via cctalk wrote:
>> 
>> 8085-based phone system weirdness continues and I'm beginning to wonder if
>> the PSU rails are all coming up in time for RESET to go high - given there's
>> 4116 DRAMs in there isn't there supposed to be a proper power up order?
>> 
>> While I look at using a 20-pin ATX PSU to run this machine temporarily I
>> need a safe way to reset the CPU rather than constantly power cycling. The
>> RESET line comes from an ICL7611 op-amp via an MC14081B through pins 1-4 of
>> a 74LS04 and I need to pull it low for longer than 3 clock cycles.
>> 
>> I wish I had a schematic to show!
> 
> Recalling the messages from December, it looked like proper operation of the
> reset circuitry at power-up
> expected the presence of the battery to power the reset circuitry with 12V
> prior to the 5V bus coming up.
> 
> It looks like you could add a reset switch to the unit by paralleling R406
> (11K) with a NO pushbutton switch and ~ 4.7 uF cap (all 3 in parallel).
> Closing the pushbutton switch simulates the absence of 5V. The cap provides a
> little debounce delay, but may not even be necessary.

I've just checked the image you're referring to and the resistor numbers are
offset so it looks like R406 is the top one of three where it's actually the
middle one. Here's an up-to-date version:

http://www.binarydinosaurs.co.uk/STCExecutelResetOpamp.jpg

Cheers!

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: Portability of Fortran - was Re: Architectural diversity - was Re: Pair of Twiggys

[Chuck Guzis via cctalk]

On 03/19/2017 02:14 PM, Toby Thain via cctalk wrote:

>   "The Fortran codes implementing the most effective methods are
> provided in the included diskette. The codes are portable on virtually
> any computer, extensively commented and---hopefully---easy to use."

Take a look at early ACM CALGO (collected algorithms).  Algorithm 1
dates from 1960 and is in Algol; indeed all of Volume I and a good part
of Volume II are exclusively Algol.  You don't hit FORTRAN until about
1968 (somewhere around Algorithm 330).  After that, you'll see pages and
pages of FORTRAN.

I do think that Algol is far more elegant for describing algorithms than
FORTRAN; but the sad fact is that many (US-based) programmers didn't
speak Algol.

--Chuck

RE: LGP-30 Update

[W2HX via cctalk]

Impressive progress! Well done!

73 Eugene W2HX


-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Cory 
Heisterkamp via cctalk
Sent: Sunday, March 19, 2017 5:40 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: LGP-30 Update

Hey guys, figured it was time for an update on the LGP-30 resuscitation. 

Some further detective work found a leaky 1500uF cap in one of the B+ supplies 
which was causing the 'surging' issue on the scope. For good measure I replaced 
all six 1500 and 3000uF caps even though ripple was low. Better safe than sorry 
and if it means pulling that chassis and its covers again, all the better. I 
attempted to weigh it on my shipping scale, but it only registers to 100 lbs 
and the indicator flew right past that. 

There had been a small thermal event in the AC junction box that the twist lock 
connector mounts to, and I suspect it occurred pre-60's refurb. It's not too 
surprising as the wiring on the computer side is aluminum and the feed is 
copper. The box needed replacing but was a unique Hubbell variation of a std 4" 
box with special ears. I couldn't find anything even close to that at any of 
the supply houses online, probably because it violates today's conductor fill 
rules (it's only 1" deep but the socket consumes most of that depth and 75% of 
the area). I eventually settled on drilling/tapping a standard box and cleaned 
up the wiring.

The sequencer unit is now working correctly after I found an NOS relay to R&R 
contacts with. The blower is still steady and quiet with its new bearings, and 
no issues (knock on wood) with the drum after greasing the end bearing, belt 
and 'tightening' up the tolerances on the timing and short register heads.

Some good news- I now have three horizontal lines on the scope, rock solid and 
where they should be. I can get the occasional pattern for Instruction 
contents, but Order and Accumulator still aren't reading/writing/displaying. 
All in good time.

http://radar58.com/LGP30/wp-content/uploads/2017/03/lgp.jpg

Even better news is that the three timing tracks appear to be intact on the 
drum and the supporting hardware is working.

http://radar58.com/LGP30/wp-content/uploads/2017/03/scope-e1489957963176.jpg
(1, 2 and 3 correspond to S1, S2 and S3)

Now to investigate those short registers...  -Cory

LGP-30 Update

[Cory Heisterkamp via cctalk]

Hey guys, figured it was time for an update on the LGP-30 resuscitation. 

Some further detective work found a leaky 1500uF cap in one of the B+ supplies 
which was causing the 'surging' issue on the scope. For good measure I replaced 
all six 1500 and 3000uF caps even though ripple was low. Better safe than sorry 
and if it means pulling that chassis and its covers again, all the better. I 
attempted to weigh it on my shipping scale, but it only registers to 100 lbs 
and the indicator flew right past that. 

There had been a small thermal event in the AC junction box that the twist lock 
connector mounts to, and I suspect it occurred pre-60's refurb. It's not too 
surprising as the wiring on the computer side is aluminum and the feed is 
copper. The box needed replacing but was a unique Hubbell variation of a std 4" 
box with special ears. I couldn't find anything even close to that at any of 
the supply houses online, probably because it violates today's conductor fill 
rules (it's only 1" deep but the socket consumes most of that depth and 75% of 
the area). I eventually settled on drilling/tapping a standard box and cleaned 
up the wiring.

The sequencer unit is now working correctly after I found an NOS relay to R&R 
contacts with. The blower is still steady and quiet with its new bearings, and 
no issues (knock on wood) with the drum after greasing the end bearing, belt 
and 'tightening' up the tolerances on the timing and short register heads.

Some good news- I now have three horizontal lines on the scope, rock solid and 
where they should be. I can get the occasional pattern for Instruction 
contents, but Order and Accumulator still aren't reading/writing/displaying. 
All in good time.

http://radar58.com/LGP30/wp-content/uploads/2017/03/lgp.jpg

Even better news is that the three timing tracks appear to be intact on the 
drum and the supporting hardware is working.

http://radar58.com/LGP30/wp-content/uploads/2017/03/scope-e1489957963176.jpg
(1, 2 and 3 correspond to S1, S2 and S3)

Now to investigate those short registers...  -Cory

Portability of Fortran - was Re: Architectural diversity - was Re: Pair of Twiggys

[Toby Thain via cctalk]

On 2017-03-17 2:56 PM, Chuck Guzis via cctalk wrote:

On 03/17/2017 11:41 AM, Paul Koning wrote:


Not quite true.  ALGOL was the first choice for a couple of
architectures: Electrologica X8, and the Burroughs 48-bit mainframes.
And I supposed you could claim that status for Bliss in the case of
VAXen, though in a different sense there was a whole set of high
level languages that were there day 1 because the architecture
envisioned all of them (and any combination of them).


Well, okay--the European-American divide must be taken into account--and
the Burroughs B5000 architecture was sui generis.

But by and large, FORTRAN, at least in North America, was the first
language of choice in implementation--after assembly, if one can call
assembly a language--many would call it "symbolic coding"; using symbols
instead of numeric addresses.

--Chuck






I came across a typical example of how Fortran was used as lingua 
franca, just yesterday, in a book titled "Knapsack Problems - Algorithms 
and Computer Implementations" (Silvano Martello, Paolo Toth), published 
1990.


The Preface includes the words:

  "The Fortran codes implementing the most effective methods are 
provided in the included diskette. The codes are portable on virtually 
any computer, extensively commented and---hopefully---easy to use."


--Toby

Re: Fwd: Re: Architectural diversity - was Re: Pair of Twiggys

[Toby Thain via cctalk]

On 2017-03-17 3:19 PM, Rich Alderson via cctalk wrote:

From: Chuck Guzis
Sent: Friday, March 17, 2017 11:27 AM


On 03/17/2017 11:09 AM, Fred Cisin via cctalk wrote:



and, although we don't know when YOU were playing it, the march had
been around half a century, so was probably playing on the radio to
inspire Backus.  Does that mean that Dan. might be right about it
being the predecessor to FORTRAN?



Valdres March has been around for more than a century--it's at least 113
years old.



So FORTRAN has some catching up to do.



It wasn't until the microcomputer era with BASIC, I think that FORTRAN
wasn't the first HLL to be contemplated for a new architecture.



"I don't know what the language of the year 2000 will look like, but I know
it will be called Fortran."

--Tony Hoare, winner of the 1980 Turing Award,
  in 1982.



Depressingly prescient...

--T

Re: Looking for cassete basic rom code

[william degnan via cctalk]

On Mar 19, 2017 12:47 PM, "Adam Sampson via cctalk" 
wrote:
>
> Alexandre Souza via cctalk  writes:
>
> > I lost my XT BASIC ROMS, can someone send me the code so I can burn it
> > and replace on my XT?
>
> minuszerodegrees.net has several versions of the XT ROM images, along
> with lots of other useful service information for PC/XT/AT machines:
>
> http://www.minuszerodegrees.net/bios/bios.htm
>
> --
> Adam Sampson  

Has anyone made a ROM that runs BASIC and allows use of the disk drive to
save on an IBM PC?  This always bugged me that if you forgot to insert your
dos disk before the computer powered up that one could not enter a basic
command to tell the system to boot up from the drive without
ctrl-alt-delete and waitor to boot from the b drive, etc.

Bill Degnan
twitter: billdeg
vintagecomputer.net

Re: 8085 RESET

[Brent Hilpert via cctalk]

On 2017-Mar-18, at 5:21 PM, Adrian Graham via cctalk wrote:
> 
> 8085-based phone system weirdness continues and I'm beginning to wonder if
> the PSU rails are all coming up in time for RESET to go high - given there's
> 4116 DRAMs in there isn't there supposed to be a proper power up order?
> 
> While I look at using a 20-pin ATX PSU to run this machine temporarily I
> need a safe way to reset the CPU rather than constantly power cycling. The
> RESET line comes from an ICL7611 op-amp via an MC14081B through pins 1-4 of
> a 74LS04 and I need to pull it low for longer than 3 clock cycles.
> 
> I wish I had a schematic to show!

Recalling the messages from December, it looked like proper operation of the 
reset circuitry at power-up
expected the presence of the battery to power the reset circuitry with 12V 
prior to the 5V bus coming up.

It looks like you could add a reset switch to the unit by paralleling R406 
(11K) with a NO pushbutton switch and ~ 4.7 uF cap (all 3 in parallel).
Closing the pushbutton switch simulates the absence of 5V. The cap provides a 
little debounce delay, but may not even be necessary.

Re: Architectural diversity - was Re: Pair of Twiggys

[Paul Koning via cctalk]

> On Mar 19, 2017, at 2:36 PM, Chuck Guzis via cctalk  
> wrote:
> 
> ...
> Still, vendors kept extending their FORTRAN IVs.  I think I remarked on
> a CDC syntactic extension that resulted in the ability to write an
> ambiguous statement, with no clear way to resolve the meaning.

I'm reminded of a T-shirt sold while I was in college (mid 1970s) with this 
text:

(.)(.)
   IKF4084I

I looked that up in Messages and Codes, found a pointer to the IBM COBOL 
messages manual, where I found this message text: "Questionable use of 
parentheses accepted with doubts as to meaning".  So I think CDC was not alone 
in that bad practice.

paul

Re: Extracting data from DEC VAX tape recordings

[Dennis Boone via cctalk]

 > I have a rather crude way of reading 9-track tapes in 1600 and 6250
 > BPI densities.  I have worked out how to unpack VAX BACKUP format
 > tapes, if that is how they were written.  I have read some tapes that
 > were about this old, but they have been stored in excellent
 > conditions, and they were high-quality tapes.  Some tapes that were
 > of lesser quality or stored in poor conditions may not be
 > recoverable.

9-track tape is remarkably resilient.  I've successfully read tapes that
were stored in an uncontrolled Michigan attic for 20+ years.

VMS Backup format isn't that hard to deal with: there are at least one
or two open source tools which can read most save sets, and feeding an
image to an actual VMS system in emulation is easy too.

The worst threat is the "sticky shed" issue, wherein the binder which
holds the coatings onto the tape backing absorbs moisture and gets
gooey.  A number of approaches have been described in the literature,
from mechanically removing the back coating applied to some media to
reduce static and other issues, to chemical applications, to baking out
the moisture.

 > Some other people have a lot of experience with baking the tapes at
 > low temperature to improve the chances of good data recovery, you you
 > might see if they want to do it, first.

I've had good luck with the lowest of tech solutions: a food dehydrator.
Many libraries have used convection ovens.  Target temperature seems to
be in the neighborhood of 130-140 degrees.  I've seen recommendations
for 2-4 hours, but I seem to have better luck with 24.

De

Re: CF cards as storage - wear leveling

[Peter Coghlan via cctalk]

I don't think anybody is actually using real CF cards 
anymore, they are about a decade out of date.


Jon



Jon,

This is the list where we discuss using stuff that's a decade and more
out of date.

(I've got a large box of real 16MB CF cards that I got for nothing on
freecycle that I keep meaning to dream up a use for...)

Regards,
Peter Coghlan.

Re: CF cards as storage - wear leveling

[Chuck Guzis via cctalk]

On 03/19/2017 11:20 AM, Warner Losh via cctalk wrote:

> Just about ANY CF card you buy today new will have wear leveling.
> It's almost impossible without trying to be an ass to the card to
> have it fail in a few weeks. I've run 64MB cards in Soekris boxes for
> a decade w/o any problems. The key, as with all flash purchases, is
> to buy the best, fastest you can rather than the cheapest you can.
> But most unix systems can do many things to mitigate wear. There's
> dozens of tutorials about mounting noatime (to keep access times from
> being updated), to more advanced features like putting /var/tmp and
> friends on memory disks, etc. With a 486, though, that might not be
> an option. Not sure what kind of system you are migrating though...

If you're worried about write wear on a CF card and can do with higher
power consumption and somewhat slower speed,  use one of the
"Microdrives" offered by IBM, Hitachi or Seagate in past years.  I
believe that capacity of 12GB may be the upper limit.  They're
comparatively inexpensive, as NOS items.

I ran a 5GB Seagate drive for about 5 years 24/7 in a mailserver with no
issues.

--Chuck

Re: Architectural diversity - was Re: Pair of Twiggys

[Chuck Guzis via cctalk]

On 03/19/2017 08:04 AM, Bill Gunshannon via cctalk wrote:

> FORTRAN.  FORTRAN D (DOS/360), F and G (OS/360), which were FORTRAN
> IV compilers (retronamed "Fortran 66").  VAX/VMS Fortran 77, except
> most VAXen of the day you seem to be talking about ran BSD Unix and
> Fortran was handled by f2c.
> 
> I learned FORTRAN IV on an IBM 1401, a decimal computer, before
> moving on to PL/1 and COBOL (and FORTRAN) on the System/360.

There was another FORTRAN 66 available fro the S/360, but you usually
saw  it on the lower models (25, 30, 40).   It was called "Basic FORTRAN
IV" or sometimes "USA Basic FORTRAN".  There doesn't seem to be a manual
in S/360 section  for this on bitsavers.  I recall that it was a slim
little packet.

It was brutal--basic INTEGER, REAL and DOUBLE PRECISION data
declarations; blank COMMON only; arithmetic IF only, computed and
unconditional GO TO--and the bugbear of many programmers:  strict
enforcement  of "mixed mode" prohibitions.  File I/O was reasonable, I
suppose.  A maximum of 6 characters in a variable name, stuff like that.

Better than some of the stripped-down FORTRAN II versions, which often
didn't even include type declarations.

FORTRAN IV was a step forward--vendor "extensions" of FORTRAN II were
getting out of hand--contrast some of the conventions of, say, 7090 FMS
II/IBSYS fORTRAN with other vendors.  For example, punching a 'B" in
column 1 indicated a "logical/Boolean" expression and so on...

Still, vendors kept extending their FORTRAN IVs.  I think I remarked on
a CDC syntactic extension that resulted in the ability to write an
ambiguous statement, with no clear way to resolve the meaning.

I believe that Univac, at one point, boasted an 1100 "FORTRAN V". That's
chutzpah for you. "FORTRAN VI", of course, was PL/I.

F77 tightened that up and brought out the notion of having to flag any
non-ANSI syntax.  F90 was clear in that vendor extensions were to be
disabled by default; i.e., the user must explicitly enable them.

F90 was, to me, the point of departure.  Many statement types were
deprecated; since the world was no longer coding on cards, free-format
input was standardized.  Extensions for high-end supercomputers were
codified, etc.   Reserved words made their appearance--in previous
versions, the notion of "whitespace" was introduced.   It was perfectly
legitimate to name a variable "FORMAT" or "REAL" and write it as "F OR M
AT", though I suspect that few ever did.

The Fortran of today resembles FORTRAN II in the same way that COBOL
2014 resembles IBM COMTRAN.

But, mutatis mutandis, Fortran/FORTRAN still lives.

--Chuck

Re: CF cards as storage - wear leveling

[Warner Losh via cctalk]

On Sun, Mar 19, 2017 at 10:06 AM, Jules Richardson via cctalk
 wrote:
>
> I just bought an IDE-CF adapter the other day with the intention of
> replacing the spinning rust in my disk imaging system (which is some
> early/mid-90s 80486-based thing).
>
> However, the CF entry on Wikipedia says:
>
> "Most CompactFlash flash-memory devices limit wear on blocks by varying the
> physical location to which a block is written. When using CompactFlash in
> ATA mode to take the place of the hard disk drive, wear leveling becomes
> critical because low-numbered blocks contain tables whose contents change
> frequently. Current CompactFlash cards spread the wear-leveling across the
> entire drive. The more advanced CompactFlash cards will move data that
> rarely changes to ensure all blocks wear evenly."
>
> ... I'm a little wary about the way it says "most CF cards", implying that
> there are some out there which don't do any wear-leveling at all. So, the
> obvious question: is there a way of knowing which cards are going to be good
> and which are useless as IDE replacements? Maybe by age, capacity,
> manufacturer? I'd prefer not to invest time into setting software up only to
> find that the card fails in a matter of weeks.

Just about ANY CF card you buy today new will have wear leveling. It's
almost impossible without trying to be an ass to the card to have it
fail in a few weeks. I've run 64MB cards in Soekris boxes for a decade
w/o any problems. The key, as with all flash purchases, is to buy the
best, fastest you can rather than the cheapest you can. But most unix
systems can do many things to mitigate wear. There's dozens of
tutorials about mounting noatime (to keep access times from being
updated), to more advanced features like putting /var/tmp and friends
on memory disks, etc. With a 486, though, that might not be an option.
Not sure what kind of system you are migrating though...

CF cards tend to be much more compatible with systems than SD card
adapters, but on extremely old system can be picky even with CF cards.
I had a system back in the day not present the CF card as a bootable
device because something in its ID string was a bit wonky to it. SD
cards tend to be crap too without careful selection (which usually
means getting a couple of the faster cards and hoping that at least
one of them is good). These days, it's more a precaution than an
actual requirement though, but see below.

For $40 you can get a 32GB Lexar Professional that boasts 1066x speed
and UDMA7. You'll likely not do UDMA at all in a system of that age.
DMA is another area where you have to buy the right CF card (though
it's hard to buy the wrong kind new, random used stuff is a crap shoot
whether all the pins needed for UDMA are present). If you have
problems, try setting the to PIO. Seems like overkill. If you are
looking for a smaller card because the BIOS just can't cope with
anything that big, you'll need to buy the professional grade used
cards, though that too is a crap shoot (so buy several). If you have a
reasonable sized system (say 2GB) the way you cope with failure is to
backup an image every so often with DD and just blast it out to a new
card if the one you get fails. But if you do that, the size has to be
>= the old one. And with a 486, you likely don't have an LBA BIOS, so
you need to make sure the geometry matches which can be tricky. The
geometry reported by CF<->USB adapters will almost certainly be
different than what the CF<->IDE adapter reports.

So good luck!

Warner

Re: CF cards as storage - wear leveling

[Jon Elson via cctalk]

On 03/19/2017 11:06 AM, Jules Richardson via cctalk wrote:


I just bought an IDE-CF adapter the other day with the 
intention of replacing the spinning rust in my disk 
imaging system (which is some early/mid-90s 80486-based 
thing).


However, the CF entry on Wikipedia says:

"Most CompactFlash flash-memory devices limit wear on 
blocks by varying the physical location to which a block 
is written. When using CompactFlash in ATA mode to take 
the place of the hard disk drive, wear leveling becomes 
critical because low-numbered blocks contain tables whose 
contents change frequently. Current CompactFlash cards 
spread the wear-leveling across the entire drive. The more 
advanced CompactFlash cards will move data that rarely 
changes to ensure all blocks wear evenly."


... I'm a little wary about the way it says "most CF 
cards", implying that there are some out there which don't 
do any wear-leveling at all. So, the obvious question: is 
there a way of knowing which cards are going to be good 
and which are useless as IDE replacements? Maybe by age, 
capacity, manufacturer? I'd prefer not to invest time into 
setting software up only to find that the card fails in a 
matter of weeks.


I have several systems that have the old Beagle Board 
computer in them.  They are not run continuously, but have 
been run for months at a time.  These use regular-size SD 
cards as the "disk" for a Linux OS.  I did set the noatime 
flag on the file system.  They are still running on the 
original SD cards.


I have a Beagle Bone running LinuxCNC under a Debian-based 
distro, and I fire it up at various times to text boards I 
make, and it is still running the original micro-SD card.


I don't think anybody is actually using real CF cards 
anymore, they are about a decade out of date.


Jon

Re: Extracting data from DEC VAX tape recordings

[Jon Elson via cctalk]

On 03/18/2017 06:28 PM, William Pearse via cctalk wrote:

Hello,


I'm sorry to bother you, but I was hoping you might be able to help me with a 
problem I'm having getting hold of some scientific data that's currently stored 
on DEC VAX magnetic tape.


A colleague of mine carried out some ecological fieldwork ~30 years ago, and her results are 
stored on eight magnetic tapes (two of 7" diameter, one 8.5", and five 10.25"). 
The data would be incredibly useful to look at, as the study was looking at how restored mines 
changes over time (the study is somewhat described here; 
https://www.jstor.org/stable/20038221?seq=1#page_scan_tab_contents). If we could get these 
original data, we could compare how the mine is now with how it was then, which would be 
phenomenally useful to conservation biologists trying to conserve and restore damaged 
ecosystems.


Do any of you have any ideas as to how I might get the data off this tape? I 
live and work in Utah (USA), but I would be willing to travel a little ways if 
it meant getting the things read off into a computer!



I have a rather crude way of reading 9-track tapes in 1600 
and 6250 BPI densities.  I have worked out how to unpack VAX 
BACKUP format tapes, if that is how they were written.  I 
have read some tapes that were about this old, but they have 
been stored in excellent conditions, and they were 
high-quality tapes.  Some tapes that were of lesser quality 
or stored in poor conditions may not be recoverable.


Some other people have a lot of experience with baking the 
tapes at low temperature to improve the chances of good data 
recovery, you you might see if they want to do it, first.


Jon

Re: Architectural diversity - was Re: Pair of Twiggys

[Raymond Wiker via cctalk]

> On 19 Mar 2017, at 16:14 , Paul Koning via cctalk  
> wrote:
> 
> 
>> On Mar 19, 2017, at 11:04 AM, Bill Gunshannon via cctalk 
>>  wrote:
>> ...
>> That's because, unlike the COBOL Professionals, the Fortran people drank from
>> the OO KoolAid.
> 
> Speaking of OO and COBOL, a colleage of mine has a button with the text "ADD 
> 1 TO COBOL".
> 
>   paul
> 

Given that C++ is the object-oriented descendant of C, one might expect 
object-oriented COBOL to be named "ADD 1 TO COBOL". In my opinion, the 
object-oriented successor to COBOL is called Java - it's similarly verbose, and 
like COBOL, originally intended for average, fungible programmers.

Re: Looking for cassete basic rom code

[Adam Sampson via cctalk]

Alexandre Souza via cctalk  writes:

> I lost my XT BASIC ROMS, can someone send me the code so I can burn it
> and replace on my XT?

minuszerodegrees.net has several versions of the XT ROM images, along
with lots of other useful service information for PC/XT/AT machines:

http://www.minuszerodegrees.net/bios/bios.htm

-- 
Adam Sampson  

RE: Re: Architectural diversity - was Re: Pair of Twiggys

[Fred Cisin via cctalk]

> FORTRAN was, and still is, widespread, even if it doesn't look 
> anything like itself these days.


On Sun, 19 Mar 2017, Bill Gunshannon via cctalk wrote:
That's because, unlike the COBOL Professionals, the Fortran people drank 
from the OO KoolAid.


Yes, there does exist an Object Oriented COBOL!

Oh, and my 1401 only did Autocoder.  I didn't start using Fortran until 
my Univac-1100 days.


There wasn't a Fortran compiler for the 1401, but 
how much did they charge for the FORTRAN compiler?

Looking for cassete basic rom code

[Alexandre Souza via cctalk]

   Dear friends

   Is it allowed to request a ROM code?

   I lost my XT BASIC ROMS, can someone send me the code so I can burn it 
and replace on my XT?


   Thanks!
   Alexandre

---

CF cards as storage - wear leveling

[Jules Richardson via cctalk]

I just bought an IDE-CF adapter the other day with the intention of 
replacing the spinning rust in my disk imaging system (which is some 
early/mid-90s 80486-based thing).


However, the CF entry on Wikipedia says:

"Most CompactFlash flash-memory devices limit wear on blocks by varying the 
physical location to which a block is written. When using CompactFlash in 
ATA mode to take the place of the hard disk drive, wear leveling becomes 
critical because low-numbered blocks contain tables whose contents change 
frequently. Current CompactFlash cards spread the wear-leveling across the 
entire drive. The more advanced CompactFlash cards will move data that 
rarely changes to ensure all blocks wear evenly."


... I'm a little wary about the way it says "most CF cards", implying that 
there are some out there which don't do any wear-leveling at all. So, the 
obvious question: is there a way of knowing which cards are going to be 
good and which are useless as IDE replacements? Maybe by age, capacity, 
manufacturer? I'd prefer not to invest time into setting software up only 
to find that the card fails in a matter of weeks.


cheers

Jules

Re: Architectural diversity - was Re: Pair of Twiggys

[Paul Koning via cctalk]

> On Mar 19, 2017, at 11:04 AM, Bill Gunshannon via cctalk 
>  wrote:
> ...
> That's because, unlike the COBOL Professionals, the Fortran people drank from
> the OO KoolAid.

Speaking of OO and COBOL, a colleage of mine has a button with the text "ADD 1 
TO COBOL".

paul

RE: Re: Architectural diversity - was Re: Pair of Twiggys

[Bill Gunshannon via cctalk]

From: cctalk [cctalk-boun...@classiccmp.org] on behalf of Rich Alderson via 
cctalk [cctalk@classiccmp.org]
Sent: Friday, March 17, 2017 3:07 PM
To: 'General Discussion: On-Topic and Off-Topic Posts'
Subject: RE: Re: Architectural diversity - was Re: Pair of Twiggys

From: ben
Sent: Thursday, March 16, 2017 6:28 PM

> On 3/16/2017 5:16 PM, Bill Gunshannon via cctalk wrote:

>> From: Chuck Guzis
>> Sent: Thursday, March 16, 2017 6:08 PM

>>> And people who weren't there can't understand why FORTRAN was the closest
>>> thing to a "portable" language...

>> Not even close to COBOL.  :-)

Preach it, brother!

> But was FORTRAN that portable?

Yes.

> Other than the IBM 1130 I cannot think of a small computer that had ample I/O
> and memory to run and compile FORTRAN. All the other 16 bitters seem to more
> paper tape I/O.

The PDP-8 family has compilers for both FORTRAN II and FORTRAN IV.  16 bits?
What could we possibly do with all that address space? ;-)

> I suspect 90% of all university computers ended up as IBM 360 systems. A few
> ended up with the VAX, but who knows what they ran.

FORTRAN.  FORTRAN D (DOS/360), F and G (OS/360), which were FORTRAN IV
compilers (retronamed "Fortran 66").  VAX/VMS Fortran 77, except most VAXen of
the day you seem to be talking about ran BSD Unix and Fortran was handled by
f2c.

I learned FORTRAN IV on an IBM 1401, a decimal computer, before moving on to
PL/1 and COBOL (and FORTRAN) on the System/360.

FORTRAN was, and still is, widespread, even if it doesn't look anything like
itself these days.


That's because, unlike the COBOL Professionals, the Fortran people drank from
the OO KoolAid.

Oh, and my 1401 only did Autocoder.  I didn't start using Fortran until my 
Univac-1100
days.

bill

Re: LINCtape/DECtape Head Alignment

[Jay Jaeger via cctalk]

Curious:  How are you measuring the signal from the head?  Do you have
an honest to gosh differential probe, or are you using some other
technique?  (If you have a differential probe, then the TU56 manual
indicates that you should see 10mv-12mv (the addition of the two paired
heads together), so as a first guess I am guessing you are looking at
the coils one at a time.

The reason I ask is that the TU56 that I use most often has gotten a bit
cranky over the years.  Generally I can read and write, but I do
typically see some errors - unacceptably many, and it *seems* that the
longer the machine is on, it seems the more mark track errors I get when
running the ZTCC?? diagnostic (test 3).

I don't have a differential probe, and the A-B math function on my Rigol
DS2072 scope is not anywhere near fast enough (though maybe a firmware
patch which I have downloaded will help, but I doubt it will help
because their is a lot of HF noise on the signals when measuring
voltages this low).  However, if I apply a 50KHz low pass filter on the
signal on the scope, then sometimes I can see a 5mv per coil signal
using an ordinary probe.  I say sometimes because the scope seems to
have some firmware problems so it isn't consistent in its behavior.  (I
have downloaded a firmware update that *might* help).

I don't really doubt my heads at this point - certainly nothing is open
- I can measure each coil at about 1.5 ohms (3.0 ohms across both), but
it is something I would like to make sure I know how to do.

Also, have you degaussed your heads?  If so, how?  I ask because some of
my symptoms could point that way (I have yet, for example, to test with
a tape, have it get worse, then go back with the machine "cold" and see
if it gets better - and if it doesn't, that could point to demagnetized
heads.)

Thanks.

JRJ


On 12/26/2016 12:08 PM, Michael Thompson wrote:
> The RICM is working on the skew adjustment on a TU56 tape drive on a
> PDP-12. We only see a 5mV signal from the head, so when we flip the tape
> over we will only see 1mV. This is below the capabilities of my 'scope.
> 
> The DEC skew adjustment procedure talks about using a DEC amplifier to
> boost the head signal to several volts. We are planning to make an
> equivalent amplifier using a modern Op-amp. It would be really convenient
> to have one of the Amphenol 133-022-03 connectors from a G851 Relay module
> on our amplifier so it would plug directly into the head cable.
> 
> Does anyone have a DEC G851 module that we could remove the connector from?
> 

BCC:  Original poster

Extracting data from DEC VAX tape recordings

[William Pearse via cctalk]

Hello,


I'm sorry to bother you, but I was hoping you might be able to help me with a 
problem I'm having getting hold of some scientific data that's currently stored 
on DEC VAX magnetic tape.


A colleague of mine carried out some ecological fieldwork ~30 years ago, and 
her results are stored on eight magnetic tapes (two of 7" diameter, one 8.5", 
and five 10.25"). The data would be incredibly useful to look at, as the study 
was looking at how restored mines changes over time (the study is somewhat 
described here; 
https://www.jstor.org/stable/20038221?seq=1#page_scan_tab_contents). If we 
could get these original data, we could compare how the mine is now with how it 
was then, which would be phenomenally useful to conservation biologists trying 
to conserve and restore damaged ecosystems.


Do any of you have any ideas as to how I might get the data off this tape? I 
live and work in Utah (USA), but I would be willing to travel a little ways if 
it meant getting the things read off into a computer!


Thanks again for your time,

Will Pearse


---

Need a phylogeny? Try phyloGenerator: 
original or new 
version
Measuring phylogenetic structure? Try install.packages('pez')

Will Pearse
Assistant Professor of Biology, Utah State University
Office: +1-435-797-0831
Skype: will.pearse

Re: DEC items

[Marc Howard via cctalk]

Peter,

Did you get my earlier message about the PDPs?  I'm in the bay area as well.

Marc Howard

On Fri, Mar 17, 2017 at 3:35 PM, Peter C. Wallace via cctalk <
cctalk@classiccmp.org> wrote:

> On Fri, 17 Mar 2017, Paul Anderson via cctalk wrote:
>
> Date: Fri, 17 Mar 2017 17:15:42 -0500
>> From: Paul Anderson via cctalk 
>> Reply-To: Paul Anderson ,
>> "General Discussion: On-Topic and Off-Topic Posts" <
>> cctalk@classiccmp.org>
>> To: Peter C. Wallace via cctalk 
>> Subject: DEC items
>>
>> Hi Peter,
>>
>> Sounds like a nice collection. Which PDP11s do you have?
>>
>
> Unfortunately its pretty buried. Its in one of those narrow vertical cases
> and i dont think its a terribly desirable or fast one though ISTR that it
> does have a A-D card installed
>
> Thanks, Paul
>>
>>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>

Re: DEC items

[Pete Lancashire via cctalk]

Paul,


Think you have me mixed up with someone else

-Pete

On Mar 17, 2017 3:15 PM, "Paul Anderson via cctalk" 
wrote:

Hi Peter,

Sounds like a nice collection. Which PDP11s do you have?

Thanks, Paul

RE: Re: Architectural diversity - was Re: Pair of Twiggys

[Rich Alderson via cctalk]

From: ben
Sent: Thursday, March 16, 2017 6:28 PM

> On 3/16/2017 5:16 PM, Bill Gunshannon via cctalk wrote:

>> From: Chuck Guzis
>> Sent: Thursday, March 16, 2017 6:08 PM

>>> And people who weren't there can't understand why FORTRAN was the closest
>>> thing to a "portable" language...

>> Not even close to COBOL.  :-)

Preach it, brother!

> But was FORTRAN that portable?

Yes.

> Other than the IBM 1130 I cannot think of a small computer that had ample I/O
> and memory to run and compile FORTRAN. All the other 16 bitters seem to more
> paper tape I/O.

The PDP-8 family has compilers for both FORTRAN II and FORTRAN IV.  16 bits?
What could we possibly do with all that address space? ;-)

> I suspect 90% of all university computers ended up as IBM 360 systems. A few
> ended up with the VAX, but who knows what they ran.

FORTRAN.  FORTRAN D (DOS/360), F and G (OS/360), which were FORTRAN IV
compilers (retronamed "Fortran 66").  VAX/VMS Fortran 77, except most VAXen of
the day you seem to be talking about ran BSD Unix and Fortran was handled by
f2c.

I learned FORTRAN IV on an IBM 1401, a decimal computer, before moving on to
PL/1 and COBOL (and FORTRAN) on the System/360.

FORTRAN was, and still is, widespread, even if it doesn't look anything like
itself these days.

Rich

Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computers: Museum + Labs
2245 1st Avenue S
Seattle, WA 98134

mailto:ri...@livingcomputers.org

http://www.LivingComputers.org/

RE: I hate the new mail system

[Rich Alderson via cctalk]

From: Jay West 
Sent: Thursday, March 16, 2017 1:31 PM

> We've been in the process of moving our datacenter. As a result, changing
> headers on this list has been the last thing on my mind priority-wise.

> Add to that, we still have a few machines to move that will require
> hand-reimplementation instead of just migration, and those have to be
> finished first (paying customers).

> Add to that... when THIS server gets reimplemented, the lists will be
> recombined and the above patch should not be necessary.

> So - given available time and priorities, I'd appreciate it if you could
> suffer the lack of fun for a few weeks or a couple months, whatever it takes
> me to (a) find the time and (b) to get it done. After that, I'm sure the fun
> will return. Thanks for patience and understanding!

Jay,

Thanks for putting up with the long, long discussion my original intemperate
complaint sparked.  (A good friend who's also on the list privately said to
me "See what you started?", weeks ago.)

Thank you as well for hosting all of this at no charge to the group's members,
something for which we are all grateful (even if it does not appear so from
time to time).

Having managed multiple mailing lists over the decades, I applaud your efforts
to keep this a vibrant, civil place to discuss broadly our mutual interests.

Best regards,
Rich


Rich Alderson
Sr. Systems Engineer
Living Computers: Museum + Labs
2245 1st Ave S
Seattle, WA 98134


http://www.LivingComputers.org/

Re: FTGH Large amount of DEC/Misc Classic computer hardware

[Marc Howard via cctalk]

I would love to get a PDP-11 & I'm in the Bay Area.

Marc Howard


On Fri, Mar 17, 2017 at 1:14 PM Peter C. Wallace via cctalk <
cctalk@classiccmp.org> wrote:

> On Fri, 17 Mar 2017, Kirk Davis wrote:
>
>
>
> > Date: Fri, 17 Mar 2017 13:08:31 -0700
>
> > From: Kirk Davis 
>
> > To: Peter C. Wallace ,
>
> > "General Discussion: On-Topic and Off-Topic Posts" <
> cctalk@classiccmp.org>
>
> > Subject: Re: FTGH Large amount of DEC/Misc Classic computer hardware
>
> >
>
> > My Plate is full but Iяяm sure others would like to know the location of
> this stuff.
>
> >
>
>
>
> Richmond CA (Hilltop business park)
>
>
>
> >
>
> >> On Mar 17, 2017, at 12:56 PM, Peter C. Wallace via cctalk <
> cctalk@classiccmp.org> wrote:
>
> >>
>
> >> We need to move our business and I have about a ton of
>
> >> classic cimputer junk in the SFBA that need to go or get scrapped:
>
> >>
>
> >> Many Decstations (3100, 5000/1xx and 5000/240/260s series even a 5100)
>
> >> many Vaxstations 3100s mostly
>
> >> Vax 4000 300?
>
> >> 5" DEC hard drives
>
> >> Many DEC mice
>
> >> Small Alphas
>
> >> Dec/HP  CRT monitors
>
> >> HP ~1990s Unix workstations and parts
>
> >> Versatec CE3000 plotter (huge)
>
> >> test equipment (misc Tek scopes and plugins mainly)
>
> >> Symbolics 3645? (from Guy Sotomayer a few years back)
>
> >> HP 2115? mini
>
> >> PDP 11
>
> >> Couple 3 KW UPSs with bad batterys
>
> >> SR22 calculator
>
> >> Altos 5 15
>
> >> etc
>
> >>
>
> >> Would really like all to go to someone in the CC community who can take
> all and sort/distribute themselves rather than cherry pick but that may be
> optimistic...
>
> >>
>
> >>
>
> >>
>
> >> Peter Wallace
>
> >>
>
> >
>
>
>
> Peter Wallace
>
> Mesa Electronics
>
>
>
> (\__/)
>
> (='.'=) This is Bunny. Copy and paste bunny into your
>
> (")_(") signature to help him gain world domination.
>
>

RE: Fwd: Re: Architectural diversity - was Re: Pair of Twiggys

[Rich Alderson via cctalk]

From: Chuck Guzis
Sent: Friday, March 17, 2017 11:27 AM

> On 03/17/2017 11:09 AM, Fred Cisin via cctalk wrote:

>> and, although we don't know when YOU were playing it, the march had
>> been around half a century, so was probably playing on the radio to
>> inspire Backus.  Does that mean that Dan. might be right about it
>> being the predecessor to FORTRAN?

> Valdres March has been around for more than a century--it's at least 113
> years old.

> So FORTRAN has some catching up to do.

> It wasn't until the microcomputer era with BASIC, I think that FORTRAN
> wasn't the first HLL to be contemplated for a new architecture.


"I don't know what the language of the year 2000 will look like, but I know
it will be called Fortran."

--Tony Hoare, winner of the 1980 Turing Award,
  in 1982.

Re: HP 9000/382 Questions

[Gregory Beat via cctalk]

Just threw out all of my HP/UX v9 training manuals from that era, last year.
Reliable machine for the era when Intel 80386/80486 were the top processors.

greg

Sent from iPad Air

Re: I hate the new mail system

[Allison Parent via cctalk]

My puff of smoke.  The email provider used decided to quit (verizon) so its
gmail.

The list works.  It broke from time to time before and kept sending
everything at least
twice if not many more times.

This whole discussion is a waste of bandwidth and a disrespect to those
that keep it functioning.

Allison

On Fri, Mar 17, 2017 at 11:42 AM, Dave Wade G4UGM via cctalk <
cctalk@classiccmp.org> wrote:

> > -Original Message-
> > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Tor
> > Arntsen via cctalk
> > Sent: 17 March 2017 15:38
> > To: General Discussion: On-Topic and Off-Topic Posts
> > 
> > Subject: Re: I hate the new mail system
> >
> > On 17 March 2017 at 14:43, Philipp Hachtmann via cctalk
> >  wrote:
> > >
> > >
> > > On 03/16/2017 10:07 PM, Mike Stein via cctalk wrote:
> > >>
> > >> I'm pretty confident that every member of the list appreciates the
> > >> time, effort and whatever else you and certain others have
> > >> contributed to keep this list humming as well as it almost always
> > >> does;
> > >
> > > Full ack, of course!
> > >
> > > But the new addressing scheme still sucks, sorry.
> >
> > I still maintain that the change solved every issue I've had, reading
> with gmail.
> > No more posts ending up in the spam folder unless I configured 'never
> send
> > to spam' (which has its own issues), no more of the weekly or bi-weekly
> > automatic de-registrations, and addressing (when replying) at the same
> level
> > of difficulty as before (i.e. not much, just edit out what's not needed).
>
> The same here. Much better.
>
> Dave
>
>