Amiga Computing - Commodore Is Awesome

DMA, and found that every now and
then you get a stationary vertical bar
running down your screen. If you turn
off sprite DMA at the exact moment the
sprite is being displayed it will continue
to display the last line of sprite data
forever.
To disable sprite DMA properly you
have to use — yes, you guessed it — a
VPOS wait loop. Simply wait for the last
line, 305, before disabling the sprite
DMA and you can avoid hitting the
sprite, as it will never reach that low.
IF YOU are ever unfortunate enough to
listen in to a crowd of programmers
talking, they will sooner or later (usually
sooner) mention how few raster lines
their latest routine takes. Raster lines, in
this particular instance, are a measure
of time — it's the time taken for the video
beam to trace one line across the
screen. As it draws a whole screen of
over 300 lines every 50th of a second,
it's not a really large measure of time, in
fact it's only 63 microseconds.
It's quite simple to do — turn the
background colour to red. run your
routine, and turn the background colour
to black when it finishes. You will see a
red flash on the screen. and you count
the number of red lines. This gives you
the speed of your routine in raster lines.
You have to run this routine continuously,
once every frame, otherwise the
screen will just flash once — for 1/50 of a
second — and stop. You'll have to count
the lines pretty quickly to make use of
this ploy.
How do you do it? Yet another
application for this wonderful VPOS wait
routine. Here's the basic theory. I'll
leave the code for you this time (and
here's one I didn't prepare earlier...)
WAIT for line 150 (somewhere in the
middle of the screen, to make it easy to
see)
CHANGE BACKGROUND TO RED
BRANCH TO YOUR SUBROUTINE
CHANGE BACKGROUND TO BLACK
WAIT FOR LINE 140 (to make sure
one whole frame has appeared)
JUMP BACK TO BEGINING.
Why do I wait for line 140 before
jumping back to the beginning? If your
routine is very fast it may only take a
fraction of the line to finish. In this case.
it will jump back to wait for line 150, and
as it will still be line 150 it will go on to
execute a second time in one frame,
giving a misleading raster line time.
If you're feeling bored you can
experiment with different colours
instead of red. You've got 4095 to try
MOO would be a little pointless).
There are a few flaws with the raster
line timing method. You'll still find
programmers saying "My blitter stack
interrupt routine takes that' (holding
forefinger and thumb a very short
distance apart) 'much time", This is a bit
pointless, as you don't know whether he
is using a 9 inch monitor or a 26 inch
monitor.
Go up to them and say, "Yes, but how
many lines is that?". You can look very
smug and they'll be very embarrassed.
Ten to one they're using a TV and can't
count the individual lines without getting
a migrane.
THERE IS nothing more annoying than
a piece of code that just refuses to
work. It's a really good feeling when a
routine works first time, but with long
and complex ones that doesn't happen
very often.
A good 80 to 90 per cent of bugs can
be trapped with a decent debugger.
such as Monam 2 from HiSoft. but some
bugs are so cleverly hidden and so
perfect in design that you have to resort
to very special tactics to dig them out.
Here, for the first time. I reveal some
of these alternative debugging practices:
Print out your source code: You will
often find the problem is obvious by the
time it is completed. This doesn't have
anything to do with what's printed on the
paper. it's just that the time taken to
print out the source gives you time to
think.
You really need a cheap old noisy dot
matrix printer for this, laser printers work
too quickly, and they don't make the
right noise.
Some people have successfully
debugged by removing the ribbon and
printer paper on their machine, printing
nothing. The time delay and the noise
are still right, but you don't waste
valuable printer paper and ink.
Invite a friend round: Every coder
knows some annoying little person who
comes round, stands behind you
looking over your shoulder, who knows
almost nothing about programming but
comes out with statements like
"Shouldn't that be a DO, not an AO?'
every now and then while your typing.
What's even more annoying is that
they are more often than not right. A
useful debugging technique, but it has a
high embarrassment factor.
The kludge: This is the dirtiest of
debugging techniques. Frowned upon
by almost every decent programmer —
but a lot resort to it in a dire emergency
— it involves logic which goes something
like this:
This code is theoretically perfect so it
should work. It doesn't. If I insert
something that is theoretically unnecessary,
or even theoretically wrong, it may,
with a bit of luck, fix the problem.
Good examples of kludges are
Jolyon Ralph
cures the coding
blues with his
previously top
secret bumper
bug-busting
hints
randomly clearing registers at the
beginning of a routine, or changing the
length of a DBRA loop by +1 or -1 "just
to see what it would do". The whole
kludge ethic is based on the philosophy
that 'As long as the program works.
I don't have to understand why it
works".
Naturally, this is rather repulsive to
most programmers, except when faced
with a tight deadline involving sums of
money. A very few programmers code
purely by the kludge method, leading to
unbeheveably badly-written code. I've
seen some of their games.
The US foreign policy. debugging
method: This was something I developed
when programming the Spectrum
in Z80. I noticed that it was taking 20
per cent of my time to write a routine.
and 80 per cent to debug it. I also
noticed that about 40 per cent of my
routines worked first time (If only it was
that way now!).
So I worked out that debugging was
a waste of time. All I had to do was
write a routine, if it worked, great. If it
didn't, nuke it and start again.
If I could narrow down the error to a
certain line, it was a simple matter of
deleting the line, and the three lines
above and below it, and rewriting it.
This technique definitely works, but
the only problem is it makes your
fingers ache.
Next month: More of the same, with
loads of interesting facts about
interrupts and copperliste Don't
you just love it? Answers on a
postcard please.
AMIGA COMPL 'MG November 1 990 1
25