Apple //e Hardware Technical Note #8 - Known Anomalies of the New //e ROMs Written: 6/84 Verified by: Cameron Birse 2/86 ------------------------------------------------------------ This technical notes describes three current problems, and some possible workarounds for them. ------------------------------------------------------------ The following three anomalies are known to occur when the new //e ROMs are present: 1) If the new //e ROMs are used with interrupts active when a combination of certain printer cards (Versacard, Uniprint, Graphitti, PSIO cards) along with the mousecard are present in the system, the system will hang when printing is attempted. This is possibly caused by a spurious interrupt occurring from the mousecard. The problem can be avoided by disabling interrupts while printing to a printer card. For more information on the general architecture of the //e and how the ROMs handle them see: "Interrupts on the Apple //e" by Ernie Beernink, 20-May-84. 2) There may be some problems when using the ROMs with communications packages. This is due to the way that the 80 column firmware switches into 40 column mode. By sending a control-Q through COUT the firmware to switches into 40 column mode. A simple solution to this would be to send an ESC-CTL-D sequence which disables the control functions. This will remain in effect until either the 80 column card is re-initialized by PR#3 or an ESC-CTL-E is sent through COUT. Another solution would be to simply not allow control-Q's to get through to COUT by filtering them before they get there. 3) Many developers using double high resolution (dbl-hi-res) graphics may wish to use 40 column text displays so that the text can be read on a television set. There are a couple of possibilities: A.) You can define your own dbl-hi-res character set with any size characters you desire and then plot them on the dbl-hi-res screen. B.) You can print text to the Apple //e text screen and toggle the screen on to display it. NOTE: There is no way to display 4 lines of 40 column text at the bottom of the dbl-hi-res screen in mixed mode since the 80 column hardware must be active while dbl-hi-res is being displayed. #To use the second method, however, does require some special considerations. The Apple //e scroll routines continues to use the window parameters when scrolling, but uses the 80COL softswitch to determine if it should scroll the 80 or 40 column screen. Since the firmware has initialized a 40-column window, the scroll routines will move only the first 40 columns. But, the 80COL flag has been turned on for dbl-hi-res! Therefore, the scrolling routine takes every even column from auxiliary memory and every odd column from main memory. As a result, only the first 40 columns get scrolled, 20 columns from auxiliary memory and 20 columns from main memory. One possible solution to the problem is to write your own scroll routines. Another might be to write to the screen so that scrolling will not occur. But there is yet another solution. Turn on the full 80 column mode with a "PR#3" or the equivalent. Now print your text to COUT in the normal manner being careful not to exceed 40 characters per line. The 80 column firmware will scroll everything properly. When you are ready to display text, send a CONTROL-Q through COUT to switch to 40 columns. When you are ready to return to dbl-hi-res mode, send a CONTROL-R to COUT. When switching modes, a momentary "glitch" may occur. If you send the CONTROL-Q to COUT while still in graphics mode the screen will go to regular "single" hi-res mode before finally going to text mode. If you switch to text mode first, the text will be in 80 column mode (with 40 columns displayed on the left half of the screen) before ultimately going to 40 column mode. The same potential glitch may occur going back to dbl-hi-res. The "glitch" will be only momentary and may not present any problem for your application.