[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Different ROM 3 ROM chips ?????



In article <3thrdh$3es@stork.qut.edu.au>,
Willie Yeo <yeo@wattle.qut.edu.au> wrote:
> 	The other day, fixing my friend's ROM 3 motherboard with wierd
> problems (certain programs worked on one but not the other ROM 3 machine),
> I discovered that both of his ROM 3 machines have different ROMs !

That makes at least two ROM 3 machines that are confirmed to have
different ROMs from most of us.

> 	Looking at a closer look, and comparing with my ROM 3 machine
> back home, I found out that the ROM 3 machine in question, had a 32 pin
> ROM FF-FE (located on UJ9, next to the 65816), part 341-0749 and sitted
> next to it, is also a different ROM FC-FD, a 28 pin ROM, part 341-0728.

Are you sure about the "341-0749"?  From my previous investigations, I
was told that the number on this ROM was "341-0729", but that might
have been misread.  Perhaps this is yet another version?

> 	Both my friend's 'working ROM 3' and my machine had 341-0748
> for ROM FF-FE and 341-0737 for ROM FC-FD, both 28 pin ROMs.

These are the standard ones.

Here is an article I wrote a while ago about the differences between
the two known versions of the ROM 3.


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.
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand