Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!rutgers!umn-d-ub!cs.umn.edu!thelake!steve
From: steve@thelake.mn.org (Steve Yelvington)
Newsgroups: comp.sys.atari.st
Subject: Re: Sozobon C
Message-ID: <A2668958805@thelake.mn.org>
Date: 22 Feb 90 01:56:42 GMT
References: <3740@uafhp.uark.edu>
Lines: 102

[In article <3740@uafhp.uark.edu>,
     dhe@uafhcx.uucp (David Ewing) writes ... ]

> 
>       Does anyone out there have any source code that would allow Sozobon C to
> use the A-Line functions and AES?  I've gotten version 1.2, but it seems to be
> lacking in a few areas, like support for all the nice graphics of the ST.

I'm responding here instead of mail because this is a question of general
interest.

These are two different issues.

First issue: the AES (and VDI).

AES calls are supplied in the GEMFAST bindings by Ian Lepore.  GEMFAST is
in the Panarthea archives. The package includes a library of AES bindings,
a library of VDI bindings, and some utility functions. The current release
seems to be pretty reliable. Among its nicer features is a fsel_exinfo()
function that checks the GEM version and fakes the extended file selector
features if you don't have TOS 1.4 or better. It's written in MadMac, so
you can't alter things with the Sozobon assembler, but you can get it in
object library form. Incidentally, Ian should be reachable at
ian%fwbbs.citadel@thelake.mn.org.

Another, older set of GEM bindings, GEMQ by Don Farmer, also is available.
It's less fully featured, but it will assemble with jas.ttp.

Second issue: Line A.

Atari has surrounded Line A with nondisclosure agreements. There is not,
to my knowledge at least, a set of PD Line A routines. J.R. Bammi wrote an
aline.h #include file that might help you roll your own. It tells you what
values you will be able to find/change based on the Line A pointer.

You can write the basic Line A functions easily enough -- using embedded
assembler if you want. Basically you're putting illegal opcodes in the
text portion of your program. If you do:

char *getlinea()
	{
	asm(".dc.w $A000");
	}

... you'll have a Line A init function. A pointer to the Line A block will
be returned (in D0).

However, you must not try to run this -- or any C code with embedded Line
A opcodes -- through Tony's optimizer. You'll have to untangle the raw
output of hcc by hand, producing this:

	.text
	.globl	_getlinea
_getlinea:
	.dc.w   $a000 
	rts

... which you probably should have written in asm in the first place.

Generally you stuff the right values into the right memory locations,
and/or place an address in register A6. Then you feed the right $Annn
value to the 68000. Zap! But figuring out what locations need to be fed
what values is a big pain.

I haven't found Line A to be worth the hassle for general programming
except for obtaining (and modifying) such system variables as the number
of lines and columns on the TOS screen.

Here are some opcodes:

 $A000	initialize; returns Line A pointer in A0 and D0, font table
	pointer in A1, and function table pointer in A2
 $A001	put pixel
 $A002  get pixel; returns a value in D0
 $A003	draw line; may return a value (??) in D0
 $A004	draw horizontal line
 $A005	draw filled rectangle
 $A006	draw filled polygon
 $A007	bit block xfer
 $A008	text block xfer
 $A009	show mouse
 $A00A	hide mouse
 $A00B	transform mouse
 $A00C	undraw sprite
 $A00D	draw sprite
 $A00E	copy raster form
 $A00F	seed fill

If you start messing around with Line A stuff you'll begin to see
similarities between the Line A and the GEM VDI.

Disclaimer: This information comes from various public sources; none comes
from Atari documentation (which I don't have anyway).  You'll have to
determine what works by experimenting at your own risk. If any of this is
incorrect, feel free to explain why and how.

-- 
   Steve Yelvington at the (thin ice today*) lake in Minnesota
   UUCP path: ... umn-cs.cs.umn.edu!thelake!steve
   
   *16 cars through the ice so far this year! Yes, you, too, can
    have that sinking feeling....