srm@nsc.UUCP (Richard Mateosian) (02/10/85)
In article <5025@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >Don't slam National too hard until you try to get Motorola to admit >that there is a non-empty bug list for the 68020. Yes, there *is* >a 68020 bug list. I'm sorry Henry, but you're dead wrong. There is no bug list for the 68020 -- only a list of CORRIGENDA. Of course, I always thought that corrigenda included corrections. These "corrigenda" seem to consist only of errors, but then, the print is so fine I might be missing an occasional correction. There's even a helpful program included. My favorite part is BEQ NORECOVER . . . NORECOVER: WE CANNOT RECOVER FROM THIS FAULT I'm a little weak on 68k assembler syntax, and I can't seem to find those instructions in my 68020 handbook. Perhaps someone can post an explanation. :-) :-) :-) No flames, please. After all the snide remarks from Austin about our bug lists back when we were where they are now, it's nice to be out of the woods and in a position to laugh at them for a while. -- Richard Mateosian {allegra,cbosgd,decwrl,hplabs,ihnp4,seismo}!nsc!srm nsc!srm@decwrl.ARPA
haapanen@watdcsu.UUCP (Tom Haapanen [DCS]) (02/13/85)
In article <2342@nsc.UUCP> srm@nsc.UUCP (Richard Mateosian) writes: >No flames, please. After all the snide remarks from Austin about our bug >lists back when we were where they are now, it's nice to be out of the woods >and in a position to laugh at them for a while. *** This is not a flame *** However, I'd like to know if National has any news about the release date of their full 32-bit processor, which used to be called the 32132 but may now be called the 32532 or something. Richard? \tom haapanen watmath!watdcsu!haapanen
davet@oakhill.UUCP (Dave Trissel) (02/13/85)
In article <2342@nsc.UUCP> srm@nsc.UUCP (Richard Mateosian) writes: > >There's even a helpful program included. My favorite part is > > BEQ NORECOVER > . > >NORECOVER: WE CANNOT RECOVER FROM THIS FAULT > >I'm a little weak on 68k assembler syntax, and I can't seem to find those >instructions in my 68020 handbook. Perhaps someone can post an explanation. > >No flames, please. After all the snide remarks from Austin about our bug >lists back when we were where they are now, it's nice to be out of the woods >and in a position to laugh at them for a while. There is something Richard is not telling you. This is one of the bugs found on first silicon and has long since been corrected. (I use the word "long" poetically since the MC68020 has only been out about 7 months.) It would be of historical interest to find out how many NS16000 masks were produced before the chip could execute any instructions at all. Here is the current "bug" list for the current mask set A45J. We will number them for Richard's convenience: 1) The LINK #size,An instruction which performs frame management will not produce the exact same results as earlier M68000 family members if the stack pointer SP (A7) is specified as the frame register. Note that specifying the stack pointer is an erroneous thing to do in the first place. Well, that terminates the bug list for the current MC68020 chip. Yes, you read that correctly. We know of no other errors on the part and we could have fixed that one on this latest mask but didn't feel it necessary since we expect no program to ever do such a thing to begin with. Of course we don't think the '020 is 100 percent bug free but for us to be working on such trivial corrections should indicate just how sound the chip is. Now, Richard, your remark about Motorola's being where National "was?" Roy Druian here after reading your posting had an interesting response. He thought it odd that you would refer to Motorola being back where you were a couple of years ago when you are still there. I challenge you to post the bug list for the NS320xx family. And please, number the items for my convenience. I have a National bug list from a year ago and if you like I'll post it and you can comment on which bugs are now gone. Actually, I understand that this is a bad time to post something to you since National is forcing its employees to take a no-pay week long leave of absence. So if you don't respond right away, I'll understand. And no, we don't happen to need someone of your expertise at the moment. (I would put a smiley face here, but I am not sure just how severe the situation is at National. Hopefully this is just a temporary measure.) Responses, of course, welcome. It is probably appropriate to move this to net.flame. I just can't see letting someone badmouth the excellent work the '020 team has been doing here at Motorola. Motorola Semiconductor Inc. Dave Trissel Austin, Texas {ihnp4,seismo,ctvax,gatech}!ut-sally!oakhill!davet
dts@gitpyr.UUCP (Danny Sharpe) (02/15/85)
In article <338@oakhill.UUCP> davet@oakhill.UUCP (Dave Trissel) writes: >In article <2342@nsc.UUCP> srm@nsc.UUCP (Richard Mateosian) writes: >> >>There's even a helpful program included. My favorite part is >> >> BEQ NORECOVER >> . >> >>NORECOVER: WE CANNOT RECOVER FROM THIS FAULT >> >>I'm a little weak on 68k assembler syntax, and I can't seem to find those >>instructions in my 68020 handbook. Perhaps someone can post an explanation. >> >>No flames, please. After all the snide remarks from Austin about our bug The original article which started this discussion was posted in net.nlang because part of it was appropriate for this newsgroup. However, most of the replies don't belong in net.nlang. Please edit the newsgroups line so the article goes to the right groups. -- Either Argle-Bargle IV or someone else. -- Danny Sharpe School of ICS Georgia Insitute of Technology, Atlanta Georgia, 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!dts
srm@nsc.UUCP (Richard Mateosian) (02/17/85)
In article <952@watdcsu.UUCP> haapanen@watdcsu.UUCP (Tom Haapanen [DCS]) writes: >I'd like to know if National has any news about the release >date of their full 32-bit processor, which used to be called the 32132 >but may now be called the 32532 or something. A long time ago I posted the entire story of our part numbering history. What used to be called the NS32132 is now called the NS32532. It is a future product. The NS32032 is a full 32-bit processor, as was the NS32016, except for the data bus. -- Richard Mateosian {allegra,cbosgd,decwrl,hplabs,ihnp4,seismo}!nsc!srm nsc!srm@decwrl.ARPA
haapanen@watdcsu.UUCP (Tom Haapanen [DCS]) (02/19/85)
In article <2373@nsc.UUCP> srm@nsc.UUCP (Richard Mateosian) writes: >>I'd like to know if National has any news about the release >>date of their full 32-bit processor, which used to be called the 32132 >>but may now be called the 32532 or something. >A long time ago I posted the entire story of our part numbering history. >What used to be called the NS32132 is now called the NS32532. It is a >future product. The NS32032 is a full 32-bit processor, as was the >NS32016, except for the data bus. BUT, BUT, BUT! The 32032 only has a 24-bit address bus. To me, this is not a full 32-bit processor like the 68020 which *does* have a 32-bit address. What I really wanted to know was when the 32532 (which *has* 32-bit addresses) will be {announced, sampling, commercial release}. Any info? \tom haapanen watmath!watdcsu!haapanen Don't cry, don't do anything No lies, back in the government No tears, party time is here again President Gas is up for president (c) Psychedelic Furs, 1982
david@daisy.UUCP (David Schachter) (02/21/85)
Can we keep National 32000 stuff in net.micro.16k and Motorola 68000 stuff in
net.micro.68k, PLEASE? There are a number of items cross-put in both categories
that belong only in one or the other. THANK YOU.
(generic disclaimer) {N.F.Q.}henry@utzoo.UUCP (Henry Spencer) (02/21/85)
> Here is the current "bug" list for the current mask set A45J.... > [there follows a trivial bug list] What's customer availability like on the A45J mask set? If it exists only within Motorola, then please don't bother telling us how good it is; we don't care. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
chuqui@nsc.UUCP (The Phantom) (02/23/85)
In article <983@watdcsu.UUCP> haapanen@watdcsu.UUCP (Tom Haapanen [DCS]) writes: > >BUT, BUT, BUT! The 32032 only has a 24-bit address bus. To me, this >is not a full 32-bit processor like the 68020 which *does* have a >32-bit address. What I really wanted to know was when the 32532 >(which *has* 32-bit addresses) will be {announced, sampling, >commercial release}. Any info? The important part of the proceessor is the data bus-- the 32032 does have a full 32 bit data bus. By the time you really NEED 32 bits of address (that is a huge thing, 32 bits...) it'll be there. We have a piece of silicon that is on its way out of the drawing boards that will have that. I've been told to expect first silicon by the end of the year. chuq -- From behind the eight ball: Chuq Von Rospach {cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA We'll be recording at the Paradise Friday night. Live, on the Death label.
phil@amdcad.UUCP (Phil Ngai) (02/24/85)
> >BUT, BUT, BUT! The 32032 only has a 24-bit address bus. To me, this > >is not a full 32-bit processor like the 68020 which *does* have a > >32-bit address. What I really wanted to know was when the 32532 > >(which *has* 32-bit addresses) will be {announced, sampling, > >commercial release}. Any info? > > The important part of the proceessor is the data bus-- the 32032 does have > a full 32 bit data bus. By the time you really NEED 32 bits of address > (that is a huge thing, 32 bits...) it'll be there. But 24 bits of address is not a huge thing, which is what the 32032 has. 24 bits is only 16 Mb or 4 4 Mb memory cards. -- This is my opinion, I guess. Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
chuqui@nsc.UUCP (The Phantom) (02/25/85)
In article <730@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >But 24 bits of address is not a huge thing, which is what the 32032 has. >24 bits is only 16 Mb or 4 4 Mb memory cards. Only 4 4Mb cards? Sigh-- Just think of the vast numbers of Vaxes running 16 megabytes right now. Just thihk of the size of the 4 Mb cards in your 16Mb Vax Last I looked, 16Mb was a LOT of memory, and from a cost/manufacturing point of view, probably more than a 32000 based (or 68K system) will run until memory costs drop and density increases. We DO have 32bit addressing silicon on the boards and on its way to reality, and I expect it will be a purchasable commodity long before the megabit chips that will be neccessary to make those kind of address spaces truly useful. 32bit addressing makes a nice marketing tool, granted, but there really isn't much that a 32bit address gives you that a 24bit address doesn't also give you in a manufactured product EXCEPT a marketing tool. chuq -- From behind the eight ball: Chuq Von Rospach {cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA We'll be recording at the Paradise Friday night. Live, on the Death label.
kurt@fluke.UUCP (Kurt Guntheroth) (02/25/85)
I wonder just how limiting a 24 bit address space is anyway. Our vaxes got
along quite well with 2 Mb running 4.1 Although they have more now we are
running 4.2, it is only 3 or 4 Mb. 16 Mb seems like quite a lot of memory.
Now I don't want to get labelled as a person who cannot see the future (why
go to CRT's when punch cards work so well, etc.) but I don't see any strong
need for more than about 4-8 Mb in the near future. I also believe that the
current generation of processors will probably run out of steam compared to
whatever is under development before they exhaust their address space.
If there is somebody who plans now to use more than 24 bits of contiguous
RAM addresses, I'd be interested to hear his story.
--
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurtkds@intelca.UUCP (Ken Shoemaker) (02/27/85)
> In article <730@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: > >But 24 bits of address is not a huge thing, which is what the 32032 has. > >24 bits is only 16 Mb or 4 4 Mb memory cards. > > Only 4 4Mb cards? Sigh-- Just think of the vast numbers of Vaxes running 16 > megabytes right now. Just thihk of the size of the 4 Mb cards in your 16Mb > Vax Last I looked, 16Mb was a LOT of memory, and from a cost/manufacturing oh well, only 16MBytes? Another point is that since the address qualification is done outside the chip, that corresponds to a 16MByte virtual space, also, regardless of the amount of physical memory you have. However, saying that the 32032 isn't a "true" 32-bit processor by virtue of its 24 of physical address pins is perhaps pressing it a bit. -- It looks so easy, but looks sometimes deceive... Ken Shoemaker, Intel, Santa Clara, Ca. {pur-ee,hplabs,amd,scgvaxd,dual,omovax}!intelca!kds ---the above views are personal. They may not represent those of Intel.
eve@ssc-bee.UUCP (Michael Eve) (02/28/85)
Regarding how much memory is enough, consider a cpu sharing ram with a video coprocessor. Let each video frame consist of 1000x1000 pixels with 3 color planes for each pixel. Each color plane consists of 1 byte. This gives you 3 Mb per frame! At this rate, you can use memory pretty fast. I think such resolution is a realistic expectation in the near future (10 years). Whether any existing integrated processor can update the frames fast enough for useful video is another question. -- Mike Eve Boeing Aerospace, Seattle ...uw-beaver!ssc-vax!ssc-bee!eve
phil@amdcad.UUCP (Phil Ngai) (03/01/85)
> Now I don't want to get labelled as a person who cannot see the future (why > go to CRT's when punch cards work so well, etc.) but I don't see any strong > need for more than about 4-8 Mb in the near future. I also believe that the Need is only part of it. Affordability is also important. As 256Kb RAMs and 1Mb RAMs go down in price, you will see more and more 16 Mbyte and bigger systems. You don't think people will drop in 16 1Mb chips and say "I'm happy with 2 Mbytes", do you? Nah, they'll put in 64 or 128. People buy as much memory as they can afford. Then they figure out what to do with it. -- Why, that's more useless than the left thumb of a touch typist! Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
jeff@alberta.UUCP (C. J. Sampson) (03/03/85)
In article <298@ssc-bee.UUCP> eve@ssc-bee.UUCP (Michael Eve) writes: > > Regarding how much memory is enough, consider a cpu sharing > ram with a video coprocessor. Let each video frame consist of > 1000x1000 pixels with 3 color planes for each pixel. Each color > plane consists of 1 byte. This gives you 3 Mb per frame! At this > rate, you can use memory pretty fast. I think such resolution is > a realistic expectation in the near future (10 years). Whether > any existing integrated processor can update the frames fast > enough for useful video is another question. > This sounds great. However, consider the fact that it takes five to twenty hours to generate each picture of this resoloution on a VAX 11/780 that has no other processes running. Now, who is going to be dumb enough to use a 32032 to do something like this? If it's the occasional frame once a month, I can see it. But nobody's going to do a large number of frames like this on a regualar basis. Keep in mind that the 32032 is a MICROprocesser. It's not made for huge jobs. However, if you insist on doing fifty or sixty frames, I'm sure that the time it takes to dump a frame to disk (a few seconds, at most) will be negligible compared to the CPU time (measured in *days*) that it will take to generate the image. ===================================================================== Curt Sampson ihnp4!alberta!jeff --------------------------------------------------------------------- "It looked like something resembling white marble, which was probably what is was: something resembling white marble."
jack@boring.UUCP (03/06/85)
>People buy as much memory as they can afford. Then they figure out what >to do with it. Nono. *UCB* buys as much memory as they can afford, then make sure that 4.7BSD uses 80% of it, and then starts distributing that:-) -- Jack Jansen, {decvax|philabs|seismo}!mcvax!jack Notice new, improved, faster address ^^^^^