INFO-MAC@SUMEX-AIM.STANFORD.EDU (Moderator Dwayne Virnau...) (07/13/87)
INFO-MAC Digest Monday, 13 Jul 1987 Volume 5 : Issue 106
Today's Topics:
A note from the Moderator
Help on Data Fork
snd resource info wanted.
Question about invisible windows
Window Manager port question
SendBehind description error in Inside Macintosh?
LSP on Mac II? How?
Lightspeed Pascal and 68020 Machines
A Programming Puzzle.
desk accessories and locked resources
TurboPascal Question
MacApp and Pascal Text IO
Apple ][ SW Dev't on a Mac?
Aztec 1.06H.1 bug -- ptrs to functions
Re: Using assembly language with Microsoft Fortran
Code generators for 68020/68881??
XLISP help needed
MPW Modula from TML
Reliability of pre-release libraries/development tools (MPW)
ADB Keyboard Key Code Info Request
using the mac II extended keys
MacPlus keypad question
----------------------------------------------------------------------
Date: Sun, 12 Jul 87 20:44:59 PDT
From: Dwayne Virnau... <INFO-MAC-REQUEST@SUMEX-AIM.STANFORD.EDU>
Subject: A note from the Moderator
Hello,
Info-Mac has been on hiatus for a few weeks while I have been doing
other things. It is back now, but the pace of digests during the
summer is going to have to be slower than during the academic year.
I receive from 50 to 100 messages *per day* -- if I do not log in
every day to process these messages my mailbox overflows. Most of
these messages are of the administrative type, of 50 messages about
five will go into a digest. It takes at least ten hours to prepare
each digest, and at it's peak there might be as many as five digests
in a week. SUMEX-AIM is a very gracious host, allowing INFO-MAC a
great deal of disk space and cpu time, but it is a very busy machine.
Which means I have to log in late at night and on weekends to get
all this work done.
Perhaps you can see why moderators burn out.
I enjoy being the INFO-MAC moderator. I take some pride in answering
the routine questions, maintaining the archives, maintaining the mailing
lists, and putting out digests that I wouldn't mind reading myself. And
I appreciate the notes of thanks, suggestions and offers of help -- I
could never do all this work without the support and assistance of many
of you on the net.
So I am asking for your assistance one more time. The following suggestions
would greatly lessen the load on me, and with any luck allow me to continue
to put out digests once or twice a week all summer.
1) Do not send messages with a time limit. As in "I need to know by
Friday what kind of drawing packages exist for the Lisa." Chances
are I won't even SEE your message by Friday.
2) If at all possible keep message size down to 20 to 30 lines maximum.
This is always a good guideline (long messages tend not to get read).
3) If you are sending me sources (such as .HQX files) *PLEASE* break
them into pieces of about 40,000k each. Also, try to send them near
the end of the week, so I'll have the weekend to work on them. Adding
new files to the archives takes the most time of anything I do, so
I'll probably save up such files and process them all at once. That
is, look for digests with a whole lot of archive announcements, and
don't be surprised at digests with none.
4) Send administrative requests (such as mailing list and archive questions)
to INFO-MAC-REQUEST@SUMEX-AIM.Stanford.EDU
Send submissions for the digests to INFO-MAC@SUMEX-AIM.Stanford.EDU
5) Don't send me mail saying you haven't seen many digests lately. I know
that.
Thank you all very much, I look forward to a good summer and on into the
next year !!
Dwayne Virnau...
Info-Mac Moderator
------------------------------
Date: Thu, 25 Jun 87 13:03:23 MST
From: Major John Buono
From: <buono%asbf-tds.huachuca-em.arpa@HUACHUCA-EM.ARPA>
Subject: Help on Data Fork
I am trying to write a MAC program (in LS Pascal) and am faced with
a curios problem. Inside MAC states that you can store any data
in the data fork of a file. Since an application contains a data fork
as well as the resource fork, I thought, why not use the data fork
of the application to store program data. This seemed logical until
I tried to figure out how to do it. All of the example are for files
which are external to the application. What I want to do is store
a number of records in the data fork of the appliation. Can this
be done if so how do you do it, or where in Inide Mac does it say
how to store data in the data fork of an application.
Thanks in Advance
Major John Buono
arpa buono%absf-tds@huachuca-em.arpa
------------------------------
Date: Thu, 2 Jul 87 23:34:38 PDT
From: Mark Frisse <FRISSE@SUMEX-AIM.STANFORD.EDU>
Subject: snd resource info wanted.
I'm trying to figure out the 'snd ' resource described in IM #5. Does anyone
know where I can find a description that I can add to my MPW Types.r file
to let ResEdit do the work. Information regarding 'snth' resource also
appreciated.
thanks in advance
mark frisse
washington u. (st. louis)
(frisse@sumex-aim.stanford.edu)
------------------------------
Date: Fri, 19 Jun 87 23:28:05 cst
From: Craig Knelsen <ihnp4!regina!cknelsen@ucbvax.Berkeley.EDU>
Subject: Question about invisible windows
I am writing an application (now on a Mac SE) which gives a user the
ability to close windows (without disposing of them) and then bring them back
later on by selecting the title from a menu (whose items correspond to all
current windows). My problem is that if the user wishes to save the current
work session and some of the windows are not visible, the rectangles pointed
to by strucRgn and contRgn for these windows in the window record are set to
zeros.
Question: How do the standard window definition functions restore these values
after the window is made visible again?
I have looked through IM (unfortunately, the latest I have is a 1984 draft
version -- the most recent version is on order but...) but have been unable
to come up with an answer. Would the dataHandle member of WindowRecord be
used here? A temporary (but unpleasant) solution has been to temporary make
the window visible, write the strucRgn rectangle values and then change the
window back to invisible.
Any assistance (including code samples if you wish -- preferably in
C [Pascal not an official language here]) would be appreciated. Thanks.
Craig Knelsen
Dept. of Computer Science
U. of Regina
Regina, Saskatchewan
Canada
UUCP: {ihnp4 | utcsri | alberta} !sask!regina!cknelsen
NetNorth (BITNET): craig@uregina2 <-- preferred
craig@uregina1
------------------------------
Date: Sat, 4 Jul 87 22:40 N
From: <FRUIN%HLERUL5.BITNET@forsythe.stanford.edu> (Thomas Fruin)
Subject: Window Manager port question
For a program I'm working on I need to do some drawing in the
Window Manager port. But in order to do this correctly I would
like to know if the Window Manager port uses the global coordinate
system. That is, the coordinate system with the origin (0,0) at
the top left corner of the screen's bit image.
This may seem logical at first, but with the Macintosh II and its
multiple screens I am very careful about assumptions like this.
Inside Macintosh hints that it is true (in the section about
writing your own WDEFs for example) but never really says so.
I realize it isn't essential that I know this, because I can always
do a GlobalToLocal or LocalToGlobal before working in the Window
Manager port. However, if it does use the global coordinate system
it would save me a bunch of calls. Besides it being interesting to
know...
Can someone from Apple comment?
Thomas Fruin
FRUIN@HLERUL5.BITNET
thomas@uvabick.UUCP
Leiden University, Netherlands
------------------------------
Date: Mon, 6 Jul 87 04:14 N
From: <FRUIN%HLERUL5.BITNET@forsythe.stanford.edu> (Thomas Fruin)
Subject: SendBehind description error in Inside Macintosh?
Here I am again with a Window Manager problem that needs some
clarification. Maybe I've even found an error in Inside Macintosh.
Let me explain what I'm trying to do:
The program I'm working on will have a "palette" window similar to
those windows in FullPaint: a window that always stays on top, but
doesn't act as the active window. My program will have several
document windows below this palette that should behave as normal
as possible to the user.
This means that when a user clicks in a window that isn't the
active one, that window should be brought to the front, BUT stay
below the palette window. Obviously I cannot use SelectWindow for
this. Instead I use SendBehind, which seems exactly the function
for this purpose (forget about highlighting for now).
Here is where the problem occurs. Inside Macintosh tells me that
if I use SendBehind to move a window closer to the front, I should
make some extra low-level Window Manager calls after calling
SendBehind. Specifically a call to PaintOne and one to CalcVis.
But I don't think these are sufficient. Whenever I try this out
by clicking in one of my windows to bring it to the "front", the
visRgn of the window that used to be in front is screwed up.
Anything I draw in it doesn't stay in its visible region, but
flows into the window I just brought to the front. See the figure.
It shows two windows before and after the SendBehind, PaintOne and
CalcVis calls, when I start drawing into one of them.
-------------------- --------------------
|behind | |in front |
| ------------------- | |---
| |I am drawing text| | I am drawing text|
----|into lower right | -----into-lower-right |
|window only. | |window only. |
------------------- -------------------
By changing the CalcVis call to a CalcVisBehind things go back
to normal. So it seems to me SendBehind is not updating the
visRgn of the window(s) it is covering up. Of course it should.
The Apple traplist in the Sybex book Using the Mac Toolbox with C
says that SendBehind already calls CalcVisBehind...
Can anyone help me with this one? If I'm doing things all wrong
I'd also welcome suggestions on how to implement the palette
window I've described.
Thomas Fruin
FRUIN@HLERUL5.BITNET
thomas@uvabick.UUCP
Leiden University, Netherlands
------------------------------
Date: Thu 25 Jun 87 20:10:14-PDT
From: Brodie Lockard <I.ISIMO@MACBETH.STANFORD.EDU>
Subject: LSP on Mac II? How?
Having read at least two messages claiming that Lightspeed Pascal runs on
the Mac II, and having asked a THINK tech support person whether it does
(and having received an answer in the negative), and having tried it a few
times myself, and having found a BOMB ID 03 as soon as execution tries to
leave the first subroutine of a program, I ask you, oh Netters: if you
really can run LSP on a II, what's the trick?
Brodie Lockard
i.isimo@lear.stanford.edu
------------------------------
Date: Fri, 19 Jun 87 15:06:41 edt
From: rs4u+@andrew.cmu.edu (Richard Siegel)
Subject: Lightspeed Pascal and 68020 Machines
Your points about software problems with 68020 machines are well taken.
However, let me clarify some things:
1. MacWrite fails because (as you say) it uses TRAP instructions
instead of real procedure calls. The exact problem is that the 68020
exception stack frame is 2 bytes *smaller* than the 68000 exception
stack frame.
2. Lightspeed C fails because of self-modifying code -- it build some
calls on the stack, and the 68020 won't notice the difference. The
workaound for this is to turn off the instruction cache on the 020. I
think someone wrote an INIT to do this. At any rate, it's not difficult.
Lightspeed Pascal also has problems with 020 machines, but
the problems have *NOTHING* to do with self-modifying code. Context
switches under Lightspeed Pascal fail for the exact same
reason that MacWrite fails -- again, the two-byte difference
between exception stack frames.
THINK Technologies knows about the problem, and if you're a registered owner,
call Customer Support and they'll help you. There's an intermediate
version that works fine on a Mac II (runs fast as hell! :-)); you
may have to sign a beta-test agreement, but that's not much problem.
As I said, call them if you need to.
Key words: *need to*. The man who currently answers phones for their
customer support section is an incredibly nice guy, helpful, knowledgeable,
&cetera. He deserves a medal. *HOWEVER*, he is continually swamped
with calls, so try not to increase his workload...
Rich
R-Squared Development Systems
134 Horseshoe Drive
Williamsburg, Virginia 23185
(804) 229-2152 [After 6pm eastern time only]
Arpanet: rs4u@andrew.cmu.edu
Uucp: {your fave gateway}!seismo!andrew.cmu.edu!rs4u
Disclaimer? I don't even KNOW 'er!
"Do you wanna be a cop or a lost cause?"
Sean Connery, in "The Untouchables"
------------------------------
Date: 26 Jun 87 21:25 +0500
From: AEIROUM <aeiroum%iro.udem.cdn%ubc.csnet@RELAY.CS.NET>
Subject: A Programming Puzzle.
Here is a puzzle for you.
We have found that the following code executes properly in
LightSpeed Pascal's interpreted mode but bombs with an illegal adress error
in the SetItext trap once compiled as a stand alone program.
Moreover if a ShowText is executed before the SetIText, along with
some Writelns, it does not bomb even compiled.
PROGRAM test;
VAR
hh : Handle;
BEGIN
hh := NewHandle(0); { size does not change anything here }
SetIText(hh, 'toto');
END.
We know... NewString does the job of getting a strig into a handle
but why did it work with windows.
We would apreciate some opinions...
Gilbert Gagnon
------------------------------
Date: Wed, 01 Jul 87 11:59:40 EDT
From: keough@mitre-bedford.ARPA
Subject: desk accessories and locked resources
Every now and then I come across a desk accessory that brings in resources,
locks them down and then proceeds to use them without ever unlocking them.
That's clearly not a good thing to do. In most cases, you'll never know about
it unless things are very tight in memory and the resources involved are on
the large size.
However, LightSpeed Pascal is susceptible to such situations. Before
executing your application code, LightSpeed has to do some fancy memory
shuffling to give your code a clean application zone. Locked objects in
LightSpeed's heap usually wind up generating a "can't run your application"
message, and that won't go away until you exit and relaunch LightSpeed.
For example, one potentially useful DA I found awhile ago was MacMan.
It's just the kind of thing you want when you're writing code in LightSpeed
(it was an online reference for Inside Macintosh). I don't know if that
DA has been rewritten since I saw it, but it left all sorts of locked
objects in the heap when it finished, making it useless with LightSpeed.
Maybe the Programmer's OnLine Companion is better about this.
Anyway, to get to the point of this message. Today I found another
such offending DA, from a reputable software vendor. It's called the
CONTROL PANEL, from APPLE COMPUTER. It's included in the 'latest'
software release called System 4.1. It seems that the Control Panel
needs to use the graphics "plus" cursor, and it brings it in and
locks it down. It never unlocks it before exiting.
A little disassembly says the DA works like this:
subq.w #4,sp ; make space for function return
move.w #2,-(sp) ; looking for cursor #2
_GetCursor
movea.l (sp)+,a0 ; get the handle to the cursor
_HLock ; LOCK IT DOWN
move.l (a0),-(sp) ; dereference, push its address
bra.s label ; (skip over some other code)
....
.... ; (intervening code)
....
label: _SetCursor ; and set the cursor
It looks like you only need to pull out the _HLock call here to fix the
thing. Inside Macintosh says that _GetCursor is not going to cause
any memory compaction, so the _HLock shouldn't be necessary anyway.
(If I'm mistaken about this, i hope someone will point this out).
So the patch, if you're willing to try it (no I haven't done it myself
yet, and maybe someone should verify that this really does the trick)
is to look for the sequence of code in the system file which is listed
above and replace the _HLock call with a NOP instruction. Specifically,
that's looking for the hex sequence:
594F 3F3C 0002 A9B9 205F A029 2F10 6012 ....
and replacing the occurrence of A029 (the _HLock trap) with 4E71 (a NOP
instruction). Alternatively, if you don't like tampering with the system
file itself, use the Font/DAMover to take the control panel out of the
system and put it into its own little suitcase file; modify the suitcase
file; and then reinstall the DA with the Font/DAMover. This second might
be preferred, in fact.
Jerry Keough
keough@mitre-bedford.arpa
keough@bcvax3.bitnet
------------------------------
Date: Tue 23 Jun 1987 10:03 CDT
From: N. Gokhale <MMAR013%ECNCDC.BITNET@forsythe.stanford.edu>
Subject: TurboPascal Question
This is posted for a friend since it's beyond me as well--->
>According to Chernicoff [author Macintosh Revealed] it looks like I should
have to declare Initgraf(@thePort) in order to use Quickdraw routines; yet I
have written some simple Turbo programs using FrameOval, MoveTo, and LineTo
without ever mentioning InitGraf, and they work just fine. Could you shed
any light on when and why one needs to do an InitGraf? I am really having
difficuly in understanding this, and my books don't answer it. (I've looked
at Inside MacIntosh too, but at the moment it's definitely beyond me.)
Respond to GFA0009@CALSTATE.BITNET or
GFA0009%CALSTATE.BITNET@wiscvm.wisc.edu or to me: ..Thanks
Nihar, Western Illinois University
bitnet MMAR013@ECNCDC
internet MMAR013%ECNCDC.BITNET@WISCVM.WISC.EDU
uucp [wanginst!decvax!cbosgd!] psuvax1!ECNCDC.BITNET!MMAR013
------------------------------
Date: Sun, 5 Jul 87 14:26:29 PDT
From: PUGH%CCC.MFENET@nmfecc.arpa
Subject: MacApp and Pascal Text IO
So, is this a true statement, or am I just not doing things correctly?
You cannot use standard Pascal text file IO with MacApp.
I have been trying, but Readln gives me a link error in Paslib.o. Is there a
secret, or have Readln and Writeln been relegated to debug info only? I want
to read and write a text file from my program and I would just as soon not
rewrite all the necessary routines again.
All I want is:
Reset(myFile, externalName);
While not Eof(myFile) do
Readln(myFile, x, y, z);
Close(myFile);
But, Sigh, it won't let me. On to the FSRead I suppose. Now where did I put
those numeric conversion routines from CS101?
Jon
N L pugh@nmfecc.arpa
M A L National Magnetic Fusion Energy Computer Center
F T N Lawrence Livermore National Laboratory
E L PO Box 5509 L-561
C Livermore, California 94550
C (415) 423-4239
------------------------------
Date: Tue 30 Jun 87 16:51:07-PDT
From: Marvin Zauderer <ZAUDERER@Sushi.Stanford.EDU>
Subject: Apple ][ SW Dev't on a Mac?
I understand that TML Systems has recently announced a Mac-based cross-compiler
for the Apple IIGS. What I'm wondering is: Is there a similar tool for Apple ][
development? Any leads would be much appreciated.
Thanks,
Marvin Zauderer (Zauderer@SUSH.STANFORD.EDU)
------------------------------
Date: Fri, 19 Jun 87 23:01:01 cst
From: Craig Knelsen <ihnp4!regina!cknelsen@ucbvax.Berkeley.EDU>
Subject: Aztec 1.06H.1 bug -- ptrs to functions
There is a compiler bug in Aztec C 1.06H.1 when declaring a pointer
to a function with the 'pascal' type and the 'extern' class:
eg.
extern pascal long (*ptr_f)();
This generates:
c.c: line 1: error 15: internal error
To alleviate this obnoxious effect, remove either/both 'extern' or/and
'pascal'. Of course, (*ptr_f[])() will also fail. In case you're wondering,
I had attempted to define an external array of pointers to control definition
functions which must follow Pascal calling conventions in order to work
properly with the Control Manager.
Craig Knelsen
Dept. of Computer Science
U. of Regina
Regina, Saskatchewan
Canada
UUCP: {ihnp4 | utcsri | alberta} !sask!regina!cknelsen
NetNorth (BITNET): craig@uregina2 <-- preferred
craig@uregina1
------------------------------
Date: Sun, 21 Jun 87 22:08:28 PDT
From: Ken_Urquhart%SFU.Mailnet@umix.cc.umich.edu
Subject: Re: Using assembly language with Microsoft Fortran
>Does anyone know a way to use an assembly language subroutine with a Fortran
>main program? I am trying to combine code written in Microsoft Fortran 2.2 and
>MDS assembler 2.0. The manual provides a sadly unclear appendix which does not
>specify, for example, whether the linker is Rel-file compatible or not. Any
>advice would be appreciated.
>Bill Lipa
...the big trick is to have the MDS Linker put the machine
code into the data fork of it's output file, just like the
Microsoft Fortran compiler puts its machine code output
into the ".sub" files it produces...
...for example, if you want to compile the subroutine "date.asm"
(supplied with the Microsoft Fortran 2.2 distribution disks) into
the file "date.sub" (suitable for input to the Fortran linker),
you first compile "date.asm" with the MDS assembler and then link it
with the MDS linker using the following "date.Link" file:
/Data
date
/Output date.sub
/Type ' ' ' '
$
...you can then treat "date.sub" like any of the ".sub" files
produced by the Fortran compiler.
------------------------------
Date: 24 Jun 87 13:43:00 EST
From: bouldin@ceee-sed.arpa
Subject: Code generators for 68020/68881??
I am using Absofts MacFortran 020. Are there any other 68020 code generators
available on the Mac?? MDS does _not_ support 020/881 mnemonics. Does the
MPW assembler?? Do the MPW Pascal and C generate 020 instructions and inline
881 floating point code??
Any help appreciated, as I am trying to take full advantage of the fancy 68020
hardware that I now have!
------------------------------
Date: Tue, 30 Jun 87 11:28:21 CDT
From: PHYS300%UNLCDC3.BITNET@wiscvm.wisc.edu (Univ. of Nebr.-Lincoln)
Subject: XLISP help needed
I am learning LISP using XLISP 1.6. Is this the latest version?
It would be helpful if I could echo the terminal session to the printer.
(Homework, don't cha no) Does anyone know how I can do this?
Thanks
Glenn Sowell PHYS300@UNL3CDC.BITNET
Dept. of Physics & Astronomy
Univ. of Nebraska
Lincoln, NE 68588-0111
(402) 472-2790
My wife always knows where to find me! Ah well.
------------------------------
Date: Mon, 22 Jun 87 20:22:28 MET
From: norbert%germany.csnet@RELAY.CS.NET
Subject: MPW Modula from TML
Does anybody out there already have the MPW Modula compiler from TML?
According to info-mac v5#083 it should be out by now...
Any comments on it? Price?
Thanx
Norbert Lindenberg
Universitaet Karlsruhe, West Germany
norbert@germany.csnet
------------------------------
Date: Tue, 30 Jun 87 11:48:26 PDT
From: Rick Wong <rick@portia.Stanford.EDU>
Subject: Reliability of pre-release libraries/development tools (MPW)
Does anyone know how safe it is to release software compiled with pre-
release libraries? I've recently recompiled an application using MPW C
2.0 A3, and now it seems that whenever I do a filing operation on an
unenhanced 512K Mac, the application exits back to the Finder! (Every-
thing seems to work on later Macs, though.) How much testing does
Apple do on their beta/pre-beta libraries before unleashing them on
us developers? Is there a version of MPW that I can rely on? I need
to have my application finished by August.
The usual thanks in advance, etc.
Rick Wong
rick@portia.stanford.edu
------------------------------
Date: Tue, 23 Jun 87 20:11:59-1000
From: uhccux!uhmanoa!uhmanoa.ICS.HAWAII.EDU!david@nosc.mil (David
From: Lassner)
Subject: ADB Keyboard Key Code Info Request
I'm hacking at some terminal emulation software which doesn't work
properly on ADB keyboards. Can someone send me or point me at the
keyboard key code info. I'm looking for the equivalent of Figure 3
in Chapter 8 of IM-I (pg I-251) for the Mac, and Figure 3 of Chapter
28 of the "Final Draft" of IM-4 (pg. 28-6) for the Mac Plus, but for
the ADB keyboards. Apple Keyboard alone would be useful, but info
on both new keyboards would be fantastic. Also, how do I tell which
keyboard is in use?
Thanks!
David Lassner, University of Hawaii Computing Center, 808/948-7351
INTERNET: david@uhccux.UHCC.HAWAII.EDU ARPA: uhccux!david@nosc.MIL
BITNET: T004550@UHCCMV PLATO: david/p/hawaii
UUCP: {ihnp4,seismo,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!david
------------------------------
Date: Thu, 25 Jun 87 09:07:51 CDT
From: "Kevin Altis" <C413315%UMCVMB.BITNET@forsythe.stanford.edu>
Subject: using the mac II extended keys
could someone with an ms-dos or unix manual for the mac ii, please tell
the rest of us how to access the functions keys... on the mac extended
keyboard? other than almost all the keys registering as control-p with
i haven't been able to use them. can they be assigned whole text string
will they only send a single keycode that your program is supposed to
decode? or are these really smart keyboards?
thanks,
kevin altis c413315@umcvmb
------------------------------
Date: Mon, 29 Jun 87 09:48:25 EDT
From: "Collins, Herman" <SYSHERM%UKCC.BITNET@wiscvm.wisc.edu>
Subject: MacPlus keypad question
OK, ok, ok. I give up. I've read the books (I'm waiting for the
movie). I've hacked at the code. How in the heck do I tell the
difference between the "=/*+" keys on the MacPlus keypad and the cursor
keys on the main keyboard? This topic has come up several times on this
list and others, but I've yet to see a good answer.
I'm writing a terminal emulator. It's an interesting project, and it
gives me some practice writing a Mac DA, but I'm stuck on this one
point. The keypad keys return exactly the same keycodes as the cursor
keys (but different ASCII codes). The modifier bits are set normally.
Inside MacIntosh_ says very little about this, although Volumn III says
that an inquire command can be sent to the keyboard, but this sounds
like I'd have to write a new keyboard driver.
MacIntosh Revealed_ mentions that INIT1 and INIT2 map the keycodes to
ASCII codes, while several passing references on the net mention INIT0
and INIT1 performing this task. I partially disassembled INITs 0-2 and
0 and 1 seem to be the right ones. At least they stick the address of
a procedure into $2A2 and $29E respectively. The procedures use D0 and
D1 to index into a table (that could be ASCII) and return a character.
Are these INITs documented anywhere? Can I poke the addresses of my own
mapping routines into these addresses? Will this work on all Macs? Is
there any documentation on the keyboard driver? Am I overlooking
something? Thanks for any help that anyone can give me.
Herman Collins
SYSHERM@UKCC (BITNET)
"Reality -- What a concept!" R. Williams
------------------------------
End of INFO-MAC Digest
**********************