[comp.sys.atari.st] Msg of Thursday, 17 March 1988 02:14-EST

COMSAT@MC.LCS.MIT.EDU (Communications Satellite) (03/17/88)

FAILED: TETHER at MITLNS.MIT.EDU; Funny reply from foreign host after sending message.
	Last reply was: {554 Unable to deliver mail to given recipient(s)}
 Failed message follows:
-------
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 MAR 88  01:36:59 EST
Received: from XX.LCS.MIT.EDU by OZ.AI.MIT.EDU with Chaos/SMTP; Thu 17 Mar 88 01:34:08-EST
Received: from Score.Stanford.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Thu 17 Mar 88 01:37:59-EST
Date: Wed 16 Mar 88 20:41:31 PST
Subject: Info-Atari16 Digest V88 #121
From: Info-Atari16 Digest <Info-Atari16@Score.Stanford.EDU>
Sender:     Info-Atari16-request@Score.Stanford.EDU
Errors-to:  Info-Atari16-request@Score.Stanford.EDU
Maint-Path: Info-Atari16-request@Score.Stanford.EDU
To: Info-Atari16 Distribution List: ;
Reply-to: Info-Atari16@Score.Stanford.edu

Info-Atari16 Digest   Wednesday, March 16, 1988   Volume 88 : Issue 121

This weeks Editor: Bill Westfield

Today's Topics:

                             Gee whiz...
                      Re: Atari Advertising Idea
                        Re: Atari no-support?
                       Re: Changes/fixes to OS
                            Re: fsel_input
                      Re: Lattice C vs. Megamax
              Why the Atari ST "flame" was posted up...
           Re: WARNING ! Atari ST owners look away now....
           Re: Re: Copyright notices (was: Shareware? Hah!)
                       Copyrights and Coercion
                ST color graphics upgrade in software

----------------------------------------------------------------------

Date: 8 Mar 88 06:14:47 GMT
From: voder!apple!landon@ucbvax.Berkeley.EDU  (Landon Dyer)
Subject: Gee whiz...
To: info-atari16@score.stanford.edu

Technical content: zero.
If ancient history bores you, please type 'n'.  I gotta flame:

>In article <345@nunki.usc.edu> rjung@castor.usc.edu (Robert Jung) writes:
>>  We know Jack Tramiel can make things move when he really wants to; Putting
>>together a prototype 68000 machine in six months is an amazing task.
>
>Yes, it would have been amazing, had it actually happened.  When Tramiel
>took over Atari, though, there were already people working on a 68000 machine,
>and had been for some time.  Those people were, essentially, the only
>ones that Tramiel kept when he purged the company.  While the final ST
>design might have had significant Tramiel influence (it looks it - it's
>cheap enough), it's pretty clear that the groundwork had been laid before
>he ever came on the scene.

In my younger years I would have sprouted bright blue actinic sparks
and gone for an artery.  Instead I'll just say that "I was there, and
you were not."  We did SO do it in six months.  I'm sure it shows.

(At one early point, the ST was going to be a National 16016 or something.
The ST was essentially designed by Tramiel Technologies Ltd (TTL), oh, days
and weeks -- maybe even a whole month -- before KUJ signed the Warner deal).


When the Flying Tramiel Bros. took over the company, I was a mere (mere?)
video-game writer in a management-impoverished (though manager-rich) part
of the 8-bit games group.  One fine, black day Leonard Tramiel and John
Feagans strode into the coin-op engineering building, hatchets and hoods
and clipboards in hand.  While they were walking down the corridor, a voice
cried out over the announcment system:

	"Imperial storm-troopers have entered the base!  Imperial
	 storm-troopers have entered the base!"

We each had a two-minute interview to save our jobs.  FTB kept fourteen out
of sixty or so engineers.  Very entertaining.  I don't think any of us had
much 68000 experience; they were looking for slaves.  In some respects the
people who were layed-off were the lucky ones....


-Landon

[Disclaimer: Leonard Tramiel and John Feagans are perfectly nice people who
are NOT storm-troopers and who would NOT do anything nasty to anyone else
with a hatchet, though perhaps with a clipboard... :-)]

-- 

I speak for me.

------------------------------

Date: 8 Mar 88 19:29:51 GMT
From: sunybcs!ugthomps@AMES.ARC.NASA.GOV  (Gregory Thompson)
Subject: Re: Atari Advertising Idea
To: info-atari16@score.stanford.edu

Recently on a cabled episode of AIRWOLF they showed a "computer center"
oof sorts in the mountain where they keep airwolf.  Lo and behold the 
keyboard to this computer center was an ST.  Looked like a 1040 too.

Maybe if atari sold more computers to the movie business *wink* *grin*

                            - greg

------------------------------

Date: 7 Mar 88 21:17:15 GMT
From: mcvax!cernvax!ethz!forty2!poole@uunet.uu.net  (Simon Poole)
Subject: Re: Atari no-support?
To: info-atari16@score.stanford.edu

In article <996@atari.UUCP> good@atari.UUCP (Roy Good) writes:
.........
>Engineering currently has in development or planned several variations on 
>the ST, with features to address different needs, as well as general
>enhancements. And great care is being taken to maintain maximum compatibility
>with the current ST/Mega series. These products are all in addition to the
>"basic ST" you all seem to know and for the most part love.
>
Hmmm, the last such "enhancement" was the infamous blitter (which still
has to arrive anywhere in mass quantities). As I've stated numerous times
before,  I don't doubt the qualities of Atari engineering, but Atari still
has to show us that they can get an actual product up and going. And as 
always there is the question of software support, will Atari mangement
make an official statement about a bug fixed GEMDOS version as an example?


-- 
----------------------------------------------------------------------------
UUCP:   ...mcvax!cernvax!forty2!poole			Simon Poole
BITNET: K538915@CZHRZU1A

------------------------------

Date: 7 Mar 88 21:38:25 GMT
From: mcvax!cernvax!ethz!forty2!poole@uunet.uu.net  (Simon Poole)
Subject: Re: Changes/fixes to OS
To: info-atari16@score.stanford.edu

In article <7499@apple.Apple.Com> landon@Apple.COM (Landon Dyer) writes:
>In article <2597@crash.cts.com>, sreeb@pnet01.cts.com (Ed Beers) writes:
......
>> Atari use the $axxx and $fxxx instruction traps.  These are reserved in the
>
>Line-A was used because, well, Apple used it, and it was there.  Line-F was
>used as an optimization (two-byte JSRs so the AES would fit into ROM), and
>is in no way related to the way the ST is "defined" to the outside world.
..........
>> This probably explains why the megas come with a 68000 rather than a 68020.

>Nope.  The ST is pretty stuck in the mud with respect to the 68000, but for
>different reasons.  Moving to a 68020 will be painful for EVERYONE.

Matter of fact, the german computer magazin c't has published a series
of patches for the ROM's that allow you to run most (they claim 99%)
programs with their 68020 board. They use some of the unused Line-A
"instructions" as replacement for the Line-F trap. The main problem is
that you really don't get so much more speed (they claim about 50%)
for the money (if you can use the 68881 you're naturally lucky).





-- 
----------------------------------------------------------------------------
UUCP:   ...mcvax!cernvax!forty2!poole			Simon Poole
BITNET: K538915@CZHRZU1A

------------------------------

Date: 8 Mar 88 22:04:09 GMT
From: pasteur!zooey.Berkeley.EDU!c162-br@ucbvax.Berkeley.EDU  (Warner Young)
Subject: Re: fsel_input
To: info-atari16@score.stanford.edu

In article <3951@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (braner) writes:
>[]


>My biggest complaints about the GEM fsel box have NOT been addressed by
>the posted alternatives.  Here is my wish list, if anybody who's into
>writing such things wants ideas...

>The drive:\directory\subdirectory\*.* entry drives me nuts.
>For one thing, the "*.*" should be the default, without the need
>to type it.  Then there's the very limited editing of that string.
>If it says "A:\*.*" and I just want to change the 'A' to 'B', I have
>to press ESC to clear it all, then retype the whole mess.  Why can't
>I position the cursor anywhere in the string with the mouse, Mac style?
>(yeah, I know, Apple's lawyers would get mad...)  If the "*.*" was
>implicit it wouldn't be so bad.

>Then comes the worst part.  After laboriously typing in the path, I
>ALWAYS, automatically, without any thought, hit RETURN.  Which kicks
>me out of the fsel box, and I have to start all over again.  Why, oh why,
>can't RETURN, at that point, be equivalent to clicking inside the directory
>list?  After all, at that point I already have the fingers on the keyboard!

>Other suggestions:  can't I be a masochist (?) and simply type the full
>pathname, including the file name, into ONE text-edit input field, if I so
>prefer?  Why can't the thing remember where I was last time around (the
>application, really, should do that) (well, "filefix" tries to do that, but
>if my last attempt involved typing in a nonexistant path, it refuses to let
>me in at all the next time).

>- Moshe Braner


	Okay, I am currently at work on a new fsel_input routine.  There
are some things that I've done which I doubt I'll change, like:

	This will be a completely new fsel_input.  It takes a few more
	arguments than the old one, so there's really no way to trap
	for the old one and pop up this one.  Which means, that you can
	use it in your own programs, but existing ones still suffer.

	I will include a string for a title (eg. Delete Junk), so you know
	what you're doing.

	There will be an option to sort the files in several ways, mostly
	like the Desktop does.

	Re-selecting the drive letter will be handled through two
	arrow buttons (up and down through the alphabet).

Aside from that, since I'm not yet done, I'm open to suggestions.
I'll try to work in as much as possible, while keeping it compact.
When I'm done, I'll be glad to release the source.  BTW, I am using
Alcyon 4.14, just in case those of you with different C compilers
need to know.

	Email me your suggestions, and we'll see what happens...

\        /arner	- Writer of the dreaded Safety Seal Reviews
 \  /   /	- Owner of the vaporware group Safety Seal Software
  \/ \_/oung
       |	- Disclaimer:  I'm not associated with any of the companies
     \_|		above, in any way except (possibly) as a customer.

------------------------------

Date: 7 Mar 88 10:08:52 GMT
From: mcvax!ukc!dcl-cs!bath63!pes@uunet.uu.net  (Smee)
Subject: Re: Lattice C vs. Megamax
To: info-atari16@score.stanford.edu

Well, since you say you have Lattice C, but not the latest version, I'd
suggest that the first thing to try is getting an upgrade.  3.04 has a
greatly expanded library over the earlier ones, runs a bit faster, and
produces much faster code.  Probably cheaper than a whole nother new C.

------------------------------

Date: 7 Mar 88 10:13:58 GMT
From: mcvax!ukc!mupsy!liv-cs!sqrkl@uunet.uu.net
Subject: Why the Atari ST "flame" was posted up...
To: info-atari16@score.stanford.edu

> 	I didn't ask for it.  You are certainly entitled to your
> 	opinions, but WHY would you post this to comp.sys.atari.st?
> 	Are you trying to stir up some excitement, or what?
> 	If you guys want to rant and rave about stupid things like this,
> 	why not keep it to yourself?  Mail is good for that, you know.  

Normally, I would have kept it to myself (and MAILed directly to the
person involved), but I was angry with the person who'd "flamed" me just
because I put a personal opinion at the end of one of my postings.
I don't like being accused of posting "childish bulls**t" and being told
to take a course in logic (???), so I thought other people should see
some extracts from his MAIL to me, along with some 'arguments' he requested
I supply...
  Anyway, if you want to see a GOOD machine, forget the Amiga, Macintosh and
Atari ST - buy an Acorn Archimedes...I've been programming in ARM (RISC) code
for a couple of months now and it is BEAUTIFUL (so's the Archimedes - puts
all other machines below a MicroVAX 3500 to shame).

Richard K. Lloyd,          ***************************************************
Computer Science Dept.,    * JANET : SQRKL@UK.AC.LIV.CSVAX                   *
Liverpool University,      * UUCP  : {backbone}!mcvax!ukc!mupsy!liv-cs!SQRKL *
Merseyside, England,       * ARPA  : SQRKL%csvax.liv.ac.uk@nss.cs.ucl.ac.uk  *
Great (?) Britain.         ***************************************************

"I have VERY strong opinions which are nothing whatsoever to do with the
University of Liverpool, so blame ME if I bitch about useless IBM PC clones,
even more redundant IBM mainframes and the terrible Atari ST..."

------------------------------

Date: 8 Mar 88 16:01:15 GMT
From: silver!stowe@iuvax.cs.indiana.edu  (holly)
Subject: Re: WARNING ! Atari ST owners look away now....
To: info-atari16@score.stanford.edu

[much deleted...]

I think Jim's point is that most of us want to see useful postings
in comp.sys.atari.st about how to make better use of the equipment
that we own rather than someone's opinion that we should have
purchased some other equipment regardless of the faults.  Every
system has bugs.  I have yet to see the perfect operating system
or perfect hardware.

Holly

-- 
UUCP:  rutgers!indycms.bitnet!ihls400
GEnie:  HS
Bitnet:  IHLS400@INDYCMS
Arpanet:  ihls400%indycms.bitnet@(wherever you like)
Internet:  stowe@silver.bacs.indiana.edu
The secret to happiness is how well you cope with Plan B.

------------------------------

Date: 8 Mar 88 05:51:22 GMT
From: mcvax!unido!tub!tmpmbx!netmbx!hase@uunet.uu.net  (Hartmut Semken)
Subject: Re: Re: Copyright notices (was: Shareware? Hah!)
To: info-atari16@score.stanford.edu

In article <160@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes:
>
>My point was that "legal" or not, and regardless of any discussions
>to that effect here or elsewhere:  DON'T GET YOUR HOPES UP.  The
>authorites showed no desire to help a small software company in Oakland;
>that includes both US and German authorites (police and Fed. agencies).
I almost don't believe that, but... yes, possible.
>
>In other words: you can read and discuss laws and legalities all you want,
>but in the *real world* all this means very little.

THAT ist awfully true.
We all now about piracy, do we?

There was an attempt to stop piracy: if you can't stop it, legalize it.
Make the program shareware (back to the original subject...)

My opinion? Shareware ist a great thing... if anybody pays (like me;
now)...

hase
-- 
Hartmut Semken, Berlin (West) (*east of West-Germany :-)
hase@netmbx.UUCP
I think, you may be right in what I think you're thinking. (Douglas Adams)

------------------------------

Date: 8 Mar 88 19:14:43 GMT
From: hyper!guest@umn-cs.arpa  (guest)
Subject: Copyrights and Coercion
To: info-atari16@score.stanford.edu

I tried to keep myself from posting this, I know it will just encourage
them to keep harping on the issue, but I just can't go on silently
suffering their non-logical assertions.  So ...

The issue is copyright infringement, software piracy, idea theft or
whatever else you like to call it.  My perspective is not whether
such things are currently illegal, but whether there is coercion
involved, and just who is invoking the coercion.  

"Define your terms!"

     Coercion - The initiation of the use of physical force, or the
                the threat thereof.

     Fraud    - (I will avoid defining the term fraud, except to say
                 that it is non-passive -- it requires the initiation
                 of some action.)

     Theft    - The use of coercion or fraud to obtain some value.


Is it possible for someone to violate the copyright law without engaging
in coercion or fraud?  Yes!  In fact that is the most common form of
piracy.  Is such piracy theft?  No! (By my definitions. Not by legal
definitions which have nothing to do with logic.)

Is it possible for a copyright holder to enforce his copyright without
the use of coercion?  No! (In most cases.)  Ironically the copyright
holder who uses coercion to maintain his asking price is directly
obtaining value by that act.  The copyright holder is the thief!!!!

Your mission, should you decide to accept it is to show that my premises
(definitions) are not robust, or that I erred in their application. (logic)

- John M. Logajan            {...!rutgers!} umn-cs!hyper!ns!logajan
- Network System Corp.;  7600 Boone Ave;   Brooklyn Park,  MN 55428

------------------------------

Date: 8 Mar 88 19:29:32 GMT
From: tektronix!tekig!tekig5!wayneck@ucbvax.Berkeley.EDU  (Wayne Knapp)
Subject: ST color graphics upgrade in software
To: info-atari16@score.stanford.edu

Lets do a software upgrade to the ST's graphics.  I'm willing to work on a
program that will allow more than 16 colors per scan line and release it to
the public domain so that it can be used by anyone.  Some time ago I wrote a
program that loaded the palette registers every scan line based on the line
return interrupt. (Horizontal blanking interrupt)  It had some problems due
to sloppy timing, but it did get the job done.  I had hoped that it would
leave plenty of free time for other processing, but actually due to saving and
restoring the registers it only left a few microseconds per scan line over.

Later I bought ColorBurst (some of you may remember), I was very disapointed.
Then I bought Spectrum and I was very impressed.  So seeing that spectrum had
licked the timing problem I got to thinking again.  Wouldn't it be great if I
could use Spectrum pictures in my own code!  So I need two things, first the 
file format of Spectrum pictures and second some code to allow more than 16
colors a scan line.  Maybe someone out in netland can give us the file format.
By the way I highly recommend Spectrum, and in no way would hope to reduce
the value of that product.  In fact if other programs could use Spectrum
pictures I would hope that it would enhance the sales of Spectrum.  If any of
the Spectrum programmers are out there I would be interested in their input.

Anyway lets get down to business.  After seeing Spectrum I knew it could be
done so I thought about it some more.  Then I wrote a program that ran a very
tight loop and just look at the value of the screen pointer and saved the values
in an array.  Sort of an built in logic analyize.  I going to do a better one
in assembly, still the data I got back was interesting.  There are 60 frames
a second and 200 scan lines a frame.  There is 2 to 3 milliseconds dead time
between frames and each scan line in about 85 microseconds long.  On the scan
line 60 microseconds is spent during the display of the graphics information
and about 25 microseconds is horizontal retrace.  The ST already has some code
executing during vertical retrace, but about 1.8 milliseconds if free.

Armed with that data I have a plan, and this is where I ask for help, maybe
some of you will have better ideas.  Remember I plan to release this code to 
the public domain, which means anyone can use it in any program, even for 
programs that they plan to sell.

Here is the plan.  Since using the horizontal retrace interrupt gained me so
little I decide to just use the whole screen time. (I sure this is how spectrum
must work).  The program would consist of the users program running in the
vertical retrace period (about 10% of the time) and the display code running the
rest of the time.  It may be possible to strip out the current vertical blank
code and get more time.  Of course you may lose some things like the clock, but
so what.  During the screen refresh time all interrupts would be turned off and
the code would be written so that the number of cycles through the color 
changer code would equal the number of cycles per scan line.  Something like 
the following:

    User Program 
      Wait for vertical retrace free time
      Set timer for 1.8 milliseconds  (could be different than 1.8)
      User code

    Timer Program 
      Put ST is supervisor mode
      Turn off all interrupts    (ori.w #0700,SR)
      watch the screen memory pointer until it starts counting
      use the first scan line to sync code
      for 199 lines
        reload color registers as much as possible
      Turn on interrupts
      Wait for vertical retrace free time
      Set time for 1.8 milliseconds
      return to user code


There are several ways to do the color register reloading.  The one I favor is
to wait until the first horizontal retrace and then blast in new vales as fast
as possible.  Maybe use move multiple during retrace and move (a1)+,(a2)+   
during the actual screen refresh to get even timing some one would know where
on the line which color registers are valid.  This would be simple and means
that the file formate would be color register values for 320X199 picture and
the pixels values for a 320X199 picture.  Another way would be to use move
quicks and actually have the program write a the color register changer   
routine.  This is a couple of cycles faster per color change, but the code
is much longer, plus the setup time would be longer.

So here are the ideas so far:

       movq.l D0,#color data for 2 registers           (18 cycles)
       move.l D0,(A0)+   a0 points to color registers
       etc.   

Or just
       move.l (A1)+,(A0)+                              (20 cycles)
       etc.


Also during horizontal retrace  to get a full change over

       move.m (A1)+,register set                       (104 cycles)
       move.m register set (A0)+
 

I think there are about 680 cycles to work with, unless my spy program has
a bug.  Anyway it will be easy to find out.

Anyway any more ideas? 

                                Thanks,
                                  Wayne Knapp

------------------------------

End of Info-Atari16 Digest
**************************
-------