🚀 go-pugleaf

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

   ----- Unsent message follows -----
Received: from finhutc.bitnet by wisdom.bitnet; Tue, 24 Mar 87 10:54:28 -0200
Received: by FINHUTC (Mailer X1.23b) id 3509; Tue, 24 Mar 87 10:45:28 FIN
Date:         Mon 23 Mar 87 22:22:31 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 #139
To: Alen Goldberg <ALEN@WISDOM.bitnet>

Info-Atari16 Digest   Monday, March 23, 1987   Volume 87 : Issue 139

This weeks Editor: Bill Westfield

Today's Topics:

                    Re: Vertical Blank Interrupts
                  Re: Batteries Included bought out.
                            Re: Ratfor (!)
                            PD RSC editor?
                           UW status report
            Re: 68020 Box, laser printer, Eastern Pa. Expo
                   Re: Info-Atari16 Digest V87 #129
                           video converter
        Re: News from Hannover Messe (really HHG and DEV Kit)
            Re: 68020 Box, laser printer, Eastern Pa. Expo

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

Date: 17 Mar 87 22:30:00 GMT
From: dayton!viper!john@RUTGERS.EDU  (John Stanley)
Subject: Re: Vertical Blank Interrupts
To: info-atari16@score.stanford.edu

In article <741@eneevax.UUCP> iarocci@eneevax.UUCP (Bill Dorsey) writes:
 >I've been doing a lot of work involving use of the vertical blank interrupts
 >recently, and have noticed certain annoying behaviors.  I'd appreciate com-
 >ments or suggestions related to either of the following:
 >
 > [_description of details deleted_]
 >
 >The other question I have regarding VBIs is this:  I want to use a VBI to
 >monitor some event, and then after that event occurs, temporarily suspend the
 >current process and execute some code that takes a bit of time.
 Unfortunately,
 >every time I do this, the system crashes very quickly.  Bios calls are sup-
 >posed to be re-entrant to only three levels, and my code does make a Bios
 >call in the interrupt section, so I thought maybe this was the problem.
 >
Well, they are supposed to be re-enterant, but it doesn't work right for
bios calls from within an interrupt routine.

  I had lots of fun tracking this roblem in a program I wrote which also
tried to make bios/xbios/gem calls from within an interrupt...  I tracked
the problem for 4 days thru the bios ROMS.  This is one of the problems
I hope they fix in the new ROMs.  (Note to Atari:  If you guys haven't
come up with a solution for this, contact me....)

  There is a bug in how trap 13 and trap 14 (bios and xbios) are handled.
As you pointed out in your message, there is an area used to save registers
while processing a trap call.  The code that does the save and restore was
written (aparently) by someone with little or no experience dealing with
an interrupt driven system.

  The code in question consists of 10-20 lines of assembly.  Since the
interrupts are not disabled and the code is not written in a way that
would allow interrupts to occur without causing problems, you eventualy
end up with a VBI or some other interrupt occuring in the middle of this
save or restore code.  If you then try to make a call to the bios (or to
any GEM function which uses the bios) the registers saved for your call
overwrite some (randomly 0-15 of them) of the registers saved for the
call being made at the time of the interrupt.  When your interrupt call
returns, the save/restore register bios routine finishes it's job and
the system continues on with no knowledge that the registers saved are
incorrect.  When it trys to return to the function that called the bios
in the 1st place, the incorrect registers are "restored" causing lots of
problems all over the place depending on the program being run...

  One other possibility is that the bios calls you were making took too
much time to return.  There are a few places in the VBI code I doubt will
work very well if you call them a second time before they return from a
previous interrupt...

  Hope this explains the problems you (and I) have been having.  As a
general rule, "Don't make any BIOS/XBIOS/GEM calls from an interrupt
routine.".  There's almost allways a way to get things done without
using them (Note: I said "ALMOST".)  So far, I've been able to use
several tricks to get things done when I need to.  Hope you can too..

 >.......  Anybody got any suggestions,
 >or will I have to write a multi-tasking kernel just to monitor an i/o port?
 >Sure seems like overkill!

Sure would be.  Since Beckemeyer has already done just that, perhaps
you would want to try using his multitasking system before you go to
all the trouble of writing your own...

---
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john

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

Date: 16 Mar 87 08:47:39 GMT
From: mnetor!utzoo!utgpu!water!watnot!watrose!jafischer@seismo.css.gov
Subject: Re: Batteries Included bought out.
To: info-atari16@score.stanford.edu

>> In any case, if I am wrong and EA did buy BI, then EA would be pretty
>> dumb if they didn't keep distributing Tom's programs -- they certainly
>> made quite a bit of money for BI!
>>
>  Electronic Arts did in fact just buy Batteries Included.
>  NO word yet on what this means for us Atari owners.

    The word from Bruce @ Atari Canada is that EA will be supporting
current BI products (e.g., Degas, Isgur Portfolio, etc.), and dropping
products that were still under development (e.g., PaperClip Elite).
Can somebody correct this?  I'm hoping that Bruce (Atari rep) is just
trying to drop some bad hints about products in competition with MS Write.
Not that Bruce is necessarily that kind of guy, I don't really know him.
--
        - Jonathan Fischer   (jafischer@watrose.UUCP)
            or ...watmath!watrose!jafischer

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

Date: 17 Mar 87 16:21:15 GMT
From: trwrb!sansom@ucbvax.Berkeley.EDU  (Richard Sansom)
Subject: Re: Ratfor (!)
To: info-atari16@score.stanford.edu

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?

-Rich



--
  //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
 /// Richard E. Sansom                    TRW Electronics & Defense Sector \\\
 \\\ {decvax,ucbvax,ihnp4}!trwrb!sansom   Redondo Beach, CA                ///

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

Date: 17 Mar 87 19:52:42 GMT
From: mcvax!ukc!its63b!csan@seismo.css.gov  (Andie)
Subject: PD RSC editor?
To: info-atari16@score.stanford.edu

[************************There aint no such thing as the linea...

Dear Netland,

Does anyone know of a *cheap* (even better,PD) RSC editor that I can get my
hands on ? I am getting pretty frustrated not being able to write friendly
prg's without RSCs . I am also on the scrounge for any ACCSTART libraries
that are going around (suitable for Lattice C,Mod2 and useable from my
M68000 assembler)

Thanks (as they say) in advance.

Andie
        Department of Computer Science
        EDINBURGH University.

        ARPA : csan%ed.its63b@ucl-cs.arpa
        UUCP : ...!seismo!mcvax!ukc!its63b!csan
        JANET: csan@uk.ac.ed.its63b

% These are my own views and any resemblance to any coherent reasoning is
% probably a typo.
%
%  "The back row strikes again!"

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

Date: 17 Mar 87 23:52:02 GMT
From: mnetor!utgpu!pete@seismo.css.gov  (Peter Santangeli)
Subject: UW status report
To: info-atari16@score.stanford.edu


    Hi everybody,
    Due to popular demand this is a status report on UW:

    My UW is still in the writing stages. I am trying to sort out a
couple of wierdities of the M2 compiler. (large library module hangs compiler
when it gets to declaration pass).
    I have heard that there is a version of UW available from Norway (?).
It is apparently a fairly simple implementation. My implementation will be
COMPLETE (with extensions over MAC) when finished, but if people are in a hurry,
perhaps someone can post it. (I would be interested).
    Source to my version will be sent to the moderated group, WHEN COMPLETE!and
 obviously the binary will be posted as well. I am still waiting for my
version 3 M2 compiler (I have version 1, non-developers) So I still don't have
a resource compiler, which will obviously slow development down a bit. I am
planning on implementing a form of "download" window for the system, so you
can download and read news at the same time :-). I am also considering a D/A
version, though that will have to wait a while (start work on it at the end
of the summer?).
    Anyways, to all those who have expressed interest in the project, many
thanks. Your encouragement it greatly appreciated.

                        Thanks,
                        Pete Santangeli
                        pete@utgpu
                        psantangeli on BIX

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

Date: 18 Mar 87 01:52:31 GMT
From: cbatt!osu-eddie!osupyr!akw@ucbvax.Berkeley.EDU  (FarOff MicroDesigns)
Subject: Re: 68020 Box, laser printer, Eastern Pa. Expo
To: info-atari16@score.stanford.edu

In article <10162@topaz.RUTGERS.EDU> appelbau@topaz.RUTGERS.EDU (Marc L.
 Appelbaum) writes:
>[..]
>print up to 300 X 300 DPI.  In order to layout a full page at 300 X
>300, you'll need about 4 megs.  This is because the LaserPrinter has
>no memory of it's own.  It uses the ST to do all the work.  When we
>asked the ATARI rep. at the seminar (I forget his name), about memory
>upgrades he said ATARI does CONDONE upgrades from 3rd party companies.
>
This is (or I think is) *slightly* incorrect.  An Apple LaserWriter does not
have 4Mb of RAM, nor does a stock Mac Plus.  The Mac (and hopefully the Atari
laser printer) takes PostScript input, which is an object and line-oriented
printer graphics language.  It doesn't require a complete bit-map of what-
ever you want to print out.  This saves the hassle (and slow speed) of
trying to bit-map an 8 1/2 x 11 page w/ 300x300 dpi in RAM instead of doing
it by objects.   *Hopefully* this will be an option on the Atari printer
so that programs that produce PostScript output (i.e. Publishing Partner,
Graphic Artist, etc.)  A bitmap is too inefficient, expensive (at this
time) and *slow*.  I hope that Atari will consider the PostScript or
QMS language for its printer.  Sheez!  Even IBM is going to use PostScript
on its laser according to what I've heard!

>I saw a BLITTER in action!

For goodness' sake HOW WAS IT?  And when can we see one in our local
Atari dealership (OK Atari...enough Real Soon Now's and some concrete
dates...like Summer '87, Autumn '87...but a _real_ date.)

Andy Weaver / akw@osupyr.UUCP / 614.293.1195  - 614.292.1741 / ========> IX0YE
The Ohio State University / Columbus, OH / "Go Bucks." / Peanut Butter & Jelly
"Like cold water to the bones, so is good news from a distant land." Prov25.25

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

Date: Wed, 18 Mar 87 10:05:14 est
From: Ashwin Ram <ram-ashwin@YALE.ARPA>
Subject: Re: Info-Atari16 Digest V87 #129
To: Info-Atari16 Digest <Info-Atari16@Score.Stanford.EDU>
In-Reply-To: Info-Atari16 Digest <Info-Atari16@Score.Stanford.EDU>, Tue 17 Mar
 87 13:51:00 PST

>   Date: 12 Mar 87 23:03:12 GMT
>   From: decvax!mcnc!duke!hsg@ucbvax.Berkeley.EDU  (Henry Greenside)
>   Subject: Scientific word processing on Atari ST machines
>   To: info-atari16@score.stanford.edu
>
>   Can anyone recommend scientific word processing programs or desk
>   accessories for the ST class Atari machines? On the Macintosh,
>   there are numerous mathematics fonts (Princeton and Symbol), and
>   a desk accessory called MacEqn that grealy simplifies the construction
>   in object form of mathematical equations. These can then be pasted into
>   any desired word processor. Is there anything like that in the Atari
>   world?

If you collect any info about this, could you forward it to me please?  I'd
like to be able to do this kind of stuff too.

>   Also, has TeX been ported to the Atari machines? In particular, are there
>   previewers for the ST's? Thanks.

Yup... here's a message I saved a few months ago.

**** Forwarded Message Follows ****
Date: 15 Oct 86 18:54:00 GMT
From: cbatt!cwruecmp!pjd@ucbvax.Berkeley.EDU  (dr. funk)
Subject: ST-TeX from Tools Gmbh
To: info-atari16@score.stanford.edu

Product: ST-TeX
Vendor:  Tools Gmbh
     Kaiserstrasse 48
     5300 Bonn 1
Phone:   0228/229791
Price:   $150 ($5 shipping)

This is TeX, Version 1.5 for the ST [0.9x] (no format preloaded)

.... and they aren't kidding. We just received a preliminary version
of ST-TeX which is being prepared for the American (English speaking)
ST market by Tools Gmbh. It arrived on six double sided floppies
consisting of TeX itself, a DVI GEM-based previewer, TFM files,
font files, LaTeX format and style files, and IniTeX.

We took two LaTeX files, a mathematical screed on timed Petri nets
and a pictorial introduction to digital system synthesis, and ran
both through without problems or modification. Speed with a hard
disk is roughly equivalent to LaTeX on a 780. If you are split
across two or more machines (and most of us here use an ST, VAX
and/or Apollo daily) you might want to standardize your format and
style files as I've noticed subtle differences such as bold
for description items on the ST and italics on the VAX.

The previewer is wonderful. The scroll bars slide the window around
a page so you can examine every nook and cranny. It is faster than
the Apollo previewer from Yale. Currently, FX-85 Epson compatible
printers are supported. The printed output is great given the 9-pin
head. Make sure you have a big print buffer though -- our standard
buffer size Panasonic 1092 truncates each line. Buffer expansion
options are now on order. Print time is about 6-8 minutes per page.

Tools Gmbh emphasizes that this version is preliminary and that a
newer version will be available near the end of the month. There are
a few problems:
  1. The version received needs a full 1 Mbyte of RAM. If you own a
     520, it's time to upgrade.
  2. Directory searching is not fully implemented. Hence, you need
     to drop a hint to the previewer as to the location of the
     screen or printer files, TEX.TOS must reside in the same
     directory as the TeX input and format files, etc.
  3. There are so many files that a single DSDD drive system may
     not cut it. A hard disk is strongly recommended.

Tools Gmbh is currently looking for a USA distributer. Since we're
nice guys in a hurry, we convinced Tools Gmbh to sell us a copy.
They do NOT encourage direct sales right now. (We had to draw an
international bank draft and Federal Express'd the order -- I said
we were in a hurry.)

This product is strongly recommended.

--

paul drongowski                         decvax!cwruecmp!pjd
case western reserve university         pjd%Case@CSNet-relay

**** End of Forwarded Message ****

-- Ashwin Ram.

ARPA:    Ram-Ashwin@yale
UUCP:    {decvax,linus,seismo}!yale!Ram-Ashwin
BITNET:  Ram@yalecs

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

Posted-From: The MITRE Corp., Bedford, MA
To: info-atari16@su-score.ARPA
Subject: video converter
Date: Wed, 18 Mar 87 10:32:25 EST
From: jhs@mitre-bedford.ARPA

John Ogawa and others interested in seeing VCR and TV tuner pictures on their
Atari monitor should write to

        John A. Hain, Jr.
        Director of Engineering
        ProTronics Laboratories
        2913 Azalea Road, S.W.
        Huntsville, AL 35805

and ask Mr. Hain when the ProTronics video converter will be available.
I have been trying to persuade John to bring this product to market for
several months, but has had many other projects in the commercial broadcast
video area making demands on his time.  If he is deluged with requests for
such a converter, it could be available in a few months.  If you'd like a
high-quality Atari RGB to NTSC Composite video converter for under $100,
write to the above address and say so!!!

-John Sangster / jhs@mitre-bedford.arpa

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

Date: 16 Mar 87 16:07:36 GMT
From: tikal!hplsla!hpvcla!ericr@BEAVER.CS.WASHINGTON.EDU  (Eric Ross)
Subject: Re: News from Hannover Messe (really HHG and DEV Kit)
To: info-atari16@score.stanford.edu

With their experience on all the multitude of IBM clones at varying
clock speeds, I would hope that Flight Simulator will keep track of
real time and produce as many refreshes as possible within the
real-time quantum.  Therefore, the blitter should in theory just
cause more refreshes, but not more airplane motion in a given
second.  Incidentally, my Cessna on my HP-Vectra(AT clone
at 8 Mhz) runs at the same speed as on an IBM-PC at 4.5? Mhz with
many more refreshes/second.


Eric Ross
Hewlett Packard, Vancouver, WA (Home of the Thinkjet and Quietjet printers)

UUCP:   ihnp4!hpfcla!hpvcla!ericr
CIS:    72347,2664
GEnie:  E.ROSS
Phone:  (206)254-8110

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

Date: 18 Mar 87 15:24:02 GMT
From: appelbau@topaz.rutgers.edu  (Marc L. Appelbaum)
Subject: Re: 68020 Box, laser printer, Eastern Pa. Expo
To: info-atari16@score.stanford.edu

In article <110@osupyr.UUCP>, akw@osupyr.UUCP (FarOff MicroDesigns) writes:
> In article <10162@topaz.RUTGERS.EDU> appelbau@topaz.RUTGERS.EDU (Marc L.
 Appelbaum) writes:
> >[..]
> >print up to 300 X 300 DPI.  In order to layout a full page at 300 X
> >300, you'll need about 4 megs.

> This is (or I think is) *slightly* incorrect.  An Apple LaserWriter does not
> have 4Mb of RAM, nor does a stock Mac Plus.
>
> >I saw a BLITTER in action!
>
> For goodness' sake HOW WAS IT?  And when can we see one in our local
> Atari dealership (OK Atari...enough Real Soon Now's and some concrete
> dates...like Summer '87, Autumn '87...but a _real_ date.)
>

The figures I recieved as to the amount of memory it takes for the
laser printer came right from the horse's mouth.  One of the members
of the Atari engineering staff gave me the figure of 4 megs.

As for the blitter, we saw it running a graphic demo.  I would say it
was at least 3-4 times faster than the normal ST.

Also accoriding to Mark Jensen the new ROMs will fix some TOS bugs, he
also said they are working on a fix for the 40 folder limit.

Release dates for the Laser Printer, MEGA's and blitter were said to
be around late summer '87.
--
 Marc L. Appelbaum                 "If life is a game of chess
 Arpa:appelbau@topaz.rutgers.edu                 and you and I are pawns
 Uucp:rutgers!topaz!appelbau                     what happens when we get to
 GEnie: M.APPELBAUM                         the other side of the board?"

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

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