MacForth 4.2
Volume Number: | | 8
|
Issue Number: | | 1
|
Column Tag: | | Jörg's Folder
|
MacForth 4.2 & Other Forth News
By Jörg Langowski, MacTutor Regular Contributing Author; Neil Ticktin, Editor, MacTutor Magazine
Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.
MACH2 Update
As many of you already know, Palo Alto Shipping has all but formally abandoned MACH2. Users that call Palo Alto Shipping for technical support report that no one answers the phone and that messages are not returned. As a result, for those of you out there who still use MACH2, MacTutor suggests that you may want to look elsewhere for your Forth needs. [Weve arranged with Creative Solutions a trade-in of MACH2 for MacForth for all MacTutor readers. To take advantage of the offer, you will need to send Creative Solutions your original MACH2 disks and $99. The offer is good through May 31, 1992. - Ed.]
MacForth® 4.2
Creative Solutions, Inc. (CSI) has been shipping a long standing Forth product for Macintosh since February, 1984. In January, 1992, CSI announced a new version of MacForth® Plus - Version 4.2. As far as we know, MacForth is the only commercial Forth compiler for Macintosh at this time. But even if it was in a crowded marketplace, it would stand out. Compared to products such as MACH2, MacForth is a very full-featured product. But more importantly, MacForth is published by a company that has a strong commitment to Forth and to supporting their users.
MacForth Plus features a built-in text editor, assembler, turnkey compiler, high-level toolbox support, extensive debug tools, a 500-page manual and many optional tools disks. Additionally, many popular software programs like Swivel 3D, Hidden Agenda, and Voyager are written in MacForth. MacForth was originally written by Don Colburn in 1984. CSI has provided updates to support all the major changes through which Apple has taken the Macintosh line. The current release was written by Xan Gregg, a third party developer, and features the following.
High Level Event support, core Apple Events handled through a built-in editor. High Level Events (HLEs) are supported through kernel additions and the extension file AppleEvents. A constant HIGH.LEVEL.EVENT = 23 was added, and the constant IN.CLOSE.BOX was changed from 23 to 26. Any code that depends on IN.CLOSE.BOX being 23 will have to be changed. The most recent HLE is stored in HIGH.LEVEL.EVENT.RECORD, which is much like MOUSE.DOWN.RECORD and KEY.STROKE in that the record is padded by two bytes at the beginning. HLEs are buffered by MacForth-like key events, which means that no HLEs will be accepted until the last one has been processed. The actual HLE handling is done by words in the extension file, which was first written by George Furnival.
Among other things, MacForth Plus Version 4.2 adds the following:
68040 Compatibility.
PPC interface for System 7s Program-to-Program Communication
MacsBug interface, allows high-level debugging of MacForth in MacsBug.
Offscreen GWorld support.
CSI graphics allowed in non-MacForth grafPorts.
Editor enhancements.
Updated On-line Glossary.
Increased tokens via a new Indirect Kernel.
Gestalt is now always available, on any machine.
PaperHi now uses HiPrinting to print listings.
SetPort trap used when changing ports (i.e., (WINDOW)).
More Extensions files from Greg Guerin: Bitting, Lacking, Chain Ops, Easy SFP...
Local Names.
Miscellaneous kernel improvements: NIP, TUCK, CROPW, EXTENDW, <=, >=, 0<=....
Faster StripAddress implemented as per Mac Tech Note #213 which improves compile times.
MacForth uses less time when in the background.
Extra A5 globals allocated.
Bug Fixes...
MacForth Plus now can generate small stand-alone code fragments. You can write XCMDs, drivers, FKEYs, and so on. A trivial example, creating an FKEY that beeps, is given in the manual:
: beeper 30 sysbeep ;
When you execute that code, it beeps on execution. When you then write:
SA beeper
MacForth creates a stand-alone code fragment that has the same behavior as the word under the Forth system. That means, since MacForth uses token-threading, it adds a mini-kernel to the Forth code which executes the tokens. It will also add code to set up the registers for the Forth world and restore them after execution to their old values. A handle to the stand-alone code segment is contained in the global variable sa.handle, so to test your FKEY you write:
sa.handle ascii FKEY 5 Beeper add.bag.resource
and Cmd-Shift-5 will beep at you. The resource bag to which the FKEY is added by add.bag.resource, is a resource file that MacForth opens on startup and which contains your custom resources that your program might need. Resources can be added and deleted from that file during a development session.
Stand-alone code is just one example of the multitude of features of MacForth. A way of object-oriented programming with message passing and inheritance is supported through the use of Actels (for active elements), and MacForth vocabularies themselves are such actels.
Another very interesting and useful concept used in MacForth are relative chains. This is a kind of linked list, and it is used in the MacForth kernel in a number of places. For instance, there are the so-called Restorer and Exodus chains. These are lists of words to be executed at startup and exit of the MacForth system, so you can easily add setup and cleanup routines. The Eventer chain can be used to add special-purpose event handlers. It is executed in the main event loop: the first word in the chain receives an event code, decides what to do with the event, processes it or not, and then passes on a flag (true if processed and false if not) and a new event code to the next word in the chain, and so on until the end of the chain is reached.
In addition to MacForth, Creative Solutions has been a key supplier of development tools for the Macintosh and other 68000 based computers since 1980. They currently provide a line of add-on boards for the Macintosh II and SE/30 that provide prototyping tools, serial, parallel extensions, SCSI communications, and other custom designs.
MACH2 Patch for Better System 7 Compatibility
Steve Wiley, a MacTutor reader in Utah, has done Palo Alto Shippings work and figured out a set of patches to Mach2 (2.14) which make it compatible with System 7, although not System 7-aware.
Jörg, I would be glad to document the changes and how to make Mach2 System 7 compatible. Mach2 is still not 100% compatible. The debugger will not work, I think because they changed some of the interrupt vectors in System 7. This is not a problem [if you] use [a debugger like] TMON professional for debugging. This works very well with MACH2.
Below I have described how MACH2 can be modified to run properly under System 7, and still remain compatible with older systems. There are three major incompatibilities with the current version (2.14) of MACH. The first is that MACH 2 is not MultiFinder aware. The second is that MACH expects Monaco 9pt font to be a standard system resource (not true under System 7). The third involves changes in the System 7 interrupt vectors that cause MACHs resident debugger to crash. [The fourth problem, as you will see below, is that Mach2 does NOT run with virtual memory under any circumstances at the moment. This is a serious drawback, e.g., compared to MacForth, and cannot be fixed by simple patches, but needs major rewriting of the Forth system - JL].
The first two problems are easy to fix. The third cannot be easily patched, but is really not a problem since real debuggers (such as the excellent TMON Professional) are far superior to the limited built-in facility. My programming environment currently consists of QUED/M 2.09, MACH2 and TMON together with a few utilities written with MACH 2 itself. Under System 7, this is a great combination and works quite smoothly (especially with a Mac IIfx!)
The changes made in MACH2 have two aims. The first is to allow the programming system to run and compile under System 7. The second is to allow programs written and compiled in MACH2 to run properly. Since MultiFinder is always running under System 7, the most important change is to make MACH2 fully MultiFinder aware and compatible. This means implementation of WaitNextEvent instead of GetNextEvent as well as Suspend/Resume events. You published a nice article on the implementation of WaitNextEvent in MacTutor, but as pointed out by Murray Anderegg, this implementation assumed that the compile-time environment was the same as the run-time. A more ambitious effort to modify the main MACH2 IOTask to be MultiFinder compatible was provided by Murray Anderegg in an upload to GEnie, but his implementation also has limitations. Basically, Anderegg assumed that all sub-tasks in the MACH2 event loop are launched before the first execution of the main event loop. The main loop would then install default Suspend/Resume routines into each tasks. For small programs, this may be true, but is hardly likely in a more complex program. A more general (if inconvenient) approach is to simply install a Suspend/Resume handler into each task as they are activated. This is will always work and has the advantage that each task can use its own custom handler and do as much (or as little) as necessary during suspend or resume. A second problem with Andereggs patch was that he wrote a Suspend/Resume handler as if it was a pseudo Activate/Deactivate event. I found that this frequently crashed my programs. In my approach, I modified the Suspend/Resume routine published in the article by David Kelly and David Smith in the Feb. 88 issue of MacTutor. This routine may perform extra (unnecessary?) work, but I have found that it works under all testing conditions.
The following are the patches made to the IOTask code necessary to make MACH2 fully MultiFinder aware. Most of these changes were originally written by Murray Anderegg, with the exception of the DoSuspendResume code. These are the additions made to the IOTask code made available from PASC. [Additions see listing - JL]
After these routines and patches are installed, it is necessary to use ResEdit to modify the SIZE resource. This will allow the system to pass the appropriate events to MACH. Remember, there are two resources to modify. One is within MACH2 itself. This is the one which is used within the programming environment. The second is the MACH.RSRC file which will be included within the compiled and TURNKEYed application itself. Use ResEdit to open the SIZE -1 resource. Set Accept suspend events and Can background to true (1). The other settings should be set to false. Save the resource.
The next step is to install Monaco 9pt font into the MACH2 resource fork. This is the font that MACH uses for its interactive screen. Apparently, MACH checks for the availability of this font when it is first run. Since System 7 uses TrueType fonts, the absence of a true Monaco 9pt font resource in the system generates an error and prevents updating of the interacting screen. However, since the resource manager will always check the current application for the availability of a requested resource, we can circumvent this problem by directly installing this font into MACH itself.
Use Font/DA mover on a pre-System 7 Mac to create the Monaco 9pt file. Select Monaco 9 from the current system in the left scrolling window and click Open under the right window. When the standard SFGetFile dialog appears, click on the New button to create a file and copy the font into it. Close Font/DA mover and use ResEdit to copy the FOND and FONT resources from this file into the MACH resource fork. There is no need to copy this into the MACH.RSRC file.
While you have the MACH resource file open, you should use this opportunity to inactivate MACHs debugger since using this will crash the system. Simply open the DEBG resource (ID=1) and replace the number there (probably a 1) with zero. This will inactivate the debugger menu item and prevent accidental crashes.
These are all of the changes necessary to make MACH run nicely under System 7. I have used this configuration extensively for the last several months without any crashes or significant problems. There are still a few, mostly cosmetic problems that I have been unable to fix. These deal with the screen display and listing of loaded text. MACH issues a PAUSE command after the printing of every character to the interactive screen. Since the main event loop calls the WaitNextEvent every time a PAUSE is encountered, all open programs as well as the system under MultiFinder are given multitasking time for every character printed! This makes for extremely slow screen listings even when using a Mac IIfx!
I have used Waymen Askeys Trap Compiler to extend the MACH2 environment to use the new traps documented in Inside Macintosh Volume VI and to fix the infrequent bugs found in the old trap calls.
For more information, contact:
Creative Solutions, Inc.
4701 Randolph Road, Suite 12, Rockville, MD 20852
800/367-8465
AppleLink: CSI, CompuServe: GO FORTH
Retail Price: $199 for MacForth 4.2.
Upgrades sell for $39 - $69 to registered MacForth users depending on the version you are upgrading from.
Listing 1
// Constants, resource definitions, etc.
$60 CONSTANT WNETrap#
\ This is the trap number for WaitNextEvent.
$9F CONSTANT UnkTrap#
\ This is the trap number for Unimplemented.
308CONSTANT gInBackgroundOffset
\ offset in user area for notification
304CONSTANT SuspendResumeOffset
\ offset to task-specific routines
-1 CONSTANT TRUE
0CONSTANT FALSE
Header MFThere 1 ,
\ This resume notifies each task
\ of a Suspend/Resume event
: gInBackground! { truthValue | homeTask nextTask - }
STATUS -> homeTask\ point to each user area
homeTask -> nextTask
BEGIN
truthValue nextTask 2+ gInBackgroundOffset + ! \ notify task
nextTask 2+ @ -> nextTask
nextTask homeTask = \ loop through all tasks
UNTIL
;
: DoSuspendResume{ | wptr taskptr - }
EVENT-RECORD Message + @ activateMask AND
IF
FALSE gInBackground!\ signal tasks to resume
CALL FrontWindow -> wptr \ get front window
wptr 0= NOT
IF ( you have a front window )
wptr windowKind + W@ L_EXT 0<
IF ( this is a desk accessory )
EVENT-RECORD Modifiers + W@\ post an activate event
activateMask OR
EVENT-RECORD Modifiers + W!
EVENT-RECORD
CALL SystemEvent DROP
ELSE
wptr CALL GetWRefCon ?DUP
IF
wptr CALL SetPort
SuspendResumeOffset + @ EXECUTE \ execute tasks routine
THEN
THEN
THEN
ELSE
TRUE gInBackground! \ signal tasks to suspend
CALL FrontWindow -> wptr
wptr 0= NOT
IF ( you have a front window )
wptr windowKind + W@ L_EXT 0<
IF ( this is a desk accessory )
EVENT-RECORD Modifiers + W@\ post a deactivate event
$FFFE AND
EVENT-RECORD Modifiers + W!
EVENT-RECORD
CALL SystemEvent DROP
ELSE
wptr CALL GetWRefCon ?DUP
IF
wptr CALL SetPort
SuspendResumeOffset + @ EXECUTE
THEN
THEN
THEN
THEN
;
\ This is the patched event table
CREATE (EVENT-TABLE)
DC.L NextEvent-(EVENT-TABLE)-4
\ (0) Null event.
DC.L DoMouseDown-(EVENT-TABLE)-4
\ (1) Mouse down event.
DC.L NextEvent-(EVENT-TABLE)-4
\ (2) Mouse up event.
DC.L DoKeyDown-(EVENT-TABLE)-4
\ (3) Key down event.
DC.L NextEvent-(EVENT-TABLE)-4
\ (4) Key up event.
DC.L DoKeyDown-(EVENT-TABLE)-4
\ (5) Auto key event.
DC.L DoUpdate-(EVENT-TABLE)-4
\ (6) Update event.
DC.L DoDisk-(EVENT-TABLE)-4
\ (7) Disk event.
DC.L DoActivate-(EVENT-TABLE)-4
\ (8) Activate event.
DC.L NextEvent-(EVENT-TABLE)-4
\ (9) Not used ?
DC.L NextEvent-(EVENT-TABLE)-4
\ (10) Network event.
DC.L NextEvent-(EVENT-TABLE)-4
\ (11) Driver event.
DC.L NextEvent-(EVENT-TABLE)-4
\ (12) Appl-defined event #1.
DC.L NextEvent-(EVENT-TABLE)-4
\ (13) Appl-defined event #2.
DC.L NextEvent-(EVENT-TABLE)-4
\ (14) Appl-defined event #3.
DC.L DoSuspendResume-(EVENT-TABLE)-4
\ (15) osEvent.
: GetNextEvent ( - f )
\ If an event occurs which should be handled,
\ GetNextEvent will return a true flag. The event
\ code and any other event information will be
\ returned in the EVENT-RECORD.
\ Changed for MF support using Jorgs code 22 XI 88 \ - M. Anderegg
[] MFThere @
CASE
TRUE OF\ Yes, we have WaitNextEvent.
everyEvent EVENT-RECORD 1 0
WaitNextEvent
ENDOF
FALSE OF\ No, we dont have WNE
CALL SystemTask
everyEvent EVENT-RECORD
CALL GetNextEvent
ENDOF
ENDCASE
;
: WNECheck( - )
\ This routine is executed the first time through the
\ I/O Task main loop. It leaves the truth value for the
\ presence of the WaitNextEvent Trap at MFThere.
\ This modification is necessary, since Jorgs
\ modification worked at compile time instead of run
\ time. - M. Anderegg - 6\89.
WNETrap# CALL GetTrapAddress
UnkTrap# CALL GetTrapAddress
=
IF \ WaitNextEvent is absent
FALSE
ELSE
TRUE
THEN
[] MFThere ! \ store result as flag
;
\ Main event loop
: (IOTask) { | dialogflag eventflag - }
WNECheck
0 gInBackground!
BEGIN
BEGIN
GetNextEvent -> eventflag
DialogEvent? -> dialogflag
dialogflag
IF
HandleDialog
ELSE
eventflag
IF
HandleEvent
THEN
THEN
eventflag 0=
UNTIL
PAUSE
AGAIN ;
( Each task written by the programmer must include an Resume/Suspend handler to be run by this code. This handler is installed in the same fashion as overriding the default event-handling. After each task is ACTIVATEd, but before the main task loop is encountered, the routine address is obtained by ticking and stored in the appropriate USER offset location where it can be found by the IOTask. )
\ User variables used to communicate between
\ program tasks and the IOTask
308 USER gInBackground
304 USER SuspendResume
\ these routines are Global and can be used
\ by all the tasks in a program
GLOBAL
: DoResume { | wptr - } \ generic resume code
CALL FrontWindow -> wptr
wptr CALL SetPort
;
GLOBAL
: DoSuspend { | wptr - }
CALL FrontWindow -> wptr
wptr CALL SetPort
wptr $10 + CALL InvalRect\ invalidate window
;
\ Example of a task-specific Suspend/Resume handler
: DoMyS&R
gInBackground @
IF ( a suspend event )
DoSuspend\ execute global routine
\ task-specific code goes here,
\ such as converting a clipboard or fixing a menu
ELSE ( a resume event )
DoResume
\ task-specific resume code goes here
THEN
;
\ The following shows how the task-specific Suspend/Resume handler should
be installed.
: Start-Task
ACTIVATE
( other code etc )
[] DoMyS&R SuspendResume !
\ store the suspend/resume handler
( other code, event loop, etc )
;