rmc@spectrix.UUCP (Russell Crook) (05/07/87)
A long while ago, Electronics had a small item about the 68070 to be
built by philips or signetics (I think). Recently, a couple of other
articles in other trade journals have mentioned this chip, which was to be
a 68000 + unspecified MMU + 1 or 2 serial ports + timer + ... for
under 25$ U.S.
I am curious as to:
Does this beastie really exist yet (sampling or better), and if not,
any guesses as to timetable?
Is the cost as low as mentioned?
Is it pin compatible with existing 68000's?
Could you drop it in an Atari St or a Commodore amiga and have a MMU available?
What kind of MMU is it?
I hope this is the right group to ask ...
Russell Crook (UUCP: ...!seismo!{utzoo,mnetor}!spectrix!rmc )junien@prls.UUCP (Junien Labrousse) (05/08/87)
In article 3268, Russell Crook writes: > A long while ago, Electronics had a small item about the 68070 to be > built by philips or signetics (I think). Recently, a couple of other > articles in other trade journals have mentioned this chip, which was to be > a 68000 + unspecified MMU + 1 or 2 serial ports + timer + ... for > under 25$ U.S. > I am curious as to: > Does this beastie really exist yet (sampling or better), and if not, > any guesses as to timetable? > Is the cost as low as mentioned? > Is it pin compatible with existing 68000's? > Could you drop it in an Atari St or a Commodore amiga and have a MMU available > What kind of MMU is it? You're lucky, I just happened to read your article. I'm one of the 68070's architects. Let me describe the beast. You can find in one single chip: - a 68000 CPU : full 32-bit architecture 68000 programming model 68000 instruction set 10 MHz clock speed enhanced bus error handling (68010 like) - a MMU : virtual address translation for 8 or 128 segments of 2Mb or 128Kb, memory protection (user/super, R-W-E access) allowing dynamic stack allocation transparent when unused adding one wait state when used - a DMA : 2 independent channels byte and word transfers up to 3.2 Mbytes/s single cycle or burst mode max block size 128Kb compatible with 68430 / 68440 / 68450 - RS232-C : one independent receive and transmit channel independent baud rates full/half duplex auto echo mode compatible with 2641 / 2661 / 2691 - timers : 3 16-bit timers match / count / capture mode pulse generator compatible with 68230 - I2C bus : two lines serial bus transfer rate up to 100 Kbits/s master / slave mode multimaster build in protocol Unfortunatly, there is no way to implement all these functions in a 68000 pin compatible package. Timers and serial busses need their own interfaces. It is packaged in an 84-pin PLCC. This chip has been designed by Philips and is being sampled with 100% functionality. It will be available on the market in the last quarter of this year and its price is estimated to be approximately $25 at the end of 88. Let me know if you want more information. Junien Labrousse ( junien@prls.UUCP )
weaver@prls.UUCP (Michael Gordon Weaver) (05/09/87)
In article <280@spectrix.UUCP> rmc@spectrix.UUCP (Russell Crook) writes: > > A long while ago, Electronics had a small item about the 68070 to be > built by philips or signetics (I think). Recently, a couple of other > articles in other trade journals have mentioned this chip, which was to be > a 68000 + unspecified MMU + 1 or 2 serial ports + timer + ... for > under 25$ U.S. > (NOTE: the following does NOT represent in any way the opinions of Philips or Signetics. For official information, contact Nelson Chan, Signetics (408) 991-3359. The following is from memory and may contain errors). The 68070 was designed by Philips with help from Signetics (Philips owns Signetics). It will be sold by Signetics and Philips. It has not yet been sampled. I believe samples are expected before the end of 1987. The price will probably be quite a bit higher than $25 US at introduction time, although that might be a reasonable cost as the price erodes. Signetics is hoping to sell a lot of these, and any follow-on products. The 68070 is not a drop-in replacement for the 68000, it has too many pins. The bus is described as '68000 compatible' in Signetics liturature. The MMU is a Philips/Signetics design and is not software compatible with the Motorola MMUs. Additional features are: o 4 decoded interrupts o decoded interrupt acknowlege o 2 channel DMA controller o 1 serial line o counter/timer Michael Gordon Weaver Usenet: ...pyramid!prls!weaver Signetics Microprocessor Division 811 East Arques Avenue Sunnyvale, CA 94088-3409 (408) 991-3450
scotty@l5comp.UUCP (Scott Turner) (05/10/87)
I have no knowledge of pricing or availablity but Signetics did break down and send me a large information package about this device. 1. The chip is NOT pin compatible with anything except itself (grin). 2. The MMU is a warped 68451. 3. The chip uses 68010 style exception frames so it can use the MMU properly, but that's ALL it takes from the 68010. No virtual CPU support ie move sr,ea isn't priv'd. 4. The opcodes execute faster than their 68000 counterparts. Signetics has used a wild 2X clock scheme. Where a 68000 counts T states off a 8MHz clock the 68070 counts it's states off a 16MHz clock BUT uses an 8MHz buss clock! This method allows them finer granularity in the timing of the execution unit. 5. It's a cute chip but I doubt we'll see too many retrofits, as for the expected design-ins... Wouldn't you rather have a MC68020?? (grin) Trying to put this chip into the Amiga would raise all sorts of issues so I don't blame C-A for not doing it. (I do think it was silly to not use the 68010 though) The MMU for example would kill most message ports. If C-A had been thinking ahead they would have included an MEMF type for a true "public" memory type. If this had been done then message ports could have been allocated using this memory type and on MMU systems this would return a pointer into a shared memory page. Alas it is too late now and we have RJ running around saying how "lucky" we are to not have an MMU because of all the overhead in passing messages back and forth in such systems. Some people should stick to designing game machines, grin. It's surprising that this concept of shared memory pages was missed since they picked up on the UN*X concept of having a slow file system to cut the legs from under the machine. Scott Turner L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)
jmpiazza@sunybcs.UUCP (Joseph M. Piazza) (05/10/87)
In article <3580@prls.UUCP> junien@prls.UUCP (Junien Labrousse) writes: >... >I just happened to read your article. I'm one of the 68070's architects. Let me >describe the beast. You can find in one single chip: > > - a 68000 CPU : full 32-bit architecture > ... Does this mean (finally) a 32-bit APU? Thanks, joe piazza
nerd@percival.UUCP (Michael Galassi) (05/10/87)
In article <280@spectrix.UUCP> rmc@spectrix.UUCP (Russell Crook) writes: > ... 68070 ... > ... a 68000 + unspecified MMU + 1 or 2 serial ports + timer + ... > I am curious as to: > ... Is it pin compatible with existing 68000's? > Could you drop it in an Atari St or a Commodore amiga and have a MMU available I know it is not pin compatible w/ any of the other 68k family parts, how could it be, there have to be pins for the new i/o functions. I seem to remember from the data sheet (can't find it now) though that the timming on all the common pins is the same as what you would expect of a 68000 so you should be able able to build a simple board w/ the 070 and some drivers for the serial/paralel functions that then would plug into your mother board on the st/amiga. (assuming the part exists) The biggest problem as I see it is that all the code currently in the ST is slopily written (this was true of the original 520 ST, I don't know what is going on w/ current Atari 68k machines) to the point that you could not get it to boot w/ the 010, I doubt it would work with the 070 without quite a few changes. I seem to remember tracing the ST problem I encountered to a move sr,d(whatever it was) instruction which is privileged on the 010 but is not on the 68000. It should not be that dificult to fix this by writing an apropriate trap handler to replace the original one. > What kind of MMU is it? sigh... Regretfully it was not a proper (or even inproper) subset of any other mmu out there, it is not a pmmu (paging) so no vitual memory support from it's corner. > I hope this is the right group to ask ... can't think of a better one to ask which is why I followed up here. Any one have more info on the part? Let's hear from you. -- If my employer knew my opinions he would probably look for another engineer. Michael Galassi, Frye Electronics, Tigard, OR ..!{decvax,ucbvax,ihnp4,seismo}!tektronix!reed!percival!nerd
ali@rocky.STANFORD.EDU (Ali Ozer) (05/11/87)
In article <110@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: > ... The MMU for example would kill most message ports. If C-A had been >thinking ahead they would have included an MEMF type for a true "public" >memory type. If this had been done then message ports could have been >allocated using this memory type and on MMU systems this would return a >pointer into a shared memory page. ... But, isn't that what MEMF_PUBLIC is for??? Right now MEMF_PUBLIC doesn't do a thing, but isn't it supposed to be for the future (the days of the Amiga 3000, say!) when there's an MMU in the Amiga? I've been a good boy all this time and have put in MEMF_PUBLIC for all my port, message, and task memory allocations (so that my programs could work in some future Amiga). I think an MMU with shared memory pages what C-A had in mind when they included this flag for memory allocation. Ali Ozer, ali@rocky.stanford.edu
walton@tybalt.caltech.edu (Steve Walton) (05/13/87)
In article <303@rocky.STANFORD.EDU> ali@rocky.UUCP (Ali Ozer) writes: >In article <110@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: >> ... The MMU for example would kill most message ports. > >But, isn't that what MEMF_PUBLIC is for??? Right now MEMF_PUBLIC doesn't >do a thing, but isn't it supposed to be for the future (the days of the >Amiga 3000, say!) when there's an MMU in the Amiga? I've been a good boy >all this time and have put in MEMF_PUBLIC for all my port, message, and task >memory allocations (so that my programs could work in some future Amiga). Since none of the Wizards took this up, thought I would. Nearly EVERY system call in the Amiga gets a pointer, and thus this pointer would have to be MEMF_PUBLIC if we had an MMU. When was the last time anyone AllocMem'd a NewWindow structure with MEMF_PUBLIC and copied their window information into it? I've seen no examples which do. (Didn't Matt Dillon go through all this at some length a while back?) Steve Walton, guest as walton@tybalt.caltech.edu AMETEK Computer Research Division, ametek!walton@csvax.caltech.edu "Long signatures are definitely frowned upon"--USENET posting rules
michael@stb.UUCP (Michael) (05/17/87)
In article <2686@cit-vax.Caltech.Edu> walton@tybalt.caltech.edu.UUCP (Steve Walton) writes: >Since none of the Wizards took this up, thought I would. Nearly EVERY >system call in the Amiga gets a pointer, and thus this pointer would >have to be MEMF_PUBLIC if we had an MMU. When was the last time ONLY pointers passed to other tasks (including devices) needs to be MEMF_PUBLIC. You do not need to declare memory passed to intuition calls, exec.library, graphics.library, etc. Only memory that is A: Pointed to by a pointer in a message B: The message itself (not sure about this, the send message call may imply any re-mapping necesary) C: The segments loaded by LoadSeg() (since they may be used for another task) What I'd like to know is: If you put a MMU up, how do you tell AddTask()? All you give it is starting address, termination routine. How does it know any MMU information? Does it need to run from MEMF_PUBLIC or would it share your MMU status (which makes sense). How would CreateProc inform exec about MMU information in the segments? Bottom line (as far as I can tell): Code (text and initialized data) must be MEMF_PUBLIC, only AllocMem() memory can be otherwise (including non- initialized data). Michael -- : Michael Gersten seismo!scgvaxd!stb!michael : The above is the result of being educated at a school that discriminates : against roosters.