Jan 87 Mousehole
Volume Number: 3
Issue Number: 1
Column Tag: Mousehole Report
Mousehole Report 
By Rusty Hodge, Contributing Editor, Mousehole BBS
Great Disk Timer Shoot-out!
We've been having a bit of a challenge here lately. Which hard drive is the
fastest? Which is the best? What are our conclusions? You won't want to know,
maybe. The fastest drives were the HD-20SC, The Dataframe XP and the ProAPP 20
and 40S, not in that order. Drives with the fastest read/write time didn't necessarily
have the fastest access time. Internal RAM caching (e.g. the ProAPP) helped some
tremendously. And our results didn't take boot speed into account. Dataframes seem to
take forever to boot, HD-20s (the non-SCSI ones) seemed to be much faster.
We're dropping speculation about the "January" Mac (Alladin some call it)
because it will probably be announced by the time you read this. [Ha ha ha! Where have
I heard that one before? -Ed] The Milwaukee is a different story, pre-release
developer machines are starting to pop out of the woodwork as we speak; which means
that everyone who has them is under piles of non-disclosure statements. So we can't
tell you that it has multiple slots, an eighty megabyte internal hard disk, slots,
floating point co-processor standard, slots, multiple video options (big mono, bigger
mono and big color), 2mb of memory-managed RAM initially ( eventually expandable
to a gigabyte), slots, 14-16mHz processor speed, and of course, slots. We'll see.
[Who needs slots? -Ed]
Can't find a SASE to send to us? For the month of January we are offering a trial
online sign-up. Here's how it goes. Call (714) 921-2252. When you get the Login
promp, type MACTUTOR GUEST. This will prompt you for a stream on information and
then you will have your very own MouseHole acount. Sound exciting? Think of it as a
sort of a late Christmas present!
Finally, we hope to see you all at the San Fransisco MacExpo. Look for us and
we'll look for you. - Rusty
68030
Frank Henriquez
With all this hype in the press lately over the 80386, most (if not all) have
overlooked the simple fact that a 68020 will be faster than the 80386...the 68020
has an internal cache. The 80386 does not. Unless the 80386 has a lot of fast static
ram to play with, it's going to have to insert a wait state or two (just like most 68020
systems) BUT, with the cache bit enabled, the 68020 will not have to access external
memory as often, and will therefore run at full speed. I've seen benchmarks where the
68020 @ 16 MHZ is 20-30% faster than the 16MHZ 80386.
The 68030 is another story; apparently Motorola has included some fancy
memory interleaving hardware AND separate data and instruction caches. I've heard
that a properly designed '030 system could run with only occasional wait-states, at
25MHZ+, using standard DRAMs. Now, that is quite a feat. And since the '030 is
basically a 68020 deep down inside, it should be fully compatible with the 68000,
68020 etc.
80386
James B. Du Waldt
I was under the impression that the '386 did have an instruction cache, like the
'020, but maybe I'm wrong... One of the real problems with the new, very fast
processors is, as Frank mentions, RAM speed. We're going to see a lot of high speed,
low end stuff having to use static row and/or nibble addressing in order to keep up
with the 16 MHz '386, not to mention the 20 and 25 Mhz '020's...
A brief note on workstation sales... Sun 20,000 units/yr (all figures approx.);
Apollo 20,000 units/yr; DEC 12,000 units/yr; IBM 6,000 units/yr.
Industry editors/writers are beginning to think that the RT (apparently gives a
new meaning to "Reduced" instruction set computers...) just ain't gonna make it,
several months after saying how slowly windows close on IBM... (I agreed with them,
still do, but I was HOPING it would...)
Some of the companies that announced early support of the RT are now dropping
their porting plans. I guess selling to people (ie, engineers) who aren't afraid of
technology isn't quite as easy as selling to MIS folks... After a year, complaints are
still the same, bad graphics & no networking.
Mike Steiner
Why has so much attention been given to how to write a resource and then
compile it with RMaker? Why not just write your code and your unique resources and
then use Resedit to write your window, menu, dialog, etc. resources? (or write the
resources first and then the program). I'd think that putting resources together with
Resedit would be easier than having to write the code from scratch without the visual
interface that Resedit affords. Maybe this might make an interesting 'Tutor article for
someone to write. [The problem is, how do you publish a resource file made with
ResEdit? You can't. So a lot of the usefulness is lost if you can't convey the idea to
someone. In this respect, MPW has it all over MDS because MPW has a resource
Referenced by (2):