From: MassiveProng on
On Sat, 17 Mar 07 10:02:21 GMT, jmfbahciv(a)aol.com Gave us:

>In article <b29c6$45faa09e$49ecf4e$12726(a)DIALUPUSA.NET>,
> "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote:
><snip>
>
>>Note to BAH. Neither krw nor I can make a silk purse
>>out of MP's stuff. I'm going to stop responding to
>>him now as there's no advance possible.
>
>Yea, I gave up a couple weeks' ago. His posts can't even
>be used to speak through him.
>

Pretty funny since I hit you with the silk purse joke several weeks
ago.

Nonsense is just a retard that never posts anything of ANY
substance, and always has some lame remark to spew.
Your buddy unlearned is the same.

Oh, wait! They ARE the same... One and the same retard, that is.
From: krw on
In article <dpmmv256n8uv2aj0ou8u47f9o7fuillsdn(a)4ax.com>,
MassiveProng(a)thebarattheendoftheuniverse.org says...
> On Fri, 16 Mar 2007 09:40:32 -0400, krw <krw(a)att.bizzzz> Gave us:
>
> >In article <87hcslhfqz.fsf(a)nonospaz.fatphil.org>,
> >thefatphil_demunged(a)yahoo.co.uk says...
> >> "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> writes:
> >> > Phil Carmody wrote:
> >> > > krw <krw(a)att.bizzzz> writes:
> >> > >>>> MassivelyWrong once again, Dimbulb. I was a member of the Apple
> >> > >>>> CPU development team (Nintendo PPC750 processor variants as well)
> >> > >>>> until Apple switched to x86.
> >> > >>>
> >> > >>>Hmmm, why were Apple buying G4s from us at Freescale if they
> >> > >>>made their own?
> >> > >>
> >> > >>Apple made none, idiot.
> >> > > Why were apply buying G4s from us at Freescale if they designed
> >> > > their own?
> >> > > If you have more than 1/4 of a brain you might be able to predict
> >> > > that I will probably narrow down the work you did "on" the G4 to be
> >> > > "filled in forms and bought them from Freescale".
> >> >
> >> > People with real lives don't have time for that sort of nonsense,
> >> > but we can easily understand why you do.
> >>
> >> I notice you don't doubt my conclusion. I notice that krw doesn't
> >> counter my conclusion either.
> >
> >Neither you nor your sister, Dimmie, are worth "countering".
> >
> >> I hope he found his form-filling fulfilling.
> >
> >You're so far off (with everything you've said so far) that you
> >haven't even hit the right side of the continent.
>
>
> He sure whopped you right upside da head tho.

Poor clueless Dimulb and his pet pantywaist Phil.

> You... designed processors... SURE!

I was a member of one of the PowerPC processor development teams
(Apple/Nintendo processors, mainly) for seven years, sure. Jealous?

> Bwuahahahahahahahaha!

You really should get that growth looked at, Dimbulb. It makes you
look silly.

--
Keith
From: The Ghost In The Machine on
In sci.physics, krw
<krw(a)att.bizzzz>
wrote
on Tue, 13 Mar 2007 13:38:46 -0400
<MPG.206087082a3344ee98a0ff(a)news.individual.net>:
> In article <t5khc4-tr.ln1(a)sirius.tg00suus7038.net>,
> ewill(a)sirius.tg00suus7038.net says...
>> In sci.physics, MassiveProng
>> <MassiveProng(a)thebarattheendoftheuniverse.org>
>> wrote
>> on Mon, 12 Mar 2007 16:52:21 -0700
>> <3mpbv2h1ts0jed1imfmdt5h52ukk3bcskj(a)4ax.com>:
>> > On Mon, 12 Mar 2007 14:34:47 +0000 (UTC), kensmith(a)green.rahul.net
>> > (Ken Smith) Gave us:
>> >
>> >>In article <45F4CF7A.BD6428AD(a)hotmail.com>,
>> >>Eeyore <rabbitsfriendsandrelations(a)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.
>> >>
>> >
>> >
>> > Tell us, oh masterTARD, what would the maximum clock be on a 40 volt
>> > logic swing.
>> >
>> > Do you even know what slew rate is?
>> >
>> > The reason it was 5 volts is because it was a reasonable voltage
>> > that could be slewed to at a decent rate.
>> >
>> > NOW, we are at 3.3 volts and even 1.2V. The reason is slew rate,
>> > and the fact that we can transition much faster at those swings than
>> > we ever could at 5V.
>> >
>> > There would be no GHz+ Pentiums if we were still at 5 Volt logic
>> > levels.
>> >
>> > Getteth thyself a clue.
>>
>> Well, I for one was under the opinion that the reason E
>> = 1.2V is because P = E^2/R and also proportional to the
>> switching frequency of the transistors (since each switch
>> requires a small pulse of current; the more pulses, the
>> higher the power required to switch), and also proportional
>> to the total transistor area, which AFAIK has been largely
>> constant even as we pack more transistors per die.
>
> Dynamic power is proportional to CFV^2 (R doesn't figure into the
> equation given that the circuit switches). You're missing static
> power though. Static power (leakage) gets significant with smaller
> geometries.

It might at that. I've been out of the biz for awhile; my speciality
now is Java / web programming. :-)

>
>> Assuming one can run a chip at both 1.2V and 5V at the
>> same clock rate, the 5V running will run far hotter --
>> about 17.4 x more power, in fact.
>
> At the same clock, yes (5^2/1.2^2).
>
>> Then again, there's a fair number of factors here, not the
>> least of which is process control. :-) A chip, like an
>> airplane, is a bunch of compromises, one of them being
>> clock speed versus power dissipation.
>
> Logic delay vs. power dissipation, really.

True.

> Clock speed gets into
> microarchitectural issues as well. For example, a P4 will run at a
> higher clock speed than a P3 in the same technology. The P3 will
> likely outperform it at the same power though.
>
>> The x86 series
>> is an excellent example of a total bodge-up because
>> it compromised so many things (for example, it's still
>> source-code compatible with the 8080A and probably with
>> the Z80 as well!).
>
> Source code compatibility means nothing here.

I'll admit I wonder how much it meant even back then.

>
>> But it still works.
>>
>> Now, assuming anyone wants an HV CMOS 40V logic swing, I
>> for one would think that the best method of achieving such
>> is through a 1.2V-to-40V swing converter, which presumably
>> would be a carefully-adjusted standard CMOS transistor-pair
>> inverter which flips at about 0.6 volts to ground. The rest
>> of the circuitry can run at 1.2 V without trouble.
>
> Not sure why you'd want 40V, but you're not going to get it on the
> same hunk of silicon.

True; I was thinking more along the lines of another chip nearby.
The only reason I'd want ~40V is because of phone specifications
still requiring it -- which stipulate 48V, IINM. Otherwise, it's
mostly a question of which chips want what when, given certain
constraints such as input power, chip speed, etc.

>
>> If necessary the level shifter can feed another, more standard inverter.
>>
>> There might be better solutions; it's been a long time since I've been
>> anywhere near semiconductor designs, and I only really worked with
>> slow-speed digital stuff at most.
>


--
#191, ewill3(a)earthlink.net
Linux sucks efficiently, but Windows just blows around
a lot of hot air and vapor.

--
Posted via a free Usenet account from http://www.teranews.com

From: jmfbahciv on
In article <eteabl$ecf$1(a)blue.rahul.net>,
kensmith(a)green.rahul.net (Ken Smith) wrote:
>In article <ete2pi$8qk_001(a)s986.apx1.sbo.ma.dialup.rcn.com>,
> <jmfbahciv(a)aol.com> wrote:
>>In article <etbicr$3ko$1(a)blue.rahul.net>,
>> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>>In article <etb9rf$8ss_002(a)s881.apx1.sbo.ma.dialup.rcn.com>,
>>> <jmfbahciv(a)aol.com> wrote:
>>>>In article <et8v9c$6oi$1(a)blue.rahul.net>,
>>>> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>>>>In article <et8hie$8ss_001(a)s787.apx1.sbo.ma.dialup.rcn.com>,
>>>>> <jmfbahciv(a)aol.com> wrote:
>>>>>>In article <et6c0m$t53$7(a)blue.rahul.net>,
>>>>>> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>>>>>>In article <et5un4$8ss_002(a)s887.apx1.sbo.ma.dialup.rcn.com>,
>>>>>>> <jmfbahciv(a)aol.com> wrote:
>>>>>>>>In article <et3pbr$rad$7(a)blue.rahul.net>,
>>>>>>>> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>>>>>>>>In article <et39hp$8ss_003(a)s948.apx1.sbo.ma.dialup.rcn.com>,
>>>>>>>>> <jmfbahciv(a)aol.com> wrote:
>>>>>>>>>>In article <et1957$ki3$2(a)blue.rahul.net>,
>>>>>>>>>> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>>>>>>>>>>In article <et0oi0$8qk_003(a)s776.apx1.sbo.ma.dialup.rcn.com>,
>>>>>>>>>>> <jmfbahciv(a)aol.com> wrote:
>>>>>>>>>>>>In article <esuqfn$ds3$5(a)blue.rahul.net>,
>>>>>>>>>>>> kensmith(a)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 is the point. It will never be "correct" because the file
>>>>>>>>contains a checksummed listing of itself.
>>>>>>>>
>>>>>>>><snip>
>>>>>>>>
>>>>>>>>Do the exercise. Then you will see what I'm talking about.
>>>>>>>
>>>>>>>Bin thar, dun that, got t-shirt, wore out t-shirt.
>>>>>>>
>>>>>>>I've done it. The idea wasn't new when I did. You just haven't
>>>>>>>understood a very simple concept.
>>>>>>
>>>>>>I understood you just fine. You didn't put a directory of the
>>>>>>tape onto the tape.
>>>>>
>>>>>That *proves* you didn't understand. I have explained how to make the
the
>>>>>directory have correct checksum no matter how you actually want to do it.

>>>>>You seem to constantly fail to understand that you can creat a file that
>>>>>has its own correct checksum. It has been done many times on many tapes
>>>>>and on many disks.
>>>>
>>>>The file you put on the tape did not contain a directory of the
>>>>tape. It was an edited file that you think may match the tape.
>>>
>>>Now at least you seem to perhaps have started to get a slight glimmer of
>>>understanding.
>>>
>>>I was not suggesting a file that was manually edited. You have claimed to
>>>be a developer so this part should have been obvious, but now lets
>>>discuss this file you put on tape. It is also not a directory of the
>>>tape. It was not made from the tape.
>>
>>My method did do this.
>
>Once again you've just changed your story. You claim that the TAPE.DIR
>was and was not made from the tape.

That is true. That was the recursive problem I had to solve.

> Back and forth go your claims.
>Until you settle on one story, there is very little point in continuing
>the discussion because at this point, I have ealready shown that in either
>case the checksum could have been correct.

You still do not understand the problem nor the spec requirements.
>
>
>>
>>> It was made from what you intended
>>>to write onto the tape.
>>
>>Nope.
>>
>>>You wrote this file onto the tape before you
>>>wrote the files it claimed were there. Unless you then checked the tape
>>>to make sure that all the files you claimed to have written were actually
>>>there,
>>
>>Of course this happened. In fact, there was always a bit by bit
>>compare to ensure that the tape nor the drive had a fault while
>>writing the tape.
>
>So you checked after the fact that the tape was correct. At least we have
>that part of the story straight now.

That was always a requirement. For the life of me I cannot remember
the command; it's been bugging me for three days. I guess I'll have
resort to RingTFM.
>
>
>>> this file you wrote could not be said to be a correct directory of
>>>the tape.
>>
>>But it was. That's what you aren't understanding.
>
>No, I think you aren't understanding. You claim that it is a directory of
>what was actually written onto the tape. This is not what it really is.

But it was.

>It is really a file of what you intended to write onto the tape. Only
>after you make the file did you actually write the tape.

Acutally, I had the tape written three times. Two would have
been sufficient but that would have had the item within TAPE.DIR
that listed TAPE.DIR to have a checksum of 000000. I figured
that customers would write a SPR about that so I "solved" the
mess prevention possibility by doing the save procedures of
the tape three times.
>
>This makes it exactly the sort of thing I suggested you were doing and you
>you objected to so strongly way back earlier in this thread.

You still do not understand the situation.
>
>
>>> The method I suggested way back at the start involved exactly
>>>this sort of check to make sure that the file I was suggesting was also a
>>>true and correct directory.
>>
>>The only thing your method did was to make the checksum of
>>the line that listed TAPE.DIR match the file TAPE.DIR if
>>a user ever did a checksummed DIR TAPE.DIR/CHECK on the
>>disk after he restored it.
>
>No, what I suggested made the checksum stated for TAPE.DIR the correct
>checksum of TAPE.DIR and have this correct checksum in TAPE.DIR on the
>tape. Nothing forbids the checking of the checksums on the tape without
>doing a restore.

Your procedure required human hands. That was a non-goal.
>
>
>
>>By making this nubmer correct, you invalidated all the rest
>>of the tape.
>
>
>That is complete and total nonsense.

You edited the tape directly. You can no longer have any confidence
that the tape is still intact as it had been saved. Your procedure
would also take too long to complete. This also creates a high
probability that the tape is not a good master.

/BAH

From: Martin Brown on
On Mar 16, 2:55 pm, kensm...(a)green.rahul.net (Ken Smith) wrote:
> In article <1173976773.203668.217...(a)l75g2000hse.googlegroups.com>,
>
> Martin Brown <|||newspam...(a)nezumi.demon.co.uk> wrote:
>
> >Unhinged is wrong though - the problem is onlyselfreferential.
>
> I'm going to disagree with you slightly on this. Read the following
> statement carefully:
>
> This statement is incorrect.
>
> Now imagine BAH saying "the statement is incorrectso therefor it
> must be correct so it must be incorrect ......." and so on in a higher and
> higher voice and then exploding like always happens in bad scifi. This I
> think you would agree makes the situation a problem with recursion.

Yes. But it is an avoidable recursion. It only recurses if you are
dumb enough to let it.

The whole point here is that anyone with a half decent computer
science education should know exactly how to construct the TAPE.DIR
file so that the checksum/CRC is right first time (or at worst know
where to look it up).

"This statement is TRUE"

Is true and then there is no recursion. Problem solved.

The trouble for fuBAH is that generating a file containing a self
consistent checksum or CRC requires the use of a programming algorithm
(which instantly conflicts with her rabid Islamophobia). So either way
her head explodes.

> failure by BAH is in fact a problem with recursion in as much as she can't
> step outside the system.
>
> >(*) The decimal checksum of this ASCII sentence is exactly 05407
>
> >fuBAH, Unhinged and MassivelyWrong might like to check this assertion-
> >the text of the sentence starts with "(" and ends with "7"
>
> I'm sure BAH will object that you didn't write it onto tape with the
> checksum at the start. Unfortunatly, she can't get to WWW stuff.

Isn't some IOCCC stuff online for FTP ?

The self consistent file internal CRC generator program entry
omiokane.c was particularly amusing.

Regards,
Martin Brown