Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!uupsi!sunic!isgate!krafla!adamd
From: adamd@rhi.hi.is (Adam David)
Newsgroups: comp.sys.atari.st
Subject: Re: What the ST should be
Message-ID: <2875@krafla.rhi.hi.is>
Date: 7 Mar 91 16:41:34 GMT
References: <1991Feb28.213727.46962@cc.usu.edu> <2864@krafla.rhi.hi.is> <1991Mar4.163632.353@midway.uchicago.edu> <1991Mar5.014330.10601@math.lsa.umich.edu>
Organization: University of Iceland
Lines: 36

In <1991Mar5.014330.10601@math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes:

[about 68010]
>Well, for us lowly ST owners, it has one advantage - pin-compatibility
>with the 68000. Although I guess even that's not true for all the 68000
>package configurations now. (Which kinda sucks for us STe owners, where
>TOS 1.6x can cope with the 68010 but you can't get one in the proper
>packaging/pin configuration. What a drag... [Hm. Why doesn't someone
>market an adapter socket or something? Sheesh!])

You mean somebody doesn't make an adaptor socket? I seem to remember reading
about how to fit 64-pin MPU boards (SST from Gadgets for instance) to the STE.
As for the 68010 they should be available as 68-pin PLCC according to
Motorola docs. Maybe they are just not stocked any more (real drag).
If you can find one it should drop straight in to an STE and work just fine.
16 MHz might require good luck and some extra cooling though for the 12.5 MHz
part to be reliable.

>Ok, moving right along... DRAM is pretty cheap now, even at reasonably fast
>speeds. Why did the Mega STe require caching for 16MHz operation, why doesn't
>the entire system allow normal accessing at 16MHz? Double all the relevant
>clock rates, while you're at it - DMA bus, for example. I wonder how long
>it'll be before we see an even faster version of the TT. (Ok, so ya can't run
>at zero wait states with a 50MHz 68030 using human-priced DRAMs. But it'd
>be nice to head that direction, eh?)

If that memory were to be interleaved it could run at full tilt inserting wait
states only for non-consecutive addresses, but I suppose that's really just
another form of caching/prefetching. It could be done pretty much with a single
PAL chip. To be really effective it would need to be buffered separately for
code and data, it might be necessary to arbitrate the bus also.

Will we ever see a 68040 TT, or something more exotic? (dirt cheap of course:-)
--
Adam David.
adamd@rhi.hi.is