delaneyg@wnre.aecl.ca ("Comp.Binaries.Apple2 Forwarding") (07/29/90)
Notes from Kansas: Views on the A2-Central Developers Conference
by Marc Farnum Rendino
(Sure you can reprint it for your newsletter or whatever!
Just credit me, and send me a copy.)
Day 0: The second less-than-semi-annual GS College
The first GS College was in 1987. To give you an idea how long ago that was,
Matt Deatherage, Keeper of the General Truths was still in Minnesota then!
This version of the GS College was run by Apple II Developer Tech Support -- a
heck of a great bunch of folks for whom the slogan "Apple II Forever!" is as
meaningful as ever! The came in force (about 30 folks from Apple all together!)
and did a great job.
Only some KansasFest attendees opted to participate, so the atmosphere was
generally lees like a lecture, and more like a two-way interchange. Levels of
experience ranged from beginner to expert and it seemed to me that all were
well served.
There were advanced discussion sessions where one could pick the brains of the
engineers who actually wrote parts of the System Software (ex: GS/OS,
QuickDraw, MIDIsynth, etc.), but it seemed that most participants stuck to the
general track.
The general track began with an overview of GS/OS and the Toolbox. Matt
Deatherage described the boot process and how GS/OS is able to boot from
_anything_ (ex: a server) unlike other operating systems (like that of the Mac).
C.K. Haun (of WriteIt and DesignMaster fame) then discussed tools. Why should
one use tools? Reliability, ease of use, less memory wasted, and they're
maintained by someone else!
Next Eric Soldan and C.K Haun led us into programming strategies -- what to do
_before_ you get to the keyboard.
Eric's prefers to plan the code so that bugs are avoided, and when they do pop
up, they're easier to find. He suggests having a clear view of the end result,
and when it's necessary to vary from that, to do it consciously and with
consideration.
Another good suggestion offered by Eric is to plan for when to freeze the
system and _stick_to_it_! For example, when a new System Disk comes, it's very
easy to fall into the trap of integrating some of the new features. Don't!
Ship it, and then work new features into a new release. A spec that's
constantly changing is one that doesn't ever ship, and if it does, it's not too
solid.
Hints for planning the job:
o write the way you think
o design it to debug it
o maintainability and expansion -- the world changes!
o segmentation
o use resources!
o keep "time to market" in mind:
think of it as a race; there's only one winner!
choose a path and stick to it (_not_ backtracking helps!)
C.K. Haun then expanded on the use of the Toolbox. "Tools are your best buddy."
"Toolbox programming is the start of the rest of your programming life." And
if you think about that for a brief moment, you'll realize it makes a lot of
sense! Toolbox programming is like a lead-in to object oriented programming.
In some ways, it is object-oriented. Surprise! Toolbox programming also
helps tremendously in ports, conversions and parallel development.
C.K. went on to discuss some of the tools specifically:
The Memory Manager: Use it! It works well! It takes care of a lot of the
drudgery for you. And don't forget the new Out Of Memory Queue; it's a great
way for your application to be much more friendly when memory gets tight!
(See Toolbox Reference Volume III and the Technotes.)
QuickDraw: Take advantage of "fast port" features and use shadowing. Follow
the rules! Doing so allows you to take advantage of Jim Mensch's constant
tweaking. He sped things up something like 4 times for System 5.X; he says
it's possible to speed it up even more!
The Window Manager: TaskMaster! And now TaskMasterDA! Make your content
draw routines smarter. Check the port. (General clue: If you're not passing
the port to a call, do a GetPort and SetPort before it -- it'll save some
headaches.) RefCons: Are you wasting them? They're there just for you!
The Control Manager: Use extended controls! (Otherwise TaskMaster can't handle
it for you.) Use custom controls.
The Resource Manager: It's not a replacement for a data file! It does take a
lot of the management burden off you, by taking care of handles, memory, disks,
etc. It is possible to use more than one resource fork...
Eric expounded further on resources. "Data is easier to debug than code."
Think about it!
More on design ("Starting _not_ from scratch"): Design the first application to
be recyclable. ("It's good for the programming environment." <grin>) This will
probably save time for the _first_ app, and definitely save time for subsequent
ones. It generally produces better code, since it's already been tested!
Your app is similar to _something_ -- start there! If you don't have one that's
similar, someone does. Like DTS -- they have several megabytes of sample code!
Eric then demonstrated the idea of using one app as a base for a new one. One
reason he chose the one he did was that it was fairly recent, so he was
familiar with it.
A few last tips from Eric: Use a debugger to trace through the code once -- you
may be surprised what you find! Also, get someone else to look at your code,
since it's very easy for you to read what you think, rather than what's
actually on the screen!
After lunch we faced the reality of what happens when you do sit down to
write something: it crashes. <grin>
Eric Soldan: Worry about speed _later_. Besides, speed improvements are often
necessary in exactly the opposite places you thought. Use debugging code like
"PtrCheck", a utility that Eric designed to make sure you're not using
uninitialized pointers. (PtrCheck is available from DTS.)
Code so it's difficult to use something incorrectly. Check the parameters on
entry to a routine; don't assume that since you wrote it you'll always use it
correctly.
Then Dave "Mr. Tangent" Lyons stepped in. He works a little differently from
Eric. He _like_ to debug! He dumps into the monitor on purpose to see what's
going on and, before you know it, he's tracing some system software totally
unrelated to what got him into the monitor in the first place. (Hence the
nickname.) His idea is that he'll probably end up needing to know about it
sooner or later, so why not trace it as it comes up!
Dave is the author of the famous Nifty List CDA which is the first thing _any_
programmer should get. Or anyone who's even remotely curious about the innards
of the system. (DAL Systems, PO Box 875, Cupertino, CA 95015-0875) Dave gave
attendees version 3.0 which, in addition to all the things Nifty List is famous
for, now adds things like "Big Brother" which monitors your memory use. ("Hey!
That's not your memory!") If you don't have Nifty List, get it. Get it now.
At 3 PM Llew Roberts described his experiences in Testing. Know what you are
testing; lay out the requirements that the application must meet and design
how to comprehensively test them. Design it so that a naive user could follow
it -- as a matter of fact, it's better if a naive user actually performs the
test. You don't want bug reports, you want the tester(s) to find them _before_
you ship.
Design the test plan from the specs, not from the application itself. Test
the limits of the program. Find places where there are constraints, such as
a routine where a date is read in. Test for values that are outside the range
of valid data. Test to make sure that defined functions are indeed performed
properly. (Does is print?) Then the fun part: destructive testing. Give it
to your mother and watch what breaks when a _real_user_ get ahold of it!
Test in all possible system configurations. For example, unless you require
a color monitor, test it with a B&W -- you might be surprised how much
suddenly becomes invisible or indecipherable. Try it with old System Software.
Don't forget about floppies!
A good rule of thumb: "A hack today is a crash tomorrow!"
Then there's regression testing. Try out old bugs. Are they really fixed?
Did the fix introduce any new bugs?
Use outside testers. They're honest! <grin> They have no vested interest
and they'll tell you when they don't like something. And they'll hit things
you've never thought of.
Next up were Jim Luther and Dan Strnad to talk about connectivity.
Jim reminded us of the 2nd edition of the IIGS Hardware Reference and Technote
#30 for corrections to it, the Firmware Reference and Technote #25 for changes
to it, and an upcoming Technote on the IIGS memory slot.
Dan launched into one of the main uses for AppleTalk, Apple's File Server
software, AppleShare. Some Dos and Don'ts for AppleShare: let the user know of
his/her privileges, temp files must have unique names since other users may be
storing temporary data to the same place, minimize segmentation to avoid
having to go back to the network many times (for speed).
There are also two calls that may come in handy for when you need a bit more
time than AppleTalk is willing to give you between checking that you're still
there: RAMForbid causes AppleTalk packets to be buffered and RAMPermit turns
buffering back off. (See the Technote #3.)
Then Jim got into network printing. There are basically four different ways
to address AppleTalk printers! Via the Toolbox Print Manager, the Remote
Printer Manager (RPM), the .RPM GS/OS device driver, and the Printer Access
Protocol (PAP). Start at the top of the list. If you can't find the service
you need, move down the list. For example, it may be necessary to use PAP to
download LaserWriter fonts, but printing a document to the LaserWriter can
usually be done with the Print Manager.
Day 1!
The day started with the "Apple IIGS System Software Update" which was
basically a repeat of the session in May at the Developers Conference. There
was also a session on some new happenings in the ProDOS 8 world, but I was busy
at the IIGS session! I hear that there will finally be a selector built into
ProDOS 8.
The next session was with Eric Soldan describing Dynamo, a system that adds
a great deal of power and flexibility for the ProDOS 8 developer. The code
generated with Dynamo is often smaller and faster than assembly! Which makes
a bit of sense because it actually is assembly that's been tweaked.
Recent additions to the Dynamo package include integer and floating point math,
string handling, and arrays. All this and it uses only two bytes of zero page!
When you assemble the source you get to experience the other side of the Dynamo
package: AppBuilder. A powerful linking/loading system that can load the code
anywhere you want: any bank, the language card, whatever. And overlays too!
Dynamo is available in an MPW version and an APW version. Due to some problems
with APW macros, the macros of Dynamo are not available to APW users. Though a
good portion of the system, Dynamo is still very useful to the native
developer.
(At the same time Mark Cecys demonstrated MIDIsynth and synthLab to an
enthralled audience. It really has to be heard to be believed!)
Jim Luther and Dan Strnad discussed AppleTalk further, exposing the ability
to do asynchronous calls. In effect, telling AppleTalk to do something, and
getting immediate control back; before the task is completed! This could come
in handy! Even for such mundane things as giving the user the chance to
cancel something.
(At the same time Jim Mensch showed off his Animation Toolkit. This tool is
amazing and yields at least 30 frames per second (maybe 60?) of multi-character
animation. It can be used just like any normal toolset (I believe it will be
distributed as any other tool; with a system disk), OR you can ask it to
generate a jump table for more speed, OR it can generate code for you (and then
you can toss the tool out of memory), OR it can simply be used to generate
characters! And that doesn't even cover it all!)
At lunch we got to meet Jane Lee, in Apple II Product Support. She's very
personable, knowledgeable about the Apple II, and won't take no for an answer!
It recently came to her attention that there was going to be a major Apple ad
in the Wall Street Journal, but only the Mac was in the ad. After she was done
with it, it mentioned the Apple II several times and had some Apple II pictures
in it. We're lucky to have her on our side!
She told us that most Apple II's are purchased in the school market, but Apple
_is_ looking into new markets. There is also work on new advertising and Jane
is trying to get some money for TV ads! Also, work will continue to insure that
the Apple II is well represented in generic Apple ads. Apple II Evangelism and
more R&D are also being worked on!
After lunch we signed a non-disclosure agreement that for System 5.0.3 and
HyperCard GS... All I can say about it, is that it looks solid and that this
will _not_ knock off HyperStudio. HyperCard is a programmers tool; HyperStudio
is a _users_ tool. HyperStudio remains the most accessible way for _anyone_
to use an Apple and all the myriad things that can be hooked up to it.
At dinner we got to meet another of our supporters at Apple; Ralph Russo who
heads Apple II Products. He is a dynamic man, and is devoted to fixing the
Apple II situation. He's been on the job less than 2 months, but already
things are jumping! He hopes to have a strategy laid out before summer's end.
As far as general plans go, he agrees that it's necessary to be aggressive;
not to sit back on the "continue to service and support" line. Our kind of
man!
Day 2:
I began Saturday with Matt Gulick regaling us with tales of SCSI. He told us
about what the High-Speed SCSI card and his new drivers can do. Did you know
that with these drivers you can hook up virtually any hard disk? And it'll
work! This goes for any fixed drive (like a Seagate) _and_ for removable media
like SyQuests and optical drives. Just plug and play! The drivers ask each
device what it's capable of and react accordingly.
And he showed us some new things like scanner and tape drivers. With an
application that a tester whipped up, he showed us some _amazing_ scans. The
quality was astounding! And, just because it can be done, he scanned intonormal HiRes! It wasn't half bad! (And the app had been written overnight!)
We also got to see the "Star Wars" demo. (Actually, The Empire Strikes Back.)
In this demo, digitized (from a laser disk) frames of the movie are played back
from a hard drive to the Super HiRes screen of the IIGS -- _faster_ than real
time! And it's done with _one_ SCSI call!
The new SCSI card supports full arbitration. For example, it would be possible
to tell two devices to do something to each other, send them on their way, and
get control of the CPU back for something else!
At 10 AM I ran a session on Computing for the Handicapped. We didn't fill the
room, but we did discuss things from the Adaptive Firmware Card to the Human
Interface itself. Don Brady from Apple was nice enough to join us, and I'm
sure he's already talking to the right people about some of the extensions we'd
like to see!
(At the same time were sessions on CD ROM and the Apple II (Llew Roberts who
helped with the GEM CD) and GS Programming in the 1990's (Tim Swihart). I hope
others who went to these sessions will jump in to let us know what went on
there.)
Next was Media Integration with Dan Hitchins and Jim Merritt. We got to see
some amazing things in this session. For example, there is a product from
Houghton Mifflin called "EcoVision" which is based on a video disk and uses
a sort of a hypermedia interface to get students to think about, research and
report on environmental concerns in their area. There are live video clips
and even a video "agent" to guide the student. It really is amazing!
Also, we were shown some demos of a 640 X 400 resolution screen! Using
technology that's readily available today -- the Video Overlay Card! It's not
at all trivial to get the system software (like QuickDraw) to use this, but
one wonders if we might see this sort of thing used in future systems...
At lunch we met David Szetela who is head of Apple Developer Support. You
remember David from his Nibble days don't you? <grin>
One of the neat things David had for us was the revelation that Apple II
developers (not Mac developers) from outside the US will now receive support
direct from DTS in Cupertino! There is a new direct DTS fax number as well!
David also discussed the new Partners and Associates programs where an Apple
II developer can get into the game for as low as $150! What are you waiting
for folks?! Jump in! Believe it or not, this price also gets you hardware
discounts and an invitation the yearly Developers Conference! It's finally
feasible to show Apple how many of us Apple II developers there really are.
Imagine the reaction at Corporate if only half of us joined up?!
Later that afternoon Matt Gulick ran another session that got down and dirty
about SCSI. (Sorry!) We learned that it's possible for a driver to be
loaded after boot, but not possible to unload it. There is also a relatively
new GS/OS call that allows anyone to flush the cache ($2026).
And Eric Soldan went into detail about printing. Apparently printing is the
last thing people think of, and it's not all that simple. One bit of sage
advice that he had to offer was to keep printing in mind when writing
window content draw routines -- it can make printing a lot easier.
Tired, but happy we thought about going to the baseball game, but it was not
to be! All hell broke loose and we all got soaked. So we went to "Crown
Center", watched a movie (a group of us saw DieHard II), scared the heck out
of some poor hostess at a restaurant downstairs, and took over the back room
until the bus showed up.
All in all, one heck of an event! Tom Weishaar is to be thanked! As well as
all the great Apple folks that came! And all the other folks, from the
stars to the unknowns! (I think some of the unknowns can't claim that title
anymore!)
I wonder if Tom is taking reservations for next year yet...
<end>toddpw@tybalt.caltech.edu (Todd P. Whitesel) (07/31/90)
delaneyg@wnre.aecl.ca ("Comp.Binaries.Apple2 Forwarding") writes: >Notes from Kansas: Views on the A2-Central Developers Conference >by Marc Farnum Rendino [...] >Also, we were shown some demos of a 640 X 400 resolution screen! Using >technology that's readily available today -- the Video Overlay Card! It's not >at all trivial to get the system software (like QuickDraw) to use this, but >one wonders if we might see this sort of thing used in future systems... [...] I have a slide show demo that uses this. It runs only under P8, because GS/OS allocates some handles inside the alternate SHR buffer (i.e. $E0/2000.9fff) which is needed by the 400 line display mode. Getting the O/S to use it would not be very difficult, but it would play hell with some of the worst-designed (i.e. GS hardware specific) QuickDraw calls. Most window-based programs would still work, but many of the paint programs wouldn't be able to use the new graphics mode without substantial modification. 3200 color (6400 color?) would only work if you connect the motherboard composite video to the VOC's input and set the VOC to sync but only display its own video; this is easy and can even be done with the Videomix NDA. Todd Whitesel toddpw @ tybalt.caltech.edu
mattd@Apple.COM (Matt Deatherage) (07/31/90)
In article <75*delaneyg@wnre.aecl.ca> delaneyg@wnre.aecl.ca ("Comp.Binaries.Apple2 Forwarding") writes: >Notes from Kansas: Views on the A2-Central Developers Conference >by Marc Farnum Rendino > > >Day 0: The second less-than-semi-annual GS College > >The first GS College was in 1987. To give you an idea how long ago that was, >Matt Deatherage, Keeper of the General Truths was still in Minnesota then! > This would be significantly more flattering had if I actually, at any time in my life, had ever been in the (fine) state of Minnesota. I did take the opportunity after Kansas to visit my family in Oklahoma, where I lived before coming to Apple. (Minnesota and Oklahoma are often confused because of the high Scandanavian populations of both states.) -- ============================================================================ Matt Deatherage, Apple Computer, Inc. | "The opinions represented here are Developer Technical Support, Apple II | not necessarily those of Apple Group. Personal mail only, please. | Computer, Inc. Remember that." ============================================================================