29 Mar
2018
29 Mar
'18
9:20 a.m.
I?m not trying to date myself but have things truly sped up? In 1970?s
Toronto I had a classic computer, sorry can?t recall what it was, connected
to a 300 baud modem; by early 80?s had ?zoomed? to 9600 baud. Oh, my! [ A
typical file size to download was probably 1 MB. ] Speed indeed! Yet now,
here in rural Ontario, Canada, I?m at 5MB/s. Yikes! (Friends in Toronto are
at 50MB/s.) We can do the math but content, particularly multimedia, has
swollen in size.[ 1 GB is not unheard of. ] Were classic computing days
that much slower? Happy computing. Murray -:)
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
29 Mar
29 Mar
10:53 a.m.
On Mar 29, 2018, at 12:20 PM, Murray McCullough via
cctalk <cctalk at classiccmp.org> wrote:
I?m not trying to date myself but have things truly sped up? In 1970?s
Toronto I had a classic computer, sorry can?t recall what it was, connected
to a 300 baud modem; by early 80?s had ?zoomed? to 9600 baud. Oh, my! [ A
typical file size to download was probably 1 MB. ] Speed indeed! Yet now,
here in rural Ontario, Canada, I?m at 5MB/s. Yikes! (Friends in Toronto are
at 50MB/s.) We can do the math but content, particularly multimedia, has
swollen in size.[ 1 GB is not unheard of. ] Were classic computing days
that much slower? Happy computing. Murray -:)
I remember downloading the GCC release kit over a 56k dialup line, in 2000. Took a
while.
The ARPAnet in its early days had "high speed backbone" links which were 56k
bps. Terminal links presumably 110 bps, that being the speed of ASCII teletypes. And
back in the late 1970s you could still find even slower links in some places, such as 6
bit links connecting teletype machines for newspaper "wire service" feeds.
It would be fun to do a "generalized Moore's Law" chart, showing not just
transistor count growth (Moore's subject) but also the many other scaling changes of
computing: disk capacity, recording density, disk IOPS, disk bandwidth, ditto those for
tape, CPU MIPS, memory size, memory bandwidth, network bandwidth...
All these have grown dramatically, but very clearly not in the same proportion, for some
of these the changes are smooth while others are jumps, and the rate of change sometimes
varies dramatically over the decades.
paul
11 Apr
11 Apr
8:05 a.m.
On 29 March 2018 at 19:53, Paul Koning via cctalk <cctalk at classiccmp.org> wrote:
It would be fun to do a "generalized Moore's Law" chart, showing not just
transistor count growth (Moore's subject) but also the many other scaling changes of
computing: disk capacity, recording density, disk IOPS, disk bandwidth, ditto those for
tape, CPU MIPS, memory size, memory bandwidth, network bandwidth...
This is the most telling I've seen in a long time...
https://danluu.com/input-lag/
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? Google Mail/Hangouts/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven ? Skype/LinkedIn: liamproven
UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
12 Apr
12 Apr
4:08 a.m.
On 11 April 2018 at 17:18, Jay West <jwest at classiccmp.org> wrote:
Liam wrote...
https://danluu.com/input-lag/
Hey thanks for that link... fun read!
High praise indeed! :-) You're very welcome.
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? Google Mail/Hangouts/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven ? Skype/LinkedIn: liamproven
UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
2:56 p.m.
On 4/12/2018 5:08 AM, Liam Proven via cctalk wrote:
On 11 April 2018 at 17:18, Jay West <jwest at
classiccmp.org> wrote:
But that assumes local character echoing,
I am sure the google "search" box must echo to server for every key press.
Ben.
Liam wrote...
https://danluu.com/input-lag/
Hey thanks for that link... fun read!
High praise indeed! :-) You're very welcome.
11 Apr
11 Apr
9:43 a.m.
On Apr 11, 2018, at 11:05 AM, Liam Proven <lproven
at gmail.com> wrote:
On 29 March 2018 at 19:53, Paul Koning via cctalk <cctalk at classiccmp.org>
wrote:
Nice. It would be interesting to throw in some even older systems. One that comes to
mind is PLATO. I don't remember exactly what it delivered for response time, there
were good test results on it. Somewhere in the 100 ms range, I believe, much of which was
transmission delays due to low baud rates. And that was with 600 users, sharing a quad
processor 4 x 10 MHz machine, in 1976.
paul
It would be fun to do a "generalized Moore's Law" chart, showing not just
transistor count growth (Moore's subject) but also the many other scaling changes of
computing: disk capacity, recording density, disk IOPS, disk bandwidth, ditto those for
tape, CPU MIPS, memory size, memory bandwidth, network bandwidth...
This is the most telling I've seen in a long time...
https://danluu.com/input-lag/ 
9:31 a.m.
It might break the rules since it only goes back to 1999, but here's
Moore's law for integer speed, floating point speed, number of processors,
memory sizes and disk sizes for the machines connected to SETI at home. Plots
are averages and medians, unfiltered for errors. At least one of the
parameters (total credited ops) is no longer used. expavg credit
includes GPU work even though it's not included in the processor speed
numbers. If someone wants a distillation of the data for comparing to
earlier machines, let me know.
http://setiathome.berkeley.edu/host_stats/index.html
On Thu, Mar 29, 2018 at 10:53 AM, Paul Koning via cctalk <
cctalk at classiccmp.org> wrote:
--
Eric Korpela
korpela at ssl.berkeley.edu
AST:7731^29u18e3
On Mar 29, 2018, at 12:20 PM, Murray McCullough
via cctalk <
cctalk at classiccmp.org> wrote:
I?m not trying to date myself but have things truly sped up? In 1970?s
Toronto I had a classic computer, sorry can?t recall what it was,
connected
to a 300 baud modem; by early 80?s had ?zoomed?
to 9600 baud. Oh, my! [ A
typical file size to download was probably 1 MB. ] Speed indeed! Yet now,
here in rural Ontario, Canada, I?m at 5MB/s. Yikes! (Friends in Toronto
are
at 50MB/s.) We can do the math but content,
particularly multimedia, has
swollen in size.[ 1 GB is not unheard of. ] Were classic computing days
that much slower? Happy computing. Murray -:)
I remember downloading the GCC release kit over a 56k dialup line, in
2000. Took a while.
The ARPAnet in its early days had "high speed backbone" links which were
56k bps. Terminal links presumably 110 bps, that being the speed of ASCII
teletypes. And back in the late 1970s you could still find even slower
links in some places, such as 6 bit links connecting teletype machines for
newspaper "wire service" feeds.
It would be fun to do a "generalized Moore's Law" chart, showing not just
transistor count growth (Moore's subject) but also the many other scaling
changes of computing: disk capacity, recording density, disk IOPS, disk
bandwidth, ditto those for tape, CPU MIPS, memory size, memory bandwidth,
network bandwidth...
All these have grown dramatically, but very clearly not in the same
proportion, for some of these the changes are smooth while others are
jumps, and the rate of change sometimes varies dramatically over the
decades.
paul
11:09 a.m.
On 04/11/2018 09:31 AM, Eric Korpela via cctalk wrote:
It might break the rules since it only goes back to
1999, but here's
Moore's law for integer speed, floating point speed, number of processors,
memory sizes and disk sizes for the machines connected to SETI at home. Plots
are averages and medians, unfiltered for errors. At least one of the
parameters (total credited ops) is no longer used. expavg credit
includes GPU work even though it's not included in the processor speed
numbers. If someone wants a distillation of the data for comparing to
earlier machines, let me know.
I thought that Moore's "law" dealt only with the number of transistors
on a die. Did Gordon also say something about performance?
--Chuck
11:31 a.m.
Chuck Guzis wrote on Wed, 11 Apr 2018 11:09:23 -0700
I thought that Moore's "law" dealt only
with the number of transistors
on a die. Did Gordon also say something about performance?
That is correct. The observation that transistors would be faster and
use less power as they became smaller is called "Dennard scaling" from
1974:
https://en.wikipedia.org/wiki/Dennard_scaling
This led to the MHz wars of the 1990s. Sadly, as the isolation barriers
(the "O" in "MOS") became thinner and thinner we could no longer
ignore
leakage currents. In addition, going with lower voltages no longer was
possible as we got closer and closer to the transistor threashold
voltages. So we got stuck at 3 GHz or less.
Besides getting more performance with smaller transistors, we have also
been increasing performance by taking advantage of more transistors by
doing more stuff in parallel. So we went from up to dozens of clock
cycles per instructions to three or four instructions per clock cycle.
Quite a few of the additional transistors have been use for more and
more layers of caches.
-- Jecel
11:40 a.m.
On Apr 11, 2018, at 2:31 PM, Jecel Assumpcao Jr. via
cctalk <cctalk at classiccmp.org> wrote:
Chuck Guzis wrote on Wed, 11 Apr 2018 11:09:23 -0700
For silicon VLSI logic circuits, yes, give or take a GHz or so. CMOS can go very much
higher in RF circuits. And if you switch to different semiconductors, you can go higher
still. People have built oscillators that get close to a THz, but those are not logic
circuits, let alone computers.
Propagation latencies also become an issue, though you can design fast computers with
substantial propagation delays if you have to. Cray did this decades ago; the basic stage
delay in the CDC 6600 is 1/20th of the clock period, and the delay on chassis
interconnects is 1/4 of the clock period. In that design, all sorts of things are
carefully paced to match the known propagation delays. But most other computers were not
designed with such complex techniques.
paul
I thought that Moore's "law" dealt
only with the number of transistors
on a die. Did Gordon also say something about performance?
That is correct. The observation that transistors would be faster and
use less power as they became smaller is called "Dennard scaling" from
1974:
https://en.wikipedia.org/wiki/Dennard_scaling
This led to the MHz wars of the 1990s. Sadly, as the isolation barriers
(the "O" in "MOS") became thinner and thinner we could no longer
ignore
leakage currents. In addition, going with lower voltages no longer was
possible as we got closer and closer to the transistor threashold
voltages. So we got stuck at 3 GHz or less.
12:49 p.m.
On 04/11/2018 11:31 AM, Jecel Assumpcao Jr. via cctalk wrote:
Besides getting more performance with smaller
transistors, we have also
been increasing performance by taking advantage of more transistors by
doing more stuff in parallel. So we went from up to dozens of clock
cycles per instructions to three or four instructions per clock cycle.
Quite a few of the additional transistors have been use for more and
more layers of caches.
As one old acquaintance said "We've given up on reducing the time it
takes one woman to produce a baby. Our new approach is to use nine
women to get a baby in one month"
...or something to that effect.
--Chuck
12:16 p.m.
On Wed, Apr 11, 2018 at 11:09 AM, Chuck Guzis via cctalk <
cctalk at classiccmp.org> wrote:
I thought that Moore's "law" dealt only with the number of transistors
on a die. Did Gordon also say something about performance?
You are correct that he only applied it to transistor count. The extension
to everything else under the sun was made by others.
--Chuck
--
Eric Korpela
korpela at ssl.berkeley.edu
AST:7731^29u18e3
12:28 p.m.
On Wed, Apr 11, 2018 at 11:09 AM, Chuck Guzis via
cctalk <
cctalk at classiccmp.org> wrote:
> I thought that Moore's "law" dealt only with the number of transistors
> on a die. Did Gordon also say something about performance?
On Wed, 11 Apr
2018, Eric Korpela via cctalk wrote:
You are correct that he only applied it to transistor
count. The extension
to everything else under the sun was made by others.
The number of things under the sun that Moore's "law" gets applied to
doubles every 18 months.
12:39 p.m.
On 04/11/2018 03:28 PM, Fred Cisin via cctalk wrote:
Isn't that one of the corollaries of Moore's Law?
bill
On Wed, Apr
11, 2018 at 11:09 AM, Chuck Guzis via cctalk <
cctalk at classiccmp.org> wrote:
> I thought that Moore's "law" dealt only with the number of transistors
> on a die.?? Did Gordon also say something about performance?
On Wed, 11 Apr
2018, Eric Korpela via cctalk wrote:
You are correct that he only applied it to
transistor count.? The
extension
to everything else under the sun was made by others.
The number of things under the sun that Moore's "law" gets applied to
doubles every 18 months.
29 Mar
29 Mar
12:12 p.m.
On Thu, Mar 29, 2018 at 12:20 PM, Murray McCullough via cctalk
<cctalk at classiccmp.org> wrote:
I?m not trying to date myself but have things truly
sped up? In 1970?s
... 300 baud modem; by early 80?s had ?zoomed? to 9600 baud.
What hasn't changed is people. Back when we had 300 baud, we only had
so many hours a night for eyeballs-on-slow text, so one could only
expect so much content to be transmitted. File transfers were
hands-off, but even the graphic machines of the time had low-res
screens so a mono-graphic didn't take so long to pull down, unlike
640x480x8bit stuff that was common by the mid-90s.
As telecom speeds (modem then ISDN then DSL, etc, etc) ramped up, what
one could do in 60 seconds or even a 3-second attention span grew.
It's true that webpages have gotten really fat and the amount of media
one pulls down from a single click is staggering, but nobody would
have sat and waited that long for pages to load at dial-up speeds.
More bandwidth enables more to get pulled in the same amount of time,
it doesn't mean that anyone will stand still and load the same
quantity as before but faster.
It's like fixed purchase points for PCs or digital cameras or
whatever. Each year, the new models cost about the same as the old
models but with more features. The price points are set and as
technology gets cheaper, they just pack more in the box and leave the
price alone. Same with telecom - more content, faster lines, same
time in chair.
-ethan
12:35 p.m.
New subject: Speed now & then (Space and time?)
On Thu, 29 Mar 2018, Murray McCullough via cctalk wrote:
I?m not trying to date myself but have things truly
sped up? In 1970?s
Toronto I had a classic computer, sorry can?t recall what it was, connected
to a 300 baud modem; by early 80?s had ?zoomed? to 9600 baud. Oh, my! [ A
typical file size to download was probably 1 MB. ] Speed indeed! Yet now,
here in rural Ontario, Canada, I?m at 5MB/s. Yikes! (Friends in Toronto are
at 50MB/s.) We can do the math but content, particularly multimedia, has
swollen in size.[ 1 GB is not unheard of. ] Were classic computing days
that much slower? Happy computing. Murray -:)
Application of "Moore's Law" calls for a logarithmic increase in speed,
such as doubling every 18 months. Yes, the rate, in terms of bits per
second has grown a lot.
Similarly storage capacity has grown.
HOWEVER, a variant of "Boyle's Law" warns that software and content will
expand to fit all available space and speed.
Once, if your handwriting is bad enough, you could type your grocery
shopping list into Electric Pencil. Took a few seconds. later WordStar.
Scripsit. WordPervert. Microsoft Weird.
Does Clippy have a template for it?
(PC-Write was a welcome respite in that growing bloat!)
It's kinda like: the plane flight is half an hour shorter, but the airport
pre-processing in an hour longer.
Once, the operating system, such as PC-DOS 1.00, fit on a single sided MFM
160K floppy disk. Now, much software comes on DVD, because CD-ROM (2/3
GB) isn't large enough!
A memo announcing change of room and time for a meeting is a very short
paragraph. That used to be about half a kilobyte.
Now, it tends to be a few MB.
It seems that some serious effort has to go into wasting so much capacity!
HTML has helped that along.
One college administrator managed that with ease. He created the memo in
his word processor, printed it on his color printer, signed it, SCANNED
it, and attached the 24bit-color picture as an attachment to an email.
The subject line of the email was: "FYI". The text, other than the
attachment was: "See attachment". The attachment was an uncompressed
picture of a line of text in the middle of a full sheet of paper:
"The curriculum committee has been moved to room D-233 at 2:oo"
But, in the memo, there was a horizontal rule that was not quite
horizontal; one end was a few pixels higher than the other! - scanning
with the paper not quite aligned may well be the easiest way to accomplish
THAT!
But, that was almost a decade ago. I wonder whether he is now attaching
MP4s?
MP4s mean that now, not only does it take MUCH longer to create the
document, we can now waste MUCH more of the reader's time!
I find it very annoying that when GOOGLE'ing to find a simple answer, many
of the first hits are YouTube.
A few seconds glance at a text document will likely tell me whether the
answer to my question is there. Or a sketch and maybe a photograph of
somebody's hardware setup. Instead, sit through minutes of talking heads.
With background music to make it hard to make out what is being said!
Youtube's "auto-generated CC" is a poor substitute for text.
Dancing kangaroos and yodelling jellyfish has let form triumph over
content! When will we finally have smell-o-vision?
Yes, certainly, the hardware is much faster, and has more storage space.
Yet, the task takes longer, and storage space runs out just as quickly.
--
Grumpy Ol' Fred cisin at xenosoft.com
12:58 p.m.
New subject: Speed now & then (Space and time?)
On 03/29/2018 03:35 PM, Fred Cisin via cctalk wrote:
On Thu, 29 Mar 2018, Murray McCullough via cctalk
wrote:
We have proof and it is us.
I?m not trying to date myself but have things
truly sped up? In 1970?s
Toronto I had a classic computer, sorry can?t recall what it was,
connected
to a 300 baud modem; by early 80?s had ?zoomed? to 9600 baud. Oh, my!
[ A
typical file size to download was probably 1 MB. ] Speed indeed! Yet
now,
here in rural Ontario, Canada, I?m at 5MB/s. Yikes! (Friends in
Toronto are
at 50MB/s.) We can do the math but content, particularly multimedia, has
swollen in size.[ 1 GB is not unheard of. ] Were classic computing days
that much slower? Happy computing. Murray? -:)
Application of "Moore's Law" calls for a logarithmic increase in
speed, such as doubling every 18 months.? Yes, the rate, in terms of
bits per second has grown a lot.
Similarly storage capacity has grown.
HOWEVER, a variant of "Boyle's Law" warns that software and content
will expand to fit all available space and speed.
Once, if your handwriting is bad enough, you could type your grocery
shopping list into Electric Pencil.? Took a few seconds.?? later
WordStar. Scripsit.? WordPervert.? Microsoft Weird. Does Clippy have a
template for it?
(PC-Write was a welcome respite in that growing bloat!)
I posited that 2 decades ago in a wired article.? My CP/M machine booted
in seconds while waiting for
the winders box to decide if it would/could.
It's kinda like: the plane flight is half an hour
shorter, but the
airport pre-processing in an hour longer.
I fly a Cessna150, cruse speed of 110mph, I could fly to Ohio in six
hours with one fuel stop.
Commercial flight is easily 4x faster and it still takes 6 hours door to
door.?
Once, the operating system, such as PC-DOS 1.00, fit
on a single sided
MFM 160K floppy disk.? Now, much software comes on DVD, because CD-ROM
(2/3 GB) isn't large enough!
Back when 160k was space, now it's a small entry in a table.
A memo announcing change of room and time for a
meeting is a very
short paragraph.? That used to be about half a kilobyte.
Now, it tends to be a few MB.
It seems that some serious effort has to go into wasting so much
capacity!
It is hideous.?? But you need the picture. <insert snark>
HTML has helped that along.
HTML is not nearly so bad its slightly bigger than runoff only wordier.
However that we need HTML for a screen of text is, yes, bad!
I blame WYSISWYG, and Postscript!? WYGINS? (for those that forgot, What
You Get Is No Surprise)
from the days before high resolution printers.
One college administrator managed that with ease.? He
created the memo
in his word processor, printed it on his color printer, signed it,
SCANNED it, and attached the 24bit-color picture as an attachment to
an email. The subject line of the email was: "FYI".? The text, other
than the attachment was: "See attachment".? The attachment was an
uncompressed picture of a line of text in the middle of a full sheet
of paper:
"The curriculum committee has been moved to room D-233 at 2:oo"
But, in the memo, there was a horizontal rule that was not quite
horizontal; one end was a few pixels higher than the other! - scanning
with the paper not quite aligned may well be the easiest way to
accomplish THAT!
But, that was almost a decade ago.? I wonder whether he is now
attaching MP4s?
Eep, the man is batty.
MP4s mean that now, not only does it take MUCH longer
to create the
document, we can now waste MUCH more of the reader's time!
I find it very annoying that when GOOGLE'ing to find a simple answer,
many of the first hits are YouTube.
A few seconds glance at a text document will likely tell me whether
the answer to my question is there.? Or a sketch and maybe a
photograph of somebody's hardware setup.? Instead, sit through minutes
of talking heads.
With background music to make it hard to make out what is being said!
Youtube's "auto-generated CC" is a poor substitute for text.
Dancing kangaroos and yodelling jellyfish has let form triumph over
content!?? When will we finally have smell-o-vision?
Please no, smell-o-vision.? I can see the hackers going for the cross
between skunk, pepperspray,
and some toxic chemical mess. ? Obviously a Blacktooth perpiheral.
?I will nominally run without that peripheral.? Come to think of it I
did that for a decades regarding
sound.??? Most of my favorite modern Linux machines can't squawk, peep,
hear, or see me.
Yes, certainly, the hardware is much faster, and has
more storage space.
Yet, the task takes longer, and storage space runs out just as quickly.
Thats the whole sad story.?? It is why I still run CP/M, RT-11 and even
a DECMate!? All hail fanfold!
Allison
2:24 p.m.
New subject: Speed now & then (Space and time?)
> HOWEVER, a variant of "Boyle's Law"
warns that software and content
> will expand to fit all available space and speed.
On Thu, 29 Mar 2018, allison via cctalk wrote:
We have proof and it is us.
Or, as Walt Kelly ("Pogo") said, "We have met the enemy, and he is
us."
I posited that 2 decades ago in a wired article.? My
CP/M machine booted
in seconds while waiting for
the winders box to decide if it would/could.
"The new machine is so much faster, that it can almost get out of its own
way!"
It is hideous.?? But you need the picture. <insert
snark>
How should I react to the college administator who told me, "You're not
seeing the big picture"? :-) I was considering defenestration.
HTML has
helped that along.
HTML is not nearly so bad its slightly bigger than runoff only
wordier.
However that we need HTML for a screen of text is, yes, bad!
I blame WYSISWYG, and Postscript!? WYGINS? (for those that forgot, What
You Get Is No Surprise)
from the days before high resolution printers. > One college administrator managed that with ease.?
He created the memo
> . . .
> But, that was almost a decade ago.? I wonder whether he is now
> attaching MP4s?
Eep, the man is batty.
I feel guilty about not having defenestrated the college administration.
Dancing
kangaroos and yodelling jellyfish has let form triumph over
content!?? When will we finally have smell-o-vision?
Please no, smell-o-vision.? I
can see the hackers going for the cross
between skunk, pepperspray,
and some toxic chemical mess. ? Obviously a Blacktooth perpiheral. Yes,
certainly, the hardware is much faster, and has more storage space.
Yet, the task takes longer, and storage space runs out just as quickly.
Thats the
whole sad story.?? It is why I still run CP/M, RT-11 and even
a DECMate!? All hail fanfold!
Allison
4:05 p.m.
New subject: Speed now & then (Space and time?)
On 03/29/2018 02:24 PM, Fred Cisin via cctalk wrote:
As a real contrast, consider, say, the IBM 1620. Go look up the cycle
times on that beast.
And yet, productive work was performed on it. Indeed the industrial
variant, the 1710 was used for early process control.
Now that I don't need to work on the bleeding edge, I prefer to see how
much can be done with the least.
It's fun.
--Chuck
> HOWEVER, a
variant of "Boyle's Law" warns that software and content
> will expand to fit all available space and speed.
On Thu, 29 Mar 2018, allison via cctalk wrote:
We have proof and it is us.
Or, as Walt Kelly ("Pogo") said, "We have met the enemy, and he is
us."
I posited that 2 decades ago in a wired article.?
My CP/M machine booted
in seconds while waiting for
the winders box to decide if it would/could.
"The new machine is so much faster, that it can almost get out of its
own way!"
4:50 p.m.
New subject: Speed now & then (Space and time?)
On Mar 29, 2018, at 7:05 PM, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
On 03/29/2018 02:24 PM, Fred Cisin via cctalk wrote:
As a real contrast, consider, say, the IBM 1620. Go look up the cycle
times on that beast.
And yet, productive work was performed on it. Indeed the industrial
variant, the 1710 was used for early process control.
Or drum machines. Dutch airplane maker Fokker used one (FERTA) for airplane design. And
its successor ARMAC was where the Internet routing algorithm (shortest path algorithm) was
first run.
paul
>
HOWEVER, a variant of "Boyle's Law" warns that software and content
> will expand to fit all available space and speed.
On Thu, 29 Mar 2018, allison via cctalk wrote:
We have proof and it is us.
Or, as Walt Kelly ("Pogo") said, "We have met the enemy, and he is
us."
I posited that 2 decades ago in a wired article.
My CP/M machine booted
in seconds while waiting for
the winders box to decide if it would/could.
"The new machine is so much faster, that it can almost get out of its
own way!" 
8:11 p.m.
New subject: Speed now & then (Space and time?)
On Thu, Mar 29, 2018 at 04:05:10PM -0700, Chuck Guzis via cctalk wrote:
And yet, productive work was performed on it. Indeed
the industrial
variant, the 1710 was used for early process control.
There were a lot of highway improvements made in the US in the 1950s/
1960s using Bendix G-15s. That particular branch of civil engineering
was probably that machine's biggest customer. (OTOH, disclaimer: the
one I used in high school had previously been owned by an oil company.)
mcl
7 p.m.
New subject: Speed now & then (Space and time?)
On 03/29/2018 04:24 PM, Fred Cisin via cctalk wrote:
From 1978 or so, I had a Z-80 CP/M system running on the
S-100 bus. In about 1980, I got a Memorex Winchester drive
on it. It really made CP/M fly.
In 1982-1984 or so, I was trying to build a 32-bit machine
very loosely patterned after an IBM 360, but would have used
a 360 user-level instruction set. It became obvious that it
would take years to have an OS, compilers, utilities, etc.
(I did not know about Unix 360, which I almost certainly
could have gotten a copy of, we had a PDP-11 Unix license at
the university.)
So, I cloned a Logical Microcomputer Co. Genix system with
the Nat. Semi 16032 chip. It was an absolute DOG! It took
several minutes for Emacs to load. Even vi (which I
detest!) was horribly slow, like 10X slower than the CP/M
editor.
Then, in 1986, I bought a MicroVAX-II CPU board from a
broker, and a bunch of 3rd party peripherals, and made a
copy of VMS 4.7 (Might have used something earlier for a time.)
I was in 7th heaven! A REAL computer at LAST!
Jon
I posited that 2 decades ago in a wired article.
My CP/M
machine booted
in seconds while waiting for
the winders box to decide if it would/could.
"The new machine is so much faster, that it can almost get
out of its own way!"
30 Mar
30 Mar
4:32 a.m.
New subject: Speed now & then (Space and time?)
On Thu, Mar 29, 2018 at 10:07:27PM -0500, Mark Linimon via cctalk wrote:
On Thu, Mar 29, 2018 at 09:00:35PM -0500, Jon Elson
via cctalk wrote:
It starts up within half a second or so on my development box, even though my
.emacs pulls in all sorts of weird and wonderful packages. On my remote
servers, it can take a few seconds if the box is overloaded, but is otherwise
instant.
A lot of traditional software has *not* encountered the kind of bloat needed to
counteract Moore's Law, and so performs beautifully. What *is* bloating is
Windows software -- mercifully I don't run Windows -- half-jobbed ports of said
Windows software to other platforms (Firefox, mainly), and web-based stuff. The
latter includes various phoned-it-in apps which are basically written in
Javascript and embed an invisible web browser, which includes Slack, Spotify,
and a few other bits and pieces.
The obvious answer is to not use that bloated crapware and find something else
that does the same job.
It was an absolute DOG! It took several minutes
for Emacs to load.
So, uh, I hate to tell you about the state of the art these days
...
31 Mar
31 Mar
3:26 p.m.
New subject: Speed now & then (Space and time?)
On 3/30/2018 5:32 AM, Peter Corlett via cctalk wrote:
On Thu, Mar 29, 2018 at 10:07:27PM -0500, Mark Linimon
via cctalk wrote:
But that is the old fly in the ointment, other software may not be
avilable. I do run windows and real text screen UNIX is not aviable
anymore. All I know it is same $$$ cycle as always, BUY the new machine
for faster software, but you need buy the software that has bug fixes
and patches for the new system and the software slows down again.
GUI's gave us 8x bloat and streaming media another 8x bloat.
It is about time NEW notebook computers to come out to let you use them
to take NOTEs rather than some ap for your phone for notes.
Ben.
PS: Do I need a VALVE computer for the best sounding digital music?
PPS: Notice how records are selling again.
On Thu, Mar 29, 2018 at 09:00:35PM -0500, Jon
Elson via cctalk wrote:
It starts up within half a second or so on my development box, even though my
.emacs pulls in all sorts of weird and wonderful packages. On my remote
servers, it can take a few seconds if the box is overloaded, but is otherwise
instant.
A lot of traditional software has *not* encountered the kind of bloat needed to
counteract Moore's Law, and so performs beautifully. What *is* bloating is
Windows software -- mercifully I don't run Windows -- half-jobbed ports of said
Windows software to other platforms (Firefox, mainly), and web-based stuff. The
latter includes various phoned-it-in apps which are basically written in
Javascript and embed an invisible web browser, which includes Slack, Spotify,
and a few other bits and pieces.
The obvious answer is to not use that bloated crapware and find something else
that does the same job. It was an absolute DOG! It took several minutes
for Emacs to load.
So, uh, I hate to tell you about the state of the art these days
...
1 Apr
1 Apr
3:43 a.m.
New subject: Speed now & then (Space and time?)
On Sat, Mar 31, 2018 at 04:26:44PM -0600, ben via cctalk wrote:
[...]
But that is the old fly in the ointment, other
software may not be avilable.
I do run windows and real text screen UNIX is not aviable anymore. All I
know it is same $$$ cycle as always, BUY the new machine
for faster software, but you need buy the software that has bug fixes and
patches for the new system and the software slows down again.
GUI's gave us 8x bloat and streaming media another 8x bloat.
Decades of being nickel-and-dimed by the Microsoft ecosystem has taught you
that you need to pay for a lot of software. This is far less common on other
platforms.
I'm watching the MNT Reform with some interest as they're much more
user-repairable and -upgradable than typical notebooks, but it's nowhere near
ready yet. The small-run prototype is also an eyewatering ?599, so I'll pass on
it for now.
It is about time NEW notebook computers to come out to
let you use them to
take NOTEs rather than some ap for your phone for notes.
I use a fountain pen and some old file cards for that :)
PS: Do I need a VALVE computer for the best sounding
digital music?
You *could* buy one of those ricer PCs which have a valve amplifier fitted
right there on the PCB, nice and close to all those sharp digital signals and
noisy ground plane. The target market is hipsters who don't understand
electronics.
PPS: Notice how records are selling again.
There's a lot of talk from the same hipsters about a vinyl resurgence, but the
impressive-sounding percentge issues are against a tiny baselines that's pretty
much an accounting error.
In absolute rather than relative terms, the only growing market for music is
streaming. Spotify is one of those appalling bloated web-wrapper apps I was
railing against. I'm sticking with CDs; they'll even play on my old Amiga.
2 Apr
2 Apr
10:28 a.m.
New subject: Speed now & then (Space and time?)
On Mar 31, 2018, at 6:26 PM, ben via cctalk <cctalk
at classiccmp.org> wrote:
Sure it is. You can perfectly well install Linux without the GUI components, never mind
other Unix operating systems like NetBSD which are more oriented towards simple
low-overhead deployments. And my workstations, while they are GUI based, really only
serve as text type Unixes with large scroll buffers.
paul
...
But that is the old fly in the ointment, other software may not be avilable. I do run
windows and real text screen UNIX is not aviable anymore.
10:34 a.m.
New subject: Speed now & then (Space and time?)
On 04/02/2018 01:28 PM, Paul Koning via cctalk wrote:
That and even the Macbook OS-X will take you to a unix terminal.? IT
runs all the same commands as my Unix-V6 on pdp11.
I'd add the win10/pro has a interface screen that allows a linux/unix
terminal interface.? That made the thing usable!
Allison
On Mar 31, 2018, at 6:26 PM, ben via cctalk
<cctalk at classiccmp.org> wrote:
Sure it is. You can perfectly well install Linux without
the GUI components, never mind other Unix operating systems like NetBSD which are more
oriented towards simple low-overhead deployments. And my workstations, while they are GUI
based, really only serve as text type Unixes with large scroll buffers.
paul
...
But that is the old fly in the
ointment, other software may not be avilable. I do run windows and real text screen UNIX
is not aviable anymore.
11 Apr
11 Apr
8:40 a.m.
New subject: Speed now & then (Space and time?)
On 1 April 2018 at 00:26, ben via cctalk <cctalk at classiccmp.org> wrote:
But that is the old fly in the ointment, other software may not be avilable.
It is, you know.
I do run windows
Why?
and real text screen UNIX is not aviable anymore.
Sure it is.
I mean, there are even text-only distros, such as INX:
http://inx.maincontent.net/
... and ADRIANE, a spinoff of Knoppix:
http://www.knopper.net/knoppix-adriane/index-en.html
But you can install Debian, Ubuntu or openSUSE in text-only mode with
no GUI if you wish. All the console-mode tools you could want are
available: web browsers, email and chat clients, twitter clients,
music players, etc.
Go the whole hog and install Slackware and go back to installing from
tarballs if you wish.
I'd probably suggest openSUSE as the YaST admin tool works in text
mode, so you don't need to know your way around a hundred config files
-- YaST will do that for you.
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? Google Mail/Hangouts/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven ? Skype/LinkedIn: liamproven
UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
2:48 p.m.
New subject: Speed now & then (Space and time?)
On 4/11/2018 9:40 AM, Liam Proven wrote:
The FREE fpga development software is only under windows.
I have a nice 18 bit cpu here, with only a few hardware bugs.
Hmm would it work better if I change that around ideas.
Care to point to a nice 18 bit version of unix or C.
BTW The cpu has a frame pointer S but no S++ --S operations
so pushing and popping wild data is not a option.
On 1 April 2018 at 00:26, ben via cctalk <cctalk at
classiccmp.org> wrote:
Smart ass response:
Who pirated it for you.
But that is the old fly in the ointment, other software may not be avilable.
It is, you know. I do run
windows
Why? and real text
screen UNIX is not aviable anymore.
Sure it is.
I mean, there are even text-only distros, such as
INX:
http://inx.maincontent.net/
... and ADRIANE, a spinoff of Knoppix:
http://www.knopper.net/knoppix-adriane/index-en.html
But my hardware (LOW density SD card) is 256 9 bit charaters per
block for disk I/O.
But you can install Debian, Ubuntu or openSUSE in
text-only mode with
no GUI if you wish. All the console-mode tools you could want are
available: web browsers, email and chat clients, twitter clients,
music players, etc.
I still have to finish Tomb Raider 1 under DOS(box) First.
Go the whole hog and install Slackware and go back to
installing from
tarballs if you wish.
I'd probably suggest openSUSE as the YaST admin tool works in text
mode, so you don't need to know your way around a hundred config files
-- YaST will do that for you.
WHAT HAPPEND TO * MINUX VERSION #1 *.
Ben.
PS: I do have a better OS kicking around, Oberon but I need a extra
screen and keyboard for it.
PPS:
Software efficiency halves every 18 months, compensating Moore's law
3:16 p.m.
New subject: Speed now & then (Space and time?)
Since you brought it up
On Wed, Apr 11, 2018 at 11:48 PM, ben via cctalk <cctalk at classiccmp.org> wrote:
The FREE fpga development software is only under windows.
Free alternatives exist (and can only get better coverage with time)
http://www.clifford.at/yosys/
https://github.com/cseed/arachne-pnr
http://www.clifford.at/icestorm/
HTH
--
Regards,
Torfinn Ingolfsen
4:45 p.m.
New subject: retrocomputing and fpg's 18 or other odd size bits
On 4/11/2018 4:16 PM, Torfinn Ingolfsen via cctalk wrote:
Since you brought it up
On Wed, Apr 11, 2018 at 11:48 PM, ben via cctalk <cctalk at classiccmp.org> wrote:
Does NOT support my FPGA. I am using the FPGA for all the heavy lifting
of testing my cpu design so in time it can be used for other things. The
real design is a microcode 2901 cpu about 1976 ish, with 256x8 70 ns
proms. Modern 22V10's will be used as 'prom' and 'glue' logic, but
alas
that software and GAL programmer still are windows only.
It is a similar feel to the 16 bit computers other than the PDP 11,
and same cycle times as core of that era. 1.3 us for operate and 2.6 us
memory operations. 18 bits is just about right for a 'small' computer
size and operands and front panel. Disk I/O will be fake devices of 9
bit characters on a SD card.
Now I need to hit the web for some good programing books from the
1970's era so I finalize the I/O and memory map of the computer and
fine tune the instruction set.
Ben.
Yes I know the FPGA card can run faster,but not with 1976 speeds.
The FREE fpga development software is only under windows.
Free alternatives exist (and can only get better coverage with time)
http://www.clifford.at/yosys/
https://github.com/cseed/arachne-pnr
http://www.clifford.at/icestorm/
HTH
4:21 p.m.
New subject: Speed now & then (Space and time?)
On Wed, Apr 11, 2018 at 3:48 PM, ben via cctalk <cctalk at classiccmp.org>
wrote:
The FREE fpga development software is only under
windows.
Xilinx and Altera (now Intel) FPGA development software, including the
"free" editions, have run under Linux for many years now. I routinely use
them on Fedora and CentOS.
The Xilinx Vivado WebPack software supports the entire Artix-7 product
line, which covers a pretty wide range of device sizes. Xilinx ISE WebPack
supports Spartan 3, Spartan 6, and CPLD devices.
5:04 p.m.
New subject: Speed now & then (Space and time?)
On 4/11/2018 5:21 PM, Eric Smith wrote:
On Wed, Apr 11, 2018 at 3:48 PM, ben via cctalk
<cctalk at classiccmp.org
<mailto:cctalk at classiccmp.org>> wrote:
The FREE fpga development software is only under windows.
Xilinx and Altera (now Intel) FPGA development software, including the
"free" editions, have run under Linux for many years now. I routinely
use them on Fedora and CentOS.
I got version #9 of the Altera software to go with the old DE1 FPGA
card.I have that card so I can do TTL logic macro's and test before
I do a PCB layout using 74LS chips. More modern software seems to have
dropped that funtionality. I also like programing in AHDL because
I find VHDL and VERLOG too confusing to use.
AHDL also has a similar format to WINCUPL that I use for 22V10
programing. This way I can define logic modules using 22V10's
with the FPGA and test that as well as the 2901 emulation.
The Xilinx Vivado WebPack software supports the entire
Artix-7 product
line, which covers a pretty wide range of device sizes. Xilinx ISE
WebPack supports Spartan 3, Spartan 6, and CPLD devices.
Any PCB designs I build will use through the hole parts, thus 22V10's
will be my biggest programable device.
Ben.
9:06 p.m.
New subject: Speed now & then (Space and time?)
On Wed, Apr 11, 2018 at 6:04 PM, ben <bfranchuk at jetnet.ab.ca> wrote:
On 4/11/2018 5:21 PM, Eric Smith wrote:
On Wed, Apr 11, 2018 at 3:48 PM, ben via cctalk
<cctalk at classiccmp.org
<mailto:cctalk at classiccmp.org>> wrote:
The FREE fpga development software is only under windows.
Xilinx and Altera (now Intel) FPGA development software, including the
"free" editions, have run under Linux for many years now. I routinely use
them on Fedora and CentOS.
Any PCB designs I build will use through the hole
parts, thus 22V10's will
be my biggest programable device.
Sorry, I thought we were talking about FPGAs.
12 Apr
12 Apr
2:49 p.m.
New subject: Speed now & then (Space and time?)
On 4/11/2018 10:06 PM, Eric Smith via cctalk wrote:
On Wed, Apr 11, 2018 at 6:04 PM, ben <bfranchuk at
jetnet.ab.ca> wrote:
So I buy a pre-made FPGA card, why re-invent the wheel.
Then again with my soldering skill's I better do a valve computer. :)
Ben.
On 4/11/2018 5:21 PM, Eric Smith wrote:
On Wed, Apr 11, 2018 at 3:48 PM, ben via cctalk
<cctalk at classiccmp.org
<mailto:cctalk at classiccmp.org>> wrote:
The FREE fpga development software is only under windows.
Xilinx and Altera (now Intel) FPGA development software, including the
"free" editions, have run under Linux for many years now. I routinely use
them on Fedora and CentOS.
Any PCB designs I build will use through the hole
parts, thus 22V10's will
be my biggest programable device.
Sorry, I thought we were talking about FPGAs.
11 Apr
11 Apr
4:47 p.m.
New subject: Speed now & then (Space and time?)
On Apr 11, 2018, at 5:48 PM, ben via cctalk <cctalk
at classiccmp.org> wrote:
...
I have a nice 18 bit cpu here, with only a few hardware bugs.
Hmm would it work better if I change that around ideas.
Care to point to a nice 18 bit version of unix or C.
BTW The cpu has a frame pointer S but no S++ --S operations
so pushing and popping wild data is not a option.
I haven't tried pcc, but supposedly that has been ported to the PDP-10, so presumably
it can be ported to an 18-bit machine too.
You could try gcc; creating a simple back end is not all that hard. And while it makes no
attempt to support non-multiple-of-8-bit machines, it can be forced to, after a fashion.
One time for grins I banged together a very primitive CDC 6000 back end. It wasn't
correct but it wasn't horribly wrong...
18 bit Unix, not sure about that one. It was originally done on a PDP-7 but I think that
was before C and it's no longer around that I know of. Still, older versions might be
somewhat portable.
Does it have to be Unix? For a simple character environment, Forth is nice and it's
very easy to port to pretty much any computer.
paul
and real
text screen UNIX is not aviable anymore.
Sure it is.
5:42 p.m.
New subject: Speed now & then (Space and time?)
On 4/11/2018 5:47 PM, Paul Koning wrote:
I haven't tried pcc, but supposedly that has been
ported to the PDP-10, so presumably it can be ported to an 18-bit machine too.
Well the original C mostly just and 8 bit bytes and 16 bit ints, with
floating point for good luck. Now who knows what it needs.
But the good (old) news is you still can get the original C compiler for
the 11.
You could try gcc; creating a simple back end is not
all that hard. And while it makes no attempt to support non-multiple-of-8-bit machines,
it can be forced to, after a fashion. One time for grins I banged together a very
primitive CDC 6000 back end. It wasn't correct but it wasn't horribly wrong...
18 bit Unix, not sure about that one. It was originally done on a PDP-7 but I think that
was before C and it's no longer around that I know of. Still, older versions might be
somewhat portable.
Disk I/O needs be word size aligned so I guess 16 bit unix (if you could
use it, curse you bell labs) could be ported providing you don't have
nasty tricks to 18 bit I/O.
Does it have to be Unix? For a simple character environment, Forth is nice and it's
very easy to port to pretty much any computer.
Unix was the only thing I can think
of that is character I/O , device
drivers and on 16 bit cpu written
in a high level language.
paul
6:38 p.m.
New subject: Speed now & then (Space and time?)
On 04/11/2018 02:48 PM, ben via cctalk wrote:
I have a nice 18 bit cpu here, with only a few
hardware bugs.
Hmm would it work better if I change that around ideas.
Care to point to a nice 18 bit version of unix or C.
BTW The cpu has a frame pointer S but no S++ --S operations
so pushing and popping wild data is not a option.
Well, the Univac 1100/2200 series mainframes ran V7 Unix--and they're
36-bit machines, so probably not far from your 18-bitter--and they're
ones' complement machines.
Univac called it "SX1100", so you have a search term.
--Chuck
11:45 p.m.
New subject: 18 bit CPU; was: Speed now & then
On 04/11/2018 06:38 PM, Chuck Guzis via cctalk wrote:
On 04/11/2018 02:48 PM, ben via cctalk wrote:
Remarkably, Unisys keeps a lot of old documentation around. Here's the
reference manual for their "C" on th 1100:
https://public.support.unisys.com/2200/docs/cp14.0/pdf/78310422-011.pdf
Looks pretty much like standard C until you get into the minutiae, such
as "A character constant is 1 to 4 characters" and page 4-4 "Data
Types"
(9 bit characters and 36 bit ints and 18 bit short ints).
So, it should be pretty straightforward unless you assume that a char is
8 bits, with a signed char having a range of +/-255.
--Chuck
I have a nice 18 bit cpu here, with only a few
hardware bugs.
Hmm would it work better if I change that around ideas.
Care to point to a nice 18 bit version of unix or C.
BTW The cpu has a frame pointer S but no S++ --S operations
so pushing and popping wild data is not a option.
Well, the Univac 1100/2200 series mainframes ran V7 Unix--and they're
36-bit machines, so probably not far from your 18-bitter--and they're
ones' complement machines.
Univac called it "SX1100", so you have a search term.
12 Apr
12 Apr
4:48 a.m.
New subject: 18 bit CPU; was: Speed now & then
On 04/12/2018 02:45 AM, Chuck Guzis via cctalk wrote:
On 04/11/2018 06:38 PM, Chuck Guzis via cctalk wrote:
Signed 8 bits would be? -128 to +127.
bill
On 04/11/2018 02:48 PM, ben via cctalk wrote:
Remarkably, Unisys
keeps a lot of old documentation around. Here's the
reference manual for their "C" on th 1100:
https://public.support.unisys.com/2200/docs/cp14.0/pdf/78310422-011.pdf
Looks pretty much like standard C until you get into the minutiae, such
as "A character constant is 1 to 4 characters" and page 4-4 "Data
Types"
(9 bit characters and 36 bit ints and 18 bit short ints).
So, it should be pretty straightforward unless you assume that a char is
8 bits, with a signed char having a range of +/-255.
I have a nice 18 bit cpu here, with only a few
hardware bugs.
Hmm would it work better if I change that around ideas.
Care to point to a nice 18 bit version of unix or C.
BTW The cpu has a frame pointer S but no S++ --S operations
so pushing and popping wild data is not a option.
Well, the Univac 1100/2200
series mainframes ran V7 Unix--and they're
36-bit machines, so probably not far from your 18-bitter--and they're
ones' complement machines.
Univac called it "SX1100", so you have a search term. 
6:55 a.m.
New subject: 18 bit CPU; was: Speed now & then
On 2018-04-12 7:48 AM, Bill Gunshannon via cctalk wrote:
Yes, but Chuck was describing the Univac, where char is a 9-bit type,
and a signed char is 1 sign bit and 8 magnitude bits, giving +/- 255.
--Toby
On 04/12/2018 02:45 AM, Chuck Guzis via cctalk wrote:
> On 04/11/2018 06:38 PM, Chuck Guzis via cctalk wrote:
>> On 04/11/2018 02:48 PM, ben via cctalk wrote:
>>
>>> I have a nice 18 bit cpu here, with only a few hardware bugs.
>>> Hmm would it work better if I change that around ideas.
>>>
>>> Care to point to a nice 18 bit version of unix or C.
>>> BTW The cpu has a frame pointer S but no S++ --S operations
>>> so pushing and popping wild data is not a option.
>> Well, the Univac 1100/2200 series mainframes ran V7 Unix--and they're
>> 36-bit machines, so probably not far from your 18-bitter--and they're
>> ones' complement machines.
>>
>> Univac called it "SX1100", so you have a search term.
> Remarkably, Unisys keeps a lot of old documentation around. Here's the
> reference manual for their "C" on th 1100:
>
> https://public.support.unisys.com/2200/docs/cp14.0/pdf/78310422-011.pdf
>
> Looks pretty much like standard C until you get into the minutiae, such
> as "A character constant is 1 to 4 characters" ...
Apple also used this extension in their Mac C compilers.
(9 bit
characters and 36 bit ints and 18 bit short ints).
So, it should be pretty straightforward unless you assume that a char is
8 bits, with a signed char having a range of +/-255.
Signed 8 bits would be? -128 to +127.
bill
3:16 p.m.
New subject: 18 bit CPU; was: Speed now & then
On 4/12/2018 7:55 AM, Toby Thain via cctalk wrote:
On 2018-04-12 7:48 AM, Bill Gunshannon via cctalk
wrote:
Yes, but Chuck was describing the Univac, where char is a 9-bit type,
and a signed char is 1 sign bit and 8 magnitude bits, giving +/- 255.
--Toby
Well I have one better with my cpu, a char is -128 to 384. Bits #8 and
#9 are sign. This way I can use the classic format
<OP><AC><INDEX><OFFSET> for single word addressing.
Are there any FPGA designs out there for the non 8 bit computers,
other than DEC's PDP 7,8,11 and perhaps a PDP 10?
Why in hindsight did I not buy 36 front panel switches?
Ben.
On 04/12/2018 02:45 AM, Chuck Guzis via cctalk wrote:
> On 04/11/2018 06:38 PM, Chuck Guzis via cctalk wrote:
>> On 04/11/2018 02:48 PM, ben via cctalk wrote:
>>
>>> I have a nice 18 bit cpu here, with only a few hardware bugs.
>>> Hmm would it work better if I change that around ideas.
>>>
>>> Care to point to a nice 18 bit version of unix or C.
>>> BTW The cpu has a frame pointer S but no S++ --S operations
>>> so pushing and popping wild data is not a option.
>> Well, the Univac 1100/2200 series mainframes ran V7 Unix--and they're
>> 36-bit machines, so probably not far from your 18-bitter--and they're
>> ones' complement machines.
>>
>> Univac called it "SX1100", so you have a search term.
> Remarkably, Unisys keeps a lot of old documentation around. Here's the
> reference manual for their "C" on th 1100:
>
> https://public.support.unisys.com/2200/docs/cp14.0/pdf/78310422-011.pdf
>
> Looks pretty much like standard C until you get into the minutiae, such
> as "A character constant is 1 to 4 characters" ...
Apple also used this extension in their Mac C compilers.
(9 bit
characters and 36 bit ints and 18 bit short ints).
So, it should be pretty straightforward unless you assume that a char is
8 bits, with a signed char having a range of +/-255.
Signed 8 bits would be? -128 to +127.
7:15 p.m.
New subject: 18 bit CPU; was: Speed now & then
On 4/12/2018 6:51 PM, Chuck Guzis via cctalk wrote:
On 04/12/2018 03:16 PM, ben via cctalk wrote:
Not really, but having 8 bit
disk IO is tad simpler.
Indexing is still -128 to 384 offset. This gives a good
sized page 0 and high address (07773xx) i/o out page.
Ben.
Well I have one better with my cpu, a char is -128 to 384.
Care to elaborate on why such a lopsided range?
--Chuck
OK, you forced me to go back to 8 bit unsigned bytes.
14 Apr
14 Apr
4 p.m.
New subject: 18 bit CPU; was: Speed now & then
On 04/12/2018 09:55 AM, Toby Thain via cctalk wrote:
On 2018-04-12 7:48 AM, Bill Gunshannon via cctalk
wrote:
Yes, but Chuck was describing the
Univac, where char is a 9-bit type,
and a signed char is 1 sign bit and 8 magnitude bits, giving +/- 255.
I'm familiar with Univac's having worked on the 1100 many moons ago,
But look at the line above my comment:
?"you assume that a char is 8 bits, with a signed char having a range
of +/-255".
An 8 bit signed char has the values -128 to +127, as I stated.? even a 9 bit
signed char would not be +/-255 but -256 to +255.
bill
On 04/12/2018 02:45 AM, Chuck Guzis via cctalk wrote:
> On 04/11/2018 06:38 PM, Chuck Guzis via cctalk wrote:
>> On 04/11/2018 02:48 PM, ben via cctalk wrote:
>>
>>> I have a nice 18 bit cpu here, with only a few hardware bugs.
>>> Hmm would it work better if I change that around ideas.
>>>
>>> Care to point to a nice 18 bit version of unix or C.
>>> BTW The cpu has a frame pointer S but no S++ --S operations
>>> so pushing and popping wild data is not a option.
>> Well, the Univac 1100/2200 series mainframes ran V7 Unix--and they're
>> 36-bit machines, so probably not far from your 18-bitter--and they're
>> ones' complement machines.
>>
>> Univac called it "SX1100", so you have a search term.
> Remarkably, Unisys keeps a lot of old documentation around. Here's the
> reference manual for their "C" on th 1100:
>
> https://public.support.unisys.com/2200/docs/cp14.0/pdf/78310422-011.pdf
>
> Looks pretty much like standard C until you get into the minutiae, such
> as "A character constant is 1 to 4 characters" ...
Apple also used
this extension in their Mac C compilers.
(9 bit
characters and 36 bit ints and 18 bit short ints).
So, it should be pretty straightforward unless you assume that a char is
8 bits, with a signed char having a range of +/-255.
Signed 8 bits would be? -128 to +127.
4:49 p.m.
New subject: 18 bit CPU; was: Speed now & then
On 2018-04-14 7:00 PM, Bill Gunshannon via cctalk wrote:
...
I'm familiar with Univac's having worked on the 1100 many moons ago,
But look at the line above my comment:
?"you assume that a char is 8 bits, with a signed char having a range
of +/-255".
An 8 bit signed char has the values -128 to +127, as I stated.? even a 9 bit
signed char would not be +/-255 but -256 to +255.
Not in one's complement.
bill
11:28 p.m.
New subject: 18 bit CPU; was: Speed now & then
On Apr 14, 2018, at 4:00 PM, Bill Gunshannon via cctech wrote:
I'm familiar with Univac's having worked on
the 1100 many moons ago,
But look at the line above my comment:
"you assume that a char is 8 bits, with a signed char having a range
of +/-255".
An 8 bit signed char has the values -128 to +127, as I stated. even a 9 bit
signed char would not be +/-255 but -256 to +255.
Doesn't the 1100 use one's complement? -0 != 0, so AFAICT it's still +/-255.
ok
bear.
--
until further notice
15 Apr
15 Apr
7:44 a.m.
New subject: 18 bit CPU; was: Speed now & then
On 04/15/2018 02:28 AM, r.stricklin via cctalk wrote:
On Apr 14, 2018, at 4:00 PM, Bill Gunshannon via
cctech wrote:
Can't remember that.? It's over 30 years since my 1100 days.
I do remember it wasn't an ASCII machine, however.? good ole Fielddata.
bill
I'm familiar with Univac's having worked
on the 1100 many moons ago,
But look at the line above my comment:
"you assume that a char is 8 bits, with a signed char having a range
of +/-255".
An 8 bit signed char has the values -128 to +127, as I stated. even a 9 bit
signed char would not be +/-255 but -256 to +255.
Doesn't the 1100 use
one's complement? -0 != 0, so AFAICT it's still +/-255.
4:47 p.m.
New subject: 18 bit CPU; was: Speed now & then
On Apr 15, 2018, at 09:44, Bill Gunshannon via cctalk
<cctalk at classiccmp.org> wrote:
Yes, the Univac 1100 series were one?s complement (had brief experience as a student with
1108 and 1110 from 1969 to 1975)
Sent from my iPad
On 04/15/2018 02:28 AM, r.stricklin via cctalk
wrote:
Can't remember that. It's over 30 years since my 1100 days.
I do remember it wasn't an ASCII machine, however. good ole Fielddata.
bill
On Apr 14, 2018, at 4:00 PM, Bill Gunshannon via
cctech wrote:
I'm familiar with Univac's having worked on the 1100 many moons ago,
But look at the line above my comment:
"you assume that a char is 8 bits, with a signed char having a range
of +/-255".
An 8 bit signed char has the values -128 to +127, as I stated. even a 9 bit
signed char would not be +/-255 but -256 to +255.
Doesn't the 1100 use
one's complement? -0 != 0, so AFAICT it's still +/-255.
5:07 p.m.
New subject: 18 bit CPU; was: Speed now & then
On 04/15/2018 04:47 PM, Jay Jaeger via cctalk wrote:
Yes, the Univac 1100 series were one?s complement (had
brief experience as a student with 1108 and 1110 from 1969 to 1975)
I thought I'd originally said as much. 9 bit characters with a range of
+/-255 as well as +/- zero.
Here are some cool coding tricks for the 1100 series:
https://www.fourmilab.ch/documents/univac/cute_tricks.html
Similar tricks exist for the ones' complement CDC 6000 series.
--Chuck
12 Apr
12 Apr
1:13 p.m.
New subject: sizes and negative ints (Was: 18 bit CPU; was: Speed now & then
So, it should
be pretty straightforward unless you assume that a char is
8 bits, with a signed char having a range of +/-255.
Signed 8 bits would be? -128
to +127.
5:16 a.m.
New subject: 18 bit CPU; was: Speed now & then
On Wed, Apr 11, 2018 at 11:45:07PM -0700, Chuck Guzis via cctalk wrote:
Looks pretty much like standard C until you get into
the minutiae, such
as "A character constant is 1 to 4 characters" and page 4-4 "Data
Types"
(9 bit characters and 36 bit ints and 18 bit short ints).
So, it should be pretty straightforward unless you assume that a char
is 8 bits, with a signed char having a range of +/-255.
"pretty straightforward"
Thanks. I needed a laugh.
As someone who tries to get/keep a zillion open source packages building
on FreeBSD, on non-x86 archs, I constantly refer to a piece of paper that
hangs on my wall. It was given to me many years ago at a conference, by
its author, Henry Spencer. An annotated version may be found here:
https://www.lysator.liu.se/c/ten-commandments.html
Of course these days s/VAX/32-bit Linux distro/, but the principle still
holds.
Finally, for any remaining disbelievers, the most recent update of
FreeBSD's toolchain to include Clang version 6, regressed 419 port
builds -- on x86 alone.
mcl
6:23 a.m.
New subject: 18 bit CPU; was: Speed now & then
On Thu, Apr 12, 2018 at 07:16:58AM -0500, Mark Linimon via cctalk wrote:
On Wed, Apr 11, 2018 at 11:45:07PM -0700, Chuck Guzis
via cctalk wrote:
> Looks pretty much like standard C until you get into the minutiae, such
> as "A character constant is 1 to 4 characters" and page 4-4 "Data
Types"
> (9 bit characters and 36 bit ints and 18 bit short ints).
...
"pretty straightforward"
Thanks. I needed a laugh.
As someone who tries to get/keep a zillion open source packages building
on FreeBSD, on non-x86 archs, I constantly refer to a piece of paper that
hangs on my wall. It was given to me many years ago at a conference, by
its author, Henry Spencer. An annotated version may be found here:
https://www.lysator.liu.se/c/ten-commandments.html
One of my favourites. Henry is an interesting guy but it has been years
since I've talked with him in person. He's also responsible for
"The Amazingly Workable Formatter".
Of course these days s/VAX/32-bit Linux distro/, but the principle still
holds.
Finally, for any remaining disbelievers, the most recent update of
FreeBSD's toolchain to include Clang version 6, regressed 419 port
builds -- on x86 alone.
*chuckle* A pointer isn't just an int anymore now. ;)
Amusingly years ago I worked for Computing Devices Canada that used some
CDC computers. I was told through a very reliable source that they
got Unix ported to the Cyber by SoftQuad based in Toronto. They were
well known as a 'troff house' at this time. I'm told they wrote a PDP-11
emulator for the Cyber and that's how they got Unix on the Cyber. ;)
mcl
db
--
- db at FreeBSD.org db at db.net http://www.db.net/~db
9:18 a.m.
New subject: 18 bit CPU; was: Speed now & then
On 04/12/2018 06:23 AM, Diane Bruce wrote:
Amusingly years ago I worked for Computing Devices
Canada that used some
CDC computers. I was told through a very reliable source that they
got Unix ported to the Cyber by SoftQuad based in Toronto. They were
well known as a 'troff house' at this time. I'm told they wrote a PDP-11
emulator for the Cyber and that's how they got Unix on the Cyber. ;)
I could see lots of problems doing it any other way, just from the
viewpoint of 'C'. A character on the Cyber 70/170 series is either 6
bits or 12 bits, if extensions are used. That's not to say that in a
character string, *all* characters are either 6 bits or 12 bits, but can
be a mixture, with certain 6-bit codes used as "escape" codes signaling
a 12 bit character code. Two null characters have to be placed in the
low-order 12 bits of a word to signal an end of line, so that EOL can be
anywhere from 12 to 60 bits.
This peculiar convention dates from the time when 6-bit codes were
common and included only uppercase letters, digits and a few
punctuation. I recall the various papers and proposals that circulated
at the time to extend the set. Rather elaborate schemes for packing 8
bit characters into a 60 bit word (7.5 of them), use of 10 and 12 bit
codes and the aforementioned 6/12 bit scheme, which was selected because
it made the smallest impact to existing programs.
Added to that, the machines are ones' complement.
And yes, Bill--perhaps I wasn't clear enough, but on SX1100 a char is 8
bits plus sign, hence +/-255, with +/- zeroes.
--Chuck
1:37 p.m.
New subject: 18 bit CPU; was: Speed now & then
On Thu, Apr 12, 2018 at 9:18 AM, Chuck Guzis via cctalk <
cctalk at classiccmp.org> wrote:
On 04/12/2018 06:23 AM, Diane Bruce wrote:
\
I could see lots of problems doing it any other way, just from the
viewpoint of 'C'. A character on the Cyber 70/170 series is either 6
bits or 12 bits, if extensions are used. That's not to say that in a
character string, *all* characters are either 6 bits or 12 bits, but can
be a mixture, with certain 6-bit codes used as "escape" codes signaling
a 12 bit character code. Two null characters have to be placed in the
low-order 12 bits of a word to signal an end of line, so that EOL can be
anywhere from 12 to 60 bits.
And, if memory serves, the ":" was coded as a null character, causing it to
disappear from the end of a line.
-- Charles
2:25 p.m.
New subject: 18 bit CPU; was: Speed now & then
On 04/12/2018 01:37 PM, Charles Anthony via cctalk wrote:
And, if memory serves, the ":" was coded as
a null character, causing it to
disappear from the end of a line.
It depended on which character set you were using. The CDC 63-character
set didn't use 00, except as an EOL. Colon was octal 63, which was a
percent sign in the 64 character set. There were also CDC graphic and
ASCII graphic variants (print trains to match), so that, depending on
the print train, double quotation marks came out as "not equal" and vice
versa, along with other differences. You learned to read your listings
both ways.
The "CDC Graphic" set seemed to be more suited to ALGOL programs, which
was a bit odd, since FORTRAN was the predominant HLL on those machines.
So, for example, the CDC Graphic set has all of the math relationals;
EQ, NE, GE, LE, LT GT, as well as the logical operators; OR AND NOT
EQUIV, as well as concatenation and up- and down- arrows.
This really wasn't any worse than IBM 6 bit character code. Usually,
the question came up as "which one?" IBM 1401 codes were not the same
as, for example, 7090 codes.
The good old days...
--Chuck
3:58 a.m.
New subject: Speed now & then (Space and time?)
On 11 April 2018 at 23:48, ben <bfranchuk at jetnet.ab.ca> wrote:
The FREE fpga development software is only under
windows.
WINE works well now.
I write in Word 97 under WINE on 64-bit Ubuntu. Works a treat,
blindingly fast, and unlike any Linux tool I can find, it has a
working outliner.
VMs are almost trivially easy, too. Win10 is a free download and works
usably without registration or activation.
WHAT HAPPEND TO * MINUX VERSION #1 *.
I don't understand the question.
PS: I do have a better OS kicking around, Oberon but I
need a extra
screen and keyboard for it.
I have that -- well, A2 with Bluebottle -- running on the metal on my
old Thinkpad X200 (installed via a VM). Awaiting more time to learn
and experiment.
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? Google Mail/Hangouts/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven ? Skype/LinkedIn: liamproven
UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
9:27 a.m.
New subject: Speed now & then (Space and time?)
On 04/12/2018 05:58 AM, Liam Proven via cctalk wrote:
On 11 April 2018 at 23:48, ben <bfranchuk at
jetnet.ab.ca> wrote:
Some of the older Xilinx software (required to create config
files for their older FPGA chips) will not run on a 64-bit
platform (either Linux OR Windows) without a lot of fooling
around. Their later versions work fine on 64-bit. That was
some kind of government ITAR restriction.
Jon
The FREE fpga development software is only under
windows.
29 Mar
29 Mar
9:45 p.m.
New subject: Speed now & then (Space and time?)
On Mar 29, 2018, at 7:00 PM, Jon Elson via cctalk
<cctalk at classiccmp.org> wrote:
Then, in 1986, I bought a MicroVAX-II CPU board from a broker, and a bunch of 3rd party
peripherals, and made a copy of VMS 4.7 (Might have used something earlier for a time.)
I was in 7th heaven! A REAL computer at LAST!
And now a Raspberry Pi running SIMH can emulate a faster VAX system than that MicroVAX II.
I?m slowly getting my VMS cluster back up and running, but through emulation. My goal is
to power down my Alpha, except when I need a couple programs that won?t run on a VAX. My
fastest VAX (beating my VAXstation 4000/60) is SIMH running on an ESXI server.
Zane
11 Apr
11 Apr
8:36 a.m.
New subject: Speed now & then (Space and time?)
On 29 March 2018 at 21:35, Fred Cisin via cctalk <cctalk at classiccmp.org> wrote:
MP4s mean that now, not only does it take MUCH longer to create the
document, we can now waste MUCH more of the reader's time!
I find it very annoying that when GOOGLE'ing to find a simple answer, many
of the first hits are YouTube.
I got a room full of very surprised looks a couple of years ago,
interviewing for a tech-writer position, when I said that I hated
online videos as instructions, finding them far too slow and
inefficient.
This concept shocked everyone in the room, AFAICT.
Dancing kangaroos and yodelling jellyfish has let form
triumph over content!
When will we finally have smell-o-vision?
I used to think this of media such as Snapchat, Tumblr, Pinterest,
Instagram et al.
Then I realised something -- something connected with my career change
to tech writing.
A lot of people _can't_ express themselves in text. Some don't care
and let fly with all their spelling and grammatical errors,
mostly-missing-and-the-rest-incorrect punctuation etc.
At least 1 of my cousins is like that -- I can barely follow when this
woman (who is in her mid 50s) writes to me. It's barely English, with
no punctuation, no capitals, no sentences or paragraphs, just stream
of incoherent severely-misspelled consciousness.
I don't think she realises, and she can't help it.
I suspect many, of all ages, are like her.
And I further suspect that they can't easily consume text, either.
They can't read very fluidly.
Also see:
https://www.joelonsoftware.com/2001/11/16/20011116/
... and this from someone who I generally admire. He, as many do now,
see threading as an unnecessary, distracting technical frippery.
Astounding.
But for those who _do_ care about appearances but _can't_ write well
*and know it*, Snapchat etc. are a way out. You can "express yourself"
via pictures. You can take them yourself, use filters and so on to
tart them up a bit, and still communicate with a community of friends,
with no more writing than a few tags at a minimum.
If you can't even do that, Pinterest lets you do it _with someone
else's images_.
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? Google Mail/Hangouts/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven ? Skype/LinkedIn: liamproven
UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
9:33 a.m.
New subject: Speed now & then (Space and time?)
-----Original Message-----
From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Liam Proven via
cctalk
Sent: 11 April 2018 16:36
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Subject: Re: Speed now & then (Space and time?)
On 29 March 2018 at 21:35, Fred Cisin via cctalk <cctalk at classiccmp.org>
wrote:
Sometimes these are useful, usually not. Some of the slowest and most painful come from
the biggest players...
Of course when you want a video, like how to remove the casing from my AirCon because the
drain is blocked
-site:youtube.com gets rid of most
MP4s mean that now, not only does it take MUCH longer to create the
document, we can now waste MUCH more of the reader's time!
I find it very annoying that when GOOGLE'ing to find a simple answer,
many of the first hits are YouTube.
I got a room full of very surprised looks a couple of
years ago, interviewing
for a tech-writer position, when I said that I hated online videos as
instructions, finding them far too slow and inefficient.
This concept shocked everyone in the room, AFAICT.
Why, its obvious...
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? Google Mail/Hangouts/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven ? Skype/LinkedIn: liamproven
UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
11:21 a.m.
New subject: Speed now & then (Space and time?)
On Wed, Apr 11, 2018 at 11:36 AM, Liam Proven via cctalk
<cctalk at classiccmp.org> wrote:
On 29 March 2018 at 21:35, Fred Cisin via cctalk
<cctalk at classiccmp.org> wrote:
I totally agree. I read faster than most people talk and I retain
more information. I'd much rather read 1,000 words than watch a 3
minute video.
MP4s mean that now, not only does it take MUCH longer to create the
document, we can now waste MUCH more of the reader's time!
I find it very annoying that when GOOGLE'ing to find a simple answer, many
of the first hits are YouTube.
I got a room full of very surprised looks a couple of years ago,
interviewing for a tech-writer position, when I said that I hated
online videos as instructions, finding them far too slow and
inefficient. This concept shocked everyone in the room, AFAICT.
Not surprising given how many generations have now grown up watching
TV as their major input mode.
Then I realised something -- something connected with
my career change
to tech writing.
A lot of people _can't_ express themselves in text. Some don't care
and let fly with all their spelling and grammatical errors,
mostly-missing-and-the-rest-incorrect punctuation etc.
Yes. People can ramble into a mobile phone and upload to YouTube but
actually _writing_ the same process... not everyone is a writer.
There are times when video instruction makes sense - describing, for
example, a chemical reaction that produces major visible change in a
few moments is better to watch than to try to describe. The vast
majority of stuff? Teaching programming? I don't want to watch 2
hours of someone editing text... give me words and perhaps a
screenshot or two if there's something too complicated to simply write
about.
I've taken several MOOCs. The only saving grace is the 2X and 4X
buttons on playback.
-ethan
12 Apr
12 Apr
3:57 a.m.
New subject: Speed now & then (Space and time?)
On 11 April 2018 at 20:21, Ethan Dicks <ethan.dicks at gmail.com> wrote:
I totally agree. I read faster than most people talk and I retain
more information. I'd much rather read 1,000 words than watch a 3
minute video.
Strongly agreed.
Not surprising given how many generations have now
grown up watching
TV as their major input mode.
:-(
Yes. People can ramble into a mobile phone and upload
to YouTube but
actually _writing_ the same process... not everyone is a writer.
Worse still, Youtube has commercialised this. The _only_ instructions
I could find anywhere for rooting my smartphone and installing a new
ROM were a Russian language Youtube video, some 30min long. I don't
speak Russian, but thankfully, he had subtitled it in English.
But people make many such vids, with bolted-on title sequences and
rambling "hi guys, welcome, thanks for watching" intros, partly
because that's all they know how to do, and partly because they hope
to get lots of people to watch it all and thus get a kickback from
Google for the revenue from the embedded ads.
99.9% won't of course, but a few get rich doing it: PewDePie etc.
And 99.9% of them are later exposed as racists, anti-semites etc. What
a shock, etc.
Wannabe "models" are doing the same on Instagram -- underweight teen
women making a good living from posting a lot of pics of themselves in
their underwear or swimwear, and so on. A few later "come out" as
suffering from anorexia etc.
https://www.theguardian.com/media/2015/nov/03/instagram-star-essena-oneill-…
Most don't, but they set horribly unrealistic standards of appearance
for young women, etc.
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? Google Mail/Hangouts/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven ? Skype/LinkedIn: liamproven
UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
9:25 a.m.
New subject: Speed now & then (Space and time?)
On 04/12/2018 05:57 AM, Liam Proven via cctalk wrote:
On 11 April 2018 at 20:21, Ethan Dicks <ethan.dicks
at gmail.com> wrote:
Yes, me too! I HATE these terrible videos with shaky
cameras and unprepared presenters.
Jon
I totally agree. I read faster than most people
talk and I retain
more information. I'd much rather read 1,000 words than watch a 3
minute video.
Strongly agreed.
2204
days inactive
2222
days old
66 comments
24 participants
participants (24)
-
abuse＠cabal.org.uk -
allisonportable＠gmail.com -
bear＠typewritten.org -
bfranchuk＠jetnet.ab.ca -
bill.gunshannon＠hotmail.com -
c.murray.mccullough＠gmail.com -
cclist＠sydex.com -
charles.unix.pro＠gmail.com -
cisin＠xenosoft.com -
cube1＠charter.net -
dave.g4ugm＠gmail.com -
db＠db.net -
elson＠pico-systems.com -
ethan.dicks＠gmail.com -
healyzh＠avanthar.com -
jecel＠merlintec.com -
jwest＠classiccmp.org -
korpela＠ssl.berkeley.edu -
linimon＠lonesome.com -
lproven＠gmail.com -
paulkoning＠comcast.net -
spacewar＠gmail.com -
tingox＠gmail.com -
toby＠telegraphics.com.au