pvf@bridge2.UUCP (Paul V. Fries) (04/09/86)
I think I have found a slight bug in the handling of the screen dump to printer capability. The situation is this; I have written a program that does some extensive graphics work on the screen in an iterative fashion. In order to prevent the user from seeing the mechanics of the update on the screen, I have used careful manipulation of physbase and logbase so that the system is never displaying the screen that is being updated. That is, I keep two copies of the screen memory. While the update is taking place, physbase points to the saved copy while logbase points to the screen in which the updated data is being computed. When the update cycle is complete, I swap the pointers, copy the updated data to the save screen, swap the pointers back again and begin the next update. The result is a screen that changes instantaneously as far as the user is concerned. All of this work 100% as expected and I get a crisp, virtually instant change from one cycle to the next. The problem came when I tried a screen dump to my printer. The output contained a picture that was partially updated. I assume that this means that TOS did the screen dump from the area whose address was found in the logbase pointer. I believe that the screen dump routine should be using the physbase pointer, as all I have read implies that the screen dump capability should give you a printout of what is visible on the actual screen. Have I found a bug? Is there any way to fix it? PS The machine is a vanilla 520 ST with TOS in EPROM.
Felton.pa@XEROX.COM (04/21/86)
>I believe that the screen dump routine should be using the >physbase pointer, as all I have read implies that the screen >dump capability should give you a printout of what is visible >on the actual screen >Have I found a bug? Is there any way to fix it? No. You haven't found a bug. If you think about the reasoning behind having two locations "logbase" and "physbase" you will see that it is working properly. The ideas is to allow the programmer to perform page flipping while using the system routines for writing to the screen. In order for this to work you must display one screen but have the system routines use another. Thus, there are two pointer, one points to the memory which is to be displayed on the screen (physbase) the other to the memory which is to be used by the system routines (logbase). If you want the system routines to work on the currently displayed memeory then you must set "logbase" to "physbase". If you started having system routine use physbase then you would loose flexability (Printing one screen while viewing another for example). To solve your problem simply set "logbase" to "physbase" before calling the screen dump routine and restore it after you return. John
Felton.pa@XEROX.COM (04/21/86)
This is an addition to the message I sent about "Logbase" and "Physbase". I realize now that the incorrect screen dump may have been a result of using the GEM desk top screen dump function and not a call from the current application. If this were the case then it does indicate a bug. This bug is not in TOS however. The GEM desktop is itself an application and should set "Logbase" to "Physbase" before performing the screen dump. "Logbase" should then be restored to its original value after the dump. You can avoid this problem by making sure that your application sets "Logbase" to "Physbase" when it is done updating the screen. John
pvf@bridge2.UUCP (04/23/86)
> > > >I believe that the screen dump routine should be using the > >physbase pointer, as all I have read implies that the screen > >dump capability should give you a printout of what is visible > >on the actual screen > > >Have I found a bug? Is there any way to fix it? > > No. You haven't found a bug. If you think about the reasoning behind > having two locations "logbase" and "physbase" you will see that it is > working properly. The ideas is to allow the programmer to perform page > flipping while using the system routines for writing to the screen. In > order for this to work you must display one screen but have the system > routines use another. Thus, there are two pointer, one points to the > memory which is to be displayed on the screen (physbase) the other to > the memory which is to be used by the system routines (logbase). If you > want the system routines to work on the currently displayed memeory then > you must set "logbase" to "physbase". If you started having system > routine use physbase then you would loose flexability (Printing one > screen while viewing another for example). To solve your problem simply > set "logbase" to "physbase" before calling the screen dump routine and > restore it after you return. > > > John You COMPLETELY missed the point of the question. I KNOW how logbase and physbase work. My program uses them and the result is that I get nice crisp screen transitions despite the fact that the program needs several seconds to prepare the next image. OK, now back to the question. Let me clarify, I did not issue a system call to print the screen. The manual says that I can hit ALT/HELP (or whatever the key combo is as per the documentation) to get hardcopy OF THE SCREEN. I hit ALT/HELP and DID NOT GET HARD COPY OF THE SCREEN. I got hard copy of the image that was partially built. Had I issued the call, you can be sure that I would have had the pointers pointing at what I wanted them to point at. I AM suggesting that the ALT/HELP routine use physbase instead of logbase. I suppose this implies that the screen dump system should take a parameter indicating the area of memory to be printed, while the parameter passed in the case of the ALT/HELP key be physbase. he use of a the keyboard to get screen dumps is to take care of the case where the program does not have the capability or desire to provide the function itself. Instead, it printed the confusing half-built image that the program was preparing. I am trying to point out to ATARI that the capability could be made to operate in a more useful fashion. Perhaps someone from ATARI would care to comment.