🚀 go-pugleaf

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.