🚀 go-pugleaf

   ----- Transcript of session follows -----
550 ALEN@WISDOM.BITNET... User unknown

   ----- Unsent message follows -----
Received: from finhutc.bitnet by wisdom.bitnet; Wed, 25 Mar 87 11:20:30 -0200
Received: by FINHUTC (Mailer X1.23b) id 8966; Wed, 25 Mar 87 11:12:22 FIN
Date:         Tue 24 Mar 87 21:40:06 PST
Reply-To:     Info-Atari16@Score.Stanford.edu
Sender: "Atari ST users forum (INFO-ATARI16)" <INFO-A16@FINHUTC>
Comments:     To: "Distribution List: ;" <INFO-ATARI16>
From: Info-Atari16 Digest <INFO-ATARI16@SCORE.STANFORD.edu>
Subject:      Info-Atari16 Digest V87 #141
To: Alen Goldberg <ALEN@WISDOM.bitnet>

Info-Atari16 Digest   Tuesday, March 24, 1987   Volume 87 : Issue 141

This weeks Editor: Bill Westfield

Today's Topics:

                      Crystal Castles for the ST
                     Re: Ratfor (!) (In C too !!)
                    Re: help! vro_cpyfm, vrt_cpyfm
                         mega-st info please
               Engineering Symbols on Panasonic Printer
                                Rats..
                    Linking ROMable code on the ST
                 Publishing Partner Printing Problems
                      reading from the midi port
                   Re: Small's 410k fast formatter
                   Re: Hacking at Megamax C (query)
                       Thank you for a fine job
                             Ramblins...

----------------------------------------------------------------------

Date: 17 Mar 87 13:57:49 GMT
From: mnetor!utzoo!utgpu!water!watnot!watmath!looking!david@seismo.css.gov
Subject: Crystal Castles for the ST
To: info-atari16@score.stanford.edu

I just bought Crystal Castles for the ST, and wonder of wonders, it
works in MONOCHROME TOO !!!  It looks pretty good in B&W, much better
than I thought it would.

It is VERY close the arcade game, and plays well with the mouse
(you can also play with a joystick)

I wish more companies would take the extra time to get their products
running under monochrome as well as colour...

By the way, it looks good in colour too :-)

Cheers,
David Rowley
Looking Glass Software

------------------------------

Date: 18 Mar 87 18:27:17 GMT
From: mnetor!yetti!oz@seismo.css.gov  (Ozan Yigit)
Subject: Re: Ratfor (!) (In C too !!)
To: info-atari16@score.stanford.edu

In article <1684@trwrb.UUCP> sansom@trwrb.UUCP (Richard Sansom) writes:
>In article <2120@alvin.mcnc.UUCP> ravi@mcnc.UUCP (Ravi Subrahmanyan) writes:
>>    Just in case someone's interested.. I have a version of Ratfor
>>for the ST; it's pretty complete, and works fine (except for I/O in
>>pipes).  Any fortran users out there??  8^)
>
>Sure Ravi (I'm no purist).  How about posting to the sources newsgroup?
>

    I have sent my Ratfor-in-C to mod.sources a couple of days ago.
    It is in C, and includes F77 output, and case-stmt handling.
    I suspect that It will be easy to put it up on an Atari. It
    corresponds very closely to the Software Tools book version.

    enjoy.


    Oz

--
The best way to have a         Usenet: [decvax|ihnp4]!utzoo!yetti!oz
good idea is to have a         Bitnet: oz@[yusol|yuyetti].BITNET
lot of ideas.            Phonet: [416] 736-5053 x 3976

------------------------------

Date: 18 Mar 87 06:44:08 GMT
From: mnetor!utgpu!pete@seismo.css.gov  (Peter Santangeli)
Subject: Re: help! vro_cpyfm, vrt_cpyfm
To: info-atari16@score.stanford.edu


    Hi everybody,
    Just thought I'd clear up the vro_copyform problem.

    vro_cpyform copies a rectangular bitmap from one location to another
based on bit boundaries. (vro_cpyfm is similar, so I will stick with
vro_cpyform). The function looks like this:
    vro_cpyform(handle,wr_mode,pxyarray,psrcMFDB,pdesMFDB);

    "handle" is the VDIHANDLE previously obtained when opening the
application under GEM. (see graf_handle in documentation).

    "wr_mode" is the writing mode under which the transfer will be
performed. example direct transfer of bits, or source bits xor'd into
destination bits.

    "psrcMFDB" and "pdesMFDB" are pointers to "memory form definition
blocks". These are data structures that describe the memory areas being
transferd to or from (more later...).

    "pxyarray" is a standard GEM input array which describes the
offsets and sizes of the rectangles within each memory area described by
the MFDB's that will be transfered.

    An MFDB is a 10 word parameter block consisting of:

(2 words) memory address of block in question. Please note that if this
          0, GEM will fill it in with the address of the current logical
      screen.
(1 word ) block width in points.
(1 word ) block hieght in points.
(1 word ) block width in points/16 (words).
(1 word ) raster format flag. 1 indicates that the block is in a standard
       format suitable for transfering between, say color and b&w, or
      even to IBM PC GEM. 0 indicates that the block is device specific
      (0 is usually used).
(1 word ) number of planes of color. (1 for mono).
(3 words) reserved, make them 0.

    While I have never had to do memory to memory raster copies, I often
do memory to screen and the inverse, with no problem. Unless GEM is much more
brain damaged than anyone imagined, there should be no problem with memory to
memory.

                        Pete Santangeli
                        pete@utgpu
                             -----
                               ^
                               \__ new address!!

------------------------------

Date: 19 Mar 87 03:38:15 GMT
From: renoir.Berkeley.EDU!john@ucbvax.Berkeley.EDU  (John Coker)
Subject: mega-st info please
To: info-atari16@score.stanford.edu

I've been hearing people refer to the ``new'' (future) version of the
st as a ``mega-st''.  I'd like to know just how this machine is better
than the current 1024 st, when it's going to come out and how much it's
going to cost (if anyone knows).

I've heard (or thought I heard):

    -   more bits on the screen

    -   blitter (or more display chips?)

    -   faster and/or more memory standard

    -   680[12]0 upgrades

    -   arithmetic coprocessor

Are any/all of these true?  When can we expect the machine?  In what
price range will it be?  The system which looks attractive at the
moment is the 1024 st; I'm interested in where the mega-st improves
on the 1024.

Will this machine really be an improvement on the st; is it a sliglty
better replacement for the st or a larger machine?  More bits on the
screen would be a wonderful improvement--especially if the physical
monitor got larger also.  (BTW, is there any way to get more pixels
with the current st and another monitor?)

If this information is general knowlege, please just respond to me.
Otherwise, others may also be interested.  If the thing (or marketing
propaganda) is already at stores in Berkeley, please tell me where.

------------------------------

Date: 18 Mar 87 18:23:19 GMT
From: ihnp4!mhuxu!cbz@ucbvax.Berkeley.EDU  (Craig B. Ziemer)
Subject: Engineering Symbols on Panasonic Printer
To: info-atari16@score.stanford.edu

  I have finally gotten around to writing a "print filter" which
allows my Panasonic KX-P1080 printer to print engineering (read
Greek) symbols through my Habawriter wordprocessor software.  If
anyone wants a copy of the filter file let me know.  If you don't
have the Habawriter wordprocessor you can still use these codes
to download the special symbols to your Panasonic printer.
  The characters I have developed codes for are: big and little
sigma, mew, tau, infinity, alpha, pi, omega, beta, gamma, epsilon,
lamda, delta, angstroms, theta, phe, phi, pho and phum. (:^)

Craig Ziemer at AT&T-BL
mhuxu!cbz

------------------------------

Date: 19 Mar 87 03:19:03 GMT
From: ucsdhub!hp-sdd!ncr-sd!ncrcae!ece-csc!mcnc!ravi@sdcsvax.ucsd.edu  (Ravi
 Subrahmanyan)
Subject: Rats..
To: info-atari16@score.stanford.edu

[]

    I have a clarification to make re. my earlier posting about
the availability of Ratfor.

    Ratfor is >not< a compiled language.

    Ratfor is a preprocessor that converts Ratfor code to regular fortran
(rather unpleasant fortran, but the good part is you don't have to
look at it)  which must then be compiled by a standard fortran compiler
(eg. the Absoft compiler).

    Sorry if I gave the impression that it included a compiler,

                                -ravi

------------------------------

Date: 18 Mar 87 13:53:04 GMT
From: mcvax!ukc!warwick!daffy@seismo.css.gov  (Steve Hunt)
Subject: Linking ROMable code on the ST
To: info-atari16@score.stanford.edu

Hi ST-folk,

    I'm attempting to link a program that resides partly in ROM
and partly in RAM.  It won't be run on an ST, I'm just using the ST
to develop and link the program.

    The program is divided into two modules, let us call them
"one" and "two."  The code in module "one" is to reside in RAM at
address $4000.  The code in module "two" is to reside in ROM at
address $80000.  The data from both sections will reside in RAM at
$1000 up.

    Now, the question is this: how can I go about linking the beast?
I've got the Developer's Kit but LINK68 and LO68 don't seem to provide
facilities for doing this sort of thing.  Of course, the two sections
need to know about each other's symbols.  So I can't get away with linking
the two parts separately.

    BTW, I tried welding the two assembler files together with appropriate
ORG directives to $4000 and $80000, but to my dismay the assembler took
about 20 minutes to produce a HUGE object file with... guess what...
$79000 nulls up front....

    Ideally I'd like to link the modules in order to satisfy the references
between them, but end up with 2 object files (preferably in S-record format)
which I can then load into the appropriate places in store.

    Any help much appreciated!

Thanks in advance,

                Steve Hunt.

--
"University computer centers are notorious for being run by
 empty-headed bozos."       -- Henry Spencer.

Steve Hunt, DONALD Programmer 1st Class
Mail: daffy@warwick.UUCP   sahunt@warwick.UUCP    daffy@uk.ac.warwick.ubu
Home: "The Silo", 15 Molesworth Avenue, Stoke Green, Coventry CV3 1BU, UK
Tel:  0203 447765

------------------------------

Date: 19 Mar 87 04:08:52 GMT
From: jade!eris!cathy@ucbvax.Berkeley.EDU
Subject: Publishing Partner Printing Problems
To: info-atari16@score.stanford.edu


Some Publishing Partner files I've created on a 1040 print fine
on an Apple Laser Writer, but others give a Postscript errors
and refuse to print.  I have not noticed any similarities in the
files that don't print (yet).

Anyone experienced the same problem?  (I am using version 1.01)

Thanks,

Cathy

------------------------------

Date: 18 Mar 87 16:30:10 GMT
From: decvax!cca!m204help@ucbvax.Berkeley.EDU  (Keith Hedger)
Subject: reading from the midi port
To: info-atari16@score.stanford.edu

I am trying to read data from the midi in port on the 520 ST  and
am having a problem. My program is written in MEGAMAX C and basically
grabs midi data a byte at a time and stuffs it into an array...when the
array reaches a length of 78 it is displayed on the screen and a new
string starts getting written. My problem is that I hook up a sequencer
to my ST and start it putting out midi data and start running my program.
My program always displays 4 or 5 lines of midi data then exits the program.
(In other words the sequencer is still running). If I stop the sequencer
and run the program again, it typically puts out another 4 or 5 lines of
midi data then stops. I run it again and the port is clear.
My program is basically built with a big 'while' loop which says
'while data is at the midi in port do blah blah blah'.
I have seen some messages from the 'bix' section of Byte where people
were saying that they had had the same kind of problem, and that the
buffer that handles incoming midi data is too small....they allocated
their own buffer large enough to handle the data.
My question is: If the buffer is filling, why would having my program
read from it and stuff the data into a bigger buffer, work any better
than reading data from it and putting it into strings to be output ?
Is putting the data in strings to be output that much slower than moving
the data into an internal buffer ????
I would appreciate any suggestions any of you MIDI hackers out there can
give me.
thanx,
keith hedger

------------------------------

Date: 17 Mar 87 20:08:00 GMT
From: ihnp4!inuxc!iuvax!franco@ucbvax.Berkeley.EDU
Subject: Re: Small's 410k fast formatter
To: info-atari16@score.stanford.edu

There is one more thing that must be done to David Small's 400k fast
formatter (START - latest issue) in order to make it useful.  The executable
given in START always sets the disk serial number to 0.  This is interesting
because, according to the source code, the executable should set the disk
serial number to a random number.   I suppose the executable provided in
START was a preliminary version.  Small probably realized there was a
problem and changed the sources, but neglected to send the updated
executables to START.  All is not lost, however.  In sector 3 there is the
HEX string FFFFFFFF.  Simply change it to HEX 0FFFFFFF to get random
serial numbers.

------------------------------

Date: 18 Mar 87 04:51:08 GMT
From: ihnp4!alberta!sask!long@ucbvax.Berkeley.EDU  (Warren Long)
Subject: Re: Hacking at Megamax C (query)
To: info-atari16@score.stanford.edu

In article <425@batcomputer.tn.cornell.edu>, braner@batcomputer.tn.cornell.edu
(braner) writes:
> Also: has anybody made an alternative printf/scanf that skips the FP stuff
> (to make it smaller). Has anybody bought the Megamax library source code
> (offered for $50)? Is it worth it?
>
> These sorts of optimizations-by-the-users have been done on the DRI/Alcyon
> compiler.  Why not for Megamax?
>
> - Moshe Braner
>
> PS: does anybody know whether the Megamax Resource Construction program
> will work with OSS Personal Pascal?  Is the .RSC file format standard?
> How would you get the Pascal .I file?  Is it easy to translate the C .h
> file to the .I form?

The resource files are all the exact same format.  However, if you load
a RSC file into the editor without the extra info files, you will have
to add in all the names and types of dialog boxes yourself.  Then when
saving it, it will create a new file.  (the info file is .DEF for
Megamax Resource construction set and .DFN for the developer's kit).
It makes it awkward to switch from one to the other, but at least you
don't have to start from scratch.

Back to the topic at hand...  Has Megamax changed the 32K code limit
yet???  My program is pushing that limit (31986 or something), and I
have lost any desire to add new features, so I don't go over the edge.

Warren

--
=-=-=-=-=-Warren Long at University of Saskatchewan, Canada-=-=-=-=-
Home: 78 Carleton Dr.,Saskatoon, Sasakatchewan, S7H 3N6
Phone: (306)-955-1237
=-=-=-=-=-U-Email: ...!ihnp4!alberta!sask!long     -=-=-=-=-=-=-=-=-

------------------------------

Date: 19 Mar 87 10:59:51 PST (Thursday)
From: Bicer.ES@Xerox.COM
Subject: Thank you for a fine job
To: ihnp4!inuxc!iuvax!franco@ucbvax.Berkeley.EDU

----------------------------------
Over 200 copies of different versions of the STarter Kit were mailed out and
many of these were duplicated and redistributed.  The operation went very
smoothly - nearly everyone followed instructions to a T and sent the correct
----------------------------------

Thank you for taking the time and trouble to make so many people
very happy.

    Jack Bicer

------------------------------

Date:     Wed, 18 Mar 87  22:01:43 EST
From:     Flash%UMASS.BITNET@wiscvm.wisc.edu
Subject:  Ramblins...
To:       Info-Atari16@SU-SCORE.ARPA

Peter Santangeli writes:

>    These guys are either BLIND or just plain aren't willing to spend the
>time to find the problem. Frankly, I am EXTREMELY PISSED OFF. I spent over
>$2000 on atari equipment. Yah, the software isn't great, I can live with that.
>I CAN'T LIVE WITH RUDE AND INEFFECTIVE SERVICE.

Peter,

   Maybe you want to take a road trip down to Amherst, Mass? I run an
Atari ST Sales and Service center, and our technician is a master at
hardware. We could run right through it and solve it all. I know it
is kind of sad, but Atari's requirement to have a "real" tech has
degraded to soup. Our local competition has some high school kid who
is never in and does nothing. Atari's official word is "So what? Until
someone complains by official channels.." Soooo, we are now making
money by fixing the computers for our competition. (As long as it is
out of warranty...)
   But we can probably figure it out, if not, search for another
dealer, I believe that even in Toronto there should be several honest
and capable dealers available.

On other stuff. Mail order places.

S&S took three weeks to deliver something for me that they claimed
would be shipped the next day UPS BLUE! And they still send it UPS
BLUE three weeks later. But by that time I got it from somewhere
else, and I refused it. (heh heh)

CMO (Computer Mail Order) seems to be pretty good and honest. I got
a printer from them. FAST. They are pretty good on whether something
is in stock or not. "We have 2 in stock..." And they ship fast.

Then of course, there is always your dealer. Find a good one who
discounts, and then you wont have to sweat it while waiting for an
UPS truck.

Rick Flashman

1040 N. Pleasant Street, #381, Amherst, MA  01002. (413) 549-0173
Flash@UMASS.BITNET   -or-    Flash%UMASS.BITNET@WISCVM.WISC.EDU
                   R-FLASHMAN on GEnie

------------------------------

End of Info-Atari16 Digest
**************************
-------