Re: 80-col. firmware bug: help!

[dempson@atlantis.actrix.gen.nz (David Empson)]

In article <4i02td$q44@acme.freenet.columbus.oh.us>,
Dave Althoff <dalloff@freenet.columbus.oh.us> wrote:
> It's not a new bug, this one, I think, is documented...
>
> [Storing 0 into location $24 while in 80-column mode doesn't set the
> column to zero.]

It isn't a bug at all.  It was done deliberately to get Applesoft
listings to work properly in 80-column mode.  It might also have some
interaction with line wrapping modes of I/O cards, when screen output
is enabled.

(Aside: location $25, CV, will always work as expected.)

Looking through the 80-column BASIC firwmare listing for the original
IIe, the behaviour is as follows.  The locations of interest are

$0024   CH     (cursor horizontal for old firmware) 
$047B   OLDCH  (last cursor horizontal position for 80-column firmware)
$057B   OURCH  (current cursor horizontal position for 80-column fimrware)

80-column INIT:

- Copy CH to OLDCH.
- Call the internal HOME routine, which sets OURCH to zero.
- Output the character that was provided to $C300 (see below).

80-column OUTPUT:

- Compare CH to OLDCH.  If they are different, store the current value in
  OURCH.
- Output the character to the screen (assuming it is printable), or process
  a control character.  The horizontal position (OURCH) is updated, wrapping
  to the next line as required.
- The current value of OURCH is copied into CH and OLDCH.
- If we are in 80-column mode, then CH and OLDCH are forced to zero,
  UNLESS the horizontal position is within 8 characters of the right margin.
  In this case, CH and OLDCH are set to (40 - (WNDWDTH - OURCH)), which will
  force Applesoft to wrap listing output.

In other words, if you are in 80-column mode, then CH and OLDCH are
always forced to zero after a character has been output (except if
near the right margin), and you will not be able to do an HTAB 1 (or
store zero at location $24, the equivalent operation), because the
entry code will not detect a change in the value.

The enhanced IIe firwmare has an improvement: on entry to the output
code, if OURCH is greater than the window width, then OURCH is forced
to zero.  It also eliminates the rubbish about checking for the cursor
being near the right margin - CH and OLDCH are always forced to zero
if 80-column mode is active.  Applesoft BASIC in the enhanced IIe takes
care of list wrapping itself in 80-column mode.

The IIc firmware (UniDisk 3.5 version) behaves the same as the
enhanced IIe (it is organised quite differently), and I assume the
IIgs firmware is also the same (no listing to check).

There is a comment in the IIc firmware listing that location $24 is
set to zero in order to prevent code which load a LDY CH then STA
(BASL),Y from storing outside screen memory.

The IIc Technical Reference says that if you are using the 80-column
firmware, you should use OURCH ($057B) instead of CH ($24).

The IIe manual is rather vague.  The only hint is that you should use
POKE 1403 ($057B) to set the horizontal position, rather than using
the HTAB command.

The IIgs manual doesn't mention this problem at all.

I cannot find any technical note on the problem.


This is going to be a problem if you might be using the built-in
80-column firmware of the IIe, IIc or IIgs.  It won't work at all with
a II+ 80-column card.

Here is my suggested solution:

   If 80-column mode might be active, and you are only setting the
   position within the first 40 columns, do an HTAB by storing the
   desired horizontal position in location $057B, AND in location $24.
   If you want to go past column 40, check that 80-column mode is active
   first (in which case, you can just use $057B).

   Before writing to the slot 3 screen hole, at least verify that there
   is an 80-column card present - in a IIe or IIgs, there might be
   something else in slot 3, and you could be stepping on its screen
   holes.  Under ProDOS, you can check if bit 1 of MACHID ($BF98) is set.

   If you KNOW you are using the 80-column firmware, never touch $24,
   and use $057B directly.
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand