Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 014
=========================================================================
INFO-ATARI16 Digest Fri, 5 Jan 90 Volume 90 : Issue 14
Today's Topics:
Changing Rez: What we _really_ want to know
How to call the bios from within process termination handlers
media change problem with Toshiba drive
STadel
too late for Lynx ...
TOS 1.4 and Supra driver
Unexpandable megas
----------------------------------------------------------------------
Date: 5 Jan 90 21:14:09 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: Changing Rez: What we _really_ want to know
Message-ID: <1929@atari.UUCP>
In article <2009@sbsvax.UUCP>, roeder@sbsvax.UUCP (Edgar Roeder) writes
stuff about using the terminate handler.
This "hacker's approach to terminate handling" is one of the scariest
things I have ever seen. The terminate handler is meant to let you
restore state which you might have changed before you terminate. It is
not intended to let you off the terminate hook, so to speak. You
should always return normally from a terminate handler, using rts. If
you don't want ~C to stop your program, you should not use cooked
GEMDOS calls. If you don't want a bus error to stop your program, you
should install an exception handler of your own. The terminate
vector just isn't meant for these things.
Correct usage of the terminate vector includes calling BIOS to restore
the state of the screen and keyboard, un-installing vectors like timers
and interrupts you've installed, and the like. You can't make GEMDOS
calls from inside a terminate handler, or call something which might
make GEMDOS calls, like flushing output streams or even closing
workstations which are really metafiles.
I use terminate handlers in graphics programs which change the rez or
palette: the terminate handler changes back to the original rez and
palette. Doing other stuff is asking for trouble: most especially, you
will die horribly if run under MetaDOS or some future multi-tasking
TOS. (MetaDOS is a filesystem call dispatcher placed between user
programs and foreign filesystems like CD-ROMs and (eventually)
networks.)
Please, please, just use the terminate vector to clean up after yourself
and RTS, and save yourself the grief later on.
(By the way, the original article has the wrong address for the
terminate vector: it's at 0x0408, not 0x0400. The exception number,
0x0102, is right.)
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: Fri, 05 Jan 90 23:49:44 -0500
From: David M. Baggett <dmb@TIS.COM>
Subject: How to call the bios from within process termination handlers
Message-ID: <9001060449.AA23484@TIS.COM>
The original thread was about changing resolution from within a
process termination handler (i.e., a function installed at the GEM
process termination vector 0x102).
Atari's Allan Pratt claimed that you can call Setscreen from within
such a handler. He was indeed correct. (I was a bit skeptical after
the 36th crash, but now I Believe.)
HOWEVER, my frustrating attempts to get this to work indicate that the
OS hooks are different in his compiler than in Sozobon C. Calling
Setscreen with Sozobon's standard xbios() call will cause an exception.
I.e., adding *just*
Setscreen(-1L, -1L, 1);
to my process termination handler causes the handler to RTS to an
illegal instruction. Note that this call is #defined in
<osbind.h> and turns into
xbios(5, -1L, -1L, 1)
(i.e., it calls the xbios hook in dstart.o, provided with Sozobon).
For the hell of it, I tried writing my own xbios hook, assuming
Sozobon's stack checking was causing the problem. It wasn't the
stack checking. (At least, that wasn't the only thing.)
Saving the stack pointer before the trap and restoring it afterwards
fixes things. I don't know why the bios trashes the stack when called
from a termination handler. Perhaps a wizardly Atari person could
comment.
Also, I'm wondering if dstart.o is in error for not saving the
stack pointer, or if Atari is in error for writing bios code
that trashes the stack pointer, or if somebody else is in
error (maybe me). (Well, _somebody_ has to be in error! Who
can we flame if no one's in error?)
In any case, anyone who's having trouble getting bios calls to work
from a termination handler (and I believe this is a problem in Laser C
as well) should try using the OS hooks below. They work with Sozobon,
and as far as I know should work with other C's too.
Dave Baggett
dmb@TIS.COM
----------------------------------- >8 ---------------------------------------
;
; Operating system hooks for C with stack pointer saves.
; These are useful for calling bios routines from within a process termination
; function; i.e., a function installed at GEM process termination vector 0x102
;
; (Modified from Dlibs code in dstart.o)
;
.globl __gemdos __bios __xbios
;
; long _gemdos(function, [parameter, ...])
; int function;
;
__gemdos:
move.l (A7)+, traprtn ; save return address
move.l A7, saveA7 ; save stack pointer
trap #1 ; do gemdos trap
move.l saveA7, A7 ; restore stack pointer
move.l traprtn, -(A7) ; put return address back
rts ; return
;
; long _bios(function, [parameter, ...])
; int function;
;
__bios:
move.l (A7)+, traprtn ; save return address
move.l A7, saveA7 ; save stack pointer
trap #13 ; do bios trap
move.l saveA7, A7 ; restore stack pointer
move.l traprtn, -(A7) ; put return address back
rts ; return
;
; long _xbios(function, [parameter, ...])
; int function;
;
__xbios:
move.l (A7)+, traprtn ; save return address
move.l A7, saveA7 ; save stack pointer
trap #14 ; do xbios trap
move.l saveA7, A7 ; restore stack pointer
move.l traprtn, -(A7) ; put return address back
rts ; return
bss
even
traprtn:
ds.l 1 ; storage for return PC in trap hooks
saveA7:
ds.l 1 ; storage for stack pointer in traps
------------------------------
Date: 5 Jan 90 10:36:50 GMT
From: mcsun!ukc!dcl-cs!gdt!gdr!exspes@uunet.uu.net (P E Smee)
Subject: media change problem with Toshiba drive
Message-ID: <1990Jan5.103650.28987@gdt.bath.ac.uk>
In article <1856@ultb.isc.rit.edu> clf3678@ultb.isc.rit.edu (C.L. Freemesser)
writes:
>>
>> I'm adding a Toshiba ND-352TH-A also known as FDD4216G0D as a
>> second floppy. If I leave the media change diode
>> (pin 34 ---|<|--- pin 28) out, everything works fine, except of
>> course media change is not detected. With the diode, once the disk
>> is removed once it always appears write protected.
>>
>> 1) What is the media change signal really supposed to do?
>> I guess that really is, what does Atari expect it to do?
The ST does NOT use the 'media change' signal (aka the 'disk inserted')
signal. It expects the 'write protect' signal to be asserted when a disk
is removed and uses that to decide whether the disk might have been
swapped.
Chinon drive mechs (some models) had this problem. The cure for the
affected Chinon mechs (which I'll describe in case it helps find a fix)
is to open the disk drive and have a look around. (KEEP YOUR GREASY
FINGERS AWAY FROM THE DISK HEADS AND ACTUATOR.) The mechs had two
adjacent and identical push switches. One was the write protect
switch, pressed down when you insert a disk with the protect window
closed. Next to it was the 'disk present' switch, pressed down when a
disk is inserted. (You can see which is which by putting a disk in
while you've got the mech opened up.) The cure was to put a jumper
across the pins of the 'disk present' switch, so that the drive always
thinks there is a disk in. Those mechs only report 'write protect' if
there is a disk in -- if they always think there is a disk in, then
'write protect' does the right thing when there isn't one. (Sounds to
me like, for your mech, you'd need both to nobble the media-change
diode, and the 'disk present' switch.)
NOTE -- This worked for me. That does not mean I guarantee it will work
for you. If you even THINK about opening the case of your mech, on your
own hands be it. Good luck.
--
Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132
Smee@bristol.ac.uk :-) (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)
------------------------------
Date: 5 Jan 90 22:08:56 GMT
From: van-bc!ubc-cs!alberta!ccu!charltn@ucbvax.Berkeley.EDU (Jim Charlton)
Subject: STadel
Message-ID: <1990Jan5.220856.19344@ccu.umanitoba.ca>
Can anyone tell me where I can get the latest version of STadel,
including all of the help and menu files. I would also like the
sources. I tried snail and e-mail to David Parsons (sp?) but my mail
must have missed him. If anyone has the latest version and could
lharc it together and mail it to me, I would much appreciate it.
jim.... charltn@ccu.umanitoba.ca
------------------------------
Date: 5 Jan 90 18:56:52 GMT
From: imagen!atari!kens@ucbvax.Berkeley.EDU (Kenneth Soohoo)
Subject: too late for Lynx ...
Message-ID: <1928@atari.UUCP>
In article <75298@tut.cis.ohio-state.edu> Mustafa Thamer
<thamer@cis.ohio-state.edu> writes:
>
> Now that Xmas is over and every kid around has a Nintendo GameBoy, I guess
>Atari can go ahead and release the relatively unknown Lynx. Couldn't
>they speed it up a little and get it out the month before Xmas ? I know
>they're not braindead over there ...
> Someone, somewhere is going to tell me that they have one, right ?
>
Actually, Lynx(s) have been shipping for quite some time now, well
before Christmas, to New York and Los Angeles. You could have called
the Sears mail-order catalog and ordered one, if you don't live in
those areas... Also, I hear that two Bay Area stores got a shipment
apiece...
--
Ken Soohoo ?ames,imagen,portal?!atari!kens
Atari (U.S.) Engineering
>> The Opinions Expressed above are _MINE_, _NOT_ Atari's. <<
------------------------------
Date: 5 Jan 90 20:25:18 GMT
From: helios.ee.lbl.gov!ux1.lbl.gov!keithj@ucsd.edu (Keith J Groves)
Subject: TOS 1.4 and Supra driver
Message-ID: <4570@helios.ee.lbl.gov>
I experienced the same symptom with my Supra 20 drive and have since
discovered that it is a feature of TOS 1.4 that prevents one from
booting off the internal floppy while the Supra autoboot feature is
installed. I just boot my ST first and then my hard drive and run the
Supboot program.
Keith Groves
------------------------------
Date: 4 Jan 90 16:01:33 GMT
From: mcsun!ukc!stl!stc!root44!hrc63!mrcu!ya16@uunet.uu.net (Ian Powell)
Subject: Unexpandable megas
Message-ID: <323@mrcu>
In article <1431@castle.ed.ac.uk>, aimd@castle.ed.ac.uk (M Davidson) writes:
> In article <8912120805.AA00886@ucbvax.Berkeley.EDU> STJLHI33@WATSON.BITNET
writes:
>
> I thought it was just *some* Mega 2's that were crippled. Any-road-up,
> Frontier Software in the UK offer a 1/2meg or 2meg solderless RAM
> upgrade which will upgrade any 512k ST to 1meg and, by switching chips
> at a later date, upgrade a 512k machine to 2.5meg. More to the point, it
> also claims to upgrade a Mega 2 to a Mega 4.
I have a Mega 2 which has been upgraded to 4 Mb using Frontier's hardware and
it works fine. And whats more the installation was relatively painless.
------------------------------
End of INFO-ATARI16 Digest V90 Issue #14
****************************************
