Ethan Grammatikidis wrote:
On Sat, 10 Oct 2009 04:15:59 +0800
W B Hacker wrote:
The only 'glue' needed was level-shifters - discrete transistors on my OSI
Challenger II, Motorola 1488 & 1489 diode-coupled-logic on everything up until
the 16XXX derivative of the 8250 was sucked into a 'bridge'
On Sat, 10 Oct 2009 04:15:59 +0800
W B Hacker wrote:
>
> The only 'glue' needed was level-shifters - discrete transistors on my OSI
> Challenger II, Motorola 1488 & 1489 diode-coupled-logic on everything up
> until
> the 16XXX derivative of the 8250 was sucked into a 'bridge' chipset.
>
I re
On Wed, 7 Oct 2009 08:24:47 +0200
Rodriguez Faszanatas wrote:
> > If you aren't trying to build a terminal, the marvell sheevaplug
> > works well
>
> That is the point. My employer is interestet in a "non-intel" terminal.
> And yeap you're right, the beagle isn't that nice.
>
I'm almost sure G
lu...@proxima.alt.za wrote:
wikipedia agrees with lucio on this point
http://en.wikipedia.org/wiki/Micro_Channel_architecture#Marketshare_issues
The majority within IBM never wanted into that part of the market in the first
place, as it was seen as cannibalizing not only 3XXX terminal sales, bu
> wikipedia agrees with lucio on this point
> http://en.wikipedia.org/wiki/Micro_Channel_architecture#Marketshare_issues
>
>> The majority within IBM never wanted into that part of the market in the
>> first
>> place, as it was seen as cannibalizing not only 3XXX terminal sales, but the
>> enti
erik quanstrom wrote:
lu...@proxima.alt.za wrote:
but by 1990 with microchannel &c. things were much more closed off.
i thought only one company ever really made microchannel,
and even they weren't terribly in earnest in the end,
except on non-PC things like RS6000.
IBM tried to recover contro
> lu...@proxima.alt.za wrote:
> >>> but by 1990 with microchannel &c. things were much more closed off.
> >> i thought only one company ever really made microchannel,
> >> and even they weren't terribly in earnest in the end,
> >> except on non-PC things like RS6000.
> >
> > IBM tried to recover c
lu...@proxima.alt.za wrote:
but by 1990 with microchannel &c. things were much more closed off.
i thought only one company ever really made microchannel,
and even they weren't terribly in earnest in the end,
except on non-PC things like RS6000.
IBM tried to recover control over the PC market b
>>but by 1990 with microchannel &c. things were much more closed off.
>
> i thought only one company ever really made microchannel,
> and even they weren't terribly in earnest in the end,
> except on non-PC things like RS6000.
IBM tried to recover control over the PC market by introducing MCA,
ba
I once worked for a telco who's exchanges where connected to their billing
machines
via a pair of IBM PS2 MCA machines, they also had one spare machine. I was
there in about
1997 and everyone very worried what might happen if they lost more than one of
these
machines.
The last I heard the large
On Thu Oct 8 16:43:50 EDT 2009, fors...@vitanuova.com wrote:
> >but by 1990 with microchannel &c. things were much more closed off.
>
> i thought only one company ever really made microchannel,
> and even they weren't terribly in earnest in the end,
> except on non-PC things like RS6000.
in the
>but by 1990 with microchannel &c. things were much more closed off.
i thought only one company ever really made microchannel,
and even they weren't terribly in earnest in the end,
except on non-PC things like RS6000.
> Thinking about it a bit more ... when systems become more and more
> closed, as x86 systems are becoming now, the field of innovation is
> reduced to what a single company can think of -- the monopoly
> provider, so to speak.
you're right "nobody wants to do that" is not a good argument.
but on
Thinking about it a bit more ... when systems become more and more
closed, as x86 systems are becoming now, the field of innovation is
reduced to what a single company can think of -- the monopoly
provider, so to speak.
When systems become more closed, you hear stuff like this: "The
percentage of
>> microcode for the Perkin-Elmer 3220 was fun and useful as well.
>
> that's interesting. i found this paper and am studying it. are there
> obvious advantages?
I think there were quite a few independent projects at different places
adding special-purpose instructions to accelerate particular al
> but writing
> microcode for the Perkin-Elmer 3220 was fun and useful as well.
that's interesting. i found this paper and am studying it. are there
obvious advantages?
http://delivery.acm.org/10.1145/81/802436/p67-roskos.pdf?key1=802436&key2=6946894521&coll=GUIDE&dl=GUIDE&CFID=55468637&CFTOK
In article <13426df10910061432y17cf8632ta09af4ffe2153...@mail.gmail.com> you
write:
>On Tue, Oct 6, 2009 at 2:15 PM, Aharon Robbins wrote:
>> I understand all your points, and many of them are good ones. But there
>> really are places where you don't want to go, and into the chipset
>> is one of
> Just like you wouldn't have wanted to redo the microcode
> in your Vax 11/750, even if you could have.
Speak for yourself. I don't know about the VAX, but writing
microcode for the Perkin-Elmer 3220 was fun and useful as well.
It was nicely integerated into Unix, so different processes
could ha
> If you aren't trying to build a terminal, the marvell sheevaplug
> works well
That is the point. My employer is interestet in a "non-intel" terminal.
And yeap you're right, the beagle isn't that nice.
ron minnich wrote:
On Tue, Oct 6, 2009 at 5:19 PM, Dave Eckhardt wrote:
For something "nobody would want to do", there sure are a
lot of hits for "pcs750.bin".
It's the difference between "nobody would want to do it" and "we don't
want you do it" ;-)
ron
To me, the 'meat' of the issue is
On Tue, Oct 6, 2009 at 5:19 PM, Dave Eckhardt wrote:
> For something "nobody would want to do", there sure are a
> lot of hits for "pcs750.bin".
It's the difference between "nobody would want to do it" and "we don't
want you do it" ;-)
ron
> i thought several universities did modify the microcode in
> various ways, to test some research ideas, or just to improve
> things.
As I understand it, on the 750 floating-point errors were
accidentally traps instead of faults, or the other way
around. DEC said "oops, well, we guess it's model
> >Just like you wouldn't have wanted to redo the microcode
> >in your Vax 11/750, even if you could have.
>
> i thought several universities did modify the microcode in various ways,
> to test some research ideas, or just to improve things.
like this one
http://portal.acm.org/citation.cf
On Tue, Oct 6, 2009 at 2:15 PM, Aharon Robbins wrote:
> I understand all your points, and many of them are good ones. But there
> really are places where you don't want to go, and into the chipset
> is one of them.
Not really the case. People do want to go there, so they can do
interesting thing
>Just like you wouldn't have wanted to redo the microcode
>in your Vax 11/750, even if you could have.
i thought several universities did modify the microcode in various ways,
to test some research ideas, or just to improve things.
In article <13426df10910061021g3b033abbia134769baee93...@mail.gmail.com> you
write:
>as bad as the ARM may be, it can't hold a candle to what the pentium has
>become:
>1. RISC CPU (undocumented) in the northbridge (MCH) running ThreadX
>2. RISC CPU in the Ethernet part running ThreadX
>3. Simple
ron minnich wrote:
On Tue, Oct 6, 2009 at 12:13 PM, Lyndon Nerenberg - VE6BBM/VE7TFX
wrote:
I don't think DEC deserves this branding. In my experience they were
one of the most open hardware companies around.
It was sad to watch the Alpha blow its early lead due to
internal politics. Get wi
On Tue, Oct 6, 2009 at 12:13 PM, Lyndon Nerenberg - VE6BBM/VE7TFX
wrote:
> I don't think DEC deserves this branding. In my experience they were
> one of the most open hardware companies around. Back when they were still
> DEC, of course.
You never dealt with Alpha maybe. The story is long and sa
> Varian Data, General Automation, SDS/XDS, DEC, Data General, Honeywell, CDC,
> GE
I don't think DEC deserves this branding. In my experience they were
one of the most open hardware companies around. Back when they were still
DEC, of course.
--lyndon
ron minnich wrote:
On Tue, Oct 6, 2009 at 11:16 AM, W B Hacker wrote:
Anyone know if the AMD environment is any more 'open'?
way, way, more open. same with via. They regularly contribute chipset
source code to coreboot. That's my measure.
I hadn't paid much attention to the ARM until the r
> Excuses are eerily the same, each time, almost without regard to the
> product family:
> "nobody else wants that"
> "we no longer release that information"
> etc. etc. etc.
intel has been good to me. perhaps i'm just
doing different things.
my experience with intel has been that if it's
not av
On Tue, Oct 6, 2009 at 11:16 AM, W B Hacker wrote:
>
> Anyone know if the AMD environment is any more 'open'?
way, way, more open. same with via. They regularly contribute chipset
source code to coreboot. That's my measure.
> I hadn't paid much attention to the ARM until the recent '2 GHz' blur
On Tue, Oct 6, 2009 at 11:06 AM, erik quanstrom wrote:
> the one that you didn't mention is the one that bothers me: smm mode.
> this has been around for a very long time. smm mode takes a special
> interrupt and takes over the cpu and runs some real-mode code. things
> like ps/2 emulation for
ron minnich wrote:
On Tue, Oct 6, 2009 at 9:55 AM, wrote:
The cortex-a8 arms are arm v7-a architecture. L2 page table
entries have changed format. The a8 includes trustzone, so
many registers have forked, producing a "secure" and a "nonsecure"
version of the register. The arm v7-a manual is
> as bad as the ARM may be, it can't hold a candle to what the pentium has
> become:
> 1. RISC CPU (undocumented) in the northbridge (MCH) running ThreadX
> 2. RISC CPU in the Ethernet part running ThreadX
> 3. Simple CPU in the southbridge (ICH) running, well, who knows. But
> the entire system w
On Tue, Oct 6, 2009 at 9:55 AM, wrote:
> The cortex-a8 arms are arm v7-a architecture. L2 page table
> entries have changed format. The a8 includes trustzone, so
> many registers have forked, producing a "secure" and a "nonsecure"
> version of the register. The arm v7-a manual is a 2,150-page
> the marvell sheevaplug
> works well
does that imply that there is a working port?
-Steve
The cortex-a8 arms are arm v7-a architecture. L2 page table
entries have changed format. The a8 includes trustzone, so
many registers have forked, producing a "secure" and a "nonsecure"
version of the register. The arm v7-a manual is a 2,150-page pdf
file and the omap35x SoC manual is a 3,500-pa
On Tue Oct 6 12:18:40 EDT 2009, ge...@plan9.bell-labs.com wrote:
> The beagleboard is somewhat painful. It has a cortex-a8 cpu,
> which is quite a bit more complex than older arms.
is there specific pain to the a8 arms, or is it just that
everything is a bit less tidy?
- erik
The beagleboard is somewhat painful. It has a cortex-a8 cpu,
which is quite a bit more complex than older arms. The lack of
built-in ethernet means that getting USB going is vital, but the
EHCI registers provoke access exceptions and the OTG registers
are like no USB interface we've ever seen bef
yeap, done. is there someone actively working on a port to the beagleboard?
just to eliminate duplicate work. i found ron's ts7200 which is a nice
starting
point.
On Mon, Oct 5, 2009 at 3:50 PM, erik quanstrom wrote:
> On Mon Oct 5 09:46:01 EDT 2009, rodri...@gmail.com wrote:
>
> > thanks erik,
On Mon Oct 5 09:46:01 EDT 2009, rodri...@gmail.com wrote:
> thanks erik,
> i had to update the 5* sources by hand. pull thought they are up to date.
>
> rod
you may also wish to apply the patch i posted to make the
comma operator work.
- erik
thanks erik,
i had to update the 5* sources by hand. pull thought they are up to date.
rod
On Mon, Oct 5, 2009 at 3:16 PM, erik quanstrom wrote:
> > Trying to build /sys/src/libip for the arm today, I found that mk was
> dying.
> >
> > /sys/include/ip.h:128 eipfmt.c:3 incomplete structure eleme
> Trying to build /sys/src/libip for the arm today, I found that mk was dying.
>
> /sys/include/ip.h:128 eipfmt.c:3 incomplete structure element: payload
>
> Is this a known problem?
i think you need to update your compiler source code and rebuild.
5c builds all the libraries for me.
- erik
Hi,
Trying to build /sys/src/libip for the arm today, I found that mk was dying.
/sys/include/ip.h:128 eipfmt.c:3 incomplete structure element: payload
Is this a known problem?
Rod
45 matches
Mail list logo
