Path: utzoo!utgpu!water!watmath!egisin
From: egisin@watmath.waterloo.edu (Eric Gisin)
Newsgroups: comp.sys.atari.st
Subject: Re: autostarting GEM programs
Message-ID: <16726@watmath.waterloo.edu>
Date: 5 Feb 88 00:20:29 GMT
References: <880201194539737.AETG@Mars.UCC.UMass.EDU> <1988Feb3.080736.14303@mntgfx.mentor.com>
Organization: U of Waterloo, Ontario
Lines: 26

In article <1988Feb3.080736.14303@mntgfx.mentor.com>, dclemans@mntgfx.mentor.com (Dave Clemans) writes:
> Re: autostarting GEM programs
> 
> My understanding is that what the autostart programs do is to set up a
> small TSR routine attached to the vertical blank interrupt vector.  On each
> interrupt the code looks around and tries to guess whether or not GEM is
> initialized yet.  If it looks initialized it disengages from the vertical
> blank interrupt and starts the requested GEM program.  Whether or not a
> specific version of this technique works with all versions of the ROM's
> depends on specifically how the code checks for GEM being initialized.

Having disassembled gemstart recently, I'll describe what I found out.

It installs a VBL routine (in slot 1, not checking if it is in use)
that waits until the line-F trap handler is initialized (changes).
GEM uses the line-F opcodes as a "short" procedure call.
It wraps it own line-F handler around GEM's handler,
which intercepts two line-F opcodes (I don't know what they are).
When the handler encounters one of these opcodes, it looks up an address
in the ROM relative to the caller's PC, and uses that
in some way to pass the name of a program to be started by GEM.

I wish people who write this type of program would distribute
source; the programs are bound to break with new version of the OS.
I guess someone will have to disassemble gemstart and try to fix it.
(not me, I don't have an assembler)