=========================================================================
 
INFO-ATARI16 Digest         Mon, 16 Apr 90       Volume 90 : Issue  451
 
Today's Topics:
                             cad packages
             FAST ST SPRITES !!!!!!!!!!!!!!!!!!!!!!!!!!!
                         MacIntosh Emulators
                         Request for Opinions
                 Severe Dcreate() bug in GEMDOS 0.23
   Small Unix for Small systems? (Was: One world, One CPU, One OS)
----------------------------------------------------------------------
 
Date: 16 Apr 90 17:24:46 GMT
From: att!dptg!lzsc!hcj@ucbvax.Berkeley.EDU  (HC Johnson)
Subject: cad packages
Message-ID: <1617@lzsc.ATT.COM>
 
In article <15107@cbnewsc.ATT.COM>, cagle@cbnewsc.ATT.COM (robert.cagle) writes:
> I want to purchase a CAD program for my 1040ST
> to help me design some woodworking projects.
>
> I would like to stay close to $100, so I think
> Dyna-Cadd should stay out of the dicussion.
>
I have Athena II; its $100, and works.
 
Howard C. Johnson
ATT Bell Labs
att!lzsc!hcj
hcj@lzsc.att.com
 
------------------------------
 
Date: 16 Apr 90 22:30:57 GMT
From: sdcc6!icogsci1!cg108fcv@ucsd.edu  (Some call me...Tim)
Subject: FAST ST SPRITES !!!!!!!!!!!!!!!!!!!!!!!!!!!
Message-ID: <9747@sdcc6.ucsd.edu>
 
In article <3143@umbc3.UMBC.EDU> petey@umbc5.umbc.edu () writes:
>
>Hey everyone:
>This one to the ASSEMBLY HACKS out there.
>
>Has anyone written a sprite routine that can beat the Line-A routines
>is the ST?  Without using multiple copies of the sprite offset by 1 pixel
>so that it can be put onto non-byte boundries???
 
It's not that difficult.  The Line-A routines are extremely
generalized, so if you optimize your code sufficiently for the
specific task you have in mind, it should go faster.
 
>It seems that since the line-a routines are in rom and can be READ faster
>therefor executed faster that this is not possible.  But ive heard people
>claim they can do it.
 
This is NOT true.  The RAM and ROM read at the same speed in the
Atari ST.  The Mac, on the other hand, is another story, taking up
to twice as long to read from RAM as ROM, depending on the model...
 
Also, look at Quick ST.  It's doing the job better than the Line-A
routines.
 
>I would like some psuedo-code or code to do this.
>Code for a monochrome monitor ( 1 BIT PLANE ) would be perferred, just so
>we dont have to mess with the strange way the ST uses 4 bitplanes.
 
Actually, I saw a nifty way to do things that took SERIOUS advantage
of the four bitplanes, but I'm under non-disclosure with regard to
that--sorry.
 
>I wrote a routine that put the sprite to the screen byte by byte shifting
>each byte as required.  The line-a  routine was still about 3 times faster
>and my routine only used adds, shifts, and moves.
>
>well, has ANYONE out there done this?
 
Sounds like your algorithm needs optimizing.  Try expanding loops
out--remember that dbra takes 18 cycles when it loops.  And try to load
the data by long words if you can--that's MUCH faster than loading a
byte at a time.  You do have the Motorola manual, or some other book
with the 68000 cycle times in it, don't you?
 
Actually, the biggest speedup is in the shifting:  Do the shift ALL
AT ONCE.  And save the other half, so you only have to do one shift
per word instead of two per byte.
 
The nifty routine I mentioned above actually did one shift per TWO
words, so that's the ultimate that I've seen in sprites...
 
----------
Tim Mensch
tmensch@ucsd.edu
 
------------------------------
 
Date: 16 Apr 90 23:26:36 GMT
From: nsc!amdahl!rtech!davemc@decwrl.dec.com  (David McAllister)
Subject: MacIntosh Emulators
Message-ID: <5260@rtech.Ingres.COM>
 
Hi,
 
As a new owner of an Atari ST, I've got a few questions:
 
1) (of major concern (-:) to justify the expense, I need to find a copy
of Adventure (yeah, the old text only adventure game). Anyone got a suggestion?
 
2) My company uses Mac's for almost everything (except Email).  Could
someone provide me a comparison of MAC emulators and/or point me to
such a beastie?  (I bought an Atari because I prefer it; I'd like to
cross my files over (particularly things created in POWERPOINT) for work.)
 
3) Is anyone aware of a DISPLAY POSTSCRIPT type of program for Atari?
 
Thanks for the help.  While I can talk Unix and VMS all day, I am definitely
not Atari literate (yet).  I promise to educate myself as fast as possible,
with ya'll help.
 
Dave McAllister
davemc@badger.ingres.com
 
 
* My opinions are my own, nobody here listens to me either *
    * Memory configuration in use: write-only *
        * The ultimate home computer: Calvin powered, Hobbes user interface *
 
------------------------------
 
Date: 17 Apr 90 02:45:22 GMT
From:
 cs.utexas.edu!news-server.csri.toronto.edu!neat.cs.toronto.edu!omicron.cs.fsu.e
 du!fsucs.cs.fsu.edu!boyd@tut.cis.ohio-state.edu  (Mickey Boyd)
Subject: Request for Opinions
Message-ID: <9004170242.AA28927@fsucs.cs.fsu.edu>
 
In article <9004160432.AA29646@xap>, stewart@xyplex.com (Bob Stewart) writes:
>I'm considering some additions to my 520ST system and would appreciate
>opinions (preferably from experience) on my tentative selections.
>
>    1.  2400-baud modem - SupraModem 2400.
 
  Good choice.  Best hundred bucks I have spent.
 
>
>    2.  Double-side floppy drive (yes, I'm suffering with a single,
>        single-sided drive - Master 3S from Konyo International.
 
  I would try to verify that the drive can format out to 85 tracks.  You
  would probably never want to do it, but the 82 track/10 sector twisted
  format is nice.  Beware of drives that make a funny click when reading
  past track 80.  Also, you might want to check out the Blitz cable copier.
  It should work with one single and one double sided (you could probably
  only copy single sided disks, but it's better than making it an ashtray).
 
>
>    3.  C compiler, etc. - Megamax Laser C and Laser source debugger.
 
  You might wish to try one of the PD offerings:  Sozobon and GNU C.  They
  might not work on a 520 though.  Also, Prospero C is ANSI standard, and
  they are really good about supporting their stuff.  Were I in your position,
  I would probably expand memory to 2.5 megs and give myself the option of
  using Sozobon or Gnu C.  The extra memory is really nice, I have a Mega2ST
  and could not imagine not having at least 2 megs on an ST!  If I could find
  a really reliable way to do it, I would expand to 4 megs in a second.
 
>
>Thanks,
>
>       Bob
>
>-----------
>Bob Stewart (rlstewart@eng.xyplex.com)
>Xyplex, Boxborough, Massachusetts
>(508) 264-9900
 
 
--
 
    -----------------------------------------------------------------------
    ---------------------------------+-------------------------------------
              Mickey Boyd            |    "Nobody can be exactly like me.
          FSU Computer Science       |      Even I have trouble doing it."
        Technical Support Group      |
      mail:  boyd@fsucs.cs.fsu.edu   |              - Tallulah Bankhead
    ---------------------------------+-------------------------------------
    -----------------------------------------------------------------------
 
------------------------------
 
Date: 16 Apr 90 19:32:10 GMT
From: fernwood!portal!atari!apratt@uunet.uu.net  (Allan Pratt)
Subject: Severe Dcreate() bug in GEMDOS 0.23
Message-ID: <2148@atari.UUCP>
 
alderaan@tubopal.UUCP (Thomas Cervera) writes:
>there seems to be a severe bug in GEMDOS 0.23's Dcreate() Call (TOS 1.?4,6?).
>If you have a file with a given name somewhere on your disk and you create a
>directory with the same name at the same path location, this Dcreate call
>completes SUCCESSFUL!
 
I can't make this happen.
 
        #include <osbind.h>
        main()
        ?
                int fd;
                long err;
 
                fd = Fcreate("silly",0);
                Fclose(fd);
                err = Dcreate("silly");
                printf("err is %ld\n",err);
                exit(0);
        ?
 
prints "err is -36" (EACCDN, access denied).  I'm using TOS 1.4's GEMDOS.
 
============================================
Opinions expressed above do not necessarily     -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.      ...ames!atari!apratt
 
------------------------------
 
Date: 16 Apr 90 21:51:11 GMT
From: granite.pa.dec.com!mwm@decwrl.dec.com  (Mike (Real Amigas have keyboard
 garages) Meyer)
Subject: Small Unix for Small systems? (Was: One world, One CPU, One OS)
Message-ID: <MWM.90Apr16145111@raven.pa.dec.com>
 
In article <1990Apr14.155106.2692@watdragon.waterloo.edu>
 swklassen@tiger.waterloo.edu (Steven W. Klassen) writes:
 
   Contrary to popular belief UNIX does NOT require 4-8 meg of
   ram and 80+meg hard disks.  (Especially if you leave out the on-line
   help.)  I have seen very useable UNIX look-alikes (namely Minix) operate
   quite well on 1 meg machines (Atari 1040ST) with only 20 meg of the
   hard drive dedicated for it.
 
Ho hum. I've seen _real_ Unix run on smaller machines - 256K and a 10
meg disk. I've seen clones run on _much_ smaller machines - say 32K
and a single floppy.
 
The problem with all these is that they are v6 or v7 Eunices, not
anything modern. Missing things like process control, networking,
modern tty drivers, windowing systems, etc. Adding those things adds a
lot to the size of the system. Worse yet, adding the necessary parts
to the kernel to support those things adds a lot to it's complexity.
That's why the clones tend to be v7-oid clones, and not 4.3 or Vr4
clones.
 
Of course, you _can_ run a full-fledged, modern Unix system in 1 meg
of real memory and 20 meg of disk (but not the 256K version I used to
run on PDP 11s). However, you won't be very happy. The kernel will
probably run 300K or more; leaving 700K of real memory for your
applications. The window system server eats up about as much space as
the kernel, and simple applications about 2/3rds that. In other words,
you're going to have trouble getting the kernel, window manager & two
terminal windows in memory. Now add a large application (emacs, or a
postscript previewer, or some such), and your system is going to be
going to the disk a lot. Not much fun. But you probably don't have a
windowing system, as the X11R4 binary distribution is ?40Meg, not
including most of the user-contributed software.
 
The 4-8meg/80meg of disk claim isn't a minimum to run Unix; it's a
minimum to provide the kind of environment that Amiga users are used
to (I don't know the Atari, so I don't know what users are used to; I
don't think an off-the-shelf Unix system is capable of providing the
kind of environment that Mac users are used to, unless it's from
Apple). But unless you are a rabid Unix fan, you probably aren't
willing to give up windowing and multiple shells and the like just to
get Unix.
 
I'd be glad to have a counterexample. A fully functional Unix system,
complete with window manager, SLIP, UUCP, cron daemon, and the ability
to provide reasonable perforamance to both an editor, a terminal and
multiple trivial applications (xsnap, xclipboard, xwd and xmessage,
for isntance) at the same time as all the above are running (hint:
choose something with shared libraries - they help a lot!). Make it
all fit in 1 or 2 meg of memory, and run from 30 meg of disk (that
seems to be the new "smallest" disk).
 
        <mike
 
 
 
 
 
 
--
All around my hat, I will wear the green willow.        Mike Meyer
And all around my hat, for a twelve-month and a day.    mwm@relay.pa.dec.com
And if anyone should ask me, the reason why I'm wearing it,     decwrl!mwm
It's all for my true love, who's far far away.
 
------------------------------
 
End of INFO-ATARI16 Digest V90 Issue #451
*****************************************
