Path: utzoo!attcan!uunet!husc6!uwvax!oddjob!ncar!ames!mailrus!purdue!decwrl!hplabs!ucbvax!VAX.ACS.OPEN.AC.UK!ADVISORY From: ADVISORY@VAX.ACS.OPEN.AC.UK Newsgroups: comp.sys.atari.st Subject: (none) Message-ID: <8807020004.AA08844@ucbvax.Berkeley.EDU> Date: 29 Jun 88 11:37:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 2297 Returned mail: User A_MONK does not exist ============================================================================== From: FTP_Manager 29-JUN-1988 01:01 To: POSTMASTER Subj: Network mail failure Unable to return Network Mail to EARN.FINHUTC. Please check your Network Autho Local Mail delivery failed to following Usernames: A_MONK Mail text: Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 5741; Wed, 29 Jun 88 01:01:00 BS Received: by UKACRL (Mailer X1.25) id 5726; Wed, 29 Jun 88 01:00:56 BST Date: Wed, 22 Jun 88 17:56:59 PDT Reply-To: Info-Atari16@EDU.STANFORD.SCORE Sender: "Atari ST users forum (INFO-ATARI16)" Comments: Warning -- original Sender: tag was Info-Atari16-request@Score.Stanford.E From: Info-Atari16 Digest Subject: Info-Atari16 Digest V88 #292 To: ALASDAIR MONK Info-Atari16 Digest Wednesday, June 22, 1988 Volume 88 : Issue 292 This weeks Editor: Bill Westfield Today's Topics: Re: Mark Johnson C Are My messages OK now? mega woes, continued Binaries news group postings Re: Read Screen Character Re: Calling M. Braner atari hard drive clones Assembler Re: Mono shakes/Uniterm blues Re: MWC & large arrays -- help! Porting utilities to the ST. ---------------------------------------------------------------------- Date: 19 Jun 88 18:24:38 GMT From: watmath!egisin@decvax.dec.com (Eric Gisin) Subject: Re: Mark Johnson C To: info-atari16@score.stanford.edu One common problem I have with MJC is running out of disk space. Neither the compiler nor linker check for write errors. A truncated .TTP file will do nothing or give you a strange TOS error. Stack overflow is another possiblity, you can change it in ttp.s. ------------------------------ Date: 20 Jun 88 05:46:49 GMT From: rubbs1!Robert_Lisowski@rutgers.edu (Robert Lisowski) Subject: Are My messages OK now? To: info-atari16@score.stanford.edu From: rutgers!rubbs1!robert_lisowski UNCLE!!!UNCLE!!!UNCLE!!! I'm being flooded with mail about my posting to this section a while back. You know, the one with 500 character lines! Sorry about the problems that may have caused some of you. This system uses auto- line wrap, so I wasn't putting in [CR's]. Are my postings getting around OK now? I started hitting return at the end of each line. If anyone out there has seen any of my more recent postings, would you please send mail so I can verify that I'm not screwing things up out there. Rob [1:107/330] (Fidonet adress) ================================================== "Gentlemen.....START YOUR OSCILLOSCOPES!" ------------------------------ Subject: mega woes, continued From: PETCHER%FSU.BITNET@CUNYVM.CUNY.EDU Date: Mon, 20-JUN-1988 12:59 To: info-atari16@score.stanford.edu X-VMS-Mail-To: CCNET%"info-atari16@score.stanford.edu" Funny, my original letter (mega woes) of a few days ago got truncated. Perhaps some of you thought it didn't make sense the way it came out. Here is a rendition of what I meant to say in total: What appeared was: > >I am not having very good luck with Mega 2's so far. Last December I purchased >one, which was obviously buggy from day one. Typically after the machine was > . > . > A story of two buggy megas out of four in our local Atari user group > . > . > ending with: >same experience with the first machine we recieved. Both had hardware >problems. And they were not purchased in the same store, but several hundred >miles apart. So I continue: Now that I have recieved my replacement mega2 and have been working with it for awhile, I have discovered that it also has problems. For one, my disk drive has the famed media change problem - whenever I take out a write enabled disk and replace it with a second write enabled disk, the disk drive doesn't recognize the media change! This was reported previously on the net to be a problem of a certain batch of Chinon drives used by third party vendors, but I did not expect to find it in the 'off-the-shelf' mega! As it turns out, I may also have other problems with the blitter (see, my letter on Uniterm vs. the blitter). Although the final analysis is not yet in, I have certainly had some mysterious crashes lately with otherwise known to be stable programs. I run the same configuration without problems on my 1040 at work and I know of others running the same programs on megas without problem. Since the mega is supposed to be essentially just a 1040 with a little more memory and a blitter in a different box it looks from my vantage point that Atari is going downhill (I am a 3 year plus user of multiple ST machines with no hardware problems to date, before the mega). Since the older machines seem to be more stable than the newer, the main point is this: *** flame on *** IF ATARI IS NOT ABLE TO PRODUCE STABLE HARDWARE, NO MATTER HOW THEY MARKET THEIR EQUIPMENT THEY WILL NEVER MAKE IT IN THE BUSINESS MARKET. *** flame off *** If I had had to depend on the mega for business I would have long ago gotten rid of it and jumped ship to something more stable. Sometimes I think that the instability of the machines is the reason that Atari doesn't market more aggressively than they do. After all, if businesses would have the experience that I have had, Atari's reputation would not be helped to put it mildly. Combine that with the recent discussion of marketing policies on the net (not to mention the many TOS bugs) and Atari has a problem. Why in our area, the closest authorized dealer including servicing is more than 200 miles away. No local dealer can meet Atari's requirements, although there are two or three that would like to sell megas (and one actually does, on a trial basis). Don't get me wrong. I do like my Atari, and intend to do what it takes to get a workable system. It is still the best micro on the market for my purposes (support in scientific research, writing, programming) and I wish Atari every success in the business community. Perhaps I am the victim of a wild fluctuation of statistics that occurred in the vicinity of Tallahassee and my experience is far from usual. I certainly hope so for Atari's sake. Don Petcher E-mail: PETCHER@FSU.BITNET, PETCHER@FSU.MFENET U. S. mail: Supercomputer Computations Research Institute The Florida State University Tallahassee, Florida 32312 ------------------------------ Date: 19 Jun 88 00:50:25 GMT From: van-bc!rthurlow@uunet.uu.net (Rob Thurlow) Subject: Binaries news group postings To: info-atari16@score.stanford.edu Well, time for one of my infrequent postings again. I just had a look at Jwahar Bammi's ZMDM binaries posted to the comp.binaries.st group, and I'm afraid it didn't make it here in very good shape. The sequence of events for this stuff is as follows: 1) The binaries came into the UUCP node I connect to, and got batched to me as if I were just another UUCP site. The articles get put in files not much larger than 100K as a rule, with all newsgroups mixed randomly and the sequence within a group not guaranteed. 2) I stuck my UUPC boot disk into my machine one day and let all the stuff come in that wanted to. Because of some (timing?) problems with the current UUPC software, I had to restart the transmission several times. This goes on for quite some time, and the days files took up a sizable part of an 800K disk, say 450K. That's quite a bit at 1200 baud with uucp g-protocol. 3) I file the disk for a few days until I get time to work on the stuff. In the interim, the binaries of course expire on the Unix machine. 4) When I finally have some spare time, I sit down with Gulam and start being an article processor. Anything interesting gets saved to RAM disk with Gulam's cut and paste. I find that the binaries are in parts too large to do easily, since Gulam can only handle 32K in its paste buffer. But it gets done. 5) I run out of RAM disk space twice while decoding, but eventually the decode works fine. Then I try to get ARC to tell me the contents of the package, and the program shows me lots of funny numbers and characters after it tells me the archive is bad. So now I have no way to fix the thing. There was no sequence checking for any of the parts. The uuencoded binary was just chopped up by hand into 40K pieces. There is no way to detect a missing line so that I can ask for just one piece, and there is no hope of getting them all again from my Unix connection. I can try cut-and-paste again, but without the I-didn't-think-they-were-that-useful multi-part lines, I don't think it will work any better. We're pretty remote from the rest of the world up here in Vancouver in terms of net topology, and it is more of a pain than usual for me to post to the net, so I'm really reluctant to ask people to send replacements by mail. So I lose. I pay for connect time, too; usually my luck is *much* better. My plea: if you are going to post to comp.binaries.st, PLEASE get hold of Dumas' multi-part uuencoder, and let it chop your postings into nice tame %30K pieces that will go through most mailers, and let it do the sequence checking and add the chaining lines so that people like me have a better chance at uudecoding correctly when it gets here properly and have a better idea of what to fix or when to give up when the group loses or mangles things. I think it is a little too much to ask the moderator to rearrange it, but I'm sure he would make happy noises if you asked him for the sources/binaries to the Dumas uu?code. And if that doesn't work, I think I can get it to you, too. The source was supposed to run great on Unix or the ST. BTW: Jwahar, I *liked* the earlier ZMDM a lot, and used it quite regularly before I went over to getting my stuff over UUCP. Thanks from all of us for the posting, even if it didn't quite make it for me. And thanks to Howard Chu for a new ARC: I can't beleive what a handicap it was before to have an ARC that bombed when its output was redirected. -- ------------------------------------------------------------------------ "There was something fishy about the butler. I think he was a Pisces, | probably working for scale." - Nick Danger | uunet-----\ | Robert Thurlow !van-bc!rthurlow | ubc-cs----/ | ------------------------------ Date: 20 Jun 88 12:17:36 GMT From: unisoft!gethen!farren@ucbvax.Berkeley.EDU (Michael J. Farren) Subject: Re: Read Screen Character To: info-atari16@score.stanford.edu In article <478@mks.UUCP> wheels@mks.UUCP (Gerry Wheeler) writes: >> I have a problem [...] reading a character from screen at current >> cursor position. > >I would theorise that this is not possible. If it's that hard, how is it that IBM PC's can do it? (And I do mean in graphics mode, where the characters are, just as they are on the ST, just bit patterns in memory.) -- Michael J. Farren | "INVESTIGATE your point of view, don't just ,ucbvax, uunet, hoptoad-! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame ------------------------------ Date: 20 Jun 88 14:38:23 GMT From: braner@tcgould.tn.cornell.edu (braner) Subject: Re: Calling M. Braner To: info-atari16@score.stanford.edu [] C. Zimmer asked if BARREL can help him save an ST screen dump, upload to a (UNIX) mainframe, then print on a (color) printer. Well, BARREL will capture a screendump (upon Alt-Help) in RAM, and allow saving to disk, in 'SCODE' format. That is my own format that both compresses (somewhat) and converts to printable characters only. Thus the SCODEd file is very suitable for e-mail. The SDECODE program can decode such a file and display it on the ST. On the mainframe side I have a program called CBW2PS that decodes, then converts to Postscript for printing (C source available upon request). It is called CBW2PS since it handles monochrome screendumps only. For other kinds of printers and/or color dumps one would need to write different backends for CBW2PS (or SDECODE). - Moshe Braner PS: still need advice: what to do with my 7-month-old Atari SH204 hard disk that suddenly died? ------------------------------ Date: Mon, 20 Jun 1988 21:13:12 LCL From: MAXG%SUVM.BITNET@Forsythe.Stanford.EDU To: INFO-ATARI16@SCORE.STANFORD.EDU Subject: atari hard drive clones In reference to the June 14 message asking about clone hard drives for the Atari, there is an article coincidentally about that very topic in the new, i.e. July 1988, issue of STLog. The article is called "Frankendrive". Based on what the article says, it looks like you can put together your own hard drive...although I'm not convinced it is worth it. The guy put together a 30mg hard drive...the drive itself cost $265, and the price of the whole thing together ended up being $636. ------------------------------ Date: 19 Jun 88 22:37:32 GMT From: mcvax!unido!tub!tmpmbx!netmbx!fischer@uunet.uu.net (Axel Fischer) Subject: Assembler To: info-atari16@score.stanford.edu Recently I looked for a good assembler package for the Atari ST but I couldn't deceide which one I should buy. Could any please give me some advise and maybe a little comparision what they perform and cost ? Any help would be greatly appreciated ! -Axel What is now proved was once only imagined. (William Blake - The Marriage of Heaven and Hell) ------------------------------ Date: 19 Jun 88 19:02:01 GMT From: mcvax!unido!tub!tmpmbx!netmbx!hase@uunet.uu.net (Hartmut Semken) Subject: Re: Mono shakes/Uniterm blues To: info-atari16@score.stanford.edu In article <8806150400.AA20432@ucbvax.Berkeley.EDU> SKF8192@TAMSIGMA.BITNET (KEITH FISCHER -- GENERIC USER) writes: >I have a SM124 Monochrome monitor. I just recently moved and now the >screen endlessly shakes and quivers. Is there some adjustment I can >make to correct the problem? Check for sources of magnetic fields in the neibouhood of your SM124. My Philips color monitor, Atari pover supply, Epson printer (and so on) got moved far away of my SM124 for that reason. hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP High on a rocky promontory sat an Electric Monk on a bored horse. (D. Adams) ------------------------------ Date: 19 Jun 88 16:02:16 GMT From: oodis01!uplherc!sp7040!jsp@tis.llnl.gov (John Peters) Subject: Re: MWC & large arrays -- help! To: info-atari16@score.stanford.edu I have ran into this problem before to. My brother regularly corresponds with someone that helped with the 3.0 MCW developement. so here is the reason. The MWC compiler uses signed short offsets from a stack value for local variables. this means that you have 15 bits or 32K to use as an offset, question answered. This is not true of global variables. All global variables are long offset from a base address so the problem does not exist and structures and arrays can be as big as wanted. Hope this helped. I was taught to not use global variables much but it seems that they have their place. -- Johnnie -- ------------------------------ Date: 19 Jun 88 15:24:09 GMT From: oodis01!uplherc!sp7040!jsp@tis.llnl.gov (John Peters) Subject: Porting utilities to the ST. To: info-atari16@score.stanford.edu In article <6332@cup.portal.com>, Henry_Burdett_Messenger@cup.portal.com writes: > > Ugh. More UNIX weenies trying to determine our future. > > "I guess it's better than having them pump quarters in Pac-Man games... > " - John C. Dvorak > > Not always! Sometimes computer companies listen to them and lose their > shirts (e.g. Fortune Systems). > > It's 1988 and UNIX still S*cks. GEM ain't the greatest, and I'd rather > have X, but I have to have a brain-damaged operating system that's older > RT-11, for pity's sake! No thanks, I'll pass. > > Besides it usually isn't GEM; it's usually TOS. Yes, TOS is awful. Can > you say "CP/M with fender flares"? I knew you could. But UNIX is even > worse... (Hmm, you'd never know I'm a VMS person, would you :-) > "UNIX compatibility is snake oil." > - Ken H. Olson > > Henry B. Messenger (DEC can have its own opinions, I have mine) For one minute lets look at why UNIX is becoming popular. Did somebody say hundreds of utilites. And what is this compilers (C and Fortran) come standard with the operating system. And could it be that even from DEC UNIX is about a third the base price of VMS. Wow and VMS comes with what, golly gee an assembler and some system monitors. Geese if I want to use a compiler I have to pay how much more. You have obviously not been involved with a company that need to get alot out of little money. Now about using UNIX as a standard for the ST. I will admit that UNIX is not perfect (thats how I make my living). However, we need to start somewhere and GEM/TOS is not it. Also imagine trying to rewrite VMS for the ST. Talk about a system eats the system. UNIX, because of a basic simplicity runs 2 to 3 times as fast as VMS (my own bench marks ran as a user on both operating systems running on identically configured MicroVAX II's at 3 in the morning with nobody else on. So untill you can come up with VMS for the ST or write VMS utilites for the ST, please don't badmouth those people who are porting UNIX utilites to the ST. Don't use them if you don't want to but I use them often and really appreciate the hard work that have gone into them. -- Johnnie -- ------------------------------ End of Info-Atari16 Digest ************************** ------- From: FTP_Manager 29-JUN-1988 01:02 To: POSTMASTER Subj: Network mail failure Unable to return Network Mail to EARN.FINHUTC. Please check your Network Autho Local Mail delivery failed to following Usernames: A_MONK Mail text: Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 5776; Wed, 29 Jun 88 01:01:13 BS Received: by UKACRL (Mailer X1.25) id 5758; Wed, 29 Jun 88 01:01:08 BST Date: Wed, 22 Jun 88 17:55:49 PDT Reply-To: Info-Atari16@EDU.STANFORD.SCORE Sender: "Atari ST users forum (INFO-ATARI16)" Comments: Warning -- original Sender: tag was Info-Atari16-request@Score.Stanford.E From: Info-Atari16 Digest Subject: Info-Atari16 Digest V88 #291 To: ALASDAIR MONK Info-Atari16 Digest Wednesday, June 22, 1988 Volume 88 : Issue 291 This weeks Editor: Bill Westfield Today's Topics: errorchk re: Atari's new mega st system policy. How to subscribe to Sources. Re: Read Screen Character Re: Midi Mega's Re: C compilers on the ST Re: (none) Re: Read Screen Character Re: Read Screen Character Desktop publishing query Refreshing window text rapidly ---------------------------------------------------------------------- Date: 18 Jun 88 17:58:21 GMT From: mcvax!philmds!leo@uunet.uu.net (Leo de Wit) Subject: errorchk To: info-atari16@score.stanford.edu Having had a small problem recently with this program that is in Comp.sources.atari.st (address error on exit of other - GEM - program) I have added a fix. The reason seems to be that when some GEM programs terminate they are using the GEM-exit vector, and the exit routine still relies on A4 having a valid contents (I'm not sure). After I modified the code to save A4 on the stack the problem disappeared. Here is the relevant part of the code (comments omitted), with 2 instructions added: DTOPWAIT MOVE.L $602C,A0 MOVEQ.L #0,D1 BRA.S DTOPAREND DTOPARNT ADDQ.L #1,D1 MOVE.L 36(A0),A0 DTOPAREND TST.L (A0) BNE.S DTOPARNT CMP.B #3,D1 BNE.S DTWEND MOVE.L A4,-(SP) * Added this instruction to save A4 .... LEA WAITMSG(PC),A4 BRA.S DTOPW3 DTOPW2 EXT.W D0 MOVE.W D0,-(SP) MOVE.W #2,-(SP) MOVE.W #3,-(SP) TRAP #BIOS ADDQ.L #6,SP DTOPW3 MOVE.B (A4)+,D0 BNE.S DTOPW2 MOVE.W #2,-(SP) MOVE.W #2,-(SP) TRAP #BIOS ADDQ.L #4,SP MOVE.L (SP)+,A4 * .... and this one to restore A4 DTWEND MOVE.L OLDVEC(PC),-(SP) RTS Leo. * Not an instruction, more a periferal 8-) ------------------------------ From: dmak%lynx.northeastern.edu@RELAY.CS.NET Date: Sun, 19 Jun 88 09:16:48 EDT To: info-atari16@SCORE.STANFORD.EDU Subject: re: Atari's new mega st system policy. >Date: 9 Jun 88 12:05:00 GMT >From: inmet!ishmael!inmet!authorplaceholder@bbn.com >Subject: Atari's new mega st system policy >To: info-atari16@score.stanford.edu > --- some background deleted --- >the guy says 'well, I hate to tell you this, but Atari has just >announced that dealers cannot purchase mega St's > unless they also purchase an Atari laser printer, so I can't >sell any megas except bundled with their laser printer' >(this is a one man music store.....not a department store). >So, now I understand why the first store is reevaluating its' >dealership. >So I say ' well give me a price on the 2 and 4 meg mega systems >that you are selling just for the hell of it'. He proceeds to >give me a price of just under $4000.00 for the 4 meg which includes >a 20 meg hard disk, the laser printer, and a bunch of software >including VIP professional, and some other 'business' oriented >stuff. The price for a similar package for a 2 meg, no hard disk, >and only one floppy came in at $29xx.xx ( don't remember the exact >change'. My response to him was ' gee....if I HAVE to spend $3000.00 >I would probably get a Mac SE with a 20 meg hard disk and no >laser printer that I don't want anyway.... >his response was 'good point'. I don't know where these dealers got their information, but I work at an Atari dealership near Boston and know we still can purchase Mega STs without their laser printers/hard drive/software. I believe people are confusing Atari's NEW OFFER to sell these ``bundles'' at special prices. I have confirmed this with the store owner: Dealers can buy the Megas packaged with: SLM804 Laser Printer, Hard Disk (New Megafiler 20), Mega ST (either 2 or 4), VIP Professional, MS-Write, and others misc. programs. This --Ultimate Desktop Publishing System-- IS NOT being forced down everyones throat... We just got in a shipment consisting of four of these packages, and based on the price we're selling them at, I know this is a GREAT deal. (Roughly $2000 for Mega4, $1000 for Laser, and free software). Would someone from Atari PLEASE try to straighten this matter out!? INTERNET ADDR: dmak@lynx.northeastern.edu Dave Mak ------------------------------ Date: 18 Jun 88 14:34:55 GMT From: dalcs!dalcsug!euloth@uunet.uu.net (George Seto) Subject: How to subscribe to Sources. To: info-atari16@score.stanford.edu We haven't received anything in the comp.sources.atari.st for quite some time. Steven tells me he has been placing things there. How may we get back on the list to receive this valuable resource? Can anyone help? Thanks. -- ******************************************************************************* * euloth@dalcsug.uucp || Disclaimer: All opinions are my own unless other- * * /\/\/\/\/\/\/\/\/\/\ || wise noted. * ****AKA: Atari Nut************************************************************* ------------------------------ Date: 19 Jun 88 09:05:37 GMT From: rling@june.cs.washington.edu (Robert Ling) Subject: Re: Read Screen Character To: info-atari16@score.stanford.edu In article <478@mks.UUCP>, wheels@mks.UUCP (Gerry Wheeler) writes: > In article <8806151250.AA29397@ucbvax.Berkeley.EDU>, U211510@HNYKUN11.BITNET (Wil Groenen) writes: > > I have a problem [...] reading a character from screen at current > > cursor position. > > ... but I would theorise that this is not possible. > Remember, once the character is drawn on the screen it is just a > bunch of bits. This is quite unlike the usual video screens for > IBM-type computers. It would take quite a program to read the pattern > of bits and tell which character it was. If you use the BIOS/GEMDOS to write to the screen, the characters are in fixed positions. If you also had access to the font used, the problem is one of (bit) pattern matching. In high resolution, a screen character is contained in 16 bytes, all you have to do is match this set of 16 bytes against 256 sets in the font table. This is actually what happens in IBM-type computers when in graphics mode. Things are a little bit more complicated if you use the DVI since the area of the screen that contains the character might be "corrupted" by other things and the character might not be normal sized. - Robert Ling ------------------------------ Date: 18 Jun 88 04:49:42 GMT From: mtunx!mtuxo!mtgzz!drutx!druhi!med@rutgers.edu (Myron Drapal) Subject: Re: Midi Mega's To: info-atari16@score.stanford.edu In article <1073@atari.UUCP>, good@atari.UUCP (Roy Good) writes: > In a recent posting, Keith Hedger flamed Atari's policy of marketing Megas, > with particular reference to the Midi world. I will refrain from posting > my personal opinion of the use of expletives etc in public posting. I have to say that I don't go for those kinds of words in a USENET posting, but I sure can identify with the frustration that was behind that posting. And to have someone at Atari complaining about this is a little odd (don't you have more important work to do, Mr. Good?. It seems that the only way lately to get you, or anyone else at Atari, to comment, is to use these words...) > > The following is the response from Larry Samuels, Atari's corporate VP of > Strategic Markets, who has a special interest in the music market. I quote > it verbatim: > --------------------------------------------------------------------------- > Answer from the "guys at Atari"... > In answer to the recent "FLAME" on USENET regarding Atari's Mega system sales > requirements for music dealers: the Mega 2 and Mega 4 computers CAN be > purchased by music retailers separately from laser printers. The Mega system > sales program described in the message from Keith Hedger pertains to computer > specialty dealers only. Why should they be "punished" (e.g. forced to purchase an over-priced, under- featured laser printer and then try to foist it onto an unsuspecting customer)? If the laser printer is such a dog (as it seems to be), why don't you "guys at Atari" just shut up and eat them quietly? > We are > concerned, however, that such misinformation would be placed in a public forum > and accordingly we request that in advance of such statements in the future, > Atari be called and the facts of such perceived policies be confirmed. I just couldn't let this one go without a chuckle ;-)... Atari, the premier company of vaporware and "misinformation", criticizing someone for the same. > > "Atari and Music...Catch the Wave" > Larry Samuels > V.P. Strategic Markets, Atari Corporation (U.S.) > --------------------------------------------------------------------------- "Catch the Wave"? Yes, catch the wave and wave bye-bye to Atari... Myron Drapal AT&T Denver ihnp4!druhi!med ------------------------------ Date: 19 Jun 88 02:56:48 GMT From: ucsdhub!jack!crash!pnet01!sreeb@ucsd.edu (Ed Beers) Subject: Re: C compilers on the ST To: info-atari16@score.stanford.edu While Alcyon seems to work ( I got it with my developers kit in addition to MWC ), it lacks a source level debugger. I couldn't live without Csd now. Csd seems to work very well. The only bug I have encountered is that integers are displayed as if they were unsigned integers. It has cut my debugging time in half. UUCP: ,cbosgd hplabs!hp-sdd sdcsvax nosc-!crash!pnet01!sreeb ARPA: crash!pnet01!sreeb@nosc.mil INET: sreeb@pnet01.cts.com ------------------------------ Date: 17 Jun 88 22:16:41 GMT From: unisoft!gethen!bdt!david@ucbvax.Berkeley.EDU (David Beckemeyer) Subject: Re: (none) To: info-atari16@score.stanford.edu In article <8806140047.AA18091@ucbvax.Berkeley.EDU> U0179@DGOGWDG5.BITNET ("GWDGV1::WHUEBNER") writes: >Two questions about ST hardware: > >1) Does anyone know something about the SH204 HOST ADAPTER CARD bug ? > (HAC always returned SCSI success status even if the SCSI > controller (ADAPTEC 4000) signals an error) Well I know the problem exists with the version of SH204 that I bought (full price of $800!) two years ago. It's a bug in the PAL. I got a fix for it from Berkeley Micro Systems (415) 465-6956. The BMS fix consists of a replacement PAL which plugs in a socket on the SH204 host adapter board. I've been using the BMS PAL for several months with absolutely no problems. Disclaimer: I am not tied to BMS, except that in the past I have sold their BMS-100 host adapters to some of my customers. -- David Beckemeyer (david@bdt.uucp) | "Yea I've got medicine..." as the Beckemeyer Development Tools | cookie cocks a his Colt, "and if 478 Santa Clara Ave, Oakland, CA 94610 | you don't keep your mouth shut, I'm UUCP: ,unisoft,sun-!hoptoad!bdt!david | gonna give you a big dose of it!" ------------------------------ Date: 19 Jun 88 09:46:00 GMT From: mcvax!philmds!leo@uunet.uu.net (Leo de Wit) Subject: Re: Read Screen Character To: info-atari16@score.stanford.edu In article <8806151250.AA29397@ucbvax.Berkeley.EDU> U211510@HNYKUN11.BITNET (Wil Groenen) writes: >Dear readers, >I have a problem which some of you probably have encountered before, >that is reading a character from screen at current cursor position. >Somehow I have not been able to find the proper gemdos (?) function >call for this. Does anyone knows how to handle this, preferably in >Fortran or Pascal?? Sorry to disappoint you, but there is no trivial way to read a character from the screen. The ST has only graphics modes, no text modes as for instance the B.B.C or the MSX line of computers (storing characters in ASCII form in Ram). The MSX uses this feature for its screen editor. But, cheer up, there is a non-trivial way of doing it: you can match the bytes that form the character image against the TOS font(s) and return that character on a match or a space for instance if there is no match. This method was used by good ol' Sinclair Spectrum; that had a SCREEN$(row,col) function that returned the matching code for the image at (row,col). The Spectrum knew only one (graphics) mode. I'm planning to mail a screen dump program next week to the moderator of Comp.sources.atari.st; this program matches each character screen position against the TOS font and sends it to the printer. Really nice if you would like the compiler's output that is on the screen, or an error message, or a screenfull while you are in the editor, being dumped to the printer. It is as fast as just printing the text as a file. It uses a function that matches the character bit image at the position indicated. It is written in C (major 8-), so you could translate the source to Pascal or link the compiled C module. B.T.W. Speaking of languages, I thought you people in Nijmegen were all dedicated C/Unix hackers? Pascal ?????????? Fortran !"#$%~&*()_+=@% %=) Leo. ------------------------------ Date: 19 Jun 88 19:14:45 GMT From: lakesys!jason@csd1.milw.wisc.edu (Jason) Subject: Re: Read Screen Character To: info-atari16@score.stanford.edu In article <5143@june.cs.washington.edu>, rling@june.cs.washington.edu (Robert Ling) writes: > In article <478@mks.UUCP>, wheels@mks.UUCP (Gerry Wheeler) writes: > > In article <8806151250.AA29397@ucbvax.Berkeley.EDU>, U211510@HNYKUN11.BITNET (Wil Groenen) writes: > > > I have a problem [...] reading a character from screen at current > > > cursor position. > > [...Entire article deleted] > [...] > in fixed positions. If you also had access to the font used, the problem > is one of (bit) pattern matching. In high resolution, a screen character > [... Portion of article deleted] > > - Robert Ling Another way to do it (not reading the character bit maps after on the screen) would be to take over the character output routines (I don't recall what this would take), and put all the characters into an array. Of course, if your program was the only thing generating character output, it'd be more efficient to just put the characters in the array immediately. I would think that you'd have to handle the VT-52 stuff that the ST does in order to get an accurate array... This entire approach would only be valid if the characters in question had not yet been drawn on the screen. Jason "Not your average iconoclast" ------------------------------ Date: 19 Jun 88 20:58:48 GMT From: sdcc6!ir10@ucsd.edu (Donald R. Fredkin) Subject: Desktop publishing query To: info-atari16@score.stanford.edu A friend with an Atari-ST has just become the editor of her club's monthly newsletter, which is typically 20 pages long and contains limited art work. She would like to know what desktop publishing software is available for her computer, with positive and negative recommendations, and how she might be able to send the results of her efforts to either an Apple Laserwriter attached to a UNIX system or to a Laserwriter in a local copy shop that is attached to a Macintosh. Please reply by email to me and I'll pass the information on to my friend. I do not read this group, so posting your reply will not reach me. Thank you for your help. UUCP ,ihnp4,decvax!ucbvax,dcdwest,ucbvax-!ucsd.edu!drfredkin Internet drfredkin@ucsd.edu or drf%sdph2@ucsd.edu Bitnet drfredkin@ucsd -- UUCP ,ihnp4,decvax!ucbvax,dcdwest,ucbvax-!ucsd.edu!drfredkin Internet drfredkin@ucsd.edu or drf%sdph2@ucsd.edu Bitnet drfredkin@ucsd ------------------------------ Date: 19 Jun 88 18:36:22 GMT From: imagine!news@itsgw.rpi.edu (news) Subject: Refreshing window text rapidly To: info-atari16@score.stanford.edu [] I'm working on a program that needs to manage several windows, with the interiors filled with text. However, the text has to be in the user's choice of point sizes (from the system fonts), since small letters are an option I need to include in this program. (limited screen space...) Now, the problem is, if I draw this text by setting the size with vst_height and then draw the text with v_gtext, it takes too long to refresh the windows. These windows need to be updated quickly. I need a way faster than v_gtext to display text in my choice of point sizes (6 to 16)... I wouldn't mind being limited to positioning the characters on an 80x24 grid or anything, but I do need to be able to make then smaller. (Cconws() always seems to make 16-point ones...) From: kibo@pawl5.pawl.rpi.edu (James Parry) Path: pawl5.pawl.rpi.edu!kibo Does anyone know a way to draw text faster than v_gtext can? ----------- Kibo (Jim Parry) userfe0n%mts.rpi.edu@itsgw.rpi.edu userfe0n@rpitsmts.bitnet or use above address from headers or snail-mail me at : 138 Birch Lane, Scotia, NY 12302 USA ------------------------------ End of Info-Atari16 Digest ************************** ------- From: FTP_Manager 29-JUN-1988 01:03 To: POSTMASTER Subj: Network mail failure Unable to return Network Mail to EARN.FINHUTC. Please check your Network Autho Local Mail delivery failed to following Usernames: A_MONK Mail text: Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 5815; Wed, 29 Jun 88 01:01:27 BS Received: by UKACRL (Mailer X1.25) id 5801; Wed, 29 Jun 88 01:01:23 BST Date: Fri, 24 Jun 88 23:30:52 PDT Reply-To: Info-Atari16@EDU.STANFORD.SCORE Sender: "Atari ST users forum (INFO-ATARI16)" Comments: Warning -- original Sender: tag was Info-Atari16-request@Score.Stanford.E From: Info-Atari16 Digest Subject: Info-Atari16 Digest V88 #293 To: ALASDAIR MONK Info-Atari16 Digest Friday, June 24, 1988 Volume 88 : Issue 293 This weeks Editor: Bill Westfield Today's Topics: Re: Mark Johnson C Re: Midi problem revisted Re: Read Screen Character Re: Question about DigiSpec Re: Atari Hard drive "clones" Midi File Format Re: mg2a wanted - where is it? RE: Jos Vermaseren - Posting GEMDOS ... (illegality) Re: Assembler Looking for 68k freaks Ataris:games, business,education? VT100 clear screen; Reading chars from ST screen ---------------------------------------------------------------------- Date: 20 Jun 88 11:23:05 GMT From: mcvax!ruuinf!piet@uunet.uu.net (Piet van Oostrum) Subject: Re: Mark Johnson C To: info-atari16@score.stanford.edu In article <155@lzaz.ATT.COM> bds@lzaz.ATT.COM (BRUCE SZABLAK) writes: In article <8806162102.AA01677@ucbvax.Berkeley.EDU>, nfrech@ALMSA-1.ARPA ("Norman R. Frech") writes: > > Has anyone out there had any experience/luck with Mark Johnson C. Yes, I've had v2.0 for a week or 2, and I've compiled one program in excess of 1700 lines or so with no problem. I'd like to help you but your problem description is pretty vague (but not more so than some MR's I've received ;-) ). I tried to compile some programs with MJC V1.2, and just got V2.0, but did not try it yet. I also expierenced some problems (note these are all V1.2): 1. macro expansion with a trap inside get screwed (e.g. #define Fseek(a,b,c) trap(....)) 2. The stdio package is almost totally broken. I rewrote a part of it but have not ported the changes to V2.0. Some problems: Redirection from a shell gives big problems. MJC just supposes that stdin and stdout are terminals if they are not redirected on its command line. So reading from a file as stdin clobbers the file. Besides, it doesn't use Fforce, so you end up with the wrong file handles (no longer 0, 1) if you do redirection in the program. Next the buffering is incomplete. fread and fwrite use unbuffered I/O, so you can't mix them with other stdio calls, like putchar. The files are not closed on exit, so you MUST do that yourself. fseek also doesn't take buffering into account. I don't know any more from the top of my head. I'm waiting for GNU cc for the ST! ------------------------------ Date: 20 Jun 88 12:10:49 GMT From: mcvax!philmds!leo@uunet.uu.net (Leo de Wit) Subject: Re: Midi problem revisted To: info-atari16@score.stanford.edu In article <8806151931.AA05945@ucbvax.Berkeley.EDU> UUCJEFF@ECNCDC.BITNET writes: >A few weeks ago a reader had a problem with outputing several midi bytes. >I think he was trying to use the Xbtimer. I have later found out courtesy >of Stefan Daystrom of Hybrid Arts that you cannot have any TOS, BIOS, or >XBIOS calls inside an interrupt. You have to do whatever it is you want without >the calls, this is due to the re-entrancy characteristics of the ST. >Therefore, you cannot use Bconstat or Midiws from inside and Xbtimer interrupt. > [14 lines deleted, says vi 8-] I've tried to figure out the characteristics of the TOS, BIOS and XBIOS calls as far as re-entrancy is conceirned and I came to the following conclusions (correct me if I'm wrong, I've just disassembled some code): 1) TOS calls are not re-entrant whatsoever. This is due to the fact that the current registers are saved on the basepage of the current process, and restored on exit from the call. Any TOS call from within a TOS call would overwrite the saved registers. Also the stack pointer is set to point to a definite area (except in the case of the Super() call). 2) BIOS and XBIOS calls (they have the same characteristics) ARE in fact re-entrant, be it not multitasking re-entrant. The registers D3-D7 and A3-A7 are saved on a separate stack pointed to by SAVPTR ($4A2). This pointer is updated when the registers have been saved, and also when they have been restored (so you may see SAVPTR as a kind of stack pointer). The problem with this scheme is that the BIOS (XBIOS) call can get interrupted when the registers are being stored and SAVPTR is not yet updated. When the interrupt routine now uses BIOS it gets the old SAVPTR and will overwrite the registers on that stack. A better approach for the save area would have been to FIRST update SAVPTR (thereby claiming the area) and THEN save the registers. 3) It is - More or Less - possible to use (X)BIOS even from within interrupt code. After some trying it worked (it was in fact your article that stimulated me). So first the More (I omitted a test to prevent re-entrance of this routine, in this case necessary but it could be done more general, permitting re-entrance): #include #define SAVPTR (*(WORD **)0x4A2) static WORD savebuf[24]; /* large enough for a PC, a SR and 10 regs */ intrupt() /* e.g. a vertical blank interrupt routine */ , WORD *savep; savep = SAVPTR; /* save the pointer */ SAVPTR = savebuf + sizeof(savebuf); /* point to tail of buffer */ /* here your code using (X)BIOS calls */ SAVPTR = savep; /* restore the pointer */ - And now the Less: Because the code of the BIOS/XBIOS depends rather heavy on static/external data you can get into trouble. For instance if your interrupt routine uses Bconout(2,..) and your application uses Bconout(2,..) you will get a mess (unless you are able to restore all the global/static data altered). In the case of Midiws() it is unlikely that your program uses that XBIOS call synchronous and asynchronous; and it is unlikely (but not inconceivable) that Midiws() shares updatable data with other calls (didn't check this one). The Midi user should give it a try, I think, before reinventing the wheel. But beware of stack sizes: don't overdo it with local variables, or use a separate stack area. There could be less space on the (supervisor) stack than you think; the reason why it didn't work the first time in my case. Leo. ------------------------------ Date: 21 Jun 88 01:50:42 GMT From: spdcc!merk!alliant!rosenkra@bbn.com (Bill Rosenkranz) Subject: Re: Read Screen Character To: info-atari16@score.stanford.edu --- In article <755@lakesys.UUCP> jason@lakesys.UUCP (Jason) writes: > Another way to do it (not reading the character bit maps after on the >screen) would be to take over the character output routines (I don't recall >what this would take), and put all the characters into an array. Of course, > > Jason >"Not your average iconoclast" i have actually done something along these lines (replacing the bios trap 13 handler with my own - in a futile attempt to buffer alcyon output to a file trouble is alcyon does not use trap13...waaahhh). it looks for any Bconout call going to dev=2 (CON:) and tee's to either a file or a buffer. it works well and _SHOULD_ be portable across ROM versions since i get the handler pointer from a sys vector. it is still kind of a kludge since i am not a 68000 as wiz, but it does work well from C (alcyon, of course :~). if anybody wants it, i'll post it here (it is short). actually i don't know if i CAN post it since it is basically the code in ROM with 10 or 12 lines added...if atari is listening, give me the ok (it is in abacus internals and you can easily look at it with dis2nd or any other disassembler, so this should not be a problem...) -bill ...!rutgers!mit-eddie!alliant!rosenkra ------------------------------ Date: 20 Jun 88 20:51:00 GMT From: uflorida!novavax!hcx1!devon@umd5.umd.edu Subject: Re: Question about DigiSpec To: info-atari16@score.stanford.edu I saw the combination at a computer faire in Worcester, MA and it was impressive. Computereyes is a good digitizer but with the normal limitation of colors it can only do so much and in fact grey scale looks better than color. However, with Spectrum 512 and the program that connects them, some really nice images can be digitized effectively. I recommend that if you're going to buy a digitizer that you get the whole setup with Spectrum 512, etc. or it won't be worthwhile. Devon ------------------------------ Date: 20 Jun 88 21:02:00 GMT From: uflorida!novavax!hcx1!devon@umd5.umd.edu Subject: Re: Atari Hard drive "clones" To: info-atari16@score.stanford.edu There are several companies which sell adapter boards to allow you to use a standard Adaptec-type controller board and ST-506 compatible hard drive. By far the best is from ICB, (they also make some nice third party ST hard drive subsystems). This board comes with good documentation, all of the necessary cabling, and a really good formatting program to configure the board for a wide variety of controller and disk combinations. Any Atari dealer should be able to order this for you through CSS/Apex. Devon ------------------------------ Date: 20 Jun 88 23:33:21 GMT From: sco!kurth@uunet.uu.net (Kurt Hutchison) Subject: Midi File Format To: info-atari16@score.stanford.edu Does anyone know how I can get a copy of the new Standard Midi File Format? I have heard that there is a standard and that several well-known sequencer vendors have converted to this format. I posted about this about a month ago and never received a response. Thanks in advance, - kurt -- ------------------------------------------------------------------------- Kurt Hutchison The Santa Cruz Operation Software Engineer Trumpet player, synth player, pianist, cyclist, philosopher at large The above opinions (if any) are my own ------------------------------ Date: 20 Jun 88 17:03:56 GMT From: van-bc!rthurlow@uunet.uu.net (Rob Thurlow) Subject: Re: mg2a wanted - where is it? To: info-atari16@score.stanford.edu In article <45448IA0@PSUVM> IA0@PSUVM.BITNET writes: >Only the first part of mg2a appeared here. If anyone could repost it >or email it to me, I would appreciate it. Did this just get posted to the binaries group or the sources group? Because none of it showed up here at all! We also got the last three of eight parts of a software list for the ST - not too useful! Maybe a repost if this was widespread? BTW, time for a note of thanks to the Lake Systems people for the lakesys file server. I've had quite good luck since I figured out how to get mail to it, and it is a great service to have. I and the people in my users group thank you for the software, especially Uniterm 2.0c. -- ------------------------------------------------------------------------ "There was something fishy about the butler. I think he was a Pisces, | probably working for scale." - Nick Danger | uunet-----\ | Robert Thurlow !van-bc!rthurlow | ubc-cs----/ | ------------------------------ Date: Tue, 21-JUN-1988 11:31 +0200 From: "GWDGV1::WHUEBNER" To: info-atari16@su-score.STANFORD.EDU Subject: RE: Jos Vermaseren - Posting GEMDOS ... (illegality) In response to your mail dated 21-APR-88 (Vol 88 Issue 211) - Posting GEMDOS improvements - you asked ... >2: a book that was recently published in Germany with a discompilation of > of GEMDOS. This last thing seems to be fully illegal to me. Is one really > allowed to do this? As one of the three authors (part AHDI) of the book "Das TOS-Listing - BIOS/GEMDOS/VDI (Kramer,Riebl,Huebner) I have to answer your question with Y E A H . We are really allowed to publish this book with a written permission of ATARI-Deutschland. Best regards PS. Sorry about the late response, I am new on this NET and it takes some time to step through old reviews, by the way, I am also very interested in testing your JAMDOS, too. +--------------------------------------------+ | BITNET: U0179 at DG0GWDG5 (W.Huebner) | | VAXMAIL: PSI%45551032808::GWDGV1::WHUEBNER | | West Germany | +--------------------------------------------+--------------------+ | All opinions are my own, and not necessarily always correct ... | | You know >>> NOBODY IS PERFECT <<< | ------------------------------ Date: 21 Jun 88 12:44:55 GMT From: dogie!stevens@csd1.milw.wisc.edu (PAul STevens-MACC) Subject: Re: Assembler To: info-atari16@score.stanford.edu In article <1946@netmbx.UUCP>, fischer@netmbx.UUCP (Axel Fischer) writes... > >Could any please give me some advise and maybe a little comparision [ of assemblers ] I have used the Metacomco assembler for a rather large project over the last year. I have discovered no bugs or 'features' to work around. I have not given the linker any kind of workout as the 15 or so individually assembled modules contain *no* entry point or external references (to maintain position independence). stevens@vms.macc.wisc.edu stevens@wiscmacc.bitnet ------------------------------ Date: 21 Jun 88 14:41:59 GMT From: lakesys!martin@csd1.milw.wisc.edu (Martin Wiedmeyer) Subject: Looking for 68k freaks To: info-atari16@score.stanford.edu I'm posting this for a friend, please note his email account expires on 7/1/88. If you'd like to contact Chris after that time, please use the snailmail address at the tail of his message. Marty Wiedmeyer martin@lakesys.UUCP *********************************************************************** Hello my name is Chris Jeffery and I am an under-graduate at the University of Newcastle upon Tyne, UK. I hope you can help me: I own an Atari 1040 ST (Colour and Mono system) which I use for my university work, entertainment *and* for the development of acade games to be sold around the world. My first game is due for release around the 4th of July. I would be grateful if you could put me in touch with ST users in the US who would be prepared to send me magazine reviews etc., and maybe swap hints, tips and Ideas? The game is called Exodus, and is to be release on the Diamond Games label. It was written entirely in M68000 assembler and I would be very interested in 'meeting' other M68k freaks. Thank you in advance, Chris Jeffery. ( fja1%ncl.turing@uk.ac.newcastle ) N.B. The mail address above is only valid until the 1st of July as at present I don't know where I will be working over the summer vac. If anyone wishes to contact me after that please use my postal address : Chris Jeffery, c/o 58 Chestnut Avenue, Billericay Essex CM12 9JG ENGLAND *********************************************************************** -- | Marty Wiedmeyer | | Lake Systems, Milwaukee, WI | | UUCP: uwvax!uwmcsd1!lakesys!martin | | Disclaimer: I take the heat for my own (mis)statements..... | ------------------------------ From: KENNEDY%DALAC.BITNET@Forsythe.Stanford.EDU Date: Tue, 21 Jun 88 14:49 ADT Subject: Ataris:games, business,education? To: info-atari16@score.stanford.edu X-Vms-To: IN%"info-atari16@score.stanford.edu" I've missed a bit of this discussion group recently, so I hope this is not out of order. I recall a number of comments about how Atari should either fish or cut bait with respect either to being a 'games' computer or a 'serious' computer (for businesses etc.) I don't recall much discussion of the role Atari could and should play in education in universities. And yet it must be the case that many readers of this net group are university users. At Dalhousie we have two Atari 1040 labs, one in the English Dept and one in the Engineering Dept. We thought we could demonstrate the versatility of the machine with this range of uses. And we are happily using the machine in both places. Our standard wordprocessor is WordPerfect; we use Drafix in Engineering, several languages, Publishing Partner and a few other things (like Uniterm, of course). But I wonder where the other kinds of software are that could be designed especially for educational use? Is there any work going on for Atari based CAI packages? Any of the grammar checkers, or writing assistants, or thinktank packages, or split screen writing tutorials like the kind you can get for the Mac? Is Atari seriously encouraging developers into the university education market? If so I'd be glad to hear of the products that people are finding useful. ------------------------------ Date: 21-JUN-1988 13:31:36 GMT From: F026%CPC865.UEA.AC.UK@Forsythe.Stanford.EDU To: Info-Atari16@SCORE.STANFORD.EDU Subject: VT100 clear screen; Reading chars from ST screen > >In article <246@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >> >>$ cls :== set terminal /width=80 >> >>to clear the screen. It doesn't work on some cheap VT100 clones, like >>the C. Itoh CIT-101. > >That's what I like about my Plessey terminal (witch is a CIT-101, a >little glue and a piece of plastic..8-) > >Hartmut Semken > If I remember right, the CIT has the 'feature' that switching between 80 & 132 columns does not clear the screen. This can be switched off locally (one of those little bit-toggles in the SETUP mode) or you could use a proper ANSI 'clear-screen' sequence. Include this in your LOGIN.COM (assuming you're using a VAX!): $ esc[0,8] == 27 $ cls == "write sys$output """+esc+"[2J""" The escape code (char 27) followed by '[' is called a Control Sequence Introducer (or CSI for short - 8 bit ANSI has a single-byte version as well, but most terminals prefer the 7-bit version). '2' is the parameter specifying the region as 'whole screen' and 'J' is the code for 'clear region'. Mike. ------ > >(Wil Groenen) writes: >> I have a problem [...] reading a character from screen at current >> cursor position. > >I do not have detailed knowledge about this (my manuals aren't here >at the moment), but I would theorise that this is not possible. >Remember, once the character is drawn on the screen it is just a >bunch of bits. This is quite unlike the usual video screens for >IBM-type computers. It would take quite a program to read the pattern >of bits and tell which character it was. >-- > Gerry Wheeler > Just to reduce the damper put on that idea, that's exactly what Acorn's BBC Micro did: there was a system call to read the bits under the current cursor position & compare them with the character bit-maps held in ROM, to allow screen editing in modes 0-6. The BBC Micro was a 6502 8-bit machine running at standard speed (1MHz?): I'm sure a 68000 can do as well! Mike. - - - - - - - - - - - - Mike Salmon, Climatic Research Unit, University of East Anglia, Norwich, UK JANET: m.salmon@uea.cpc865 | BITNET: f026@cpc865.uea.ac.uk | BIX: msalmon Anywhere else: f026%cpc865.uea@ukacrl.bitnet | Time Zone: BST (GMT + 1) ---> Gateways hate me - don't assume I heard you 'til you've got my reply.<--- "Hey guys, you may like to know that although this cave is not in a mountain it is thirteen miles above ground level. Hey guys? Oh well, they'll find out." ------------------------------ End of Info-Atari16 Digest ************************** ------- From: FTP_Manager 29-JUN-1988 07:19 To: POSTMASTER Subj: Network mail failure Unable to return Network Mail to EARN.FINHUTC. Please check your Network Autho Local Mail delivery failed to following Usernames: A_MONK Mail text: Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 9023; Wed, 29 Jun 88 07:18:34 BS Received: by UKACRL (Mailer X1.25) id 9012; Wed, 29 Jun 88 07:18:31 BST Date: Fri, 24 Jun 88 23:44:55 PDT Reply-To: Info-Atari16@EDU.STANFORD.SCORE Sender: "Atari ST users forum (INFO-ATARI16)" Comments: Warning -- original Sender: tag was Info-Atari16-request@Score.Stanford.E From: Info-Atari16 Digest Subject: Info-Atari16 Digest V88 #294 To: ALASDAIR MONK Info-Atari16 Digest Friday, June 24, 1988 Volume 88 : Issue 294 This weeks Editor: Bill Westfield Today's Topics: Re: Midi File Format Re: Midi File Format Re: Read Screen Character More mega policy from k. hedger UUPC Re: Midi Mega's Changing Resolutions Re: Refreshing window text rapidly Re: COMPUTE! ST Public Domain/Low-cost Software Need ST Help - Chicago UUCP address of pm and bammi at case western university? Re: Mono shakes/Uniterm blues 8th-Bit Prefixing Bug in UniTerm Kermit minix ---------------------------------------------------------------------- Date: 21 Jun 88 12:41:35 GMT From: mtunx!lzaz!hcj@rutgers.edu (HC Johnson) Subject: Re: Midi File Format To: info-atari16@score.stanford.edu Subject: Midi File Format >Does anyone know how I can get a copy of the >new Standard Midi File Format? I have heard >that there is a standard and that several well-known >sequencer vendors have converted to this format. > >I posted about this about a month ago and >never received a response. > > Thanks in advance, > - kurt There is attempt to produce a MIDI standard. The current DRAFT standard is 0.06, and can be obtained from: Dave Oppenheim Opcode Systems 1024 Hamilton Court Menlo Park, California 94025 (415) 321-8977 I got my copy by just calling. Some personal comments on the MIDI standard. I have Master Tracks Pro (Atari ST). This excellent sequencer supports two formats: Its own, and MIDI std. Its own format saves EVERYTHING, and can be reloaded without loss of information. When MIDI format is reloaded, some niggly details are lost. MIDI standard is easily implemented, IF YOU ARE A PROGRAMMER. I have written a converter for Music Studio to MIDI STD, Master tracks (C64) to MIDI STD, and Music construction set to MIDI STD. The first two were straight forward; the latter requires interfacing to SMUS-IFF, the other standard format. SMUS is in note-on-staff notation, leaving timing to be recreated. Howard Johnson ATT ...att!lzaz!hcj 201 591 1598 ------------------------------ Date: 21 Jun 88 18:59:51 GMT From: accelerator.eng.ohio-state.edu!czei@tut.cis.ohio-state.edu (Michael S. Czeiszperger) Subject: Re: Midi File Format To: info-atari16@score.stanford.edu In article <158@lzaz.ATT.COM> hcj@lzaz.ATT.COM (HC Johnson) writes: >I have written a converter for Music Studio to MIDI STD, Master tracks (C64) >to MIDI STD, and Music construction set to MIDI STD. >The first two were straight forward; the latter requires interfacing to >SMUS-IFF, the other standard format. SMUS is in note-on-staff notation, >leaving timing to be recreated. > If everyone's got a SMF translater, it's time we got some sequences posted on the net. It would be interesting to do collaborative pieces where several people help compose one piece of music by sending the different parts back and forth. If I was to post a SMF sequence, what format would be appropriate? Binhex could be used but I don't know how many non-mac computers use that format. -- Michael S. Czeiszperger | "The only good composer is a dead composer" Systems Analyst | Snail: 2015 Neil Avenue (614) The Ohio State University | Columbus, OH 43210 292- ARPA:czei@accelerator.eng.ohio-state.edu PAN:CZEI 0161 ------------------------------ Date: 20 Jun 88 15:33:12 GMT From: mcvax!unido!mutec!ud@uunet.uu.net (Ulrich Dessauer) Subject: Re: Read Screen Character To: info-atari16@score.stanford.edu In article <8806151250.AA29397@ucbvax.Berkeley.EDU> U211510@HNYKUN11.BITNET (Wil Groenen) writes: >I have a problem which some of you probably have encountered before, >that is reading a character from screen at current cursor position. >Somehow I have not been able to find the proper gemdos (?) function >call for this. Does anyone knows how to handle this, preferably in >Fortran or Pascal?? The problem of the ST is his graphic-mode where also all text will be put out. To get a charackter from the screen, you first have to calculate the Postion in the graphic-screen, then compare the current 8 * 16 (or 8 * 8) field with the current systemfont. You see, it is a lot of work, so the (nearly) only possible language is assembler. As I know, gemdos doesn't support such a function, but perhaps later it will do it :-). Greetings, U//i -- UUCP: ..!unido!mutec!ud ud@mutec.UUCP Snail: Ulrich Dessauer Markt&Technik Verlag AG, Hans-Pinsel-Strasse 2, D-8013 Haar Voice: +49 89 4613 745 (Office) ------------------------------ Date: 20 Jun 88 14:44:00 GMT From: inmet!ishmael!inmet!authorplaceholder@bbn.com Subject: More mega policy from k. hedger To: info-atari16@score.stanford.edu I have just read the response to my posting regarding Atari's mega-st marketing policies. 1) As for my using expletives on the network, I apologize publicly for my language in my original posting. 2) The 'Guys at Atari' say that this policy doesn't apply to music stores.....interesting, both of the places I talked to were music stores. The first is a full line music store that has been selling ST's for at least 6 months now. As soon as the MEGA'S were available, they had them. These are the guys that told me ' uuuummmm we're re-evaluating whether we're going to carry Atari computers anymore' Isn't it a coincidence that this statements comes one day after the other dealer I talked to tells me he received the letter from Atari outlining the new policy. 3) The 'Guys from Atari' suggest that I check my facts more carefully before posting to the net. Just exactly who am I supposed to check with if not the 2 dealers in town that I know of ???? I can assure you that my original posting was based on information I received from local Atari dealers as stated. If your policy is what you say it is, then I can assure you that you have some confused dealers in Boston , Mass. keith hedger ------------------------------ Date: 21 Jun 88 18:22:09 GMT From: agate!saturn!ssyx.ucsc.edu!koreth@ucbvax.Berkeley.EDU (Steven Grimm) Subject: UUPC To: info-atari16@score.stanford.edu Does anyone have UUPC binaries they'd be willing to mail me? I can't get it to work properly under Laser C. --- These are my opinions, and in no way reflect those of UCSC, which are wrong. Steven Grimm Moderator, comp.,sources,binaries-.atari.st koreth@ssyx.ucsc.edu ...!ucbvax!ucscc!ssyx!koreth ------------------------------ Date: 21 Jun 88 17:03:05 GMT From: ubc-cs!alberta!calgary!brinsmead@beaver.cs.washington.edu (Mark Brinsmead) Subject: Re: Midi Mega's To: info-atari16@score.stanford.edu In article <3160@druhi.ATT.COM>, med@druhi.ATT.COM (Myron Drapal) writes: > In article <1073@atari.UUCP>, good@atari.UUCP (Roy Good) writes: > > We are > > concerned, however, that such misinformation would be placed in a public forum > > and accordingly we request that in advance of such statements in the future, > > Atari be called and the facts of such perceived policies be confirmed. > > I just couldn't let this one go without a chuckle ;-)... Atari, the premier > company of vaporware and "misinformation", criticizing someone for the same. > Say, good point. Of course, no matter how bad certain corporate entities might be in this regard, it should not really justify rude or thoughtless criticism. On the other hand, they have had some pretty (dare I say it?) st*pid (they probably can't sue me for that) policies in the past, and its looking as though things may be getting worse, not better. Well, now that I've had my two cents worth, I think I'll just stay out of this discussion, at least until Atari *REALLY* confirms (or hopefully, denies) this rumour (about the laser printers). ------------------------------ Reply-To: Date: Wed, 22 Jun 88 16:28:24 EDT From: Jack_Mason@CSC03.CEO.DG.COM To: info-atari16@score.stanford.edu Subject: Changing Resolutions Does anyone know how to position the mouse cursor under program control? I have not been able to get anything to work so far. How about positioning the graphics cursor (as opposed to the text cursor, which is easy!)? ------------------------------ Date: 22 Jun 88 05:43:30 GMT From: spdcc!merk!alliant!rosenkra@husc6.harvard.edu (Bill Rosenkranz) Subject: Re: Refreshing window text rapidly To: info-atari16@score.stanford.edu ---- In article <935@imagine.PAWL.RPI.EDU> kibo () writes: -> I need a way faster than v_gtext -> to display text in my choice of point sizes (6 to 16)... I wouldn't mind -> being limited to positioning the characters on an 80x24 grid or anything, -> but I do need to be able to make then smaller. (Cconws() always seems to -> make 16-point ones...) you can actually replace the system fonts with your own without too much difficulty. the pointers to the fonts can be accessed via line-A and you can easily switch these pointers on the fly, perhaps even controlled by your own control sequence (maybe like nroff "." commands if you like). the bios/gemdos char output routines (i think) look for the default system font and just draw the current char. that's how you can make your ST kinda look like a mac (with "Chicago" font...). -bill ...!rutgers!mit-eddie!alliant!rosenkra ------------------------------ Date: 21 Jun 88 23:48:56 GMT From: hp-pcd!hpcvmb!jma@hplabs.hp.com (John Altendorf) Subject: Re: COMPUTE! ST To: info-atari16@score.stanford.edu I had just renewed my subscription when I heard the same rumor. I called a phone number that I had from some subscription information and found out that it is true. Compute will soon cease to publish Compute ST. They gave me a choice to receive the regular Compute as a substitute or to get a refund. I asked for the refund and hope to see the credit on my next VISA bill. In my opinion, it is really too bad that they are discontinuing the ST version. I enjoyed their articles and the software that came with it. John ...!hplabs!hp-pcd!jma ------------------------------ Date: 22 Jun 88 20:53:11 GMT From: aftac.tis.llnl.gov!mcclean@tis.llnl.gov (Bonnie McClean) Subject: Public Domain/Low-cost Software To: info-atari16@score.stanford.edu I am not a regular reader of this group. I seem to remember, however, a long list of public domain or low cost Atari ST software being posted a while ago. Can someone mail me this list or any other information on acquiring inexpensive or free software. Thanks - Bonnie McClean mcclean@tis.llnl.gov ------------------------------ Date: 21 Jun 88 20:51:00 GMT From: uxh.cso.uiuc.edu!fleming@uxc.cso.uiuc.edu Subject: Need ST Help - Chicago To: info-atari16@score.stanford.edu I need some help locating an Atari dealer in Chicago that handles the ST. I have to find someine to rent a few for a conference in December. As I am totally ignorant about this computer, I'd appreciate it if someone would E-Mail me some basic info. Thanks much. Declan ------------------------------ Date: 17 Jun 88 10:13:28 GMT From: iconsys!caeco!jose!pedro!darin_wayrynen@uunet.uu.net (Darin Wayrynen) Subject: UUCP address of pm and bammi at case western university? To: info-atari16@score.stanford.edu I need to have the uucp addresses of pm and bammi. Thanks in advance.. ------------------------------ Date: 22 Jun 88 04:06:38 GMT From: portal!cup.portal.com!Alice_Helen_Amore@uunet.uu.net Subject: Re: Mono shakes/Uniterm blues To: info-atari16@score.stanford.edu My monochrome developed the shakes when I moved my system, too. I discovered that the display shook only when the refrigerator motor was cranking. Move your system to an isolated outlet and see if that helps. Alice Amore ------------------------------ Date: 21 Jun 88 08:03:01 GMT From: portal!cup.portal.com!R_Tim_Coslet@uunet.uu.net Subject: 8th-Bit Prefixing Bug in UniTerm Kermit To: info-atari16@score.stanford.edu I have encountered a bug in UniTerm's Kermit File Transfer Protocol. I thought other users of UniTerm might like to know about this Bug, so below is a copy of the e-mail I sent to Simon Poole on the problem I encountered. =============================================================================== I am currently using UniTerm 2.0c 008 The UniTerm Kermit has the following bug in its 8th-Bit Prefixing Algorithm when it is Receiving... Other Kermit UniTerm Kermit Mode: Sending Receiving "S" Packet QBIN field: "&" (Prefix) "Y" (I can Prefix) Thus the two Kermits have agreed to do 8th-Bit Prefixing. During the transfer (about 11K Binary) the following occures... Data in file: 26 B0 (Hex Bytes) Other Kermit Sent: #&&0 (Ascii in "D" Packet) UniTerm Kermit Wrote: 66 26 30 (Hex Bytes) Somehow the UniTerm Kermit is converting (what should be) 2 Bytes of data into 3 Bytes (also UniTerm Kermit failed to set ANY 8th-Bits anywhere in the file it wrote!). It looks to me like UniTerm Kermit does not recognize that it has agreed to do 8th-Bit Prefixing, and has 1) controlified the first "&" even though it isn't a "control character", 2) then saved the "&0" directly without decoding the Prefix. The UniTerm Kermit does correctly perform 8th-Bit Prefixing when it is Sending... UniTerm Kermit Other Kermit Mode: Sending Receiving "S" Packet QBIN field: "Y" (I can Prefix) "&" (Prefix) Thus the two Kermits have again agreed to do 8th-Bit Prefixing. During the transfer (about 11K Binary) the following occures... Data in file: 26 B0 (Hex Bytes) UniTerm Kermit Sent: #&&0 (Ascii in "D" Packet) Other Kermit Wrote: 26 B0 (Hex Bytes) I have verified this Bug both in UniTerm 2.0c 008 and in an old UniTerm 2.0a that I still have available. If it would be any help in debugging this problem, write me and I will send you a UUENCODED copy of the about 11K Binary file I tested it with. R. Tim Coslet Usenet: R_Tim_Coslet@cup.portal.com BIX: r.tim_coslet ------------------------------ Date: 22 Jun 88 12:38:48 GMT From: mcvax!unido!cosmo!hase%cosmo.UUCP@uunet.uu.net (Juergen Seeger) Subject: minix To: info-atari16@score.stanford.edu I'v installed Tanenbaum's MINIX on an Atari ST. Who has programs (f.e.: rs232-support), knowledge, experience and so on? please send to Juergen Seeger ...!unido!uucp!cosmo!hase ------------------------------ End of Info-Atari16 Digest ************************** ------- From: FTP_Manager 29-JUN-1988 07:22 To: POSTMASTER Subj: Network mail failure Unable to return Network Mail to EARN.FINHUTC. Please check your Network Autho Local Mail delivery failed to following Usernames: A_MONK Mail text: Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 9091; Wed, 29 Jun 88 07:21:14 BS Received: by UKACRL (Mailer X1.25) id 9077; Wed, 29 Jun 88 07:21:11 BST Date: Tue, 28 Jun 88 12:41:34 PDT Reply-To: Info-Atari16@EDU.STANFORD.SCORE Sender: "Atari ST users forum (INFO-ATARI16)" Comments: Warning -- original Sender: tag was Info-Atari16-request@Score.Stanford.E From: Info-Atari16 Digest Subject: Info-Atari16 Digest V88 #295 To: ALASDAIR MONK Info-Atari16 Digest Tuesday, June 28, 1988 Volume 88 : Issue 295 This weeks Editor: Bill Westfield Today's Topics: Re: MWC & large arrays -- help! blitter GULAM for german ST's Re: (none) Re: Read Screen Character Re: Renaming folders The archive at lakesys Re: Binaries news group postings Re: The archive at lakesys Re: Midi Mega's Re: Midi File Format Re: MWC & large arrays -- help! ---------------------------------------------------------------------- Date: 22 Jun 88 01:00:44 GMT From: mnetor!utzoo!lsuc!ncrcan!brambo!sid@uunet.uu.net (Sid Van den Heede) Subject: Re: MWC & large arrays -- help! To: info-atari16@score.stanford.edu In article <46700008@hcx2> jgj@hcx2.SSD.HARRIS.COM writes: > >I have experienced this problem too. As far as I can tell, in 3.0, structures >are limited to 32Kb. Also, elements of an array are limited to 32Kb. I thought 3.0 was supposed to fix the problem with big arrays etc. Here I was all excited that they said they fixed the problem and now I'll have to forget about a program I wrote a couple of years ago that tried to use big arrays. Maybe in a year from now when 4.0 comes out?? -- Sid Van den Heede Voice: 416-792-1137 sid@brambo.UUCP FAX: 416-792-1536 ...!uunet!mnetor!utgpu!telly!brambo!sid Bramalea Software, Suite 406, 44 Peel Centre Dr, Brampton, Ontario L6T 4B5 ------------------------------ Date: Wed, 22 Jun 88 16:12:58 PLT From: Bruce Heimbigner Subject: blitter To: Info-a16 Dist List True of False? 1._____ Programs that use tos/gem (primitives?) for graphics will speed up with the blitter on. 2._____ The desk top speeds up with the blitter on. 3._____ Only programs written specifically with the blitter in mind will have any speed up. 4._____ All GEM programs will experience some speed up. 5._____ The new database from Timeworks is the only program currently on the market that uses the blitter. Bye Bruce Heimbigner Email: Snail mail: HEIMBIG@WSUVM1.bitnet N.W. 324 True Street Pullman WA 99163-3347 (USA) ----"It's all very well in practice, but in theory it just doesn't work." ------------------------------ Date: Thu, 23-JUN-1988 14:53 +0200 From: "KARL::FUCHS" To: Info-Atari16@SU-SCORE.STANFORD.EDU Subject: GULAM for german ST's Does anybody know a GULAM adaption for the german ST keyboard? Karl Fuchs ------------------------------ Date: 23 Jun 88 00:42:37 GMT From: mcvax!unido!tub!tmpmbx!netmbx!hase@uunet.uu.net (Hartmut Semken) Subject: Re: (none) To: info-atari16@score.stanford.edu In article <8806140047.AA18091@ucbvax.Berkeley.EDU> U0179@DGOGWDG5.BITNET ("GWDGV1::WHUEBNER") writes: >Two questions about ST hardware: >2) Does anyone know, how far the DMA chip can address in memory ? I once wrote an adress immediatly after the 4 Megabytes to (physbase). The system crashed. The Shifter and DMA chips appear to "borrow" their adress counter from the "MMU" chip; the registers seem to be 12 bit wide (right, Atari?) hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP High on a rocky promontory sat an Electric Monk on a bored horse. (D. Adams) ------------------------------ Date: 21 Jun 88 13:13:06 GMT From: mcvax!ukc!its63b!hwcs!neil@uunet.uu.net (Neil Forsyth) Subject: Re: Read Screen Character To: info-atari16@score.stanford.edu In article <272@scolex> kurth@sco.COM (Kurt Hutchison) writes: >It *IS* possible to get the current cursor location by sending the cursor >save string to the roms and then looking in the documented location for >the saved cursor address. Excuse me bt i have never seen this variable location documented anywhere. Where is it? If it's not an official location just ignore this message. _____________________________________________________________________________ / "I think all right thinking people in this country are sick and tired of \ ! being told that ordinary decent people are fed up in this country with ! ! being sick and tired. I'm certainly not and I'm sick and tired of being ! ! told that I am!" - Monty Python ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh ! ! Scotland ! ------------------------------ Date: 21 Jun 88 14:15:48 GMT From: mcvax!ukc!its63b!hwcs!neil@uunet.uu.net (Neil Forsyth) Subject: Re: Renaming folders To: info-atari16@score.stanford.edu In article <880617-013029-3945@Xerox> "Russell_Stather.SBDERX"@Xerox.COM writes that my renaming a folder would work if I rebooted afterwards. Yes it does work. Thanks to all who wrote and to Allen Pratt for severely chastising me for attempting it in the first place. When a guy has to do this sort of hacking regularly to recover the priceless (?) programs on the students floppy disks one gets in to the habit of solving ones problems this way. _____________________________________________________________________________ / "I think all right thinking people in this country are sick and tired of \ ! being told that ordinary decent people are fed up in this country with ! ! being sick and tired. I'm certainly not and I'm sick and tired of being ! ! told that I am!" - Monty Python ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh ! ! Scotland ! ------------------------------ Date: 21 Jun 88 08:17:47 GMT From: mcvax!ukc!stl!stc!datlog!dlhpedg!cpm@uunet.uu.net (Paul Merriman) Subject: The archive at lakesys To: info-atari16@score.stanford.edu Hi, Can anyone tell me what has happened to the archive of gulam 1.03 at the lakesys archive. I sent a request for it and several other bits and pieces most of which came back ok (much to my surprise and delight !), however All the gulam requests were greeted with a message along the lines of ... File not found in archive .... I was requesting gulam103/part.uaa etc but this was on an old index list so I guess the name may have changed. Has it , or has it been removed from the archive ? I'm currently using a copy of Gulam I got from a PD library (STUK) which declares itself to be Version 0.5 alpha site test, so I assumed I was a bit out of date - is this the case or am I using the most current one after all ? (it certainly seems relatively bug free, but maybe I'm missing some exciting new commands!) Alternatively, if anyone could mail me the up to date version I'd be most grateful. Thanks in advance for any help, Paul. ******************************************************************************** ____ ____ __ __ | | | | \ / | | |____| | \/ | | | | | - "I am not a operating system , |____ | | | I am a free man..." ------------------------------ Date: Thu, 23 Jun 88 17:47 UT+2 From: "MARKS@HDETUD53.bitnet" To: info-atari16@score.stanford.EDU X-VMS-To: @infoatari About three months ago I inquired about the possibilities of using my American 1040ST in Europe on 50 Hz. I received a lot of replies (thanks!) and, while most were encouraging, no one actually said, "Yeah, I've seen it work." One fellow from Atari said basically "It'll work; but to be sure, why don't you just buy some new power supplies," which wasn't the most reassuring thing to hear. In any case, when the machine finally turned up after being lost in the mail, I plugged it into a mongo 220-to-110 V converter and, as everyone expected, it works fine, monochrome monitor and external 2S disk drive included. Beware that I received warnings that the color monitor does NOT work from 50 Hz. If you plan on doing the same thing, you ought to think about getting a trans- former in the US. I was told they exist over here, but (in Holland) I could only find little 25 watt ones. I thought I was going to have to break out the soldering iron and start attaching cables, connectors, and transformers, until someone found the exact item in a storeroom at work. Roger Marks@HDETUD53.bitnet ------------------------------ Date: 23 Jun 88 03:56:28 GMT From: hubcap!ncrcae!ncr-sd!crash!pnet01!sreeb@gatech.edu (Ed Beers) Subject: Re: Binaries news group postings To: info-atari16@score.stanford.edu rthurlow@van-bc.UUCP (Rob Thurlow) writes: > > Well, time for one of my infrequent postings again. I just had a look >at Jwahar Bammi's ZMDM binaries posted to the comp.binaries.st group, and >I'm afraid it didn't make it here in very good shape. The sequence of >events for this stuff is as follows: > >1) The binaries came into the UUCP node I connect to, and got batched > to me as if I were just another UUCP site. The articles get put > in files not much larger than 100K as a rule, with all newsgroups > mixed randomly and the sequence within a group not guaranteed. > This brought to mind a problem I have. Several of the last posting have required a unix shell to decode. I have only limited access to to a unix machine which doesn't seem able to unpack these anyway. Is there a program that allows unpacking these on my ST? Is there a real need to use these rather than just arcing and uuencoding? UUCP: ,cbosgd hplabs!hp-sdd sdcsvax nosc-!crash!pnet01!sreeb ARPA: crash!pnet01!sreeb@nosc.mil INET: sreeb@pnet01.cts.com ------------------------------ Date: 23 Jun 88 12:37:23 GMT From: lakesys!mark@csd1.milw.wisc.edu (Mark Storin) Subject: Re: The archive at lakesys To: info-atari16@score.stanford.edu In article <801@dlhpedg.co.uk> cpm@.co.uk (Paul Merriman) writes: > Can anyone tell me what has happened to the archive of gulam >1.03 at the lakesys archive. ... > I was requesting gulam103/part.uaa etc but this was on an old index > list so I guess the name may have changed. You're right, it's under a newer name, as we have a newer version. Here's an extract from the latest index: gu10304/part.uaa 880609 Gulam shell, docs and example .g files gu10304/part.uab 880609 Gulam shell, docs and example .g files gu10304/part.uac 880609 Gulam shell, docs and example .g files gu10304/part.uad 880609 Gulam shell, docs and example .g files In most cases (if your request syntax is correct), if the file is not found, then the name has been changed to reflect an update. Just request an index again. The indexes are updated about monthly, more often if necessary. It is our intention at lakesys to try to keep the most up-to-date versions of the programs we have that are available. Some authors send us there work directly, other stuff we get from various sources. This will often result in frequent changes in the index. We are sorry if this causes any inconvience, but feel that it is worth it to get the "latest and the greatest" :-). -- Mark A. Storin Lake Systems, Milw., WI UUCP: ,ihnp4,uwvax-!uwmcsd1!lakesys!mark ------------------------------ Date: 22 Jun 88 21:29:15 GMT From: unisoft!gethen!bdt!david@ucbvax.Berkeley.EDU (David Beckemeyer) Subject: Re: Midi Mega's To: info-atari16@score.stanford.edu In article <3160@druhi.ATT.COM> med@druhi.ATT.COM (Myron Drapal) writes: >In article <1073@atari.UUCP>, good@atari.UUCP (Roy Good) writes: >> We are >> concerned, however, that such misinformation would be placed in a public forum >> and accordingly we request that in advance of such statements in the future, >> Atari be called and the facts of such perceived policies be confirmed. > >I just couldn't let this one go without a chuckle ;-)... Atari, the premier >company of vaporware and "misinformation", criticizing someone for the same. > >"Catch the Wave"? Yes, catch the wave and wave bye-bye to Atari... > > Myron Drapal > AT&T Denver > ihnp4!druhi!med You said it loud and clear! When was the last time Atari Corp. ever called any of us before spewing out TOTALLY FALSE statements? And even worse than a "public forum": how about "offical" releases to the press and news conferences?! I remember plainly, as late as 1987 Atari spokesmen were making statements to the press such as "There is no multitasking available for the ST"... almost a year after the release of Micro RTX and MT C-Shell. Oh, and today I got a call from Sig Hartmann at Atari, telling me that I'm "no longer allowed to make negative statements on USENET" and that he "is my sole contact for Atari related communications". Hmm... sounds pretty heavy to me. If anything happens to me, remember you're all witnesses! It would be different if I was giving out proprietary information - but we're talking about non-technical opinions. This is America Jack! -- David Beckemeyer (david@bdt.uucp) | "Yea I've got medicine..." as the Beckemeyer Development Tools | cookie cocks a his Colt, "and if 478 Santa Clara Ave, Oakland, CA 94610 | you don't keep your mouth shut, I'm UUCP: ,unisoft,sun-!hoptoad!bdt!david | gonna give you a big dose of it!" ------------------------------ Date: 23 Jun 88 15:35:08 GMT From: dewey.soe.berkeley.edu!oster@ucbvax.Berkeley.EDU (David Phillip Oster) Subject: Re: Midi File Format To: info-atari16@score.stanford.edu In article <313@accelerator.eng.ohio-state.edu> czei@accelerator.eng.ohio-state.edu (Michael S. Czeiszperger) writes: >sending the different parts back and forth. If I was to post >a SMF sequence, what format would be appropriate? Binhex could be >used but I don't know how many non-mac computers use that format. Use macget -d 1.) on the unix/vms end to accept the data fork, in a MacTerminal 1.1 protocol transmission from the Mac to the host. (this protocol is supported by MacTerminal and VersaTerm.) This puts an exact copy of the Mac MIDI file data on the host, without any mac file system specific header info. 2.) use uuencode on the host end to make the file safe for mail/usenet To recieve: 1.) use uudecode to turn the mail back into a binary data file. Watch out: the encoded form has a filename built in, and if you name your saved mail file the same as that name, your saved mail will get destroyed, but you'll get no data file. 2.) use macput -d to move the file to the macintosh 3.) use ResEdit, disktop, or any other such tool to change the files type to MIDI (4 characters, must be Capital letters.) --- David Phillip Oster --When you asked me to live in sin with you Arpa: oster@dewey.soe.berkeley.edu --I didn't know you meant sloth. Uucp: ,uwvax,decvax,ihnp4-!ucbvax!oster%dewey.soe.berkeley.edu ------------------------------ Date: 22 Jun 88 23:46:06 GMT From: mcvax!philmds!leo@uunet.uu.net (Leo de Wit) Subject: Re: MWC & large arrays -- help! To: info-atari16@score.stanford.edu In article <427@sp7040.UUCP> jsp@sp7040.UUCP (John Peters) writes: > > I have ran into this problem before to. My brother regularly >corresponds with someone that helped with the 3.0 MCW developement. so >here is the reason. The MWC compiler uses signed short offsets from a >stack value for local variables. this means that you have 15 bits or >32K to use as an offset, question answered. This is not true of global >variables. All global variables are long offset from a base address so >the problem does not exist and structures and arrays can be as big as >wanted. Long offsets from a base address? What 68000 instruction do you have in mind?? Probably you mean absolute addresses (with relocation that is). Lets see how we can address memory on the MC68000: 1) (An) contents of the location pointed at by An (n = 0-7) 2) -(An) same as 1) but with predecrement of An 3) (An)+ same as 1) but with postincrement of An 4) w(An) word displacement from An; w is a 16 bit signed offset. 5) b(An,Rx) byte displacement with index; b being a 8 bit signed offset. 6) There are also the PC-relative adressing modes; basically like 4) and 5) 7) Absolute short (16 bit signed) 8) Absolute long (32 bit; of course limited by a 24 bit databus). Your local variables are typically adressed by a(A6), with a being a negative value for local variables, and a positive one for parameters. Static and global data? 1), 2) and 3) kommt nicht in frage, as it would require loading the address register for each different variable. 4) is widely used by various compilers, but means that only 64K can be addressed (GEMDOS initializes some address registers to point to the start of the initialized and uninitialized data spaces; these addresses can be found on the processes' basepage). 5) seems hardly likely, have to waste two registers. Leaves us with 7): only for programs in low memory (or I/O references); not useful for most cases (unless you can enforce this on your program). And 8): Absolute long. Note that the address generated will be a long address relative to the start of the text segment; this becomes relocated when the program gets loaded (GEMDOS does that for you). This is the default that Lattice C uses (but you can have type 4) addressing by a compiler option). Speaking of addressing modes, I would prefer type 4) if the data fits into 64K; the instruction is shorter and also faster than absolute addressing. If the data is over 64K you'll probably have to use absolute addressing (or else you could use something like LEA (An,Dx),Am and then use Am; but this requires an additional overhead). There's also another case in which absolute addressing is almost mandatory: when you make an interrupt routine. When the program that sets up the interrupt vector exits (memory resident), the data base register will be destroyed. In this case I prefer absolute addresses. > Hope this helped. I was taught to not use global variables much but >it seems that they have their place. You can often use static variables instead of global ones; they have a more restricted scope and will be put in the same program segment(s). As for not using global variables, this is a tendency that has come forth from the structured programming gurus; I think that you may use it as a general rule. However, there are very often values/variables in your program that have a program-wide or module-wide scope; it would be both foolish and inefficient to not use that fact. > -- Johnnie -- Leo. ------------------------------ End of Info-Atari16 Digest ************************** -------