info-mac@uw-beaver (info-mac) (07/12/84)
From: Richard Furuta <Furuta@washington.arpa>
1) 21-Jun Bill Croft using MACSBUG with SUMACC
2) 21-Jun Bill Croft utilities on SUMACC disk
3) 21-Jun winkler@harvard (Dan Re: Macpascal due in early July
4) 25-Jun Ed Pattermann Sources on INFO-MAC
5) 25-Jun Frank da Cruz Macintosh Kermit Progress Report
6) 25-Jun David H M Spector Font Editor.
7) 25-Jun David H M Spector Replacement of "Apple Brand" Disks.
8) 25-Jun John Clark Re: utilities on SUMACC disk
9) 25-Jun Bill Croft debugging new icons
10) 25-Jun Bill Croft SUMACC bugs
11) 25-Jun Bill Croft some bugs in APPLE Mac Workshop (and SUMACC)
12) 25-Jun David.Anderson@CMU-C 68000 programming books?
13) 25-Jun B.BPE%LOTS-A@SU-SCOR WARNING: Transylvania
14) 25-Jun winkler@harvard (Dan porting unix programs to mac
15) 25-Jun Bill Croft Re: StartSound
16) 25-Jun Joseph I. Pallas Re: StartSound
17) 25-Jun wert.pa@XEROX.ARPA International Macintosh?
18) 25-Jun Edward.Tecot at CMU- Macsbug
19) 26-Jun Dave Johnson downloading files using macterminal/modem7
20) 26-Jun jmh@BNL binhex.bas
21) 26-Jun David H M Spector 68K Books.
22) 26-Jun To: info-mac@SUMEX-A surge protectors?
23) 26-Jun Larry F. Byard RAMs
24) 26-Jun Bill Croft re: porting unix programs to mac
25) 26-Jun Mike Schuster Need help on Text Edit guts
Message 1 -- ************************
Mail-From: PATTERMANN created at 21-Jun-84 15:03:34
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Thu 21 Jun 84 12:18:01-PDT
Date: Thu, 21 Jun 84 12:20:55 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: using MACSBUG with SUMACC
Cc: croft, sumacc@sumex
ReSent-date: Thu 21 Jun 84 15:03:34-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
----
Date: 20 Jun 1984 20:27-EST
From: David.Anderson@CMU-CS-G.ARPA
I picked up my copy of the SUMacC disk today, and it included MacsBug
and Disassembler. I can't figure out what they do -- can someone
enlighten me? They sound terribly useful.
----
David,
Your SUMACC disk as distributed has MACSBUG named xMACSBUG, this prevents
it from being loaded at boot time. If you want to debug something you
should follow these steps:
Ensure that Macsbug is NOT loaded; i.e. the name in the system
folder should read "xMACSBUG". If this is not true, then rename it,
attempt eject (to flush), and reboot. MacTerminal and the Finder don't
work well when the large MACSBUG and DISASSEMBLER are loaded; Finder
runs out of space and MacTerminal crashes.
AFTER you have downloaded and/or converted your program, then
rename "xMACSBUG" to "MACSBUG", eject, and reboot. This will load
the debugger/disassembler at the top of memory.
Make sure that you have an ASCII terminal connected to the
"printer" port at 9600 baud.
Double click your program, pause a half-second, then hold down
the mouse button. When you hear a beep, release the mouse button.
What this does is: (1) load your program, (2) tells the "C runtime
startoff" (lib/crtmac.s, the first part of your program to
get control after loading) to "pause" before entering your main
program. This will give you time to set breakpoints or alter
memory before your program starts.
The "beep" means crtmac is waiting in a tight loop for register
D0 to become zero. It will just sit there forever. Now on
the side of your Mac, carefully press the "INTERRUPT" (not the
"RESET") button once. The debugger should print out a register
dump on your terminal.
I assume you have read the section "ROM 7.0 MacsBug Summary" in
your Inside Macintosh. This is located somewhat behind the "Misc"
tab in my copy. Other sections that are helpful are "Pascal Program
Debug Strategy" and "Toolbox Names"; the latter is useful for setting
breakpoints on toolbox calls.
To MACSBUG, type "d0 0"; this clears register D0 and will allow
the program to proceed. Now you might want to set a breakpoint on
a location or a trap; use the appropriate "br" or "at" command.
You will probably want to have an assembler listing of your
program; use the "-S" switch of cc68. After you are ready to
proceed, type "g" or "t". This will go to the next breakpoint
or trace each instruction before execution.
When finished debugging you will (unfortunately) need to rename
MACSBUG back to xMACSBUG and reboot if you want to use MacTerminal.
BETTER DEBUGGERS: Soon Apple will be releasing their two-Mac debugger/
assembler system. Instead of an ascii terminal on the printer port, you
use another Mac with a nice window based debugging package. And instead
of MACSBUG/DISASSEMBLER there is just a tiny "stub" that lives on the
system heap which interfaces to the "remote" window debugger. This idea
is very similar to David Bogg's old "TeleSwat" protocol on the Alto.
Message 2 -- ************************
Mail-From: PATTERMANN created at 21-Jun-84 15:03:37
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Thu 21 Jun 84 12:38:41-PDT
Date: Thu, 21 Jun 84 12:41:47 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: utilities on SUMACC disk
Cc: sumacc@sumex
ReSent-date: Thu 21 Jun 84 15:03:37-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Date: Wed 20 Jun 84 00:37:38-EDT
From: BERGER@CMU-CS-C.ARPA
Subject: SetFile and resource mover questions
I can't get SetFile to set the creator field of a file. Am I
doing something wrong, or is it just broken?
Also, how do you get the Resource Mover to do anything?
Robert Berger
Berger@CMU-CS-C
Somewhere in the Monitor/Workshop/Inside Mac document set was a "hint"
on how to use SETFILE. There is a bug in SETFILE and you have to use
the "tab" key (rather than the mouse) to select the text field(s) that you
want to edit. After changing all the stuff you are interested in, then
you mouse "SET IT" and exit.
For a discussion of the Resource Mover, see the section "Working with
Resource Files on the Macintosh" in the "Putting Together an Application"
document dated 1/13/84.
Message 3 -- ************************
Mail-From: PATTERMANN created at 21-Jun-84 19:00:03
Return-Path: <winkler@harvard>
Received: from harvard.ARPA by SUMEX-AIM.ARPA with TCP; Thu 21 Jun 84 17:59:42-PDT
Received: by harvard.ARPA (4.12/4.27)
id AA05421; Thu, 21 Jun 84 21:08:24 edt
Date: Thu, 21 Jun 84 21:08:24 edt
From: winkler@harvard (Dan Winkler)
Message-Id: <8406220108.AA05421@harvard.ARPA>
To: info-mac@sumex-aim, kalagher@mitre
Subject: Re: Macpascal due in early July
ReSent-date: Thu 21 Jun 84 19:00:03-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
A representative of Think Technologies said he expects MacPascal to be
released in early July. This is a later date than they had previously
expected, but he said that Think "will sell no software before its
time" and criticized Microsoft's releasing an initially buggy version
of Multiplan.
Message 4 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 14:31:45
Date: Mon 25 Jun 84 14:31:45-PDT
From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
Subject: Sources on INFO-MAC
To: info-mac: ;
cc: Pattermann@SUMEX-AIM.ARPA
As moderator of this list, I am faced with the dilemma of whether or not to
send out program sources to the INFO-MAC distribution network. On one hand,
the sending of sources can lead to a lot of bits propagating across the net,
and in many cases of no real value to the receiver. On the other hand,
providing sources solely via Arpanet FTP means alot of readers who do not have
FTP access to SUMEX lose out.
My current policy is going to be to allow sources to be sent out on the list,
provided they are of reasonable quality, not of hugh proportions, and are not
copy protected. This includes both programs for the Macintosh (in Basic,
Pascal, Forth, etc) and programs and bug fixes for the SUMACC environment.
My logic for this decision is as follows ; The model I have tried to put forth
for INFO-MAC is that of a resource for users and sites interested in the
serious development of the Macintosh within their environment. This originally
included mostly the Apple University Consortium schools, but since has grown
to include many others. Exchange of software among this community is important
to the continued development of Macintosh applications. I also believe a
mailing list such as INFO-MAC is best handled locally as a bboard which all
readers can share, rather than each person receiving individual copies. Those
sites that can and do use this scheme will not be hurt by the posting of
sources. Those who do receive INFO-MAC directly are left to bear the brunt for
all those who would lose otherwise if sources were not posted.
If you have any experience with this issue or any good comments to make, I
would appreciate hearing them.
-- Ed
-------
Message 5 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:31:59
Return-Path: <@COLUMBIA-20.ARPA:SY.FDC@CU20B>
Received: from COLUMBIA-20.ARPA by SUMEX-AIM.ARPA with TCP; Thu 21 Jun 84 20:25:24-PDT
Received: from CU20B by CUCS20 with DECnet; 21 Jun 84 23:26:07 EDT
Date: Thu 21 Jun 84 18:19:34-EDT
From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA-20.ARPA>
Subject: Macintosh Kermit Progress Report
To: Info-Kermit@CUCS20, Info-Mac@SUMEX-AIM.ARPA
Reply-To: cc.fdc@COLUMBIA-20
ReSent-date: Mon 25 Jun 84 17:31:59-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Columbia has finally received its Lisa-2/10 development system, though we
haven't actually tried to use it yet for Mac development yet (we just
unpacked it).
We had a rudimentary, receive-only adaptation of Unix Kermit running on
the Mac briefly, bootstrapped with the Sumacc cross development package.
This was painful to do, and only worked once for some reason. We may
pursue this avenue, or give it up if the Lisa proves to be easier to deal
with.
We submitted a proposal to Apple 2 months ago to add Kermit as one of the
file transfer protocols supported by MacTerminal. We haven't had a
response yet. Meanwhile, a review of MacTerminal in the current
(July/August 1984) issue of Macworld compares Kermit favorably to the
XMODEM protocol that is already in MacTerminal (p.69). I hope someone at
Apple reads the review.
What does all this add up to? We'll produce a Kermit for the Mac one way
or another. We'd prefer to see it as an option in MacTerminal, since that's
the natural place to put it, but failing that we'll do a standalone version.
Anyway, at least now we can start.
-------
Message 6 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:32:03
Return-Path: <SPECTOR@NYU-CMCL1.ARPA>
Received: from NYU-CMCL1.ARPA by SUMEX-AIM.ARPA with TCP; Thu 21 Jun 84 21:21:18-PDT
Date: 22 Jun 84 00:19 EDT
From: David H M Spector <SPECTOR@NYU-CMCL1.ARPA>
To: info-mac@SUMEX-AIM.ARPA
Subject: Font Editor.
Message-ID: <17401C534.017A0030.1984@CMCL1.NYU-CMCL1.ARPA>
ReSent-date: Mon 25 Jun 84 17:32:03-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
The new version of the system disk I was given by my dealer contains a
font editor (version 2.0), however, it uses generic documents as its
input AND output, these are actually basic form of a font that I assume
eventually finds its way into the "fonts file". However, my problem is
that no matter what I attempt to do with this application, it crashes.
Does anyone know how to use the program, or is it broken?
David Spector
Spector@NYU-CMCL1
-------
Message 7 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:32:09
Return-Path: <SPECTOR@NYU-CMCL1.ARPA>
Received: from NYU-CMCL1.ARPA by SUMEX-AIM.ARPA with TCP; Thu 21 Jun 84 21:26:40-PDT
Date: 22 Jun 84 00:24 EDT
From: David H M Spector <SPECTOR@NYU-CMCL1.ARPA>
To: info-mac@SUMEX-AIM.ARPA
Subject: Replacement of "Apple Brand" Disks.
Message-ID: <1740242AD.017A0030.1984@CMCL1.NYU-CMCL1.ARPA>
ReSent-date: Mon 25 Jun 84 17:32:09-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Does anyone have any idea on what one should do if any of your "Apple Brand"
disks are defective (i.e., won't format)?
I have found a couple that refuse to format, even after being "degaussed"
by a hefty mangnet. And, it seems a pity to waste $5 like that...
Thanks Much,
David Spector
Spector@NYU-CMCL1
-------
Message 8 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:32:11
Return-Path: <clark@rand-unix>
Received: from rand-unix.ARPA by SUMEX-AIM.ARPA with TCP; Fri 22 Jun 84 08:52:06-PDT
Received: by rand-unix.ARPA (4.12/4.7)
id AA08016; Fri, 22 Jun 84 08:39:29 pdt
From: John Clark <clark@rand-unix>
Message-Id: <8406221539.AA08016@rand-unix.ARPA>
Date: 22 Jun 84 08:39:26 PDT (Fri)
To: Bill Croft <croft@safe>
Cc: info-mac@sumex, sumacc@sumex
Subject: Re: utilities on SUMACC disk
In-Reply-To: Your message of Thu, 21 Jun 84 12:41:47 pdt.
<8406220138.AA28519@rand-unix.ARPA>
ReSent-date: Mon 25 Jun 84 17:32:11-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Another work-around for the bug in SETFILE is to make liberal use of
backspaces (before) and spaces (after) entering file type and creator in
their textfields. This seems to work if the fields are initially empty.
If not, then spacing existing text off the right end first, seems to work.
Use of the tab key as you suggest is a cleaner work-around.
For those who haven't got the docs for Resource Mover, the program's
primary capabilities seem to be: editing resource IDs and names, and moving
resources around (via the familiar select, cut, copy, and paste route).
It's handy for installing fonts, renaming menus, and such. If it does
other things, I haven't discovered them yet. Whatever's left on The Scrap
when the program is exited seems to be saved in a document called ResScrap;
however, this gets zeroed the next time Resource Mover is started.
John Clark
clark@rand-unix
Message 9 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:32:13
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Fri 22 Jun 84 16:49:06-PDT
Date: Fri, 22 Jun 84 16:51:41 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: debugging new icons
Cc: croft, mikes@cit-vax, sumacc@sumex
ReSent-date: Mon 25 Jun 84 17:32:13-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
The finder has a "cache" of the icon information that it gleans
from your application resource file when it is installed for the first
time. This means that the finder runs faster, but there is also
a finder bug here: there is currently no way to tell the finder
to refresh his cached icon pictures.
This situation where this is most painful is when you are debugging
the icon for your application. Even though you change the icon in
your program's resource file, the finder won't see the change.
Currently the only solution is to force the finder to rebuild his
DeskTop file by rebooting with command-option held down. (Since this
cache is indexed by filetype/creator, you should also ensure that
ALL your applications on the disk have the new definition in their
resource file's because you don't know which one the finder will
encounter first to make his cache entry).
One solution might be to have the finder compare the date when he
made his cache entry to the "modified" date of the file being
considered. If the file is newer than the cache, that entry in
the cache should be rebuilt.
When I mentioned this to Bruce Horn, he said that he had once
considered checking the (SETFILE) "init" bit for this purpose, but
didn't have time at the moment to implement it.
Message 10 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:32:16
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Fri 22 Jun 84 18:55:06-PDT
Date: Fri, 22 Jun 84 18:57:57 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: SUMACC bugs
Cc: croft, sumacc@sumex
ReSent-date: Mon 25 Jun 84 17:32:16-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Here are some bug fixes for SUMACC.
This first bug was a glitch in the standard file SFReply structure:
+ diff h/packintf.h- h/packintf.h
77,78c77,78
< short good; /* ignore if false */
< short copy;
---
> char good; /* ignore if false */
> char copy;
This was a misdeclaration of the p2cstr subroutine; it's really a
subroutine, not a function.
+ diff h/quickdraw.h- h/quickdraw.h
287c287
< char *p2cstr(); /* "casts" Pascal string into C string */
---
> void p2cstr(); /* convert Pascal string into C string */
A tip of the hat to Bill Schilit at Columbia and Mike Schuster at CALTECH
for reporting these.
Message 11 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:32:18
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Fri 22 Jun 84 18:58:34-PDT
Date: Fri, 22 Jun 84 19:01:20 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: some bugs in APPLE Mac Workshop (and SUMACC)
Cc: croft, sumacc@sumex
ReSent-date: Mon 25 Jun 84 17:32:18-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
These bugs are in the Lisa Mac Workshop release of 3/30/84, so I hope
Apple Tech support is listening. Here are the translations for SUMACC:
The OpenRF subroutine did not clear the IOPermssn and IOOwnBuf fields
of the IOQ Element on the stack, so depending on what was there before,
OpenRF would crash if IOOwnBuf pointed somewhere weird (instead of zero).
These additional lines were mirrored after FSOpen.
+ diff lib/io.s- lib/io.s
719c719,721
< .word __openrf
---
> clrb a0@(iopermssn) | open for read/write
> clrl a0@(ioownbuf) | use system buffer
> .word __openrf | open resource fork
This bug is in the Desk Manager and its documentation (pg 8, SystemEdit
function). The editCmd numbers expected by SystemEdit are documented
and defined wrong.
+ diff h/toolintf.h- h/toolintf.h
208,212c208,212
< #define cutCmd 0
< #define copyCmd 1
< #define pasteCmd 2
< #define undoCmd 3
< #define clearCmd 4
---
> #define undoCmd 0
> #define cutCmd 2
> #define copyCmd 3
> #define pasteCmd 4
> #define clearCmd 5
This also explains one of the problems with cut/paste and the grow
sample program (although it still doesnt work correctly with the
NotePad).
+ diff test/grow.c- test/grow.c
219c219,223
< if (SystemEdit(theItem-1)) /* (why -1?) */
---
> /*
> * SystemEdit expects 0=undo, 1=----, 2=cut, 3=copy, etc.,
> * since our menu starts with 1=cut, we add +1.
> */
> if (SystemEdit(theItem+1))
Thanks again to Bill Schilit and Mike Schuster.
Message 12 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:32:20
Return-Path: <dba@cmu-cs-spice.arpa>
Received: from CMU-CS-SPICE.ARPA by SUMEX-AIM.ARPA with TCP; Sat 23 Jun 84 20:20:15-PDT
Date: 23 Jun 1984 23:05-EST
From: David.Anderson@CMU-CS-SPICE.ARPA
Subject: 68000 programming books?
To: info-mac@sumex-aim
Message-Id: <456894344/dba@CMU-CS-SPICE>
ReSent-date: Mon 25 Jun 84 17:32:20-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Can anyone recommend a good book on 68000 programming? Is Motorola's
book just fine as a reference (I haven't really read it), or is there
something better to look at? I'm interested both in something to use
now to learn the architecture, and to use later as a reference manual.
--david
P.S. Not that I plan to do a great deal of assembly language hacking,
but I'd like to know what's going on in there.
Message 13 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:32:23
Received: from LOTS-A by SUMEX-AIM with Pup; Sun 24 Jun 84 13:39:43-PDT
Date: Sun 24 Jun 84 12:12:53-PDT
From: B.BPE%LOTS-A@SU-SCORE.ARPA
Subject: WARNING: Transylvania
To: info-mac@SUMEX-AIM
ReSent-date: Mon 25 Jun 84 17:32:22-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Potential purchasers of this (or presumably any other) adventure from
Penguin software whould be warned that there are many bugs in their
Macintosh implementation. I successfully avoided the bug mentioned on this
list, where use of the mouse button in response to <Press any Key> trashes
the disk, however there seem to be a number of ways of achieving that effect.
In particular, attempting to open two saved games in a row caused my disk
to be trashed. There are also bugs in the information display, and a long
session sometimes causes the system to lock up with garbage on the screen,
though a reboot seems to work in such cases. There are other bugs in the game
logic, which I mentioned when I sent my disk back for replacement, but which
I will not describe here to avoid a spoiler.
My recommendation is to avoid this game until a newer version is issued with
the bugs fixed. I will report to the list if/when I get a replacement from
them and if it has the problems fixed. Unfortunatly they do not give a version
number on their games, so even if they immediatly begin issuing corrected
versions, you may still get stuck with a buggy one and have to return it.
I should have guessed this might happen, based on the interview with the
implementor of the game in the June ST.MAC - he apparently hacked the program
from BASIC into 68000 assembler on the fly, then chased bugs until he and
one other person didn't notice any more. I really hate it when companies
use initial purchasers as their beta release testers.
-Barry Eynon
-------
Message 14 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:32:24
Return-Path: <winkler@harvard>
Received: from harvard.ARPA by SUMEX-AIM.ARPA with TCP; Mon 25 Jun 84 08:19:14-PDT
Received: by harvard.ARPA (4.12/4.27)
id AA16891; Mon, 25 Jun 84 10:37:54 edt
Date: Mon, 25 Jun 84 10:37:54 edt
From: winkler@harvard (Dan Winkler)
Message-Id: <8406251437.AA16891@harvard.ARPA>
To: info-mac@sumex
Subject: porting unix programs to mac
ReSent-date: Mon 25 Jun 84 17:32:24-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I've ported the Unix hangman game (and its entire 15,000 word
dictionary) to the Mac using sumacc. Only minor changes were
necessary. I had to remove the signal handling and replace the calls
to the curses package by QuickDraw commands. The file i/o calls had
direct analogs in the Mac file system and were easily adapted. Hangman
doesn't use malloc, but if it had I could have replaced calls to malloc
and free by the Mac's NewPtr and DisposePtr. Calls to realloc would be
harder to fix since the Mac memory manager does not have the ability to
extend a block without destroying its contents.
I think the prospects are good for porting any Unix C program that runs
in a single process and does not exceed sumacc's limit of one 32k
segment, assuming it is clearly written. (Hangman is very well written,
but I had previously started to port dc and gave up because the style
was so convoluted.) In fact, I think it would be possible to develop
a library of Unix system calls written for the Mac that would allow
many Unix programs to run essentially unmodified on the Mac.
Porting hangman's dictionary required some extra work because the form
of the dictionary under Unix is a 15,000 line (140k byte) file with one
word per line. MacTerminal will only save 2,000 lines off top. But
after setting the MacTerminal linelength to 132 and reformatting the
dictionary so that it put several words per line, this limit was not a
problem. The largest file you can transfer this way is 2,000 X 132 =
264,000 bytes.
Message 15 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:32:27
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Mon 25 Jun 84 11:21:32-PDT
Date: Mon, 25 Jun 84 11:24:09 pdt
From: Bill Croft <croft@safe>
To: pallas@Pescadero
Subject: Re: StartSound
Cc: croft, info-mac@sumex, sumacc@sumex
ReSent-date: Mon 25 Jun 84 17:32:27-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Date: Mon, 25 Jun 84 09:15:25 pdt
From: Joseph I. Pallas <pallas@Pescadero>
Subject: StartSound
To: croft@safe
The assembly implementation of StartSound (both the Apple version and yours)
has the ASYNC flag commented out. The effect of this seems to be that calls
to StartSound do not return until the specified duration has passed. I
assume that you were just translating what was there, but do you have any
idea why the ASYNC was commented out? Is there a known problem mentioned in
some document, or should I try changing it and see what happens?
joe
Usually when one does ASYNC IO, several buffers are used so that you can
be filling one while the OS empties the other. Since there is only one
buffer declared in the StartSound assembly helper, Apple probably wanted
to reduce confusion and made the Write call synchronous. Otherwise they
probably would have had to have a "TestSoundDone" routine and/or a
"WaitSoundDone", etc.
If you want to do ASYNC IO, then setup your own ParamBlocks and use the
PBWrite call directly. There is probably an example of this in the
SoundLab sample program.
Message 16 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:32:29
Return-Path: <pallas@Pescadero>
Received: from Pescadero by SUMEX-AIM.ARPA with TCP; Mon 25 Jun 84 12:38:13-PDT
Date: Mon, 25 Jun 84 12:37:43 pdt
From: Joseph I. Pallas <pallas@Pescadero>
Subject: Re: StartSound
To: croft@safe
Cc: info-mac@sumex, sumacc@sumex
ReSent-date: Mon 25 Jun 84 17:32:29-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
From: Joseph I. Pallas <pallas@Pescadero>
Subject: StartSound
To: croft@safe
The assembly implementation of StartSound (both the Apple
version and yours) has the ASYNC flag commented out. The
effect of this seems to be that calls to StartSound do not
return until the specified duration has passed.
From: Bill Croft <croft@safe>
Subject: Re: StartSound
Since there is only one buffer declared in the StartSound
assembly helper, Apple probably wanted to reduce confusion and
made the Write call synchronous. Otherwise they probably would
have had to have a "TestSoundDone" routine and/or a
"WaitSoundDone", etc.
If you want to do ASYNC IO, then setup your own ParamBlocks and
use the PBWrite call directly. There is probably an example of
this in the SoundLab sample program.
Alas, the SoundLab program is the question, not the answer. As an
exercise, I transliterated SoundLab into C. The result works fine
(well, almost), except that SoundLab calls StartSound and expects it to
work asynchronously. SoundLab, in fact, does implement a sort of
WaitSoundDone (very kludgily) by setting the duration to 1 and doing a
delay loop. There's no question that the author of SoundLab believed
StartSound was asynchronous. I'm willing to believe that someone
decided to change that after SoundLab was written, given that the last
date in its code is Jan. 1983; I just wondered whether there was any
explanation for the change.
joe
Message 17 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:32:31
Return-Path: <wert.pa@Xerox.ARPA>
Received: from Xerox.ARPA by SUMEX-AIM.ARPA with TCP; Mon 25 Jun 84 15:14:25-PDT
Received: from Salvador.ms by ArpaGateway.ms ; 25 JUN 84 15:15:14 PDT
Date: 25 Jun 84 15:14:57 PDT
From: wert.pa@XEROX.ARPA
Subject: International Macintosh?
To: info-mac@SUMEX-AIM.ARPA
Cc: wert.pa@XEROX.ARPA
ReSent-date: Mon 25 Jun 84 17:32:31-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Does anyone know what the differences are between the Regular Mac and
the International Mac?
Thanks,
Scott Comer
Message 18 -- ************************
Mail-From: PATTERMANN created at 25-Jun-84 17:32:33
Return-Path: <tecot@cmu-cs-h.arpa>
Received: from CMU-CS-H.ARPA by SUMEX-AIM.ARPA with TCP; Mon 25 Jun 84 15:31:30-PDT
Date: 25 Jun 1984 18:31:22-EDT
From: Edward.Tecot at CMU-CS-H
Subject: Macsbug
ReSent-date: Mon 25 Jun 84 17:32:33-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Macsbug is a generic monitor for the MC68000. There is a manual for
it. (The standard Motorola blue pamphelet) I am not sure if the Macintosh
conforms exactly, but it is probably pretty close.
_emt
Message 19 -- ************************
Mail-From: PATTERMANN created at 26-Jun-84 11:19:54
Return-Path: <ddj@csnet-relay.csnet>
Received: from csnet-relay by SUMEX-AIM.ARPA with TCP; Fri 22 Jun 84 15:52:24-PDT
Received: From brown.csnet by csnet-relay; 22 Jun 84 18:35 EDT
Message-Id: <8406222232.AA07967@nancy.Brown.CSNet>
Date: 22 Jun 84 (Fri) 18:32:17 EDT
From: Dave Johnson <ddj%brown.csnet@csnet-relay.arpa>
To: info-mac@sumex-aim.arpa
Subject: downloading files using macterminal/modem7
ReSent-date: Tue 26 Jun 84 11:19:54-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
This program emulates the Mac's modified modem7 protocol on
a unix system so that files can be easily downloaded through
MacTerminal. It can be used for both binary and mundane text
files, and avoids the need to convert binaries to and from
printable-hex format. The source and the manual page follow
immediately, with everything shifted over one tab stop to avoid
problems with mailers eating lines which start with '.'.
Macput has been tested under 4.2 on both vaxes and suns, but
since I didn't use any 4.2 specific features, it should work
under 4.1 without any hassles. Let me know if you have any
problems or improvements; I will post updates when/if MacTerminal
changes out from under macput.
Dave Johnson
Brown University
ddj%brown@csnet-relay
---------
macput.c:
---------
#include <stdio.h>
#include <signal.h>
#include <setjmp.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#define RECORDBYTES 132
#define DATABYTES 128
#define NAMEBYTES 63
#define RETRIES 10
#define ACKTIMO 10
#define MAXRECNO 0xff
#define BYTEMASK 0xff
#define TMO -1
#define DUP '\000'
#define SOH '\001'
#define EOT '\004'
#define ACK '\006'
#define NAK '\025'
#define CAN '\030'
#define EEF '\032'
#define ESC '\033'
#define H_NLENOFF 1
#define H_NAMEOFF 2
#define H_TYPEOFF 65
#define H_AUTHOFF 69
#define H_DLENOFF 81
#define H_RLENOFF 85
#define TEXT 0
#define DATA 1
#define RSRC 2
#define FULL 3
int mode, txtmode;
struct macheader {
char m_name[NAMEBYTES+1];
char m_type[4];
char m_author[4];
int m_datalen;
int m_rsrclen;
} mh;
struct filenames {
char f_info[256];
char f_data[256];
char f_rsrc[256];
} files;
int recno;
char buf[DATABYTES];
/*
* macput -- send file to macintosh using xmodem protocol
* Dave Johnson, Brown University Computer Science 6/17/84
*/
char usage[] =
"usage: \"macput [-rdu] [-t type] [-a author] [-n name] filename\"\n";
main(ac, av)
char **av;
{
int n;
char *filename;
if (ac == 1) {
fprintf(stderr, usage);
exit(1);
}
mode = FULL;
ac--; av++;
while (ac) {
if (av[0][0] == '-') {
switch (av[0][1]) {
case 'r':
mode = RSRC;
strncpy(mh.m_type, "APPL", 4);
strncpy(mh.m_author, "CCOM", 4);
break;
case 'u':
mode = TEXT;
strncpy(mh.m_type, "TEXT", 4);
strncpy(mh.m_author, "MACA", 4);
break;
case 'd':
mode = DATA;
strncpy(mh.m_type, "TEXT", 4);
strncpy(mh.m_author, "????", 4);
break;
case 'n':
if (ac > 1) {
ac--; av++;
n = strlen(av[0]);
if (n > NAMEBYTES) n = NAMEBYTES;
strncpy(mh.m_name, av[0], n);
mh.m_name[n] = '\0';
break;
}
else goto bad_usage;
case 't':
if (ac > 1) {
ac--; av++;
strncpy(mh.m_type, av[0], 4);
break;
}
else goto bad_usage;
case 'a':
if (ac > 1) {
ac--; av++;
strncpy(mh.m_author, av[0], 4);
break;
}
else goto bad_usage;
default:
bad_usage:
fprintf(stderr, usage);
exit(1);
}
}
else {
filename = av[0];
}
ac--; av++;
}
find_files(filename, mode);
if (mode != FULL)
forge_info();
setup_tty();
if (send_sync() == ACK) {
txtmode = 0;
send_file(files.f_info, 1);
if (mode == TEXT) txtmode++;
send_file(files.f_data, 1);
txtmode = 0;
send_file(files.f_rsrc, 0);
}
if (mode != FULL)
unlink(files.f_info);
reset_tty();
}
find_files(filename, mode)
{
int n;
struct stat stbuf;
sprintf(files.f_data, "%s.data", filename);
sprintf(files.f_rsrc, "%s.rsrc", filename);
if (mode == FULL) {
sprintf(files.f_info, "%s.info", filename);
if (stat(files.f_info, &stbuf) != 0) {
perror(files.f_info);
cleanup(-1);
}
return;
}
else {
strcpy(files.f_info, "#machdrXXXXXX");
mktemp(files.f_info);
}
if (mode == RSRC) {
strcpy(files.f_data, "/dev/null");
if (stat(files.f_rsrc, &stbuf) != 0) {
strcpy(files.f_rsrc, filename);
if (stat(files.f_rsrc, &stbuf) != 0) {
perror(files.f_rsrc);
cleanup(-1);
}
}
mh.m_datalen = 0;
mh.m_rsrclen = stbuf.st_size;
}
else {
strcpy(files.f_rsrc, "/dev/null");
if (stat(files.f_data, &stbuf) != 0) {
sprintf(files.f_data, "%s.text", filename);
if (stat(files.f_data, &stbuf) != 0) {
strcpy(files.f_data, filename);
if (stat(files.f_data, &stbuf) != 0) {
perror(files.f_data);
cleanup(-1);
}
}
}
mh.m_datalen = stbuf.st_size;
mh.m_rsrclen = 0;
}
if (mh.m_name[0] == '\0') {
n = strlen(filename);
if (n > NAMEBYTES) n = NAMEBYTES;
strncpy(mh.m_name, filename, n);
mh.m_name[n] = '\0';
}
}
forge_info()
{
int status, n;
char *np;
FILE *fp;
for (np = mh.m_name; *np; np++)
if (*np == '_') *np = ' ';
buf[H_NLENOFF] = n = np - mh.m_name;
strncpy(buf + H_NAMEOFF, mh.m_name, n);
strncpy(buf + H_TYPEOFF, mh.m_type, 4);
strncpy(buf + H_AUTHOFF, mh.m_author, 4);
put4(buf + H_DLENOFF, mh.m_datalen);
put4(buf + H_RLENOFF, mh.m_rsrclen);
fp = fopen(files.f_info, "w");
if (fp == NULL) {
perror("temp file");
cleanup(-1);
}
fwrite(buf, 1, DATABYTES, fp);
fclose(fp);
}
send_sync()
{
int c, i;
for (i = 0; i < 3; i++) {
tputc(ESC);
tputc('a');
while ((c = tgetc(ACKTIMO)) != TMO) {
switch (c) {
case CAN:
case EOT:
case ACK:
return c;
default:
continue;
}
}
fprintf(stderr, "starting handshake timeout\r\n");
}
fprintf(stderr, "giving up\r\n");
}
send_file(fname, more)
char *fname;
int more;
{
register int status, i, n;
register char *bp;
FILE *inf;
int naks = 0;
inf = fopen(fname, "r");
if (inf == NULL) {
perror(fname);
cleanup(-1);
}
recno = 1;
for (;;) {
n = fread(buf, 1, DATABYTES, inf);
if (n > 0) {
for (i = 0; i < RETRIES; i++) {
send_rec(buf, DATABYTES);
status = tgetc(ACKTIMO);
if (status != NAK)
break;
}
if (status == NAK || status == CAN) {
fclose(inf);
cleanup(-1);
/* NOTREACHED */
}
}
if (n < DATABYTES) {
tputc(EOT);
if (more) {
status = tgetc(ACKTIMO);
}
return;
}
recno++;
recno &= MAXRECNO;
}
}
send_rec(buf, recsize)
char buf[];
int recsize;
{
int i, cksum;
char *bp;
cksum = 0;
bp = buf;
for (i = 0; i < recsize; i++, bp++) {
if (txtmode && *bp == '\n')
*bp = '\r';
cksum += *bp;
}
tputc(SOH);
tputc((char)recno);
tputc((char)(MAXRECNO - recno));
tputrec(buf, recsize);
tputc((char)cksum);
}
static int ttyfd;
static FILE *ttyf;
static jmp_buf timobuf;
tgetc(timeout)
int timeout;
{
int c;
if (setjmp(timobuf))
return TMO;
alarm(timeout);
c = getc(ttyf);
alarm(0);
if (c == -1) /* probably hung up or logged off */
return EOT;
else
return c & BYTEMASK;
}
tputrec(buf, count)
char *buf;
int count;
{
write(ttyfd, buf, count);
}
tputc(c)
char c;
{
write(ttyfd, &c, 1);
}
timedout()
{
longjmp(timobuf, 1);
}
static struct sgttyb otty, ntty;
/* should turn messages off */
setup_tty()
{
int cleanup();
int timedout();
ttyf = stdin;
ttyfd = fileno(stdin);
ioctl(ttyfd, TIOCGETP, &otty);
signal(SIGHUP, cleanup);
signal(SIGINT, cleanup);
signal(SIGQUIT, cleanup);
signal(SIGTERM, cleanup);
signal(SIGALRM, timedout);
ntty = otty;
ntty.sg_flags = RAW|ANYP;
ioctl(ttyfd, TIOCSETP, &ntty);
}
reset_tty()
{
if (ttyf != NULL) {
sleep(2); /* should wait for output to drain */
ioctl(ttyfd, TIOCSETP, &otty);
}
}
cleanup(sig)
int sig;
{
reset_tty();
exit(sig);
}
put4(bp, value)
char *bp;
int value;
{
register int i, c;
for (i = 0; i < 4; i++) {
c = (value >> 24) & BYTEMASK;
value <<= 8;
*bp++ = c;
}
}
--------
macput.l
--------
.TH MACPUT local "22 June 1984"
.UC 4
.SH NAME
macput \- send file to macintosh via modem7 / macterminal
.SH SYNOPSIS
.B macput
file
.br
.B macput
[
.B \-rdu
] file
[
.B \-t
type
]
[
.B \-a
author
]
[
.B \-n
name
]
.SH DESCRIPTION
.I Macput
sends a file to a Macintosh running MacTerminal.
MacTerminal should be set to use the modem7 protocol,
and should have flow control disabled.
This program has only been tested with version -0.15x
of MacTerminal.
.PP
If none of the
.B \-rdu
flags are specified,
.I macput
sends three files to the mac:
.IB file .info ,
.IB file .data ,
and
.IB file .rsrc .
This is useful for returning files to the mac which were stored
using macget.
.PP
The
.B \-r
flag specifies
.I resource
mode.
Either
.IB file .rsrc
or
.I file
will be sent to the Mac, along with a forged
.B .info
file and an empty
.B .data
file.
The file sent becomes the resource fork of the Mac file.
.PP
The
.B \-d
flag specifies
.I data
mode.
Either
.IB file .data
,
.IB file .text
or
.I file
will be sent to the Mac, along with a forged
.B .info
file and an empty
.B .rsrc
file.
The file sent becomes the data fork of the Mac file.
.PP
The
.B \-u
flag requests
.I unix
mode, which is the same as
.I data
mode except unix newline characters are converted
into carriage returns.
.PP
The remaining options serve to override the default
file type, author, and file name to be used on the Mac.
The defaults for
.I resource
mode are "APPL", "CCOM", and
.IR file .
.I data
mode defaults are "TEXT", "????", and
.I unix
mode defaults are "TEXT" and "MACA".
.SH SEE ALSO
macget(local)
.SH BUGS
Doesn't work over flow controlled communication lines,
or when using rlogin.
.PP
Doesn't set the bundle bit on resource files, to incorporate any
icons into the Desk Top.
Use setfile to set the bundle bit.
-----------
end of file
Message 20 -- ************************
Mail-From: PATTERMANN created at 26-Jun-84 11:19:58
Return-Path: <jmh@BNL>
Received: from BNL by SUMEX-AIM.ARPA with TCP; Sat 23 Jun 84 09:35:09-PDT
Date: 23 Jun 84 12:34:23 EDT
From: jmh@BNL
Subject: binhex.bas
To: INFO-MAC@SUMEX-AIM
ReSent-date: Tue 26 Jun 84 11:19:58-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
The following program will convert a MacWrite or MacPaint document
into hex format, and visa versa, facilitating the upload and download of
Paint and Write documents.
Joel M. Heller
-----------------------------
10 '" BinHex -- MS-BASIC Hex to binary/Binary to hex file
20 '" conversion program for the Apple Macintosh.
30 '"
40 '"ABSTRACT: Will take any NON-RESOURCE file on the Macintosh
50 '" and create a file containing a 2-byte hexadecimal text represen-
60 '" tation of each byte in the source file. This program (as well as
70 '" MS-BASIC) will NOT read the Resource fork of a file. It will,
80 '" however, read the DATA fork. This allows conversion and trans-
90 '" mission of MacWrite and MacPaint documents! We cannot, however
100 '" send application program, system files, or Font Mover documents.
110 '" WRITTEN BY WILLIAM B. DAVIS, JR.
120 '" 6904 Hopkins Road
130 '" Des Moines, Iowa 50322
140 '" (515)-276-9064 or (515) 276-2345 (both home #'s)
150 '" CompuServe PPN: [71505,410]
160 '" MCI Mail Id: WDAVIS
170 '" Version 1.0.0 - 16-April-1984
180 '" Copyright (C) 1984 William B. Davis, Jr.
190 '" Permission is hereby granted for personal, non-commercial
200 '" reproduction and use of this program, provided that this
210 '" notice is included in any copy.
220 '"
230 '" Certain portions of this program (lines 4000-5450) were written
240 '" by Dennis F. Brothers are are subject to the following notice:
250 '" Copyright (C) 1984 - Brothers Associates, Waylan MA
260 '" Permission is hereby granted for personal, non-commercial
270 '" reproduction and use of this program, provided that this
280 '" notice is included in any copy.
290 '
1000 CLEAR 10000:GOSUB 5000
1010 DEF FND1(X$)=INSTR("123456789ABCDEF",LEFT$(X$,1))
1020 DEF FND2(X$)=FND1(RIGHT$(X$,1))+16*FND1(RIGHT$(X$,2))
1030 CLS:WIDTH "SCRN:",80:PRINT
1040 CALL TEXTFONT(0):CALL TEXTSIZE(12)
1050 CALL TEXTMODE(1):CALL TEXTFACE(8)
1060 PRINT"BinHex -- Hex to binary/Binary to hex file conversion"
1070 PRINT
1080 CALL TEXTMODE(0):CALL TEXTFACE(32)
1090 PRINT " Enter (1) to convert a binary file to hex format"
1100 PRINT " Enter (2) to convert a hex file back to binary"
1110 PRINT:PRINT"Your choice";:CALL TEXTFACE(0)
1120 INPUT D
1130 IF D=0 THEN CLS:END
1140 ON D GOSUB 3000,2000
1150 GOTO 1030
1160 '
1170 '" Hex--->Binary conversion procedure
1180 '
2000 CLS
2010 PRINT "Hex to Binary":PRINT
2020 LINE INPUT"Enter name of HEX file to convert FROM (or RETURN):";HF$
2030 IF HF$="" THEN RETURN
2040 XX$=HF$:GOSUB 3500:IF NOT FILE.EXISTS THEN 2000
2050 LINE INPUT"Enter name of BINARY file to CREATE (or RETURN):";BF$
2060 IF BF$="" THEN 2000
2070 OPEN"I",1,HF$
2080 OPEN"O",2,BF$
2090 LINE INPUT #1,D$:'" Prime the pump....
2100 WHILE LEFT$(D$,1)<>"#" AND NOT EOF(1)
2110 LINE INPUT #1,D$
2120 WEND
2130 '" if we reach this point (1) we have found the header, of the form
2140 '" #TYPECRTR where TYPE is 4 byte type code & CRTR is 4 byte
2150 '" creator code; or (2) we have reached EOF of hex file.
2160 WHILE NOT EOF(1)
2170 TYPEAPPL$=MID$(D$,2,8)
2180 PRINT:PRINT "TYPE of new file is:";MID$(TYPEAPPL$,1,4)
2190 PRINT "CREATOR of new file is:";MID$(TYPEAPPL$,5,4)
2200 F$=BF$:GOSUB 4500:PRINT:PRINT"Converting.";
2210 WHILE NOT EOF(1)
2220 LINE INPUT #1,D$
2230 IF D$="" OR LEFT$(D$,1)="." THEN 2280
2240 FOR I=1 TO LEN(D$) STEP 2
2250 PRINT #2,CHR$(VAL("&H"+MID$(D$,I,2)));
2260 NEXT I
2270 PRINT".";
2280 WEND
2290 WEND
2300 CLOSE
2310 BEEP:PRINT:PRINT "File ";HF$;" converted to binary file ";BF$;"
2320 LINE INPUT" Press [RETURN] key to display main menu";D$
2330 RETURN
2340 '
2350 '" Binary ---> Hex conversion procedure
2360 '
3000 CLS:PRINT "Binary to Hex":PRINT
3010 LINE INPUT"Name of BINARY File to convert FROM:";BF$
3020 IF BF$="" THEN RETURN
3030 XX$=BF$:GOSUB 3500:IF NOT FILE.EXISTS THEN 3000
3040 LINE INPUT "Name of file to receive HEXADECIMAL text:";HF$
3050 IF HF$="" THEN 3000
3060 OPEN"R",1,BF$,1
3070 PRINT "LENGTH of Binary file is ";BF$;":";LOF(1)
3080 OPEN"O",2,HF$
3090 FIELD 1,1 AS D$
3100 F$=BF$:GOSUB 4000
3110 PRINT "TYPE of binary file is:";LEFT$(TYPEAPPL$,4)
3120 PRINT "CREATOR of binary file is:";RIGHT$(TYPEAPPL$,4)
3130 CALL TEXTFONT(4):CALL TEXTSIZE(9)
3140 PRINT #2,"#";TYPEAPPL$
3150 ON ERROR GOTO 3260:REM EOF(1) DOESN'T SEEM TO WORK WITH LEN=1
3160 COUNT = 0
3170 FOR I=0 TO 30
3180 IF COUNT=LOF(1) THEN 3260
3190 GET 1,COUNT+1
3200 DD$=HEX$(ASC(D$)):IF LEN(DD$)<2 THEN DD$="0"+DD$
3210 PRINT #2,DD$;:PRINT DD$;
3220 COUNT=COUNT+1
3230 NEXT I
3240 PRINT #2,"":PRINT" ";COUNT;"/";LOF(1)
3250 GOTO 3170
3260 PRINT #2,"":PRINT:PRINT
3270 CLOSE:CALL TEXTFONT(0):CALL TEXTSIZE(12)
3280 BEEP:PRINT COUNT;" * 2 Bytes processed"
3290 PRINT "Binary file ";BF$;" converted to hex file ";HF$
3300 LINE INPUT " Press [RETURN] key to display main menu ";D$
3310 RETURN
3500 ON ERROR GOTO 3530
3510 OPEN"I",1,XX$:CLOSE
3520 FILE.EXISTS=TRUE:RETURN
3530 BEEP:PRINT"File ";
3540 CALL TEXTFACE(1):PRINT XX$;:CALL TEXTFACE(0)
3550 PRINT" does not exist!"
3560 LINE INPUT "Press the [RETURN] key to select another";XX$
3570 FILE.EXISTS=FALSE:RESUME 3580
3580 RETURN
3590 REM Subroutine to get type and application of a file
3600 REM
4000 FL=LEN(F$)
4010 F$=CHR$(FL)+F$
4020 FP!=VARPTR(F$)
4030 PARAM!=VARPTR(PARAMLIST%(0))
4040 FOR I=0 TO 79: POKE PARAM!+I,0: NEXT I
4050 POKE PARAM!+19,PEEK(FP!+2)
4060 POKE PARAM!+20,PEEK(FP!+3)
4070 POKE PARAM!+21,PEEK(FP!+4)
4080 GETFILEINFO!=VARPTR(GETFILEINFOCODE%(0))
4090 CALL GETFILEINFO!(PARAM!)
4100 TYPEAPPL$ = ""
4110 FOR I = 1 TO 8
4120 TYPEAPPL$ = TYPEAPPL$ + CHR$(PEEK(PARAM!+31+I))
4130 NEXT I
4140 RETURN
4150 REM
4160 REM
4170 REM Subroutine to set type and application of a file
4180 REM
4500 FL=LEN(F$)
4510 F$=CHR$(FL)+F$
4520 PARAM!=VARPTR(PARAMLIST%(0))
4530 FP!=VARPTR(F$)
4540 FOR I=0 TO 79: POKE PARAM!+I,0: NEXT I
4550 POKE PARAM!+19,PEEK(FP!+2)
4560 POKE PARAM!+20,PEEK(FP!+3)
4570 POKE PARAM!+21,PEEK(FP!+4)
4580 GETFILEINFO!=VARPTR(GETFILEINFOCODE%(0))
4590 CALL GETFILEINFO!(PARAM!)
4600 FOR I=1 TO 8
4610 POKE PARAM!+31+I,ASC(MID$(TYPEAPPL$,I,1))
4620 NEXT I
4630 SETFILEINFO!=VARPTR(SETFILEINFOCODE%(0))
4640 CALL SETFILEINFO!(PARAM!)
4650 RETURN
4660 REM
4670 REM
4680 REM Pre-allocate all variables so the machine code arrays do
4690 REM not move. Even so, always take array addresses just before
4700 REM using them, for insurance against unintended declaration
4710 REM of a new variable.
5000 F$="": FL = 0: REM File name and its length
5010 FP! = 0
5020 DIM PARAMLIST%(39): PARAM! = 0
5030 TYPEAPPL$=""
5040 GETFILEINFO!=0
5050 SETFILEINFO!=0
5060 X$="":D$="":HF$="":DF$="":FT$="":XX$="":DD$=":X=0:D=0
5070 I=0:TRUE=-1:FALSE=0:FILE.EXISTS=0
5080 REM Set up GetFileInfo ROM call
5090 REM
5100 DIM GETFILEINFOCODE%(25)
5110 RESTORE 5180
5120 I=0
5130 READ A: GETFILEINFOCODE%(I)=A
5140 I=I+1
5150 IF A<>-1 THEN GOTO 5130
5160 REM
5170 REM
5180 REM Machine language code to invoke GetFileInfo ROM function
5190 REM
5200 DATA &H4E56, &HFFF8, &H48EE, &H0101, &HFFF8, &H206E, &H0008, &HA00C
5210 DATA &H4CEE, &H0101, &HFFF8, &H4E5E, &H4E75
5220 DATA -1
5230 REM
5240 REM
5250 REM Set up SetFileInfo ROM call
5260 REM
5270 DIM SETFILEINFOCODE%(25)
5280 RESTORE 5350
5290 I=0
5300 READ A: SETFILEINFOCODE%(I)=A
5310 I=I+1
5320 IF A<>-1 THEN GOTO 5300
5330 REM
5340 REM
5350 REM Machine language code to invoke SetFileInfo ROM function
5360 REM
5370 DATA &H4E56, &HFFF8, &H48EE, &H0101, &HFFF8, &H206E, &H0008, &HA00D
5380 DATA &H4CEE, &H0101, &HFFF8, &H4E5E, &H4E75
5390 DATA -1
5400 REM
5410 REM
5420 RETURN
5430 REM
5440 REM
5450 END
Message 21 -- ************************
Mail-From: PATTERMANN created at 26-Jun-84 11:20:10
Return-Path: <SPECTOR@NYU-CMCL1.ARPA>
Received: from NYU-CMCL1.ARPA by SUMEX-AIM.ARPA with TCP; Mon 25 Jun 84 19:26:03-PDT
Date: 25 Jun 84 22:24 EDT
From: David H M Spector <SPECTOR@NYU-CMCL1.ARPA>
To: dba@CMU-CS-SPICE.ARPA
Subject: 68K Books.
Cc: info-mac@SUMEX-AIM.ARPA
Message-ID: <1777B0651.0F400035.1984@CMCL1.NYU-CMCL1.ARPA>
ReSent-date: Tue 26 Jun 84 11:20:10-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
David,
The Osborne-McGraw Hill book, "68000 Assembly Language Programming", by
Kane, Hawkins & Leventhal seems pretty good. Its style is obviously
intended for those who have never programmed in assembly before, but its a good
primer for the 68K.
David Spector
NYU Systems Group
Spector@NYU-CMCL1
-------
Message 22 -- ************************
Mail-From: PATTERMANN created at 26-Jun-84 11:20:19
Return-Path: <FURUTA@WASHINGTON.ARPA>
Received: from WASHINGTON.ARPA by SUMEX-AIM.ARPA with TCP; Mon 25 Jun 84 20:59:41-PDT
Date: Mon 25 Jun 84 20:52:41-PDT
From: Richard Furuta <Furuta@WASHINGTON.ARPA>
Subject: surge protectors?
To: info-mac@SUMEX-AIM.ARPA
cc: Furuta@WASHINGTON.ARPA
ReSent-date: Tue 26 Jun 84 11:20:18-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I'd appreciate hearing what people have to say about whether or not it
is necessary or useful to use a surge protector with the Macintosh.
I'd also like to hear specific recommendations from people. What, for
example, is the difference between a $19 surge protector and a $60
one?
--Rick
-------
Message 23 -- ************************
Mail-From: PATTERMANN created at 26-Jun-84 11:20:41
Return-Path: <byard@dca-eur>
Received: from dca-eur by SUMEX-AIM.ARPA with TCP; Tue 26 Jun 84 07:43:41-PDT
Date: 26 Jun 1984 14:38:23 GMT (Tuesday)
From: Larry F. Byard <byard@dca-eur>
Subject: RAMs
To: info-mac@sumex
ReSent-date: Tue 26 Jun 84 11:20:41-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Anyone know for sure how fast the 64K chips in the Mac are? Yes,
I know it has an ~8 MHz clock and I could make a good guess by looking
at the 68K timing charts; but knowing for sure what they are using now
would be helpful. I am keeping a close eye on 256K prices (retail,
unfortunately). Thank you. Larry
.
Message 24 -- ************************
Mail-From: PATTERMANN created at 26-Jun-84 11:20:54
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Tue 26 Jun 84 09:19:14-PDT
Date: Tue, 26 Jun 84 09:22:03 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex, winkler@harvard
Subject: re: porting unix programs to mac
Cc: croft
ReSent-date: Tue 26 Jun 84 11:20:53-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
"...and does not exceed sumacc's limit of
one 32K segment..."
While it is true that SUMACC currently does not support overlays,
there is no limit on the size of the program (other than the amount
of physical memory). Thus SUMACC programs on the current hardware
are limited to about 80K bytes.
The 32K byte limit you mentioned DOES exist for Pascal (workshop)
segments, since these use PC-relative addressing, which is restricted
to +-32K offsets.
--Bill
Message 25 -- ************************
Mail-From: PATTERMANN created at 26-Jun-84 11:21:03
Return-Path: <MIKES@CIT-20>
Received: from CIT-20.ARPA by SUMEX-AIM.ARPA with TCP; Tue 26 Jun 84 10:26:44-PDT
Date: 26 Jun 1984 1027-PDT
Subject: Need help on Text Edit guts
From: Mike Schuster <MIKES@CIT-20.ARPA>
To: info-mac@SUMEX-AIM.ARPA
ReSent-date: Tue 26 Jun 84 11:21:03-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Has anyone seen documentation on the following issues concerning
the Text Edit Manager:
1) When the text gets to big (e.g. free memory is exhausted),
TEPaste and TEKey (etc) do things to the text edit record and its
graph port that are not documented in the 9/28/83 guide. What
is the proper way to learn about and handle these cases?
2) How are the text edit globals 'tescrplength' and 'tescrphandle'
changed when the scrap gets large? I have noticed that disk io
occurs when a very large piece of text is TECUT or TECOPY'ed.
This too, does not seem to be documented.
3) When bringing up dialogs and alerts (especially after calling
ParamText to update static text) the text edit globals 'tescrplength'
and 'tescrphandle' seem to get changed. When else does this happen?
4) The hooks 'wordbreak', 'clickloop', and 'tewdbreak' are not documented.
What are the argument passing conventions to these routines? I know
I could use the Disassembler, but does anyone have some info?
5) TECalText seems to ignore the field 'TELength', sometimes. Is calling
NewHandleSize on 'hText' necessary and/or sufficient?
If no one has the answers, maybe some certified developer could ask Apple
for internal documentation on text edit? Needless to say, I will
release the SUMACC source for my text editor to <info-mac> as well as
a list of hints as soon as I can resolve these (and a few other) issues.
Thanks.
Mike
(mikes@cit-20, mikes@cit-vax)
-------
-------