🚀 go-pugleaf

In article <396@ssc-bee.UUCP>, ditzel@ssc-bee.UUCP (Charles L Ditzel) writes:
> Does anyone know for a *fact* (as opposed to rumor) if anyone is working
> on porting os9 or some unixlike environment to the ST?

I know for a fact that Atari has a project to port Unix to the ST.
It's not very far along yet but it is real Unix.  Jack Tramiel is
negotiating with AT&T to hack back the arcane licensing requirements
so he can afford to sell it cheap and still make a profit.

> There has been a *rumor* drifting about (especially among sales people)
> that Atari is working on module for the ST that will snap into that side
> expansion slot.  The rumor continues that the module contains : 1) a full
> 32 bit National Semiconductor chip (NS320xx ?) that becomes the main
> processor (?) and 2) the 68000 thereafter is used for i/o only????  Anyone
> know if this is 1)possible and 2)if anything remotely close to this is 
> being worked on?

This is definitely possible but it would be stupid, I think.  If
they're going to a 32-bit CPU they should go 68020 since it would be
software compatible.  Also if they go to a 32-bit version, they should
let it handle the user interface because (if it's a 68020) it's 2-3
times as fast as the 68000.  (Today's buggy National chips are roughly
68000 speed +/- 30%, and their future ones don't touch the 68020.)  If
you let the big chip numbercrunch and leave the 68000 moving bits on
the screen, the user interface runs at the same old speed, and face it
guys, what percentage of the time do you crunch numbers versus moving
screen bits anyway?  If the 32-bit CPU did both, then both would run
quickly...

There is a company in Connecticut (CT. Microsystems?) that is seriously
considering porting OS9/68K to the ST.  I have not heard whether or not
a final decision has been made yet.

Atari has announced (at least informally; it was at an users group meeting
attended by some of their top executives) that they will be supporting
Unix in 5-6 months.

The 32-bit add on to the ST will attach to the 10 Megabit DMA channel
on the back of the ST.  The 68020 is under consideration for the system;
its main drawbacks are compatibility problems for system mode software
(and presumably price).

The "50,000 sales" number is supposedly the rough sales figure for ST's
worldwide as of 1-2 months ago.

dgc

In article <213@l5.uucp> gnu@l5.uucp (John Gilmore) writes:
>let it handle the user interface because (if it's a 68020) it's 2-3
>times as fast as the 68000.  (Today's buggy National chips are roughly
>68000 speed +/- 30%, and their future ones don't touch the 68020.)  If

Apparently John is unaware of the NS32332 which provides 3 times
the performance of the NS32032 putting it in the same ballpark as
the 68020.  It will be available in December 85 (Yes, this one is on
schedule!) and also has a leg up on the 68020 in its memory interface
because it supports currently available dynamic rams in nibble mode.
This becomes important when you get clock rates up around 15Mhz.

Cory Barker

PS. Yes, the 32000 series does have a few minor bugs left in current
revisions, however I would not refer to them as buggy.  The 68020 on
the other hand...

In article <1584@hammer.UUCP>, coryb@hammer.UUCP (Cory Barker) writes:
> In article <213@l5.uucp> gnu@l5.uucp (John Gilmore) writes:
> >let it handle the user interface because (if it's a 68020) it's 2-3
> >times as fast as the 68000.  (Today's buggy National chips are roughly
> >68000 speed +/- 30%, and their future ones don't touch the 68020.)  If
> 
> Apparently John is unaware of the NS32332 which provides 3 times
> the performance of the NS32032 putting it in the same ballpark as
> the 68020.  It will be available in December 85 (Yes, this one is on
> schedule!) and also has a leg up on the 68020 in its memory interface
> because it supports currently available dynamic rams in nibble mode.
> This becomes important when you get clock rates up around 15Mhz.
> 
> Cory Barker
> 
> PS. Yes, the 32000 series does have a few minor bugs left in current
> revisions, however I would not refer to them as buggy.  The 68020 on
> the other hand...

I must say that I find it quite hard to believe that NatSemi is already coming
out with the 32332 already, when they haven't even come out with the 32132
or the 32232 yet(Yes, these are actual scheduled components).

This argument is moot anyway for one reason.  The 68020 is considerably faster 
because the original 68000 is very bus bound, while the 20 is much less so. On
the other hand, the whole NS series has a prefetch queue etc. and so speed
differential between any of the components is much less.  Also, a memory cycle
on the NS series and the 68000 is 4 cycles, as opposed to the twenty, which is
3 for main memory, and 2 for the 256 byte queue.

Would you like anymore?

Scott Weisman
sdcsvax!sdcc7!ln63fcv
in beautiful la jolla

i'm not sure if i should disclaim, but i guess i will.
i don't feel any different now, guess i will just have to try again later.

In article <1584@hammer.UUCP>, coryb@hammer.UUCP (Cory Barker) writes:
>     Yes, the 32000 series does have a few minor bugs left in current
> revisions, however I would not refer to them as buggy.  The 68020 on
> the other hand...

(He must have left the ... because he didn't know the answer.  Here it is:)

Motorola tells me that the bug list on the 68010 is zip, null,
zero -- and after working with it for years, I believe it.  It's a
production chip.

After close to a year of work with 68020's, the last bug list I saw
(August) had three or four things, all minor, and I have every
confidence that these will be gone within a few months (if not
already).  None of these affects user code or compilers.

Let me hear you say the same things about National's chips...after canceling
a whole product line because they didn't work.



PS:  Not to run down National; they make great jellybean chips, and their
PALs are OK.

> I must say that I find it quite hard to believe that NatSemi is already coming
> out with the 32332 already, when they haven't even come out with the 32132
> or the 32232 yet(Yes, these are actual scheduled components).

Last I heard, the 32232 was no longer a real part, and the 32132 is a minor
upgrade of the 32032.  The plans got reshuffled a while ago:  make sure you
have the up-to-date word.  Yes, the 32332 is coming, and looks interesting.
Non-disclosure prevents me from saying more.  (Except that they'd better
get the 32332 out fast without major bugs if they want any market share!)

> This argument is moot anyway for one reason.  The 68020 is considerably faster 
> because the original 68000 is very bus bound, while the 20 is much less so.

Let me see.  You're saying that because the 68000 had no prefetch queue and
a 16-bit bus, and the 68020 fixes both of those problems, that the 68020 is
better than the National 32-bit chips?  Does not compute:  the National chips
have had prefetch queues all along, and the 32-bit ones have had a 32-bit
bus all along.  The 68020 is a vast improvement on the 68000 in this regard,
but that is utterly irrelevant to comparing it against the 32000s.

> ...  Also, a memory cycle
> on the NS series and the 68000 is 4 cycles, as opposed to the twenty, which is
> 3 for main memory, and 2 for the 256 byte queue.

Let me know if you can find a 68020 system that really does a main-memory
fetch in 3 cycles.  It's extremely difficult to build low-cost main memory
that can run that fast (although caches can help).  Don't forget to add the
delay for memory management.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

In article <6099@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes:
> > I must say that I find it quite hard to believe that NatSemi is already coming
> > out with the 32332 already, when they haven't even come out with the 32132
> > or the 32232 yet(Yes, these are actual scheduled components).
> 
> Last I heard, the 32232 was no longer a real part, and the 32132 is a minor
> upgrade of the 32032.  The plans got reshuffled a while ago:  make sure you
> have the up-to-date word.  Yes, the 32332 is coming, and looks interesting.
> Non-disclosure prevents me from saying more.  (Except that they'd better
> get the 32332 out fast without major bugs if they want any market share!)
> 
all right, i admit i was probably wrong since i was relying on old information
but i from what i hear, nat semi is still having problems with their components
and the only thing of theirs that i would consider using is a 32081 fpu, and
this is only till motorola comes out with the 68881

> > This argument is moot anyway for one reason.  The 68020 is considerably faster 
> > because the original 68000 is very bus bound, while the 20 is much less so.
> 
> Let me see.  You're saying that because the 68000 had no prefetch queue and
> a 16-bit bus, and the 68020 fixes both of those problems, that the 68020 is
> better than the National 32-bit chips?  Does not compute:  the National chips
> have had prefetch queues all along, and the 32-bit ones have had a 32-bit
> bus all along.  The 68020 is a vast improvement on the 68000 in this regard,
> but that is utterly irrelevant to comparing it against the 32000s.
> 
that was exactly what i was saying, that the nat semi chips show no great 
improvement in speed as we up to bigger bus widths, while the 020 is a lot
faster than the 000 because of the inclusion of these new features, also, im not sure, but i think the 020 also includes pipelining while the 000 didn't(is
this right?)

> > ...  Also, a memory cycle
> > on the NS series and the 68000 is 4 cycles, as opposed to the twenty, which is
> > 3 for main memory, and 2 for the 256 byte queue.
> 
> Let me know if you can find a 68020 system that really does a main-memory
> fetch in 3 cycles.  It's extremely difficult to build low-cost main memory
> that can run that fast (although caches can help).  Don't forget to add the
> delay for memory management.
> -- 
> 				Henry Spencer @ U of Toronto Zoology
> 				{allegra,ihnp4,linus,decvax}!utzoo!henry

about that last comment, the 020 is capable of doing main memory fetch in 3
cycles, and a queue fetch in 2 cycles. the 80286 i have heard can do a main
memory fetch even faster, but that doesn't mean it will when implemented.
NOW, why should i include a delay for memory management? I mean, why should
i have memory management? we're talking a single user system here with maybe
a few small background tasks.  I dont understand this idea of strapping me
with memory management when i do not want to use unix or anything similar
to it in complexity.
the simpler the os, the faster the system. and i have used att 3b2 unix
 personal computers and they are slow, even though there are provsions
 for up to four users in them. i believe this is because of the os(unix)

 ah, well, i am getting philosophical here, so

				scott weisman
				sdcsvax!sdcc7!ln63fcv

this is a disclaimer

the below statement is true
	   ^
	   |
          \/
the above statement is false