========================================================================= 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 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: 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).