> From: Johnny Billquist
> But for people who actually wants to read several hundred K of
> MACRO-11... Here is your chance... :-)
Ah. Was going to ask what the TCP/IP itself was written in. Well, at least
it's an 8-bit machine - think about writing a TCP/IP in PDP-10 MACRO... :-)
Noel
It is David Tumey and he is on the Greenkeys list.
Regards
Rob
> -----Original Message-----
> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Bill
> Sudbrink
> Sent: 14 January 2015 22:24
> To: cctalk at classiccmp.org
> Subject: Dan Tumey
>
> Is he on this list? The University of Iowa's PDP-8 restoration site says
he is
> producing beautiful replacement Teletype hammer pads:
>
> http://homepage.cs.uiowa.edu/~jones/pdp8/UI-8/log.shtml
>
> I'd love to get a few for my tty.
>
> Bill S.
Jay, leds hasn't changed much from years ago. Electronicaly, i believe any
led of same size/format/color will fit. Of course i can dig deeper if you
want
enviado do meu telemovel
Em 14/01/2015 19:25, "Jay West" <jwest at classiccmp.org> escreveu:
Yep, I'm still working on "restoration" of the Microdata Reality.
I say "restoration", because due to another restoration project that
actually has a deadline, I only have time to clean up the microdata and
repair just obvious visual brokenness, not actually start testing/repairing
it electronically. That will come after the "deadline project" J
As most know, schematics and detailed documentation are nonexistent for this
machine.
I've done the rack, the disc drive, the tape drive, and the power supply. On
to the last item, the front panel.
Virtually all of the LED's on the front panel board had so much mouse pee
that the leads on the LEDS actually corroded through, so I need to replace
them all.
Without schematics, can anyone suggest how I might go about determining a
suitable replacement LED from an electrical perspective?
Pictures at www.ezwind.net/microdata/restoration
Best,
J
Cctalk'rs,
Very exciting news to share tonight.
Al Katz and Sol Libes, who co-founded the Trenton Computer Festival
based on Roger Amidon's idea, gave we "MARCHins" permission to publish
their video of ENIAC's John Mauchly keynoting the 1977 show. It was the
first TCF keynote: there wasn't one at the 1976 show.
Claude Kagan (a Western Electric engineer who also ran a 1960s/1970s
high school computer club here in central New Jersey) gave the
introduction. There are also remarks by Kay Mauchly, who was an ENIAC
programmer, followed by some audience Q&A.
A few minutes of the video are choppy due to the original source.
Please share this far and wide!
Video is in two parts so here's the playlist:
https://www.youtube.com/playlist?list=PL_e5fSxflvrxXO5Ddh9ZXX-cli94zF3Pc
I just noticed that NTP on classiccmp stopped, it has been restarted.
My apologies, but you?ll probably want to scroll back ? day to catch any
unread messages if you didn?t notice it!
J
Sean wrote....
------------
I have Comcast business grade cable Internet to my home and I'm already hosting my own personal site and sites for a few other folks; no data caps; plenty of static IPs; not terribly slow; everything's protected with a Liebert double-conversion UPS... not totally a commercial datacenter in terms of available bandwidth or backup power capacity but nevertheless my uptimes are decent.
------------
I have said many times in the past, but as new list members pop on they are probably not aware of this.
I host the classiccmp server (which is not just the classiccmp mailing list, but a growing truckload of user websites that are classiccmp related) gratis. I do not host it on a "Comcast business grade cable internet" connection (there's a contradiction in terms in and of itself...)
This is not something I "run out of my home". One of the companies that I own is a hosting provider. We have a rather large-ish datacenter and I have dedicated a set of resources to classiccmp.
Our bandwidth is many orders of magnitude greater than a "home or business connection". Not to mention, it's managed bandwidth with load balanced connections to multiple carriers. Our infrastructure is all xenserver based, so spinning up new VM's is a mouseclick. We have quite a few SAN's so storage is not a problem at all. Full HVAC monitoring & control, power backups (oh, and we have two separate powerstations from Ameren UE ON SITE). This infrastructure is professionally managed by my company 24x7. Long story short... it's not a "home" connection.
More to the point, since I own the company, rest assured that hosting your site here is not a "till the boss finds out" or "my wife accidentally turned off the computer" type of situation.
As a result - I'm happy to host any website, ftp site, wiki, etc. etc. that is classic computer related. As long as it meets that criteria, you can host your site with us for no charge.
Best,
J
> From: Robert Jarratt
>> I've replaced LEDs many times without thinking what I am fitting.
> "without thinking" is that an impostor pretending to be Tony? :-) :-)
Foolish novice! Please consult:
http://en.wikipedia.org/wiki/Hacker_koan#Enlightenment
for enlightenment. :-)
Noel
More discussion ensued than was expected for this question.
On a minimal 4k machine (no extended memory and no EAE) and no data break
devices operating the longest latency would be that of a memory reference
instruction with a defer (indirect address) cycle. On a Straight 8 this
would be 4.5 microseconds. A single cycle data break device could have
delayed the interrupt indefinitely although I know of no such devices. A
three cycle break could extend the delay by an additional three memory
cycles (4.5 microseconds) for a total of 9 microseconds.
If the machine was equipped with an EAE then the Division instruction would
have delayed entry of the interrupt service routine by up to 35
microseconds (on a straight 8). I believe this was a 9 microsecond
instruction on the 8/e EAE.
If the machine is equipped with extended memory then there is the CIF
induced delay. CIF is the Change Instruction Field instruction. This
instruction only schedules the change. The actual change does not take
place until the next JMP I or JMS I instruction. The interrupts are masked
by the CIF until the conclusion of the indirect branch. This is because
the interrupt handler would not be able to restore the instruction field
correctly in this instance. I have been unable to think of a reason why
you would ever want to delay the indirect branch although you certainly
could do so. That means the sequence CIF followed by a JMS I would only
see the additional delay from the JMS I which is the same as the delay from
a memory reference instruction with a defer. The JMP I variant would only
be 3 microseconds.
And the greatest source of interrupt latency on a straight 8 would have
been due to the Option 189 which is the low cost A/D converter. This
option added the ability to do 6 to 12 bit A/D conversions as a CPU
instruction (6004). It performed a typical successive approximation
conversion using the MB and AC registers. When 12 bit conversion were
selected this instruction would take 56.6 microseconds to execute according
to the manual. I don't have a 189 for my straight 8 but I am planning on
hunting down the cards I don't have.
And the answer Mr Stearns gave for this question was "No matter what it is
faster than Windows."
On Mon, Jan 12, 2015 at 9:10 AM, Doug Ingraham <dpi at dustyoldcomputers.com>
wrote:
> This weeks question comes from Warren Stearns. It is a little obscure and
> specific to the PDP-8 family of computers.
>
> What is the source of the greatest latency in the interrupt system on a
> PDP-8.
>
> I have three answers, two of the answers depends on the options fitted to
> an 8.
>
> Why would this have been an important question? Interrupt latency would
> be extremely important in the field of data collection which was one of the
> principal early uses of these machines. My particular 8 was used for
> exactly this purpose in the Summer when it was hauled to a radar site and
> collected weather research data for the Institute of Atmospheric Sciences.
> I believe it was used for this from 1969 through 1972. I have several
> hundred DECTapes with some of this data. The surprising thing is we don't
> see any problems reading DECTapes that haven't been out of their box since
> the early 70's.
>
> Doug Ingraham
> PDP-8 S/N 1175
>
Is he on this list? The University of Iowa's PDP-8 restoration site
says he is producing beautiful replacement Teletype hammer pads:
http://homepage.cs.uiowa.edu/~jones/pdp8/UI-8/log.shtml
I'd love to get a few for my tty.
Bill S.
So.. about this "knowledgebase" of restoration techniques.
Apparently new folks don't know and some older listmembers don't remember...
We did start a "wiki" for people to post restoration tips, repair tips, etc.
This was done about 8 years ago. When I first brought up the idea there was
a lot of discussion on the list as to if it was a good idea or not. Many
people had very good thoughts as to why it would be wonderful, and many
other people had equally good thoughts as to why it would not be wonderful.
In any case, I set it up. We found that there was an initial flurry of
posting, and then virtually nothing. Statistics showed it was not used very
much at all. There were a handful of issues as I recall (not my
implementation of it, but in the general idea of a
repair/troubleshooting/restoration "wiki"). I only remember one of them at
the moment... and that was that someone would post an article without really
having detailed expertise in that given area and then someone that DID have
expertise in that area would (for lack of a better term) contramand that
article or write a separate one with conflicting info which made it hard for
a novice to really sift through the information. In short, everyone has an
opinion and at times the articles directly conflicted with another and
someone seeking knowledge wouldn't know who to believe.
That being said, if people really want to give this another try, I would be
happy to turn on the old classiccmp knowledge base (I'm 99% sure it's stored
but just not turned on), or I could easily have one of my support staff dump
a wiki installation to a folder there (under classiccmp) and we could give
it a try again. I'm all for it, but for it to be successful - it has to be
due to contribution/acceptance by the membership at large. My proclivity at
this point would be to install a new wiki and then pull articles already
posted in the old "wiki" into it.
And yes, if it's to be in the classiccmp.org domain, I'd have to host it. I
have not yet seen a scenario where we'd be willing to point an a-record
off-site (but that's not to say some future situation might get a different
response).
Best,
J