From dempson@atlantis.actrix.gen.nz Tue Jul 11 20:14:21 CDT 1995 Article: 21757 of comp.sys.apple2 Newsgroups: comp.sys.apple2 Path: winternet.com!io.org!infoserv.illinois.net!news.cic.net!newsxfer.itd.umich.edu!europa.chnt.gtegsc.com!howland.reston.ans.net!news.starnet.net!wupost!waikato!comp.vuw.ac.nz!actrix.gen.nz!dempson From: dempson@atlantis.actrix.gen.nz (David Empson) Subject: Re: Different ROM 3 ROM chips ????? Message-ID: Sender: news@actrix.gen.nz (News Administrator) Organization: Actrix - Internet Services Date: Sat, 8 Jul 1995 13:47:16 GMT References: <3thrdh$3es@stork.qut.edu.au> X-Nntp-Posting-Host: atlantis.actrix.gen.nz Lines: 149 In article <3thrdh$3es@stork.qut.edu.au>, Willie Yeo 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