30 Sep
2024
30 Sep
'24
2:21 p.m.
I have two SPST time delay 12-volt relays packaged like vacuum tubes
with octal bases, Amperite models 12N010 (ten seconds) and 12C5 (five
seconds).
They're in their original boxes.
I have no idea what devices used them.
It seems a shame to throw them in a recycle bin.
Does anybody want them?
Van Snyder
30 Sep
30 Sep
2:23 p.m.
One application for devices like that would be vacuum tube power amplifiers, to delay the
high voltage power supply until after the heater current has been on for a bit.
paul
On Sep 30, 2024, at 5:21 PM, Van Snyder via cctalk
<cctalk(a)classiccmp.org> wrote:
I have two SPST time delay 12-volt relays packaged like vacuum tubes
with octal bases, Amperite models 12N010 (ten seconds) and 12C5 (five
seconds).
They're in their original boxes.
I have no idea what devices used them.
It seems a shame to throw them in a recycle bin.
Does anybody want them?
Van Snyder
3:04 p.m.
If no takers, donate them to Goodwill. They’ll put them up on their web site and someone
will buy them. And you can get a tax deduction.
Sent from my iPhone
On Sep 30, 2024, at 14:23, Paul Koning via cctalk
<cctalk(a)classiccmp.org> wrote:
One application for devices like that would be vacuum tube power amplifiers, to delay
the high voltage power supply until after the heater current has been on for a bit.
paul
On Sep 30, 2024, at 5:21 PM, Van Snyder via
cctalk <cctalk(a)classiccmp.org> wrote:
I have two SPST time delay 12-volt relays packaged like vacuum tubes
with octal bases, Amperite models 12N010 (ten seconds) and 12C5 (five
seconds).
They're in their original boxes.
I have no idea what devices used them.
It seems a shame to throw them in a recycle bin.
Does anybody want them?
Van Snyder
3:58 p.m.
I'd be happy to take them if no one else has a specific use for them. They
sound like they'd be interesting to put into a project. What do you want
for them? And what would shipping cost?
~Daniel
On Mon, Sep 30, 2024 at 4:04 PM Wayne S via cctalk <cctalk(a)classiccmp.org>
wrote:
If no takers, donate them to Goodwill. They’ll put
them up on their web
site and someone will buy them. And you can get a tax deduction.
Sent from my iPhone
On Sep 30, 2024, at 14:23, Paul Koning via cctalk
<cctalk(a)classiccmp.org>
wrote:
One application for devices like that would be vacuum tube power
amplifiers, to delay the high voltage power supply until after the heater
current has been on for a bit.
paul
> On Sep 30, 2024, at 5:21 PM, Van Snyder via cctalk <
cctalk(a)classiccmp.org> wrote:
I have two SPST time delay 12-volt relays packaged like vacuum tubes
with octal bases, Amperite models 12N010 (ten seconds) and 12C5 (five
seconds).
They're in their original boxes.
I have no idea what devices used them.
It seems a shame to throw them in a recycle bin.
Does anybody want them?
Van Snyder
6:31 p.m.
On 9/30/24 16:23, Paul Koning via cctalk wrote:
One application for devices like that would be vacuum
tube power amplifiers, to delay the high voltage power supply until after the heater
current has been on for a bit.
paul
> On Sep 30, 2024, at 5:21 PM, Van Snyder via cctalk <cctalk(a)classiccmp.org>
wrote:
>
>
> I have two SPST time delay 12-volt relays packaged like vacuum tubes
> with octal bases, Amperite models 12N010 (ten seconds) and 12C5 (five
> seconds).
>
Another place they were used (but I think 60 second delay)
was in the IBM 2314 disk system, where these delayed loading
the heads until the drive had been spinning for 60 seconds
or so.
Jon
7:03 p.m.
On 9/30/2024 6:31 PM, Jon Elson via cctalk wrote:
On 9/30/24 16:23, Paul Koning via cctalk wrote:
Now that's an actual antique computer application, though I'm surprised
they didn't use a solid state implementation.
Bob
--
Vintage computers and electronics
www.dvq.com
www.tekmuseum.com
www.decmuseum.org
One application for devices like that would be
vacuum tube power
amplifiers, to delay the high voltage power supply until after the
heater current has been on for a bit.
paul
> On Sep 30, 2024, at 5:21 PM, Van Snyder via cctalk
> <cctalk(a)classiccmp.org> wrote:
>
>
> I have two SPST time delay 12-volt relays packaged like vacuum tubes
> with octal bases, Amperite models 12N010 (ten seconds) and 12C5 (five
> seconds).
>
Another place they were used (but I think 60 second delay) was in the
IBM 2314 disk system, where these delayed loading the heads until the
drive had been spinning for 60 seconds or so.
Jon
7:16 p.m.
On 2024-09-30 8:03 p.m., Bob Rosenbloom via cctalk wrote:
Ben, ducking the thrown banana.
On 9/30/2024 6:31 PM, Jon Elson via cctalk wrote:
Why would do something so new?
We all know keypunches back then came with coding forms
and the odd monkey.
On 9/30/24 16:23, Paul Koning via cctalk wrote:
Now that's an actual antique computer application, though I'm surprised
they didn't use a solid state implementation.
Bob One application for devices like that would be
vacuum tube power
amplifiers, to delay the high voltage power supply until after the
heater current has been on for a bit.
paul
> On Sep 30, 2024, at 5:21 PM, Van Snyder via cctalk
> <cctalk(a)classiccmp.org> wrote:
>
>
> I have two SPST time delay 12-volt relays packaged like vacuum tubes
> with octal bases, Amperite models 12N010 (ten seconds) and 12C5 (five
> seconds).
>
Another place they were used (but I think 60 second delay) was in the
IBM 2314 disk system, where these delayed loading the heads until the
drive had been spinning for 60 seconds or so.
Jon
1 Oct
1 Oct
7:54 a.m.
On 9/30/24 21:03, Bob Rosenbloom via cctalk wrote:
On 9/30/2024 6:31 PM, Jon Elson via cctalk wrote:
The IBM 2314 was REALLY low tech. There was almost no
electronics in the drives! They has a read amp, a write amp
and a hydraulic "stepper motor" with mechanical detents that
moved the heads in response to step in and step out pulses
from the control unit.
IBM did know how to distill things down to the absolute
minimum. Remember, this was developed in the early 1960s and
first shipped with the first 360's in 1965.
Jon
On 9/30/24 16:23, Paul Koning via cctalk wrote:
Now that's an actual antique computer application, though
I'm surprised they didn't use a solid state implementation.
Bob
One application for devices like that would be
vacuum
tube power amplifiers, to delay the high voltage power
supply until after the heater current has been on for a
bit.
paul
> On Sep 30, 2024, at 5:21 PM, Van Snyder via cctalk
> <cctalk(a)classiccmp.org> wrote:
>
>
> I have two SPST time delay 12-volt relays packaged like
> vacuum tubes
> with octal bases, Amperite models 12N010 (ten seconds)
> and 12C5 (five
> seconds).
>
Another place they were used (but I think 60 second
delay) was in the IBM 2314 disk system, where these
delayed loading the heads until the drive had been
spinning for 60 seconds or so.
Jon
8:11 a.m.
On Oct 1, 2024, at 10:54 AM, Jon Elson via cctalk
<cctalk(a)classiccmp.org> wrote:
I haven't met a 2314, but I did see 2311 drives on a 360/44 and 1311 drives on a 1620.
The 1311 is definitely hydraulic -- I learned that when ours sprung a leak and sprayed
hydraulic fluid all over the system pack. It got fixed perfectly, though. So that drive
technology may be older than 1965.
paul
...
The IBM 2314 was REALLY low tech.
There was almost no electronics in the drives! They has a read amp, a write amp and a
hydraulic "stepper motor" with mechanical detents that moved the heads in
response to step in and step out pulses from the control unit.
IBM did know how to distill things down to the absolute minimum. Remember, this was
developed in the early 1960s and first shipped with the first 360's in 1965. 
8:30 a.m.
On 10/1/24 07:54, Jon Elson via cctalk wrote:
The IBM 2314 was REALLY low tech. There was almost no
electronics in
the drives! They has a read amp, a write amp and a hydraulic "stepper
motor" with mechanical detents that moved the heads in response to step
in and step out pulses from the control unit.
IBM did know how to distill things down to the absolute minimum.
Remember, this was developed in the early 1960s and first shipped with
the first 360's in 1965.
Hydraulic positioning was used in several early drives. The Bryant
4000/CDC 6603, for example, had containers to catch leaks. ISTR that
the head assemblies weighed about 8 lbs each.
The Univac FASTRAND drum, on the other hand, used electromagnetic
positioning, employing a mechanical lever adder to come up with a binary
position.
-C
10:26 a.m.
On Oct 1, 2024, at 11:30 AM, Chuck Guzis via cctalk
<cctalk(a)classiccmp.org> wrote:
On 10/1/24 07:54, Jon Elson via cctalk wrote:
For that matter, the first hard drive (IBM RAMAC) used hydraulic positioners, for both
cylinder and track select I believe. It had only one or two heads, so track switching was
a mechanical operation and actually a lot more expensive than changing cylinders.
The IBM 2314 was REALLY low tech. There was
almost no electronics in
the drives! They has a read amp, a write amp and a hydraulic "stepper
motor" with mechanical detents that moved the heads in response to step
in and step out pulses from the control unit.
IBM did know how to distill things down to the absolute minimum.
Remember, this was developed in the early 1960s and first shipped with
the first 360's in 1965.
Hydraulic positioning was used in several early drives. The Bryant
4000/CDC 6603, for example, had containers to catch leaks. ISTR that
the head assemblies weighed about 8 lbs each. The Univac FASTRAND drum, on the other hand, used
electromagnetic
positioning, employing a mechanical lever adder to come up with a binary
position.
-C
Interesting. It reminds me of technology used on PLATO terminals, both in the microfiche
projector option and in the audio disc player: a set of pneumatic pistons with stroke
length scaled 1:2:4:8 so you could get any of 16 positions by sending a 4 bit address to a
set of 4 valves. It's the only place I've ever seen where computer terminals had
connections to pneumatic supply lines.
paul
4:29 p.m.
-----Original Message-----
From: Jon Elson <elson(a)pico-systems.com>
<snip>
Now that's an actual antique computer application, though I'm
surprised they didn't use a solid state implementation.
Bob
The IBM 2314 was REALLY low tech. There was almost no electronics in the drives!
They has a read amp, a write amp and a hydraulic "stepper motor" with mechanical
detents that moved the heads in response to step in and step out pulses from the control
unit.
IBM did know how to distill things down to the absolute minimum. Remember, this was
developed in the early 1960s and first shipped with the first 360's in 1965.
Jon
Comment--------------------------------------
I wouldn't call the 2314 low tech - it was the highest areal density at the time, a
breakthru with ferrite heads and very low cost to manufacture. Note I said cost, its
profit margin was enormous, in part by putting as much expensive electronics as possible
in the control unit. 😊
Actually the 2314 did not ship with the first 360's in 1965; it was announced in April
1965 about 1 year after the 360 announcement and AFAICT from Bitsavers document dates it
didn't ship until late 1966, which FWIW, at the Computer History Museum, 1966 is also
the date for first shipment of the 2414 and its ferrite heads. BTW the hydraulic actuator
design goes back to the 1311 - more or less the same actuator in the 1311, 2311 and 2314.
Tom
> I have two SPST time delay 12-volt relays packaged
like vacuum
> tubes with octal bases, Amperite models 12N010 (ten seconds) and
> 12C5 (five seconds).
>
Another place they were used (but I think 60 second
delay) was in the IBM 2314 disk system, where these delayed loading
the heads until the drive had been spinning for 60 seconds or so.
Jon
4:55 p.m.
On 10/1/24 18:29, Tom Gardner via cctalk wrote:
I wouldn't call the 2314 low tech - it was the highest areal density at the time, a
breakthru with ferrite heads and very low cost to manufacture. Note I said cost, its
profit margin was enormous, in part by putting as much expensive electronics as possible
in the control unit. 😊
Actually the 2314 did not ship with the first 360's in 1965; it was announced in
April 1965 about 1 year after the 360 announcement and AFAICT from Bitsavers document
dates it didn't ship until late 1966, which FWIW, at the Computer History Museum, 1966
is also the date for first shipment of the 2414 and its ferrite heads. BTW the hydraulic
actuator design goes back to the 1311 - more or less the same actuator in the 1311, 2311
and 2314.
Well, yes, and in the days of SLT logic, everything was
expensive. So, putting as much of the functions in the
control unit rather than the drive was good. But, one thing
that this mindset caused was that they could not have one
drive seeking while another drive was transferring. The
entire operation, cylinder seek, rotational seek and data
transfer was all one atomic operation. That really killed
the throughput of the whole disk system. The reason was
that the IBM developers came from systems like 7070 and 7090
where all permanent storage was on tape, and they didn't
quite "get" how central disks were going to be to the 360
systems. They had the CKD scheme, where you could search
several cylinders for a match of some arbitrary field in the
DATA portion of a sector, but this resulted in massive
slowdown of the system, as it tied up not only the drive,
but the controller and the channel as well! Thus the need
for the database system, which would make selecting the
desired record much faster.
I didn't mean that the 2314 DISK was low tech, just that the
drive, itself, was quite spartan.
Jon
2 Oct
2 Oct
1:15 p.m.
-----Original Message-----
From: Jon Elson <elson(a)pico-systems.com>
Sent: Tuesday, October 01, 2024 4:55 PM
To: Tom Gardner via cctalk <cctalk(a)classiccmp.org>
Subject: [cctalk] Re: Might be antique computer parts
On 10/1/24 18:29, Tom Gardner via cctalk wrote:
Well, the IBM S/360 IOS implemented a stand-alone seek which allowed seek overlap
and pretty much eliminated seek latency. Later on in System/370 they added disconnected
command chaining and RPS which then reduced seek and rotational latency. S/360 and S/370
seemed to run fast enough for many applications not using database software. At least it
appears to me that the need for database software was driven by other market forces than
the performance of S/360 and S/370 Channel hardware
Tom
I wouldn't call the 2314 low tech - it was the highest areal density at the time, a
breakthru with ferrite heads and very low cost to manufacture. Note I said cost, its
profit margin was enormous, in part by putting as much expensive electronics as possible
in the control unit. ??
Actually the 2314 did not ship with the first 360's in 1965; it was announced in
April 1965 about 1 year after the 360 announcement and AFAICT from Bitsavers document
dates it didn't ship until late 1966, which FWIW, at the Computer History Museum, 1966
is also the date for first shipment of the 2414 and its ferrite heads. BTW the hydraulic
actuator design goes back to the 1311 - more or less the same actuator in the 1311, 2311
and 2314.
Well, yes, and in the days of SLT logic, everything was expensive. So, putting as much of
the functions in the control unit rather than the drive was good. But, one thing that
this mindset caused was that they could not have one drive seeking while another drive was
transferring. The entire operation, cylinder seek, rotational seek and data transfer was
all one atomic operation. That really killed the throughput of the whole disk system.
The reason was that the IBM developers came from systems like 7070 and 7090 where all
permanent storage was on tape, and they didn't quite "get" how central disks
were going to be to the 360 systems. They had the CKD scheme, where you could search
several cylinders for a match of some arbitrary field in the DATA portion of a sector, but
this resulted in massive slowdown of the system, as it tied up not only the drive, but the
controller and the channel as well! Thus the need for the database system, which would
make selecting the desired record much faster.
I didn't mean that the 2314 DISK was low tech, just that the drive, itself, was quite
spartan.
Jon
1:39 p.m.
-----Original Message-----
From: Jon Elson <elson(a)pico-systems.com>
Sent: Tuesday, October 01, 2024 4:55 PM
To: Tom Gardner via cctalk <cctalk(a)classiccmp.org>
Subject: [cctalk] Re: Might be antique computer parts
On 10/1/24 18:29, Tom Gardner via cctalk wrote:
For the earlier 1311, lack of overlap made perfect sense. After all, the 1620 has no
interrupts, no parallelism of any kind: every I/O operation stalls the CPU until the
operation is finished. (That and the BB instruction are among the reasons why Dijkstra
rejected the 1620.)
Speaking of high profit margins: on the 1620, there was an extra cost option called
"direct seek". I don't know if involved a jumper cut or some actual
circuitry (an adder, most likely). We didn't have that, and the result is that a seek
from cylinder x to cylinder y was done by a full retract to cylinder 0, followed by a seek
out to y. It was amusing to watch the shaking resulting from a simple "incrementing
seek test" -- seek to cylinder i for i = 0 to 99. Those last few seeks would take
the better part of a second.
paul
I wouldn't call the 2314 low tech - it was the highest areal density at the time, a
breakthru with ferrite heads and very low cost to manufacture. Note I said cost, its
profit margin was enormous, in part by putting as much expensive electronics as possible
in the control unit. ??
Actually the 2314 did not ship with the first 360's in 1965; it was announced in
April 1965 about 1 year after the 360 announcement and AFAICT from Bitsavers document
dates it didn't ship until late 1966, which FWIW, at the Computer History Museum, 1966
is also the date for first shipment of the 2414 and its ferrite heads. BTW the hydraulic
actuator design goes back to the 1311 - more or less the same actuator in the 1311, 2311
and 2314.
Well, yes, and in the days of SLT logic, everything was expensive. So, putting as much
of the functions in the control unit rather than the drive was good. But, one thing that
this mindset caused was that they could not have one drive seeking while another drive was
transferring. The entire operation, cylinder seek, rotational seek and data transfer was
all one atomic operation. That really killed the throughput of the whole disk system.
The reason was that the IBM developers came from systems like 7070 and 7090 where all
permanent storage was on tape, and they didn't quite "get" how central disks
were going to be to the 360 systems. They had the CKD scheme, where you could search
several cylinders for a match of some arbitrary field in the DATA portion of a sector, but
this resulted in massive slowdown of the system, as it tied up not only the drive, but the
controller and the channel as well! Thus the need for the database system, which would
make selecting the desired record much faster.
I didn't mean that the 2314 DISK was low tech, just that the drive, itself, was quite
spartan.
Jon 
1:52 p.m.
Some PC HD maker offered a drive with a clear top so you could see the heads moving. I had
a friend write a VB program to do random seeks. It was fun to watch. Still have the drive
and the program. Don’t know if the program will run in Win 11. 😊
On Oct 2, 2024, at 13:39, Paul Koning via cctalk
<cctalk(a)classiccmp.org> wrote:
-----Original Message-----
From: Jon Elson <elson(a)pico-systems.com>
Sent: Tuesday, October 01, 2024 4:55 PM
To: Tom Gardner via cctalk <cctalk(a)classiccmp.org>
Subject: [cctalk] Re: Might be antique computer parts
For the earlier 1311, lack of overlap made perfect sense. After all, the 1620 has no
interrupts, no parallelism of any kind: every I/O operation stalls the CPU until the
operation is finished. (That and the BB instruction are among the reasons why Dijkstra
rejected the 1620.)
Speaking of high profit margins: on the 1620, there was an extra cost option called
"direct seek". I don't know if involved a jumper cut or some actual
circuitry (an adder, most likely). We didn't have that, and the result is that a seek
from cylinder x to cylinder y was done by a full retract to cylinder 0, followed by a seek
out to y. It was amusing to watch the shaking resulting from a simple "incrementing
seek test" -- seek to cylinder i for i = 0 to 99. Those last few seeks would take
the better part of a second.
paul
On 10/1/24 18:29, Tom Gardner via cctalk wrote:
I wouldn't call the 2314 low tech - it was the highest areal density at the time, a
breakthru with ferrite heads and very low cost to manufacture. Note I said cost, its
profit margin was enormous, in part by putting as much expensive electronics as possible
in the control unit. ??
Actually the 2314 did not ship with the first 360's in 1965; it was announced in
April 1965 about 1 year after the 360 announcement and AFAICT from Bitsavers document
dates it didn't ship until late 1966, which FWIW, at the Computer History Museum, 1966
is also the date for first shipment of the 2414 and its ferrite heads. BTW the hydraulic
actuator design goes back to the 1311 - more or less the same actuator in the 1311, 2311
and 2314.
Well, yes, and in the days of SLT logic, everything was expensive. So, putting as much
of the functions in the control unit rather than the drive was good. But, one thing that
this mindset caused was that they could not have one drive seeking while another drive was
transferring. The entire operation, cylinder seek, rotational seek and data transfer was
all one atomic operation. That really killed the throughput of the whole disk system.
The reason was that the IBM developers came from systems like 7070 and 7090 where all
permanent storage was on tape, and they didn't quite "get" how central disks
were going to be to the 360 systems. They had the CKD scheme, where you could search
several cylinders for a match of some arbitrary field in the DATA portion of a sector, but
this resulted in massive slowdown of the system, as it tied up not only the drive, but the
controller and the channel as well! Thus the need for the database system, which would
make selecting the desired record much faster.
I didn't mean that the 2314 DISK was low tech, just that the drive, itself, was quite
spartan.
Jon
3 Oct
3 Oct
10:56 a.m.
On 2024-10-02 2:52 p.m., bluewater emailtoilet.com via cctalk wrote:
Some PC HD maker offered a drive with a clear top so
you could see the heads moving. I had a friend write a VB program to do random seeks. It
was fun to watch. Still have the drive and the program. Don’t know if the program will run
in Win 11. 😊
Not like old computers, that could sing and drives could dance. :)
I know the PDP-8 could do music thru a AM radio. Did they ever have it sing?
12:13 p.m.
On 03/10/2024 19:56, ben via cctalk wrote:
Not like old computers, that could sing and drives
could dance. :)
I know the PDP-8 could do music thru a AM radio. Did they ever have it sing?
No, they used DecTalks.
https://www.youtube.com/watch?v=1l0Ko1GUiSo&pp=ygUecGV0ZXIgbGFuZ3N0b24g…
https://peterlangston.com/Papers/2332.pdf
Julf
2 Oct
2 Oct
2:23 p.m.
On Wed, 2024-10-02 at 16:39 -0400, Paul Koning via cctalk wrote:
For the earlier 1311, lack of overlap made perfect
sense. After all,
the 1620 has no interrupts, no parallelism of any kind: every I/O
operation stalls the CPU until the operation is finished. (That and
the BB instruction are among the reasons why Dijkstra rejected the
1620.)
1401 had overlap, but as far as I can tell, only for cards and tape.
The 1403 had a buffer, and 1401 had instructions to test whether the
printer or carriage were busy, but that "overlap" didn't work the same
as for cards and tape.
I remember the 1620 being called CADET, but not because it was a
beginner computer. It didn't have arithmetic hardware. It was done by
table lookup. CADET meant "Can't Add, Doesn't Even Try." One of my
colleagues exploited the table-based arithmetic to do octal arithmetic
for satellite telemetry processing.
3 Oct
3 Oct
7:05 a.m.
On Oct 2, 2024, at 5:23 PM, Van Snyder via cctalk
<cctalk(a)classiccmp.org> wrote:
On Wed, 2024-10-02 at 16:39 -0400, Paul Koning via cctalk wrote:
That would be the Model 1, which had "add-multiply tables" in lowcore. Adding
and multiplying was done by looking up entries in those tables. I assume the address was
formed from the two input digits, producing a two-digit result (or for add, maybe a one
digit result plus a carry bit encoded in the sign bit). Core memory of course is
non-volatile so unless you had a program scribble wildly, those tables would carry from
one run to the next. When in doubt, you could boot the add-multiply tables card deck to
load the correct values.
And yes, you could do octal arithmetic that way, in the sense of interpreting a string of
digits in memory as octal rather than decimal digits. Neat hack.
Ours was a Model 2, which differs in a number of ways; one major difference is that it has
add and multiply hardware. So while we did have an add-multiply card deck sitting around,
it wasn't actually needed.
A fun aspect of both machines is that they would do arithmetic on variable length
operands, of any length if you were patient enough. So you could add a pair of 5000 digit
numbers. The same was true for floating point (I don't know if that was only in Model
2), the mantissa was variable length (the exponent always two digits). I remember the
Fortran compiler had a compiler option setting to choose the "field length"
(number of digits) for the integer and real data types, allowing you to pick any length up
to 20 digits separately for each.
Speaking of interrupts vs. blocking I/O, there's an interesting hybrid technique
I've seen only in one place: the Electrologica X1 will interrupt on completion of an
I/O, but also allows you to start a new I/O on a device that's still busy with the
preceding one. If you do that, the second I/O command will block the CPU until the first
one is done, then it will issue the I/O start and the instruction is then complete. In
practice, I/O was interrupt driven, but with the help of what is arguably the world's
first BIOS, a set of ROM resident I/O library routines originally written by Dijkstra for
his Ph.D. project. As far as I can tell, the X1 was the world's first production
computer with interrupts as a standard feature.
paul
For the earlier 1311, lack of overlap made
perfect sense. After all,
the 1620 has no interrupts, no parallelism of any kind: every I/O
operation stalls the CPU until the operation is finished. (That and
the BB instruction are among the reasons why Dijkstra rejected the
1620.)
1401 had overlap, but as far as I can tell, only for cards and tape.
The 1403 had a buffer, and 1401 had instructions to test whether the
printer or carriage were busy, but that "overlap" didn't work the same
as for cards and tape.
I remember the 1620 being called CADET, but not because it was a
beginner computer. It didn't have arithmetic hardware. It was done by
table lookup. CADET meant "Can't Add, Doesn't Even Try." One of my
colleagues exploited the table-based arithmetic to do octal arithmetic
for satellite telemetry processing. 
8:13 a.m.
The IBM 1710 was a 1620 enhanced for process control. It had interrupts.
Dave Wise
________________________________
From: Paul Koning via cctalk <cctalk(a)classiccmp.org>
Sent: Thursday, October 3, 2024 7:05 AM
To: cctalk(a)classiccmp.org <cctalk(a)classiccmp.org>
Cc: Paul Koning <paulkoning(a)comcast.net>
Subject: [cctalk] Re: Might be antique computer parts
On Oct 2, 2024, at 5:23 PM, Van Snyder via cctalk
<cctalk(a)classiccmp.org> wrote:
On Wed, 2024-10-02 at 16:39 -0400, Paul Koning via cctalk wrote:
That would be the Model 1, which had "add-multiply tables" in lowcore. Adding
and multiplying was done by looking up entries in those tables. I assume the address was
formed from the two input digits, producing a two-digit result (or for add, maybe a one
digit result plus a carry bit encoded in the sign bit). Core memory of course is
non-volatile so unless you had a program scribble wildly, those tables would carry from
one run to the next. When in doubt, you could boot the add-multiply tables card deck to
load the correct values.
And yes, you could do octal arithmetic that way, in the sense of interpreting a string of
digits in memory as octal rather than decimal digits. Neat hack.
Ours was a Model 2, which differs in a number of ways; one major difference is that it has
add and multiply hardware. So while we did have an add-multiply card deck sitting around,
it wasn't actually needed.
A fun aspect of both machines is that they would do arithmetic on variable length
operands, of any length if you were patient enough. So you could add a pair of 5000 digit
numbers. The same was true for floating point (I don't know if that was only in Model
2), the mantissa was variable length (the exponent always two digits). I remember the
Fortran compiler had a compiler option setting to choose the "field length"
(number of digits) for the integer and real data types, allowing you to pick any length up
to 20 digits separately for each.
Speaking of interrupts vs. blocking I/O, there's an interesting hybrid technique
I've seen only in one place: the Electrologica X1 will interrupt on completion of an
I/O, but also allows you to start a new I/O on a device that's still busy with the
preceding one. If you do that, the second I/O command will block the CPU until the first
one is done, then it will issue the I/O start and the instruction is then complete. In
practice, I/O was interrupt driven, but with the help of what is arguably the world's
first BIOS, a set of ROM resident I/O library routines originally written by Dijkstra for
his Ph.D. project. As far as I can tell, the X1 was the world's first production
computer with interrupts as a standard feature.
paul
For the earlier 1311, lack of overlap made
perfect sense. After all,
the 1620 has no interrupts, no parallelism of any kind: every I/O
operation stalls the CPU until the operation is finished. (That and
the BB instruction are among the reasons why Dijkstra rejected the
1620.)
1401 had overlap, but as far as I can tell, only for cards and tape.
The 1403 had a buffer, and 1401 had instructions to test whether the
printer or carriage were busy, but that "overlap" didn't work the same
as for cards and tape.
I remember the 1620 being called CADET, but not because it was a
beginner computer. It didn't have arithmetic hardware. It was done by
table lookup. CADET meant "Can't Add, Doesn't Even Try." One of my
colleagues exploited the table-based arithmetic to do octal arithmetic
for satellite telemetry processing. 
9:01 a.m.
New subject: Might be antique computer parts --1620
I worked on a model 1 with 40k memory (my very first computer experience) and floating
point, and later a model 2 stripped. I believe the model 2 still used table lookup for
multiply.
floating point in model 1 (and I think model 2) was limited to a 98 digit mantissa, still
more precision than the hardware in any subsequent computer AFAIK. since the exponent was
10**-99 to 10**99 a broader range than any computer till many years later I think.
fixed point divide was limited to (?) 10000 digits because it ended at address x0099, i
set that up once it took a loonng time for that one instruction to execute. might have
been 1000 digits only.
don't know if the disk i/o RPQ overlapped, I saw one through a glass window once.
I'll have to look up the 1710. There are emulators for the 1620, i hope there are for
the 1710 too. I had forgotten or never knew the relationship, thank you.
<pre>--Carey</pre>
On 10/03/2024 10:13 AM CDT David Wise via cctalk
<cctalk(a)classiccmp.org> wrote:
The IBM 1710 was a 1620 enhanced for process control. It had interrupts.
Dave Wise
________________________________
From: Paul Koning via cctalk <cctalk(a)classiccmp.org>
Sent: Thursday, October 3, 2024 7:05 AM
To: cctalk(a)classiccmp.org <cctalk(a)classiccmp.org>
Cc: Paul Koning <paulkoning(a)comcast.net>
Subject: [cctalk] Re: Might be antique computer parts
On Oct 2, 2024, at 5:23 PM, Van Snyder via cctalk
<cctalk(a)classiccmp.org> wrote:
On Wed, 2024-10-02 at 16:39 -0400, Paul Koning via cctalk wrote:
That would be the Model 1, which had "add-multiply tables" in lowcore. Adding
and multiplying was done by looking up entries in those tables. I assume the address was
formed from the two input digits, producing a two-digit result (or for add, maybe a one
digit result plus a carry bit encoded in the sign bit). Core memory of course is
non-volatile so unless you had a program scribble wildly, those tables would carry from
one run to the next. When in doubt, you could boot the add-multiply tables card deck to
load the correct values.
And yes, you could do octal arithmetic that way, in the sense of interpreting a string of
digits in memory as octal rather than decimal digits. Neat hack.
Ours was a Model 2, which differs in a number of ways; one major difference is that it
has add and multiply hardware. So while we did have an add-multiply card deck sitting
around, it wasn't actually needed.
A fun aspect of both machines is that they would do arithmetic on variable length
operands, of any length if you were patient enough. So you could add a pair of 5000 digit
numbers. The same was true for floating point (I don't know if that was only in Model
2), the mantissa was variable length (the exponent always two digits). I remember the
Fortran compiler had a compiler option setting to choose the "field length"
(number of digits) for the integer and real data types, allowing you to pick any length up
to 20 digits separately for each.
Speaking of interrupts vs. blocking I/O, there's an interesting hybrid technique
I've seen only in one place: the Electrologica X1 will interrupt on completion of an
I/O, but also allows you to start a new I/O on a device that's still busy with the
preceding one. If you do that, the second I/O command will block the CPU until the first
one is done, then it will issue the I/O start and the instruction is then complete. In
practice, I/O was interrupt driven, but with the help of what is arguably the world's
first BIOS, a set of ROM resident I/O library routines originally written by Dijkstra for
his Ph.D. project. As far as I can tell, the X1 was the world's first production
computer with interrupts as a standard feature.
paul For the earlier 1311, lack of overlap made
perfect sense. After all,
the 1620 has no interrupts, no parallelism of any kind: every I/O
operation stalls the CPU until the operation is finished. (That and
the BB instruction are among the reasons why Dijkstra rejected the
1620.)
1401 had overlap, but as far as I can tell, only for cards and tape.
The 1403 had a buffer, and 1401 had instructions to test whether the
printer or carriage were busy, but that "overlap" didn't work the same
as for cards and tape.
I remember the 1620 being called CADET, but not because it was a
beginner computer. It didn't have arithmetic hardware. It was done by
table lookup. CADET meant "Can't Add, Doesn't Even Try." One of my
colleagues exploited the table-based arithmetic to do octal arithmetic
for satellite telemetry processing.
10:39 a.m.
New subject: Might be antique computer parts --1620
On Oct 3, 2024, at 12:01 PM, CAREY SCHUG via cctalk
<cctalk(a)classiccmp.org> wrote:
I worked on a model 1 with 40k memory (my very first computer experience) and floating
point, and later a model 2 stripped. I believe the model 2 still used table lookup for
multiply.
Sure enough, that's what the Model 2 manual I just found on Bitsavers says. I always
though that both add and multiply were in hardware. Interesting. Another major
enhancement in model 2 is index registers.
floating point in model 1 (and I think model 2) was
limited to a 98 digit mantissa, still more precision than the hardware in any subsequent
computer AFAIK. since the exponent was 10**-99 to 10**99 a broader range than any
computer till many years later I think.
100 digits says the model 2 manual.
Exponents larger than that do appear in machines of that era. The CDC 6000 series goes up
to 10**322 (11 bit signed binary exponent) and the Electrologica X8 to 10**644 (12 bit
signed binary exponent). Both are early 1960s. I don't remember what the IBM
360's range is; the exponent field is fairly small but it's a power of 16 rather
than the usual power of 2 (or power of 10 as in the 1620).
...
don't know if the disk i/o RPQ overlapped, I saw one through a glass window once.
No, just like all the other I/O instructions they block the CPU.
paul
10:51 a.m.
New subject: Might be antique computer parts --1620
The IBM 360 single precision floating point has a range of 10**-79 to 10**75; double
precision and extended precision has the same number of bits for the exponent.
From: "Paul Koning via cctalk" <cctalk(a)classiccmp.org>
To: "cctalk" <cctalk(a)classiccmp.org>
Cc: "David Wise" <d44617665(a)hotmail.com>om>, "CAREY SCHUG"
<sqrfolkdnc(a)comcast.net>et>, "Paul Koning" <paulkoning(a)comcast.net>
Sent: Thursday, October 3, 2024 10:39:47 AM
Subject: [cctalk] Re: Might be antique computer parts --1620
On Oct 3, 2024, at 12:01 PM, CAREY SCHUG via cctalk
<cctalk(a)classiccmp.org> wrote:
I worked on a model 1 with 40k memory (my very first computer experience) and floating
point, and later a model 2 stripped. I believe the model 2 still used table lookup for
multiply.
Sure enough, that's what the Model 2 manual I just found on Bitsavers says. I always
though that both add and multiply were in hardware. Interesting. Another major enhancement
in model 2 is index registers.
floating point in model 1 (and I think model 2) was
limited to a 98 digit mantissa, still more precision than the hardware in any subsequent
computer AFAIK. since the exponent was 10**-99 to 10**99 a broader range than any computer
till many years later I think.
100 digits says the model 2 manual.
Exponents larger than that do appear in machines of that era. The CDC 6000 series goes up
to 10**322 (11 bit signed binary exponent) and the Electrologica X8 to 10**644 (12 bit
signed binary exponent). Both are early 1960s. I don't remember what the IBM 360's
range is; the exponent field is fairly small but it's a power of 16 rather than the
usual power of 2 (or power of 10 as in the 1620).
...
don't know if the disk i/o RPQ overlapped, I saw one through a glass window once.
No, just like all the other I/O instructions they block the CPU.
paul
12:25 p.m.
New subject: Might be antique computer parts --1620
On 10/3/24 10:51, Norman Jaffe via cctalk wrote:
The IBM 360 single precision floating point has a
range of 10**-79 to 10**75; double precision and extended precision has the same number of
bits for the exponent.
...and most significanrly, normalized to only the hex digit (4 bits),
not to the bit. Really awful if you thought you could migrate code
from a 7094...
--Chuck
12:57 p.m.
New subject: Might be antique computer parts --1620
On 10/3/24 14:25, Chuck Guzis via cctalk wrote:
On 10/3/24 10:51, Norman Jaffe via cctalk wrote:
Yes, this was a huge error on IBM's part. There are some
standard numerical algorithms that work by examining small
differences between numbers and then iterating. The varying
level of precision (up to 3 lost bits of significance) made
all these iterations very problematic on the 360/370. IBM
finally admitted their mistake and put IEEE floating point
on their later mainframes as a software-selectable option.
I helped one physicist who was trying to run a big VAX
astrophysics simulation on the U of MO 370 that ran into
this. It ran fin on our VAX, of course.
Jon
The IBM 360 single precision floating point has a
range of 10**-79 to 10**75; double precision and extended precision has the same number of
bits for the exponent.
...and most significanrly, normalized to only the hex digit
(4 bits),
not to the bit. Really awful if you thought you could migrate code
from a 7094...
12:27 p.m.
New subject: Might be antique computer parts --1620
On 10/3/24 10:39, Paul Koning via cctalk wrote:
*FANDK
-Chuck
On Oct 3, 2024, at 12:01 PM, CAREY SCHUG via
cctalk <cctalk(a)classiccmp.org> wrote:
I worked on a model 1 with 40k memory (my very first computer experience) and floating
point, and later a model 2 stripped. I believe the model 2 still used table lookup for
multiply.
Sure enough, that's what the Model 2 manual I just found on Bitsavers
says. I always though that both add and multiply were in hardware. Interesting. Another
major enhancement in model 2 is index registers. 
4 Oct
4 Oct
12:07 a.m.
On Wed, 2 Oct 2024, Tom Gardner wrote:
Speaking of high profit margins: on the 1620, there
was an extra cost
option called "direct seek". I don't know if involved a jumper cut or
some actual circuitry (an adder, most likely). We didn't have that, and
the result is that a seek from cylinder x to cylinder y was done by a
full retract to cylinder 0, followed by a seek out to y. It was amusing
to watch the shaking resulting from a simple "incrementing seek test" --
seek to cylinder i for i = 0 to 99. Those last few seeks would take the
better part of a second.
Here's a link to a video that I took last year of a 1311 doing seeks (it
is running on a 1401): https://www.youtube.com/watch?v=LXDVRP9pfyw
Christian
8:30 a.m.
On 10/4/24 00:07, Christian Corti via cctalk wrote:
On Wed, 2 Oct 2024, Tom Gardner wrote:
We did not have the direct seek feature on the 1311 on our CADET back
then. Figure that it takes additional logic to figure out "where am I
now and where do I want to go?"
So, a feature.
--Chuck
Speaking of high profit margins: on the 1620,
there was an extra cost
option called "direct seek". I don't know if involved a jumper cut or
some actual circuitry (an adder, most likely). We didn't have that,
and the result is that a seek from cylinder x to cylinder y was done
by a full retract to cylinder 0, followed by a seek out to y. It was
amusing to watch the shaking resulting from a simple "incrementing
seek test" -- seek to cylinder i for i = 0 to 99. Those last few
seeks would take the better part of a second.
Here's a link to a video that I took last year of a 1311 doing seeks (it
is running on a 1401): https://www.youtube.com/watch?v=LXDVRP9pfyw 
10:57 a.m.
New subject: Data General MV/8000 emulator announcement
A Data General MV/8000 emulator beta release is now available from my DG
legacy preservation web site:
www.NovasAreForever.org
The MV/8000 emulator runs AOS/VS and AOS/VS II, plus associated
languages and utilities, in a single-user environment on Windows and
Linux systems.
Files are available at the bottom of the web site's emulator download page:
www.NovasAreForever.org/dgbeta/index.php
The 'Beta_Update_00.01.00_Notes.txt' file contains brief notes
describing the emulator configuration and files, and assumes substantial
knowledge about running DG systems.
Now "MVs Are Forever..."
Bruce Ray
Wild Hare Computer Systems, Inc.
Denver, Colorado USA
bkr(a)WildHareComputers.com
...preserving the Data General legacy: www.NovasAreForever.org
11:30 a.m.
New subject: Data General MV/8000 emulator announcement
Woohoo!
Rich Alderson
Sent from my iPhone
On Oct 4, 2024, at 11:00, Bruce Ray via cctalk
<cctalk(a)classiccmp.org> wrote:
A Data General MV/8000 emulator beta release is now available from my DG
legacy preservation web site:
www.NovasAreForever.org
The MV/8000 emulator runs AOS/VS and AOS/VS II, plus associated
languages and utilities, in a single-user environment on Windows and
Linux systems.
Files are available at the bottom of the web site's emulator download page:
www.NovasAreForever.org/dgbeta/index.php
The 'Beta_Update_00.01.00_Notes.txt' file contains brief notes
describing the emulator configuration and files, and assumes substantial
knowledge about running DG systems.
Now "MVs Are Forever..."
Bruce Ray
Wild Hare Computer Systems, Inc.
Denver, Colorado USA
bkr(a)WildHareComputers.com
...preserving the Data General legacy: www.NovasAreForever.org
1:04 p.m.
New subject: Data General MV/8000 emulator announcement
Nice!
So is this the current open-simh simulator, or a newer version? Will you update the one
in open-simh?
paul
On Oct 4, 2024, at 1:57 PM, Bruce Ray via cctalk
<cctalk(a)classiccmp.org> wrote:
A Data General MV/8000 emulator beta release is now available from my DG
legacy preservation web site:
www.NovasAreForever.org
The MV/8000 emulator runs AOS/VS and AOS/VS II, plus associated
languages and utilities, in a single-user environment on Windows and
Linux systems.
Files are available at the bottom of the web site's emulator download page:
www.NovasAreForever.org/dgbeta/index.php
The 'Beta_Update_00.01.00_Notes.txt' file contains brief notes
describing the emulator configuration and files, and assumes substantial
knowledge about running DG systems.
Now "MVs Are Forever..."
Bruce Ray
Wild Hare Computer Systems, Inc.
Denver, Colorado USA
bkr(a)WildHareComputers.com
...preserving the Data General legacy: www.NovasAreForever.org
5 Oct
5 Oct
8:35 a.m.
New subject: Data General MV/8000 emulator announcement
On 10/4/2024 2:04 PM, Paul Koning via cctalk wrote:
Nice!
So is this the current open-simh simulator, or a newer version? Will you update the one
in open-simh?
paul
None of the SimH versions currently has an MV emulator, so there is
technically nothing to "update".
This is a new emulator that uses parts of our commercial product stuffed
into the SimH structure. It is a challenge to adapt sections of our
commercial software into the SimH framework due to their significant
differences in design, implementation and certification. Accordingly,
it will take time before source code will be part of a SimH release.
Bruce Ray
bkr(a)WildHareComputers.com
11:41 a.m.
New subject: Data General MV/8000 emulator announcement
On Oct 5, 2024, at 11:35 AM, Bruce Ray via cctalk
<cctalk(a)classiccmp.org> wrote:
On 10/4/2024 2:04 PM, Paul Koning via cctalk wrote:
I don't know DG computers at all, but I see a Nova emulator in Open SIMH so I was
thinking of your work as an extension of that. This is why I asked about updating.
Your answer suggests that you intend to deliver this as an Open SIMH contribution at some
point. That's great news. Not soon because of the complexity of the job, ok,
that's perfectly fine. My question was more about the overall intent rather than
specifics of the timeline.
paul
Nice!
So is this the current open-simh simulator, or a newer version? Will you update the one
in open-simh?
paul
None of the SimH versions currently has an MV emulator, so there is
technically nothing to "update".
This is a new emulator that uses parts of our commercial product stuffed
into the SimH structure. It is a challenge to adapt sections of our
commercial software into the SimH framework due to their significant
differences in design, implementation and certification. Accordingly,
it will take time before source code will be part of a SimH release.
Bruce Ray
bkr(a)WildHareComputers.com 
4 Oct
4 Oct
7:53 p.m.
New subject: Data General MV/8000 emulator announcement
A Data General MV/8000 emulator beta release is now
available from my DG
legacy preservation web site:
www.NovasAreForever.org
Very good. Will there be source code, for those of us not on x86 or ARM?
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- There is no rest for the wicked, yet the virtuous have no pillows. ---------
5 Oct
5 Oct
8:37 a.m.
New subject: Data General MV/8000 emulator announcement
On 10/4/2024 8:53 PM, Cameron Kaiser via cctalk wrote:
This is a new emulator that uses parts of our commercial product stuffed
into the SimH structure. It is a challenge to adapt sections of our
commercial software into the SimH framework due to their significant
differences in design, implementation and certification. Accordingly,
it will take time before source code will be part of a SimH release.
What platform(s) were you targeting...?
Bruce Ray
bkr(a)WildHareComputers.com
A Data General MV/8000 emulator beta release is
now available from my DG
legacy preservation web site:
www.NovasAreForever.org
Very good. Will there be source code, for those of us not on x86 or ARM?
10:28 a.m.
New subject: Data General MV/8000 emulator announcement
A Data General MV/8000 emulator beta release is now
available from my DG
legacy preservation web site:
www.NovasAreForever.org
Very good. Will there be source code, for those of us not on x86 or ARM?
5 Oct
5 Oct
7:11 a.m.
New subject: Data General MV/8000 emulator announcement
not really, just run the emulator in a VM or even an x86 emulator with the old
winblows/linux.
<pre>--Carey</pre>
On 10/04/2024 11:42 PM CDT Tom Hunter via cctalk
<cctalk(a)classiccmp.org> wrote:
...
Now "MVs Are Forever..."
...
As the software is binary only it won't be "Forever", but only until the
next major change in Windows or Linux APIs which breaks binary
compatibility. 
7:51 a.m.
New subject: Data General MV/8000 emulator announcement
On Sat, 5 Oct 2024, Tom Hunter via cctalk wrote:
As the software is binary only it won't be
"Forever", but only until the
next major change in Windows or Linux APIs which breaks binary
compatibility.
Linux maintains backwards ABI compatibility as far as both the OS kernel
and the C library is concerned. If something breaks with an upgrade then
please report a bug rather than complaining on a random mailing list (not
that I endorse proprietary or any kind of closed-source software).
Maciej
9:29 a.m.
New subject: Data General MV/8000 emulator announcement
Maciej W. Rozycki via cctalk [2024-10-05 16:51:13]:
On Sat, 5 Oct 2024, Tom Hunter via cctalk wrote:
Have you tried to run any libc5-program lately? Or a.out binaries?
--
Hilsen Harald
As the software is binary only it won't be
"Forever", but only until the
next major change in Windows or Linux APIs which breaks binary
compatibility.
Linux maintains backwards ABI compatibility as far as both the OS kernel
and the C library is concerned. If something breaks with an upgrade then
please report a bug rather than complaining on a random mailing list (not
that I endorse proprietary or any kind of closed-source software).
9:51 a.m.
New subject: Data General MV/8000 emulator announcement
On Sat, 5 Oct 2024, Harald Arnesen via cctalk wrote:
If there's an issue with libc5, then please report a bug; anything ELF is
supposed to continue running.
Support for a.out was removed indeed, I forgot about that. It boils down
to maintenance really: no one was interested in becoming a maintainer and
I reckon calls to fix bugs were unanswered for years. Someone *has* to do
the work, things do not happen automagically.
Maciej
Linux
maintains backwards ABI compatibility as far as both the OS kernel
and the C library is concerned. If something breaks with an upgrade then
please report a bug rather than complaining on a random mailing list (not
that I endorse proprietary or any kind of closed-source software).
Have you tried to run any libc5-program lately? Or a.out binaries? 
7 Oct
7 Oct
2:10 a.m.
New subject: Data General MV/8000 emulator announcement
On Sat, 5 Oct 2024 at 17:38, Harald Arnesen via cctalk
<cctalk(a)classiccmp.org> wrote:
Have you tried to run any libc5-program lately? Or
a.out binaries?
Does WordPerfect 8 (released in 1998) count?
If so, yes, I have:
https://www.theregister.com/2022/07/20/wordperfect_for_unix_for_linux/
Instructions to install it yourself:
https://www.xwp8users.com/wp81script.htm
--
Liam Proven ~ Profile: https://about.me/liamproven
Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
IoM: (+44) 7624 227612: UK: (+44) 7939-087884
Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
2:41 a.m.
New subject: Data General MV/8000 emulator announcement
Liam Proven via cctalk [2024-10-07 11:10:56]:
Sure, I have tested it myself. I can't see a regular user having a need
to run a random libc5-program will manage to do this (hunt down the
libraries needed and the like).
--
Hilsen Harald
Have you tried
to run any libc5-program lately? Or a.out binaries?
Does WordPerfect 8 (released in
1998) count?
If so, yes, I have:
https://www.theregister.com/2022/07/20/wordperfect_for_unix_for_linux/
Instructions to install it yourself:
https://www.xwp8users.com/wp81script.htm
3:04 a.m.
New subject: Data General MV/8000 emulator announcement
On Mon, 7 Oct 2024, Harald Arnesen via cctalk wrote:
Sure, I have tested it myself. I can't see a regular user having a need to run
a random libc5-program will manage to do this (hunt down the libraries needed
and the like).
Running 25 years old a piece of software in a new deployment has never
been a regular use case. Support is there in the OS, but I agree that
making the individual thing run can be a challenge, and if one feels
incapable of taking it, they can always ask/hire someone to do it for
them. Software freedom does not imply freedom from challenges or free
support.
FWIW compiling 25 years old a piece of software is even tougher, unless
you use contemporary tools in a contemporary environment, so while the
availability of the source code is surely always worth appreciating, the
challenge to make them run is not any smaller.
NB if you clean up old a.out support and submit it for re-inclusion in
Linux along with a serious offer to maintain it long-term, then it may
well end up being accepted. You have the option to maintain it off-tree
too.
Maciej
Have you tried to run any libc5-program lately? Or
a.out binaries?
Does WordPerfect 8 (released in 1998) count?
If so, yes, I have:
https://www.theregister.com/2022/07/20/wordperfect_for_unix_for_linux/
Instructions to install it yourself:
https://www.xwp8users.com/wp81script.htm 
3:22 a.m.
New subject: Data General MV/8000 emulator announcement
On Mon, 7 Oct 2024 at 06:10, Maciej W. Rozycki via cctalk <
cctalk(a)classiccmp.org> wrote:
FWIW compiling 25 years old a piece of software is even tougher, unless
you use contemporary tools in a contemporary environment, so while the
availability of the source code is surely always worth appreciating, the
challenge to make them run is not any smaller.
That's sort of an odd claim. I bet that you could download an arbitrary
piece of software from 25 years ago, run the configure script, and have
something working with very few tweaks. The biggest hurdle is probably
just going to be disabling all of the guardrails that modern clang/GCC give
you (implicit function declarations, implicit int, etc.). The only real
hurdle would come when trying to either compile something written for
varargs.h or something written in true K&R. At that point we're talking
about software written more like 35-40+ years ago.
-Henry
4:05 a.m.
New subject: Data General MV/8000 emulator announcement
On Mon, 7 Oct 2024, Henry Bent via cctalk wrote:
You bet and I have proofs otherwise, as it's the kind of stuff I've been
doing all the time, both professionally and with personal projects.
First of all don't expect there'll be a configure script (end even if
there is, chances are it'll break with a modern compiler). Then expect
all the assumptions the authors made that no longer stand. Even missing
#include directives, which used to work owing to indirect inclusions,
which have since been cleaned up, and that's just the tip of the iceberg.
For example I was recently faced with building SPEC CPU 2006 for POWER9
and RISC-V platforms. No it wasn't trivial, it didn't amount to running
configure and making a couple of tweaks at all, and the software was like
only 15 years old rather than 25 when I got at it.
Likewise try building an old version of GCC, say 4.1 (let's not even
mention 2.7, etc.), for whatever platform nowadays.
I'm not talking trivial software, I could build a small demonstration
shell I wrote back in 1990s with no issue recently when I needed it to
debug a serious OS issue and a standard shell just crashed or hung.
Maciej
FWIW
compiling 25 years old a piece of software is even tougher, unless
you use contemporary tools in a contemporary environment, so while the
availability of the source code is surely always worth appreciating, the
challenge to make them run is not any smaller.
That's sort of an odd claim. I bet that you could download an arbitrary
piece of software from 25 years ago, run the configure script, and have
something working with very few tweaks. The biggest hurdle is probably
just going to be disabling all of the guardrails that modern clang/GCC give
you (implicit function declarations, implicit int, etc.). The only real
hurdle would come when trying to either compile something written for
varargs.h or something written in true K&R. At that point we're talking
about software written more like 35-40+ years ago. 
1:37 p.m.
New subject: Data General MV/8000 emulator announcement
It was thus said that the Great Henry Bent via cctalk once stated:
On Mon, 7 Oct 2024 at 06:10, Maciej W. Rozycki via
cctalk <
cctalk(a)classiccmp.org> wrote:
Maybe. I downloaded Viola, an early-90s graphical web browser (around 30
years old), and while it did compile on two different Linux systems (My God!
It's full of warnings!), it ran (for various values of "run") on the 32-bit
system, and immediately crashed on the 64-bit system (because sizeof(int) ==
sizeof(long) == sizeof(char *)).
It was written just *after* C89 came out, and it shows.
-spc
FWIW compiling 25 years old a piece of software is even tougher, unless
you use contemporary tools in a contemporary environment, so while the
availability of the source code is surely always worth appreciating, the
challenge to make them run is not any smaller.
That's sort of an odd claim. I bet that you could download an arbitrary
piece of software from 25 years ago, run the configure script, and have
something working with very few tweaks. The biggest hurdle is probably
just going to be disabling all of the guardrails that modern clang/GCC
give you (implicit function declarations, implicit int, etc.). The only
real hurdle would come when trying to either compile something written for
varargs.h or something written in true K&R. At that point we're talking
about software written more like 35-40+ years ago.
3:47 a.m.
New subject: Data General MV/8000 emulator announcement
Maciej W. Rozycki [2024-10-07 12:04:29]:
FWIW compiling 25 years old a piece of software is
even tougher, unless
you use contemporary tools in a contemporary environment, so while the
availability of the source code is surely always worth appreciating, the
challenge to make them run is not any smaller.
That depends. I have compiled several SysV- and BSD4.3-utilities for
FreeDOS, using gcc or openwatcom. Most compiled straight away.
Most of the C programs I made for my Amiga compiles fine today
(obviously not Intuition-based graphics programs).
I like to collect old text adventure games, most of what I find are easy
to compile on Linux.
NB if you clean up old a.out support and submit it
for re-inclusion in
Linux along with a serious offer to maintain it long-term, then it may
well end up being accepted. You have the option to maintain it off-tree
too.
Not me. I have really no need to run a.out binaries, nor am i qualified
to do such a thing.
--
Hilsen Harald
30 Sep
30 Sep
4:39 p.m.
Tektronix used this type of tube in some of their later vacuum tube
scopes. Some audio amplifiers also used them. Can help improve tube life
by keeping the plate supply off until the tubes warm up.
Bob
On 9/30/2024 2:21 PM, Van Snyder via cctalk wrote:
I have two SPST time delay 12-volt relays packaged
like vacuum tubes
with octal bases, Amperite models 12N010 (ten seconds) and 12C5 (five
seconds).
They're in their original boxes.
I have no idea what devices used them.
It seems a shame to throw them in a recycle bin.
Does anybody want them?
Van Snyder
--
Vintage computers and electronics
www.dvq.com
www.tekmuseum.com
www.decmuseum.org
4:51 p.m.
Another way to use them is to switch a series resistor out of the power supply input after
a few seconds; that is good for capacitor-input filters where the inrush current is
otherwise very high. The 5 second delay may be just that; it seems a bit short for the
pre-heat delay.
paul
On Sep 30, 2024, at 7:39 PM, Bob Rosenbloom via cctalk
<cctalk(a)classiccmp.org> wrote:
Tektronix used this type of tube in some of their later vacuum tube scopes. Some audio
amplifiers also used them. Can help improve tube life by keeping the plate supply off
until the tubes warm up.
Bob
On 9/30/2024 2:21 PM, Van Snyder via cctalk wrote:
I have two SPST time delay 12-volt relays
packaged like vacuum tubes
with octal bases, Amperite models 12N010 (ten seconds) and 12C5 (five
seconds).
They're in their original boxes.
I have no idea what devices used them.
It seems a shame to throw them in a recycle bin.
Does anybody want them?
Van Snyder
--
Vintage computers and electronics
www.dvq.com
www.tekmuseum.com
www.decmuseum.org
7:11 p.m.
On 2024-09-30 5:51 p.m., Paul Koning via cctalk wrote:
Another way to use them is to switch a series resistor
out of the power supply input after a few seconds; that is good for capacitor-input
filters where the inrush current is otherwise very high. The 5 second delay may be just
that; it seems a bit short for the pre-heat delay.
paul
That works nice for both audio and digital power supplies.
One can add a relay to latch the output after the time delay, as well as
turn off the power to the time delay.
5 seconds sounds good for a core memory power supply.
Ben.
76
days inactive
83
days old
51 comments
24 participants
participants (24)
-
ben -
bluewater emailtoilet.com -
Bob Rosenbloom -
Bruce Ray -
Cameron Kaiser -
CAREY SCHUG -
Christian Corti -
Chuck Guzis -
Daniel Williams -
David Wise -
Harald Arnesen -
Henry Bent -
Johan Helsingius -
Jon Elson -
Liam Proven -
Maciej W. Rozycki -
Norman Jaffe -
Paul Koning -
Rich Alderson -
Sean Conner -
Tom Gardner -
Tom Hunter -
Van Snyder -
Wayne S