Re: ROM 3 Questions

[a_specto@alcor.concordia.ca (Mitchell Spector)]

dempson@actrix.gen.nz (David Empson) wrote:

>william strutts <wrstrutts1@home.com> wrote:
>
>> I have two ROM 3 motherboards.  They are basically identical
>> except for the actual ROM's.  The First machine has two ROM's
>> marked 341-0748 and 341-0737.  The Control Panel Screen
>> for this machine shows the options: Control Panel, Alternate
>> Screen Mode.  The second machine has these ROM's marked
>> 341-0728 and 341-0748 (this is a different size ROM than the
>> other machine, it is four pins shorter than the other Machine).
>
>One of the machines probably has a pre-release version of the firmware
>(most likely to be the 341-0728 ROM).  I don't have my ROM 3 handy, so I
>can't check it against my own machine.  I recall looking into this
>several years ago.

    That was more than seven years ago, and you indeed did. I recall
your having done a complete disassembly and comparison between 
the beta and standard (final; masked production) ROM 3 firmware in
great detail.

>I don't remember the details off the top of my head, but there was only
>a very minor change between the beta and final version of the ROM 3
>firmware, consisting of one initialization routine somewhere in the
>memory manager, I think.  My previous posting on the subject predates my
>current News software, so I don't have a copy of my earlier posting on
>hand.

    That's what Goggle/DejaNews is handy for. :) I just looked it up
and found it without too much difficulty. Actually it was a reposting
and near the start of when DejaNews began archiving messages. 
Rather than post the link to that post (a URL which is over three
lines long!), here's a copy of that actual posting. My apologizes in
advance if the formatting isn't intact...

---------Begin post clipping------------------------------------------

Differences between the two versions of the ROMs in the ROM 3 IIgs
 
by David Empson (dempson@actrix.gen.nz)
 
Apple released two sets of ROMs for the "Apple IIgs with 1 megabyte of
memory", popularly known as the "ROM 3 IIgs".
 
The original set of ROMs has the serial numbers 341-0728 and 341-0729.
These are very rare: I only know of one IIgs that has been confirmed
to have these ROMs.  [Make that two now]

The revised ROMs have the serial numbers 341-0748 and 341-0737. 
These are by far the most common.
 
I have done a byte-for-byte comparison on the old and new ROMs, and
have identified the following differences:
 
Banks $FC and $FD are identical.  [This means that ROM 341-0728 is
identical to ROM 341-0737.]
 
Bank $FE has changes in the following locations:
 
    $FE345F  (branch destination)
    $FE3466  (branch destination)
    $FE3475 to $FE349D  (code changes)
 
Bank $FF has changes in the following locations:
 
    $FF6232  (branch destination)
    $FF623A  (low byte of table address)
    $FF623E  (branch destination)
    $FF6242 to $FF6260  (code and data moved due to an inserted
                         BRA instruction at $FF6242)
    $FFFFF6 to $FFFFF7  (ROM checksum)
 
The Bank $FE Changes
====================
 
The changes in bank $FE are within an internal QuickDraw II routine
that calculates the memory address of a line, based on the current
LocInfo structure (i.e. pixel image base address, boundary rectangle
and row width in bytes).
 
The earlier version of the ROM 3 has a bug in this routine: if the row
width or line number is too large, the wrong address will be
calculated and QuickDraw will draw the object in the wrong place. With
the standard onscreen GrafPort (or an offscreen one of the same size),
this will not be a problem unless you try to draw past line 1023. With
a larger drawing area, as might be used by a high resolution printer
driver, for example, the line number limit is much lower.
 
For example, a driver printing at 300 dpi on paper 8 inches wide will
have 2400 pixels per line, requiring 600 bytes per line in 640 mode (2
bits per pixel). The bug in this routine will manifest itself if the
line number is 128 or higher (about a third of an inch down the page).
 
This routine is only used to calculate the start address of an object
-
subsequent lines will be drawn relative to the first address. This
means that a printer driver running at high resolution will not hit
this bug if the object starts at the top of the page (or very close to
it), until it tries to print the second band pass, which will start
further down the page.
 
This bug was noticed by Paul Bauer (pbauer@mit.edu) when trying to
print a vertical line in the AppleWorks GS Page Layout module, using
the Harmonie Hewlett-Packard LaserJet II driver at 300 dpi. The first
part of the line was correct, but it had a break in it a certain
distance down the page and was drawn at the wrong horizontal position.
The problem was not evident on other ROM 3 machines, or if a lower
resolution was used. Paul had the older ROMs in his ROM 3.
 
The revised ROM 3 does not have this bug: it uses the Integer Math
toolset _Multiply routine, which can handle up to 65535 rows and 65535
bytes per row.  The ROM 1 also uses _Multiply for this routine.
 
It looks like an attempt was made to do a much faster version of the
routine in the ROM 3 by doing the multiplication with a special case
routine, but it didn't allow for large enough images; Apple then went
back to the original code for the fixed version. There is also some
code in both ROM 3 versions to do a very quick calculation if the
pixel image width is 160 bytes and the line number is less than 400,
which will cover all onscreen drawing and a large proportion of
offscreen drawing as well.
 
The Bank $FF Changes
====================
 
The main group of changes appear to be part of the SmartPort code. 
The routine that was modified is checking for a SmartPort INIT call,
and also checking for the presence of a ROMdisk. I haven't looked 
into this one in detail, but I think the older version of the ROM 3
has a bug that prevents it from using a ROMdisk at all (or in certain
circumstances).
 
The other change is to the pair of bytes at $FFFFF6 and $FFFFF7. 
These are in the middle of the interrupt vector table for the 65816,
and are defined as "reserved" in the 65816 data sheet (they would 
be the emulation mode BRK vector, if it wasn't combined with IRQ at
$FFFFFE/F). The value in this location is meaningless and pretty
useless, so I suspect it contains a checksum of the ROM (or forces 
the checksum of the ROM to add up to some magic number when 
every byte or word is added, which is basically the same thing). The
value is $67E9 for a ROM 1, $A751 for an old ROM 3, and $6250 
for a new ROM 3. Part of the patch to the QuickDraw routine involved
replacing several consecutive bytes with zeros, which may account 
for the "lower" checksum in the new ROM.
 
 
What to do about it
===================
 
If you have been having strange problems on a ROM 3 IIgs with high
resolution printers not printing pictures correctly, or your ROMdisk
isn't working, then check the serial numbers printed on your ROMs.  If
they say 341-0728 and 341-0729, you have probably hit one of these
bugs.
 
Alltech Electronics are able to supply replacement ROMs for the ROM 3
(the correct ROM numbers are 341-0748 and 341-0737).  I believe they
charge US$29 for a replacement set of ROMs.
 
--------------end post clipping---------------------------------------

>> The Control Panel Screen shows Control Panel, Alternate Screen
>> Mode, Visit Monitor and Memory Peeker.
>
>For a very small number of ROM 3 machines, this location happens to
>contain a different value when powered on (probably FF), so these CDAs
>appear at startup.
>
>This behaviour is an artifact of dynamic RAM - it tends to power up with
>a particular pattern of values, and this will be reasonably consistent
>for the same memory chip.
>
>I know that Mitchell Spector's ROM 3 has this particular behavioural
>glitch.  I only recall ever hearing about one other machine which does
>it.

    I've since semi-retired the particular ROM 3 board and replaced it
with one where the bit location in the Slow RAM bank doesn't power
up in that unexpected state. So, I can now toggle the programmer 
CDA's to 'off' and they remain off.

    My board wasn't unique however. I did visit Apple Canada
in person to show them there was a defect with my board, when I
myself thought it was unique, but they convinced me otherwise 
after showing me at least two or three other ROM 3's that exhibited
the same behavior. I vaguely remember discussing the problem 
much later on with Apple and learning that a small number of these
boards were produced before the problem and caught and 
corrected.

    Another interesting thing about that board is it has gold colored
traces instead of dark green (my "fixed" ROM 3 board). It's worth
mentioning it would very often cold-boot in a dead state until I
firmly tapped the front tab on the case several times. After Tony
Diaz mentioned this was a particular trait of these gold trace
boards, I decided it swap it out. I've never seen the problem
since replacing the board.

>(There is another possibility: the beta firmware version might
>deliberately turn on these CDAs, but I don't recall noting that
>behaviour when I examined the differences.)

    He may want to check if the option is for "Enable Programmer
CDAs" is checked off in the 'SetStart' Control Panel (NDA). That
changes the bit that's checked in bRAM so they'd normally always 
show up even after powering down and back up again. Toggling
this option had no effect on my particular ROM 3 board.

    Speaking of the ROM 3, I noticed my replacement board either
automatically activates hardware shadowing of text page 2 or it's
always flagged to 'on' via the Alternate Display Mode CDA. I had 
a look an emulated IIgs in KEGS32 (both a ROM 01 and ROM 3) 
and it acts identically. I can't seem to disable it with the CDA so
I'm not entirely clear on why the CDA is needed on the ROM 3.

Mitchell Spector
a_specto@alcor.concordia.ca