Jihad needs scientists

[Dan Bloomquist]

Eeyore wrote:

So Mr Expert. Why isn't TTL made on a 40 Volt process ?

Gee donkey ass. There are open collector devices. Gee DA, I work at 3.3
volts, not 5. Gee DA, what about mixed signal?. Do you really want to go
there?

I'm sure you will troll every place possible, AKA Poo Bear.

To the sci. groups, sorry for feeding the troll. I've been on the poo
wagon for several days!!!!!!!!

 

[Eeyore]

Dan Bloomquist wrote:

Eeyore wrote:

So Mr Expert. Why isn't TTL made on a 40 Volt process ?

Gee donkey ass. There are open collector devices.

Blimey ! I must have missed that (not) !

Gee DA, I work at 3.3 volts, not 5. Gee DA, what about mixed signal?. Do you
really want to go there?

How about you address the operating voltage of *TTL* which was the subject of
discussion, not some CMOS process ?

I'm sure you will troll every place possible, AKA Poo Bear.

To the sci. groups, sorry for feeding the troll. I've been on the poo
wagon for several days!!!!!!!!

You're an idiot, you cretinous naysayer. Never a damn useful thing to say.

Graham

 

[MassiveProng]

On Sun, 11 Mar 2007 21:12:11 -0600, "nonsense@unsettled.com"
<nonsense@unsettled.com> Gave us:

You never managed to figure out that because something
is *A* standard doesn't mean that's all there is.

You're pathetic. SINCE we are talking about TTL, THAT IS the
standard we refer to, dipshit.

IF we were talking about a 600Volt IGBT it would be different, you
retarded fuck. You could never be one of us.

 

[MassiveProng]

On Mon, 12 Mar 2007 05:38:28 GMT, Dan Bloomquist
<public21@lakeweb.com> Gave us:

Eeyore wrote:


So Mr Expert. Why isn't TTL made on a 40 Volt process ?

Gee donkey ass. There are open collector devices. Gee DA, I work at 3.3
volts, not 5. Gee DA, what about mixed signal?. Do you really want to go
there?

I'm sure you will troll every place possible, AKA Poo Bear.

To the sci. groups, sorry for feeding the troll. I've been on the poo
wagon for several days!!!!!!!!

Note that TTL was the requisite defining element. That rules out
"mixed signal" TTL is digital. Did you miss something, like READING
THE FUCKING THREAD?

 

In article <90cd3$45f42b40$4fe74eb$3027@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:

Ken Smith wrote:

In article <et0nu2$8qk_001@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:

In article <esuq2s$ds3$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

[....]

has run on 5V. The selection of 5V can be traced in part to the heater
voltage on tubes.

Now think about that over time.


Suddenly, you are arguing exactly my case and agreeing with me but putting
the above as a preface to it. This is a very strange thing for you to be
doing. I was the one arguing that a lot of choice are the result of
considerations that appeared trivial or near coin tosses at the time that
ended up having a large effect later. I used the 5V logic case because I
thought it was an obvious and well known example. From the fact that I
got an argument on it, I see that it is less well known than I thought.

There are lots of well believed urban legends.

You have noted that he stripped my post to make it appear that
I was agreeing with his factoid. I was talking about something
completely different.

/BAH

 

In article <et18sk$ki3$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <et0nu2$8qk_001@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esuq2s$ds3$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
has run on 5V. The selection of 5V can be traced in part to the heater
voltage on tubes.

Now think about that over time.

Suddenly, you are arguing exactly my case and agreeing with me but putting
the above as a preface to it.

I wasn't agreeing to anything. By stripping the post to make it
appear that I was talking about a 5V factoid is blatant intellectual
dishonesty.

<snip>

/BAH

 

In article <et1957$ki3$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <et0oi0$8qk_003@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esuqfn$ds3$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
No, you are making the same mistake over and over. As I stated before, if
you know what you are going to put into TAPE.DIR, you can make its
checksum correct. No editing of a magnetic tape was needed by the method.

Then that TAPE.DIR was not made by taking a directory of the
tape. That was not the purpose of the file. If I had to do
it the way you suggested, I wouldn't put the file on the tape
since it would be a waste of tape space.

So now you are suddenly changing your story and saying that editing of the
tape was done.

There was no tape editing done.

You really need to go back and reread what I've suggested.
I have pointed out that you could have gotten the correct checksum if you
had just thought for a minute.

It is impossible.

[....]
I have tried to explain how but you just don't seem to be able to
understand the issue.

It is you who do not understand the purpose of the file. It is
made by taking a physical directory of the magtape and never
touched by human hands. The last was THE requirement.

I never suggested that the directory had to be touched by human hands.
You have made claims of being a developer. If you retract that claim then
perhaps we can say that you did the best you could do. If you don't
retract, you then have to admit that you could have shipped correct tapes
but didn't.

I shipped correct tapes. I never allowed corrected tapes to be shipped.

/BAH

 

In article <et1a4q$ki3$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <et0qsp$8qk_002@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esurfc$ds3$6@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esu74a$8qk_001@s861.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esrtcj$qj4$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
In other words, you wrote the TAPE.DIR after all the other files were
written. This means you had to write a file of that size and then the
data and then open TAPE.DIR for writing.

If this is what you did then my method of putting a correct checksum
still
works. If you wrote the TAPE.DIR before the other files and never
changed
it, my method still works.


[....]
Anybody who has done any grocery shopping would know the difference
between the two. Just because dog food is on your shopping list
never guarantees that dog food will be in your car when you get home.
The only listing that shows you were successful in putting
dog food in the shopping cart is the cash register receipt.

Does this mean you wrote TAPE.DIR after the other files were all written?

Yes. TAPE.DIR was created after the files were written to the tape.
That is how you get a directory listing of the tape onto the tape.

The first cut of the tape had a zero block TAPE.DIR for a place holder
on the tape. Then a DIRECT DSK:TAPE.DIR=TAPE:/CHECKSUM was done.
Then another save was done; this time TAPE.DIR that was on the
tape contained a checksummed directory of the tape.

In other words, you "editted" the tape.

No.

How yes you did. You did exactly the action called editing when speaking
of a tape.

We don't call saving a saveset editing.

You wrote one file and then wrote
something different in its place.

No. I wrote the whole save set. In magtape terms, the saveset
was the file on the tape.

Now what the heck are you claiming?

I'm still talking about the same thing.

I know you've explained ad nauseum. You keep ignoring the point
of the file. IOW, you implemented something that wasn't in the spec.
In fact, your implementation is 100% contrary to the spec.

You seem to keep not being able to understand it, or the spec said "do it
wrong".

Kid, I wrote the spec. I know what the goals were; I know what
was possible and what wasn't possible.

[....]
As I explained, the claim that it can't be correct it wrong. The method I
explained makes it correct. There is no problem.

But you don't fulfill the requirement that the file is a
directory of the tape, untouched by editing hands.

Yes, I do. At least if you are as you claimed earlier in the development
team.

Go do the exercise. You will see you cannot put a checksummed
directory of the tape onto the tape and have the checksum of
TAPE.DIR match the checksum of TAPE.DIR that is listed in
TAPE.DIR.

[....]
You don't seem to be able to understand the idea so yes, I guess you would
punt the idea. leaving the tape incorrect and your customers at an extra
risk.

Nobody assembled the file called TAPE.DIR. It listed the files
that were on the tape when we made the master.

You earlier stated a command you typed to make the file. Are you a
noone??????

Then that file was saved along with all the other files onto the tape.


<snip>

/BAH

 

In article <et15r5$h35$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <et0umt$8qk_018@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esuppf$ds3$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[.....]
In my house there is a network that links two fast machines. These are
linked to the internet by a single high speed pathway. At some future
time, my house may have more than one path to the rest of the world. When
the city puts in its 802.11 system, it will start to make sense for my
computer to start to choose between the two paths for my packets. This
puts routing inside my house.

Sure. If you have an sense of self-preservation, your router is
going to be seperated from your user machines. All homes
will have their own server which will not be on the same hardware
as their data.

I doubt this is where it will end up. The router software will just be
another task in the home machine. The code for doing rounting doesn't put
the user's data at risk. The firewall is the place where the danger is if
at all.

That would be a cheap and dangerous configuration.

/BAH

 

[nonsense@unsettled.com]

jmfbahciv@aol.com wrote:

In article <90cd3$45f42b40$4fe74eb$3027@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:

Ken Smith wrote:


In article <et0nu2$8qk_001@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:


In article <esuq2s$ds3$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

[....]


has run on 5V. The selection of 5V can be traced in part to the heater
voltage on tubes.

Now think about that over time.


Suddenly, you are arguing exactly my case and agreeing with me but putting
the above as a preface to it. This is a very strange thing for you to be
doing. I was the one arguing that a lot of choice are the result of
considerations that appeared trivial or near coin tosses at the time that
ended up having a large effect later. I used the 5V logic case because I
thought it was an obvious and well known example. From the fact that I
got an argument on it, I see that it is less well known than I thought.

There are lots of well believed urban legends.


You have noted that he stripped my post to make it appear that
I was agreeing with his factoid. I was talking about something
completely different.

Happens all the time.

These are the people who when asked "What is pi" will argue to
death that it is 3.14.

# the ratio of the circumference to the diameter of a circle;
approximately equal to 3.14159265358979323846...
# private detective: someone who can be employed as a detective to
collect information
# principal investigator: the scientist in charge of an experiment or
research project
# the 16th letter of the Greek alphabet
# protease inhibitor: an antiviral drug used against HIV; interrupts HIV
replication by binding and blocking HIV protease; often used in
combination with other drugs

wordnet.princeton.edu/perl/webwn

 

[nonsense@unsettled.com]

jmfbahciv@aol.com wrote:

In article <et15r5$h35$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <et0umt$8qk_018@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:

In article <esuppf$ds3$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

[.....]

In my house there is a network that links two fast machines. These are
linked to the internet by a single high speed pathway. At some future
time, my house may have more than one path to the rest of the world. When
the city puts in its 802.11 system, it will start to make sense for my
computer to start to choose between the two paths for my packets. This
puts routing inside my house.

Sure. If you have an sense of self-preservation, your router is
going to be seperated from your user machines. All homes
will have their own server which will not be on the same hardware
as their data.

I doubt this is where it will end up. The router software will just be
another task in the home machine. The code for doing rounting doesn't put
the user's data at risk. The firewall is the place where the danger is if
at all.


That would be a cheap and dangerous configuration.

Fine for a purely hobby machine. Folks are making serious use of
home machines these days, including doing their own finances on
a machine they connect to the internet. Some of them leave that
machine connected 24/7.

I keep a separate machine for such stuff.

 

[Ken Smith]

In article <et3a41$8qk_002@s948.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <et15r5$h35$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et0umt$8qk_018@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esuppf$ds3$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[.....]
In my house there is a network that links two fast machines. These are
linked to the internet by a single high speed pathway. At some future
time, my house may have more than one path to the rest of the world. When
the city puts in its 802.11 system, it will start to make sense for my
computer to start to choose between the two paths for my packets. This
puts routing inside my house.

Sure. If you have an sense of self-preservation, your router is
going to be seperated from your user machines. All homes
will have their own server which will not be on the same hardware
as their data.

I doubt this is where it will end up. The router software will just be
another task in the home machine. The code for doing rounting doesn't put
the user's data at risk. The firewall is the place where the danger is if
at all.

That would be a cheap and dangerous configuration.

There need not be any increase in the risk. Its all a matter of starting
with a reasonable OS and not adding buffer over runs.

--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <5b9a2$45f55682$4fe7735$10616@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:

jmfbahciv@aol.com wrote:

In article <et15r5$h35$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <et0umt$8qk_018@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:

In article <esuppf$ds3$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

[.....]

In my house there is a network that links two fast machines. These are
linked to the internet by a single high speed pathway. At some future
time, my house may have more than one path to the rest of the world. When
the city puts in its 802.11 system, it will start to make sense for my
computer to start to choose between the two paths for my packets. This
puts routing inside my house.

Sure. If you have an sense of self-preservation, your router is
going to be seperated from your user machines. All homes
will have their own server which will not be on the same hardware
as their data.

I doubt this is where it will end up. The router software will just be
another task in the home machine. The code for doing rounting doesn't put
the user's data at risk. The firewall is the place where the danger is if
at all.


That would be a cheap and dangerous configuration.

Fine for a purely hobby machine. Folks are making serious use of
home machines these days, including doing their own finances on
a machine they connect to the internet. Some of them leave that
machine connected 24/7.

I keep a separate machine for such stuff.

Keeping important information on a Windows machine puts it at risk.
Remember that very strange virus that modulated the data onto the horz.
rate of the video. Even not being connected to the network is not enough.

--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <45F4CF7A.BD6428AD@hotmail.com>,
Eeyore <rabbitsfriendsandrelations@hotmail.com> wrote:
[....]

So Mr Expert. Why isn't TTL made on a 40 Volt process ?

Thats obvious. Its so there is a market for MOSFET drivers. I still want
a PIC made with Supertex's HV CMOS.



--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <et39an$8ss_001@s948.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <90cd3$45f42b40$4fe74eb$3027@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:
[......]
Now think about that over time.


Suddenly, you are arguing exactly my case and agreeing with me but putting
the above as a preface to it. This is a very strange thing for you to be
doing. I was the one arguing that a lot of choice are the result of
considerations that appeared trivial or near coin tosses at the time that
ended up having a large effect later. I used the 5V logic case because I
thought it was an obvious and well known example. From the fact that I
got an argument on it, I see that it is less well known than I thought.

There are lots of well believed urban legends.

You have noted that he stripped my post to make it appear that
I was agreeing with his factoid. I was talking about something
completely different.

I did nothing of the sort. I just took the only part of your post that
said something interesting on the topic and pointed out that you weren't
saying anything that contradicted me.

/BAH

--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <et39ee$8ss_002@s948.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <et18sk$ki3$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et0nu2$8qk_001@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esuq2s$ds3$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
has run on 5V. The selection of 5V can be traced in part to the heater
voltage on tubes.

Now think about that over time.

Suddenly, you are arguing exactly my case and agreeing with me but putting
the above as a preface to it.

I wasn't agreeing to anything. By stripping the post to make it
appear that I was talking about a 5V factoid is blatant intellectual
dishonesty.

No, it was nothing of the sort. It was taking a section of what you said
without changing its meaning and pointing out that you had said "now think
about" in front of statements by you that agreed what what I had earlier
said.

You followed this with some other stuff that was so old hat it didn't need
a reply. We have beaten to death the topic of being compatible with the
installed base.


--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <et39hp$8ss_003@s948.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <et1957$ki3$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et0oi0$8qk_003@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esuqfn$ds3$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
No, you are making the same mistake over and over. As I stated before, if
you know what you are going to put into TAPE.DIR, you can make its
checksum correct. No editing of a magnetic tape was needed by the method.

Then that TAPE.DIR was not made by taking a directory of the
tape. That was not the purpose of the file. If I had to do
it the way you suggested, I wouldn't put the file on the tape
since it would be a waste of tape space.

So now you are suddenly changing your story and saying that editing of the
tape was done.

There was no tape editing done.

In that case. The tape had to be written with the TAPE.DIR in place and
correct on the first pass. This contradicts earlier statements by you
where you said this could not be the method.

You have said that the TAPE.DIR must list what is actually on the tape and
not what you intend to put onto the tape. You can only find out what you
have put on the tape by reading it after you have written it. The only
way that you can write the TAPE.DIR at the start of the tape is to then do
an operation that is called "editing".

You are contradicting yourself.

You really need to go back and reread what I've suggested.
I have pointed out that you could have gotten the correct checksum if you
had just thought for a minute.

It is impossible.

No, it isn't. You haven't understood the main point.

I have explained how a file can contain its own checksum without error.
You need to go back and read it and think.


[....]

I never suggested that the directory had to be touched by human hands.
You have made claims of being a developer. If you retract that claim then
perhaps we can say that you did the best you could do. If you don't
retract, you then have to admit that you could have shipped correct tapes
but didn't.

I shipped correct tapes. I never allowed corrected tapes to be shipped.

No, you shipped ones where the checksum was reported incorrectly. I have
shown that there was no need to do this, no matter which way you made
these tapes. At this point I have explained it for every posible
procedure for producing the tape.


--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <et39vo$8qk_001@s948.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <et1a4q$ki3$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et0qsp$8qk_002@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esurfc$ds3$6@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esu74a$8qk_001@s861.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esrtcj$qj4$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
In other words, you wrote the TAPE.DIR after all the other files were
written. This means you had to write a file of that size and then the
data and then open TAPE.DIR for writing.

If this is what you did then my method of putting a correct checksum
still
works. If you wrote the TAPE.DIR before the other files and never
changed
it, my method still works.


[....]
Anybody who has done any grocery shopping would know the difference
between the two. Just because dog food is on your shopping list
never guarantees that dog food will be in your car when you get home.
The only listing that shows you were successful in putting
dog food in the shopping cart is the cash register receipt.

Does this mean you wrote TAPE.DIR after the other files were all written?

Yes. TAPE.DIR was created after the files were written to the tape.
That is how you get a directory listing of the tape onto the tape.

The first cut of the tape had a zero block TAPE.DIR for a place holder
on the tape. Then a DIRECT DSK:TAPE.DIR=TAPE:/CHECKSUM was done.
Then another save was done; this time TAPE.DIR that was on the
tape contained a checksummed directory of the tape.

In other words, you "editted" the tape.

No.

How yes you did. You did exactly the action called editing when speaking
of a tape.

We don't call saving a saveset editing.

Did you write a TAPE.DIR onto the tape after the tape had already been
written?

If the answer is yes, you edited the tape. In this case the method works.

If the answer is no then you can no longer argue that the TAPE.DIR is the
list of what is actually on the tape. It must be the list of what you
intend to put on the tape. You have claimed that this is not allowed, but
the method still works for this too.

No matter which you did, the checksums can be correct.

You wrote one file and then wrote
something different in its place.

No. I wrote the whole save set. In magtape terms, the saveset
was the file on the tape.

Now what the heck are you claiming?

I'm still talking about the same thing.

You have changed what you have claimed. Suddenly, the TAPE.DIR is not a
file on the tape and is a part of the contents of a file on the tape, or
you have merely added a confusion factor. The TAPE.DIR file could still
have the correct checksum not matter which so the point doesn't really
matter to the argument.

You have missed the core question about making the checksum correct.

I know you've explained ad nauseum. You keep ignoring the point
of the file. IOW, you implemented something that wasn't in the spec.
In fact, your implementation is 100% contrary to the spec.

You seem to keep not being able to understand it, or the spec said "do it
wrong".

Kid, I wrote the spec. I know what the goals were; I know what
was possible and what wasn't possible.

It appears you don't you still haven't understood that you could have, no
matter what the requirements were, sent tapes with correct checksums and
still met the specs.

We have covered every case except doing it all with a write reverse. I
will state for the record that if you had to use a write reverse to do the
write, you still could have gotten the checksum right.

But you don't fulfill the requirement that the file is a
directory of the tape, untouched by editing hands.

Yes, I do. At least if you are as you claimed earlier in the development
team.

Go do the exercise. You will see you cannot put a checksummed
directory of the tape onto the tape and have the checksum of
TAPE.DIR match the checksum of TAPE.DIR that is listed in
TAPE.DIR.

I see that I can and have done exactly that in the past. I have explained
how to do it a few times. You seem unable to graps it. I've used it.
Remember I have written tapes too.

[....]

Then that file was saved along with all the other files onto the tape.

Wait a minute! Suddenly TAPE.DIR is the list of what you intend to write
onto the tape. Your story has changed. You earlier asserted that it must
be made from what you actually wrote. Which is it?

Not that it matter which it was because as I have already stated, I have
explained how you can get it right in either case.

--
--
kensmith@rahul.net forging knowledge

 

[Dan Bloomquist]

MassiveProng wrote:

Note that TTL was the requisite defining element.

No, it is, 'Jihad needs scientists'

 

[Eeyore]

"nonsense@unsettled.com" wrote:

Dan Bloomquist wrote:

MassiveProng wrote:

Note that TTL was the requisite defining element.

Actually "the reason TTL was designed for 5 volts BCC"
was the requisite defining element. As usual, when
beaten to a logical pulp, one side attempted to shift
the goalposts.

It was nothing to do with 6.3 V AC either.

Graham