Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!glacier!bridge2!pvf From: pvf@bridge2.UUCP (Paul V. Fries) Newsgroups: net.micro.atari16 Subject: Logbase/Physbase and Screen Dumps Message-ID: <157@bridge2.UUCP> Date: Tue, 8-Apr-86 20:23:53 EST Article-I.D.: bridge2.157 Posted: Tue Apr 8 20:23:53 1986 Date-Received: Thu, 17-Apr-86 04:49:35 EST Distribution: net Organization: Bridge Communications, Inc., Mountain View, Ca Lines: 31 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.