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.
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.
Anyone have a different part number ?
Willie Yeo (Kingfisher) | Apple IIGS ROM 3, 8Mb OctoRAM, RAMFast D SCSI,
| Pegasus 540i, ZipGSX 9/32, SuperDrive, Quickie,
Apple IIGS Disk Librarian | PC-Transporter, SuperSonic Stereo, StyleWriter.
Apple IIGS SIG Convenor |
| Bringing the Apple IIGS into the 21st Century
Apple-Q Inc. |
Brisbane Apple Users Group | ********** InterNet : y...@qut.edu.au **********
These specific ROM part numbers were never publically released.
341-0749 and 341-0728 had some slight bugs that were caught just before
(or days after) the ROM 3 went into production, yet again, _none_ should
have made it into the comsumer market. What your friend has is either a
ROM 3 prototype that slipped out of Apple, or a dealer-demo that had the
prototype ROMs installed. Where did your friend purchase this ROM 3?
> 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.
341-0737 and 341-0748 are the standard (newer) ROM part numbers in
the ROM 3. The only difference between the two ROM 3's is in the 256K of
firmware, but no one (expect in _extreme_ rare circumstances, such as your
friend's ROM 3) has the prototype ROMs.
> Anyone have a different part number ?
Nope, I've only heard of one other case where someone had the
prototype ROMs. David Empson has disassembled these unreleased ROMs and
listed the differences, I'm sure he'll follow up shortly with a review
of what they are. I recall the most serious bug was in QuickDraw II or
the print manager.
FYI there is a third type of ROM 3, though it has nothing to do with
the firmware. It has to do with the vaule found at E1:017D:xx in memory at
cold-boot. The vaule _should_ be '00' but on my ROM 3 (and a hundred or so
others) the vaule is 'FF'. This bug causes the programmer CDAs be invoked
whenever the machine is powered on, even the bRAM settings don't help here.
No one has quite figured out the source of the problem, but a guess is the
type of DRAMs used in the 'Standard RAM' (128K) bank, just next to DOC RAM.
Solutions? If you have the prototype ROMs (rare) swap them with a copy
of the current ROMs. Alltech might have the parts or perhaps you can burn
a copy if none are available. It's important that it be done...
CDA-bug: Install a small INIT in your System folder that temporarily purges
them from memory. At the same time it changes the address at E1 to '017D:00'
so the first warm-boot keeps them from returning (until you power down the GS).
The extra CDAs are really just a minor annoyance and eats only a couple of
bytes. This, like the other ROM 3, is rare. I found a batch of them at
Apple Headquarters in Montreal though, possible they only made it to this
part of Canada. You could do a motherboard swap too, if your luckly enough
to find one (the Apple dealer out here tossed a dozen or so in the dumster
a few weeks ago, wish I had been there. :-(
>Willie Yeo (Kingfisher) | Apple IIGS ROM 3, 8Mb OctoRAM, RAMFast D SCSI,
>Brisbane Apple Users Group | ********** InterNet : y...@qut.edu.au **********
Mitchell Spector
m_s...@vega.concordia.ca / spe...@vax2.concordia.ca
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 (dem...@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 (pba...@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
dem...@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand
As luck would have it, my ROM 3 is sitting here with the case off. UJ9
is covered by my Zip cable, but UJ11 has this #: 342-0728.
--
Wily
I think you mean -0749 and -0728. Assuming the numbers were allocated
in chronological order (which seems to be true in most cases), then
341-0728 (the rare version) is older than 341-0737 (the common
version). However, 341-0749 (the other half of the rare version,
which I thought was 341-0729) would be newer than 341-0748 (the other
half of the common version, and the one with the bugs fixed).
This is probably an exception: maybe two versions of the ROMs were
done, and the wrong ones (prototypes) got shipped in some machines
(particularly dealer demo machines) or the numbers were swapped at
some point.
Now, it is possible that 341-0749 is yet another version. My
comparison (see my earlier posting on this thread) was with a ROM that
I was told was labelled "341-0729". This could have been misread.
The only way to be sure would be for someone to send me a copy of the
contents of 341-0749, and I can do a comparison against the other
versions.
(If anyone wants to do this, please E-Mail me first. I can tell you
how to save a copy of the ROM to disk.)
I've got one of those "prototype" ROM 3's... :) I ordered it just before
the ROM 3 came out, and I guess the dealer didn't have any ROM 1's in
stock, and the first few they got were those prototypes.
I replaced the ROMs with ones from a friend's newer motherboard that
went bad... so there is a 28 pin chip in a 32 pin socket. Works just fine,
though.
Never ran into the described bugs, but back then I didn't have a inkjet...
-arekusu
PS Spector, I have the YS hd mods now if you still want them.
> Mitchell Spector (spe...@vax2.concordia.ca) wrote:
> I've got one of those "prototype" ROM 3's... :)
Me too, but I'm leaving it fully proto unless I absolutely have to change
it for some reason. :)
--
Eric Shepherd she...@cris.com
Chief Sysop she...@genie.com
GEnie PowerPC Programmers' and she...@aol.com
Developers' RoundTable she...@eworld.com
> Me too, but I'm leaving it fully proto unless I absolutely have to change
> it for some reason. :)
And I just got my Sequential RAM-GS 4 Mb card for it today, so with that
and my Zip 10/32 (was running 12.5 MHz, but it's a tad flaky -- I think 12
would work), I installed System 6.0.1 on it today. Runs like a champ. :)