Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 011
=========================================================================
INFO-ATARI16 Digest Thu, 4 Jan 90 Volume 90 : Issue 11
Today's Topics:
Archive-server
Changing Rez: What we _really_ want to know
Commandline length?
HARD DRIVE WOES
LHARC takes over? Sure hope not!
PageStream fonts
too late for Lynx ...
----------------------------------------------------------------------
Date: 4 Jan 90 22:51:32 GMT
From:
pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uf
lorida!news@tut.cis.ohio-state.edu (USENET Master)
Subject: Archive-server
Message-ID: <21615@uflorida.cis.ufl.EDU>
I seem to have lost contact with
archive-server@panarthea.ebay.sun.com. Is there another address for
this, or does it have an FTP site?
From: cr1@beach.cis.ufl.edu (Christopher Roth)
Path: beach.cis.ufl.edu!cr1
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Christoper Roth * "Machines have no
* InterNet : cr1@beach.cis.ufl.edu * Conscience..."
=-=-=-=-=-=-=-=-=-=-=-=-=-Post No Bills-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
------------------------------
Date: 4 Jan 90 14:50:38 GMT
From: mcsun!unido!sbsvax!roeder@uunet.uu.net (Edgar Roeder)
Subject: Changing Rez: What we _really_ want to know
Message-ID: <2009@sbsvax.UUCP>
In article <8912301917.AA19200@TIS.COM>, dmb@TIS.COM (David M. Baggett) writes:
> P.S.> Could some kind soul please repost the "all about terminate handlers"
> article here? Thanks.
Sorry, i don't have this document, but i have prepared another one. The file is
in Info-format, suitable for reading with GNU-emacs, but it should be readable
as text too.
Hope this helps!
- Edgar
---------------------- cut here ------------------------
Info file: etv_term, -*-Text-*-
produced by texinfo-format-buffer
from file: etv_term.txi
This file documents the TOS terminate handler etv_term and what you can
do with it.
File: etv_term Node: Intro, Prev: Concept Index, Up: Top, Next: Top
The Terminate handler
*********************
Some people on the net asked for documentation about the terminate
vector. Here is what i have collected over the past few years. Some of
the details required a lot of experimenting, but all the presented
solutions work with all TOS versions (although undocumented features are
used).
- Edgar
File: etv_term Node: Top, Prev: Intro, Up: (dir), Next: Actions
When is the Terminate Handler called ?
======================================
The logical vector #0x102 "etv_term" at address 0x400 is called by
`Pterm()' before a program is terminated. This can have several
causes. Either
1. an explicit call to
* the gemdos functions `Pterm0()', `Pterm()' or `Ptermres()' or
* `trap #2' with argument 0 in register D0 or
2. another program (a resident monitor like templmon or a shell or an
accessory) directly calls one of the above functions or
3. `Pterm()' (in early TOS versions `Pterm0()') is called
from one of the exception routines (after some bombs or mushrooms
have been drawn) or
4. `Pterm(-32)' is called when ~C is pressed during screen-I/O
Since in cases 2--4 above the user program normally has not
initiated the program termination, the terminate vector is the last
(and only) chance to do some cleanup work before execution is
finished.
* Menu:
* Actions:: What can a terminate handler do
* Call:: How the handler is called
* Installation:: How to install a handler
* Concept Index::
File: etv_term Node: Actions, Prev: Top, Up: Top, Next: Call
What you want to do in the Handler
==================================
Before Program Termination (cases 2 + 3)
----------------------------------------
* give some good-bye message to the user
* flush buffered output streams (files are closed after the call to
etv_term by TOS)
* deinstall modified system vectors (*Note Installation::)
* modify the return code to signal an error condition to the calling
program (*Note Return Code::)
* prevent termination (probably after asking the user) and go to a
safe place to restart the program (for example the prompt in an
interpreter) or enter a debugger (in case 3 above)
If ~C is pressed (case 4)
-------------------------
* ignore it completely (*Note Ignore ~C::)
* ask the user wether to ignore it or to terminate the program
* go to a safe place and cancel the current action of the program
So what we need to know about terminate handlers are the
restrictions, which TOS-functions can be called, how we can access
the parameter to `Pterm' and how we can resume execution at
the place where ~C was pressed.
* Menu:
* Restrictions:: What can be called from a handler
* Return Code:: access the program's return code
* Ignore ~C:: avoid program termination
File: etv_term Node: Call, Prev: Actions, Up: Top, Next: Installation
How is the handler called ?
===========================
The etv_term vector is called via `jsr' in supervisor mode. The
calling routine (`Pterm()') was called in C with one parameter (the
return code for the program) on the stack (*Note Return Code::).
File: etv_term Node: Installation, Prev: Call, Up: Top, Next: Concept Index
How can i install my own routine ?
==================================
If you are in supervisor mode (after a call to `Super()' from user
mode with a parameter != 1L or in a routine executed by
`Supexec()') you can directly set the variable at `0x400' to
the address of your routine:
*((void (**)()) 0x400) = own_routine;
More portable and the recommended way is a call to the Bios function #5
(`Setexc()'):
old_routine = (void (*)()) Setexc(0x102, own_routine);
The terminate handler itself has no parameter and no return value:
void own_routine(void);
File: etv_term Node: Restrictions, Prev: Actions, Up: Actions, Next: Return
Code
What can be done in a terminate handler ?
=========================================
This depends on what should happen after the handler has finished. We
have three cases:
1. cleanup and terminate execution of the program
2. resume execution at some safe point (eg. top level of program)
3. ignore the termination request (*Note Ignore ~C::)
In case 1 we should restore the original terminate handler before we
leave our program. This can be done like the installation with
Setexc(0x102, old_routine);
If our terminate handler is not removed before other programs are
started, the handler will also be called when these other programs are
about to be terminated. In a shell this can be used to control the
behavior of other programs with respect to ~C.
In case 2 we should return to user mode since this is the normal mode of
execution for user programs. This can be done with a call to the gemdos
function `Super()' after calling `longjmp()'. A sample code
fragment could be this:
#include <setjmp.h>
jmp_buf global_exit;
long stackpointer;
void
terminate_handler(void)
?
...
longjmp(global_exit,1);
?
toplevel_routine()
?
int ret;
...
stackpointer = Super(0L);
ret = setjmp(global_exit);
Super(stackpointer);
switch(ret) ?
...
?
...
?
In the cases 1 and 2 you may call any routines (including gemdos, bios,
xbios, aes and vdi) since we leave the normal flow of execution anyway
and so no information needs to be preserved. But you have to be
careful, if `Pterm()' was called as the result of a processor
exception (eg. bus error): probably some internal data structures are
in an unstable state.
In case 3 it is important to know where the `Pterm()'-call
happened. As a thumb rule you can call xbios or bios safely from any
place. But if you have switched to user mode (and want to decide
between cases 1, 2 or 3 later), you cannot use the old userstack. Some
people might prefer using the user stack in supervisor mode too. Also
gemdos - if called from user mode - uses a part of the user stack below
the user stack pointer (?40 bytes) to save some registers. And this is
just the case if `Pterm()' was called via `trap #1'.
File: etv_term Node: Return Code, Prev: Restrictions, Up: Actions, Next: Ignore
~C
How can the argument to `Pterm()' be accessed ?
===============================================
`Pterm()' is called from C. The argument to `Pterm()' can
thus be found on the stack. Since it is also programmed in C we can
access the parameter with the help of processor register A6 the
frame pointer in C. `Pterm()' calls (*etv_term)() directly. At
the entry of our routine A6 still points to the right frame. So
we can get the return value for the program (the parameter of
`Pterm()') simply as the word 8 bytes above the frame pointer (as
usual in C).
The value of the return code can be read and compared against -32 to
decide wether ~C was pressed (or `Pterm(-32)' called). So we can
distinguish the several causes for a `Pterm()'-call. We can also
change this value on the stack to change our program's return value.
If you are using KAOS-TOS (some patches to Blitter-TOS from the german
magazine c't - don't ask me about it since TOS 1.4 is certainly better)
the return value if ~C was pressed is different. Here it is -68 if ~C
was pressed and -69 if an exception occured.
File: etv_term Node: Ignore ~C, Prev: Return Code, Up: Actions
How can ~C be ignored ?
=======================
Several solutions exist for this problem. One is to use only functions
ignoring ~C for screen-I/O (`Crawio()', `Crawcin()' or bios
functions).
But you can also use the terminate-vector for this task. TOS was
programmed in C and the compiler did not know that `Pterm()' is not
supposed to return to the calling routine. Now if `Pterm()'
returns no surprising effects are observed and the execution goes on as
if ~C was not pressed. But remember that this is not guaranteed to work
to all eternity (but it works from TOS 1.0 - 1.4).
To ignore ~C all you have to do in the terminate handler is to check for
the return value -32 and before the rts instruction do an extra
`unlk a6' to pop the frame of the C-function `Pterm()'. The
program will continue as if ~C was never touched.
File: etv_term Node: Concept Index, Prev: Installation, Up: Top, Next: Intro
Concept Index
*************
* Menu:
* access return code: Return Code.
* actions: Actions.
* call: Call.
* calling conditions: Top.
* etv_term: Top.
* get address of old handler: Installation.
* ignore ~C: Ignore ~C.
* install a new handler: Installation.
* installation: Installation.
* restrictions: Restrictions.
* resume execution: Ignore ~C.
* return code: Return Code.
* stackpointer: Restrictions.
* switch to user mode: Restrictions.
* terminate handler: Intro.
* terminate vector: Top.
* test return code: Return Code.
Tag table:
Node: Intro184
Node: Top619
Node: Actions1810
Node: Call3154
Node: Installation3484
Node: Restrictions4139
Node: Return Code6592
Node: Ignore ~C7771
Node: Concept Index8674
End tag table
--
Mail: Edgar R\"oder E-Mail: roeder@cs.uni-sb.de
Liesbet-Dill-Stra\ss e 3
D-6602 Dudweiler -o- -o-
W-Germany ~
Phone: 06897/74643 '---'
------------------------------
Date: 4 Jan 90 14:08:30 GMT
From: mcsun!hp4nl!nikhefh!n62@uunet.uu.net (Klamer Schutte)
Subject: Commandline length?
Message-ID: <711@nikhefh.nikhef.nl>
(Please note: i missed the original article -- please don't flame if
i miss the point which the original author meant!)
In article <1176@pcsbst.UUCP> roland@cochise writes:
>joep@tnosoes.UUCP (Joep Mathijssen) writes:
>
>>Using Gulam and make, I want to link a program using TURBO-C.
>>But there are so much .O-files that must be linked, that my list of
>>files is not processed correctly. I think the commandline is limited to
>>only 80 characters. It this a ST- or Gulam-limit?
>
>Don't know about possible Gulam limits, but there IS a TOS-limit of
>about 125 characters. There is an official work-around, but I wouldn't
>expect any program to support it (yet).
>
the MWC compiler did work around this TOS 'bug'. This worked in with the
GP-Shell (part of the CRAFT package) and probably also with MSH and gulam.
The TurboC linker doesn't like these long command lines. Neither can it be
told how it understands these :-(.
What can be done is to give the TurboC linker a file describing what to link.
I have written a shell script (actually, a function, but these are not available
under gulam) which does translate a line like
link -o my_prog.ttp main.o aap.o noot.o mies.o -l tos -l flt -l wim
to a file like:
a:\lib\startup.o
-O=my_prog.ttp
main.o
aap.o
noot.o
mies.o
a:\lib\tctoslib.lib
a:\lib\tcfltlib.lib
a:\lib\tcwimlib.lib
a:\lib\tcstdlib.lib
where aap, noot, mies, wim are dutch equivalents for foo, bar etc.
Not having this script on-line i can't help directly; but everybody should
be able to construct such a shell script. (Or write a C program; but make this
C program accept a long commandline! (by using sobozon or MWC C.))
Klamer.
--
________________________________________________________________________________
( Currently unemployed )
Klamer Schutte mcvax!nikhefh!?n62,Schutte? ?Schutte,n62?@nikhef.nl
------------------------------
Date: 4 Jan 90 21:40:37 GMT
From: milton!blake!ramsiri@beaver.cs.washington.edu (Enartloc Nhoj)
Subject: HARD DRIVE WOES
Message-ID: <5222@blake.acs.washington.edu>
In article <900103.10572140.037876@SFA.CP6> Z4648252@SFAUSTIN.BITNET (Z4648252)
writes:
>Enartloc Nhoj writes of drive problems, Howard Johnson offers some
>wise advise:
>
>> Symptoms: Occasionally... and sometimes frequently,
>> my Quantum drive slows down and then comes
>> back up. When it slows i obviously can't
>> read or write to the drive.
>>
>>So the problem is not intermittent... Therefore, it will be hard to
>>isolate it and make if fail for a technician. Anybody out there
>>ever have similar problems?
>
> Howard Johnson responds:
>
>
>>My guess is that the ability to read is failing on your servo track.
>>This surface is used to control speed and bit rate.
>>BACK UP YOUR DRIVE! IT WILL SOON BE DEAD!
>
> One suggestion from my own "Dumb Larry Experience" is to go ahead
>and FIRST try some maintenance before attempting any backups!!! In
> Do some hardware maintenance: cleaning and possible connector
>replacement first.
>
>Larry Rymal: |East Texas Atari 68NNNers| <Z4648252@SFAUSTIN.BITNET>
First.. THANKS to all of you who have offered me advice.
I am very appreciative and grateful.
Unfortunately, Larry, i already mailed my drive off to MacLand
in Tempe before reading your article... here's what i have
learned in the past few days about certain Quantum drives:
My dealer tech had heard about a bunch of quantums at Boeing that
were sent back due to some "oil" leaking on to the media and causing
the heads to stick.
He wasn't any more specific than that as he had heard this idea
from someone who heard something... etc...
I called the techs at MacLand.. who, by the way, are incredibly
helpful and very willing to listen... the tech there, Jay Denton,
thought it might be the power supply... but, as Howard told me, it
might also be in the servo track or motor...
I called the Quantum rep... he gave me several possible diagnoses:
Power supply.. any deviation of .6 volts off the 12 volt line or the
5 volt line will cause the drive to power down.. not always to a
full stop..
He also described a problem with some "fluid"... had never heard
of the "oil" scenario nor of the "recall"...
Talked to a friend in Boston who immediately knew what i was
talking about.. had heard of the Quantum 80 problems people
were having..
Called MacLand again and talked with Jay.. he knew about the
"oil" "fluid" "lubricant" problem.. it is documented by Quantum,
and a chip fix is already available.. also.. the newer drives
have the chip on the drive:
The FLUID they are all talking about is the lubricant in the
sealed cylinder that houses the actuator arm for the heads.
Apparently, under dusty or humid conditions (even though
it is sealed) the lubricant gets globby or ceases to function
properly.. and thereby does not allow the heads to move
where and when they want to.... the solution is a chip
that forces a random seek across the plates when the drive
senses inactivity after a period of x minutes.
Supposedly, there's a 24 hour turn-around time.. so i should
be getting the chip added to my drive and all will be ok.
In the meantime, i have cleaned the dust out of my case and
will heed Larry's advice and maintain the contacts he was
mentioning above...
-kevin
ramsiri@blake.acs.washington.edu
------------------------------
Date: 4 Jan 90 11:51:50 GMT
From: mcsun!unido!laura!klute%trillian@uunet.uu.net
Subject: LHARC takes over? Sure hope not!
Message-ID: <1866@laura.UUCP>
Path: trillian
!klute
In article <1363@atha.AthabascaU.CA> rwa@cs.AthabascaU.CA (Ross Alexander)
writes:
>Arcgsh is the best reason I have ever had to install a shell (gulam,
>msh, any keyboard oriented line-at-a-time shell at all). Yes, I was
>using 2.1 and IMHO it's at least 5 times as much work to use as the
>raw commands themselves. Faugh!
Depends on what you like and what you do not like. Surely
Arcgsh is nothing for people who like command line shells and
are able to remember all the options a program has, and
especially Zoo has *many* of them.
Arcgsh was designed for people who 1) like GEM or 2) do not
want to remember all commands and options of Zoo, Arc etc. in
order to keep their heads free for more important things.
If you like to use Arcgsh in general but do not like details of
user guiding please mail me you suggestions!
Dipl.-Inform. Rainer Klute klute@heike.informatik.uni-dortmund.de
Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet
Postfach 500500 |)|/ ...uunet!mcvax!unido!klute
D-4600 Dortmund 50 |\|\ Tel.: +49 231 755-4663
------------------------------
Date: 4 Jan 90 19:46:25 GMT
From: cs.utexas.edu!asuvax!mcdphx!hrc!force!covertr@tut.cis.ohio-state.edu
(Richard E. Covert)
Subject: PageStream fonts
Message-ID: <47d6aeaf.14a1f@force.UUCP>
In article <1990Jan1.193559.24673@cs.dal.ca>, silvert@cs.dal.ca (Bill Silvert)
writes:
> I finally have a version of PageStream (1.8) which is stable enough to
> use, but among the many problems I am having, the fonts are weird. Tyme
> and Helv work OK, but Saturn and Hudson, despite the presence of printer
> files for these fonts, do not print correctly -- many of the letters
> appear only in outline form (i e and x in Saturn, about half the letters
> in Hudson). I don't use these fonts very much, but it is annoying.
>
.
.
. stuff deleted
.
.
>
> with each new release. Do the new versions come with a up-to-date manual?
>
> --
> Bill Silvert, Habitat Ecology Division.
Bill, our PHAST Times newsletter is produced using PageStream 1.8
and printed on a SLM804 laser printer (the SLM804 is used at Computer
Works, our local Phoenix area ST store). Our PHAST editor is a guy named Jim
Kehoe
who is very happy with version 1.8.
As far as a new manual is concerned if you would call Softlogik I believe that
you would hear that a new manual is available. I read a message on GEnie to
the effect that users who ordered the $25 upgrade to PgS 1.8 got a new
manual. I didn't know that when I sent in my $10 upgrade or I would have
sent for the $25 upgrade.
In any case there is plenty of help for you if you can get a GEnie account.
Good luck with PgS 1.8
--
Richard E. Covert, Lead Engineer of Software Tools Group
AG Communications Systems, Phoenix AZ (602) - 581-4652
TCP/IP: covertr@gtephx
UUCP: ?ncar!noao!asuvax | uunet!zardoz!hrc | att?!gtephx!covertr
------------------------------
Date: 4 Jan 90 21:19:52 GMT
From: yacht.cis.ohio-state.edu!thamer@tut.cis.ohio-state.edu (Mustafa Thamer)
Subject: too late for Lynx ...
Message-ID: <75298@tut.cis.ohio-state.edu>
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 ?
-=-
"Two days ago I saw a vehicle that'd haul that tanker.
You wanna get out of here; you talk to me." Max - The Road Warrior
------------------------------
End of INFO-ATARI16 Digest V90 Issue #11
****************************************
