The A68K Front End Project.

 As you may have realised I was a little disapointed with the response to
this project. Still this has not hindered things to much. Since the last
disc the program has undergone a major re-write, two infact.

 Steve Marshall added code that allows a Workbench startup. This entails
making A68K and Blink resident and using the ARP AsyncRun subroutine. There
is a slight flaw in this as A68K does not like being made resident. After
A68K has been run once, the program produces a checksum error which brings
forth a requester on all subsequent calls. This is annoying, but does not
stop the program from running.

 Steve has also added code to use RawKeyConvert for translating RAWKEY
messages into useable data. I have not taken full advantage of this yet as
the buffer returned is not checked to see if multiple entries exsist in it
( ie if the user is using a customised keymap ).

 Also, as the source listing is now some 80K long, it has been split up
into a number of sections. These are all INCLUDed at the end of the main
routine. This makes editing much easier and does not waste so much memory.

 As suggested by Steve, I have done away with the large data section. The
program now allocates a block of memory for the variables and uses the
Devpac rs command to calculate the offsets into this memory block for each
variable. This reduced the overall size of the assembled program by some 4K
and also speeded things up to.

 Next I done away with the fixed size text buffer. The text file is now
read into a linked list, each line being a unique entry in the list. The
list is maintained by a suite of subroutines I have written. These can be
seen in the list.s file.

 Memory for each line of text is allocated as required, this saves having a
huge buffer for only a small file. Of course all the screen display
subroutines, printing subroutines, load, save and assemble subroutines all
had to be modified. I must admit that I have introduced a few bugs while
doing this and will set about tracing them shortly. The most noteable of
these are:

 After selecting Load from the Project menu, click on the DRIVES gadget in
the requester, then the OK gadget. The system hangs up and you will need to
reset.

 If you do load a file, go to the bottom of the text and hit return. An
interesting, but as far as I am aware, non fatal bug.

 The last addittion I have made is the very basic editing routines. The
cursor can be moved about the text using the arrow keys. Alphanumeric input
is allowed and backspace and delete both work as you would expect. This is
just the start, do not expect miracles at this point. However, you can now
type in a program, assemble and run it from within the front end. 

 Neither Steve or myself have documented all our alterations. This will be
done later, along with an explanation of how each section works. One reason
( excuse ) for this is the format may change yet again and that would mean
a great deal of wasted time.

 The list routines I have written can be put to a number of uses, for
example the word pattern matching programs elsewhere on this disc. At
present they are not completely stand alone, but I am working on this. Then
your own programs could use the lists. The list.s file is commented and you
should be able to see what each routine does. The start and end of the list
are set up in the Initialise subroutine in the main program.

 How can you help ? As the program develops, you could test it for us.
Reporting any bugs or annoyances and also suggesting any improvements. If
you are willing to do this then write to either myself or Steve. Our
addresses can be found elsewhere on this disk. Also needed is source that
can be assembled by A68K. There is little difference between Devpac source
and A68K source, so give that a try. The names of all involved will appear
in the credits on the final PD release.

 If you have looked at the source and seen areas that you could
enhance/modify, then write to Steve or myself as soon as possible.

 Using ACC
 =========
 
 This month you will have to assemble ACC for yourselves. First decrunch
the source as detailed elsewhere on this disc. Read the ConvertFD doc,
assemble and run ConvertFD, this will generate the include files you need.
You cannot use Devpacs include files with a68k, so don`t bother trying.
Next assemble ACC. You can load examples given on last months disc or type
in a program of your own. If you type in your own program do not forget that
A68K requires all listings to be terminated with an end statement.

 Beware the bugs ! and please report them to me. There are bound to be some
I do not know of.

 Again thanks for you interest and anticipated participation in this
project,


		Mark. Jan 1991


 Here are Steve`s notes on ACC taken from a text file he sent:
 

 Running A68k from the WBench. I originally  used execute but later changed
to ASyncRun. Execute works OK if you  set  the output handle to the console
and the input to a NULL: file  handle.  Use DOS (or ARP) Open as usual with
the name set to 'NULL:'. Using ASyncRun  is a little more involved but as I
wanted to have the  code  already  loaded  this  was  the best method. Note
because ASyncRun returns immediately it  is necessary to set up a replyport
so we can wait for a zombie message  telling  us  that A68k has terminated.
Without this Blink would always fail, being  unable to find the object file
as A68k would still be assembling.  Current  problem  is that A68k will not
run more than once if held in  memory.  At  present you will be informed of
the checksum error and then the  original  copy of A68k will be loaded from
disk. Assembling with Acc the  first  time  will  give you an idea of how I
want the program to run. I have ideas on  how to correct this and hopefully
this will be fixed for the next  version.  I added ASyncRun to the menu run
command. This allows you to  run  multiple  copies  of the program and even
terminate Acc whilst leaving them running.  Compile the Rays_sprite example
then select run from the  menu  a  few  times  to  see this work. One up on
Devpac here.
 Raw Keycodes to ascii. I have added  a  subroutine to acc which does this.
Note  you  may  well  get  more  than  one  character  returned  with  this
subroutine. This is because the subroutine takes into account the fact that
the user may have created his  own  keymap  with  Setkey or KeymapEd. These
programs allow the user to set  up  to  128  chars for one keypress. I have
allowed for 40 chars which should be enough  for most uses. In the event of
a buffer overflow d0 will return with -1, otherwise it will return with the
number of chars. The subroutine is already patched in and works OK allowing
scrolling through the file etc.
 Mutual excluding of gadgets. Hope that  you haven't been trying to use the
gg_MutualExclude field of the gadget structure.  As you will know by now it
doesn't work (it may in OS 2.0 I  don't  know - I'm not a millionaire). The
excepted method is to keep track  of  the  gadgets  state  and change their
SELECTED flags to whatever you wish the  gadgets to be. To do this you must
first remove the gadgets from the  windows  gadgetlist. After you have done
this you twiddle  the  SELECTED  flags  then  add  the  gadgets back to the
windows gadget list. You must then refresh  these gadgets so that intuition
will display them correctly. Final  note  on  gadget types, the gadget must
have   an   image   and   the   activation   flags   should   be   set   to
GADGIMMEDIATE+GADGHCOMP (or  GADGHIMAGE)+GADGIMAGE  ,with the SELECTED flag
only set for one of the gadgets. There is an example on this disk.
  One last  point to make, the Acc  source file  is getting a bit large and
cumbersome. Because of this I have split it into a number of smaller pieces
and  included them  into the main file  (see  ACC_Source Dir). If you don't
like this approach the full source is in the Acc dir. I use this method for
most large projects, it's a matter of taste really.

Thoughts and Comments on Acc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 First problem is a lack of communication.  I found that I had to rip out a
large chunk of code from the version of acc that I was working on. The main
reason for  this  was  duplication  of  routines,  I  had  written  similar
subroutines to you. The other reason  was  the incompatibility of your code
with some of mine. The editor I was  working  on used the console device to
read the keyboard, menu, mouse etc., this may still be the better option. I
was also looking into  differing  ways  of  storing the file in memory. The
method of storing the file as a single  large block is OK but requires that
you set up a fixed file buffer ( the  size  of which is set in the programs
preferences) thus wasting memory if you  are only editing a small file. The
other problem is that when you edit the beginning off a large file you have
to move all the rest of the text  a  byte  further  in the buffer for every
character added slowing editing down. Of  course you can use the blitter to
move this text to speed thing up a  bit,  and  you can reduce the number of
shifts needed by using a separate edit  buffer. By doing this you only have
to move the rest of the  text  when  the  user  moves  to  another line (by
clicking the mouse on another  line  or  pressing  return) or when the user
selects Save or Assemble.
 I did think of holding the text in a  sort  of linked list. This does away
with the need to set up a single  buffer  thus only using as much memory as
needed. The main problems with this  method  is more work is required to do
loading, saving and searches. On the  plus  side  things like adding a line
into the middle of a file is easy -  just  change a couple of pointers. The
lack of the RS directive can be  cured  by  writing a macro for it. Another
way around the copyright on include files is to create a linker library for
acc or use a PD version of amiga.lib (on  Fish disk 92). Acc should use the
clipboard device for block commands so  that the user can import clips from
other text editors  or  second  versions  of  acc  running.  This is a main
failing of Devpac.
 I think we should allow the user  to  use  linker  libraries and also link
with other files. Devpac doesn't allow  this (from within the editor) so we
could improve on Devpac yet  again.  There  is  a PowerWindows file on this
disk which offers  a  rough  suggestion  as  to  the layout of the Assemble
window. You may wish to change or scrap this - it's just a suggestion.
 We will have to find some way of  simulating  the INCDIR directive. I have
some ideas on this. Possibly  the  crudest  way  is to make a subroutine to
created linkable file from the file  whose  name  is passed to it then make
BLink link this file with the  main  file.  This  is  quite easy but crude.
Another way would be to create  a  preparser  routine  to scan the file for
INCBIN then read the filename. We could then find the size of the file then
change INCBIN to :

ds.b <filesize>

 We would then compile as usual, then  copy  the binary file into the block
created with the ds.b. This  is  slightly  better  but  messy. I have a few
other more subtle ideas but have not quite  worked them out yet. You used a
larger space between the lines of  text  than  normal. I prefer to see more
text on screen so I changed this. However there must be others who like you
prefer the extra space between  lines.  For this reason I have made it easy
to change the spacing - even whilst  the  program  is running. We could add
this option to the preferences requester.  We could at a later date write a
dedicated assembler, debugger and linker for Acc. I wrote a linker of sorts
a while ago for a project I was doing.
  How about adding the code  for  the  68k  helper  or  allowing this to be
called from within acc. Also another helper program could be written giving 
details of all the library routines.
  Finally how about redirecting the errors from A68k and BLink to a file in
RAM: then copying this into memory, then copying this to the console. Doing
this would  give us a copy of  the errors in memory  which could be used to
implement a jump to error routine.