Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 90 Issue 035
=========================================================================
INFO-ATARI16 Digest Fri, 12 Jan 90 Volume 90 : Issue 35
Today's Topics:
Aegis Animator
Atari's Quarterly Results ($5.4 Mil
C++ pre-processor
CO-Processors---(Atari!) ARE NICE PEOPLE!
GEM windows programming problem
HP PaintJet Printer info wanted
Larry's right!
lharc/arc/zoo/compress
LHARC source not all that portable
Mac II screen colors (Was: Genlock Inquiry)
MIXED
OOPS - BAD PATCH FOR TOS 1.4/1.6
PageStream 1.8 Bug (?)
Stacey shippi?ng??
TOS 1.6 and the 68030
Viruses
----------------------------------------------------------------------
Date: 10 Jan 90 21:03:15 GMT
From: davidli@UMN-CS.CS.UMN.EDU (David Paschall-Zimbel)
Subject: Aegis Animator
Message-ID: <18126@umn-cs.CS.UMN.EDU>
In article <24938@brunix.UUCP> mjv@iris.brown.edu (Marshall Vale) writes:
>> domain version is called Ani-ST. It'd be a nice thing to have, it used
> Sorry, but it is not PD but was released on a STart disk which is not
>PD (but has this myth about being so).
ACtually, Ani-ST is "shareware", and was released to GEnie, for one, before
it appeared on the STart disk. I believe that Jim Kent wanted a "smile" as
payment ...
So, no, you do not have to buy the STart disk in order to obtain the Ani-ST
program, but you may certainly do so.
Public domain programs have appeared in STart before, and are generally
marked as such. Programs such as ST Writer may be freely copied, since
STart magazine _cannot_ hold a copyright on the material. This does not mean
that all programs on STart are PD, most of the are not. But in the case of
Ani-ST and ST Writer, the programs are freely distributable ...
-- David Paschall-Zimbel
------------------------------
Date: 11 Jan 90 23:47:58 GMT
From: wang!ejohanss@uunet.uu.net (Eric Johansson)
Subject: Atari's Quarterly Results ($5.4 Mil
Message-ID: <784@wang.UUCP>
waynekn@tekig5.PEN.TEK.COM (Wayne Knapp) writes:
>In article <30200039@inmet>, hedger@inmet.inmet.com writes:
>- Are they serious ????
>- They sold 98 million dollars worth of stuff and only made
>- a 900,000 dollar profit ????
>-
>- Sounds fishy to me.
>That's nothing! My company has even manage to sell 1.4 BILLION
>and LOSE 16 million!!! Atari looks good from where I'm sitting.
>(The above happen in the year that ended June of 1988)
> Wayne Knapp
What are you guys complaining about. wang makes you look like pikers! we lost
0.5 billion on 3 billion of sales...( hmmm. maybe that's why they RIFed about
10,000 folks world wide)
--- eric ( from whats left of ) Wang Labs
ejohanss@wang.com
------------------------------
Date: 12 Jan 90 22:31:59 GMT
From: pyramid!athertn!alex@hplabs.hpl.hp.com (Alex Leavens)
Subject: C++ pre-processor
Message-ID: <16556@laurel.athertn.Atherton.COM>
Does anybody know of, or have, a C++ (or Objective C)
pre-processor for a C compiler on the ST? (I specifically
use Mark Williams C, but a pre-processor for any
C compiler would be fine.) Has anybody heard of such
a thing being commercially available?
--
|----------------------------------------------------------|
|--alex | 'My mind is my own', and so are my opinions |
|Now who are you gonna believe--me, or your own lyin' eyes?|
|----------------------------------------------------------|
------------------------------
Date: 11 Jan 90 19:08:49 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: CO-Processors---(Atari!) ARE NICE PEOPLE!
Message-ID: <1946@atari.UUCP>
kar7481@cuphub.cup.edu (Dan Karbowsky;AtariEliteOfPghPa bbs412-384-5609) writes:
>I was VERY INTERESTED in attempting to tack a mc68881 co-processor onto
>my 1040.....I talked to ATARI-US and ATARI-UK: They couldn't tell me
>ANYTHING and ATARI-US denied the '881s existance.
I can't imagine why they did that.
Atari has a product, the SFP004, which is a 68881 peripheral for a Mega.
It only works with Megas, not 1040s, which may have been the source
of the confusion. It comes with a library (and source!) for linking
Alcyon C programs which use floating point so they use the 68881
if it's there, and use the old software routines if it's not.
Once you have this technical document and a 68881 chip, how do you
propose to weld the chip into your 1040? It's a nontrivial
undertaking. The SFP004 plugs into the internal Mega expansion bus. If
you do manage to weld a 68881 onto a 1040, please try to make sure it
addresses at the same place as the SFP004: the base address is $FFFA40.
============================================
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:13:36 GMT
From: hpfcso!hpldola!jg@hplabs.hpl.hp.com (Joe Gilray)
Subject: GEM windows programming problem
Message-ID: <11830069@hpldola.HP.COM>
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.
Solutions and commentary:
1) When traversing the rectangle list set the clipping area to the
whole window instead of the just the covered part, then draw the
entire window's data.
results: YECH. This doesn't work because the windows are drawn in
somewhat random order (any ideas here?) and windows that are
beneath other, already drawn windows may pop through them
when drawn.
2) When the window(s) are "dirtied" (that is their data is changed), use
appl_write() to send a redraw message for the entire desktop.
comments: I haven't tried this yet, but it seems pretty good. The
questions that come to mind are:
a) will this new WM_REDRAW message get merged with the
one from the dialog box closure? I know that redraw
messages will get merged, I have used this before when
I wanted to force a redraw whenever windows were sized
(normally window sizing only causes a redraw event if
one of the window's dimensions is increased).
b) Will this look bad even if the redraws are merged?
I'll have to try this and see.
3) Variation on (2) above, send multiple redraw messages, one for each
dirtied window.
Will these messages all get merged?
Anyway, any ideas and comments are appreciated!
-Joe Gilray
------------------------------
Date: 11 Jan 90 20:39:02 GMT
From: att!cbnewsj!rcd@ucbvax.Berkeley.EDU (rana.c.dutt)
Subject: HP PaintJet Printer info wanted
Message-ID: <3326@cbnewsj.ATT.COM>
In article <2866@cuphub.cup.edu>, kar7481@cuphub.cup.edu (Dan
Karbowsky;AtariEliteOfPghPa bbs412-384-5609) writes:
> Could you please tell me SPECIFICALLY what hardware/software you're using
> and especially where you got the driver for the PAINTJET!!!???
>
> This MAY change my mind.....(from LJ-II to PJ)...
Let me talk about the ways ST programs talk to printers, and then let's
see how these ways relate to the HP Paintjet, OK?
The first and simplest way is for the program to use the text mode of
your printer only, and forget about the graphics mode. You get to tell the
program what escape sequences it needs to print bold, italics, compressed,
etc., but the important thing is, you're limited to the printer's own
internal fonts and capabilities in text mode.
First Word and Wordwriter ST are examples of programs that fall into this
category. If you'd be happy with a 10-point Letter Gothic font, which is
a font that the Paintjet has built in, then using one of these programs
will produce 180-dpi NLQ text mighty speedily. And besides the black text,
you can print colored text in 6 other colors. You can do this by mapping some
Wordwriter ST modes to color escape sequences, e.g., I mapped the light,
superscript, and subscript modes (which I don't use) to red, blue, and green.
Anyway, writing a driver for these types of programs is easy.
The second way a program can print is to use GDOS along with the graphics
mode of the printer. So, if you need fancy fonts, you specify them in your
ASSIGN.SYS file, and GDOS will map them to the best possible resolution
for your printer. EasyDraw, Timeworks DTP, and Wordup are all examples of
programs that use GDOS for output. Alas, there is no GDOS driver for the
Paintjet, to my knowledge. If programs like these are important to you,
don't buy the Paintjet! (I have the HP Deskjet also, and, fortunately,
both Neocept and Migraph have very good GDOS drivers for the Deskjet/Laserjet
series; if 300 dpi laser quality output is important to you, get one of
these printers instead.)
A third way a program can print is to use the graphics mode of your
printer, but bypass GDOS, and use its own graphics-producing schemes.
Pagestream 1.8 is in this category. It comes with a whole slew of printer
drivers including an excellent one for the Paintjet. This program is
powerful enough to be a wordprocessor and object-oriented drawing program
all by itself, not to mention it's excellent page layout capabilities.
But what really makes it stand out is it's ability to represent hundreds
of colors internally, import Degas, Neo, and Amiga HAM format color
pictures with the palettes intact, and print them beautifully to the Paintjet.
It also has a color postscript driver for people with color postscript
printers. Not only that, it comes with outline fonts (not bitmapped) so
you can get arbitrarily big, tall letters with no additional disk space!
Summary: If you really need brilliant color output and 180 dpi text in the
same device, get the Paintjet. You can use the programs I mentioned, and
you'll be happy. If you need a printer that has good GDOS support, and color
is not important but 300 dpi laser quality is, get the Deskjet/Laserjet.
Rana Dutt
rcd@mtqua.att.com
------------------------------
Date: 13 Jan 90 01:38:35 GMT
From: ogicse!blake!ramsiri@ucsd.edu (Enartloc Nhoj)
Subject: Larry's right!
Message-ID: <5321@blake.acs.washington.edu>
Larry's right... possibly Atari's best
effort should be put into the education system..
Seems like much of Apple's initial success has
to be attributed to their establishing of themselves
in the student market.
About two years after i graduated from Dartmouth, i
learned that the new Dartmouth students (freshmen) were
being handed Macintoshes at registration. THey'd pick
up their class schedule and a Mac Plus. THe cost
was built into the tuition.. though one was not
officially obligated to purchase a Mac.. 97% of the
entering students in fact did go home with one...
(perhaps a current Dartmouth student can confirm this).
A logical outgrowth of this is a preponderance of
users who stay loyal to Apple. Were I a few
years younger, I'd probably be reading comp.sys.mac
instead of comp.sys.atari. I don't think
it is impossible for Atari to enter this market
and follow suit.. in fact, i think the time is
ripe for Atari to do so.
-kevin
ramsiri@blake.acs.washington.edu
------------------------------
Date: 12 Jan 90 01:31:52 GMT
From: usc!cs.utexas.edu!oakhill!dover!digital!chen@ucsd.edu (Jinfu Chen)
Subject: lharc/arc/zoo/compress
Message-ID: <47fb17d2.81da@digital.sps.mot.com>
In article <21723@uflorida.cis.ufl.EDU> rs0@beach.cis.ufl.edu () writes:
>
>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.
>
It's possible to write such program. However, it's pretty hard to write
a program to handle multiple format by itself with comfortable speed.
It's much easier to write a program to identify the compression format
and call appropriate compression program to handle the data file. Under UNIX,
this is trival as each of these four compression schemes has an unique 'magic'
number. The UNIX command `file' can be used for such application. If you add
following lines in the 'magic' file (/etc/magic), the command should be able
to identify the format of an compressed file:
0 short 0x1f9d compress(l) output
0 byte 0x1a arc(l) archive output
2 string -l lharc(l) archive output
20 long 0xdca7c4fd zoo(l) archive output
Note that the magic number for zoo is for Motorola 680x0 chips, the Intell
chips and VAX family (?) store the long integer in normal order. So the
number should 0xfdc4a7dc instead.
I'm not 100% sure the lharc magic string covers every format of lharc. Inside
lharc.c, there are four of them listed:
#define LZHUFF0_METHOD "-lh0-"
#define LZHUFF1_METHOD "-lh1-"
#define LARC4_METHOD "-lz4-"
#define LARC5_METHOD "-lz5-"
Alternatively, one can add these information to the magic file so `file' command
can even tell you which archive method lharc uses.
------------------------------
Date: 11 Jan 90 21:09:25 GMT
From: per2!dag@speedy.wisc.edu (Daniel A. Glasser)
Subject: LHARC source not all that portable
Message-ID: <891@per2.UUCP>
The sources to LHARC posted recently to comp.sources.atari.st are not
all that portable across *nix systems. There is a routine gettz() in
lharc.c that is specific to BSD4.X, and the use of ftruncate, mkdir,
rmdir, and rename is not flagged as a system dependency.
The routine gettz() uses structures and a subroutine call which are
not available on many systems, and it is unclear from the code if
they are required for proper operation.
The routines ftruncate(), rename(), mkdir(), and rmdir() are used.
On older Unix systems (binary license) these routines are not available
in the standard libraries.
Before people move to LHARC format wholesale, a version of the lharc sources
should be created which is portable to a larger number of *nix varients.
--
_____________________________________________________________________________
Daniel A. Glasser "Their brains were small and they died."
uwvax.cs.wisc.edu!per2.uucp!dag
---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711-----------
------------------------------
Date: 9 Jan 90 16:32:30 GMT
From: davidli@UMN-CS.CS.UMN.EDU (David Paschall-Zimbel)
Subject: Mac II screen colors (Was: Genlock Inquiry)
Message-ID: <18107@umn-cs.CS.UMN.EDU>
In article <9001091511.AA13450@ucbvax.Berkeley.EDU> MBERNAR@ERENJ.BITNET
(Marcelino Bernardo) writes:
>You're dead wrong on this one. The Mac II series does provide for 16.7
>million colors. Whether you get it or not depends on the video display
>board installed on the Nubus. In front of me is an ad from Radius for
>their DirectColor/24 which can simultaneously access every one of the Mac's
>16.7 million colors. They also make a 16-bit board (32,768 colors simul-
>taneously) and 8-bit board.
Now let's see, what sort of video display unit do we need? 16 million colors
displayed simultaneously would imply 16 million pixels, or a resolution of
16000 x 1000 pixels, or 8000 x 2000 pixels, or 4000 x 4000 pixels.
Considering that such video display units do not appear to exist in the real
world today (if you _do_ know of one, by all means give the address of the
vendor -- and the price!), I highly doubt that there is a display which can
show all 16 million colors "simultaneously".
As an aside, consider that each pixel requires 24 bits (or 3 bytes). The
DISPLAY MEMORY alone would be 48 megabytes in order to display 16 million
colors "simultaneously".
What can we therefore conclude? Although 24-bit Color is possible on a
Macintosh, using non-Apple hardware, there are no Macintosh computers which
can currently display 16 million colors on screen simultaneously. The standard
operating system limit is 256 (ie. buy Apple monitor and RAM card). In order
to be able to display 16 million colors on screen at the same time would
require investment in 48 megabytes of memory (at $100 / meg this is about
$5000), AND use of a video display with a minimal resolution of 4096 x 4096
pixels. I expect that the display would cost more than the memory (by a long
shot).
-- David Paschall-Zimbel
On second thought, the display device probably does exist -- given all of the
wondrous CAD/CAM systems which one can purchase ... but then why bother with
a Macintosh when the 'real thing' probably doesn't cost much more?
------------------------------
Date: 11 Jan 90 22:43:32 GMT
From: pwp@iuvax.cs.indiana.edu (Paul Purdom)
Subject: MIXED
Message-ID: <32896@iuvax.cs.indiana.edu>
Could someone say briefly what techniques the overscan software uses to do
overscanning?
------------------------------
Date: 11 Jan 90 19:11:12 GMT
From: imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt)
Subject: OOPS - BAD PATCH FOR TOS 1.4/1.6
Message-ID: <1947@atari.UUCP>
I posted a patch for TOS 1.4 and 1.6 to this newsgroup, but it doesn't
work. I cancelled the patch itself, but some of you may have gotten
it. In my haste to get the fix out, I didn't test it thoroughly
enough. I'm sorry. Ignore the patch, and keep your eyes out for a
new, correct one.
============================================
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 18:47:05 GMT
From: sumax!amc-gw!pilchuck!ssc!fyl@beaver.cs.washington.edu (Phil Hughes)
Subject: PageStream 1.8 Bug (?)
Message-ID: <374@ssc.UUCP>
In article <9001092309.AA02621@CASPIAN.SAIC.COM>, steveg@SAIC.COM (Stephen
Harold Goldstein) writes:
>
> Well so far I've encountered several problems with the 'debugged' version of
> PageStream (1.8).
>
> Sure glad I didn't jump in until v1.52 was out. I shudder to think what 1.0
> was like.
Yeah, me too and I have 1.0 and 1.1. The really disappointing this is
that rather than fix what is wrong, new features are added. PP 1.01 does
essentially what we need to do. Nothing fancy. We use it to lay out some
of our advertising flyers. All of our "real" publishing work is done on
the UNIX systems.
But, each new version of PP (now PS) adds a whole bunch of stuff plus some
new bugs. I have looked at the options and still don't have the right
answer. FleetStreet 2.0 lacks some stuff. I don't know if 3.0 is good or
not. Calamus is wonderful -- I have played with it -- but I need
PostScript output as we ultimately send stuff to a Linotronic.
--
Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155 (206)FOR-UNIX
uunet!pilchuck!ssc!fyl or attmail!ssc!fyl (206)527-3385
------------------------------
Date: 12 Jan 90 04:32:44 GMT
From:
pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ap
lcen!jhunix!ins_bac@tut.cis.ohio-state.edu (Ajay Choudhri)
Subject: Stacey shippi?ng??
Message-ID: <3936@jhunix.HCF.JHU.EDU>
I spoke to wonderful folks at Computer Emporium in Texas and found out that
they are getting a batch of Stacy1's and 1+20meg HD's in by the end of next week
the prices he quoted me, dont quote this from me, its fuzzy
were 1199 without 20meg and 1599 with..
he said he didn't know when or if he will be getting Stacey2's or 4's..
at least they are appearing(maybe I shouldn't speak so soon)
-Ajay
------------------------------
Date: 11 Jan 90 20:15:20 GMT
From: cbmvax!valentin@rutgers.edu (Valentin Pepelea)
Subject: TOS 1.6 and the 68030
Message-ID: <9299@cbmvax.commodore.com>
In article <1149@crash.cts.com> bradm@pro-grouch.cts.com (Brad Martin) writes:
>
>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
Well, I too work for a company that makes 68030 boards, though not likely to
ever produce ST boards. :-) Now I don't know how TOS is written but I can
tell you what the difference in the processors are.
All user-mode instructions, as opposed to supervisor-mode, are fully upwardly
compatible from the 68000 up to the 68040. Except for the MOVE <ea>,SR
instruction of the 68000 which is now executable only in supervisor mode on
68010+ processors.
This however can be easely fixed through software. Executing this instruction
in user mode on 68010+ processors will cause a priviledge violation exception,
and an exception software handler can substitue the right code there.
Another difference between the 68000 and 68010+ processors is the exception
stack frame created during an exception, such as interrupts. The differences
are small and well documented, but they have to be taken into account anyway.
If Atari provides source code to its OS, then fixing this should be no problem,
particularly on 68030+'s. You see, the 68030 has a built-in MMU, thus allowing
you to load a fake image of ROM in RAM and then translating all memory accesses
to the ROM area to the RAM area.
If source code to the OS is not provided, you're screwed, unless the OS already
takes account of the different exception stack frames created on the different
processors. You can probably disassemble the exception processing code yourself,
since the exception processing routines have their pointers starting at
location 8.
Of course, software which depends on busy-waiting timing loops will be
completely out of wack. So even if you get your act together, that does not
mean that third party software out there does too.
(how would you like to have you ST running at 40mhz?).
Don't hold your breath. Even if you get a processor running at 40MHz, the rest
of the hardware will not. You would have to provide your own 32-bit memory board
to go along the 68030, and it will not be accessible to the blitter or any other
device at high speeds.
By the way, if your friend's company would like to make a board for this 'other'
computer I work on, you know who to have him contact. :-)
Valentin
--
The Goddess of democracy? "The tyrants Name: Valentin Pepelea
may distroy a statue, but they cannot Phone: (215) 431-9327
kill a god." UseNet: cbmvax!valentin@uunet.uu.net
- Ancient Chinese Proverb Claimer: I not Commodore spokesman be
------------------------------
Date: 11 Jan 90 15:08:13 GMT
From: usc!srhqla!quad1!ttidca!woodside@ucsd.edu (George Woodside)
Subject: Viruses
Message-ID: <8940@ttidca.TTI.COM>
In article <21702@uflorida.cis.ufl.EDU> cr1@beach.cis.ufl.edu (Chris Roth)
writes:
...[edited]...
>...I have heard of things called antibodies, that sit in
>your boot sector and do something like flash the screen . The idea
>being that if a virus hits and writes over the antibody, you will
>notice the screen not flashing. Is there currently a program to
>install something like this out?
There are two such "anti-virus" programs that I have copies of.
One spreads itself across disks, just like a virus would. That is,
in my opinion, unacceptable.
The other can be manually installed on a disk, and will do something
like what you ask. I can post it, after I find time to set up a
reasonable install program. It will take a little while, though, since
I'm a little short on spare time...
--
* George R. Woodside - Citicorp/TTI - Santa Monica, CA *
* Path: woodside@ttidca *
* or: ..!?philabs|csun|psivax?!ttidca!woodside *
------------------------------
End of INFO-ATARI16 Digest V90 Issue #35
****************************************
