jdg@elmgate.UUCP (Jeff Gortatowsky) (09/02/86)
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>bammi@case.CSNET ("Jwahar R. Bammi") (09/04/86)
The parameter block for bitblt (a007) is described in detail in the document titled 'The much awaited Line A document' that comes with the developers sytem. Its too long to retype here.
jdg@elmgate.UUCP (Jeff Gortatowsky) (09/05/86)
In article <8609050623.AA09089@ucbvax.Berkeley.EDU>, bammi@case.CSNET ("Jwahar R. Bammi") writes: > The parameter block for bitblt (a007) is described in detail in the document > titled 'The much awaited Line A document' that comes with the developers > sytem. Its too long to retype here. No,no,no,... I meant I'd just like to see the same structure definition that was published in the 68K issue of BYTE, only with the fields of the structure commented as to what units they represent (BYTES,PIXELS,X/Y pairs, words, etc). That is assuming of course it is the correct structure definition in the first place. For example the structure starts with: struct blahblah { short b_wd,b_ht; ..... .... lots more stuff... Now I looked at that and said AH HAH! block width and block height. Hmmm ....in pixels? Must be. Well maybe not. Hmmm. The offsets (word,line,plane) really are the ones I can't deduce from looking at the structure. Offset by what? Word offset? 16 bits right? Or 1 for one word. Plane offset? I thought the plane offsets were 0,1,2,3 words depending on color choice (or something like that). I'll muddle along figuring the rest out. Just get me started with a commented structure definition. Please? As for the Line A doc you mentioned, my developer buddy told me on the phone that it says 'see the end of this document for a description of BITBLT'. Only there is no description to be found! I asked him if the 300 bucks was well spent? He hung up...... 8^) -- Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg Eastman Kodak Company <Kodak won't be responsible for the above comments, only those below>
wip014@uklirb.UUCP (09/06/86)
/***** uklirb:net.micro.at16 / elmgate!jdg / 4:22 pm Sep 2, 1986*/
Subject: Questions on BITBLIT, Malloc (not malloc), and 68 Disassemblers
I have some questions I hope someone can reply to:
.
.
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.
.
.
Thanks,
--
Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg
Eastman Kodak Company
<Kodak won't be responsible for the above comments, only those below>
/* ---------- */
Some time ago the West German computer magazine "Happy Computer" released
a special 68000-issue. There was a PD-Disk available, that featured most
of the Atari-ST-programs as executables and some of them even as source.
Among these programs was a PD-ML-monitor (somewhat bigger than 8KByte)
with some excellent features:
- display/edit memory in hex/ascii
- load/save files from/to disk (Sorry, no loading for execution like SID)
- tiny disk monitor
- disassembler
- single stepping/tracing of instructions
- output redirection to parallel or serial port
- advanced find capabilities (hex bytes, strings, wildcards, 68000 instructions)
[to find all MOVE.Ws yoy say: f "move.w" start-address end-address]
I'm willing to post the executable, if there's enough interest on the net. But
there's one problem with the documentation: it's in German. Although this is
my mother tongue, it may be not your's. I might be convinced to attempt a
translation, if I get tremendous feedback. But that might take a while to get
accomplished. I'll even consider sending the assembler sources (BIG: ~>50Kbyte),
if the responses are overwhelming.
Michael Doerr
University of Kaiserslautern (Germany)
uucp: ...!seismo!unido!uklirb!wip014bammi@cwruecmp.UUCP (Jwahar R. Bammi) (09/07/86)
In article <521@elmgate.UUCP> jdg@elmgate.UUCP (Jeff Gortatowsky) writes: > >As for the Line A doc you mentioned, my developer buddy told me on the >phone that it says 'see the end of this document for a description of >BITBLT'. Only there is no description to be found! I asked him if the 300 >bucks was well spent? He hung up...... >Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg >Eastman Kodak Company ><Kodak won't be responsible for the above comments, only those below> Well i admit it takes some digging around, but all the info is certainly present. The 300 bucks are more than well spent. The bit block info is on pages 775-789. Ok here are the details: B_WD width of blocks in pixels D_HT height " " PLANE_CT # of consecutive planes to blit FG_COL & BG_COL fg and bg color OP TAB (4 bytes) { logic op to employ when FG=0 and BG = 1 FG=0 BG = 1 FG=1 BG = 0 FG=1 BG = 1 } (one of 16 logic ops) S_XMIN , S_YMIN minimum X & Y source (in pixels) S_FORM source form base address (must fall on word address) D_FORM destin " " " " " S_NXWD and D_NXWD offset to next word in plane of memory form. Mono = 2. Med = 4, low=8 S_NXLN and D_NXLN form width for source and dest. These widthare even, they represent the offset from one row of the form to the next. Hi rez (mono) = 80, low and med rez = 160 S_NXPL and D_NXPL offset from start of one plane to the start of next. Always = 2 The pattern parameters (P_ADDR P_NXLN P_NXPL) are similarly defined. Also there is that 26 byte buffer at the end that is used and does not need to be initialized before the call. Also see the description of MFDB in anything that describes Vdi and the above will be quite clear. I can recommend "Gem Programming" by Balma and Titler highly. Hope that helps, -- Jwahar R. Bammi Usenet: .....!decvax!cwruecmp!bammi CSnet: bammi@case Arpa: bammi%case@csnet-relay CompuServe: 71515,155
franco@iuvax.UUCP (09/07/86)
Are you kidding? Of course the response is overwhelming. Kindly put it on the net tomorrow (at least the executables). Thank you.
XBR4D76H@DDATHD21.BITNET (09/12/86)
>I have some questions I hope someone can reply to: > ...... > >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? > > ...... I found some hints in the "Hitch' Guide" and played a bit with SID. BIOS call "getmpb" is a special system call provided for GEMDOS use only (parameter passing between BIOS and BDOS). "getmpb" is called only once at boot time by GEMDOS to get its initial memory management structure. The first "getmpb" call initializes a BDOS structure at 0x56ec of type MPB with { 0x48e, 0, 0x48e } and a memory descriptor at 0x48e of type MD with { NULL /* end of list */, 0xa100 /* _membot */, 0xedf00 /* _memtop - _membot (520ST+) */, NULL /* owning process is system */ }. The memory descriptor at 0x48e is the initial single element free list for the GEMDOS memory manager. The first time, Malloc() is called, the MD at 0x48e is removed from the free list and is inserted into the allocated list modified to the requested block length. For the memory left a new MD is created and inserted into the allocated list. Insertion is done by putting the new in front of the existing elements. This causes the MD at 0x48e to be the end of the allocated list and no Malloc() call will change it. Calling "getmpb" in a user program ( panic !!!!!!! ) modifies the last MD in the allocated list. Probably this has no effect to the memory manager because the modified MD was originated for system memory which is never released, but who knows ????? I wrote a little program to print the memory descriptor lists. It might be useful, if you have memory fragmentation problems. Enjoy ..... ------------ CUT HERE ------------ #include <osbind.h> typedef struct PD { long p_lowtpa,p_hitpa; long p_tbase,p_tlen; long p_dbase,p_dlen; long p_bbase,p_blen; char *p_xdta; struct PD *p_parent; char p_lddrv,p_curdrv; char p_uft[2]; char *p_env; char p_curdir[16]; } PD; typedef struct MD { struct MD *m_link; /* next MD (or NULL) */ long m_start; /* startaddr of block */ long m_length; /* #bytes in block */ PD *m_own; /* owner's process descriptor */ } MD; typedef struct { MD *mp_mfl; /* memory free list */ MD *mp_mal; /* memory allocated list */ MD *mp_rover; /* roving ptr */ } MPB; MPB *gdosmpb = 0x56ec; /* pointer to GEMDOS memory parameter block */ printmd(md) MD *md; { printf(" Address: %lx\tLength: %lx\tOwner: %lx\n", md->m_start, md->m_length, md->m_own); } main(argc,argv) int argc; char *argv[]; { MD *mdpnt; long stack; stack = Super(0L); mdpnt = gdosmpb->mp_mal; printf("\nAllocated Memory Blocks:\n\n"); while (mdpnt) { printmd(mdpnt); mdpnt = mdpnt->m_link; } printf("\nFree Memory Blocks:\n\n"); mdpnt = gdosmpb->mp_mfl; while (mdpnt) { printmd(mdpnt); mdpnt = mdpnt->m_link; } Super(stack); Cconin(); } ------------ CUT HERE ------------ Konrad Hahn Techn. University Darmstadt Dept. of Computer Science (Datentechnik) Merckstr. 25, D-6100 Darmstadt, W.-Germany BITNET: XBR4D76H@DDATHD21 ....... a voice from good old Germany ........
Ulrich.wbst@XEROX.COM (09/13/86)
Who publishes "Gem Programming" that you mentioned in your message. Thanks, Denny
XBR4D76H@DDATHD21.BITNET (09/19/86)
Maybe I found a reason for some system crashs. GEMDOS uses a 3000 word memory area starting at 0x29dc for system purposes (memory descriptors, root process descriptor, directory entries, ... ). Memory of this area is allocated in blocks sized in multiples of 8 words. Released blocks are collected in free lists for each blocksize. Now it comes: A block once created with a particular size has this size forever !!!! I could'nt find any routine to split or combine blocks. The blocks for directory entries and memory descriptors differ in size. If your first program after boot extensively uses Malloc() and Mfree() the system memory will be fragmented into 8 word blocks (actually 9 words because of 1 additional word for blocksize information). After that any request for blocks of other size will fail. I have no idea, why system memory is limited to such a small area, nor why this management scheme is used. Any comments on that ? Konrad Hahn Techn. University Darmstadt Dept. of Computer Science (Datentechnik) Merckstr. 25, D-6100 Darmstadt, W.-Germany BITNET: XBR4D76H@DDATHD21 ....... a voice from good old Germany ........