Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!inesc!unl!unl!jgp From: jgp@fctunl.rccn.pt (Jose Goncalo Pedro) Newsgroups: comp.sys.atari.st Subject: Re: 68030 speed increases (was Re: Atari TT 030 Launched!) Message-ID: Date: 8 Jun 90 00:20:04 GMT References: <1990Jun5.143231.4977@watserv1.waterloo.edu> <13266@wpi.wpi.edu> <81214@tut.cis.ohio-state.edu> <1990Jun6.044350.20403@cbnewsh.att.com> <10373@batcomputer.tn.cornell.edu> <3647@rodan.acs.syr.edu> Sender: news@fctunl.rccn.pt (USENET News System) Organization: Universidade Nova de Lisboa -- Lisbon, Portugal Lines: 52 In-Reply-To: jfbruno@rodan.acs.syr.edu's message of 6 Jun 90 20:23:21 GMT Well, you get the two-fold speed increase going form a 16 bit bus and a 32 bit bus this way: The 68030 has a built-in instruction cache (don't know about a prefetch queue, but shouldn't need it), which, when the 030 is fetching an instruction not present in the cache, fetches a 32 bit long word from memory and stores it in the cache, too. So, when the 030 fetches the next 16 bit instruction (or operands, or whatever) it goes directly to the cache (or maybe prefetch queue) and gets it much faster than ram (I don't think TT's ram runs at 0 wait states!). For most purposes, and for the vast majority of programs, this represents a 2-fold speed increase. But all this is incorrect because I am not taking into account the fact that the place where programs generaly spend more time, i.e. short inner loops (i think) have a good chance to be executed from the cache after the first pass, and i think that a 256 byte cache is enough for most such loops. And the 030 has got also a 256 byte data cache... All this coupled to an increase from 8 Mhz to 16 Mhz, and the fact that the 030 takes half as many clock cicles to do a memory access than the 68000 (memory speed permiting), without using the burst transfer mode which transfers 4 32 bit words in 5 clock cicles to the cache (but i doubt that the TT uses that) (I hope I am not confusing this with the 68040!!!), should give better than a fourfold speed increase! I'd like to state that ever since i read about the TT i have sort of dreamed of owning one, but have always had my doubts of Atari's capabilities to make this a real, usable computer (and supported, almost forgot that one), with real software that can be used to develop applications for more than one platform (I live in a country where the vast majority of PC's [not counting Spectrum's] are IBM compatibles, and I wouldn't try to make a living developping only for the ST). Here, there are almost no third party dealers (almost no official atari dealers, also), harddisks and the like are 2* or 3* the price one can get them abroad, software for the ST is virtually non-existent, and I barely use the ST anymore (1040ST with SM124, no HD, 1Meg), and turn to my brother's IBM PS/2 55 SX, with a 16Mhz 386SX, colo(u)r VGA monitor, 60Mb HD, 2Meg ram, and a decent (portuguese) keyboard. I still prefer the ST, but.... The TT would be my salvation from the PC world, where I developed some applications (and got sick of it, when i needed to write a windowing environment for the next versions of those program, you know, those little windows and menus that every Mac, ST or Amiga programmer takes for granted), but, as i said, my faith in Atari isn't very high... Enough complainig! Two (three? 4?) more questions. Why isn't there a 25 Mhz TT ? Apple has got a 40 MHz MacIIfx, and I think Motorola already ships 50Mhz '030's. Will it bee so difficult to upgrade has the other models? And what about a 68040 based TT ? (I think I'm in love with that chip) And why not a proper GEM implementation, with more services managers (for sound, comms, or even extending th