Article View: comp.sys.atari.st
Article #33086(none)
From: ADVISORY
Date: Wed, 29 Jun 1988 11:37
Date: Wed, 29 Jun 1988 11:37
2300 lines
95927 bytes
95927 bytes
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)" <INFO-A16@EARN.FINHUTC>
Comments: Warning -- original Sender: tag was
Info-Atari16-request@Score.Stanford.E
From: Info-Atari16 Digest <Info-Atari16@EDU.STANFORD.SCORE>
Subject: Info-Atari16 Digest V88 #292
To: ALASDAIR MONK <A_MONK@UK.AC.OPEN.ACS.VAX>
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)" <INFO-A16@EARN.FINHUTC>
Comments: Warning -- original Sender: tag was
Info-Atari16-request@Score.Stanford.E
From: Info-Atari16 Digest <Info-Atari16@EDU.STANFORD.SCORE>
Subject: Info-Atari16 Digest V88 #291
To: ALASDAIR MONK <A_MONK@UK.AC.OPEN.ACS.VAX>
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 <rling@june.cs.washington.edu>
------------------------------
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 <rling@june.cs.washington.edu>
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)" <INFO-A16@EARN.FINHUTC>
Comments: Warning -- original Sender: tag was
Info-Atari16-request@Score.Stanford.E
From: Info-Atari16 Digest <Info-Atari16@EDU.STANFORD.SCORE>
Subject: Info-Atari16 Digest V88 #293
To: ALASDAIR MONK <A_MONK@UK.AC.OPEN.ACS.VAX>
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 <portab.h>
#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" <U0179%DGOGWDG5.BITNET@Forsythe.Stanford.EDU>
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)" <INFO-A16@EARN.FINHUTC>
Comments: Warning -- original Sender: tag was
Info-Atari16-request@Score.Stanford.E
From: Info-Atari16 Digest <Info-Atari16@EDU.STANFORD.SCORE>
Subject: Info-Atari16 Digest V88 #294
To: ALASDAIR MONK <A_MONK@UK.AC.OPEN.ACS.VAX>
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: <Jack_Mason%CSC03.CEO.DG.COM@adam.DG.COM>
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)" <INFO-A16@EARN.FINHUTC>
Comments: Warning -- original Sender: tag was
Info-Atari16-request@Score.Stanford.E
From: Info-Atari16 Digest <Info-Atari16@EDU.STANFORD.SCORE>
Subject: Info-Atari16 Digest V88 #295
To: ALASDAIR MONK <A_MONK@UK.AC.OPEN.ACS.VAX>
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 <HEIMBIG%WSUVM1.BITNET@Forsythe.Stanford.EDU>
Subject: blitter
To: Info-a16 Dist List <info-atari16@Score.Stanford.edu>
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" <U0094%DGOGWDG5.BITNET@Forsythe.Stanford.EDU>
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" <MARKS%HDETUD53.BITNET@CUNYVM.CUNY.EDU>
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, <fill in today's
title here> 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
**************************
-------
Technical Details
Message-ID:
<8807020004.AA08844@ucbvax.Berkeley.EDU>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!husc6!uwvax!oddjob!ncar!ames!mailrus!purdue!decwrl!hplabs!ucbvax!VAX.ACS.OPEN.AC.UK!ADVISORYShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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