[net.micro.mac] May SS: "Future Mac Architectures"

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.