APPLE II Q & A

APPLE II Developer Technical Support

Q What's the best way to do text-only printing to a character device through GS/OS?

A If you want to print text to a GS/OS character device, here's how you do it:

Look at all the on-line devices to find which are character devices. You
can tell when a device is a character device by examining bit 7 of the
"characteristics" word returned by DInfo--the bit is set for block devices and
clear for character devices. You don't have to hard-code a list of character
device IDs.
Present the user with a list of device names followed by their location and
generic type in parentheses. You can adjust the names of device types to reflect
your use. For example, ".RPM (AppleTalk printer, port 1)," ".DEV2 (serial
modem, port 2)," or ".DEV3 (generic character device, slot 5)." You can use
bit 3 of the slot returned by DInfo to know whether to return "slot" or "port,"
too.
When the user selects a printing device, call Open on the device name
(such as .RPM for an AppleTalk printer). Use Write to write the information,
just as you would to a file; then call Close (you can call Flush if you like, but
it shouldn't be necessary). That's all you need to do.

Remember not to embed ImageWriter or any other printer-specific codes in the
output stream. With the exception of choosing a device and creating a file, this same
code could be used to print to any text printer or to another device such as a disk or
modem. You might give users a "text printing preferences" dialog where they can enter
some codes if they like, and you might have built-in sets for ImageWriters and other
common printers, but don't make it too complicated. These instructions are very
generic and will work well on any setup, not just an ImageWriter II connected through
the serial port.

Q On a ROM 03 Apple II GS, I save and restore the mouse mode by getting it from
ReadMouse, setting the mode to what I need, and restoring the value (with SetMouse)
when done. This sometimes kills the mouse--I don't get any mouse movement until my
program quits. Help! By the way, this isn't a problem on ROM 01 machines.

A The ROM 03 mouse firmware doesn't behave as documented in two respects. First, it
sometimes returns an illegal mouse mode value from ReadMouse. Specifically, there's
garbage in the high nibble of the mouse mode byte. Second, SetMouse returns an error
and takes no action when passed an invalid mode, even though the Apple IIGS Toolbox
Reference says it returns no errors. When you try to restore the invalid mode,
nothing happens and the mouse stays in whatever mode you had it in--if it's not what
the system needs, the mouse will appear "hung" until someone sets the mode to what
the system does need.

You can work around this problem by masking off the high nibble of the mode result
from ReadMouse (AND #$000F in 65816 assembly) before passing it to SetMouse.
This problem is fixed in Apple IIGS system software version 6.0-- ReadMouse always
returns a valid mode under 6.0.

Q When I call SFMultiGet2, I randomly get error $1705 (bad pathname descriptor in
the reply record) even though that error doesn't mean anything for that call. Any
ideas?

A All versions of SFMultiGet2 before Apple II GS System 6.0 incorrectly look at two
of the words in the reply record (offsets $0008 and $000E) to make sure they don't
contain the value $0002. That value would be illegal in those positions--in any of the
other new Standard File calls. SFMultiGet2 doesn't use the same reply record, but
pre-6.0 versions of Standard File accidentally check those fields anyway. Make sure
the values in bytes that are past the beginning of the 6-byte reply record are not
$0002. This is fixed in System 6.0.

Q Although my application fully supports GS/OS, the Finder uses slashes instead of
colons in the pathnames in message #1. This means my application can't open any files
that have slashes in the filename.

A The Finder and its message-passing conventions were originally released before
GS/OS was written. Applications depend on the slash (/) as the separator character to
be able to parse these pathnames (for example, to find the filename to use in a
document window title). If the separator character were to change, many older
applications would break.

Finder version 6.0 may support an additional message containing a list of fully
expanded GS/OS pathnames. These pathnames use colons as separators and aren't
limited to 255 characters. See the Finder 6.0 documentation for details on using this
message.

Q I've written a program that hangs inside Standard File under Apple II GS System
5.0.4, but works fine under development versions of 6.0. I'm not using any
6.0-specific features. What could be the problem?

A Standard File before System 6.0 does not behave gracefully if called with both
prefix 0 and prefix 8 empty. Try setting one of these prefixes to an existing directory
and see if your problem vanishes.

Q I can't find the ProDOS partition on Volume IX or later of the Developer CD Series
discs. What's happened?

A Apple II information was duplicated on all Developer CDs from Volume III through
Volume VIII because without the ProDOS partition, Apple II users couldn't see the
information, and without the Apple II folder on the HFS partition, the information
couldn't be shared on an AppleShare file server (or Macintosh System 7 File Sharing).
Apple II GS System 6.0 includes an HFS (Macintosh) file system translator, which
means that Apple II GS developers can access the information on the HFS partition,
making the ProDOS partition unnecessary.

The Apple II information can be found on the HFS partition with the pathname Dev.CD
Vol. IX:Development Platforms (Moof!):Apple II. Note that this means the Apple II
folder can only be accessed from ProDOS 8 using AppleShare with long naming on--the
path to the Apple II folder is not a legal ProDOS 8 pathname.

Q Apple II Applesoft's floating-point routine results are sometimes accurate to only
two places. For example, the answer returned for PRINT 55555.099-55555.09 is
9.01031494 E-03. How can we get more accurate results?

A The accuracy loss you're experiencing with the Applesoft floating-point routines is
normal. If you convert a number such as 55555.099 to a base 2 floating-point
number, you won't get an exact representation using Applesoft's floating-point
routines or even 96-bit precision IEEE numerics. Because 9.01031494 E-03 is
0.0090103, you can see that you have accuracy out to three and a half decimal places.
The solution is to determine the accuracy that you want and massage the result to give
you that accuracy. Here's a sample program that shows common Applesoft rounding
techniques:

1 REM Round to 3 decimal places of accuracy example
10 Input a
20 Input b
30 If a-b>1000 then 100: REM no 3-digit rounding of numbers >1000
40 Print "Standard Applesoft Non-accurate result:";a-b
50 Print "Truncated result:";
   INT((a-b)*1000)/1000 60 Print "Rounded result:";
   INT(((a-b)+.0001)*1000)/1000
70 Goto 10
100 Print "Result has 3 decimal accuracy already:";a-b
110 Goto 10

This is the only way that you can get Applesoft to clip the numbers, apart from using a
separate floating-point engine. Alternatively, you can do your own conversion from
Applesoft internal numeric format to a string in assembly language and have it
simulate the above operation when converting the number.

Kudos to our readers who care enough to ask us terrific and well thought-out
questions. The answers are supplied by our teams of technical gurus; our thanks to all.
Special thanks to Matt Deatherage, Jim Luther, Dave Lyons, Jim Mensch, and Tim
Swihart for the material in this Q & A column. *

Have more questions? Need more answers? Take a look at the Dev Tech Answers
library on AppleLink (updated weekly) or at the Q & A stack on the Developer CD
Series disc.*