russotto@eng.umd.edu (Matthew T. Russotto) (06/14/91)
In article <1991Jun11.234006.12996@nntp.hut.fi> jmunkki@hila.hut.fi (Juri Munkki) writes: >>I have version 1.3, which works fine with System 6.0.7, but when switching >>monitor depths in System 7, the system seems to forget that it has a larger >>monitor. I expect this is because of unanticipated differences between >>6 and 7. I've got 1.31, and it does this sometimes, but not always, and not when using Switch-A-Roo. >It seems that MaxAppleZoom behavior varies a lot and the variations are quite >random. When I first upgraded to System 7.0, I used MaxAppleZoom 1.2. It worked >fine for a week and then it started complaining about the system version. I >upgraded to 1.3 and noticed that the narrow monochrome mode wouldn't switch >off. 1.2 appears to have a time bomb of some sort in it (though it never looks at the system time, and the behavior is more complicated than that of a time bomb. For instance, setting the clock back makes the cdev work, but on reboot, the INIT fails, and then the cdev fails until you set the clock back again). >After some work with ResEdit and a bunch of debuggers, I decided that >it would be quite hard to figure out what MaxAppleZoom really does. >Maybe I should have printed out the disassemblies, since I've always >had more success in understanding printed assembly language than that >displayed in a debugger window (easier to make notes that way). Most of the early code is paranoia code-- it checks the video driver six ways from sunday, including searching for various byte sequences. There also seems to be some timing-dependant stuff in there, because messing with the code often crashes it in one of the VBL tasks it installs. (and I haven't been able to figure out what those VBL tasks are supposed to do). The actual code which changes the screen isn't nearly as confusing. >Since I don't have a deep understanding of how MaxAppleZoom works, I >can't say anything definite. A good guess would be that MaxAppleZoom >is unable to read the configuration resource or it looses it somewhere >on the way. The bit about compressing the screen appears to be that MaxAppleZoom misses a few places where the 640*480 information is stored-- my guess is that it is the system 'scrn' resource, as the problem seems to fix itself after a few boots, but comes back if you move the video card. (of course, it could also be parameter ram... do you know where the information for the main screen is stored in parameter ram?) -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
rosen@cs.utexas.edu (Eric Carl Rosen) (06/14/91)
In article <1991Jun14.142904.28785@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: > >The bit about compressing the screen appears to be that MaxAppleZoom misses a >few places where the 640*480 information is stored-- my guess is that it is >the system 'scrn' resource, as the problem seems to fix itself after a few >boots, but comes back if you move the video card. > >(of course, it could also be parameter ram... do you know where the information >for the main screen is stored in parameter ram?) > > I tried changing the 'scrn' resource to account for the new 704x512 screen size. Although the change stuck, even after rebooting, it did not seem to make any difference to MAX's operation -- Macsbug still messes things up. I did not zap the pram after I'd modified the 'scrn' resource as I don't know how to do this under 7.0. --Eric