Info-Atari16 Digest Thu, 6 Jun 91 Volume 91 : Issue 319 Today's Topics: Atari TT Autobooting Drive C Black Cauldron Wanted! Color monitor replacement? FSM-GDOS...When? How? GIF decompressor in GFA Basic 3.0 (not a viewer) Hard-drive on a 520ST? (2 msgs) Man w/ pipe (2 msgs) More than 4 Meg ?? (2 msgs) Neophyte question: what's Blitter? Re: Man w/ pipe XOR (Was RE: More than 4 Meg?) Welcome to the Info-Atari16 Digest. The configuration for the automatic cross-posting to/from Usenet is getting closer, but still getting thrashed out. Please send notifications about broken digests or bogus messages to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU. Please send requests for un/subscription and other administrivia to Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list instead of the moderators are likely to be lost or ignored. If you want to unsubscribe, and you're receiving the digest indirectly from someplace (usually a BITNET host) that redistributes it, please contact the redistributor, not us. ---------------------------------------------------------------------- Date: 5 Jun 91 09:57:34 GMT From: mcsun!hp4nl!star.cs.vu.nl!hvaalde@uunet.uu.net (Aalderen van Harold) Subject: Atari TT To: Info-Atari16@naucse.cse.nau.edu apratt@atari.UUCP (Allan Pratt) writes: >You can buy a 2MB ST RAM add-on card, for a total of 4MB of ST RAM. There >may one day be an 8MB ST RAM add-on card, resulting in a total of 10MB >of ST RAM. >You can buy a 4MB TT RAM add-on card. It may be that, with some work, you >can make this address 16MB of TT RAM. In future (now?) you can buy 16MB of >TT RAM from Atari -- I'm just not sure. Since where on the subject now. Is there a legal way to find out the begin and end adresses of the ST-RAM and the same for TT_RAM And for the ROM? I want to write a routine that as some 32 bit number as input and assuming that it is an address it determines if it is ROM, ST_RAM or TT_RAM or just JUNK and if it lies in the system part of RAM or in the TPA part. any info appreciated? Harold van Aalderen (hvaalde@cs.vu.nl) ------------------------------ Date: 7 Jun 91 03:01:21 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!spool.mu.edu!agate!darkstar!ucscb.UCS C.EDU!rome@arizona.edu (60380000) Subject: Autobooting Drive C To: Info-Atari16@naucse.cse.nau.edu I am borrowing my friend's Mega 2 for the summer and he has an SHS205 hard drive attatched. When I got it, it would boot all of the stuff in the AUTO folder on the C partition (actually, that was the only thing that it would boot, it would not read a floppy at bootup!) I seemed to have messed something up and now it will not boot off the hard drive, I have to boot off a floppy and with all of the utilities, it takes forever. Does anyone know how I can fix the C partition to autoboot again??????? Thanks, Roman Baker ------------------------------ Date: 6 Jun 91 15:14:39 GMT From: aurs01!whitcomb@uunet.uu.net (Jonathan Whitcomb) Subject: Black Cauldron Wanted! To: Info-Atari16@naucse.cse.nau.edu Does anyone have a copy of the game Black Cauldron that they wish to unload, or know where I can still purchase a copy? I've just started re-reading the Prydain Chronicles by Lloyd Alexander, and thought it would be fun to play the game after reading the book. Thanks! ********************************************************************** Jonathan Whitcomb UUCP: Alcatel Network Systems, Raleigh, NC Delphi: JBWHIT ------------------------------ Date: 6 Jun 91 17:28:35 GMT From: noao!asuvax!ncar!elroy.jpl.nasa.gov!wciu!abode!scale@arizona.edu (Luis Outumuro) Subject: Color monitor replacement? To: Info-Atari16@naucse.cse.nau.edu Hi David, $230 is a very fair price for a brand new monitor! By all means, get the new monitor. Bye............. Luis ------------------------------ Date: 6 Jun 91 20:03:36 GMT From: tempest.Berkeley.EDU!kawakami@ucbvax.berkeley.edu (John Kawakami) Subject: FSM-GDOS...When? How? To: Info-Atari16@naucse.cse.nau.edu In article <1991May31.191105.13736@lonex.radc.af.mil> longj@lonex.radc.af.mil (Jeffrey K. Long) writes: >Questions: >1) When will it be relesed ? According to a letter from Goldleaf, there is less than two weeks before it is released. Seems that Goldlead is just itching to send it out ASAP (after all, they have possibly the only FSM-ready program on the market, thus the new GDOS is a selling point.) >2) Who will handle distribution (Atari Directly, or through dealers, mail > order, ...)? Probably all channels. I would hope that they distribute it in addition to the old GDOS (in software packages.) >3) What will it cost, and will it include (as I have heard rumoured) drivers > for most printers including the HP DeskJet (original version)? Cost? Beats me. It's supposed to include a DJ driver, as well as an HP Laserjet driver and Epson drivers. They'd be stupid to drop any drivers in the package. >4) Can I get it now by buying Goldeaf's Wordflair II? No. They are going to charge cost plus shipping and handling when they sell FSM. >---------------------------------------------------------------------------- >Capt Jeff Long Rome Laboratories, Griffiss AFB, NY >longj@lonex.radc.af.mil (preferred) Network Design Laboratory >jlong@cassiopeia.radc.af.mil (315)330-7751 or (DSN)587-7751 John Kawakami kawakami@ocf.berkeley.edu ucbvax!ocf.berkeley.edu!kawakami ------------------------------ Date: 6 Jun 91 23:31:06 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio -state.edu!linac!uwm.edu!spool.mu.edu!cs.umn.edu!uc!noc.MR.NET!ns!ns!logajan@ar izona.edu (John Logajan) Subject: GIF decompressor in GFA Basic 3.0 (not a viewer) To: Info-Atari16@naucse.cse.nau.edu REM This GFA Basic 3.0 program unpacks the images in GIF files, creating RGB REM color tables, and an uncompressed image array. Each byte in the image REM array points into the intensity values in the RGB color tables. This means REM the image can contain only 256 different colors, but those colors can be REM selected from a palette of 16.7 million. REM REM *THIS IS NOT A COMPLETE PROGRAM* It does not display the GIF images. REM I leave that up to you to figure out how to do. Good luck. By the way, REM this is pretty slow. It does run much faster if compiled. REM REM Totally original code by John Logajan, June 6, 1991. I don't know what REM legal status it has, as CompuServe owns GIF, and I've heard rumors that REM the owners of the LZW compression routines aren't happy with CompuServe. REM If it was up to me, this code would be released into the public domain. REM INPUT "Filename: ",a$ OPEN "I",#1,a$ DIM pcl|(260),prep&(4097),scar|(4097),temp|(4097) pcp%=VARPTR(pcl|(0)) sig$="" version$="" FOR j&=1 TO 3 sig$=sig$+CHR$(INP(#1)) NEXT j& FOR j&=1 TO 3 version$=version$+CHR$(INP(#1)) NEXT j& IF sig$="GIF" ! Check for GIF signature. swidth&=INP(#1)+INP(#1)*256 ! Some sort of screen size sheight&=INP(#1)+INP(#1)*256 ! neither of which I use. tmp|=INP(#1) global!=BTST(tmp|,7) ! Check for Global Color Map. gpixel&=(tmp| AND 7)+1 ! Global bits per pixel. gcolres&=(SHR|(tmp|,4) AND 7)+1 ! Color range. I don't use. gbackground&=INP(#1) ! Background color. I don't use. tmp|=INP(#1) IF global! ! We have a Global Color Map. crange&=SHL(1,gpixel&) ! Color range. pixel&=gpixel& ! Bits per pixel. DIM r|(crange&),g|(crange&),b|(crange&) ! RGB color map reserved. FOR j&=0 TO crange&-1 ! Go gety the map RGB values. r|(j&)=INP(#1) g|(j&)=INP(#1) b|(j&)=INP(#1) NEXT j& ENDIF REPEAT ! Main Image(s) Loop sep|=INP(#1) IF sep|=&H21 ! Throw away any Extension Blocks tmp|=INP(#1) DO bc|=INP(#1) EXIT IF bc|=0 FOR j&=1 TO bc| tmp|=INP(#1) NEXT j& LOOP sep|=INP(#1) ENDIF IF sep|=&H2C ! Look for Image Descriptor Start offleft&=INP(#1)+INP(#1)*256 ! Some sort of offset, I don't use. offtop&=INP(#1)+INP(#1)*256 ! I don't use. width&=INP(#1)+INP(#1)*256 ! Image width (pixels) height&=INP(#1)+INP(#1)*256 ! Image height (pixels) imglen%=width&*height& ! Total pixels in the image. DIM pic|(imglen%+256) ! Reserve image space + spare room. pici%=0 tmp|=INP(#1) uselocal!=BTST(tmp|,7) ! Look for Local Color Map interlace!=BTST(tmp|,6) ! See if image is interlaced. lpixel&=(tmp| AND 7)+1 ! Local bits per pixel. pass|=0 hline&=0 vcol&=0 lstep&=8 IF uselocal! ! We have a Local Color Map crange&=SHL(1,lpixel&) ! Color range pixel&=lpixel& ! Bits per pixel IF NOT global! DIM r|(crange&),g|(crange&),b|(crange&) ! Reserve room for color map. ENDIF FOR j&=0 TO crange&-1 ! Go fill local color map. r|(j&)=INP(#1) g|(j&)=INP(#1) b|(j&)=INP(#1) NEXT j& ENDIF PRINT crange&;" colors." PRINT width&;" * ";height& REM REM This is the LZW decompresser REM initcodesize&=INP(#1) ! How many bits in first code. clearcode&=SHL(1,initcodesize&) ! Now we know the clear code. eofcode&=clearcode&+1 ! Now we know the eof code. firstfree&=clearcode&+2 ! Where to put first incoming code. FOR j&=0 TO clearcode&-1 ! We put roots into string table. REM Prep&() entries point to the previous character prep&(j&)=5000 ! Are roots so we make them too big. REM scar|() entries are the actual string value at that point scar|(j&)=j& NEXT j& INC initcodesize& cbp&=0 cpt&=0 lpt&=0 GOSUB codeclear ! Let's get started. REPEAT ! Do a whole compressed image. GOSUB getcode ! Get a code. IF code&=clearcode& ! Always test it for clear code. GOSUB codeclear ELSE IF code&=maxcode& ! Look out for variable sized codes. IF codesize&<12 ! Don't go over 12bit limit. INC codesize& ! Adjust code size up one bit. maxcode&=SHL(1,codesize&) readmask&=maxcode&-1 ENDIF ENDIF ENDIF UNTIL code&=eofcode& ! We're out'a here. sep|=INP(#1) ENDIF UNTIL sep|=&H3B ! Look for GIF Terminator REM PRINT "Your code goes here." REM REM pic|() contains image, one byte per pixel -- pointing into RGB maps. REM The image data in pic|() is left to right, top to bottom REM i.e. The first 640 bytes of a 640 pixel wide image make up the first REM horizontal line, the next 640 bytes make up the second line... REM width& = number of horizontal pixels (bytes) REM height& = number of vertical pixels (bytes) REM r|() contains the red level values 0-255 intensities. REM g|() contains the green level values 0-255 intensities. REM b|() contains the blue level values 0-255 intensities. REM crange& = the number of entries in each color map. REM REM Have fun. REM ELSE PRINT "Not a GIF file." ENDIF END PROCEDURE getcode REM This routine extracts code bits out of a very long bit stream. REM cpt&=current byte in the buffer block REM cbp&=current start bit in the byte REM codesize&=current code bit width REM lpt&=last byte in the buffer block sumb&=codesize&+cbp& smo%=lpt&-cpt& REM A 10 bit code can span 3 bytes, so there are many cases to handle. IF sumb&<=8 IF smo%<1 GOSUB getblock ENDIF code&=SHR&(pcl|(cpt&),cbp&) AND readmask& IF sumb&=8 INC cpt& cbp&=0 ELSE cbp&=sumb& ENDIF ELSE IF sumb&<=16 IF smo%<2 GOSUB getblock ENDIF code&=SHR&(pcl|(cpt&),cbp&) OR SHL&(pcl|(cpt&+1),8-cbp&) AND readmask& IF sumb&=16 ADD cpt&,2 cbp&=0 ELSE INC cpt& cbp&=sumb&-8 ENDIF ELSE IF smo%<3 GOSUB getblock ENDIF code&=SHR&(pcl|(cpt&),cbp&) OR SHL&(pcl|(cpt&+1),8-cbp&) OR SHL&(pcl|(cpt&+2),16-cbp&) AND readmask& REM REM Just in case that line gets truncated in transit, here it is: REM code&=SHR&(pcl|(cpt&),cbp&) OR SHL&(pcl|(cpt&+1),8-cbp&) REM OR SHL&(pcl|(cpt&+2),16-cbp&) AND readmask& REM ADD cpt&,2 cbp&=sumb&-16 ENDIF ENDIF RETURN PROCEDURE getblock REM The image date is broken up in blocks less than 256 bytes long in the REM GIF file. I get one of those blocks whenever I am running short. smo2&=0 WHILE cpt&<>lpt& ! Move any as yet unused bytes from previous pcl|(smo2&)=pcl|(cpt&) ! block up to front. INC smo2& INC cpt& WEND cpt&=0 bc|=INP(#1) lpt&=bc|+smo% IF bc|<>0 ! And then stick the new block on behind. BGET #1,pcp%+smo%,bc| ENDIF RETURN PROCEDURE codeclear REM This clears the code table. It does this right away, and every 4096 REM codes sent thereafter -- and sometimes sooner. freecode&=firstfree& codesize&=initcodesize& maxcode&=SHL(1,codesize&) readmask&=maxcode&-1 REPEAT GOSUB getcode UNTIL code&<>clearcode& GOSUB codeout ! We always send the first code out right oldcode&=code& ! away after a code clear. RETURN PROCEDURE codeout REM This routine expands the code into real image data. oz&=-1 ooz&=code& REPEAT ! I have to extract the string backwards INC oz& temp|(oz&)=scar|(ooz&) ooz&=prep&(ooz&) UNTIL ooz&=5000 pscar|=temp|(oz&) IF interlace! ! A nitwit interlaced image. Bleech. FOR ooz&=oz& TO 0 STEP -1 ! Take the backward string and put it into IF vcol&=width& ! the picture image, forwards. vcol&=0 hline&=hline&+lstep& ! Set up the crazy interlace cases. IF hline&>=height& INC pass| IF pass|=1 lstep&=8 hline&=4 ENDIF IF pass|=2 lstep&=4 hline&=2 ENDIF IF pass|=3 lstep&=2 hline&=1 ENDIF IF pass|=4 hline&=height& ENDIF ENDIF pici%=hline&*width& ! I've figured out where it goes. ENDIF pic|(pici%)=g|(temp|(ooz&)) ! Now I finally put it there. INC pici% INC vcol& NEXT ooz& ELSE ! Ah, a seqential image. FOR ooz&=oz& TO 0 STEP -1 ! Take the backward string and put it pic|(pici%)=g|(temp|(ooz&)) ! into the picture image, forwards. INC pici% NEXT ooz& ENDIF RETURN -- - John Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428 - logajan@ns.network.com, 612-424-4888, Fax 612-424-2853 ------------------------------ Date: 6 Jun 91 16:47:15 GMT From: noao!asuvax!ncar!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!crdgw1!g ecrdvm1!syspmzt@arizona.edu Subject: Hard-drive on a 520ST? To: Info-Atari16@naucse.cse.nau.edu In article <1991Jun5.181758.4095@murdoch.acc.Virginia.EDU>, lch3e@holmes.acc.Virginia.EDU (Lauren C. Howard) says: > >Can a hard-drive (spec. Megafile 30) be used with a stock 520ST? >Will there be enough memory left to run WordPerfect? Timeworks DTP? > >Why are the Megafile 30's being sold off so cheap right now? I know >they're discontinued; but is there anything wrong with them? Are >they upgradeable? > I can't answer most of the questions, but having been in the market for a hard drive recently, I can tell you that every dealer I've talked to about the Megafile 30 has had the same response: "They're really slow. Most of my customers can't deal with anything this slow." Mind that they're dealers with non-Atari drives to sell, but it became the expected response whenever I talked to one of them. I found a 49M 28ns drive from Carter Graphics for $414 that I'm waiting for now. Atari's Megafile was $365 at most places that would touch them. Seemed like a simple choice to me. Phil Z ------------------------------ Date: 6 Jun 91 17:55:07 GMT From: noao!asuvax!ncar!elroy.jpl.nasa.gov!wciu!abode!scale@arizona.edu (Luis Outumuro) Subject: Hard-drive on a 520ST? To: Info-Atari16@naucse.cse.nau.edu Hi Lauren, Yes, a hard drive such as the Megafile 30 can be used with a "stock" 520ST, although I doubt there would be enough memory left to run either WordPerfect or Publisher ST. You could however run the likes of WordWriter and Publishing Partner. Having a hard drive connected to a 512k ST really restricts which programs you can use; this would be an excellent time to upgrade your computer. Megafiles are so cheap now, because hard drive prices are at an all-time low; and this is industry wide (not just Atari). There is nothing wrong with the Megafile 30's; low OEM prices of the mechanism and market competition allow the price to be low. Yes, the Megafile 30's are upgradeable; one of the most popular replacement mechanisms for the Megafile 30 is the Mitsubishi MR535. The MR535 (when connected to a RLL controller, like the Megafile 30 has) is a 65m, 25ms hard drive; it simply plugs and mounts in the same place as the Megafile 30's Seagate ST238R mechanism, although you will need different software to format and partition the drive with (such as Supra's Hard Drive Utilities, Diamond Cache would be nice too). I hope this helps, take care. Bye................ Luis ------------------------------ Date: 6 Jun 91 18:54:48 GMT From: noao!ncar!gatech!prism!mailer.cc.fsu.edu!nu!boyd@arizona.edu (Mickey Boyd) Subject: Man w/ pipe To: Info-Atari16@naucse.cse.nau.edu In article <1991Jun6.131017.12110@ira.uka.de>, S_DINGLER@iravcl.ira.uka.de (|S| Florian Dingler) writes: >Hi folks! > >I wonder if anyone knows who the man smoking a pipe is. You know, the one you >find in the ATARI-ST charset with the codes 28-31 or so. Is he just a little >joke or a special person or what ? >Please write followups, no mail. Bob, from the Church of the Subgenius. Consult your weirdest bookstore for details. -- ---------------------------------+------------------------------------- Mickey R. Boyd | "Kirk to Enterprise. All clear FSU Computer Science | down here. Beam down Technical Support Group | yeoman Rand and a six-pack . ." email: boyd@fsucs.cs.fsu.edu | ---------------------------------+------------------------------------- ------------------------------ Date: 6 Jun 91 21:16:57 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!rpi!news-server. csri.toronto.edu!utgpu!watserv1!roulston@arizona.edu (James Parker) Subject: Man w/ pipe To: Info-Atari16@naucse.cse.nau.edu In article <1991Jun6.161545.14157@rice.edu> bemo@spacsun.rice.edu (Brian D. Moore) writes: >In article <1991Jun6.131017.12110@ira.uka.de>, S_DINGLER@iravcl.ira.uka.de (|S| Florian Dingler) writes: >|> Hi folks! >|> >|> I wonder if anyone knows who the man smoking a pipe is. You know, the one you >|> find in the ATARI-ST charset with the codes 28-31 or so. Is he just a little >|> joke or a special person or what ? >|> Please write followups, no mail. > > Hey buddy, that's Bob Dobbs, leader of the Church of the Sub-Genius. >Slack off! Quit your job! Send your money to Bob!! > So, how do get a look at the Atari character set anyway? Please send em the necessary slack. thanx james ------------------------------ Date: 7 Jun 91 00:42:15 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!mips!pacbell.com!iggy.GW.Vitalink.COM!lll- winken!taco!taco.cc!twmanino@arizona.edu (TONY W MANINO) Subject: More than 4 Meg ?? To: Info-Atari16@naucse.cse.nau.edu >>Nope. TOS 1.6 has a screwed up memory sizer that assumes that if two banks of >>RAM exist then both banks are the same size. I don't know if this is a bug >>in the true sense or malicious crippling but it is sad. >> >>BTW, a bank is two SIMMs since memory access is on a word basis. >> >> 512K = 2 x 256K SIMMs >> 1Mb = 4 x 256K SIMMs >> 2Mb = 2 x 1Mb SIMMs >> 2.5Mb = 2 x 1Mb SIMMs + 2 x 256K SIMMs (Not with TOS 1.6) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >I heard this works on TOS 1.6 if you put the 256k SIMMs as the first bank >and the 1M SIMMs as the second bank. But I could be wrong. If you're >having trouble, though, it's trivial to try it the other way. >> 4Mb = 4 x 1Mb SIMMs There's a file at atari.archive that fixes the 2.5 meg problem... It's called SIMMFIX. You put it in your auto folder. It reprograms the MMU, then does a warmstart. I get 2 bombs on the first boot attempt, but when the machine resets, it does just fine. Any subsequent warmstarts just boot right up. Be sure to read the instructions.... Hope this helps, Tony twmanino@eos.ncsu.edu ------------------------------ Date: 6 Jun 91 15:16:54 GMT From: mcsun!ukc!mucs!els!camm@uunet.uu.net (Ian Camm) Subject: More than 4 Meg ?? To: Info-Atari16@naucse.cse.nau.edu In article <1991Jun5.222630.24777@jato.jpl.nasa.gov> vsnyder@jato.Jpl.Nasa.Gov (Van Snyder) writes: >In article <3153@odin.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes: >>In article <1991Jun4.112631.10649@cs.nott.ac.uk> dpg@cs.nott.ac.uk >>(Dave Gymer) writes: >>> ... I believe, that the MMU in the STe can >>>only handle .25 and 1 meg SIPPS/SIMMS, and these are arranged in two banks, >>>which must contain the same amount (hence, memory configurations can only >>>be .5 meg, 1 meg, 2 meg, 2.5 meg, and 4 meg). I too have a four meg STe. >> ~~~~~~~ >> >>Nope. TOS 1.6 has a screwed up memory sizer that assumes that if two banks of >>RAM exist then both banks are the same size. I don't know if this is a bug >>in the true sense or malicious crippling but it is sad. >> >>BTW, a bank is two SIMMs since memory access is on a word basis. >> >> 512K = 2 x 256K SIMMs >> 1Mb = 4 x 256K SIMMs >> 2Mb = 2 x 1Mb SIMMs >> 2.5Mb = 2 x 1Mb SIMMs + 2 x 256K SIMMs (Not with TOS 1.6) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >I heard this works on TOS 1.6 if you put the 256k SIMMs as the first bank >and the 1M SIMMs as the second bank. But I could be wrong. If you're >having trouble, though, it's trivial to try it the other way. >> 4Mb = 4 x 1Mb SIMMs Well 2.5Mb does work on my 520STE with TOS 1.6, but it does think there are 4Mb there. I have not had any problems yet but I have not (knowingly) tried to use all of the memory thus far. I have the feeling that when I do I will commit mass bit murder :-) by trying to throw them into spaces that aren't there. I will try changing the boards round and let you know what happens. n e w s f o d d e r Cheers, Ian -- Ian Camm | JANET: camm@uk.ac.man.ee.els Dept. of Electrical Engineering | ARPA: camm@els.ee.man.ac.uk University of Manchester, England | UUCP: ...!!ukc!man.ee.els!camm Disclaimer: If you think I need one make it up yourself. ------------------------------ Date: 6 Jun 91 22:40:23 GMT From: noao!ncar!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!lll-winken!aunro!ersys !mforget@arizona.edu (Michel Forget) Subject: Neophyte question: what's Blitter? To: Info-Atari16@naucse.cse.nau.edu darkstar@milton.u.washington.edu (Alden Hackmann) writes: > We are the very new (3 days) owners of an Atari 1040 STe. > There is a toggle on the options menu for something called Blitter. > The little manual has no reference to it at all. Can anyone enlighten > us as to the meaning of this option? > If you can select the "Blitter" option, do so. It is a special graphic chip inside the machine that allows it to do Hardware Scrolling. It makes for faster, smoother scrolling. I'm not sure about the other capabilities. It is better than the standard, though, so use it if you can. << ---------------------------------- >> << ersys!mforget@nro.cs.athabascau.ca >> << mforget@ersys.edmonton.ab.ca >> << Michel Forget >> << ---------------------------------- >> ------------------------------ Date: 6 Jun 91 20:39:54 GMT From: noao!asuvax!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!crdgw1!gecrdvm1 !syspmzt@arizona.edu Subject: Re: Man w/ pipe To: Info-Atari16@naucse.cse.nau.edu In article , steve@thelake.mn.org (Steve Yelvington) says: > >[In article <1991Jun6.131017.12110@ira.uka.de>, > S_DINGLER@iravcl.ira.uka.de (|S| Florian Dingler) writes ... ] > >> I wonder if anyone knows who the man smoking a pipe is. You know, the one >you >> find in the ATARI-ST charset with the codes 28-31 or so. Is he just a little >> joke or a special person or what ? >> Please write followups, no mail. > >Bob is indeed a special person, being the revered icon of the Church of the >Sub-Genius. > Well, now I know why Bob is seen on the dialog box of the ram disk I use. I'd thought that the programmer was really cool to spend the time drawing Bob. Now I know that the real cool person is or was hidden inside Atari while they were developing the machine. For all the deficiencies of the operating system, at least it offers slack to all who seek. Phil Z ------------------------------ Date: 6 Jun 91 18:56:50 GMT From: noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!crdgw1!gecrdvm1 !syspmzt@arizona.edu Subject: XOR (Was RE: More than 4 Meg?) To: Info-Atari16@naucse.cse.nau.edu I can't reply to Ralph Berg, who asked about programming for the Cazio CZ1 with XOR: XOR is a generic patch editor that runs in Dr. T's KCS Multi-Programming Environment (MPE). It can also be run as a standalone program. As I understand it, XOR uses modules that describes the programming requirements for a given synth, and then uses a generalized interface to allow that programming. Feedback from the synth category was very favorable to XOR over other available packages. I like the idea of going to XOR since it s supports a lot of synths, some of which are not exactly popular models. . If you're not familiar with Dr. T's, they write a lot of midi software that may not always have the greatest flexibility right off the bat, but are well supported in upgrades, and are reasonably priced. I've stayed with the KCS through 4 upgrades now, and with Tiger and Level II, have an extremely powerful sequencer environment that supports the functioning of many external programs; last night I figured how to initiate other GEM programs from within the KCS so that I don't have to reload my sequencer configuration just to get to my all-important Daleks game... Phil Z ------------------------------ End of Info-Atari16 Digest ******************************