ditzel@ssc-bee.UUCP (Charles L Ditzel) (10/15/85)
Question 1 : Does anyone know for a *fact* (as opposed to rumor) if anyone is working on porting os9 or some unixlike environment to the ST? Question 2 : 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? Question 3 : Does anyone know where the '50,000+ Atari's sold' number is coming from? ---- Trying to pin down hype versus fact.
gnu@l5.uucp (John Gilmore) (10/23/85)
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...
davecl@shark.UUCP (Dave Clemans) (10/24/85)
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
coryb@hammer.UUCP (Cory Barker) (10/24/85)
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...
ln63fcv@sdcc7.UUCP (This is a test) (10/27/85)
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.
henry@utzoo.UUCP (Henry Spencer) (10/30/85)
> 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
ln63fcv@sdcc7.UUCP (This is a test) (11/06/85)
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