From: Brian Inglis on
fOn 31 Mar 2007 15:52:19 -0700 in alt.folklore.computers, "Quadibloc"
<jsavard(a)ecn.ab.ca> wrote:

>David Kanter wrote:
>> On Mar 5, 5:20 am, "Quadibloc" <jsav...(a)ecn.ab.ca> wrote:
>
>> > Struggling with many opcode formats with which I was not completely
>> > satisfied in my imaginary architecture that built opcodes up from 16-
>> > bit elements, I note that an 18-bit basic element for an instruction
>> > solves the problems previously seen, by opening up large vistas of
>> > additional opcode space.
>>
>> Why is 18 bits any better than 32 bits?
>
>Well, 18 bits is less bits than 32 bits, but it's more bits than 16
>bits. So, if 16 bits aren't enough, jumping to 18 may get me what I
>want while using fewer transistors.
>
>However, further thought has led me to modify my page further, and add
>
>http://www.quadibloc.com/arch/per01.htm
>
>where I show it might be possible to build instructions out of units
>12 bits long, to economize on RAM, without giving much up. (Of course,
>the PDP-8, and more especially the FPP-12, could be cited as
>precedents here.)

OT followup: PDP-11/74 front panel http://www.ak6dn.com/stuff/1174.jpg

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
From: jmfbahciv on
In article <20070401100525.e3d02109.steveo(a)eircom.net>,
Steve O'Hara-Smith <steveo(a)eircom.net> wrote:
>On Sun, 01 Apr 2007 01:39:04 -0500
>Charles Richmond <frizzle(a)tx.rr.com> wrote:
>
>> CBFalconer wrote:
>> > Nick Maclaren wrote:
>> >> Morten Reistad <first(a)last.name> writes:
>> >>> Lastest pc press blurbs. Vista only runs around 80 of 150
>> >>> identified critical XP applications.
>> >> Hasta la vista?
>> >
>> > No, Vista hasta go sista.
>> >
>> It's just *another* Mi$uck mess... What can we expect???
>> This is their idea of innovation.
>
> Indeed, soon there will be new versions of the other 70 that will
>work on Vista but will not work on XP, 2000, ME, 9x and so forth. These new
>versions will have new features so the old versions won't reliably read
>files from the new versions thus forcing updates to the new versions and
>therefore Vista. This is a painfully familiar pattern that has been reused
>over and over again going back (at least) to the move to Windows versions
>of DOS software.
>

Has it been verified that Vista cannot read MS' older formats?

/BAH
From: jmfbahciv on
In article <f18113dsl8uj8eom3khl8180vk734vj9ei(a)4ax.com>,
Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote:
>fOn Sat, 31 Mar 07 12:29:26 GMT in alt.folklore.computers,
>jmfbahciv(a)aol.com wrote:
>
>>In article <mddejn6wjk5.fsf(a)panix5.panix.com>,
>> Rich Alderson <news(a)alderson.users.panix.com> wrote:
>>>jmfbahciv(a)aol.com writes:
>>>
>>>> In article <mddd52rx59j.fsf(a)panix5.panix.com>,
>>>> Rich Alderson <news(a)alderson.users.panix.com> wrote:
>>>
>>>>> They wanted 8-bit bytes and power-of-2 words, and nothing was going to
>>>>> change their minds about that.
>>>
>>>> Then customers would continue to buy -11s and move the boring grunt work
to
>>>> the -10s and their secretaries.
>>>
>>>I see that the point was completely missed, and
>>>there's no use in trying to fix it.
>>
>>It was not missed by me. Those people you talked to will continue
>>to have their minis bought for them. However, the infrastruture
>>that surrounded them would have computing needs beyond mini
>>capabilities. Thus, the _bosses_ of those people you talked to
>>would buy a -10 because 1. they were already doing business
>>with DEC and were pleased with the services; 2. it was easier
>>to stay with one supplier than introduce a brand new computer
>>culture 3. the -10 was "compatible" with the gear that those
>>people to whom you talked insisted on using.
>>
>>Now do you see?
>
>In the PDP-11 era Marketing seemed to consider 10s(/20s) suitable only
>for educational institutions, not for businesses.

Wrong. Note that the PDP-11 era was going strong when I was
hired by DEC, 1971, and is still going strong.

>
>1. Digital made no promises of better (hours of) service from the branch
>for 10s than 11s.
>
>2. The OS and third party software products were from different
>cultures, different products would have to be chosen, code would have to
>be rewritten, and data converted, regardless of which dissimilar
>architecture or vendor was chosen.
>
>3. Going from 8 bit characters to 7 or 6 bit was seen as a step
>backwards, even in an environment where only 7 bits mattered.

I have absolutely no idea what you are talking about.

>
>How your group saw business was one thing, how local field service and
>marketing saw business was another, and how businesses saw Digital thru
>their local reps was yet another.

Field service was doing just fine at that time. Bad service
complaints were rare and if they did exist, it got fixed.

/BAH

From: jmfbahciv on
In article <mv8113db7op5afc3p181q92gtsjbtg10mk(a)4ax.com>,
Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote:
>fOn 29 Mar 2007 22:10:41 -0700 in alt.folklore.computers, "Tarkin"
><Tarkin000(a)gmail.com> wrote:
>
>>On Mar 30, 3:46 am, CBFalconer <cbfalco...(a)yahoo.com> wrote:
>>> Nick Maclaren wrote:
>>>
>>> ... snip ...
>>>
>>> > No, but nor could the Z80 compete on industry-quality functionality
>>> > and reliability. I know quite a few people who used Z80s for that,
>>> > and they never really cut the mustard for mission-critical tasks
>>> > (despite being a factor of 10 or more cheaper).
>>>
>>> Nonsense. I had 8080 based communications systems that ran
>>> continuously (no restart) for 2 to 3 years, until brought down by a
>>> mains power failure.
>
>>8080 != Z80. ISTR reading from a few different
>>places that early Z80's were 'twitchy'; that's
>>also why there are 'undocumented' opcodes-
>>those opcodes did not work reliably until the kinks
>>were worked out of the (wafer production [?])
>>process.
>
>Nonsense. Undocumented opcodes tend to be a side effect of a particular
>implementation of an architecture: that implementation does this if you
>set those bits in an instruction. That's why they're undocumented: if
>they change the implementation, the side effects of setting those bits
>may produce a different result.

DEC documented all of its opcodes. Those that were not used
were documented as "Reserved for future use".
/BAH
From: jmfbahciv on
In article <ag9113lncbeo99n4smua1o6f2rq72cm0dk(a)4ax.com>,
Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote:
>On Sat, 31 Mar 07 11:41:25 GMT in alt.folklore.computers,
>jmfbahciv(a)aol.com wrote:
>
>>In article <1ptr03dlr4i094g32r3aflhsg8e12ing85(a)4ax.com>,
>> Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote:
>>>On Thu, 29 Mar 07 13:29:12 GMT in alt.folklore.computers,
>>>jmfbahciv(a)aol.com wrote:
>>>
>>>>In article <tl7n03h8uppujai6ck0ap794okqulb9i71(a)4ax.com>,
>>>> Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote:
>>>>>fOn Wed, 28 Mar 07 11:16:23 GMT in alt.folklore.computers,
>>>>>jmfbahciv(a)aol.com wrote:
>>>>>
>>>>>>In article <46099974$0$18859$4c368faf(a)roadrunner.com>,
>>>>>> Peter Flass <Peter_Flass(a)Yahoo.com> wrote:
>>>>>>>jmfbahciv(a)aol.com wrote:
>>>>>>>>
>>>>>>>> And I'm telling you, again, that DEC did not have the infrastructure
>>>>>>>> to handle that support. DEC's main business was not retail-ish.
>>>>>>>>
>>>>>>>
>>>>>>>Even IBM decided they didn't want to be in this business.
>>>>>>
>>>>>>I've spent quite a bit of my thinking time trying to figure out
>>>>>>how to do the single task of software support with 200 million
>>>>>>systems. I still don't have it. Micshit is trying by using the
>>>>>>internet and edictive practices. That's not working either.
>>>>>>
>>>>>>Number one rule is to not ship security holes and have a backout
>>>>>>plan when you do.
>>>>>>
>>>>>>I haven't thought of any way to do this. Micshit's answer is an
>>>>>>"as is" which was anathema to the manufacturers of the past.
>>>>>
>>>>>Ahem, manufacturers didn't do software support: they did production and
>>>>>maintenance.
>>>>
>>>><ahem> But DEC did do software support for the products it did
>>>>ship. This was part of our corporate folklore. It would ahve
>>>>been unthinkable to sell millions of _systems_ with no followup.
>>>>It simply was not in our blood to do this. If the customers
>>>>wanted us to leave them alone, we did. However, the reverse
>>>>was never true.
>>>>
>>>>>A few inhouse staff did the software support, complained to the
>>>>>manufacturer occasionally, mostly got some response, rarely got changes
>>>>>made, if it followed the strategic direction (on the mini products).
>>>>>The same model would have worked for personal workstations, with the
>>>>>customer being responsible for most support.
>>>>
>>>>That implies that all sources are shipped with the toy. You
>>>>people are talking about a product line that made acquiring sources
>>>>a miracle.
>>>
>>>DEC did not ship sources for their popular PDP-11 OSes,
>>
>>Since when?
>>
>>> we had to work
>>>with the documented system interfaces, but they were pretty good for
>>>most purposes.
>>>
>>>>>DEC FE supported their terminals
>>>>
>>>>Terminals did not run OSes. We knew how do hardware in that
>>>>number but not systems. Do you understand the difference
>>>>between a piece of gear and a _system_?
>>>
>>>Do you understnad the difference between supporting hundreds of
>>>mainframe systems on a few hardware bases and thousands of mini systems
>>>on a variety of hardware bases?
>>
>>Do you understand that support a PC base would have been giving
>>direct corporate support to each and every person who had accounts
>>on the mainframes? Not only would we have to "train" all users
>>to be sysadmins, but they would also have to be trained to be
>>field service, operator, systems analyst, etc.
>>
>>>IMHO the mini people really had to have had their ducks in a row to deal
>>>with the volume.
>>>Remember there were independent industry mags for at least some of the
>>>popular mini OSes.
>>
>>This has nothing to do with supporting the _systems_ that we sold.
>
>The distinction is that the customers supported the systems, and shared
>information thru industry mags: DEC supported the customers, via DEC and
>the customers' support staff.
>
>Your definition of systems includes only the DEC hardware and software:

You have an incorrect assumption.

>useful customer systems (typically) contained much more hardware and
>software than DEC provided or supported.

You do not know what you're talking about.
<snip>

/BAH