[comp.sys.atari.st] AES Support

jimomura@lsuc.on.ca (Jim Omura) (11/13/90)

     Having successfully added the graphic display I wanted
in the program I'm working on, I decided to try to add
some mouse support.  Again I faced the question of deciding
the level to work on.  In this case the decision was again
simple, but the opposite of my earlier Line-A approach.  My
documentation of the low level mouse call is very sketchy
and not sufficient to program with.  So I decided to finally
give a try at programming on the AES level.

     I have the "Compute!'s Technical Reference Guide
Atari ST Vol. 2" by Sheldon Leemon and it looked fairly
complete, so having read all that I expected I'd needed, I
started into the programming.  The first thing I found was
that the Sozobon C 1.2 DLIBS library didn't have any bindings
for "appl_int()" and "appl_exit()".  So I couldn't even
get started.  Nor was there a "GEMDEFS.H" file, which
didn't bode well.  So I checked the libraries as best as
I could and came to the conclusion that GEM AES calls are
simply not supported by Sozobon C.  I looked again at the
Leeman book and I'm not sure yet if there really is enough
information for me to build the support functions.

     If anybody has sources for support functions, again,
I'd appreciate it.  If not, well, I'm going to start in
coding my own for now.  And that leads me to my most
immediate problem.  I've coded what I think are valid
implimentations for an 'appl_init()' equivalent function
and an 'appl_exit()' equivalent function.  These are
*deliberately* a bit different then the functions described
as being "standard".  In the "standard" versions, the
AES Base Pointer Structure is a global that is presumed
by the function calls and thus, *no* arguments are passed.
In my versions I pass a pointer to the structure.  I won't
go into why I wrote it this way.  I'll simply say that it's
my personal opinion that this is probably a better idea.

     But having written the functions, and a test program,
I ran it and found that the 'ap_id' returned is always 0.
This doesn't sound right to me, though it could be.  Does
anybody know if this is a reasonably possible result?
The following is my source:


	.text
	.globl	_apinit
_apinit:
; int apinit(aespb);
; AESPB *aespb; /* aespb is a pointer to an array of pointers */
;
; Initializes AES support and returns 'ap_id';
; Sozobon C AES Support by Jim Omura
;
;var	4	8	_aespb
;
	link	a6,#-0
;
	movea.l	8(a6),a0	; A0 = 'aespb'
	movea.l (a0),a1		; A1 = 'contrl'
	move.w	#10,(a1)	; 'opcode'   = 10
	move.w	#0,2(a1)	; 'sintin'   =  0
	move.w	#1,4(a1)	; 'sintout'  =  1
	move.w	#0,6(a1)	; 'saddrin'  =  0
	move.w	#0,8(a1)	; 'saddrout' =  0
;
	movea.l	4(a0),a1	; A1 = 'aesglob'
	move.l	#0,14(a1)	; 'ap1resv' = 0
	move.l	#0,18(a1)	; 'ap2resv' = 0
	move.l	#0,22(a1)	; 'ap3resv' = 0
	move.l	#0,26(a1)	; 'ap4resv' = 0
;
	move.l	a0,d1		; D1 = 'aespb'
	move.w	#$c8,d0		; AES routines
	trap	#2
;
; Store ap_id in globals:
	movea.l	8(a6),a0	; A0 = 'aespb'
	movea.l	12(a0),a1	; A1 = 'intout'
	movea.l 4(a0),a2	; A2 = 'aesglob'
	move.w	(a1),4(a2)	; 'gl_apid'
;
; Store the Return Value:
	move.w	(a1),d0		; D0 return 'ap_id'
;
	unlk	a6
	rts
;
	.data
-- 
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
lsuc!jimomura
Byte Information eXchange: jimomura

davidli@simvax.labmed.umn.edu (11/13/90)

In article <1990Nov12.185237.8817@lsuc.on.ca>, jimomura@lsuc.on.ca (Jim Omura) writes:
> started into the programming.  The first thing I found was
> that the Sozobon C 1.2 DLIBS library didn't have any bindings
> for "appl_int()" and "appl_exit()".  So I couldn't even
> get started.  Nor was there a "GEMDEFS.H" file, which
> didn't bode well.  So I checked the libraries as best as
> I could and came to the conclusion that GEM AES calls are
> simply not supported by Sozobon C.

Sozobon C does not contain GEM support.  There -are- GEM Bindings and support
libraries (for AES/VDI), written by Ian Lappore.  You should check the archives
for the GEMFAST archives (atari.archive.umich.edu has the version 1.2 bindings
in "/atari/Binaries/volume05/gemfst12.arc" -- meaning they were posted to
comp.binaries.atari.st at one time.

The latest version is 1.3 or 1.4.  I didn't see them in the 'programming'
subdirectory.  Good luck.

-- 

David Paschall-Zimbel		davidli@simvax.labmed.umn.edu

csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) (11/15/90)

jimomura@lsuc.on.ca (Jim Omura) writes:

>     But having written the functions, and a test program,
>I ran it and found that the 'ap_id' returned is always 0.
>This doesn't sound right to me, though it could be.  Does
>anybody know if this is a reasonably possible result?

The main application always gets 0 as its ID. Try to start
it as a DA, and you'll get other values.

----------------------------------------------------------------------
Claus Brod, Am Felsenkeller 2,			Things. Take. Time.
D-8772 Marktheidenfeld, West Germany		(Piet Hein)
csbrod@medusa.informatik.uni-erlangen.de
----------------------------------------------------------------------