68020 Programming Considerations

By By Our Readers

The WSM Group provides a Hyper-C and asm development system for the Macintosh with the unique feature that the complete source code to the system is also available at a very reasonable price. Contact them at (602) 298-7910. This tech note is valuable as we canticipate the next Mac family of 68020 based systems.

As one of a fortunate class of Macintosh programmers, I have had the enjoyable opportunity to run a 68020 MPU chip in my Macintosh. Initial investigations show, however, that a number of incompatibilities exist between the 68000 and the 68020 in spite of the claim that the 68020 is "upward compatible" with its ancestors. This paper addresses a few of these of these claims and offers some suggestions for the future, as well as some patches for the present...

Welcome to the Future

The exceptional processing of the 68020 is considerably more complex than that of the 68000. The stack frame produced as a result of calling a TRAP or receiving an interrupt includes a format word beneath the saved PC (and possibly a bunch more information as well...). The RTE instruction of the 68020 expects to see this format word.

Many of us have written code which saves the current status register contents on the stack on entry to a called routine, and as a shortcut, we execute an RTE which restores the old status register and performs an effective RTS all at once...well, it used to... Now, with the requirement for the format word beneath the saved PC, this trick no longer works - the stack can get out of sync and a format exception can be generated. So unless you are responding to an actual exception condition, don't play this RTE trick anymore!

Along the same line, many programmers attempt to augment the instruction set of the 68000 by making use of the TRAP instruction. On receipt of the exception, they simply add 2 to the stack pointer to remove the saved status register, then proceed as though the routine were simply called by a JSR. This does not work any longer because the TRAP leaves a word or frame format information beneath the saved PC. MacWrite 4.5 is a particular offender here, as is MacFORTH. There may be others as well - we have all used this technique at one time or another - in the future, be sure to take account of the format of the frame, or don't use this technique.

Several popular programs (including the Mac ROMs) make explicit or implicit assumptions about the speed of execution of various code patterns, either for time delay loops or for SCC accessing which has internal setup delay requirements. The 68020 has an internal cache of 128 words and a pipelined architecture. Both of these, coupled with the varying overhead of memory accesses at different byte alignment boundaries, makes the timing of 68020 instructions impossible to predict, as well as being much faster than the older 68000 for the same clock frequency.

This means that you should neither use instruction sequences nor loops to produce timing delays, especially if the delay has a critical lower bound as in SCC accessing! Even if the internal cache is disabled, you still have a pipelined architecture which overlaps instruction execution, thereby increasing the speed of execution. The 68020 also completes each bus cycle in 3 clocks, instead of the 4 clocks which was characteristic of the 68000. MacinTalk and many sound generation programs behave poorly here.

In general, you should not assume that the exception vectors for the system are located in the page beginning at absolute address zero. They always were for a 68000, but the 68020 allows them to be located anywhere since it maintains a vector base register internally. If you need to intercept an exception, you should first locate the vector page by reading the VBR with a MOVEC instruction. (But don't do this until you conform to the aforementioned exception protocol requirements.) Read below about current patches.

Surviving with the Past

Because of their daily importance to many of us, the older programs such as MacWrite 4.5 must be handled with care in a 68020 environment. MacPaint and MacDraw appear to be OK. Here is the solution which we found to work for this one example program. Other programs such as MacFORTH may have different requirements.

MacWrite 4.5 uses TRAP instructions to enhance its instruction set. In particular it uses TRAPs 0..4/6..9. In all except the case of TRAP 9, it assumes that it can simply remove the saved status register by incrementing the stack pointer by 2, then continuing as if called by a JSR. In the case of TRAP 9 it behaves properly by executing an RTE at the end of a very short instruction sequence. (The rationale for this one escapes us. Apparently they need a special instruction to increment a single register and force an alignment of some sort.)

The 68020 Solution

Fortunately, the 68020 allows us to intercept these poorly handled TRAP calls by allowing us to generate another vector page. MacWrite alters the TRAP vectors in the original zero-based vector page. By creating a second vector page, and changing the internal VBR of the 68020, we get a first shot at all exceptions - including TRAPs. For the sake of MacWrite, our interception code for the TRAP 0..8 should adjust the stack frame produced by the exception so that it looks just like the ones generated by the 68000. Once this is done, we can permit MacWrite to continue by vectoring through its vectors in the page 0 table. (Fortunately, MacWrite does not alter the vector handling on the fly from one which ignores the exception to one which returns with an RTE, or vice versa).

All other exception vectors in this new vector page should point to intercept code which in turn vectors through the vectors in the page 0 table. This allows any alterations to the I/O interrupt vectors to be accommodated without requiring the programs to know about our new table.

The one vector which should be handled directly is the 1010 exception vector used to access all ROM routines. Direct handling of this one seems safe since it never (?) changes and any additional vectoring indirection would cause undesirable runtime overhead.

This solution works well for us. It is a tribute to the architecture of this superb chip that a solution is even possible. As far as we can tell, all other instructions are upward compatible with the older 68000.

We do not yet have a solution for programs which generate sound such as MacinTalk and music synthesis programs. The voice and tones are very garbled and gravelly. We have found, however, that they sound better (but not correct) when the 68020 internal cache is disabled.

Congratulations Apple

Apple is to be commended for their efforts to look to the future. The 128K ROM code appears to be safe in all areas except for mouse SCC interrupt handling. It is remarkable that Apple did not shortcut the ROM code with respect to other exception types, expecially 1010, in light of the need to maximize performance. We look forward to a recoding of the ROM to take into account the bitfield instructions of the 68020, effectively the inner guts of Bill Atkinson's Blitter in the chip. Graphics should really scream then.

In the case of the SCC handling, the Apple ROM code made some implicit assumptions about the speed of execution of their ROM interrupt handler for the SCC. As it happens, this code executes on the hairy edge of being too fast on some Macintoshes, while on others, it is definitely too fast!

Our solution was to install a new interrupt handler during boot time which assures that SCC accesses cannot happen closer in time than 2.2 usec. The way we did it was to force a RAM data memory access with a "MOVE.L (SP),(SP)" instruction placed at strategic spots in the interrupt handler. The internal cache of the 68020 does not cache data, it only caches instructions. The RAM timing of the Macintosh assures that this will take at least about 2.2 usec. to execute 1 read cycle/1 write cycle.

The MC68020 with its 68881 math coprocessor are a welcome addition to the Macintosh. Initial benchmarks show that the internal instruction cache can make as much as a 2:1 speed difference when switched on vs. when switched off. Even with it off, the 68020 is definitely faster than the 68000.

We have run Smalltalk under the 68020 with quite favorable results, and it's quite pleasant to use now. We have yet to take full advantage of the 68881 math coprocessor. We expect a result several thousand-fold faster than SANE in software... P.S. You should see Life run with this chip! Our thanks to Jeff Brooks of Spectra Corp. for inviting us to participate in the testing of his 68020/68881 subsystem.

SpaceExtra Needs 32-bit Fixed Argument

James G. Haberly

In this note, James fixes an error in Inside Macintosh and reminds us of a useful ROM call for text manipulation.

When attempting to produce fully justified text (both left and right margins), the "SpaceExtra" trap is a great help. Of considerably less help is the documentation. According to The Bible, "SpaceExtra" needs a 16-bit integer argument. It is quite obvious that this portion of The Bible was written by a heretic. "SpaceExtra" needs a 32-bit fixed argument (normally produced by "FixRatio").

How many compiler writers have assumed that The Bible was correct and moved a 16-bit argument to the stack? Check your favorite software package and see what it does. Fortunately, the error was not too difficult to find. Set TMON to stop the next time that "SpaceExtra" is used, look at the stack, step once, and then look at the stack. A 32-bit argument is now missing, not a 16-bitter.

Final note on this bug for Mach2 users, (which is where I found it): if you do change the amount of extra spacing between words to print fully justified text, change the setting back to zero before you try to use Mach2's main window for normal input and output. The cursor does some very strange things otherwise.

PostScript Banner Program

James Haberly

In this pair of notes, James gives us some useful Postscript programs. Since our previously published Laser Print DA doesn't work on a Mac Plus, we will pay $100 to the first submission that re-writes it so it will work. There are two problems: first, the PAPSTATUS call now requires three parameters in the new ROMS, so a third parameter must be added. Second, the name of the currently selected LaserWriter is now contained in the file LaserWriter, not in the system file, so an open resource must be done to fetch it. See Volume 2, Number 2, Feb. for the complete source code.

Imagewriter banner programs tend not to work with the LaserWriter. Here's a very simple PostScript program that will produce large banners (500-point fonts; one character per page). You need the Laser Print DA to be able to send the file to the LaserWriter, or use Bob Denny's PAP driver by including the Postcript in a simple Pascal or Basic program, or just use MacWrite with the Postscript Escape font from the June issue of MacTutor. The letters are outlined and filled with a light gray pattern because sending an all-black letter to the LaserWriter uses significantly more toner. Only one change, replacing "Text to be printed" with your message is required. [If using Postscript Escape, include gsave initgraphics at the front and grestore at the end to switch coordinate systems. Otherwise, text comes out upside down.]

% Haberly: Laser:Banner

% This file takes a string of characters and prints
% them on a one-per-page basis using 500 point 
% Helvitica. The characters are outlines and filled.

% How to use:
%     "Text to be printed." should be changed to 
%      whatever you want turned into a banner.

/banner {
 /strg exch def
 0 1 strg length 1 sub {
 150 200 moveto
 strg exch 1 getinterval
 false charpath
 .8 setgray gsavefillgrestore
 0 setgraygsave  stroke grestore
 showpage
 } for
 } def
/Helvetica findfont [500 0 0 600 0 0] makefont setfont

% Change this next part to create a banner.
(Text to be printed.) banner

Anyone who has purchased the PostScript books from Adobe has seen the shaded headings that adorn each chapter. They look quite nice on report chapters, so here is a simple method of producing your own shaded headings. Replace (Text to be printed) with your own heading, and send to the LaserWriter using the Laser Print DA or use a Postscript Escape font in MacWrite.

%!Postscript Haberly 5/21/86

% This file prints a chapter heading on a shaded background.
% Replace "SIO Per Second" in the next line with 
% whatever you want to have printed.

/boxMessage (Text to be printed) def

/boxLength 3 def
/boxHeight 60 def

/Helvetica-Bold findfont 30 scalefont setfont

/nextBox {
 boxLength 0 rlineto
 0 boxHeight rlineto
 boxLength neg 0 rlineto
 closepath} def

/intervals 150 def

1 1 intervals {
 dup 1 sub boxLength mul 72 add  %x coord
 8 72 mul %y coord
 moveto nextBox
 intervals div setgray  %change shading
 fill
 } for

intervals boxLength mul 72 add
boxMessage stringwidth pop sub 5 sub % x coord

8 72 mul boxHeight
boxMessage stringwidth exch pop 2 div
sub 3 div add  %y coord

moveto  %start ms here

0 setgray
boxMessage show  %show the header

showpage

Adapting MIDI and T'Scan devices to Mac Plus

Ronald Spicer

Here is a handy source for the Mini-Din connector for those of you who want to wire your own Mac 512K to Mac Plus cable. (As with all hardware, use at your own risk. We haven't verified this material.)

After buying a Mac Plus, a friend and I soon discovered that one of the common MIDI interfaces and the Thunderscan no longer worked. Through testing, the differences were discovered to be the lack of the +12VDC line, and that the +5VDC was moved to pin 6 on the adapter cables. To remedy this, an adapter must be made to include these two voltages. The following solution costs about $18 to build, as opposed to $50 to get your Mac Plus 'converted'. Warning: do not connect these devices to a mac Plus unless the adapter is modified.

Parts / Suppliers

1 ea. 8 pin MINI-DIN, pre-wired to 6 ft. of cable, $9.95 from Advanced Computer Products, Irvine CA.

1 ea. DE-9B connector and shell, standard, from Radio Shack.

1 ea. power supply outputs at +5 and +12 volts DC approx. 200ma. each, $4.95 from Radio Shack, catalog #277-1022. This is a Coleco power pack for their arcade game. The -5 volt line should be cut and taped off.

1 ea. 8 conductor cable (choose your own length).

Any further questions, contact Ron Spicer, PO Box 411, Surfside, CA 90743.

INTERCONNECTION LIST

(If using listed parts, then color codes match)

Macintosh Fortran Compiler Bug List

Pete Mahowald

The following bug reports generally apply to version 2.1. Microsoft has now released version 2.2 and we would like to know how many of these have been fixed in the new version. Please report your findings to MacTutor so we can share them with our readers.

Summary of Bugs/Caveats/Suggestions

1. Output from compiler program scrolls off screen.

2. Display card at run time option means card numbers are included in the error message. Should be clarified.

3. If 2.1 crashes during a compile, it leaves files which can be removed only by rebooting the computer. This is true of the 2.2 linker, librarian and compiled applications, but not the 2.2 compiler. All applications should be fixed.

4. Control C during compile first stops the compiler (like the VAX) and then starts it (since control C is the keyboard equivalent for compiled). This is unexpected.

5. Run time errors give the line numbers with respect to the first line of the subroutine, but they do not say which subroutine they occur in. Need better identification.

6. Include is sensitive to trailing blanks. Shouldn't be.

7. Printer and modem ports are inaccessible. Should be!

8. Include statements cannot be nested.

9. Control S and Control Q don't always work during program execution. Control decimal won't always stop program execution.

10. Error messages from the compiler during run time can be invisible if the cursor was left on the bottom or right hand side of the screen.

11. The Macintosh disks are not utterly dependable, and occasionally bugs creep into the compiler, run time library and operating system. Keep a backup, and if it does strange things, copy the backup onto the working disk.

12. Stop statement with a message following will not be seen since it will exit directly to the finder. End statement should pause.

13. Cannot allocate the heap based on machine size. Very little information is given about how big the heap should be. It should be equal or greater than the local storage plus code of any loaded subroutine, however this information is not readily available. Program won't run on huge Mac due to heap space, yet this is not obvious. Appears broken.

14. Array checking doesn't always check the lower bounds.

15. Dynamically loaded routines must be self contained, and cannot reference routines in the root section.

16. The error message reporting subroutine which is an option in the Program statement cannot process all of the various types of errors! A frustrating example of poor quality.

17. Dynamically loaded routines will be reloaded each time they are used, unless they are recursive, even if they were just loaded.

18. Compiling a program with a missing format statement label will cause the compiler to crash if the operating system is HFS.

19. The debugger will not restore the cursor when it regains control from the user program. Thus if your program calls HIDECURSOR, you cannot use the cursor in the debugger.

20. Under MFS, it will not put the symbol, list and applications files in the same folder where the source came from.

21. Unit 9 does not respond to Fortran Carriage control. The first character is not trimmed off and used to get a new page, double spaced line, or typing on the same line.

22. There is no cursor for data entry.

23. Control S. and Control Q have opposite meanings under the debugger and while the program is executing.

24. Debugger crashes a lot.

25. In the debugger, holding down the scroll arrows (distinct from clicking them occasionally) causes the program listing window to scroll incorrectly. It moves the cursor but forgets to move the text until the arrow is released.

26. Function names aren't in the symbol table and the debugger cannot display values returned by functions.

27. In the debugger, in the variable command, entering a different array element than one already in the list doesn't do anything.

28. Printing from the compiler cannot be stopped by a control decimal.

29. Neither the compiler nor any programs can use the LaserWriter! This is a glaring omission.

30. The compiler diagnostic "unterminated DO loop in program unit" doesn't include the name of the program which generated the error.

31. In the linker, capital letters do not always work correctly.

32. First file-not-found is fatal for the linker. (Either script file or object files).

33. Can have only one entry point per file in the linker.

34. F77.RL must be specified in small letters.

35. Incorrectly states the number of unresolved external references. It actually reports the number of resolved external references.

36. Debugger doesn't always know the maximum size of arrays.

37. End of record and end of file when using unformatted sequential files are ignored.

38. Script files for the compiler and the linker are quite different in format.

39. Compiler isn't shipped with HFS system, nor with the best choice of MFS systems.

40. Linker should have a transfer command where it executes the file it just linked.

41. Fortran maps don't have array sizes and dimensions.

42. If Errmsg.sub is linked, the linked copy is not used.

43. Bug box for list compile obscures error messages.

44. List compile cannot be stopped once in progress.

45. No error message if f77.rl is not linked and not found.