emmayche@dhw68k.cts.com (Mark Hartman) (06/08/91)
Has anyone seen a copy of MaxAppleZoom that works properly with System 7?
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.
Any news would be welcome - e-mail and I'll summarize to the net.
--
Mark Hartman, N6BMO "What are you just standing there for? Where
Applelink: N1083 or BINARY.TREE do you think you are, DIS-ney World??"
Internet: emmayche@dhw68k.cts.com -- General Knowledge, from
uucp: ...{spsd,zardoz,felix}!dhw68k!emmayche CRANIUM COMMANDjmunkki@hila.hut.fi (Juri Munkki) (06/12/91)
In article <1991Jun8.025731.7019@dhw68k.cts.com> emmayche@dhw68k.cts.com (Mark Hartman) writes: >Has anyone seen a copy of MaxAppleZoom that works properly with System 7? > >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. 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. 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). I then noticed that if I had the monitor initially set to 256 colors, I could use MaxAppleZoom even in B&W mode and the screen size was not reduced. I quickly wrote an INIT to change the screen depth from 256 to 2 colors and everything was fine... Yesterday my hard disk became unreadable when a program I was writing and TMON Pro decided to rewrite the volume information block. I recovered 99.9% of the files (I think I lost 3 files or something like that) and rebooted from the newly formatted hard disk. Guess what? MaxAppleZoom now always compresses the 2-color screens no matter what the initial screen depth is. ----- Techno-mumbo-jumbo follows: 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. I haven't paid the shareware fee, but I refuse to pay it for something that doesn't work reliably and doesn't come with source code. If it came with source code, I'd be willing to pay $25 for it. If it worked as reliably as Compact Pro has, I'd be willing to pay for it (I have paid the shareware fee for Compact Pro). MaxAppleZoom is a weird piece of code...most of the functionality is incorporated in an INIT resource called "showinit". The original showinit code is only about 10% of that resource. Most of the code is dedicated to making sure that the system is acceptable for MaxAppleZoom. Personally I would rely more on the users ability to see if the INIT works and worry less about compatibility. (That way I could still be using version 1.2, although a quick look at 1.2 revealed that 1.3 is a major improvement in code quality). If we had source code, we could easily hunt out all the problems and fix them. Without source code, it's like trying to read a bowl of spaghetti. (I think MaxAppleZoom was written is assembly, since it doesn't look like the output of any compiler that I have ever seen. Neither would any compiler use supervisor-only instructions and there was at least one in v 1.2) Forgive me for the technical nature of this article... ____________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / Project / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / STORM / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
jmunkki@hila.hut.fi (Juri Munkki) (06/12/91)
This is a followup to my own article that I wrote last night. After a good night sleep, I booted my Macintosh and was amazed to find that MaxAppleZoom worked again correctly. The only difference with the system is that I didn't switch on the other hard disk that I had used with SUM for storing the recovered files. MaxAppleZoom really behaves quite randomly with System 7.0, so if you're interested in a stable system, avoid MaxAppleZoom. I haven't had any crashes, but with behavior like this, who knows what it's really doing. ____________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / Project / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / STORM / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
russotto@eng.umd.edu (Matthew T. Russotto) (06/15/91)
In article <1548@nada.cs.utexas.edu> rosen@cs.utexas.edu (Eric Carl Rosen) writes: > >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. Macsbug? Do you mean that macsbug's screen stuck to 640*480? That is normal. Or do you mean that breaking into Macsbug and continuing makes the normal screen revert to 640*480? That is a problem I have not had. -- 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/15/91)
In article <1991Jun14.175042.1467@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >Macsbug? Do you mean that macsbug's screen stuck to 640*480? That is normal. >Or do you mean that breaking into Macsbug and continuing makes the normal >screen revert to 640*480? That is a problem I have not had. After returning from Macsbug, the right and bottom borders (the pixels between 640 and 712 horizontal, and between 480 x 512 vertical) do not update. If I, for example, have a Finder window that stretches into the bonus region provided by MAZ, and I close and open this window, no drawing takes place in the region outside the standard 640x480. The only fix I know of is to toggle screen depths.I have always had this "feature" under all versions of MAZ I've tried (1.2 and 1.3). Initially, after returnning from Macsbug, the bonus region is black until I change depths. I always assumed this was "normal". Does it sound familiar? I was hoping to fix the problem outside of Macsbug by modifying the scrn resource. I realize that Macsbug's screen will only be 640x480. Perhaps we are fighting a losing cause. There may be sublte differences in various versions of the Toby frame buffer that result in unique bugs and failure modes. --Eric