HDTenEightyP/NetNews huggingface dataset:
From: ralph@laas.fr (Ralph P. Sobek)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Floppy Disk Fats ..... In the beginning......
Date: 9 Oct 92 13:22:39 GMT
Organization: LAAS-CNRS France
In-reply-to: sheppard_r@kosmos.wcc.govt.nz's message of 4 Oct 92 09:11:05 GMT

>>>>> Regarding Re: Floppy Disk Fats ..... In the beginning......;
>>>>> sheppard_r@kosmos.wcc.govt.nz adds:

RS> Well you did, you should have know that Atari is a dumb company..!!.

RS> They have also left it in the newer Tos's as they now think that its a feature,
RS> yes a feature to show the world how dumb Atari is... 

Since no one has mentioned the obvious I'll do it:  there are many
FORMATTERS out there that format diskettes putting in 3 sector FATs!
F_COPY21.PRG or FORMAT.PRG.  Both are decent German products!

--
Ralph P. Sobek			  Disclaimer: The above ruminations are my own.
Ralph.Sobek@laas.fr			   Addresses are ordered by importance.
ralph@laas.fr						If all else fails, try:
ralph@laas.uucp, or ...!uunet!laas!ralph	      sobek@eclair.Berkeley.EDU
Phone: (+33-)61-33-62-66  FAX-1: (+33-)61-33-64-55  FAX-2: (+33-)61-55-35-77
===============================================================================
Got a Mega 4 ST. Wish it was a Mega STe? :-|  Do I *really* want a Falcon/Next?
From: Peter.Kocourek@p13.f112.n100.z60.wlink.nl (Peter Kocourek)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: What makes the Screen Scroll *UP* ???
Date: Fri, 09 Oct 1992 20:31:44 -0100

In a message of <09 Oct 92  01:27:14>, Thomas Campbell (60:100/1) writes:

 TC> What makes the screen scroll up?  I"ve been working on this program
 TC> and I want to have an input line on line 22-23 while still
 TC> accepting input on line 20 and above.  (It's a modem program)  Do I
 TC> have to do this thru screen flipping or what? I"m a pretty

You do this by using GEM, and doing all your input and output in GEM windows.

 TC> experienced programmer but, this has completely stumped me.  (An easy
 TC> way to do it)  I remember with the *old* Atari 800.. :) that there
 TC> was a special graphics window that I could have used but, how do I do
 TC> this now?

You don't. There is a trick to stop part of the screen scrolling up, but it certainly won't work with MultiTOS. So the best (if perhaps unhelpful) advice I can give you is: don't do it.


YHS:QSI!
From: grier@bnr.ca (Brian Grier)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: XBIOS function to set floopy seek rate
Date: 7 Oct 92 17:29:44 GMT
Organization: BNR


> The ST boots up on the fastest speed it can effectively use. Slowing it down
> is pointless (Unless you are using some *OLD* & *SLOW* drive), and making it
> faster (Only 1 step higher is available) can only result in data loss.
> Really, leave this one alone, it's not worth it (Why did atari put it there
> anyways ???)


It's in there because the 5.25" drives require more time for
the head to move one track. I agree leave it alone for 3.5" drives.
However it must be set to 6ms for the 5.25" drives

Brian
a.k.a.
Wyle E. Coyote
 
Newsgroups: comp.sys.atari.st.tech
From: hjv@phil.ruu.nl (Hendrik Jan Veenstra)
Subject: Re: WF_NEWDESK
Keywords: 1
Organization: Department of Philosophy, University of Utrecht, The Netherlands
Date: Tue, 13 Oct 1992 14:03:52 GMT

grellier@ufrima.imag.fr (GRELLIER thierry) writes:


>	I've tried to define a new desk background, but it
>	has not given what I expected to.
>	My new background (just a g_box with a standart pattern)
>	was actually redrawn but it covers the drives and trash
>	icons. And when I select blindly one icon, it draws
>	the icon in the old desk background.
>	So my question is : could someone send me a tiny example
>	to show me how using wind_set(0, WF_NEWDESK, ...) in
>	C or post it as an answers to my article.

The icons (and other objects) are children of the root -i.e. the desktop-box.
So when you install a plain G_BOX as desktop, the icons won't be drawn,
since they're not childeren of your g_box.
I don't know how to use WF_NEWDESK when replacing the normal desktop - I
don't even know if this can be done in a simple way. Using WF_NEWDESK to
install a custom-made desktop in your own programs is rather straightforward
though.

--
Hendrik Jan Veenstra  |  hjv@phil.ruu.nl  |   You look for your dreams in
Dept. of Philosophy   |                   |   heaven, but what the hell are
University of Utrecht |                   |   you supposed to do when they
The Netherlands       |                   |   come true...?
Xref: sparky comp.sys.atari.st.tech:5184 comp.sys.atari.st:15180
From: ekrimen@wet.UUCP (Ed Krimen)
Newsgroups: comp.sys.atari.st.tech,comp.sys.atari.st
Subject: Re: Falcon and Hard Drives
Date: 15 Oct 92 03:54:49 GMT
Followup-To: comp.sys.atari.st.tech
Organization: Wetware Diversions, San Francisco

In article <719058799.8966@minster.york.ac.uk> andrew@minster.york.ac.uk writes:
>I read an advert yesterday claiming that the internal hard disk interface of
>the new Falcon030 is a IDE standard yet the external drives can run off a
>SCSI-2 bus.  Is this true???
>

Yes.

>If it is then why do Gasteiner(sp?) and ultimately Atari hope to sell the
>Falcon with 64Mb HD for 400 pounds more than the machine without HD.  One can
>easily buy a 100+ Mb HD for less than 200 pounds with an IDE interface.
>Intenal SCSI drives of similar capacity can be bought for less than 300
>pounds.

Keep in mind that the internal IDE drive is 2.5" form-factor, not 3.5".  





-- 
   |||    Ed Krimen
   |||    ekrimen@wet.uucp   Contributing Editor, Atari Explorer Online
  / | \   E.KRIMEN (GEnie)            Vice-President, ABACUS User Group
Newsgroups: comp.sys.atari.st.tech
From: andi@gmd.de (Andreas Rohrschneider)
Subject: TOS 2.06 & OXYD2 -> problems !?
Organization: GMD, Sankt Augustin, Germany
Date: Thu, 8 Oct 1992 10:54:22 GMT


Hi, netters!


After upgrading my old 520 ST+ to 4MB and TOS 2.06 and supplying it with a 
hardware clock, I discovered the following problem with OXYD2: 

When the menu shows up, there is a section in the lowest part of the screen
where you can see some graphic symbols black on white overlaying the menu. When
you start the game, this 'symbol-panel' starts flickering with every movement of
graphic on the screen. 
The game still works, but it's not much fun guessing what's happening below
this 'panel'. The same happens with OXYD and SPACOLA, so it seems to be 
originated in this special kind of software.
Assuming a hardware fault, I went to my local dealer, who had done the upgrade.
He checked everything twice and didn't find any defects. I guess it has 
something to do with the new TOS.

So I decided to post this query to the net. Maybe some of you had similar
problems with this software and know a solution.

Thanx in advance,

Andreas Rohrschneider.

P.S.: STADT, a painting program from Application Systems Heidelberg also doesn't
      run anymore. I only get a messed-up screen and some bombs. Any 
      suggestions ?

--------------------------------------------------------------------------------
Andreas Rohrschneider
GMD - I5.SKS
German National Research Center for Computer Science
Schloss Birlinghoven             		    phone: (+49 2241) 14-2242
D-5205 Sankt Augustin 1, FRG     		    email: rohrschneider@gmd.de 
--------------------------------------------------------------------------------
Newsgroups: comp.sys.atari.st.tech
From: 7103_2622@uwovax.uwo.ca (Eric Smith)
Subject: Re: GCC questions...
Organization: University of Western Ont, London
Date: Thu, 15 Oct 1992 16:06:38 GMT

In article <98545@bu.edu>, anneklin@acs.bu.edu (Patricia Anne) writes:
> Okay, from what I can gather from the READMEs in the recent update2?.zoo files
> from ++jrb and from the docs in the PL 24 MiNT libraries for GCC, the two
> libraries are very close to the same.  However, they're obviously different
> in some respects, and I'm curious as to whether it's "safe" to use the MiNT
> libraries with the C++ libraries that are distributed with ++jrb's libs.

There should be no problems. jrb's code is very clean, and I've tried
to keep the mntlib code similarly clean. The differences are mostly
confined to the lowest level Unix emulation functions (e.g. open(),
read(), write()) and even there the interfaces are the same, it's just
that they do things differently. (For example, mntlib implements symbolic
links by calling the appropriate MiNT functions, gcclib does it with
UNIXMODE.)
--
Eric R. Smith                     email:
Dept. of Mathematics            eric.smith@uwo.ca
University of Western Ontario

Newsgroups: comp.sys.atari.st.tech
From: annius@sif.research.ptt.nl (Annius Groenink)
Subject: Misunderstandings about ACCs and messages
Organization: PTT Research
Date: Tue, 13 Oct 1992 08:46:46 GMT

bpat@cs.mcgill.ca (Patrick BETREMIEUX) writes:

>In article <hjv.718883974@groucho.phil.ruu.nl> hjv@phil.ruu.nl (Hendrik Jan Veenstra) writes:
>>tony@microware.co.uk (Tony Mountifield) writes:
>>
>>Citing the Profibuch (thereby translating a Dutch translation of a German

>>book in English... :)
>>
>>WM_TOPPED (21): This window becomes the active window.
>>	mbuf[3]: window handle

>The previously active window was deleted. you cannot avoid it, tou're on top
>whether you like it or not.

Not true. You get WM_TOPPED when the user wishes to top a window. My Edith
doesn't top background windows if the top dialog has to be finished first.

>>WM_NEWTOP (29): The window was activated. Seems to be identical with
>>                WM_TOPPED (21) !
>>	mbuf[3]: window handle

>the user clicked on you. do you want to be nice and go on top, or tell him to
>forget it because you're comfy where you are?

Not so. This one is not implemented in Atari GEMs. I assume this message was
actually meant to give ALL applications a sign if ANY window was ACTUALLY
topped by means of wind_set(w_h,WF_TOP,w_h). Really, it's too bad something
like that doesn't exist.

  I never heard of

>>WM_UNTOPPED (30): The window will be inactivated (sp?) in a while. This
>>                message can be used to buffer the contents of the window
>>                somewhere in advance.
>>                Only with GEM >= 2.0!
>>	mbuf[3] window handle.

Now that would be great. You could use that to `backgroundify' your window. But
be cautious! In (not very distant-) future TOSes one can move, slide, close
etc. background windows! Especially the sliders are dodgy and will cause many
programs to write in windows of other applications.

-- 
Annius Victor Groenink      Universiteit Utrecht      PTT Research Leidschendam
Mathematics/Comp. Sc.        avgroeni@cs.ruu.nl       +31 70 3325445 (weekdays)
Atari ST/Music          A.V.Groenink@research.ptt.nl  +31 70 3464732 (evenings)
_____________My opinions are my opinions____________  +31 5700 29396 (weekends)
From: tony@microware.co.uk (Tony Mountifield)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Detecting the closing of an ACC from within an APP
Date: 12 Oct 92 08:30:12 GMT
Organization: Microware Systems (UK) Ltd., Winchester, UK.

In article <hjv.718670793@groucho.phil.ruu.nl> hjv@phil.ruu.nl (Hendrik Jan Veenstra) writes:
> genius@sys6626.bison.mb.ca (Trevor Cordes) writes:
> 
> >How would I go about detecting if an accessory was closed (after it had 
> >been opened, of course) while a GEM application was running?  The message 
> >pipe never seems to return AC_CLOSE (or AC_OPEN), which, as I'm told, are 
> >only received by accessories.  I tried WM_NEWTOP and no go (What the hell 
> >is WM_NEWTOP anyway? Never seems to be sent to my APP at all).  Any 
> >ideas?
> 
> My (not completely blind) guess would be that this is not possible, but I
> could be mistaken (if so, please let someone correct me). According to
> the 'Atari Profibuch' WM_NEWTOP is the same as WM_TOPPED.

No, they are different, but I am given to understand that WM_NEWTOP is
only implemented on newer versions of TOS (1.2? 1.4? ...).

As I understand it, WM_TOPPED is sent to an application to indicate that
one of its windows (ID given) has become the top window, and WM_NEWTOP
is sent to an application when one of its windows stops being the top
window because another window has been topped. In other words, a window
is only on top after getting a WM_TOPPED until it gets a WM_NEWTOP.

Hope this is right - someone correct me it not. I think the information
came from Tim Oren's 17-part Gem class articles, in a Q-and-A section.

Tony.

-- 
Tony Mountifield     (G4CJO)       | Microware Systems (UK) Ltd.
Email:  tony@microware.co.uk       | Colden Common, WINCHESTER, SO21 1TH.
(or:  ...!uknet!mwuk!tony)         | Tel: 0703 601990   Fax: 0703 601991
------------------------------------------------------------------------
** Any opinions are mine, not Microware's - but you knew that anyway. **
------------------------------------------------------------------------
From: warwick@cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Upgrading Megafile 20
Date: 11 Oct 92 08:28:57 GMT
Reply-To: warwick@cs.uq.oz.au

boyd@shmop.cs.fsu.edu (Mickey Boyd) writes:

>rost@rgb.dec.com (My name is Brian Rost) writes:

>>Is it possible to expand a Megafile 20 by simply replacing the 20Mb mechanism
>>with a larger one and reformatting?

>In theory, yes.  However, I would personally recommend getting an ICD host 
>adaptor (to replace Atari's), and a standard SCSI mechanism.  They should 
>fit in the case, and I am sure you will be much happier with the speed and 
>nice software.  Host adaptor should cost about $80, SCSI's are pretty cheap.

I'll second this recommendation.  I think there is a definate limit on the
size you can expand a Megafile 20 to anyway.  And it's much lower than ICD's
2 or so Gigabytes (like probably 90M).


--
Warwick
--
  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
 /     * <-- Computer Science Department,  /  
 \_.-._/     University of Queensland,    /   C references are NULL && void*
      v      Brisbane, Australia.        /
From: mforget@ersys.edmonton.ab.ca (Michel Forget)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: What makes the Screen Scroll *UP* ???
Date: Fri, 09 Oct 92 18:16:24 MDT
Organization: Edmonton Remote Systems #2, Edmonton, AB, Canada

thomasc@ms.uky.edu (Thomas Campbell) writes:

- What makes the screen scroll up?  I"ve been working on this program
- and I want to have an input line on line 22-23 while still accepting
- input on line 20 and above.  (It's a modem program)  Do I have to do
- this thru screen flipping or what? I"m a pretty experienced programmer
- but, this has completely stumped me.  (An easy way to do it)  I remember
- with the *old* Atari 800.. :) that there was a special graphics window
- that I could have used but, how do I do this now?
-
- alex
-

I had this problem as well.  To solve it, you have to use the Line-A variables,
which would make your program TT-unfriendly.  And most likely Falcon-unfriendly
as well.  So if you go ahead, make the status bar optional so that users with
TT systems are not left in the cold.  To actually do it, you:

To further complicate matters, I found that I could not access the Line-A
variables through Personal Pascal so I had to play with the memory locations
themselves, which is not a good thing to do.  Anyway, the WORD located at $2AB2
holds the number of lines that the screen is.  After you get the original
value, subtract one from it, and then put the value back via the poke()
function appropriate to WORD values.  When you want to change the line, simply
add one to the value, poke it, do what you need, subtract one, and poke the
value again.

Keep in mind I have only tested this on TOS 1.4, and it IS NOT GOOD PROGRAMMING
PRACTICE TO BEGIN WITH.  Regardless of how I did it, though, at least you now
know that you need to use Line-A to make the screen shorter.

One user suggested another method, which was to re-write the VT-52 handler that
the computer uses.  This was beyond me, but I was told that there was a much
better (and faster) VT-52 handler at atari.archive (which I have no access to
so I could not verify).

I hope this information helps you out a little.

<<  ------------------------------------------  >>
<<        mforget@ersys.edmonton.ab.ca          >>
<<  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  >>
<<               Michel Forget                  >>
<<   The Key:  Spirit over mind over matter.    >>
<<  ------------------------------------------  >>
From: warwick@cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: VT52 variables? (was: What makes the Screen Scroll *UP* ?)
Date: 14 Oct 92 02:14:24 GMT
Reply-To: warwick@cs.uq.oz.au

mforget@ersys.edmonton.ab.ca (Michel Forget) writes:

>- >the WORD located at $<address deleted>
>- >holds the number of lines that the screen is.

> He disassembled the Bconout() function and traced it to see what it
>was doing.


This is the most STUPID thing I have ever heard of.  What do you people
think you are playing with?  An Atari 400 or something?

PLEASE, do NOT spread this kind of USELESS information around.  If you
need to disassemble the operating system to work out what a memory location
does, then you shouldn't be using it.  I doubt the address mentioned
is portable to different TOS versions, let alone TT/STe/Falcon.

There are PLENTY of dumb ways of doing things, but you can at least choose
the portable ones [eg. print 100 linefeeds, then ask where the cursor is :-)].

--
Warwick
--
  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
 /     * <-- Computer Science Department,  /  
 \_.-._/     University of Queensland,    /   C references are NULL && void*
      v      Brisbane, Australia.        /  
Newsgroups: comp.sys.atari.st.tech
From: ridderbusch.pad@sni-usa.com (Frank Ridderbusch, STO SI211)
Subject: Re: Can't get gcc2.2.2 to work! (cpp-problem)
X-Md4-Signature: 2e9101f17b12c5fdd35420c17e1b6cef
Organization: Siemens Nixdorf Informationssysteme AG, Paderborn, Germany
Date: Fri, 9 Oct 1992 07:59:41 GMT

In article <92282.161212POHLERB@DMSWWU1A.UNI-MUENSTER.DE> Bjarne Pohlers <POHLERB@DMSWWU1A.UNI-MUENSTER.DE> writes:

 In article <MXQ7GKN@mailgzrz.tu-berlin.de>, subiaagb@w350zrz.zrz.tu-berlin.de
 (Andre Pareis) says:
 >
 >Hi C++ users,
 >
 >
 >I have a little problem with getting gcc2.2.2 to work.
 >gcc -v -c mytest.cc results in:
 >
 >gcc-cpp.ttp /d/gnu/atariST/2.2.2/ ...
 > /d/gnu/atariST/2.2.2/: file not found ( not exactly gcc's message )
 >                        /*      /d/gnu is the working directory         */
 >
 I suppose you have set GCC_EXEC_PREFIX. There is a bug in the Compiler-
 Driver gcc. I have compiled a fixed version for the ST. It is located
 at ftp.uni-muenster.de in the folder pub/atari/Gnustuff/Gcc/
 The filename is gcc222b3a.zoo.
   --
 !"$%&/);=?!-.'"[!=({\,@*~#+$['&^(/!&=]`"%$_^.|?>}`>|"/~^<$:&)*;#!;[&=#"&%$\':"[
 "  Bjarne Pohlers    Fast address: <pohlerb@math.uni-muenster.de>             &
 [":'\$%&"#=&[;!#;*)&:$<^~/"|>`}>?|.^_$%"`]=&!/(^&'[$+#~*@,\{(=!["'.-!?=;)/&%$"!

Even better, don't use GCC_EXEC_PREFIX at all on the ST. Since I've
been using GCC, which is since version 1.36 (over 2 years now), I've
set the variable GNUEXEC (similar to GNUINC and GNULIB). Please don't
create another version of GCC 2.2.2. There are already three, I know
of (Bammi's original, Howard Chu's version with baserel and a version
here in Paderborn,Germany compiled with MiNT libs).

I would definitly suggest, to stick with J.R.Bammi as main maintainer
of GCC (until he decides to pass the key). I'm sure the last changes
from Howard will move into Bammi's version.

Another technical reason to not use GCC_EXEC_PREFIX (or fiddling with
it) is in a cross compiling environment. GCC_EXEC_PREFIX is then used
the access the native machine componente of GCC and GNUEXEC is used to
locate the ST cross compiler equivalents.

BTW, Bjarne, this is also my main criticism to your article in
ST-Magazin.
--
MfG/Regards

     /====                          Siemens Nixdorf Informationssysteme AG
    /    Ridderbusch        / ,    Abt.: STO SI211
   /                       /./    Riemeke Str.
  /=== /,== ,===/  /,==,  //     W-4790 Paderborn, Germany
 /    //   /   /  //   / / \    Tel.: (49) 05251-8-0
/    /     `==/\ /    / /   \  NERV:ridderbusch.pad

Email: ridderbusch.pad@sni-usa.com (America (North & South))
       ridderbusch.pad@sni.de      (Rest of world)
From: UweKloss@lionbbs.bs.open.de ( Uwe Kloss )
Newsgroups: comp.sys.atari.st.tech
Organization: The Lion Town BBS, Brunswik, Germany
Subject: Re: Detecting the closing of an ACC from within an APP
Reply-To: UweKloss@lionbbs.bs.open.de
X-Software: HERMES GUS 1.04 Rev. Sep  5 1992
Date: Sun, 11 Oct 1992 23:36:30 MET

In <Jy8csB2w165w@sys6626.bison.mb.ca>, Trevor Cordes writes:
>How would I go about detecting if an accessory was closed (after it had
>been opened, of course) while a GEM application was running? The message
>pipe never seems to return AC_CLOSE (or AC_OPEN), which, as I'm told, are
>only received by accessories.
They are! An APP will never receive such a message.

>Oh ya, basically, I want my app to check the clipboard everytime an
>accessory is closed (to see if it contains some relevant data that I may
>have copied to it from STeno or STalker).

If you have the Sources let the ACC send a user defined
message to the APP if it receives AC_CLOSE.
If you havn't write an ACC which checks the Clipboard in
regular Intervals an does the above.

Uwe
-- 
Eliminiere das Unmoegliche. Was immer uebrig bleibt, so
unwahrscheinlich es auch wirkt, muss die Wahrheit sein.
Aber was ist, wenn einmal NICHTS mehr uebrig bleibt?
   (nach: John Brunner - Mehr Dinge zwischen Himmel und Erde)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Uwe Kloss                   UUCP: UweKloss@lionbbs.bs.open.de
Fasanenstrasse 65           BTX:  0531336908 0001
3300 Braunschweig           FIDO: not connected
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Truncating files in C
From: Murray_Moffatt@kcbbs.gen.nz (Murray Moffatt)
Date: 13 Oct 92 23:50:33 GMT
Organization: Kappa Crucis Unix BBS, Auckland, New Zealand

as327@cleveland.Freenet.Edu (Roy Bixler) says:

>Check out the 'chsize()' system call.  That, in combination with
>fseek/lseek ought to to it for you.

I'm using Propsero C and as far as I can see there is no chsize() function 
in it libraries (point me to the manual page or header file if I'm wrong!)

Is there a GEMDOS or BIOS routine I can use to truncate a file??

Newsgroups: comp.sys.atari.st.tech
From: annius@sif.research.ptt.nl (Annius Groenink)
Subject: Re: Questions about colors and the vdi.
Organization: PTT Research
Date: Fri, 16 Oct 1992 09:11:26 GMT

annius@nanna.research.ptt.nl (that's me) writes:

>ST Magazine (if I remember well) proposed to get the mapping by executing

Of course I meant the German ST 68oooer Magazin

-- 
Annius Victor Groenink      Universiteit Utrecht      PTT Research Leidschendam
Mathematics/Comp. Sc.        avgroeni@cs.ruu.nl       +31 70 3325445 (weekdays)
Atari ST/Music          A.V.Groenink@research.ptt.nl  +31 70 3464732 (evenings)
_____________My opinions are my opinions____________  +31 5700 29396 (weekends)
From: glens@natinst.com (Glen Sescila)
Newsgroups: comp.sys.atari.st.tech
Subject: STE Blitter Concern
Date: 16 Oct 92 05:34:58 GMT
Article-I.D.: falcon.1bmnf2INNl33
Distribution: usa
Organization: National Instruments, Austin, TX
NNTP-Posting-Host: falcon.natinst.com


	What happens if an interrupt occurs during a large blit when using
the BLiTTER in HOG mode?  I have not experienced any problems yet but my
concern is that I have a critical VBI installed that must run before the
first scan line is fetched.  I am using the BLiTTER in HOG mode and am doing
very large blits.  I hope that an interrupt stops the blitter and allows the
68000 to service the interrupt but I am worried that the interrupt is held
off until the end of the blit.

Thanks for any help.
-----------------------------------------------------------------------------
"Now You're Playing With Power Without The Price!"  Glen Sescila   |||
                                                                  / | \
My opinions do not necessarily reflect those of my employer and probably are
exact opposites.	InterNet: glens@natinst.com
-----------------------------------------------------------------------------
Newsgroups: comp.sys.atari.st.tech