Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!WISDOM.BITNET!MAILER-DAEMON From: MAILER-DAEMON@WISDOM.BITNET.UUCP Newsgroups: comp.sys.atari.st Subject: Returned mail: User unknown Message-ID: <8703251513.AA27176@ucbvax.Berkeley.EDU> Date: Wed, 25-Mar-87 00:40:06 EST Article-I.D.: ucbvax.8703251513.AA27176 Posted: Wed Mar 25 00:40:06 1987 Date-Received: Fri, 27-Mar-87 02:04:22 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 464 ----- Transcript of session follows ----- 550 ALEN@WISDOM.BITNET... User unknown ----- Unsent message follows ----- Received: from finhutc.bitnet by wisdom.bitnet; Wed, 25 Mar 87 11:20:30 -0200 Received: by FINHUTC (Mailer X1.23b) id 8966; Wed, 25 Mar 87 11:12:22 FIN Date: Tue 24 Mar 87 21:40:06 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 #141 To: Alen Goldberg Info-Atari16 Digest Tuesday, March 24, 1987 Volume 87 : Issue 141 This weeks Editor: Bill Westfield Today's Topics: Crystal Castles for the ST Re: Ratfor (!) (In C too !!) Re: help! vro_cpyfm, vrt_cpyfm mega-st info please Engineering Symbols on Panasonic Printer Rats.. Linking ROMable code on the ST Publishing Partner Printing Problems reading from the midi port Re: Small's 410k fast formatter Re: Hacking at Megamax C (query) Thank you for a fine job Ramblins... ---------------------------------------------------------------------- Date: 17 Mar 87 13:57:49 GMT From: mnetor!utzoo!utgpu!water!watnot!watmath!looking!david@seismo.css.gov Subject: Crystal Castles for the ST To: info-atari16@score.stanford.edu I just bought Crystal Castles for the ST, and wonder of wonders, it works in MONOCHROME TOO !!! It looks pretty good in B&W, much better than I thought it would. It is VERY close the arcade game, and plays well with the mouse (you can also play with a joystick) I wish more companies would take the extra time to get their products running under monochrome as well as colour... By the way, it looks good in colour too :-) Cheers, David Rowley Looking Glass Software ------------------------------ Date: 18 Mar 87 18:27:17 GMT From: mnetor!yetti!oz@seismo.css.gov (Ozan Yigit) Subject: Re: Ratfor (!) (In C too !!) To: info-atari16@score.stanford.edu In article <1684@trwrb.UUCP> sansom@trwrb.UUCP (Richard Sansom) writes: >In article <2120@alvin.mcnc.UUCP> ravi@mcnc.UUCP (Ravi Subrahmanyan) writes: >> Just in case someone's interested.. I have a version of Ratfor >>for the ST; it's pretty complete, and works fine (except for I/O in >>pipes). Any fortran users out there?? 8^) > >Sure Ravi (I'm no purist). How about posting to the sources newsgroup? > I have sent my Ratfor-in-C to mod.sources a couple of days ago. It is in C, and includes F77 output, and case-stmt handling. I suspect that It will be easy to put it up on an Atari. It corresponds very closely to the Software Tools book version. enjoy. Oz -- The best way to have a Usenet: [decvax|ihnp4]!utzoo!yetti!oz good idea is to have a Bitnet: oz@[yusol|yuyetti].BITNET lot of ideas. Phonet: [416] 736-5053 x 3976 ------------------------------ Date: 18 Mar 87 06:44:08 GMT From: mnetor!utgpu!pete@seismo.css.gov (Peter Santangeli) Subject: Re: help! vro_cpyfm, vrt_cpyfm To: info-atari16@score.stanford.edu Hi everybody, Just thought I'd clear up the vro_copyform problem. vro_cpyform copies a rectangular bitmap from one location to another based on bit boundaries. (vro_cpyfm is similar, so I will stick with vro_cpyform). The function looks like this: vro_cpyform(handle,wr_mode,pxyarray,psrcMFDB,pdesMFDB); "handle" is the VDIHANDLE previously obtained when opening the application under GEM. (see graf_handle in documentation). "wr_mode" is the writing mode under which the transfer will be performed. example direct transfer of bits, or source bits xor'd into destination bits. "psrcMFDB" and "pdesMFDB" are pointers to "memory form definition blocks". These are data structures that describe the memory areas being transferd to or from (more later...). "pxyarray" is a standard GEM input array which describes the offsets and sizes of the rectangles within each memory area described by the MFDB's that will be transfered. An MFDB is a 10 word parameter block consisting of: (2 words) memory address of block in question. Please note that if this 0, GEM will fill it in with the address of the current logical screen. (1 word ) block width in points. (1 word ) block hieght in points. (1 word ) block width in points/16 (words). (1 word ) raster format flag. 1 indicates that the block is in a standard format suitable for transfering between, say color and b&w, or even to IBM PC GEM. 0 indicates that the block is device specific (0 is usually used). (1 word ) number of planes of color. (1 for mono). (3 words) reserved, make them 0. While I have never had to do memory to memory raster copies, I often do memory to screen and the inverse, with no problem. Unless GEM is much more brain damaged than anyone imagined, there should be no problem with memory to memory. Pete Santangeli pete@utgpu ----- ^ \__ new address!! ------------------------------ Date: 19 Mar 87 03:38:15 GMT From: renoir.Berkeley.EDU!john@ucbvax.Berkeley.EDU (John Coker) Subject: mega-st info please To: info-atari16@score.stanford.edu I've been hearing people refer to the ``new'' (future) version of the st as a ``mega-st''. I'd like to know just how this machine is better than the current 1024 st, when it's going to come out and how much it's going to cost (if anyone knows). I've heard (or thought I heard): - more bits on the screen - blitter (or more display chips?) - faster and/or more memory standard - 680[12]0 upgrades - arithmetic coprocessor Are any/all of these true? When can we expect the machine? In what price range will it be? The system which looks attractive at the moment is the 1024 st; I'm interested in where the mega-st improves on the 1024. Will this machine really be an improvement on the st; is it a sliglty better replacement for the st or a larger machine? More bits on the screen would be a wonderful improvement--especially if the physical monitor got larger also. (BTW, is there any way to get more pixels with the current st and another monitor?) If this information is general knowlege, please just respond to me. Otherwise, others may also be interested. If the thing (or marketing propaganda) is already at stores in Berkeley, please tell me where. ------------------------------ Date: 18 Mar 87 18:23:19 GMT From: ihnp4!mhuxu!cbz@ucbvax.Berkeley.EDU (Craig B. Ziemer) Subject: Engineering Symbols on Panasonic Printer To: info-atari16@score.stanford.edu I have finally gotten around to writing a "print filter" which allows my Panasonic KX-P1080 printer to print engineering (read Greek) symbols through my Habawriter wordprocessor software. If anyone wants a copy of the filter file let me know. If you don't have the Habawriter wordprocessor you can still use these codes to download the special symbols to your Panasonic printer. The characters I have developed codes for are: big and little sigma, mew, tau, infinity, alpha, pi, omega, beta, gamma, epsilon, lamda, delta, angstroms, theta, phe, phi, pho and phum. (:^) Craig Ziemer at AT&T-BL mhuxu!cbz ------------------------------ Date: 19 Mar 87 03:19:03 GMT From: ucsdhub!hp-sdd!ncr-sd!ncrcae!ece-csc!mcnc!ravi@sdcsvax.ucsd.edu (Ravi Subrahmanyan) Subject: Rats.. To: info-atari16@score.stanford.edu [] I have a clarification to make re. my earlier posting about the availability of Ratfor. Ratfor is >not< a compiled language. Ratfor is a preprocessor that converts Ratfor code to regular fortran (rather unpleasant fortran, but the good part is you don't have to look at it) which must then be compiled by a standard fortran compiler (eg. the Absoft compiler). Sorry if I gave the impression that it included a compiler, -ravi ------------------------------ Date: 18 Mar 87 13:53:04 GMT From: mcvax!ukc!warwick!daffy@seismo.css.gov (Steve Hunt) Subject: Linking ROMable code on the ST To: info-atari16@score.stanford.edu Hi ST-folk, I'm attempting to link a program that resides partly in ROM and partly in RAM. It won't be run on an ST, I'm just using the ST to develop and link the program. The program is divided into two modules, let us call them "one" and "two." The code in module "one" is to reside in RAM at address $4000. The code in module "two" is to reside in ROM at address $80000. The data from both sections will reside in RAM at $1000 up. Now, the question is this: how can I go about linking the beast? I've got the Developer's Kit but LINK68 and LO68 don't seem to provide facilities for doing this sort of thing. Of course, the two sections need to know about each other's symbols. So I can't get away with linking the two parts separately. BTW, I tried welding the two assembler files together with appropriate ORG directives to $4000 and $80000, but to my dismay the assembler took about 20 minutes to produce a HUGE object file with... guess what... $79000 nulls up front.... Ideally I'd like to link the modules in order to satisfy the references between them, but end up with 2 object files (preferably in S-record format) which I can then load into the appropriate places in store. Any help much appreciated! Thanks in advance, Steve Hunt. -- "University computer centers are notorious for being run by empty-headed bozos." -- Henry Spencer. Steve Hunt, DONALD Programmer 1st Class Mail: daffy@warwick.UUCP sahunt@warwick.UUCP daffy@uk.ac.warwick.ubu Home: "The Silo", 15 Molesworth Avenue, Stoke Green, Coventry CV3 1BU, UK Tel: 0203 447765 ------------------------------ Date: 19 Mar 87 04:08:52 GMT From: jade!eris!cathy@ucbvax.Berkeley.EDU Subject: Publishing Partner Printing Problems To: info-atari16@score.stanford.edu Some Publishing Partner files I've created on a 1040 print fine on an Apple Laser Writer, but others give a Postscript errors and refuse to print. I have not noticed any similarities in the files that don't print (yet). Anyone experienced the same problem? (I am using version 1.01) Thanks, Cathy ------------------------------ Date: 18 Mar 87 16:30:10 GMT From: decvax!cca!m204help@ucbvax.Berkeley.EDU (Keith Hedger) Subject: reading from the midi port To: info-atari16@score.stanford.edu I am trying to read data from the midi in port on the 520 ST and am having a problem. My program is written in MEGAMAX C and basically 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. (In other words the sequencer is still running). If I stop the sequencer and run the program again, it typically puts out another 4 or 5 lines of midi data then stops. I run it again and the port is clear. My program is basically built with a big 'while' loop which says 'while data is at the midi in port do blah blah blah'. I have seen some messages from the 'bix' section of Byte where people were saying that they had had the same kind of problem, and that the buffer that handles incoming midi data is too small....they allocated their own buffer large enough to handle the data. My question is: If the buffer is filling, why would having my program read from it and stuff the data into a bigger buffer, work any better than reading data from it and putting it into strings to be output ? Is putting the data in strings to be output that much slower than moving the data into an internal buffer ???? I would appreciate any suggestions any of you MIDI hackers out there can give me. thanx, keith hedger ------------------------------ Date: 17 Mar 87 20:08:00 GMT From: ihnp4!inuxc!iuvax!franco@ucbvax.Berkeley.EDU Subject: Re: Small's 410k fast formatter To: info-atari16@score.stanford.edu There is one more thing that must be done to David Small's 400k fast formatter (START - latest issue) in order to make it useful. The executable given in START always sets the disk serial number to 0. This is interesting because, according to the source code, the executable should set the disk serial number to a random number. I suppose the executable provided in START was a preliminary version. Small probably realized there was a problem and changed the sources, but neglected to send the updated executables to START. All is not lost, however. In sector 3 there is the HEX string FFFFFFFF. Simply change it to HEX 0FFFFFFF to get random serial numbers. ------------------------------ Date: 18 Mar 87 04:51:08 GMT From: ihnp4!alberta!sask!long@ucbvax.Berkeley.EDU (Warren Long) Subject: Re: Hacking at Megamax C (query) To: info-atari16@score.stanford.edu In article <425@batcomputer.tn.cornell.edu>, braner@batcomputer.tn.cornell.edu (braner) writes: > Also: has anybody made an alternative printf/scanf that skips the FP stuff > (to make it smaller). Has anybody bought the Megamax library source code > (offered for $50)? Is it worth it? > > These sorts of optimizations-by-the-users have been done on the DRI/Alcyon > compiler. Why not for Megamax? > > - Moshe Braner > > PS: does anybody know whether the Megamax Resource Construction program > will work with OSS Personal Pascal? Is the .RSC file format standard? > How would you get the Pascal .I file? Is it easy to translate the C .h > file to the .I form? The resource files are all the exact same format. However, if you load a RSC file into the editor without the extra info files, you will have to add in all the names and types of dialog boxes yourself. Then when saving it, it will create a new file. (the info file is .DEF for Megamax Resource construction set and .DFN for the developer's kit). It makes it awkward to switch from one to the other, but at least you don't have to start from scratch. Back to the topic at hand... Has Megamax changed the 32K code limit yet??? My program is pushing that limit (31986 or something), and I have lost any desire to add new features, so I don't go over the edge. Warren -- =-=-=-=-=-Warren Long at University of Saskatchewan, Canada-=-=-=-=- Home: 78 Carleton Dr.,Saskatoon, Sasakatchewan, S7H 3N6 Phone: (306)-955-1237 =-=-=-=-=-U-Email: ...!ihnp4!alberta!sask!long -=-=-=-=-=-=-=-=- ------------------------------ Date: 19 Mar 87 10:59:51 PST (Thursday) From: Bicer.ES@Xerox.COM Subject: Thank you for a fine job To: ihnp4!inuxc!iuvax!franco@ucbvax.Berkeley.EDU ---------------------------------- Over 200 copies of different versions of the STarter Kit were mailed out and many of these were duplicated and redistributed. The operation went very smoothly - nearly everyone followed instructions to a T and sent the correct ---------------------------------- Thank you for taking the time and trouble to make so many people very happy. Jack Bicer ------------------------------ Date: Wed, 18 Mar 87 22:01:43 EST From: Flash%UMASS.BITNET@wiscvm.wisc.edu Subject: Ramblins... To: Info-Atari16@SU-SCORE.ARPA Peter Santangeli writes: > These guys are either BLIND or just plain aren't willing to spend the >time to find the problem. Frankly, I am EXTREMELY PISSED OFF. I spent over >$2000 on atari equipment. Yah, the software isn't great, I can live with that. >I CAN'T LIVE WITH RUDE AND INEFFECTIVE SERVICE. Peter, Maybe you want to take a road trip down to Amherst, Mass? I run an Atari ST Sales and Service center, and our technician is a master at hardware. We could run right through it and solve it all. I know it is kind of sad, but Atari's requirement to have a "real" tech has degraded to soup. Our local competition has some high school kid who is never in and does nothing. Atari's official word is "So what? Until someone complains by official channels.." Soooo, we are now making money by fixing the computers for our competition. (As long as it is out of warranty...) But we can probably figure it out, if not, search for another dealer, I believe that even in Toronto there should be several honest and capable dealers available. On other stuff. Mail order places. S&S took three weeks to deliver something for me that they claimed would be shipped the next day UPS BLUE! And they still send it UPS BLUE three weeks later. But by that time I got it from somewhere else, and I refused it. (heh heh) CMO (Computer Mail Order) seems to be pretty good and honest. I got a printer from them. FAST. They are pretty good on whether something is in stock or not. "We have 2 in stock..." And they ship fast. Then of course, there is always your dealer. Find a good one who discounts, and then you wont have to sweat it while waiting for an UPS truck. Rick Flashman 1040 N. Pleasant Street, #381, Amherst, MA 01002. (413) 549-0173 Flash@UMASS.BITNET -or- Flash%UMASS.BITNET@WISCVM.WISC.EDU R-FLASHMAN on GEnie ------------------------------ End of Info-Atari16 Digest ************************** -------