Jan 87 Mousehole
|Column Tag:||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
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.
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.
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 compiler and de-compiler that are compatible and opposite in function. -Ed.]
ResEdit vs. RMaker
I agree with you Mike. I've never used RMaker, because most the the resources are graphic items and RMaker is a text-based tool. I have forever, and will always use ResEdit to create my resources. I've made just about every type of resource totally using ResEdit before writing ANY code. I have a library of generic resource items that I start with. Then with little modification I customize them for my new program. Then after all my resources are completed, which also allows me to play with the user interface, I'll start writing code LAST. I find this method greatly helps me to build programs quickly and easily.
I think the RMaker utility is just a cheap way to publish a resource in print. Until magazines start getting published on disk, how else can someone document a resource? I'd like to write or help someone write an article on using ResEdit instead of RMaker.
From what I understand, Apple is rewriting HFS for the new slotted Mac due out first quarter. Last prototype unit that landed in this area came with 2000+ pages of appendums to the documentation of why your code doesn't work now. When our "guru" friend asked Apple about compatibility, all they would say is, "well it started out compatible" Has anyone else had similar dealings yet? I personally am not really in the mood to start over again come February re-writing code to fit the "NEW STANDARD". [Amen. -Ed]
Also, Apple's Sales Reps are starting to get a little loose tongued lately. Look for one Mac in January, another in May. Last I heard, Apple is suggesting dealers clear LOTS of floor space for Apple products starting in the April - May time frame. Look to see MUCHO monitors in all shapes, sizes, and colors.
Tops vs Macserve
In Nov's Mactutor I'm quoted from the MH regarding Macserve. An editors' comment endorsed Tops within my quote. I would like to rebutt the editors' comment along with a bunch of other pro Tops comments. I've learned from northern sources that Centram's Tops does not use Apple's File structure, while Macserve does. While this might not seem to matter all that much to the operator at this time... it will later. [If someone out there can give us the precise technical scoop on exactly how Tops and MacServe work, we would love to publish it and clear up the confusion between these two products. -Ed]
I talked to Microsoft today and they said Word 3.0 will be released sometime in Jan. The cost for people who bought 1.05 before 10-1-86 will be $99.00, $50.00 for people after 10-1. Sounds pretty steep to me. Is it worth it?
At $50-99 for an upgrade, Word 3.0 is an absolute steal. It's hard not to be so enthusiastic, since I've been working in it for 3 months. I suggest as Microsoft starts making the User group circuit that people attend a demonstration. Dealers will not have a demo until the product is released in January. It's great!
Mac Fortran Interface
More information on McFace for you Fortran programmers: "McFace is a Fortran-callable unlinked external subroutine which creates a Macintosh user interface for existing Fortran programs. McFace adds access to desk accessories, file handling, text editors, picture editing, alerts, and dialogs without a single call to the toolbox by the main Fortran program..." The author can be reached by phone at (217) 328-5842. [Watch for an article on this product in MacTutor.-Ed]
Try the following: Take an HFS disk that has some files in the disk window. Check the memory available on the disk. Create a new folder and put some files into it. Now look at how much memory is available. Now try to get the lost memory back. You can take the files out of the folder, trash the folder, rebuild the desktop, etc. to no avail. The only way I have found to do it is to copy the disk to another disk. It seems that a folder takes up disk space that cannot be recovered. I'm using system 3.2 and Finder 5.3 for this.
I LOVE the hint in the letter I got for the EXCEL upgrade. Version 1.03 will take advantage of the 68881 coprocessor.
Remove Macsbug, why?
[In response to "How can you detect Macsbug is loaded in your Mac"]
Let me guess what you're trying to do. Remove Macsbug to keep someone from unprotecting your program. Without getting on a soapbox and pleading "no copy protection please", I'll explain why removing Macsbug would be a bad idea.
Macsbug gets installed during system load time below the Main Screen Buffer ($7A700). Then the sound buffers, jump tables, application parameters, application globals, quickdraw globals, and finally the CurStackBase get installed below this. All of these addresses will change depending on the version of Macsbug in use. All of this will happen before any of your code is excecuted. You could not remove Macsbug and reload all of these addresses. Therefore, you would have erase a section of high memory and leave the area blank.
BASIC 3.0 Features
According to Microsoft, the MS BASIC 3.0 Interpreter has the following enhancements:
Toolbox Support. In the new version, you'll be able to directly use resources, add command-key equivalents to menus, and make toolbox calls, etc. Microsoft basically purchased the marketing rights to the Clear Lake Research toolbox assembly language libraries and grafted them in to the interpreter, calling them the "Microsoft Basic Toolbox Library". At least, you can do as much as you could under MS Basic with the CLR libraries. So, at best, this will be a superficial interface Toolbox. No low level File Manager calls here!
Runtime Package. Microsoft has finally understood that waves of commercial Macintosh developers are NOT rushing out to license their MS BASIC runtime package at almost $300 per year, so they are now going to include it with the interpreter. Last I heard, though, the runtime was a separate file, and could not be "bundled" with a BASIC application to produce a single, double-clickable program. [Not true. You can link the runtime library into a stand-alone program without paying fees. -Ed]
HFS Compatibility. Yes, there are new enhancements to the FILE$ functions that return directory information to your program. There is also a way of changing the "default" directory on the fly.
Multi-line IF...THEN..ELSE Constructs. New to this level are block IF/THEN/ELSE statements that permit a more structured coding style.
A Miscellany of Other Stuff. Like SADD, for String Address function, which allows you to pass the address of a string variable to a machine language subroutine.
That's all I know at this time. No word on price or availability. I was told that the compiler is "under development," which I know is a stunning surprise to all of you. [Microsoft has begun a direct mail marketing program selling Basic for $99 if you order direct by Jan 15th. Call (206) 882-8088 for more info. -Ed]
Yes, I too have recieved my update notice. $25 to upgrade, but this gives you 140 CLR Libraries routines and multiline IF-THEN ELSE ENDIF type statement. Better support for LaserWriter. Fixed HFS problems and added CHDIR to change the directory. The compiler apparently has not been finished quite yet even though I think they wanted to have both done at the same time. It will probably (my guess only) be a new product which you'll have to pay extra for.
As the ad in MacWorld says, the compiler will support all the new 3.0 stuff. By the way, about a month ago someone from Microsoft called me and asked me what I thought they should do to improve MS Basic. I think they took some of my ideas, but not all. They had been reading the "BASIC WARS" Mactutor column where I reviewed ZBasic and others. I think they were finally seeing that they had to act fast to just keep up and work even harder if they wanted to keep any advantages over ZBasic. ZBasic is a much better product now. Version 3.02 is out and most bugs are gone. I'm almost ready to recommend it to everyone, but they are re-writting their editor and I'll wait till it comes out. By then maybe MS will have their compiler out too.
Hard Disk Survey
Here are my times for DiskTimer 1.1 and my 10MB HyperDrive. I have the OLD 128K motherboard and the OLD Hyper controller board (rev 1.0). I am, however, running HFS with the new 128K ROMs and General's V3R1 software:100 32K reads, 133.0; 100 32K writes, 114.5; 80 seeks across 1MB, 6.7
My Hyperdrive 20 running on approximately a 512E (it has been upgraded so many times I don't know what it is!) gives the following times: 100 Reads 26.5 sec, 100 Writes 25.0 sec, Access time 2.8 sec.
Ok, so now I've got version II. Here are the results with my 512E and Hyper 20 running V3R1 (the latest & ......):
Test w/o caching w/ caching
100 24k reads 188 ds 184 ds
100 24k writes 187 ds 187 ds
80 seeks across 1MB 30 0
I just got my new ProAPP 40mb hard disk. This drive is REALLY nice. It uses a 3.5" 2 platter disk mech, with built in SCSI controller. The typical read/seek time is 28-29ms. I have used a lot of SCSI drives but this is DEFINITLEY my favorite now! I have about 27 out of 40 megs full, and have had NO noticible speed decrease, either reading or writing.
If you are looking for a new disk, this is the one. The 40meg version retails for $1995, and the 20meg version for $995. These prices INCLUDE all applicable sales tax and shipping charges! [Note: There is developer pricing for real developers, according to ProAPP]
ProAPP 40s: 21.7 read; 21.2 write; 3.1 across 1mb.
Here's my results of bench marking the ProAPP 40. The drive had nearly 35mb of data. I've tested a freashly formatted 40 with less than 1mb, but the results were the same.
DiskTimer test: READ = 21.4; WRITE = 21.2; ACCESS TIME = 2.2.
Timing results from Disk Timer II For HD-20: 874, 294, 37. For ST-225N (as used by Loy Spurlock): 194, 294, 37.
I just ran Disk Timer on Scott Winders' 40Mg XP and it screams!!!!. Here are the results:
Reads 6.9, Write 7.6, Access 1.8.
Just got my Dataframe 40xp today and was blown away the Disktimer 2 results:
Reads 53, Write 55, Seeks 18. That is the fastest drive I have seen yet!!!
Disk Timer II
Results from DataFrame20 (original) w/Mac+: Reads 146, Writes 146, Seeks 68
Note: This is with INIT 1.5 software. INIT 2.1 would blow up on me after loading the disk with System/Finder.
Here's the averaged results of three tests on my Micah AT20, (a drive whose company is having financial problems).
Reads: 55 Writes: 59 Seeks: 72
Personally, I like the drive. It's the company that's got me worried.
I'm the proud owner of a Relax Technology Hard 20 Plus disk drive. I guess it's got a Seagate drive in it. I'm real happy with it 'cept it has a noisy fan. Anyway, my disktimer II results are:
100 24KB reads: 194
100 24KB writes: 293
80 seeks: 37
The disk cache was off when I ran this.
That is probably the hard disk, not your fan that is noisy. I had an SCSI drive that had the ST-225N in it, and it made more noise than the boxer fan...
More results for the Great Disk Timer Shootout:
For an EasyDrive 30-meg SCSI drive (based on a Seagate drive):
100 24KB Reads: 422
100 24KB Writes: 425
Access Time: 36
For what it's worth, I've had personal experience with 5 (yup: 5 different ones) of these drives, and I've found them to be tireless: 3 of them are on all day long... and have been for about 4 months. They're cheap. They don't break. The manufacturer is in the City of Orange [CA, Home of MouseHole!). They have a 1 year warranty.
What I want to do is a tool window almost exactly like the one in Fullpaint that will stay in front of all the other windows no matter what. I would like to pass events to it using DialogSelect like all my other dialogs
Here is a quote from inside mac - "In the global variable GhostWindow, you can store a pointer to a window that's not to be considered frontmost even if it is (for example, if you want to have a special editing window always present and floating above all the others).
This is what I want, So I do a GhostWindow = (WindowPtr)GetNewDialog(...
and what I get is a window that is just the opposite from what inside mac says...
The reason I want this is because normally everytime this window gets covered I have to do a BringToFront and that looks lame...
The function of GhostWindow is not to keep a window in front of all other windows, but rather to pretend it isn't when it really is.
What I mean is, if you have a window and you store its pointer in GhostWindow, any calls to FrontWindow will not return your ghost window even if it really is in front. This way, you can have it highlighted at the same time as another window and have the next-to-front window be the "Active" one that gets all the normal events because it gets returned as the result of FrontWindow.
Unfortunately, you have to handle the GhostWindow completely manually. Because the window will get unhighlighted and moved to back if you activate another window, you have to constantly bring yours to the front. But that causes all sorts of flicker and other problems because of some of the things the ROM is doing.
We use a GhostWindow palette in dBASE Mac, and we wound up writing our own versions of some of the Window Manager routines to avoid having our palette flicker all the time.
I'm having a hard time figuring out how to highlight the default button in a dialog. According to a couple things I read, it seems it's supposed to be "automatic" if you have a button that's item number one. However, it didn't seem to work for me. Anyone have the solution?
The default is automatic if you use _ModalDialog. It will return a 1 in itemHit if the return or Enter key is hit. If you don't use ModalDialog you're supposed to support the return/enter = OK anyway (Macintosh user interface guidelines -- hee hee)
To automatically draw a box around the item, it's not automatic... you have to do the drawing.
Do a GetDItem(OK button) and use the rect it returns in "theBox":
The automatic highlight does actually exist. Only it's for Alert calls, not dialogs.