Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!ames!ucbcad!ucbvax!WISDOM.BITNET!MAILER-DAEMON From: MAILER-DAEMON@WISDOM.BITNET.UUCP Newsgroups: comp.sys.atari.st Subject: Returned mail: User unknown Message-ID: <8703261311.AA15586@ucbvax.Berkeley.EDU> Date: Thu, 26-Mar-87 00:35:37 EST Article-I.D.: ucbvax.8703261311.AA15586 Posted: Thu Mar 26 00:35:37 1987 Date-Received: Sat, 28-Mar-87 02:08:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 894 ----- Transcript of session follows ----- 550 ALEN@WISDOM.BITNET... User unknown ----- Unsent message follows ----- Received: from finhutc.bitnet by wisdom.bitnet; Thu, 26 Mar 87 15:01:50 -0200 Received: by FINHUTC (Mailer X1.23b) id 5248; Thu, 26 Mar 87 13:41:19 FIN Date: Wed 25 Mar 87 21:35:37 PST Reply-To: Info-Atari16@Score.Stanford.edu Sender: "Atari ST users forum (INFO-ATARI16)" Comments: To: "Distribution List: ;" From: Info-Atari16 Digest Subject: Info-Atari16 Digest V87 #142 To: Alen Goldberg Info-Atari16 Digest Wednesday, March 25, 1987 Volume 87 : Issue 142 This weeks Editor: Bill Westfield Today's Topics: icon RE: 68000 box Re: Ratfor (!) (In C too !!) Re: reading from the midi port Atari ST system and related items for sale (revised) Publishing Partner memory usage Re: Help! vro_cpyfm,vrt_cpyfm 1st posting to comp.binaries.atari.st Re: 68020 Box, laser printer, Eastern Pa. Expo Re: laser printer The New 8-Bit Emulator ---------------------------------------------------------------------- Date: Thu, 19 Mar 87 22:20:44 EST From: Michael DeCorte To: INFO-ATARI16@SU-SCORE.ARPA Subject: icon I have the icon programming language for the st. Icon has nothing to do with the icon's used by the st, it is a high level language that implements back-tracking. Anyone who wants it email me. michael decorte l40a@clutx.bitnet p.s. please include your bitnet or arpa address. I don't have access to UUCP. ------------------------------ Date: Thu, 19 Mar 87 22:39:37 EST From: Michael DeCorte To: INFO-ATARI16@SU-SCORE.ARPA Subject: RE: 68000 box There have been several comments on the net lately about adding this or that to the unix box that atari is planning. While all of the additions that I have seen are very interesting I can not support them. The 68000 box as I understand is supposed to be a cheap, fast unix box that plugs into the back of the ST. The proposed additions contradict this purpose. Each addition adds to the cost of the machine and it will delay it's release. I don't think anyone wants to have to pay more and wait longer for unix on the ST. If a multi-user box is desired then one possible solution would be to create (perhaps by third party) a box with a bunch of rs-232 ports in it. The rs-232 box could be just another thing on the dma-bus. This has the advantage that it would be useful even without the unix box and to make the unix box work with the rs-232 box should involve a DRIVER change not a HARDWARE change. Of course this would cost more than if the unix box had rs-232 ports but not everyone want's a multi-user machine. This was just something that came to me and I have not really thought it out, so it may to be even be possible but the point is there are other ways to add power other than make one really powerfull box. michael decorte l40a@clutx.bitnet ------------------------------ Date: 20 Mar 87 00:16:25 GMT From: mcnc!ravi@seismo.css.gov (Ravi Subrahmanyan) Subject: Re: Ratfor (!) (In C too !!) To: info-atari16@score.stanford.edu In article <472@yetti.UUCP> oz@yetti.UUCP (Ozan Yigit) writes: > I have sent my Ratfor-in-C to mod.sources a couple of days ago. > [....] I suspect that it will be easy to put it up on an Atari. The version I started from is from a previous posting by Ozan. The circle closes.. -ravi ps: I'll get his newer posting (in mod.sources) and set that up on the ST (unless someone's done it; in that case please post. It looks like lots of people are interested after all). ------------------------------ Date: 20 Mar 87 00:32:47 GMT From: rgoodman@csvax.caltech.edu (Ron Carl Goodman) Subject: Re: reading from the midi port To: info-atari16@score.stanford.edu In article <14085@cca.CCA.COM> you write: >... >grabs midi data a byte at a time and stuffs it into an array...when the >array reaches a length of 78 it is displayed on the screen and a new >string starts getting written. My problem is that I hook up a sequencer >to my ST and start it putting out midi data and start running my program. >My program always displays 4 or 5 lines of midi data then exits the program. >My program is basically built with a big 'while' loop which says >'while data is at the midi in port do blah blah blah'. The problem is really that your ST is a fast computer! When your sequencer is plopping out data, your ST reads it in. At first, before your program is going, the data is stored in the 128 byte midi buffer. As you read the data, more is being placed in the buffer, but the sequencer does not spew out data as fast as the ST reads the data. So your buffer is eventually depleted. When the ST catches up (based on when you ran the program in relation to turning on the sequencer) your ST will make a request for data and there will be none waiting. A fraction of a second later, some will be waiting, but its too late... your while loop has fallen through. One solution is to use something that checks the port N times before deciding that no more data is truly there (to be sure that no more is coming). N can be found experimentally. 300 is plenty. This kind of method is sort of icky, because N may not work when this program is run on a different computer. Another solution is to call a system timer with a delay of like 1/10 of a second and check again before determining no data is left. By the way, you might wonder how this method works, since the time between two notes could actually be far more than 1/10th of a second. Sequencers put out timing signals as part of the MIDI code (I think 247) at a constant rate to solve that problem. Unfortunately, there is no standard END_OF_ SEQUENCE marker. Ron Goodman -- rgoodman@cit-vax.caltech.edu _______ _________ _________ | rgoodman@cit-vax.bitnet / \#/ \#/ | Pasadena rgoodman@cit-vax.uucp |alifornia |nstitute |echnology | California \_______ ___/#\___ of | | U. S. A. ------------------------------ Date: 19 Mar 87 23:45:04 GMT From: ihnp4!ihlpf!gjphw@ucbvax.Berkeley.EDU (Wyant) Subject: Atari ST system and related items for sale (revised) To: info-atari16@score.stanford.edu We have recently upgraded our Atari 520ST system by purchasing someone else's 1040ST system. This has left us with several duplicate items and a lot of software for sale. In my original posting, I omitted a single-sided disk drive which is also available, so I will repeat that part of the notice that should be changed. For those who are interested but living outside of the Chicago area, we can send you what you want COD by UPS. ------------------------------ hardware: 520ST color system (520ST console with 512K RAM, Atari color monitor, disk drive, owner's manual) : with single-sided drive - $674 : with double-sided drive - $774 software included - BASIC, Neochrome (drawing program), First Word (word processor), LOGO, ST-Writer (word processor), and DBmaster (GEM based database utility). Also, Flash (very good terminal emulator), DEGAS (excellent drawing program), Cornerman by Michtron (similar to Sidekick), and five (5) public domain disks: 1. Uniterm 1.7a and arc program disk 2. disk of pictures for Dr. Who and Star Trek characters (includes latest TINY routine for viewing and scaling) 3. cartoon disk of Warner Brothers and Disney characters (uses TINY) 4. AEGIS Animator demonstration disk (files must be unarced) 5. utility disk containing Apple II and Atari 8 bit emulators plus other utilities 6. Boffin demo disk - a working prototype of a word processing routine which can handle graphics as well An Abacus book titled "Presenting the Atari ST". ------------------------------ A second double-sided disk drive is available for $179.00. The single-sided disk drive alone is $85.00. Gail Wyant (312) 554-2657 or Michael Fanelli DECmail: phdvax::fanelli Bluebell, PA or Patrick Wyant AT&T Bell Laboratories Naperville, IL *!ihnp4!ihlpf!gjphw ------------------------------ Date: Thu, 19 Mar 87 20:41 AST From: Subject: Publishing Partner memory usage To: info-atari16@su-score.arpa X-Original-To: arpa%"info-atari16@su-score.arpa", FXDDR I made up a demo file for Publishing Partner, incorporating graphics, Helvetica, and Times-Roman fonts at various sizes, saved it on disk and went on to other things. This morning I booted from my Uniterm disk, which sets up a 400K eternal ramdisk and loads Antic's Crystal desk accessory. I cranked up Pub Partner to convert my demo to PostScript on the ramdisk so I could upload it for printing. When the demo loaded, yuk! The Times-Roman was now Martian-Hieroglyphics. I checked the font menu and in place of Times-Roman was more Martian. Hmmm. After some fooling around I found that when I rebooted with a 320K ramdisk and no desk accessories, I had Times-Roman again. So it looks like when memory gets tight, the last font in the table gets grunged. However, with the 400K ramdisk and Crystal, Pub Partner's "Don't Look..." box showed free program space of about 200K and free system space of about 7K. No sign that it is worried about lack of RAM. With the smaller ramdisk and no DAs free program space is about 300K and free system space is still about 7K. The question is this: why does the font get trashed? Pub Partner doesn't seem to be upset about the amount of ram, and its display shows no shortage. Is there some sort of interaction between Pub Partner and Crystal? Or does the ramdisk mess up Pub Partner's memory allocation? My main concern is that there doesn't appear to be a way to tell when you've stepped over this line...things just start getting trashed. Any ideas? For now I will do my composing with no DAs and no ramdisk just to be safe. Don Rice University of Alaska, Fairbanks BITNET%"FXDDR@ALASKA" CIS 72337,3417 // KL7JIQ ------------------------------ Date: 20 Mar 87 03:01:52 GMT From: mnetor!utgpu!pete@seismo.css.gov (Peter Santangeli) Subject: Re: Help! vro_cpyfm,vrt_cpyfm To: info-atari16@score.stanford.edu In article <672@atari.UUCP> leavens@atari.UUCP (Alex Leavens) writes: >in article <8703170112.AA00614@ucbvax.Berkeley.EDU>, JANKOWSJ@UNION.BITNET says: >> Is there any-hacker in this universe that can assist me in >> finding information about working with the G.E.M. functions > > 2) Make _sure_ that your source and destination blocks the > same size. Although I have yet to try it, According to Abacus, when given differing sizes of blocks, the system uses the size of the source block. > > 3) Make sure the pixel width of your raster is an even multiple > of a word size (ie, 16). This is only necesairy when speed is at a premium. The routines can handle bit-boundaries. This brings up an interesting point of interface theory. I have noticed that many GEM programs snap windows to 16bit boundaries. I fully understand the rational for this, but I don't think I agree with it. Though doing this increases speed, it very much reduces the quality of the user interface. Snapping takes away the feelinng that what you do is what you get. I would rather have the machine do EXACTLY what i want, and decide when running a program whether I want 16 bit boundaries. This is sort of a time- interface tradeoff. One of many in a windowing system! > > 4) You probably want to make sure that your source and destination > rectangles don't overlap. I can see no real reason for this. The routines are "smart" and can transfer over each other. > >Good luck! Yup! Pete Santangeli pete@utgpu ------------------------------ Date: 19 Mar 87 23:48:46 GMT From: imagen!turner@ucbvax.Berkeley.EDU (D'arc Angel) Subject: 1st posting to comp.binaries.atari.st To: info-atari16@score.stanford.edu I have just post my first program to comp.binaries.atari.st, it is the SpaceWars game (Version 3.1). hopefully most of the bugs are out of the system. However i doubt it, could people give me feedback as they receive the posting, thanks. Also I am sending it to INFO-ATARI16@SCORE which i hope will get it onto ARPA but i still need help with BITNET, would some kind soul like to volunteer as my gateway to bitnet ???? -- --------------- C'est la vie, C'est la guerre, C'est la pomme de terre Mail: Imagen Corp. 2650 San Tomas Expressway Santa Clara, CA 95052-8101 UUCP: ...{decvax,ucbvax}!decwrl!imagen!turner AT&T: (408) 986-9400 ------------------------------ Date: 18 Mar 87 15:50:31 GMT From: decvax!watmath!daemon@ucbvax.Berkeley.EDU Subject: Re: 68020 Box, laser printer, Eastern Pa. Expo To: info-atari16@score.stanford.edu In article <10162@topaz.RUTGERS.EDU> you write: >Mark did say that the box would only use the ST's I/O ports. Well why >not put a few RS-232 ports on the box. This would allow you to hook >your 8-bit up to your ST as a terminal. It could also be used in a >University Microlab, for running a BBS and allowing console logins. >Another use would be in an office situtation. This way many people >can access the same files, share printers, etc. It seems that this is >VERY possible under System V UNIX. I'm a little leary of this suggestion. The 68020 box would be a wonderful, single-user, Unix workstation. Adding multiple serial ports to allow a lot of multi-user use would change this inexpensive Unix workstation into an "Office" computer, with a corresponding increase in price. Atari would have to pay AT&T for additional licenses; there would be more gunk in the drivers and hardware to suppport the extra serial ports, etc., etc. I would like a couple of serial ports for one extra terminal, a modem, etc., but nothing more. Atari has often been the David of the computer industry; I would prefer that the 68020 box remains affordable and doesn't turn into another Goliath of a computer. Mike Berkley, University of Waterloo UUCP: {allegra,ihnp4,utcsri,utzoo}!watmath!watsup!mberkley Bitnet: mberkley%watsup%waterloo@csnet-relay.ARPA ------------------------------ Date: 19 Mar 87 05:18:08 GMT From: mnetor!genat!maccs!cs3c3cg@seismo.css.gov (Ray ) Subject: Re: laser printer To: info-atari16@score.stanford.edu In article <667@atari.UUCP> leavens@atari.UUCP (Alex Leavens) writes: >in article <261@nikhefh.UUCP>, t68@nikhefh.UUCP (Jos Vermaseren) says: >> >> At Hannover I saw the Atari laser printer. >> It was announced as a 8 pages per minute printer. >> In a report from the computer show in Vegas I read >> something about 30 or more pages per minute. Was the person >> who mentioned this mistaken, or is this not the same printer ? >> ...Alex ??.... > > The 8 pages a minute figure is correct. I've never even _heard_ of a laser >printer that'll do 30 pages a minute... > Oh yeah, The IBM 3800 Laser printer prints at 2 1/2 pages a second!!! thats 150 pages a minute!!! Now before any of you in netland start salavating, there is a catch, the price, a cool $1M (at least that is what I was told) :-) :-) Ray Wong ------------------------------ Date: Fri, 20 Mar 87 00:08:44 PST From: johnson%msuhep.hepnet@lbl.arpa Subject: The New 8-Bit Emulator To: INFO-ATARI16@SCORE.STANFORD.EDU X-ST-Vmsmail-To: LBL::"INFO-ATARI16@SCORE.STANFORD.EDU" Howdy Netland!! I have heard very little about the NEW 8-BIT Emulator and thought I would give an update on its current status. For those of you who are not familiar with the Beta version that has been out for awhile it may be because it was _OFFICIALLY_ ordered out of distribution by Atari corp. {Question to Alex, why did you wait until last week to even call the author, when Atari made this declaration at least a month ago?????} The emulator does a real good job of emulating 8-bit software and should be in distribution again soon. You see there was a reason Atari ordered this yanked; it used Atari OS images.... yes, this is illegal. Darek's (the person who did the programing) newest version, being completed this weekend, will come up and ask you if you want to be an 8-bit atari or an apple II today! Although I understand both the Apple II and the Atari emulators run at about a quarter of the speed on their respective machines, they are pretty impressive. The Atari emulator, for instance, emulates almost everything but player missle graphics!! {I should be recieving a test copy next week and I will inform you of what progress he has made.} The purpose of my posting this is to a) inform the info-atari readers of this new piece of software and to b) bring up the poor attitude of Atari. Both of these topics are covered in much greater detail in the following articles. The first is by Darek Mihocka, the author, and the second is by John Nagy, sysop and Vice President of C.H.A.O.S. users group in Lansing, Mi. Responses from Atari are welcomed (have you recieved your copy yet Alex?? ) Good reading, John Johnson- ST Interest Group President, C.H.A.O.S. -------------------------- (reprinted from ZMAG) Current information about the ST Transformer as of 03/09/87 By Darek Mihocka (CIS 73657,2714) Programmed by Darek Mihocka additional programming and all night testing by Ignac Kolenko hardware supplied by: Xanth Computer Systems 600 First Avenue Seattle, Washington The purpose of this document about the ST Transformer is: - to explain its purpose and give a history of its development - to give the latest information about the ST Transformer - to discuss the legal problems with this program and why I can't release it to the public for all former Atari 400/800 owners - to find other programmers to work on this project. For those of you unfamiliar with the name, you have seen it as the Atari 800 Emulator Demo or the Apple ][ Emulator. Part 1:The history When Atari introduced the ST computers, I was then the owner of an Atari 400, bought way back in 1981 with all my summer's earnings. Like many other people I spent a considerable amount of money on my system for software and disk drives. About the only piece of hardware that I could use on the ST was my FX80 printer. This is not too useful as none of the software works. So I held off buying an ST for over a year as I waited for Atari to introduce some kind of a device or program to allow me to run old software. They never did. I finally sold the 400 and bought the ST anyway because after using 68000 based in machines at my university, I was impressed by its power and already had a program in mind. The implementation: The first project I decided to work on was to somehow run the old software so that all that money didn't all go to waste. I considered 2 approaches: - the first approach is to write a program that reads a binary file from a 400/800 and convert each machine language instruction into a 68000 instruction. This would then create a file on the ST that would run about 10 times the speed of the original file! Problems: - how do you tell the difference between code and data? - how to handle self modifying code? - how to handle the hardware registers? - the second approach is to write an interpreter, similar to the way BASIC interprets a tokenized program, or the way that a real microprocessor executes code. You read in a byte of memory, determine which 6502 instruction it is, and execute it. The real 6502 executes microcode. I would use 68000 instructions. Problems: - the overhead of processing each instruction is greater than the time it takes to actually execute it. - how to handle hardware registers? I chose the second approach because it solves the first two problems of the first approach, and shares the third problem. The problem of speed is also in both approaches. Software running at ten times the speed is usually unusable. This is similar to the problem when some IBM PC software is run on an AT or even worse, a Compaq 386 (18 times faster). It is always possible to use software running slower. The unknown is how slow the software would run. The hardware problem can be solved by a similar interpreter which checks which register is being accessed and does something accordingly. First results: The first version of the 6502 interpreter was written in Megamax C in August. As it turned out, the unknown speed was about 7% of the speed of a real 6502. This does not include the extra interpretation of hardware. It was obvious that hand coded 68000 code was needed. About a month later, I had the hand coded version sort of working at about 30% of the speed. To make the hardware interpreter would be difficult, because of the dozens of hardware locations in a 400/800. I chose then to first do an Apple ][ hardware emulator, because there are only 2 vital locations needed to get it to work: the keyboard and the screen. The next month was spent debugging the many bugs that crept into the 6502 interpreter and porting software from . Finally it worked, at about 25% of the speed. This is the version that you have seen as the Apple ][ emulator. First Problems: One problem with all emulators is inherent in their design: to emulate the software of another machine, you must transfer that software. When I approached Apple about this, they told me that what I am doing is illegal, since I copied the ROMs of Ignac's no name ][ clone, which had ROMs probably derived from an Apple. I approached Apple Canada about getting the real ROMs from them, plus the code for Apple DOS, and anything else they'd want to let me try. As it turned out, they saw my project as software piracy and told me to forget it. I guess they didn't want to expand to the ST market anyway. After the Apple told me they weren't interested, I decided to stop spending more time on Apple emulation. I ported over my copy of the Translator disk's image of the Revision B ROMs. I chose those ROMs because they are made to run with 64K of RAM, which is what the 6502 interpreter sees when it is executing. I also ported a copy of Atari Basic to use as a test file. After only a few days of hacking the Apple ][ routines, I got a very primitive version of the Atari emulator working. It only supported a few graphics modes and still had a major 6502 bug, but it sort of worked. I uploaded it to my BBS and to Atari's BBS as the Atari 800 Emulator Demo. Part 2: the Atari 800 emulator What happened then was a big shock. I got a phone call from one of the Atari BBS sysops telling me that Atari was not pleased with what I had done. They too considered my program as piracy. I was told that I would be contacted within a few days to discuss the emulator. No one ever called back, and I have never been able to get through to anyone that would discuss it with me. The secretaries usually screwed me around on the phone. Attempts to reach someone willing to talk on Compuserve also failed. What I currently have is a program that appears to execute 6502 code according to the 6502 specs at about 20% of the speed. This includes the overhead of the hardware interpreter. The hardware supported so far includes: - graphics modes 0,1,2,3,6,6+,7,7+, and 8 - most display lists, no matter how complex - most keyboard keys, including START, SELECT, OPTION, RESET, caps, inverse, and BREAK. - the color registers, and a few other miscellaneous locations - most read and write DOS operations - 1 joystick port - printer output - Runs most BASIC software I've downloaded from BBSs and tested. Not supported yet: - GTIA modes - player missle graphics - sound registers - a combination of the two mentioned approaches, where parts of the operation system are hand coded to 68000 code and executed directly, not interpreted. This is already done for the D: and P: drivers, but I plan to eventually do the whole operating system which would result in a significant speed increase. Part 3: Legal Problems According to Apple and Atari, it is illegal for me to distribute the emulator any more because I had included the ROMs with the demos. That is the reason I have not released anything in over 2 months. I respect their legal right, but I also believe that Atari has an obligation to all the tens of thousands of 8 bit owners who helped build the Atari empire. The only people who can make a perfectly legal emulator are Atari themselves. I have spent about 500 hours of my time planning, programming, and testing my program. This may seem like a lot, but it works out to about 10 weeks of full time work, or about 2 to 3 weeks work for a team of Microsoft caliber programmers, which I assume Atari has. With their technical knowledge of both the 8 bit and the ST computers, I don't see why Atari couldn't have released an fully implemented emulator 18 months ago. They were quick to introduce the CP/M emulator. I've compared the code of my program and theirs, and it is quite similar. So they are half done already. Until they do, I will keep working on my program until it is functional enough to run most software that can be downloaded. Once released, it will be up the individual used to copy their ROMs over to the ST. Atari says that's illegal. For as long as the people do it for their own use, I do not see this as being illegal. I do not have access to high priced lawyers, so I am hoping that Atari will finally talk to me and come to an agreement that will benefit us all. Part 4: Programmers Wanted Most of the emulator is written in 68000 code, with C code handling the less critical routines. It has been suggested that I write my program for the Amiga, because its superior graphics would make it easier to implement player missle graphics and the other features. Since I have never programmed the Amiga, I cannot make the Amiga version. What I would also like to do is write hardware emulators for other computers, like the Commodore 64, VIC 20, Color Computer, Sinclair, etc. Anyone proficient in 68000 programming that would be interested in writing those modules starting sometime next fall or winter should contact me. Until then, keep an eye out on your local BBS for the ST Transformer which I hope to have released in June. I will update the situation on the board I hang out on, Megabaud 416-243-9519. Anyone having any suggestions on the program or who can help me with the legal questions can reach me on Compuserve or write to me before May 1 ,1987 at 5023 148th Ave. N.E. #G207, Bellevue, Washington [ED.] In addition to this text sent in by Darek. I would like to add that I have spoken to this gentleman myself and feel that he is entitled to some type of official response from Atari Inc. In the weeks ahead and until we feel that Atari is looking into this matter, we will update you on a weekly basis and next week, we will supply you with a few names and addresses to send off letters to. If we can produce a loud enough voice as 8 bit owners, we can perhaps persuade Atari to respond. >> Note: Darek told John Nagy that Alex did FINALLY call >> after what was rudely and inordinate ammount of time. >> Alex informed him that Atari would have to do ALL distributing >> of it.. I'll try to get him to mail me a reply to post next week. ----------Article 2---------------------------- Supplied by the CHAOS BBS- Reprinted From MICHIGAN ATARI MAGAZINE by permission. THAT WAS THE ATARI EMULATOR THAT WAS by JOHN NAGY (C.H.A.O.S.) An "800" emulator for the ST is a reality! I have seen it and talked to the author. DAREK MIHOCKA of the LONDON, ONTARIO area, has written and distributed several levels of beta test versions on BBS's. He originally planned to make a emulator for just about all the 6502 machines, but has since broken the emulations into separate versions for the APPLE ][, the ATARI, and soon the COMMODORE 64. (YIKE!). The version I saw ran no graphics and did not support DOS functions. But in a telephone interview on February 22, Darek, a 20 year old college student at Waterloo University outside Toronto, told me that he has now developed the emulation to produce all graphics modes, DOS support, and even DISPLAY LISTS! Still to be developed are PLAYER MISSLE GRAPHICS and SOUND. Additionally, there seems to be a string-handling bug in the ATARI 8-bit BASIC emulation but Darek expects to have that corrected shortly. Ult