Club Amiga de Montreal - CAM/CAM_CD_1.iso/files/198.lha/Flip/flip.readme

Text File | 1988-12-27 | 6.5 KB | 106 lines

Let's see now, where do I begin:

First of all, I designed this program to conceal itself after it starts
running so as soon as you set the two time variables to your liking and
then hit the Start gadget, the control window is whisked away.  It should
now be, and on my Amiga is, located directly on top of the Workbench
Screen front/back gadgets.  In fact, the shrunk Flip control window matches
the size of these gadgets exactly, and it is quite impossible to access
the Workbench gadgets using the mouse.  Unfortunately, when it is in the con-
cealed position there is not much you can do with it execpt resize it in the
up/down direction.  There is a way out of this dilemma.  Just make sure that
the flip window is active (click on what appear to be the Workbench
front/back gadgets) and access the flip menu using the right mouse button.
You'll see an item labeled Enlarge Window.  Selecting this item will
expand the window to it's original size.  From there you can start or stop
the timing process, play with the time variables, or quit the program if
you wish.  I decided to set it up this way in order to make it possible
for the program to run in the background in a concealed fashion.
You can therefore start it running and if you sit a friend of yours in
front of your Amiga and let him or her start to play, every so often the
screen will flip, and it will be very difficult for this person to figure
out what in the heck is going on.  It shouldn't eat much CPU time while
this is going on since the timer is the only thing that is functioning.

Warnings:  There are a large number of potential problems when an ignorant
programmer like myself tries messing around where he probably shouldn't
be messing around.  I warn you, this program has not been extensively
tested for bugs and is therefore likely to cause system crashes when
operating in non-standard environments.  I've checked it out with a cli
window opened on the Workbench Screen and it seems to work fine there.
I've tested it with a large # of other programs and it seems to flip almost
any screen without crashing the system.  HAM screens are obviously not
very fun to look at in this manner but there wasn't much I could do about
that.  Even terminal programs seem to flip ok.  I was online the other
day with Access and flip was running in the background, and the Access
screen was flipping every five minutes or so with no problems.
If it causes you problems, throw it in the trashcan and don't
complain to me.  Oh well, you can, but there won't be much I'll be
willing to do to help.

Observations:  My only previous experience in programming was a short
class in C offered by our User Group.  I don't know what possessed me
to jump into assembly language but I guess that's not too important.
From my viewpoint, it seems that assembly language is a heck of a lot
easier in many ways than C.  I say this cautiously since I realize that
my perspective is that of a novice.  Given that, I will say that the old
"Is it a pointer or isn't it?" question is quite maddening to the new
student in C.  This is much less of a problem in assembler.  Pointers
and addresses are much easier to keep distinct.  I suppose where I ran
into the most trouble with assembly was in the debugging.  A C compiler
will filter out a lot of programmer stupidity mistakes that will slip
right through the assembler.  Unfortunately, the way you find out about
these is through a message from you friendly neighborhood wise man.  Not
a pleasant way to get the message.  The Metascope debugger proved invaluable
in this respect and for those of you just starting to learn assembly
language I heartily recommend it.  I also recommend Structure Browser.  You
can use this gem to snake through a considerable number of structures and
find out the values of the members.  Very helpful in picturing how the
internal variables are arranged.

I've included the source code in case anyone wants to add, subtract, or
butcher this.  It comes in two pieces, flip.asm and ud.asm.  Flip is the
main portion of the program and contains the code for the parent process
and the child task which does the timing.  Ud is the subroutine that
actually flips the screen.  I would have split it up into smaller pieces
but every time I tried that I ended up with graphical data being sent to
the twilight zone of fast mem, and an invisible gadget.  Fixhunk didn't
seem to help, and I have no idea where to get hold of ATOM which I gather
is the proper way to deal with this, at least according to the RKM's.

And, by the way, I seem to remember someone else writing a program that
flips the screen just like this one.  I've searched my collection of
screen hacks and can't find it.  If this is true, now there are two of
them out there and perhaps more.  I'm sure we've got a ways to go before
we match to terminal program count, not to mention the Directory Utility
count.

I created one nasty little bug while I was writing this thing and I'll
mention it here in the hope of preventing others from running into it.
Quite stupid actually, but it had me scratching my head for a while.
What I was trying to do was remove the system sizing gadget from the console
windows that the program opens to display the text.  It was necessary to
do this since the console display is lost if the user shrinks the window.
So I figured I'd get smart and remove the sizing gadget.  I remember reading
somewhere that this was not allowed, but I'm brave, I went ahead and tried.
Seemed to work out just fine.  I'd do a RemoveGadget followed by a
RefreshWindowFrame and all seemed well.  Gomf didn't like this too much,
smart program that it is, but it let me recover just fine.  Then I realized
that every time I'd open a con window I'd lose #fh_SIZEOF bytes of memory.
Then it all clicked and I realized what a stupid thing I'd done and went
ahead and just turned off the sizing gadget.  Now I'm happy and so is
AmigaDos.  What was particularly nasty about this was that it really didn't
cause a Guru, so it slipped by me for quite a while.  I guess AmigaDos is
smart enough to deal with this in a semi-intelligent manner but I'll bet
it ends up being a trap for a Guru later on down the line.  I guess the
message is DON'T MESS WITH THE SYSTEM STRUCTURES.  Perhaps you can but
you'd better be prepared to repair the damage that you will invariably cause.

If you find any other bugs please let me know.
If you like the program, let me know.  You might end up convincing me
to write something useful.
                Charles J. Besecker
                CIS 75226,1266
                People Link - ops433
                CA-AUG BBS 216-581-2284