🚀 go-pugleaf

I have some questions I hope someone can reply to:

1. The short discussion in the 'Best of BIX' column in the latest BYTE
magazine tantilized(sp?) me into wanting to know more about the LINE-A bit
blit opcode ($A007).  The structure was given but no mention of the what
the fields represent.  I could guess at some but that could take months.
Could someone get me started by posting a commented view of the BITBLIT
structure in the article?
ie.     struct BitBlock {
			short	b_wd,b_ht;	/* Width and height of block in 'xunits' */
													pixels/words/bytes
													     Get the idea??
			short	plane_ct;	/* Video planes ??? */
			etc ...........

Any help would be fine.  I've worked with the Mindset PC, and the Amiga. so
bit-blitting (or blasting as I like to say) is not completely out of my
grasp.  I just need to know the 'units' for each structure field.

2.  What exactly ARE the KNOWN bugs in the ST's memory allocation system?
I find sometimes I have missing memory, other times everything is fine.  I
don't seem to be able to find a pattern.  One person says you can have no
more than 512 Malloc() calls, the GEMDOS manual says 20, and my  own
program seems to allow 120.  Could someone on the NET give a short run down
of what Malloc()'s real behavior is?  It seems to me any bugs in something
as vital as memory allocation is a real loser, and knowing the bugs could
save many a programmer many a late night fiasco.


3.  Does anyone know of a an ST disassembler in the PD?  Or one that is
'easily' ported?  Preferrably one that's output can be redirected to a
printer.


4.  Related to memory allocation.... Has anyone understood the Memory
Parameter Block concept in the ST?  Is this related to GEMDOS's free memory
list.  If so I'd try and write some working allocation routines (assuming
Malloc is broken, see question 2) maintaining the system memory list
myself, thereby not breaking the loader.  I looked a the MBP block in the
system's variable area but nothing seemed to be linked to the three
pointers in each.  Further, after an allocation, nothing changed.  Anyone
understand how and where the SYSTEM's idea of free/allocated memory is
kept?

The line-a question is the most pressing for me right now.  Email if you
think it's of limited interest.  However the memory and disassembler
questions would be of interest to many (I think).


    Thanks,



-- 
Jeff Gortatowsky       {allegra,seismo}!rochester!kodak!elmgate!jdg
Eastman Kodak Company  
<Kodak won't be responsible for the above comments, only those below>