Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 098
=========================================================================
INFO-ATARI16 Digest Thu, 25 Jan 90 Volume 90 : Issue 98
Today's Topics:
AES function appl_tplay() and appl_trecord()
Elite! - Avoiding police
GEM, BIOS, XBIOS, GEMDOS bindings for Sozobon
MWC (was Re: dissassembly)
Networking
Subscription
Where is AES entry point?!? (Please Help Me. :-)
----------------------------------------------------------------------
Date: Thu, 25 Jan 90 19:53:19 GMT
From: Michael Mueller <K298027%CZHRZU1A.BITNET@CUNYVM.CUNY.EDU>
Subject: AES function appl_tplay() and appl_trecord()
I'd like to use the functions appl_tplay()| & appl_trecord(). Unfortunately, I
still have old ROMs of 1985 (don't ask me the TOS version). As far as I could u
nderstand, these functions only work with newer TOS versions.
Does anybody know what is the bug in the old ROMs ? Is it reasonably possible t
o implement these functions by soft ? Where could I get the listings (in C, ev.
in ASM) ?
N.B.: These functions allow to record every event. You can store these events,
and play them back when you want. I think there was a question about it recentl
y...
Michael Mueller, Brain Research Institute, Zuerich, Switzerland
------------------------------
Date: Thu,25 Jan 90 11:02:56 GMT
From: R.D.Chafer%sysc.salford.ac.uk@NSFnet-Relay.AC.UK
Subject: Elite! - Avoiding police
Message-ID: <25 Jan 90 11:02:56 A10326@UK.AC.SALF.C>
Even with the docking computer on SLOW, the police will not shoot while
the docking computer is on (my version anyway).
Robert
------------------------------
Date: 25 Jan 90 18:20:37 GMT
From: dartvax!eleazar.dartmouth.edu@CS.BU.EDU (Clark L. Breyman)
Subject: GEM, BIOS, XBIOS, GEMDOS bindings for Sozobon
Message-ID: <18829@dartvax.Dartmouth.EDU>
What are the preferred binadings to GEM (AES/VDI), GEMDOS,
BIOS and XBIOS for Sozobon? Or is the best way to teach oneself
GEM... by writing bindings?
Much app,
Clark
------------------------------
Date: 25 Jan 90 18:32:50 GMT
From: sjsca4!greg@uunet.uu.net (Greg Wageman)
Subject: MWC (was Re: dissassembly)
Message-ID: <1990Jan25.183250.20884@sj.ate.slb.com>
Opinions expressed are the responsibility of the author.
In article <893@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes:
>> >If you're writing code that you eventually hope for
>> >other people to use, don't hard-code magic numbers like 32K into your
>> >screen manipulation routines. [In fact, don't even use 32K. You only
>> >need, at most, 32256, to get 32000 bytes on a 256 byte boundary, eh?]
>
>Well -- I had to use some value when I wrote the example. I could have
>used a #define, but at the time it seemed like this would remain unchanged
>for the immediate future, and we didn't want to go through all the extra
>trouble (in the example) to calculate the memory needs of the new display.
>(It was not a GEM example, and S.A.L.A.D. was not yet written, and even when
>these two conditions are met, it is still more than a few lines of code
>to figure this out in the general case for all possible future display
>modes, if its possible at all. I don't know what happens when you use
>a Moniterm.) These examples were supposed to be short and illustrate
>proper use of the documented routine/function/feature, without adding
>lots of extra stuff that might confuse or intimidate the novice ST programmer.
Since TOS fails to provide a system call to return you a
correctly-aligned, properly-sized chunk of memory useable as display
memory, it is *impossible* not to hard-code certain assumptions into
the code to do this. MWC needs no defending on this point.
>In my honest opinion, biased as it may be, the MWC manual is the single
>best volume for programming the ST published to date. It needs revision,
>bugfixing, and maybe some other tweeking (new GEM examples, etc.) and
>the compiler should be updated, but it is still a very good package at a
>good price.
There are some occasions where it leads to more frustration than
useful results, but care in marking corrections discovered through
trial-and-error will eventually produce a very comprehensive manual.
I consult my MWC manual first (since it's only one volume and fits
comfortably in my hand), and only when something doesn't work as
advertised do I break out the backup, the dreaded Developer's Docs.
Since the MWC manual seems to have been written from experience rather
than specs, it tends, when there is a disagreement, to be the
more-frequently-correct one.
In many cases the MWC examples demonstrate important points that
aren't mentioned elsewhere. On the other hand, at least one of the
examples doesn't work at all (I think it was the one that demonstrated
the use of fsel_input()). A new versions was published in the
errata with version 3.0.6 of the compiler, but *it* didn't quite work,
either. These are the sorts of problems that extend the development
time of what should otherwise be a quick and easy program.
However, since the wise programmer writes routines that are as general
as possible, and reuses them as frequently as possible in new code,
(or at least reuses code fragments) one should find the learning curve
getting steeper with each project, as one discovers how to use more
and more pieces of TOS properly. This has certainly been my
experience.
Copyright 1990 Greg Wageman DOMAIN: greg@sj.ate.slb.com
Schlumberger Technologies UUCP: ?uunet,decwrl,amdahl?!sjsca4!greg
San Jose, CA 95110-1397 BIX: gwage CIS: 74016,352 GEnie: G.WAGEMAN
Permission is granted for reproduction provided this notice is maintained.
------------------------------
Date: 25 Jan 90 15:06:14 GMT
From: cs.umn.edu!thelake!steve@ub.d.umn.edu (Steve Yelvington)
Subject: Networking
Message-ID: <0025900906143026@thelake.mn.org>
[In article <9001250807.AA00801@ucbvax.Berkeley.EDU>,
K331672@AEARN.BITNET (Gerfried Klein) writes ... ]
>
> Hi all |
>
> Please could somebody tell me how to reach the CI$ network from BITNET ?
> Or is there a better way to contact ANTIC via e mail ?
>
> Hey folks, it would be a wonderfull thing if someone could sommon the
> networking information (which networks are reachable, archive-hosts, ..)
> so that beginners in networking could fetch this info.
> But maybe there is one out there, would be fine |
>
Convert the CIS user ID from the form 7xxxx,yyy to 7xxxx.yyy (replace
the comma with a dot).
Then mail to the following address:
7xxxx.yyy%compuserve.com@saqqara.cis.ohio-state.edu
The appropriate newsgroup for questions of this sort is comp.mail.misc.
John Chew posts a (mostly monthly) guide to internetwork mailing; I
received the most recent copy about three days ago, so it should be
available on your system.
--
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....
------------------------------
Date: 25 Jan 90 18:58:51 GMT
From:
swrinde!zaphod.mps.ohio-state.edu!uwm.edu!mrsvr.UUCP!jupiter.uucp!krieg@ucsd.ed
u (Andrew Krieg)
Subject: Subscription
Message-ID: <1953@mrsvr.UUCP>
SUBSCRIBE INFO-A16
--
=========================================================================
= Andrew Krieg The Marvel Historian =
= G.E. Medical Systems - CT - New Berlin, WI =
= USENET: krieg@jupiter.med.ge.com =
=========================================================================
= "Holy one track Batcomputer mind!" - Robin =
=========================================================================
------------------------------
Date: 25 Jan 90 15:23:12 GMT
From: cs.umn.edu!thelake!steve@ub.d.umn.edu (Steve Yelvington)
Subject: Where is AES entry point?!? (Please Help Me. :-)
Message-ID: <0025900923123027@thelake.mn.org>
[In article <10489@saturn.ucsc.edu>,
rome@ucscb.UCSC.EDU writes ... ]
> I was up all last night trying to call a file selector using
> assmebler code mixed with a C source file.
>
> I am trying to send the extended information to the AES file
> selector function that is picked up and utilized by LGF's File Selector.
>
> In the documentation for the LGF FS, there is in-line assembler
> code provided to type into a C program to get it to call the file selector.
>
> One of the instructions is "bsr AES" ... Well, Laser C does
> not seem to have any constant "AES" defined.
>
> Does anyone know the absolute memory entry point for the AES?
> Can anyone help? We'll see.
>
It doesn't work that way. AES is entered through a 68000 trap, not through
an address.
I think Charles Johnson has made some unwarranted assumptions about what
can be found in the C bindings for the AES. The label "aes" may or may not
be defined. I don't know how Laser does it.
The following information may help you determine what he is looking for.
The AES is invoked by:
* copying the arguments to the function (file selector call, for
example) into "mailboxes." There are arrays of mailboxes, typically
labeled control[], global[], int_in[], int_out[], addr_in[], and
addr_out[]. I don't recall their sizes. The args are copied from
left to right in a C binding. Integers go into int_in[];
addresses (such as pointers to strings) go into addr_in[], etc.
* the control[] mailbox array is stuffed with an AES opcode
number (control[0]). Three magic numbers are stuffed into
control[1] through [3]. These numbers tell the AES how many
integers and addresses to expect. The numbers are contained in
the dlibs crystal.s module, if you're interested.
* an array of 6 addresses is loaded with the addresses of
each of the mailbox arrays (control, global, etc., as above).
This array typically is called the AES parameter block.
* The address of the AES parameter block is loaded into d1.
* The magic number 200 is loaded into d0.
* trap #2 kicks AES into action.
I think I've got all this right, but no promises. :-) I wrote some AES
bindings in C for Sozobon before GEMFAST came out, and this is the
strategy that I figured out from various published (non-Atari) documents
and code snippets.
--
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....
------------------------------
Date: Thu, 25 Jan 90 09:12:00 -0900
From: <AXCSH%ALASKA.BITNET@CUNYVM.CUNY.EDU>
UNSUBSCRIBE Chris Hamman
------------------------------
End of INFO-ATARI16 Digest V90 Issue #98
****************************************
