jww@sdcsvax.UUCP (Joel West) (07/25/85)
> The "May" supplement finally arrived today (posted July 22 via > UPS). It was about 250 pages and 13 disks (7 Mac, 6 Lisa). There are several things in the "May" software supplement that hint at future products. One talks about using Quickdraw so that the Laserwriter works right; another refers to how to use printer drivers so that the Imagewriter II will work right. But the most interesting thing is "Future Macintosh Architectures", which is what we all want to hear. I'd like to paraphrase highlights for the benefits of those who don't get the supplement. (The parenthetic comments contain opinions not directly correlated to Apple's). If the answer to any question is "YES", you may be in trouble with a future product. I'm skipping some boring ones. 1. Do you use any 68000 supervisor mode instructions, including changing the interrupt level? Location $12F has 00 for a 68000, $01 for a 68010, or $02 for 68020. 3. Do you twiddle low-memory (0x00 to 0xFF), except as documented? 4. Do you assume: a. The size of an File Control Block? It will get bigger for "a more sophisticated file system". The 30 existing bytes won't move. b. The layout of a directory or allocation map? (same reason) c. Customer code in boot blocks? Use INIT resources instead. 5. Do you allocate system heap, particularly large stuff? The size of this will change on the 128 and 512, so don't count on much space... 6. Don't count on using instructions that work within 1st 32k... (more globals and stack space are planned.) 8. Access VIA, SCC or IWM directly? A MMU (may) map such direct hardware addresses and force you to use a subroutine call to get at them. For god's sake, at least load their address indirect from global memory. 9. Assume anything about screen bit map? it will move and get bigger. 28. Depend on a second screen buffer? "The machine may not support a second screen at all". 10. Do you work on a Mac XL? If not do you know why? (If you can't support a known Mac product, your chance on an unknown one are slim.) 12. Do you check explicitly for 128k, 512k, or 1M? Don't count on it. An address could be up to 16M. 13. Do you fail with non-Apple hardware or desk accessories? You might have a problem with future Apple stuff. Please call us. 14. Do you expect to free memory by purging system resources from RAM? (They are moving to ROM.) 15. Is your code timing sensitive? Future machines "will run at a faster clock rate." Try the VIA timer 2 or Tick Count instead. 16. Do you have writable data blocks in your code? 17. Do you read the keymap instead of ASCII? (All bets are off.) 21. Do you depend on existing side effects (bugs) in: RectInRgn PinRect Cursor with hot spot outside cursor? Use HLock, HPurge, etc. on non-handles? 22. Use Command-Shift 5,6,7,8,9,0? 24. Place text outside resources? Assume ascii is only 32-127? Use time, currency, etc. without using international utilities? (You might as well write off France, the #2 Mac market...) 26. Assume anything about disk driver? "Apple's announced hard disk drive for the Mac as well as an enhanced 3 1/2" disk drive will allow more and larger drives to be available to the user." 27. Use copy-protection scheme changing the disk speed? The enhanced 3 1/2" has an internal motor speed control. 29. Do you write to the serial printer directly? You screw up Appletalk and won't work with the new Imagewriter 30. Does it fail as a startup application? You probably screwed up in your initialization calls. It doesn't say anything about making assumptions about color, although QuickDraw and other places do. Hmmmmm. VERRRRRRY interesting. Joel West CACI, Inc. - Federal (c/o UC San Diego) {ucbvax,decvax,ihnp4}!sdcsvax!jww jww@SDCSVAX.ARPA
brad@gcc-bill.ARPA (Brad Parker) (07/27/85)
In article <1010@sdcsvax.UUCP> jww@sdcsvax.UUCP (Joel West) writes: >15. Is your code timing sensitive? Future machines "will run at a faster > clock rate." Try the VIA timer 2 or Tick Count instead. > will allow more and larger drives to be available to the user." Humm... The AppleTalk drivers are full with processor speed dependant loops. They were, however, the first Apple code I noticed which dropped RTE's are a method of restoring the CC's (a 68010/20 anticipatory move). Interesting... -- J Bradford Parker uucp: seismo!harvard!gcc-bill!brad "She said you know how to spell AUDACIOUSLY? I could tell I was in love... You want to go to heaven? or would you rather not be saved?" - Lloyd Coal
peterson@utah-cs.UUCP (John W Peterson) (07/28/85)
> 28. Depend on a second screen buffer? "The machine may not support > a second screen at all". Yikes. I hope apple has the good sense not to throw this one out - a double-buffered screen is one of the more fundamental tools in interactive graphics. I've seen several very clever Mac applications that make good use of it.