Mark Meany,
							12 Hinkler Road,
							Thornhill,
							Southampton,
							Hant's

							April 92

 Hi All,

 I was looking back through some old source recently and came across a
loader I had played with that was written by Blaine. There was a problem
with the scroll text when the program was loading modules from disk.

 My solution at that time was to use CIA interrupts. Considering the same
problem again now, the juddering text was probably due to the method of
interrupt used.

 If you just replace the level 3 interrupt at address $6c with a vector of
your own, you must remember that your interrupt routine will be called
whenever a level 3 interrupt takes place. Level three interrupts are
generated every vertical blank, but also by the Copper and the Blitter.

 Disk routines use the Blitter to decode information, hence while accessing
a disk, level 3 interrupt will be generated. To distinguish what caused the
level 3 interrupt, you should check the INTREQR flags. If the vertical
blank bit is set, execute your interrupt code. If not ignore the interrupt.
This will stop your interrupt code from 'speeding' during disk access.

 A quick word about my subm9ission this month. The utility of particular
interest is called 'Displayer' and has been written to accompany a few
disks I am compiling. The compilation is an Assembly Language Manual similar
to the Amiga C Manual available from Andres Bjoreing, but I wanted to try a
different approach.

 Hence the development of a utility that can display a tutorial and one
example source. The ability is also there to run the example providing it
has been pre-assembled. At this stage the utility is still under development
but I included it anyway to see what you think of the idea.

 The manual is progressing at a slow pace, I have not had much free time
lately, and to date I have only completed the 68000 instruction set ( a 90K
text file with some 47 examples ) and about three quaters of the DOS file (
sneaking up to 60K, but much fewer examples ).

 All the examples are simple! One of the complaints I received from readers
of ACC was that some examples were too complicated. I am ensuring that all
examples are kept as brief as possible, demonstrating the point and not a
programming technique.

 By the second week of May, I expect to have DOS completed and would like
a few people to take a look at the manual for an honest opinion. Dave Shaw,
your number one on my list. This is a spin-off of that little adventure I
discussed with you about 15 months ago! If you are interested in reading
through what I've done and giving some constructive critisism, please send
an sae to me.

 I see that Commodore are cashing in on Bench 2.0 in a big way! There are
now Four programmers reference manual, all costing around £30. Ridiculous!
Also, there is this new A600. When will it end? Are we all supposed to rush
out and swap our machines every six months or what! Software houses must be
having nightmares right now, the main monster being called Compatability.
They start working to a spec that suits A500 1.2, A500 1.3 and A500 + only
to find another member of the family is about to show it's face.

 Can anyone supply me with the following:

 1/ A PD/Shareware text editor, v2.0 friendly, that will allow insertion
    of escape sequences into the text. I need this to add colour and style
    to the Manual tutorials. Nothing I've got fits the bill! The text must
    be saved as standard ASCII, not a specialised format or IFF.

 2/ The font editor that everone except me seems to have that saves out
    fonts as dc.b's ( Metallions is it? ).

 Both the above are required as medication to stop me going grey! You help
will keep my barber in buisness that little bit longer.

 I'm pleased to see that people are switching to using an address register
to point to a block of memory for use as a variable store and using
offsets into this to refer to variables. If an application looks as if it
is going to grow to some size, I do the same. In some circumstances, the
size of the program does not warrant the addittional programming involved
allocating the memory. A pitifull excuse I know, but when you don't have
much time to spend programming it can be most disheartening having to write
all the lines of source required to set up a block of memory for use as a
variable store.

 Why bother? Rather, why bother allocating memory. Unless you are writing a
subroutine that makes excessive demands on memory, you may as well reserve
a block of memory as a BSS hunk ( using the section directive ).

 BSS hunks do not waste disk space and save your program the job of calling
AllocMem(), which may say go away anyhow. Using a BSS hunk you save
yourself a little coding and can rest assured that if your program loads,
then there is memory for it's variables. You can still use Devpacs rs.
directive to define your variables without having to allocate memory.

 BSS hunks were devised for a reason, which I have just explained. There
are times that you should still use AllocMem() to obtain variable storage
memory, these are:

	1/ If your writing a subroutine that requires large blocks of
	   memory when called. Such a subroutine could waste a lot of
	   memory if it was only called once in a blue moon.
	2/ If your writing an application that can 'sleep'. Such an
	   application should release as much memory as possible when
	   sleeping and allocate it again on being awakened.
	3/ If you wan't your application to inform the user that there
	   is not enough memory available for it to run. 

 To give an example of the use of BSS hunks, see my source this month! One
program called 'Displayer' uses a BSS hunk for variable memory allocation.
The other, a hardware slideshow, for buffers. The slideshow, when assembled,
occupies less than 4K of disk space. To run, it needs some 500K! This was
done for a purpose, the program is being written for a friend. Infact it is
an umpteenth rewrite, neither of us have been happy with earlier versions
that had a lot more to offer! When a finished version surfaces, I'll
include it on the current ACC disk.

 While talking about source files, another point springs to mind. I receive
a lot of source that uses the 'incdir' directive to declare a directory that
the file being assembled is in. There is no need for this! Devpac will search
the directory that a source file is in for include files as well as any
directory declared using 'incbin'!

 A quick note about scrunch. This utility was passed onto me some time ago. I
do not have a use for it, but see it's potential. Make of it what you will,
maybe the writer has hit upon a novel idea, 'Beerware'! Writing to the author
of this program may not be a bad idea, files it crunches cannot be bettered
by powerpacker ( but you must write for the decrunch source! ).

 Marc Bateson, hi there! Yet another blitter question! Well a quick word of
warning, your code crashes if the bob is moved off the top of the screen! I
have corrected this in a modified example, but you should still remedy the
problem in the original code!

 Talking of crashing, thanks Axal. One of your programs this month crashes if
assembled with Devpac2! I have commented it so you can see what I'm talking
about. The problem is not evident if the opt o+ is removed, but some of you
will remember that there is not a bug in the optimisation routines of Devpac?

 Most of my first tutorials were bugged in the same way! I had to write many
a groveling letter to people trying to learn to program from my example, only
to find that my source crashed! Remove the optimisation and everything is
fine, but ask HiSoft and it's not Devpac! Make up your own mind on this one.
Just because Devpac3 can assemble it!!!!!!!

  Well, I must get back to waiting for summer. If it's here by next month,
I'll let you know!

						Mark.

 PS. On previous disks attention has been drawn to who contirutes how much.
    Consider the time spent contributing anything! If you can type at 4O 
    words a minute, then your a typist ( RSA gradable ). Let's assume the
    average length of a word is 8 characters, more than fair. That's about
    320 characters a minute or 19200 characters an hour! Remember these
    times are for a typist. Now think about a subject that you were having 
    problems with and all the time spent assembling and debugging code. Yep!
    typing speed amounts to very little.

     My thanks to everone, even Snowman and his sidekick, who have taken time
    out to write something for ACC. Before you ask, I don't bear a grudge,
    just my approach is different. A Lamer is non-exsistent, because oneday
    a lamer will become a Guru. Know what I mean?