pes@bath63.ux63.bath.ac.uk (Paul Smee) (12/11/86)
I have an application for which I need (essentially) a GEM program which can be run automatically on boot and reset. Of course, GEM isn't around when AUTO folder things get run. It feels to me like what I need to do is write a program which can be put into the AUTO folder, which will hang itself onto the vsync or hsync interrupts, and then sit patiently until GEM has been started, and kick off the application. This means that it's got to be able to tell that GEM has started. So, what I think I need is a location, somewhere, which I can garbage (or which the system itself garbages on boot/reset, and which is set to a recognisable value at some point late in the startup of GEM itself, after the GEM facilities have become available. Has anyone found such a variable? (Unofficial 'works under version XXX' bootleg solutions would be acceptable at this point -- though a 'documented and guaranteed low-mem location would be preferable, of course.) If I get desperate, I might try the video buffer, but that's a bit shaky since other AUTO folder programs could move the video buffer between 'looks', and because other AUTO folder programs might *use* the video buffer -- and so might by chance put values in which look just like the GEM desktop in whatever area I choose to look at... Variables which are set during the GEM start-up, a more-or-less predictable amount of time before GEM has moved in, would also be OK. I could live with something like 'wait until location 1AFC is set to FFFEAB02, and then wait 2 more vsyncs'... Paul
pc@ukc.ac.uk (R.P.A.Collinson) (12/11/86)
I took the approach that you should ask GEM if it is there. The
routine below works for me. Whether it is legal... is not clear.
You need to kill GEM on exit so that TOS (or whoever)
can start it again...
/*
* This C is compiled by my VAX compiler, it may not compile on another
* compiler in the world. But I am sure the you will get the drift.
*
*
* Ensure that VDI is running
*/
#include <vdi.h> /* replace by your favourite header */
static int vdi_handle;
ensure_vdi()
{ short work_in[11];
short work_out[57];
register i;
if (vdi_handle == 0)
{ work_out[0] = 0;
vq_extnd(1, 0, work_out);
if (work_out[0] == 0)
{ /* need to open the workstation */
for (i = 0; i < 10; i++)
work_in[i] = 1;
work_in[10] = 2;
v_opnwk(work_in, &vdi_handle, work_out);
}
}
}
ensure_vdi_closed()
{ if (vdi_handle)
v_clswk(vdi_handle);
}
bammi@cwruecmp.UUCP (12/15/86)
It seems to me the most logical way would be to write a little accessory that kicks off the programs that you want (could read the paths of the programs from a file in a fixed place). This way you don't have to depend upon any locations, weird timings etc, and you are guaranteed that if the accessory was able to run, Gem is there. -- usenet: .....!decvax!cwruecmp!bammi jwahar r. bammi csnet: bammi@case arpa: bammi%case@csnet-relay compuServe: 71515,155
pete@utcs.UUCP (12/16/86)
Hi.
Last night, while cursing machine, I had an idea. I have noticed that
some accessories seem to load in and never appear in the desk menu. Things
like RamDisks and Printer Spoolers seem to do this. I am assuming that these
things must happen AFTER gem is launched. Would it not be possible to create
a program that does the following:
1: load as an accessory, thus post gem launch.
2: execute all programs in a certain directory (AUTO.GEM for example?)
3: return to desktop.
I realise that this would have to be the last accessory to be loaded. I
assume that gem loads sequetially, like the AUTO folder. I would try to
accomplish this feat myself, but neither Modula, nor my PD assembler allow
the creation of Accessories.
How 'bout it? Any adventurous takers wanna give it a try? Instead of
cursing Atari for not including all the featurs we want, why don't we try
to create this and set a standard ourselves!
Thanks,
Pete Santangeli
pete@utcs
psantangeli on BIXpes@bath63.ux63.bath.ac.uk (Paul Smee) (12/17/86)
In article <1699@cwruecmp.UUCP> bammi@cwruecmp.UUCP (Jwahar R. Bammi) writes: > >It seems to me the most logical way would be to write a little >accessory that kicks off the programs that you want (could read the >paths of the programs from a file in a fixed place). This way you don't have >to depend upon any locations, weird timings etc, and you are guaranteed that >if the accessory was able to run, Gem is there. In general, yep, I'd go along with that. It's certainly a cleaner and neater way to do things. However, I'm addressing an area which assumes (probably wrongly, but I don't get to choose my working assumptions) that the 'typical' user won't even have the cleverness or wit to pick an accessory or menu item. So, what I need, is a way of making the system (appear to) boot straight from power-on into a GEM-based application, with no help from the user other than putting the boot disk in. (God only knows why I'm even allowed to assume they know how to do that, but there you are.)