Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!orsvax1!pyrnj!caip!topaz!shulman From: shulman@topaz.RUTGERS.EDU (Jeff Shulman) Newsgroups: net.micro.mac Subject: Delphi Mac Digest V2 #11 Message-ID: <4608@topaz.RUTGERS.EDU> Date: Sat, 22-Mar-86 21:34:55 EST Article-I.D.: topaz.4608 Posted: Sat Mar 22 21:34:55 1986 Date-Received: Tue, 25-Mar-86 02:53:54 EST Organization: Rutgers Univ., New Brunswick, N.J. Lines: 537 Keywords: Delphi Delphi Mac Digest Sunday, 23 Mar 1986 Volume 2 : Issue 11 Today's Topics: Administrativia - Replying to digest messages RE: Magic location in mac+ selects boot sequence Re: bitmap form of MacPaint & cleaning the desktop & Gutfreund (graphic representations) Re: How to clean up an HD20 desktop Re: sending a Break on Mac+ Re: Macintosh Hard Drives Re: SCSI disk drives Re: baud rate discussion & internal Mac hard disks HARDWARE Re: Record Holder L.W. crashes Mac Re: Servant and Andy's idea for opening a document Re: InfoMac posting & MacTerminal question Hard Disk Benchmark RE: Hard Disk Benchmark (Re: Msg 6686) RE: Hard Disk Benchmark (Re: Msg 6700) Re: PackIt II/Switcher 4.6 bug Mac+ and 3rd party ext. drives Re: 128K ROM versions Re: MAC SCSI drivers External RAM drives Re: Abaton scanner Re: Servant addendum Re: How do the 800K drives write to the disk? Re: Mac/Mac+/3rd party upgrade strategies ---------------------------------------------------------------------- From: Jeff Shulman, moderator Subject: Administrativia - Replying to digest messages Date: 22 Mar 86 21:25:00 EST If you wish to reply to messages in this digest you should send your reply to INFO-MAC@SUMEX if you get this on the Arpanet *OR* net.micro.mac if you get this on Usenet. DO NOT SEND TO BOTH. If you mail it to me it gets included in the next Usenet Mac Digest which Usenetter's do not get, thus miss out on your reply. ------------------------------ From: BRECHER (6600) Subject: RE: Magic location in mac+ selects boot sequence Date: 16-MAR 21:20 MUGS Online In the copy of parameter RAM in the system global area, bit 4 set in the SPMisc2 field ($20B) will cause the internal floppy drive to be skipped in the first pass through the drive queue during the boot sequence. When you moved the System file to the root directory, there was no longer a "blessed" folder -- but the starting default directory is the root directory, so the system file was found, and hence the volume was considered bootable past the point of no return. But the Finder was not in the "system directory" (there was no such directory) so Launch failed with a Segment Loader Error (ID=26). If you had moved the System file to another folder instead of to the root directory, and left Finder in its original folder, your scheme would have worked. The drive queue elements for floppies and/or the HD-20 are created at boot time; if the drive isn't there (on) at that time, there is no way to introduce it later -- except by writing custom software to add the appropriate element to the drive queue. ------------------------------ From: PEABO (6651) Subject: Re: bitmap form of MacPaint & cleaning the desktop & Subject: Gutfreund (graphic representations) Date: 20-MAR 00:04 MUGS Online Re: bitmap form of MacPaint ... That is easy ... a MacPaint document consists of one 512 byte header block which you can ignore, and then a run-length encoded bit map of 720 lines, each 576 pixels wide. There are toolbox routines to decode (and encode) a scanline and they are called UnpackBits and PackBits. For making bit image files of the MacDraw and MacWrite documents, you will probably need to write a sort of printing application. The print manager images the document in horizontal bands in memory, and then writes to a printer according to the specific printer graphics commands needed. If you don't want to go to the trouble of doing that, then you should probably capture the bit stream coming out of the printer port as if you were an Imagewriter, and decode the escape sequences. It takes two Macs to do this (or one Mac and another machine of some sort). One clinker is flow control. You will have to accept the data at burst rates of 9600 bps or respond with XON/XOFF or control lead flow control signals. Re: cleaning the desktop Jeff -- the Purgeicons program we have here in the database was souped up by Steve Brecher to include a dialog box to choose which volume was to be cleaned. Bill Pugh's orginal just cleaned the Startup Volume. It is possible that Brecher's souped-up version would work better under HFS than the original. [ This program has been be posted - Jeff ] Re: Gutfreund (graphic representations) The proceedings of SIGGRAPH '83 (?? not sure which year) contain a very interesting talk about cartography which goes into some detail about how cartographers choose the appropriate level of detail for maps at various scales. I recall also an article by Frank Crow (Ohio State University) about rendering objects whose structure contained components of widely differing sizes ... the objective being to avoid doing hidden surface rendering of an object which would be of sub-pixel size in the current view of the scene (for example). ------------------------------ From: BRECHER (6658) Subject: Re: How to clean up an HD20 desktop Date: 20-MAR 05:28 MUGS Online There are multiple versions of PurgeIcons floating around. The one I hacked to provide a dialog box allowing you to select the volume to be purged seems to work OK for me on an HFS volume (128K ROM, System 3.1.1). However, in order for the "Purge" button to be enabled, the program must be run from the root directory, since the dialog box is really an SFGetFile box with the file list hidden, and SFGetFile/HFS starts with the default (application) directory. ------------------------------ From: BRECHER (6659) Subject: Re: sending a Break on Mac+ Date: 20-MAR 05:28 MUGS Online The signal used to tell an application that a break is to be sent is entirely application-dependent; hence there is no way to send a break with Versaterm and the Mac+ keyboard, except to patch the application to change the keycode that is associated with the Enter key. On the old keyboard the keycode is 52 decimal; assuming that the keypad on the Mac Plus keyboard sends the same keycodes as the original numeric pad hardware option, Enter's new keycode is 76. (I can't be of any help with regard to VersaTerm specifically.) ------------------------------ From: BRECHER (6660) Subject: Re: Macintosh Hard Drives Date: 20-MAR 05:29 MUGS Online External drives connected through the floppy port (HD20) or serial port ( MacBottom) will be considerably slower than internal drives or properly-driven external SCSI drives. If speed is a criterion, forget Warp 9; it uses basically the highly inefficient MacSCSI driver software (it also requires a boot floppy). For speed among currently-available internal drives, consider HyperDrive or MicahDrive. Informal tests reported to but not verified by me indicate MicahDrive to be somewhat faster. The MicahDrive uses 1:1 sector interleave (i.e., no interleave); I believe that current HyperDrives use 2:1. Claimer: I wrote the MicahDrive ROM/driver/manager. ------------------------------ From: BRECHER (6661) Subject: Re: SCSI disk drives Date: 20-MAR 05:29 MUGS Online The following are the external SCSI hard disks I've seen advertised: AST Colossus (70MB, with tape backup) Iomega, Bernoulli Boxes, 10MB -- 40MB, removeable media MDIDeas, 20MB LoDown, 20MB SuperMac DataFrame, 20MB I haven't seen any Mac SCSI floppy disks (technically, the Bernoulli Boxes use floppy media; but they perform like hard disks). SCSI is an interface to the disk controller (more generally, it's a bus specification, and the disk controller attaches to the bus). Typically a drive manufacturer (taking your phrase literally) sells only drives, not controllers, to OEMs who put together disk subsystems. Some drive manufacturers, however, are starting to offer drives with integral SCSI controllers. To such a combo the OEM must add a power supply, box, cables, and software. For a disk with a SCSI controller to be useable on the Mac it must have the proper cable to connect to the Mac's SCSI port, and it must have a Mac device driver. For it to be directly bootable, the driver and certain other code and descriptive information must be written on the disk in the format expected by the 128K ROMs. ------------------------------ From: PEABO (6653) Subject: Re: baud rate discussion & internal Mac hard disks Date: 20-MAR 00:13 MUGS Online Re: baud rate discussion ... with some careful programming using DrawString instead of DrawChar, it is possible to run a terminal program at about 4800 bps, I think. The point of the slowness of the Mac is that when you compare a Mac program against a VT-100 at the next desk, the Mac seems sluggish. Either one will pause from time to time during use of a full screen editor due to timesharing service of other users, but the VT-100 is pretty crisp at 9600. And even more so at 19.2kbps. Re: internal Mac hard disks ... Hyperdrive vss. Warp 9 ... don't forget the MicahDrive AT when doing your shopping. peter ------------------------------ From: FREDDYO (6644) Subject: HARDWARE Date: 19-MAR 20:26 Hardware & Peripherals Anybody got any ideas on what neat usage (Be nice now!) that I might make of a Diablo 1650 previously configured as a terminal for a Big Blue? With all those circuits, etc. I would hate to have it's usage limited to being a VERY heavy letter quality printer. ------------------------------ From: RICFORD (6645) Subject: Re: Record Holder Date: 19-MAR 21:54 MUGS Online In reply to John Major's question about Record Holder, we did a mini-review of it in the February issue of "MacInTouch," concluding that it was surprisingly good for the price and well suited to many smaller data management tasks. Ric Ford ------------------------------ From: RICFORD (6646) Subject: L.W. crashes Mac Date: 19-MAR 22:01 Bugs & Features Anyone else having this problem? When the Mac is running, idle, and I turn on the LaserWriter, the Mac crashes with ID=02. The System is 3.1, the Finder 5.2, and the 4.0/4.1 AppleTalk installer indicates that I'm up-to-date there. Ric Ford ------------------------------ From: PEABO (6670) Subject: Re: Servant and Andy's idea for opening a document Date: 20-MAR 23:38 MUGS Online I hope he doesn't abandon the double-click method! It was pointed out at the BCS MacTechGrp meeting yesterday that it would be a serious hassle to have to open up the folder containing the application just to drag a document icon on top of the application to run it. peter ------------------------------ From: PEABO (6671) Subject: Re: InfoMac posting & MacTerminal question Date: 20-MAR 23:51 MUGS Online Re: InfoMac posting ... The December 85 Software Supplement (shipped in March 86) contains MDS Edit 2.0 which runs under HFS, and also contains instructions on how to patch the other MDS programs. Re: MacTerminal question I have always assumed that the CNFG resource contains the various settings which are remembered from session to session, and that the Prec resource had something to do with printing. The LPtr resource gets large in proportion to the size of the text saved off top, and apparently contains pointers to the beginnings of lines in the text. I don't have any idea what DStt is. peter ------------------------------ From: BRECHER (6675) Subject: Hard Disk Benchmark Date: 21-MAR 05:48 Hardware & Peripherals I wrote a simple disk performance benchmark program and have submitted it along with its MDS assembler source code to the Hardware database. The test is designed to measure hardware and disk driver performance, with no influence from the file system (HFS/MFS) or volume/file/Finder configuration. The program issues I/O requests directly to the disk driver. The benchmark consists of three parts: (1) 100 reads of 32KB of data from the start of the volume; (2) 100 writes of 32KB of data to the start of the volume; --the above two tests measure data transfer speed; 32KB was chosen to be a reasonably large chunk, but not so large that it would cross a cylinder boundary (thus not requiring any head movement). (3) 40 iterations of: read one 512-byte block from an offset of 1MB, followed by read of one 512-byte block from start of volume; --the above test measures access time, i.e., seek or head movement speed. The test is non-destructive -- test (2) writes the data that was read in test ( 1). Test (3) is bypassed if the volume size is less than 1MB+512bytes. The volume tested is that from which the program is run. So far, the program has been run on three drives, with the following results ( times are in ticks, i.e., sixtieths of a second): Data transfer time Access Time ------------------ Reads Writes DataFrame 20 1344 2233 487 HyperDrive, (see note) 1586 1600 563 MicahDrive 20 AT 507 508 528 Note: HyperDrive is original 10MB unit with old controller and version 5.1 software; current models are said to be faster. I encourage those with access to other hard disks to report results with this benchmark. On a Mac Plus, make sure disk caching is disabled in the Control Panel. [ This program has been be posted - Jeff ] ------------------------------ From: BRECHER (6700) Subject: RE: Hard Disk Benchmark (Re: Msg 6686) Date: 22-MAR 03:43 Hardware & Peripherals You're right; the benchmark is *designed* to be non-destructive, but it is potentially destructive if things go wrong (as they did for one ICONtact member who had his HyperDrive Startup drawer trashed). BTW, the HyperDrive reported on in the initial results I posted was my own. I doubt that the DataFrame is doing a read-after-write. If it were, I think the write time would be more than twice as long as the read time (2x plus rotational latency). MicahDrive and DataFrame use the same controller; I also had a "slow-write" problem during a stage of MicahDrive development... The MicahDrive driver does not do a verify on a write request. It does do a verify (not a byte-by-byte comparison, but a read with ECC verification) if the verify bit is set in the _Read trap word. This is a standard Mac disk driver facility, documented in the Disk Driver chapter of IM. ------------------------------ From: NANOCHIP (6701) Subject: RE: Hard Disk Benchmark (Re: Msg 6700) Date: 22-MAR 04:01 Hardware & Peripherals Steve> DiskBench benchmark times for Tecmar MacDrive (10Meg Fixed). Data transfer time Access Time ------------------ Reads Writes Tecmar MacDrive (10M Fixed) 6017 6719 401 MicahDrive 20 AT 507 508 528 Performed on a Mac+ (System 3.1.1) with DiskCaching disabled. I couldn't *believe* the difference... performed the benchmark a _number_ of times...just to be sure. The numbers speak for themselves :-) . Wow.