HDTenEightyP/NetNews huggingface dataset:
From: ssw@aber.ac.uk (Simon the Loony)
Newsgroups: comp.sys.atari.st.tech
Subject: Using Setexec() [a bit of help needed]
Keywords: Setexec(), BIOS, vectors, AAARRRGGGGHHHH!
Date: 17 Aug 92 08:30:05 GMT
Organization: Department of Physics, University of Wales, Aberystwyth

Greetings,
	I am currently writing a little program in C which requires that 
certain errors, notably bus and address errors should be trapped. According to
my copy of ``Internals'', Setexec() (BIOS function 5) will do just that and is
defined thus :		long Setexec(exec_no, vector)
			int	exec_no ;
			long	vector ;

Where vector is the address of the routine to be executed when a certain error
occurs, and exec_no is the execution number.

My program is (roughly) of the following form :

main(argc,argv)
int	argc ;
char	**argv;
{
	:
	assorted code
	:
}

BusError()	/* This should be executed when a bus-error occurs	*/
{
	printf("Bus Error!\n") ;	
}

AddressError()	/* This should be executed when an address error occurs	*/
{
	printf("Address Error!\n") ;	
}

The question is, what do I pass to Setexec() for the addresses of each of these
functions? According to my book on C, just taking the address of a function is
not allowed.....

Help would be greatly appreciated.

Thanx in advance,

Simon.

-- .sig? I don't need no steenking .sig! :-)
Newsgroups: comp.sys.atari.st.tech
From: r0mill01@ulkyvx.louisville.edu (Robert Delius Royar)
Subject: Re: Falcon 030 ?  nah wait the 040 !
Reply-To: r0mill01@ulkyvx.louisville.edu
Organization: University of Louisville
Date: Fri, 21 Aug 1992 10:15:07 GMT

In article <1992Aug21.083142.16355@prl.dec.com>, amos@prl.dec.com (Samos) writes:
>I think there is a large step between the 68030 and the 040, 
>the programmation is being more interesting, and I even could
>say that the 040 is a microprocessor half CISC half RISC..
>and to buy a falcon at 16Mhz 030 is to buy an 'under-TT device'..
>so wait for the high technology, and buy the falcon 040 !
>
>Samos.
>
The Mac Quadra uses a 40, and I understood that everything has to be 
rewritten to run on it.  Doesn't the 40 have some very different ways of 
doing things, and aren't some instructions just gone and others added?  
Wouldn't that mean the 40 machine would be a "from-the-ground-up" kind of 
thing like the quadra is supposed to be?

Just wondering.

r. royar
Newsgroups: comp.sys.atari.st.tech
From: cbbrowne@csi.uottawa.ca (Christopher Browne)
Subject: Opening aux1
Organization: Dept. of Computer Science, University of Ottawa
Date: Sat, 15 Aug 92 02:15:12 GMT


Here's a possibly dumb question:

How do I open a file to aux (a.k.a. modem1, a.k.a. com1: ...)?

I've compiled C-Kermit, with only minor difficulties, and it seems to
work, up to the point at which I try to actually USE it to do file
transmissions.

It requests that I "set line", which is sensible enough.

If I'm running MiNT, I enter /dev/aux or /dev/modem1.  It complains
about being unable to acquire a "lock" on the device, but life
continues.  Unfortunately, data doesn't get transmitted.

If I'm NOT running MiNT, there's no sensible way to actually NAME the
device.  In the good 'ol 8 bit days, you could ALWAYS open a file to
ANY device, whether that be D1:, D2:, for disk drives, or E: for the
"line editor" device.  On MS-DOS machines, file names like lpt1: or
com1: get interpreted as devices; I don't seem to be able to do this
from either tcsh or mupfel (or from inside C-Kermit).  Do I need to
hack up the code in order to get this running?  Or am I missing the
"magic name?"

-- 
Christopher Browne
cbbrowne@csi.uottawa.ca
University of Ottawa
Master of System Science Program
From: eker@loria.crin.fr (Steven Eker)
Newsgroups: comp.sys.atari.st.tech
Subject: why does rsrc_load() always rev up the floppy drive?
Date: 19 Aug 92 18:44:06 GMT
Organization: CRIN (CNRS) Nancy - INRIA Lorraine


I notice that when I'm loading resources from a RAM disk the floppy always
revs ups. Am I doing something wrong or is AES just dumb?

TIA

Steven
From: JJL101@psuvm.psu.edu (J.J. Lehett)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Continuing 1.44 Drive Woes
Date: 19 Aug 92 22:23:00 GMT
 <92225.143240JJL101@psuvm.psu.edu> <l95eruINNb3n@aludra.usc.edu>
Organization: Penn State University

In article <l95eruINNb3n@aludra.usc.edu>, baffoni@aludra.usc.edu (Juxtaposer)
says:
>
>        Hi,
>
>        I've been watching the problems with the 1.44 drive in a MSTe, and
>I was wondering if anyone tried replacing the floppy drive, and if they
>tried the connecting-all-grounds-to-earth-ground trick that someone posted?
>
>        -Mike
>
>

      Trying a different mech is my next step, since it always err's on track
45 while formatting any HD disk, this may be from a defect in the 'head rails'\
of the drive(?)  Now to look for a place that sells these drives with the
best price (or will any 1.44 drive work with correct jumpers?).
------------------
J.J. Lehett     : Atari's, puzzles, games, chaos, fractals, math....

  - jjl101@psuvm.psu.edu                 Penn State CAC
  - aa400@cleveland.freenet.edu          Atari 16/32 bit SIG Sysop
  GEnie: J.LEHETT2                       Delphi: JLEHETT@delphi.com
Newsgroups: comp.sys.atari.st.tech
From: ilepore@nyx.cs.du.edu (Ian Lepore)
Subject: Re: Trapping ^C
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Sat, 15 Aug 92 22:00:08 GMT

Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.

 > Under MiNT... Psignal(SIGINT, SIG_IGN)
 
 Yeah ::sigh:: unfortunately what I'm doing is trying to build a signal()
system for dlibs, for folks not running under MiNT.
 
 > have execv() remore the 0x0102 vector
 
 Aw sh*t you're kidding!  I hadn't checked it, I just assumed GEMDOS would
be bright enough to manage the pterm vector on a per-process basis.
 
 Actually, I had about given up on implementing SIGINT at all, but I was 
gonna implement the ANSI-defined SIGTERM and tie it to the termination 
vector.  I was also going to use the termination vector to clean up hooks
in other vectors (for handling SIGSEGV and stuff).  It looks like this is
gonna get to be more comlex than I had ever imagined.  No wonder the 
original dlibs didn't have a signal() system in it.


--
- Ian
(void *) where prohibited by law

Newsgroups: comp.sys.atari.st.tech
From: mintha@geog.ubc.ca (Jim Mintha)
Subject: FAQ
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Fri, 21 Aug 1992 09:31:56 GMT

If anyone is wondering what has become of the comp.sys.atari.st.tech
FAQ, its still alive.  I've been fairly busy, and everytime it gets
close to completion, somebody comes out with a new version of 
software (i.e. Mint 0.95), so I'll hopefully have something next week.

If any of you have any enlightening experiences with the new MiNT, 
I'd much appreciate hearing from you, especially if your running
MGR as I don't.

Jim


--
Jim Mintha                       Home: (604) 467-2148
mintha@geog.ubc.ca               Work: (604) 465-5074
From: rgoseweh@digi.lonestar.org (Roy Gosewehr)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: is it possible to change the font in hi res?
Summary: The WARP 9 Acc can.
Keywords: mono, font, hi-res, warp9, acc
Date: 20 Aug 92 14:17:53 GMT
Organization: DSC Communications Corp, Plano, TX

In article <Bt8vvD.4G@acsu.buffalo.edu> ugafence@ubvmsd.cc.buffalo.edu (UB FENCING CLUB) writes:
>
>  I'm fond of my mono monitor, BUT, the font sucks.  Plain and simple.  Is
>there any way to change it to something a little bit smoother around the 
>corners?  I'm primarily using wordwriter & flash.

The Warp 9 Control Panel (accessory) allows you to load any font you
want (and it comes with a lot of them).  I just received my Warp 9 the
other day and happened to be playing with this last night.  (Actually,
the 3270 font looks nice :-)  But since I just started using this
package (used to use Turbo ST), I can't point out any caveats, etc..

Good luck.

Roy C. Gosewehr
-- 
 ------------------------------------------------------------------------
| GEnie: R.C.Gosewehr | rgoseweh@digi.lonestar.org | uunet!digi!rgoseweh |
 ------------------------------------------------------------------------
From: Bob_BobR_Retelle@cup.portal.com
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon 030 ?  nah wait the 040 !
Date: Sat, 22 Aug 92 00:42:23 PDT
Organization: The Portal System (TM)
  <BtC3yq.552@acsu.buffalo.edu>

You can always just wait for the "next generation" of computers
or the next generation beyond that...
 
Or you can have today's computer and use it, while everyone else
waits (and waits, and waits) for the "next generation"...
 
BobR
From: jvt@its.bt.co.uk (John Trickey)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Null arguments with ARGV
Date: 12 Aug 92 16:30:35 GMT
Organization: BT Group Computing Unix Support, Birmingham, UK

I have been following this thread with more than a little bemusement at
the intricasies of passing args through TOS. Probably the way to have
avoided all of this would have stored the *argv[] array in the parent
and passed a pointer to the child, yes in the environment if you have
to!

However, we do not have a clean slate so compatibility must be
paramount. First we must consider that old applications being passed a
null arg will fail anyway. That means we only need consider new
applications as long as we leave ARGV untouched.

So now we must mandate a new variable (say ARGN --- call it what you
want) which will hold pointers to the null args. 

> app arg1 "" arg3 "" arg5

wil produce
ARGN=2,4
ARGV=\bin\app\0arg1\0arg3\0arg5\0\0

All we are left with is the "validity of ARGN" problem. Well, since GEM
only copies the environment up to the first \0\0, then ARGV **must** be
the last entry in the environment for this mechanism to work. Similary
for the exec mechanism to work, ARGN will be the penultimate entry and
for it to be valid
	(getenv(ARGV) == (getenv(ARGN)+strlen(getenv(ARGN))+6))
Now this is not perfect as a non conforming application that execs could
pass on ARGN and ARGV in that configuration and so lead to chaos.
Conforming applications could remove the ARGN value after use on startup
which would limit the damage but its only really a partial cure.

Umm, coming back to the conclusion that all existing applications could
potentially break, then there is little mileage in trying to bend the
existing method to cope so why not consider a new method that will run
alongside the existing argv? If the *argv[] array was stored in the
child and pointed to the strings (or WHY) in the exec call, the address
of argv could be passed as a hex represented string in the environment
along with the current ARGV. The cost penalty is low at 4n + 4 bytes +
new env variable. This should be alright as long as a child does not
outlive its parent (MiNT etc?).

Hope I've provided some food for thought.

John
-- 
John Trickey <jvt@its.bt.co.uk>
       Voice: +44 21 524 8200     Fax: +44 21 553 6120
(Home) <john@its.bt.co.uk> || <john@g4rev.ampr.org> || G4REV @ GB7FLG
       +44 21 308 8892
Newsgroups: comp.sys.atari.st.tech
From: ilepore@nyx.cs.du.edu (Ian Lepore)
Subject: Re: Help with prog. Execption handlers on ST
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Fri, 21 Aug 92 18:58:09 GMT

Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.



> * this is the exception processing routine
> BusErrHandler   move.b	#$FF,BusErrFlag	* set flag for Bus error
>                 rte
>*** this is where i get "address errors" when I try to execute a
>    RTE from the exeception handler.

 For exceptions 2 & 3, there's an extra 8 bytes of info on the stack on
entry to the exception handler.  The extra bytes provide info on what type
of memory access was happening (instruction/data fetch, etc).  You have to
clean them off the stack before you can RTE.  Another issue, one I'm not
as familiar with, is that the return address on the stack may point into
the middle of the instruction that failed, depending on what type of 
failure occurred.  Logic for returning to the next instruction after the
failure would be complex for a general solution, but I think you can cheat,
since you know the exact place you're expecting the failure, and the exact
instruction that you expect to fail.
 
 Try something like this:
 
  BusErrHandler:   move.b   #$FF,BusErrFlag  ; set local flag
                   addq.l   #8,sp            ; clean extra info off stack
                   addq.l   #nnnn,2(sp)      ; adjust return address
                   rte                       ; return from exception

 You'll need to do a little trial-and-error to get the right value for
#nnnn for adjusting the return address.  (Or, get better info from someone
who knows this stuff better than I do.  My exception-handling experience
has never included returning to the fail code in this way.)
 
 One other issue is processor type:  I have this vague notion that chips
upwards in the 68k family may put even more than 8 bytes of extra info
on the stack -- you may need a couple different exception handlers, and 
install the right one for the chip type you're running on.



--
- Ian
(void *) where prohibited by law
From: warwick@cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Sprite code (Re: Second&last time: Hacking Contest)
Date: 20 Aug 92 01:48:51 GMT
Reply-To: warwick@cs.uq.oz.au

eker@loria.crin.fr (Steven Eker) writes:
>warwick@cs.uq.oz.au (Warwick Allison) writes:

>This is fine. but is a previous post you mentioned that sprites could
>be updated at different speeds which made me think you were using some
>arbitrary interleaving of draws & wipes.  

Oops, poor qualification by me.  Obviously, it is DAMNED HARD to give
arbitrary sprite priorities, AND arbitrary update rates.  (Although
possible - using full-screen masks, which are also useful for clipping,
moving "behind" playfield objects, etc.)  If I even need such Sprite
classes, I'll have my head examined.

>Maybe, maybe not - it depends on your sprite drawing method. The code
>I originally posted only read the screen implicity with 
>       or.w    d0,(a0)+ 

Hardly useful for anything but UNMASKED single-bitplane graphics, which 
is next-to-useless (at he very least, you usually want to have black
and white sprites (like the ST mouse pointer), rather than just black
sprites (like the Sun SunView mouse pointer)).  Of course, in the 
interests of competition, anything is "useful" :-).

>BTW the code I posted is (slightly) faster than the 32x32 sprite code in
>your GNUchess port even under the most pessimistic assumptions (you did a great
>job on the port though...).

<delight> if you can mail me code-for-code patches, I'll put them into
my library (which will be free-to-all one of these days).

>|> Which reminds me - was this a competition?  I wrote some VERY fast 
>|> sprite routines in a furious discussion with Dave B. - 60 or so
>|> single-bitplane 16x16 sprites at arbitrary positions on an arbitrary
>|> background was I believe my limit...

>No, it was just a sugestion for a better competition goal than the
>rather pointless TOS hacking in Nat!'s competion.  60 sprites at 50Hz
>is quite amazing on a non-blitter ST. At 25Hz rather less so.  

Actually, I think it was more like 50 at 72Hz (ie. mono).

>Still I can't resist the challenge...

You didn't post performance stats!  How well does it BURN?


Let's make some categories:

	1. Preshifted / Unshifted
	2. 16x16 / 32x32
	3. Masked / Unmasked       (ie. black&white / black)

>Come to think of it, if the sprites are only one pixel deep why not preshift
>the blighters???

Yep.  One better:  with unmasked sprite, why even HAVE sprite data?
it uses only 100% more RAM to have the sprite data be the CODE ITSELF,
ie. automatically generate the

	orl   #....,(a0)     (3 words)
	addl  d0,a0          (1 word)

instructions from the 2-word sprite-data!

(Of course, this is only acceptable for HACK CONTESTS.  Anyone who seriously
considers this a "programming technique" is a beauxault)

--
Warwick
--
  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
 /     * <-- Computer Science Department,  /  
 \_.-._/     University of Queensland,    /      void (if removed)
      v      Brisbane, Australia.        /  
Newsgroups: comp.sys.atari.st.tech
From: 7103_2622@uwovax.uwo.ca (Eric Smith)
Subject: Re: Trapping ^C
Organization: University of Western Ont, London
Date: Fri, 14 Aug 1992 14:39:38 GMT

In article <1992Aug14.071027.24659@mnemosyne.cs.du.edu>, ilepore@nyx.cs.du.edu (Ian Lepore) writes:
>  What's a good method of trapping a ^C from within a program and ignoring
> it?

Psignal(SIGINT, SIG_IGN)...

...oops; you're not using MiNT? Well, then it gets a lot harder :-).

Actually, I'm afraid there isn't any very good way to catch ^C in the
general case. If you use the terminate handler, not only do you have to
worry about Pterm0() and similar kinds of exits, but you also have to
watch out for Pexec() (i.e. the program terminating may not be the one
that you want to prevent from terminating).

The "best" way to do this under TOS, I think, is to not allow ^C to
terminate programs at all -- do all I/O in raw mode (e.g. through the
BIOS) and look for ^C's yourself. That's what we did in the original
gcc library.

Next best is to require people to exit using exit() and unhook the 0x0102
vector there; also, in execv() unhook the vector before running a new
program. You said this wasn't an option, but perhaps you could make it
an option by specifying this in the docs for your library.

Last best (IMO) is to catch trap #1 and look for Pterm() calls, as well
as hooking into the 0x0102 terminate vector. This may cause problems
under MultiTOS or MiNT, though, if other programs are running at the same
time.
--
Eric R. Smith                     email:
Dept. of Mathematics            eric.smith@uwo.ca
University of Western Ontario
From: Julian_Reschke@ms.maus.de (Julian Reschke)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Opening aux1
Date: 16 Aug 92 11:32:00 GMT
Article-I.D.: MS.A46017
Organization: MausNet
X-Gateway: MausGate/News 1.11

Christopher Browne (cbbrowne@csi.uottawa.ca) wrote:
>How do I open a file to aux (a.k.a. modem1, a.k.a. com1: ...)?

Try "AUX:".
Newsgroups: comp.sys.atari.st.tech
From: cbbrowne@csi.uottawa.ca (Christopher Browne)
Subject: VT102 tip for MiNT?
Organization: Dept. of Computer Science, University of Ottawa
Date: Thu, 13 Aug 92 05:05:11 GMT

I'm playing with Howard Chu's tip program (is that short for "terminal
interface program?"  It would make sense...), and have a quick question.

It uses the "standard" Atari implementation of vt52-like features.  Is
there something out there that will do vt102?  I'd really like to be able
to use Emacs remotely, and for things to have "inverse" mode, and all the
other "good" stuff that vt1xx modes give you (partial screen scrolls, I
believe?)

I can live with Uniterm...  I've been enjoying it for a LONG time...
Any new version of tip won't likely have Kermit, which would be a big
minus as compared to Uniterm.

But it would sure be nice to have an in-the-window terminal under MiNT
that does a little better than vt52...

Now, for a totally unrelated question:  Has anybody seen a standalone
Kermit for the ST?  Other than the desk accessory, which does NOT work
very well?  If there was source code for the UNIX version kicking
around, we might be able to have C-Kermit running, which would be
pretty neat!
-- 
Christopher Browne
cbbrowne@csi.uottawa.ca
University of Ottawa
Master of System Science Program
Newsgroups: comp.sys.atari.st.tech
From: heidelj@alleg.edu (Jason Heideloff)
Subject: Re: Atari Dealers & SM147
Organization: Allegheny College
Date: Fri, 14 Aug 1992 12:48:57 GMT

Good to see you on the net Rick!

Jason
From: vicb@clark.edu (Victor Bruhn)
Newsgroups: comp.sys.atari.st.tech
Subject: DMA Sound playing
Date: 20 Aug 92 16:10:37 GMT
Article-I.D.: clark.1992Aug20.161037.19742
Distribution: na
Organization: Clark College, Vancouver, Wa.  USA

Can anyone tell me any information about playing sound samples on an STe 
through the DMA?  Information for C or Assembly language preferred.  It must 
be a pretty well guarded secret, as I can't seem to find any text files
anywhere on this subject.  HELP!!!

Victor Bruhn
vicb@clark.edu
From: M.P.Wood@lut.ac.uk (Michael Wood)
Newsgroups: comp.sys.atari.st.tech
Subject: MFM RLL drives on Ataris
Keywords: disk mfm rll
Date: 19 Aug 92 09:48:32 GMT
Reply-To: M.P.Wood@lut.ac.uk (Michael Wood)
Organization: Loughborough University, UK.


I saw the recent topic of PC disk for ataris.
I was told by many vendors in the UK that it was not possible.

Please could the relavent people post their replies as I would
love to be able to connect my RLL/MFM Priam 519 drive up.

Thanks,
	Mike.
Newsgroups: comp.sys.atari.st.tech
From: hunt@hal.gnu.ai.mit.edu (Hunt)
Subject: Re: cts/rts fix for tos1.0?
Keywords: modem
Organization: /etc/organization
Date: Wed, 19 Aug 1992 19:54:59 GMT

In article <1992Aug19.091600.29603@jet.uk> pjc@jet.uk (Peter J Card) writes:
>The title says it all. I have a v32bis modem and an old tos1.0 ST.
>Which cts/rts patch program is best used with this pairing. Am I
>correct in thinking that the ST cannot run its rs232 port above 9600
>baud under any circumstances?
>
>Is hardware flow control properly implemented on the Falcon, I wonder?
>

I don't know about anyone else, but I have an old 1040ST with v1.0 roms,
and I have done file transfers at 19.2K with no problems whatsoever.
This was using one of the "rz" programs from a commandline.
It got decent CPS as well. (don't remember exactly, was a while ago.)
Tad
From: mangane@SOLEIL.matra-espace.fr (Laurent 7557)
Newsgroups: comp.sys.atari.st.tech
Subject: Use of SC1424 with another computer
Date: 19 Aug 92 06:59:43 GMT


I would like to use my SC1424 to receive PERITEL signal output
from another computer's video adapter. Who has ever succeed in such
a HARD challenge (because I am sure I have to use my solding-iron) ?
I may insist on THIS type of signal which level is around 12 V and
not TTL in order to avoid answers from PC and compatibles users who
can easily use the SC1424 as a CGA monitor.

PLEASE, ANSWER BY E-MAIL AS I CANNOT READ NEWS.

My addresses are: mangane@soleil.matra-espace.fr or
		  mangane@mms.matra-espace.fr
If you can use X-400, you can also answer to
S=MANGANE ; P=MATES400 ; C=FR.


Thanks in advance for your help.

;;; Laurent MANGANE