Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 032
=========================================================================
INFO-ATARI16 Digest Fri, 12 Jan 90 Volume 90 : Issue 32
Today's Topics:
Aegis Animator
Atari ST books
Atari ST Picture Formats
Dead Mega2
Double open file warning
Genlock inquiry
How to call the bios from within process termination handlers
lharc/arc/zoo/compress
Need Mouse Info
opus 2.2
Parochialism in the Worlds of ST
Physbase vs. Logbase
Tempus II
Xbios dosound command
----------------------------------------------------------------------
Date: 10 Jan 90 15:01:56 GMT
From: brunix!iris.brown.edu!mjv@uunet.uu.net (Marshall Vale)
Subject: Aegis Animator
Message-ID: <24938@brunix.UUCP>
In article <1513@castle.ed.ac.uk> aimd@castle.ed.ac.uk (M Davidson) writes:
> The public
> domain version is called Ani-ST. It'd be a nice thing to have, it used
> to cost 80 quid (erk!).
>
> Has anyone got it? And if they do how about sending me a copy or putting
> it on terminator or some other archive, pleeeease...
Sorry, but it is not PD but was released on a STart disk which is not
PD (but has this myth about being so).
Contact them at (415) 957-0886 if you want to order that issue. (Sorry,
couldn't find it off hand so I don't know which issue number that was).
-- mjv@iris.brown.edu
------------------------------
Date: 9 Jan 90 11:04:43 GMT
From: mcsun!ukc!stl!idec!prlhp1!noonan@uunet.uu.net (Lee Noonan)
Subject: Atari ST books
Message-ID: <1040@prlhp1.prl.philips.co.uk>
I am just about to buy an Atari ST for developing C programs for both
graphics and windowing applications.
Can anyone tell me of any good books (not for beginners) on
1) detailed technical workings of ST
2) applications development on ST
Thanks
Lee
--
Lee Noonan Philips Research Laboratories, Redhill, Surrey, England
noonan@prl.philips.co.uk
------------------------------
Date: 10 Jan 90 14:59:59 GMT
From: rochester!rit!ritcv!ajy2208@pt.cs.cmu.edu
Subject: Atari ST Picture Formats
Message-ID: <1516@cs.rit.edu>
Hello everyone,
I am looking for information for various picture formats, for both
the ST and other computers.. Specifically for the ST, I am looking for
PD C or Assembly source code to display Spectrum pictures. I hav e
seen several programs that display SPC pics, but I'm not quite
experienced enough on the ST (yet!) to write my own Spectrum display
algorithm..
I also need the GIF format (it's not in the Picture Formats file
that was posted recently), any 8-bit formats (Koala, Micropainters,
etc..), and any Mac format(s). (just the description of these
should be fine)..
Also, what ever happened to PicSwitch? The latest version I saw
was 0.7, with a promise of a newer release. Well, that never seemed
to happen! Is the source code available?? Is the author on the
net? (sorry, I'm not on my ST or I'd look to see who he is)..
Thanks for any help,
_____________________________________________________________________________
Albert Yarusso, Rochester ajy2208@ritvax.bitnet,ajy2208@ultb.isc.rit.edu
Institute of Tech. _________________________________________________________
Computer Science /___ / ?rutgers, ames?!rochester!ritcv!ajy2208
______________________/ / ajy2208@ritcv.cs.rit.edu GEnie: A.Yarusso
------------------------------
Date: 10 Jan 90 14:58:19 GMT
From:
cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!econadm5@tut.cis.ohio-stat
e.edu (BENTLEY BH - ECONOMICS)
Subject: Dead Mega2
Message-ID: <567@watserv1.waterloo.edu>
In article <3906@jhunix.HCF.JHU.EDU> rick@jhunix.UUCP (Eric Ruck) writes:
>
>OK, I've got a dead Mega 2 ST. Probably the power supply. For about 20
>seconds it sounded like there was a piece of paper caught in the fan, then
>the thing completely blacked out, no power light or anything.
>
>Thus far, my alternatives to getting it repaired seem to be either having one
>local repair center cannabilize a 1040 power supply at a cost (parts and
>labor) of around $200, or having the thing sent back for $60 and six or so
>weeks, none of which seem attractive to me.
>
>Is there anyone who has had this problem, and can suggest a way a couple of
>undergraduate EE majors can fix it?
Well I have fixed several Atari St Machines and upgraded many of them.
The cause of the power failure could be anything from grounding out
the disk drive connector to the Dma port etc over a period of time.
Most likely the cause was a cold solder joint that over time heated
up and then had no connection. These cold solder joints can be located
at various spots but from experience near C10 C11 or where any of the
wires that enter or exit the power supply board. I have had to replace
a leaky capacitor at c13 and a fuse time to time(normally due to improper
disconnection of the power supply). Regardless before sending it off look
high an low for a cold solder joint on the power supply board.
If you require any more assistance send me mail and Ill see how I can help.
Dave Tomesch , Super BBS (519) 749-1206 250Megs. Brain Bentley KWEST Editor
" Never say Never"
------------------------------
Date: 9 Jan 90 23:57:17 GMT
From: portal!atari!apratt@uunet.uu.net (Allan Pratt)
Subject: Double open file warning
Message-ID: <1939@atari.UUCP>
Talking with Dale Schumacher led to the following concise warning:
If the same file is open more than once, it's trouble.
That is, if you Fopen a file, then Fopen it again without calling
Fclose on the first handle first, you are courting disaster. When
either handle is Fclosed, using the other one might or might not lead
to any sensible results.
This ESPECIALLY applies to having the same file open by two different
processes: if you Fopen a file, then Pexec a child, and that child
Fopens the same file, you're in deep doo-doo. When the child Fcloses
the file, or Pterms (which closes all its files), the handle in the
parent might or might not refer to anything sensible.
Fdup and Fforce suffer from the same problems. It's all in the data
structures which turn handles into files and eventually into blocks on
disk. They're done wrong. This is true for all existing TOSes:
1.0, 1.2, 1.4, and 1.6.
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 10 Jan 90 15:19:03 GMT
From: mailrus!uflorida!beach.cis.ufl.edu!cr1@tut.cis.ohio-state.edu
(Christopher Roth)
Subject: Genlock inquiry
Message-ID: <21700@uflorida.cis.ufl.EDU>
In article <90010.000352SML108@PSUVM.BITNET> SML108@PSUVM.BITNET writes:
>In response to my response to an ST flame...
>
>I only call people names when appropriate, I'm not going to knock a great
>computer, only the attitude of its owner...
>
>It's getting even more moot these days. The STE appears to have everything
>the Amiga originally had over it in a slightly less elegant fashion, and this
>makes the price difference even more questionable...
>
>If only the dimbops would advertise the thing on MTV like the smart people at
>Commodore. I shouldn't complain though, at least they aren't trying to sell
>the Lynx by word of mouth (yeah I know about the Amiga/Lynx connection, I
>LOVE that!)
>
>What I really wish would happen is that Apple recruit Atari to make a mac
>for the home market. The real expertise Atari has is in making hardware
>dirt cheap. Yes, the Stacy is just that, but if Atari doesn't push the thing,
>it won't make a gnat's yeast infection of a difference...
>
>Commodore deserves to dominate the desktop video market. They entered it the
>same time as atari, but unlike atari, they supported it, rather than get lost
>in their own machinations, confusing everyone...
> My reply was only to the dimwit who aimlessly blasted the ST because of
>obvious insecurity over the size of his peripherals, rather than actually
>spouting some truth about the Amiga's dominance of desktop video...
I think Atari is a great machine. I love my ST and prefer it over any
other computer I can think of that I could afford to buy. Right now,
it seems to me like there is a hole in the computer market. C64 is
going out, and C128 never really was a big deal. There is nothing for
the person who doesn't know much about computers, doesn't WANT to know
much about computers, or doesn't NEED to know much about them.
Nothing for the casual home user who wants to play games and also do
some serious stuff on it. The Atari ST could fill this gap, but they
do not advertise. Half the people I ask do not even know what an ST
is. It is all well and good that things are different in NY and the
west coast, but tht isn't going to help Atari. Atari doesn't have a
bad image...right now, they have NO image.
You guys at Atari listening? I also think that advertising on MTV
is DUMB. But it would be smart to get more dealerships open across
the US...Buy advertisement in computer magazines. (I was happy to see
ATari ST mentioned in Computer Shopper)...support the product! And
get rid of some of these distributors that aren't getting products to
the dealers that they have...or should have...
Tell you what, Atari can hire me as a campaign manager for the US.
I'll accept the job for ...oh, to be generous...40,000 a year.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* Christoper Roth * "Machines have no
* InterNet : cr1@beach.cis.ufl.edu * Conscience..."
=-=-=-=-=-=-=-=-=-=-=-=-=-Post No Bills-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
------------------------------
Date: 9 Jan 90 19:03:17 GMT
From: portal!atari!apratt@uunet.uu.net (Allan Pratt)
Subject: How to call the bios from within process termination handlers
Message-ID: <1937@atari.UUCP>
dmb@TIS.COM (David M. Baggett) writes:
>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).
>
>Saving the stack pointer before the trap and restoring it afterwards
>fixes things.
I don't believe it's a question of the stack pointer. When you return
from the BIOS your sp is ALWAYS what it was before you went in.
(How else could anything work?)
I think it's a reentrancy problem. The OS hooks seem to use external
storage, meaning they're non-reentrant. Worse, they all use the SAME
external location, so in a given program, you can't call BIOS from
BIOS, but you also can't call XBIOS from BIOS!
(Study the flow of a BIOS call which calls XBIOS when both go through
the same hook: the mainline calls BIOS, saving the return PC someplace.
That BIOS code calls XBIOS, saving it's return PC IN THE SAME PLACE!)
On the other hand, it shouldn't matter, since the Pterm call in question
never returns.
Hooks like this can be made reentrant by changing how they work:
instead of this:
move.l (sp)+,trapret ; save return PC
trap #$x
move.l trapret,-(sp) ; restore return PC
rts
you could use this:
movem.l 4(sp),d0-d2/a0-a2 ; get 6 longs' worth of args
movem.l d0-d2/a0-a2,-(sp) ; push them
trap #$x
add.w #24,sp
rts
This uses no external storage (and therefore is reentrant). The point
is to give the trap the intended args without the hook's own return PC
in the way. The first method pops the PC off and saves it, while the
second method does it by copying the args into a new stack frame.
------------------------------
Date: 10 Jan 90 22:12:57 GMT
From:
zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!jarthur!uci-ics!jvance@tut.cis.ohi
o-state.edu (Joachim Patrick Vance)
Subject: lharc/arc/zoo/compress
Message-ID: <25ABB36A.5680@paris.ics.uci.edu>
In article <21701@uflorida.cis.ufl.EDU> cr1@beach.cis.ufl.edu (Chris Roth)
writes:
>What we have here is a lot of different archive methods being used.
>It would be nice if we could use one standard, and I would vote for
>Zoo.
>
I would rather have someone develop a universal archiving tool which
could dearchive many different formats and perhaps archive in all those
formats as well. There are trade-offs for all the compression methods and
I would rather not lose the freedom of choice.
Does someone want to develop such a universal archiving tool? Is it
worth it? I for one would have a use for such a program.
--
Joachim
?????????????????????? What do my .sig and UCI have in common? |
| jvance@ics.uci.edu | - - - - - - - - - |
?????????????????????? They're both Under Construction Indefinately.|
------------------------------
Date: 10 Jan 90 12:11:34 GMT
From: mcsun!ukc!dcl-cs!gdt!gdr!exspes@uunet.uu.net (P E Smee)
Subject: Need Mouse Info
Message-ID: <1990Jan10.121134.15539@gdt.bath.ac.uk>
In article <7051@b11.ingr.com> cowie@b11.ingr.com (Ivan Cowie) writes:
>In article <1782@mrsvr.UUCP>, krieg@jupiter.uucp (Andrew Krieg) writes:
>> My mouse is dying and I need to replace it fast. Can anyone recommend one
>> cable. The arrow moves in the opposite direction of what I want, sometimes.
>> I shake the cord a little, and it will work OK for a short time. Can I
>> cheaply replace/build a new cable?
This problem can occur if one of the wires inside the cable is broken.
(There seems to be a favorite place for them to break, about an inch
outside the mouse.) You might be able to get a replacement cord from
someplace that repairs Atari. (I thought about rebuilding mine, but
couldn't find either an appropriate strain-relief, or a source of the
fiddly little connector used to attach the cable to the board inside
the mouse.)
You can also get this effect (it follows) if your mouse socket in the
ST is lifting from the board and so breaking a connection (apparently
not too uncommon if you unplug the mouse a lot, to put a joystick into
that port) or if the mouse is not firmly, all-the-way, plugged into the
ST. Check that first, it's easier; my mouse often wiggles loose. If
you plug/unplug the mouse a lot, get a switchbox, or even just a
joystick extension cable (Tandy/Radio Shack) and do the swap at the end
of that.
If you go for a third party mouse, be careful about the ones with
switches that make a loud click. They tend to have metal domes which
deform under pressure (like the little metal 'cricket clickers') and
will die from metal fatigue under heavy use. Probably OK for 'serious'
use, where you don't click a LOT, but I've killed 2 such (different
makes) playing Populous. (Anybody know a good, durable, light button
touch, 'GAMES' mouse?) My dead ones where a Kempston mouse, and one
labeled 'Conniver' or something like that. These might be UK-specific
brand names. I'm tempted to try modifying the shell of the Kempston
mouse, which is very nice for 'serious' use, so I can install heavy-duty
microswitches. Nothing to lose, after all...
--
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: 10 Jan 90 16:47:33 GMT
From:
cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!crdgw1!brspyr1!tim@tut.cis.
ohio-state.edu (Tim Northrup)
Subject: opus 2.2
Message-ID: <6609@brspyr1.BRS.Com>
SCHMIDTM@CMR001.BITNET writes about problems running Opus 2.2 and getting
it to accept the ASSIGN.SYS file.
I found that Opus is very particular about the ASSIGN file format.
In particular, the device entries can't have anything extra around
them, and device number MUST be 2 digits long. That is, the
following line will not work:
1r screen.sys
But this one should be okay:
01r screen.sys
It may have also complained when the drivers selected used upper
case (or the other way around -- I'm not at my system right now, so
most if this is just vague recollection). Play with the device
driver entries though, it took me several hours to get it right.
One of these days I'll get around to writing that ASSIGN.SYS file
builder/maintainer I've been meaning to ... ah, well.
-- Tim
--
Tim Northrup +------------------------------------------+
+---------------------------------+ GEnie: T.Northrup |
UUCP: uunet!crdgw1!brspyr1!tim | Air Warrior: "Duke" |
ARPA: tim@brspyr1.BRS.Com +------------------------------------------+
------------------------------
Date: Wed, 10 Jan 90 09:31 EST
From: JOHNBARNES@ENH.NIST.GOV
Subject: Parochialism in the Worlds of ST
There has been enough traffic from the "loneliness...." message thread
to raise the following issues:
1). What are the factors that retard the movement of the wonderful
software that we hear of in Europe, the true home of the Atari ST,
across the Atlantic to the underdeveloped reaches of the USA and
Canada?
2). How many different kinds of ST's are there? This may seem naive
but are German ST's, English ST's, French ST's, Canadian ST's etc...
that different from each other and from those in the USA? If so, Why?
If this is true of ST's is it also true of PC Clones and Macintoshes?
3). What barriers exist to the migration of software and hardware into
Europe? What obstacles other than his own simple ignorance would an
outside developer face if he tried to market in Europe?
4). We often hear that ST's are taken more seriously for professional,
academic, and scientific use in Europe. Is this still true?
5). Problems with RFI suppression have been cited as the most frequent
cause of delays for the introduction of new products into the US
market. Are these standards different in Europe and the US? If so
what are the differences? Is there a common standard that could serve
as the benchamrk for RFI suppression engineering?
I am sure that others can think of other questions in a similar vein.
I have offered this topic in the spirit of initiating a dialog which
could, if the outcome were taken to heart, lead to a more unified
approach to the Atari marketplace to replace the fragmented approach we
see today.
While it is difficult to separate institutional factors from technical
issues, it would be desirable to be as objective as possible in this
discussion. Isolated personal experiences should be eschewed in favor
of globally valid descriptions.
It might also be possible to identify areas of possible transatlantic
collaboration in such areas as translation of documentation, standards
development, and software testing that could help to break the ice.
This may just be another gasp from a superannuated Candide, but I am
seriously interested in seeing improved computing on both sides of the
pond.
------------------------------
Date: 10 Jan 90 12:42 -0800
From: Doug Latornell <latornell@mech.ubc.ca>
Subject: Physbase vs. Logbase
Message-ID: <255*latornell@mech.ubc.ca>
In response to the question by:
John R. Dunning <jrd@STONY-BROOK.SCRC.Symbolics.COM>
regarding: Physbase vs Logbase
Physbase() is the XBIOS call to get the physical base address of the
screen while Logbase() is the call (also XBIOS) to get the logical
base address of the screen.
Physbase() returns a long that is the screen's physical address in
memory at te next vertical blank interupt after the call. Logbase()
immediately returns a long that is the screen's logical address. To
actually do anything with these call you need to know about
Setscreen() too.
Setscreen() has 3 arguments, log_base, phys_base and res. log_base
points to the screen buffer on which writes operate, phys_base points
to the buffer that is displayed. If they are the same then a write
operation will appear on the screen as it is done. If they are
different, you won't see the result of the write until you change the
physical base to show that logical screen. res sets the resolution.
A -1L for *_base or -1 for res leaves the current value unchanged.
Perhaps an example will make things clearer. I've used this to do
primitive animation, the sort where you flip back and forth between 2
screen buffers, displaying one while drawing the next frame on the
other. An outline of the code goes something like:
/* globals */
char *screen1, /* logical base of current screen */
*screen2; /* logical base of new screen */
set_bases()
?
long new_buffer;
new_buffer = Malloc(32256L);
/* some code to make sure new_buffer starts on
a half page boundary */
screen1 = Logbase();
screen2 = (char *)new_buffer;
?
main()
?
set_bases();
while( /* not stop animation condition */ )
?
/* show screen 1 while drawing on screen 2; leave res alone */
Setscreen(screen2, screen1, -1);
/* draw next frame */
....
/* show screen 2 while drawing on screen 1 */
Setscreen(screen1, screen2, -1);
/* draw next frame */
...
?
/* put logical ad physical bases back to original values */
Setscreen(screen1, screen1, -1);
/* release memory used for 2nd buffer */
Mfree(screen2);
?
Hope this helps. Check out Pollack and Weber, "Atari ST Application
Programming", Bantam, 1987 for further details.
Doug Latornell
latornell@mech.ubc.ca (this address works for everybody I know!)
------------------------------
Date: Wed, 10 Jan 90 09:29 EST
From: JOHNBARNES@ENH.NIST.GOV
Subject: Tempus II
As a heavy user of Tempus II and the Universal Item selector I have
been plagued by the following problems:
1). Tempus' Item Selector, while it was great when first introduced,
has been supplanted by Universal or, to a lesser extent, the built-in
item selector under TOS 1.4. Could we get the Tempus people to abandon
their item selector or at least provide a configuration option that
allows use of whatever happens to be resident in the system, as the new
WordPerfect does?
With the Tempus item selector one has to take extra steps to get past 6
logical drives. Universal provides capabilities like delete, copy,
rename, format, print, touch, ....which are very handy when doing
editing. While it is true that the UIS can always be brought up as a
desk accessory it would seem very convenient to also have it available
for loads, block saves, etc.
2) Tempus' scroll bars interact with the scroll bars and buttons on UIS
such that any UIS item that happens to overlay a Tempus scroll bar
fails to function. This can create a serious problem if the horizontal
scroll bar for an active window happens to lie beneath the "Cancel"
button on the UIS. I have seen this problem in TOS 1.4 and TOS 1.2.
Has anyone else seen it? This seems to imply that Tempus replaces
certain GEM functions in a non-standard manner, which is greatly to be
deprecated.
3) Tempus does not provide hot-key reminders on its drop-down menus.
This would be a really nice feature to have because Tempus does make
effective use of hot-keys. I recognize that the fact that Tempus' key
bindings are user-selectable may be a problem but it would seem to me
that the text strings for the menu entries could be rewritten when
Tempus recompiles its bindings. Since Tempus does not use a separate
resource file to hold data for menus and the like this would mean
modifying the executable image of the program, which should not be too
difficult.
4). Perhaps the Tempus developers could also provide online help via
the Help Key.
Tempus II is by far the most satisfactory line-oriented editing program
that I have used on the ST. I would hope that its developer would be
responsive to these very minor problems. I would gladly pay another
$25 or 30 for an upgrade to enhance the value of this fine program.
If anyone out there in Net-Land has contacts with the Tempus developers
I would appreciate it if they could forward this to the responsible
people. I do not find it useful to take problems like these to
Michtron, the US distributor.
Please keep me posted via E-Mail on anything that develops out of this
message. I would be interested in other folks' reactions to these
suggestions in the spirit of evolving sound standards for the
development of a coherent "look and feel" for ST applications programs.
------------------------------
Date: 10 Jan 90 14:11:10 GMT
From:
cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!watdragon!tiger!achowe@tut
.cis.ohio-state.edu (anthony howe)
Subject: Xbios dosound command
Message-ID: <19657@watdragon.waterloo.edu>
Change the envelope pattern to be continuous. See the messages just
before Xmas were I sent out a set of examples. Steve Grimm should be
placing them onto the comp.sources.atari.st too very soon now.
- ant
achowe@tiger.waterloo.edu | "It is hard to make the world go away
_ -|-|_ _ | when it has decided to notice you."
(_\ |\| | | | (_) |\| \/ | - Spock's World
___/ | disclaimer...
------------------------------
End of INFO-ATARI16 Digest V90 Issue #32
****************************************
