Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 039
=========================================================================
INFO-ATARI16 Digest Sat, 13 Jan 90 Volume 90 : Issue 39
Today's Topics:
Atari's Quarterly Results ($5.4 Mil
Buying TOS 1.4
Gathering info on memory upgrades
GEM windows programming problem
lharc/arc/zoo/compress
Multifinder on GCR (Really the multiple TOS patches)
Poolfix problem
TOS 1.6... (2 msgs)
TOS 1.6 and the 68030
----------------------------------------------------------------------
Date: 11 Jan 90 01:36:02 GMT
From: crash!pro-grouch.cts.com!bradm@nosc.mil (Brad Martin)
Subject: Atari's Quarterly Results ($5.4 Mil
Message-ID: <1148@crash.cts.com>
In-Reply-To: message from hedger@inmet.inmet.com
>Sounds fishy to me.
Low margens on their products. :-)
.>Brad Martin<.
Atari Jihad
"The above opinions are mine and mine alone... I think."
------------------------------
Date: 10 Jan 90 20:52:00 GMT
From: smithb@nyu-acf2.arpa (Barry Smith)
Subject: Buying TOS 1.4
Message-ID: <12530019@acf2.NYU.EDU>
Does anyone know where I can buy TOS 1.4 in NYC?
Can I buy them by mail, if so, where?
------------------------------
Date: 11 Jan 90 01:38:26 GMT
From:
zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.e
du!renner@tut.cis.ohio-state.edu
Subject: Gathering info on memory upgrades
Message-ID: <7500011@m.cs.uiuc.edu>
On one hand I have a very nice 1040ST. On the other I have a large pile
of memory chips, of various package types and capacity. I'd like to put
the two together. But I have to learn more about the upgrade possibilities
first. So...
If you have knowledge about memory upgrades for Atari ST machines -- 520s,
megas, whatever -- please send me mail. I will summarize the replies.
============
Scott Renner USENET: pur-ee!uiucdcs!renner
University of Illinois at Urbana-Champaign ARPA: renner@cs.uiuc.edu
------------------------------
Date: 12 Jan 90 19:59:32 GMT
From: imagen!atari!mui@ucbvax.Berkeley.EDU (Derek Mui)
Subject: GEM windows programming problem
Message-ID: <1958@atari.UUCP>
in article <11830069@hpldola.HP.COM>, jg@hpldola.HP.COM (Joe Gilray) says:
>
>
> Here is a GEM programming problem:
>
> I've written a multiwindow GEM application, everything was fine until I
> added a "feature" that allows users to edit window data in a dialog box.
> The dialog box editing function allows the user to edit data that may
> appear in several windows that are currently open on the screen.
>
> Here's the difficulty, when the dialog box closes, the window(s) receive
> a WM_REDRAW message which is fine, but data may have changed in an area
> of a window (or two, or three) that is not covered by the dialog box and
> therefore does not appear on the redraw rectangle list. When the uncovered
> part of the window(s) is redrawn the window data looks wrong because the
> part of the window that was not covered is old.
>
Here's my $0.02
Inside the same function do the following:
Immediately after the dialogue box is closed, do a
evnt_multi of Timer Zero and Messages wait. You should receive
a redraw message with a rectangle that covered the windows, and
then do the normal window redraw.
After you have done all these, do your internal data update.
Then do a window redraw with a big rectangle ( full desktop size )
to each of the windows.
The code should look like:
foo( )
?
......;
......;
form_do( ... );
form_dial( 3, ... );
event = evnt_multi( MU_TIMER|MU_MESAG, ..., msgbuff, .... );
if ( event & MU_MESAG )
? /* do your own window redraw */
do_redraw( msgbuff[3], &msgbuff[4] );
/* window handle, rectangle */
?
update_windowdate( ); /* update your windows' data */
handle = firstwin( ); /* get your first window's handle */
loop
?
/* rectangle = desktop rectangle area */
do_redraw( handle, rectangle );
handle = nextwin; /* get your next window's handle */
?while( handle >= 0 );
?
Hope this helps and works!
==================================================================
Derek Mui, Atari Corp, 1196 Borregas Ave, Sunnyvale, CA 94086
UUCP: ?..ames!atari!mui?
FAX: 408-745-5179
Disclaimer: Opinions expressed here are my own and they may be
hazardous to your mind.
==================================================================
------------------------------
Date: 11 Jan 90 02:43:53 GMT
From: mailrus!uflorida!beach.cis.ufl.edu!rs0@tut.cis.ohio-state.edu (Bob
Slaughter)
Subject: lharc/arc/zoo/compress
Message-ID: <21723@uflorida.cis.ufl.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 _really love to see a super-smart program that can use any of
these formats, and allow you to unarchive _anything_. Then the choice
of archive format would become less of a problem in the present and
the future.
--
* Bob Slaughter * This space for rent *
* InterNet#1: rs0@beach.cis.ufl.edu * Call 1-800-FOR-RENT *
* InterNet#2: Haldane@Pine.Circa.Ufl.Edu * Model Railroading *
* Bitnet: Haldane@UFPine * is Fun!! *
------------------------------
Date: 12 Jan 90 22:56:29 GMT
From: att!chinet!saj@ucbvax.Berkeley.EDU (Stephen Jacobs)
Subject: Multifinder on GCR (Really the multiple TOS patches)
Message-ID: <1990Jan12.225629.3008@chinet.chi.il.us>
We now have about 5 useful official TOS patches that I can think of to run
from the AUTO folder. Perhaps it would be reasonable for Atari to combine
all of them into 1 program which reads a configuration file to tell it how
big to make OSPool and how much buffer to set aside. Not at all coinciden-
tally, this gets to look a lot like the MS-DOS startup mechanism. I'd be
willing to buy such an animal, as long as it was both official and
supported (that means that Atari would take names, and send a card to let
us know when a new one was available).
Steve J.
------------------------------
Date: 13 Jan 90 01:53:56 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: Poolfix problem
Message-ID: <1962@atari.UUCP>
I MADE A MISTAKE. DON'T USE POOLFIX.PRG. POOLFIX.PRG DOESN'T WORK.
I'm sorry. My fault. It has bugs and should not have been released.
Next week (that is, 1/15 or so) I will post a new one, POOLFIX2.PRG,
which will work. Until then, REMOVE POOLFIX.PRG from your system.
Wipe it completely. Kill it before it kills you.
Am I making myself clear?
I have the new fix already done & working, but I hope you can
understand if I want to test it to death before releasing it.
============================================
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 21:40:11 GMT
From:
cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!watcgl!electro!ignac@tut.c
is.ohio-state.edu (Ignac Kolenko)
Subject: TOS 1.6...
Message-ID: <1252@electro.UUCP>
In article <9001100808.AA18195@ucbvax.Berkeley.EDU> VBRANDT@DBNUAMA1.BITNET
writes:
> Sorry, but this technically impossible. The 1.6 version is bigger than the
>available ROM space in a regular ST/Mega, and is installed at a different
>location in the CPU address space.
>
> Also, I doubt that 1.6 checks for CPUs other than a 68000. TOS 3.0, on the
>other hand, does just what you want. 3.0 is the TOS that comes with the TT.
>It won't work in STs for the same reasons.
actually, darek mihocka and myself have an STE and we've disassembled the
exception handlers in TOS 1.6, and sure enough, it checks some
system variable which tells the software what type of stack frame it can
expect. therefore, if its a 68000 processor, it uses an offset begeinning
at 6 from the current stack pointer to get params, and if its an 010 or
higher, it uses an offset of 8. it does this in getting params, and also
for reconstructing stack frames, etc. so, in actuality, tos 1.6 does indeed
support cpus other than the 68000.
also, i remember vaguely reading some review in ST world on the STE when
it was unveiled at the dusseldorf show, and they were saying it was running
tos 1.6 at the time. but i could be wrong ...
--
=====Ignac A. Kolenko (The Ig) watmath!watcgl!electro!ignac=====
co-author of QuickST, and the entire line of Quick Shareware!!!!
"I don't care if I don't win, 'cause I don't care if I fail"
from 'Youth Of Today' by SUBURBAN DISTORTION
------------------------------
Date: 12 Jan 90 19:28:47 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: TOS 1.6...
Message-ID: <1956@atari.UUCP>
saj@chinet.chi.il.us (Stephen Jacobs) writes:
>In article <1252@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes:
>>actually, darek mihocka and myself have ... disassembled ...
>This is what serious developers do ... to
>check EXACTLY what TOS would do in a given situation (and any commented
>source, no matter how 'ugly', beats a disassembly).
The fallacy here is that you think we want you to know EXACTLY what TOS
would do. Publishing the source would make it impossible to change it,
because people would start relying on accidental side-effects of
operations. When that happens, we can't change the code without
breaking those programs or maintaining those previously-accidental side
effects. This is a maintenance nightmare.
Take this example: if you had source for the original Fsfirst call,
you'd have seen that the only error it can return is EFILNF, file not
found. You might have used that knowledge in your code somehow. In
TOS 1.4 and beyond, Fsfirst can return EPTHNF, *path* not found. I
consider this an improvement. If your code was expecting either success
or EFILNF, and gets neither, how will it behave?
In an extreme case, you might have seen that there was a bug in Cconout
when stdout is redirected to a file; the HIGH byte of the argument is
written to the file, not the low byte, or something like that. This is
a bug, not a feature, but if you take advantage of it we can't ever fix
it without breaking your program.
Finally, take Malloc: you would know that Malloc uses OS POOL to keep
track of memory, and that two successive Malloc calls are likely to
result in two contiguous blocks of memory. People have in fact taken
advantage of this, and the result is that we can't ever fix this
brain-damaged approach to memory management. We're straitjacketed by
the tricks people pull; imagine how much worse it would be if the whole
OS were open to that kind of scrutiny!
You needn't tell me that UNIX source is available (if you pay for it).
UNIX is different, because (A) it was designed better, so people don't
have to resort to these tricks just to do ordinary things, and (B)
people on UNIX systems don't come from a tradition of 8-bit
game-machine programming, where the first question they ask is, "Where
can I POKE to change rez?"
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 11 Jan 90 01:36:04 GMT
From: crash!pro-grouch.cts.com!bradm@nosc.mil (Brad Martin)
Subject: TOS 1.6 and the 68030
Message-ID: <1149@crash.cts.com>
I have heard rumors (God I hate rumors) that TOS 1.6 would allow the STe to
work with an 68030 processor (and perhaps an 1040ST or Mega if outfited with
1.6). I would like to know if any of the Atari reps here on the net could
comment on this. I have a friend who works for a company who makes 68030
boards for 'other' computers who could have an '030 board out for the ST way
before another well publisized project (Hi Dave :-) ). If this is not true, I
will have to convince them that they want to write the software to make it
compatable (how would you like to have you ST running at 40mhz?).
.>Brad Martin<.
Atari Jihad
"The above opinions are mine and mine alone... I think."
------------------------------
End of INFO-ATARI16 Digest V90 Issue #39
****************************************
