🚀 go-pugleaf

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

   ----- Unsent message follows -----
Received: from finhutc.bitnet by wisdom.bitnet; Thu, 26 Mar 87 15:01:50 -0200
Received: by FINHUTC (Mailer X1.23b) id 5248; Thu, 26 Mar 87 13:41:19 FIN
Date:         Wed 25 Mar 87 21:35:37 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 #142
To: Alen Goldberg <ALEN@WISDOM.bitnet>

Info-Atari16 Digest   Wednesday, March 25, 1987   Volume 87 : Issue 142

This weeks Editor: Bill Westfield

Today's Topics:

                                 icon
                            RE: 68000 box
                     Re: Ratfor (!) (In C too !!)
                    Re: reading from the midi port
         Atari ST system and related items for sale (revised)
                   Publishing Partner memory usage
                    Re: Help! vro_cpyfm,vrt_cpyfm
                1st posting to comp.binaries.atari.st
            Re: 68020 Box, laser printer, Eastern Pa. Expo
                          Re: laser printer
                        The New 8-Bit Emulator

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

Date: Thu, 19 Mar 87 22:20:44 EST
From: Michael DeCorte <l40a%CLUTX.BITNET@wiscvm.wisc.edu>
To: INFO-ATARI16@SU-SCORE.ARPA
Subject: icon

I have the icon programming language for the st.  Icon has
nothing to do with the icon's used by the st, it is a high
level language that implements back-tracking.

Anyone who wants it email me.

michael decorte
l40a@clutx.bitnet

p.s. please include your bitnet or arpa address. I don't have
access to UUCP.

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

Date: Thu, 19 Mar 87 22:39:37 EST
From: Michael DeCorte <l40a%CLUTX.BITNET@wiscvm.wisc.edu>
To: INFO-ATARI16@SU-SCORE.ARPA
Subject: RE: 68000 box

There have been several comments on the net lately about
adding this or that to the unix box that atari is planning.
While all of the additions that I have seen are very
interesting I can not support them.

The 68000 box as I understand is supposed to be a cheap, fast
unix box that plugs into the back of the ST.  The proposed
additions contradict this purpose.  Each addition adds to the
cost of the machine and it will delay it's release.  I don't
think anyone wants to have to pay more and wait longer for
unix on the ST.

If a multi-user box is desired then one possible solution
would be to create (perhaps by third party) a box with
a bunch of rs-232 ports in it.  The rs-232 box could
be just another thing on the dma-bus.  This has the advantage
that it would be useful even without the unix box and to
make the unix box work with the rs-232 box should involve a
DRIVER change not a HARDWARE change.  Of course this
would cost more than if the unix box had rs-232 ports but
not everyone want's a multi-user machine.  This
was just something that came to me and I have not
really thought it out, so it may to be even be possible but
the point is there are other ways to add power other than
make one really powerfull box.

michael decorte
l40a@clutx.bitnet

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

Date: 20 Mar 87 00:16:25 GMT
From: mcnc!ravi@seismo.css.gov  (Ravi Subrahmanyan)
Subject: Re: Ratfor (!) (In C too !!)
To: info-atari16@score.stanford.edu

In article <472@yetti.UUCP> oz@yetti.UUCP (Ozan Yigit) writes:
>    I have sent my Ratfor-in-C to mod.sources a couple of days ago.
>    [....]  I suspect that it will be easy to put it up on an Atari.

    The version I started from is from a previous posting by Ozan.
The circle closes..
                                -ravi

ps:  I'll get his newer posting (in mod.sources) and set that up on
the ST (unless someone's done it; in that case please post.  It looks
like lots of people are interested after all).

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

Date: 20 Mar 87 00:32:47 GMT
From: rgoodman@csvax.caltech.edu  (Ron Carl Goodman)
Subject: Re: reading from the midi port
To: info-atari16@score.stanford.edu

In article <14085@cca.CCA.COM> you write:
>...
>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.
>My program is basically built with a big 'while' loop which says
>'while data is at the midi in port do blah blah blah'.

The problem is really that your ST is a fast computer!  When your
sequencer is plopping out data, your ST reads it in.  At first, before your
program is going, the data is stored in the 128 byte midi buffer.  As you
read the data, more is being placed in the buffer, but the sequencer does
not spew out data as fast as the ST reads the data.  So your buffer is
eventually depleted.  When the ST catches up (based on when you ran
the program in relation to turning on the sequencer) your ST will make
a request for data and there will be none waiting.  A fraction of a second
later, some will be waiting, but its too late... your while loop has
fallen through.

One solution is to use something that checks the port N times before deciding
that no more data is truly there (to be sure that no more is coming).  N
can be found experimentally.  300 is plenty.  This kind of method is sort
of icky, because N may not work when this program is run on a different
computer.  Another solution is to call a system timer with a delay of like
1/10 of a second and check again before determining no data is left.

By the way, you might wonder how this method works, since the time between
two notes could actually be far more than 1/10th of a second.  Sequencers
put out timing signals as part of the MIDI code (I think 247) at a constant
rate to solve that problem.  Unfortunately, there is no standard END_OF_
SEQUENCE marker.

Ron Goodman


--
rgoodman@cit-vax.caltech.edu    _______ _________ _________       |
rgoodman@cit-vax.bitnet        /           \#/       \#/          |   Pasadena
rgoodman@cit-vax.uucp         |alifornia    |nstitute |echnology  | California
                               \_______ ___/#\___ of  |           |   U. S. A.

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

Date: 19 Mar 87 23:45:04 GMT
From: ihnp4!ihlpf!gjphw@ucbvax.Berkeley.EDU  (Wyant)
Subject: Atari ST system and related items for sale (revised)
To: info-atari16@score.stanford.edu

    We have recently upgraded our Atari 520ST system by purchasing someone
 else's 1040ST system.  This has left us with several duplicate items and a lot
 of software for sale.  In my original posting, I omitted a single-sided disk
 drive which is also available, so I will repeat that part of the notice that
 should be changed.  For those who are interested but living outside of the
 Chicago area, we can send you what you want COD by UPS.

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

 hardware:

 520ST color system  (520ST console with 512K RAM, Atari color monitor, disk
 drive, owner's manual)

 : with single-sided drive - $674

 : with double-sided drive - $774

 software included - BASIC, Neochrome (drawing program), First Word (word
      processor), LOGO, ST-Writer (word processor), and DBmaster (GEM based
      database utility).  Also, Flash (very good terminal emulator), DEGAS
      (excellent drawing program), Cornerman by Michtron (similar to Sidekick),
      and five (5) public domain disks:

 1. Uniterm 1.7a and arc program disk

 2. disk of pictures for Dr. Who and Star Trek characters (includes latest TINY
    routine for viewing and scaling)

 3. cartoon disk of Warner Brothers and Disney characters (uses TINY)

 4. AEGIS Animator demonstration disk (files must be unarced)

 5. utility disk containing Apple II and Atari 8 bit emulators plus other
    utilities

 6. Boffin demo disk - a working prototype of a word processing routine which
    can handle graphics as well

 An Abacus book titled "Presenting the Atari ST".

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

 A second double-sided disk drive is available for $179.00.

 The single-sided disk drive alone is $85.00.



                                           Gail Wyant
                                           (312) 554-2657

                                               or

                                           Michael Fanelli
                                           DECmail: phdvax::fanelli
                                           Bluebell, PA

                                               or

                                           Patrick Wyant
                                           AT&T Bell Laboratories
                                           Naperville, IL
                                           *!ihnp4!ihlpf!gjphw

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

Date:     Thu, 19 Mar 87 20:41 AST
From:     <FXDDR%ALASKA.BITNET@wiscvm.wisc.edu>
Subject:  Publishing Partner memory usage
To:       info-atari16@su-score.arpa
X-Original-To:  arpa%"info-atari16@su-score.arpa", FXDDR

I made up a demo file for Publishing Partner, incorporating graphics,
Helvetica, and Times-Roman fonts at various sizes, saved it on disk and
went on to other things.  This morning I booted from my Uniterm disk,
which sets up a 400K eternal ramdisk and loads Antic's Crystal desk
accessory.  I cranked up Pub Partner to convert my demo to PostScript
on the ramdisk so I could upload it for printing.
When the demo loaded, yuk!  The Times-Roman was now Martian-Hieroglyphics.
I checked the font menu and in place of Times-Roman was more Martian.
Hmmm.  After some fooling around I found that when I rebooted with a
320K ramdisk and no desk accessories, I had Times-Roman again.  So it
looks like when memory gets tight, the last font in the table gets
grunged.
However, with the 400K ramdisk and Crystal, Pub Partner's "Don't Look..."
box showed free program space of about 200K and free system space of about
7K.  No sign that it is worried about lack of RAM.  With the smaller ramdisk
and no DAs free program space is about 300K and free system space is still
about 7K.
The question is this:  why does the font get trashed?  Pub Partner doesn't
seem to be upset about the amount of ram, and its display shows no shortage.
Is there some sort of interaction between Pub Partner and Crystal?  Or
does the ramdisk mess up Pub Partner's memory allocation?  My main concern
is that there doesn't appear to be a way to tell when you've stepped over
this line...things just start getting trashed.  Any ideas?
For now I will do my composing with no DAs and no ramdisk just to be safe.

Don Rice
University of Alaska, Fairbanks   BITNET%"FXDDR@ALASKA"
CIS 72337,3417  //  KL7JIQ

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

Date: 20 Mar 87 03:01:52 GMT
From: mnetor!utgpu!pete@seismo.css.gov  (Peter Santangeli)
Subject: Re: Help! vro_cpyfm,vrt_cpyfm
To: info-atari16@score.stanford.edu

In article <672@atari.UUCP> leavens@atari.UUCP (Alex Leavens) writes:
>in article <8703170112.AA00614@ucbvax.Berkeley.EDU>, JANKOWSJ@UNION.BITNET
 says:
>>              Is there any-hacker in this universe that can assist me in
>>          finding information about working with the G.E.M. functions
>
>        2)  Make _sure_ that your source and destination blocks the
>            same size.
    Although I have yet to try it, According to Abacus, when given differing
sizes of blocks, the system uses the size of the source block.

>
>        3)  Make sure the pixel width of your raster is an even multiple
>            of a word size (ie, 16).
    This is only necesairy when speed is at a premium. The routines can
handle bit-boundaries. This brings up an interesting point of interface theory.
I have noticed that many GEM programs snap windows to 16bit boundaries.
I fully understand the rational for this, but I don't think I agree with it.
Though doing this increases speed, it very much reduces the quality of the user
interface. Snapping takes away the feelinng that what you do is what you get.
    I would rather have the machine do EXACTLY what i want, and decide when
running a program whether I want 16 bit boundaries. This is sort of a time-
interface tradeoff. One of many in a windowing system!
>
>        4)  You probably want to make sure that your source and destination
>            rectangles don't overlap.
    I can see no real reason for this. The routines are "smart" and can
transfer over each other.

>
>Good luck!
Yup!

                    Pete Santangeli
                    pete@utgpu

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

Date: 19 Mar 87 23:48:46 GMT
From: imagen!turner@ucbvax.Berkeley.EDU  (D'arc Angel)
Subject: 1st posting to comp.binaries.atari.st
To: info-atari16@score.stanford.edu

I have just post my first program to comp.binaries.atari.st, it is
the SpaceWars game (Version 3.1). hopefully most of the bugs are out
of the system. However i doubt it, could people give me feedback as
they receive the posting, thanks. Also I am sending it to
INFO-ATARI16@SCORE which i hope will get it onto ARPA but i still
need help with BITNET, would some kind soul like to volunteer as my
gateway to bitnet ????


--
---------------
C'est la vie, C'est la guerre, C'est la pomme de terre
Mail:    Imagen Corp. 2650 San Tomas Expressway Santa Clara, CA 95052-8101
UUCP:    ...{decvax,ucbvax}!decwrl!imagen!turner      AT&T: (408) 986-9400

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

Date: 18 Mar 87 15:50:31 GMT
From: decvax!watmath!daemon@ucbvax.Berkeley.EDU
Subject: Re: 68020 Box, laser printer, Eastern Pa. Expo
To: info-atari16@score.stanford.edu

In article <10162@topaz.RUTGERS.EDU> you write:
>Mark did say that the box would only use the ST's I/O ports.  Well why
>not put a few RS-232 ports on the box. This would allow you to hook
>your 8-bit up to your ST as a terminal.  It could also be used in a
>University Microlab, for running a BBS and allowing console logins.
>Another use would be in an office situtation.  This way many people
>can access the same files, share printers, etc.  It seems that this is
>VERY possible under System V UNIX.

I'm a little leary of this suggestion.  The 68020 box would be a wonderful,
single-user, Unix workstation.  Adding multiple serial ports to allow a lot
of multi-user use would change this inexpensive Unix workstation into an
"Office" computer, with a corresponding increase in price.  Atari would have
to pay AT&T for additional licenses; there would be more gunk in the drivers
and hardware to suppport the extra serial ports, etc., etc.

I would like a couple of serial ports for one extra terminal, a modem, etc.,
but nothing more.  Atari has often been the David of the computer industry;
I would prefer that the 68020 box remains affordable and doesn't turn into
another Goliath of a computer.

Mike Berkley, University of Waterloo

UUCP:        {allegra,ihnp4,utcsri,utzoo}!watmath!watsup!mberkley
Bitnet:        mberkley%watsup%waterloo@csnet-relay.ARPA

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

Date: 19 Mar 87 05:18:08 GMT
From: mnetor!genat!maccs!cs3c3cg@seismo.css.gov  (Ray )
Subject: Re: laser printer
To: info-atari16@score.stanford.edu

In article <667@atari.UUCP> leavens@atari.UUCP (Alex Leavens) writes:
>in article <261@nikhefh.UUCP>, t68@nikhefh.UUCP (Jos Vermaseren) says:
>>
>> At Hannover I saw the Atari laser printer.
>> It was announced as a 8 pages per minute printer.
>> In a report from the computer show in Vegas I read
>> something about 30 or more pages per minute. Was the person
>> who mentioned this mistaken, or is this not the same printer ?
>> ...Alex ??....
>
>  The 8 pages a minute figure is correct.  I've never even _heard_ of a laser
>printer that'll do 30 pages a minute...
>
  Oh yeah,
      The IBM 3800 Laser printer prints at 2 1/2 pages a second!!!
  thats 150 pages a minute!!!

  Now before any of you in netland start salavating, there is a catch,
  the price,

      a cool  $1M  (at least that is what I was told) :-) :-)

                          Ray Wong

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

Date:    Fri, 20 Mar 87 00:08:44 PST
From:     johnson%msuhep.hepnet@lbl.arpa
Subject: The New 8-Bit Emulator
To:       INFO-ATARI16@SCORE.STANFORD.EDU
X-ST-Vmsmail-To: LBL::"INFO-ATARI16@SCORE.STANFORD.EDU"

Howdy Netland!! I have heard very little about the NEW 8-BIT
Emulator and thought I would give an update on its current status.

    For those of you who are not familiar with the Beta version that
has been out for awhile it may be because it was _OFFICIALLY_ ordered
out of distribution by Atari corp. {Question to Alex, why did you
wait until last week to even call the author, when Atari made this
declaration at least a month ago?????}

    The emulator does a real good job of emulating 8-bit software
and should be in distribution again soon.  You see there was a
reason Atari ordered this yanked; it used Atari OS images....
yes, this is illegal. Darek's (the person who did the programing)
newest version, being completed this weekend, will come up and
ask you if you want to be an 8-bit atari or an apple II today!
Although I understand both the Apple II and the Atari emulators
run at about a quarter of the speed on their respective machines,
they are pretty impressive.  The Atari emulator, for instance,
emulates almost everything but player missle graphics!!
{I should be recieving a test copy next week and I will inform you
of what progress he has made.}

    The purpose of my posting this is to a) inform the info-atari
readers of this new piece of software and to b) bring up the poor
attitude of Atari.  Both of these topics are covered in much
greater detail in the following articles.  The first is by Darek
Mihocka, the author, and the second is by John Nagy, sysop and Vice
President of C.H.A.O.S. users group in Lansing, Mi.
Responses from Atari are welcomed (have you recieved your copy yet
Alex?? <grin>)

Good reading, John Johnson- ST Interest Group President, C.H.A.O.S.
--------------------------

(reprinted from ZMAG)
Current information about the ST
Transformer as of 03/09/87

By Darek Mihocka (CIS 73657,2714)
Programmed by Darek Mihocka
additional programming and all night
testing by Ignac Kolenko hardware
supplied by:

Xanth Computer Systems
600 First Avenue
Seattle, Washington

The purpose of this document about
the ST Transformer is: - to explain
its purpose and give a history of its
development - to give the latest
information about the ST Transformer
- to discuss the legal problems with
this program and why I can't release
it to the public for all former Atari
400/800 owners - to find other
programmers to work on this project.

For those of you unfamiliar with the
name, you have seen it as the Atari
800 Emulator Demo or the Apple ][
Emulator.

Part 1:The history

When Atari introduced the ST
computers, I was then the owner of
an Atari 400, bought way back in 1981
with all my summer's earnings. Like
many other people I spent a
considerable amount of money on my
system for software and disk drives.
About the only piece of hardware that
I could use on the ST was my FX80
printer. This is not too useful as
none of the software works. So I held
off buying an ST for over a year as I
waited for Atari to introduce some
kind of a device or program to allow
me to run old software. They never
did. I finally sold the 400 and
bought the ST anyway because after
using 68000 based in machines at my
university, I was impressed by its
power and already had a program in
mind.

The implementation:
The first project I decided to work
on was to somehow run the old
software so that all that money
didn't all go to waste. I considered
2 approaches:

 - the first approach is to write a
   program that reads a binary file
   from a 400/800 and convert each
   machine language instruction into
   a 68000 instruction. This would
   then create a file on the ST that
   would run about 10 times the speed
   of the original file!

Problems:
 - how do you tell the difference
   between code and data?
 - how to handle self modifying code?
 - how to handle the  hardware
   registers?

 - the second approach is to write an
   interpreter, similar to the way
   BASIC interprets a tokenized
   program, or the way that a real
   microprocessor executes code. You
   read in a byte of memory,
   determine which 6502 instruction
   it is, and execute it. The real
   6502 executes microcode. I would
   use 68000 instructions.

Problems:
 - the overhead of processing each
   instruction is greater than the
   time it takes to actually execute
   it.

 - how to handle hardware registers?

I chose the second approach because
it solves the first two problems of
the first approach, and shares the
third problem. The problem of speed
is also in both approaches. Software
running at ten times the speed is
usually unusable. This is similar to
the problem when some IBM PC software
is run on an AT or even worse, a
Compaq 386 (18 times faster). It is
always possible to use software
running slower. The unknown is how
slow the software would run. The
hardware problem can be solved by a
similar interpreter which checks
which register is being accessed and
does something accordingly.

First results:

The first version of the 6502
interpreter was written in Megamax C
in August. As it turned out, the
unknown speed was about 7% of the
speed of a real 6502. This does not
include the extra interpretation of
hardware. It was obvious that hand
coded 68000 code was needed. About a
month later, I had the hand coded
version sort of working at about 30%
of the speed. To make the hardware
interpreter would be difficult,
because of the dozens of hardware
locations in a 400/800. I chose then
to first do an Apple ][ hardware
emulator, because there are only 2
vital locations needed to get it to
work: the keyboard and the screen.
The next month was spent debugging
the many bugs that crept into the
6502 interpreter and porting software
from . Finally it worked, at about
25% of the speed.

This is the version that you have
seen as the Apple ][ emulator.

First Problems:

One problem with all emulators is
inherent in their design: to emulate
the software of another machine, you
must transfer that software. When I
approached Apple about this, they
told me that what I am doing is
illegal, since I copied the ROMs of
Ignac's no name ][ clone, which had
ROMs probably derived from an Apple.
I approached Apple Canada about
getting the real ROMs from them, plus
the code for Apple DOS, and anything
else they'd want to let me try. As it
turned out, they saw my project as
software piracy and told me to forget
it. I guess they didn't want to
expand to the ST market anyway. After
the Apple told me they weren't
interested, I decided to stop
spending more time on Apple
emulation. I ported over my copy of
the Translator disk's image of the
Revision B ROMs. I chose those ROMs
because they are made to run with 64K
of RAM, which is what the 6502
interpreter sees when it is
executing. I also ported a copy of
Atari Basic to use as a test file.
After only a few days of hacking the
Apple ][ routines, I got a very
primitive version of the Atari
emulator working. It only supported
a few graphics modes and still had a
major 6502 bug, but it sort of
worked. I uploaded it to my BBS and
to Atari's BBS as the Atari 800
Emulator Demo.

Part 2: the Atari 800 emulator

What happened then was a big shock.
I got a phone call from one of the
Atari BBS sysops telling me that
Atari was not pleased with what I had
done. They too considered my program
as piracy. I was told that I would be
contacted within a few days to
discuss the emulator. No one ever
called back, and I have never been
able to get through to anyone that
would discuss it with me. The
secretaries usually screwed me around
on the phone. Attempts to reach
someone willing to talk on Compuserve
also failed.

What I currently have is a program
that appears to execute 6502 code
according to the 6502 specs at about
20% of the speed. This includes the
overhead of the hardware interpreter.
The hardware supported so far
includes:

 - graphics modes 0,1,2,3,6,6+,7,7+,
   and 8
 - most display lists, no matter how
   complex
 - most keyboard keys, including
   START, SELECT, OPTION, RESET,
   caps, inverse, and BREAK.
 - the color registers, and a few
   other miscellaneous locations
 - most read and write DOS operations
 - 1 joystick port
 - printer output -

Runs most BASIC software I've
downloaded from BBSs and tested.

Not supported yet:

 - GTIA modes
 - player missle graphics
 - sound registers
 - a combination of the two mentioned
   approaches, where parts of the
   operation system are hand coded to
   68000 code and executed directly,
   not interpreted. This is already
   done for the D: and P: drivers,
   but I plan to eventually do the
   whole operating system which would
   result in a significant speed
   increase.

Part 3: Legal Problems

According to Apple and Atari, it is
illegal for me to distribute the
emulator any more because I had
included the ROMs with the demos.
That is the reason I have not
released anything in over 2 months.
I respect their legal right, but I
also believe that Atari has an
obligation to all the tens of
thousands of 8 bit owners who helped
build the Atari empire. The only
people who can make a perfectly legal
emulator are Atari themselves. I have
spent about 500 hours of my time
planning, programming, and testing my
program. This may seem like a lot,
but it works out to about 10 weeks of
full time work, or about 2 to 3 weeks
work for a team of Microsoft caliber
programmers, which I assume Atari
has. With their technical knowledge
of both the 8 bit and the ST
computers, I don't see why Atari
couldn't have released an fully
implemented emulator 18 months ago.
They were quick to introduce the CP/M
emulator. I've compared the code of
my program and theirs, and it is
quite similar. So they are half done
already. Until they do, I will keep
working on my program until it is
functional enough to run most
software that can be downloaded. Once
released, it will be up the
individual used to copy their ROMs
over to the ST. Atari says that's
illegal. For as long as the people do
it for their own use, I do not see
this as being illegal. I do not have
access to high priced lawyers, so I
am hoping that Atari will finally
talk to me and come to an agreement
that will benefit us all.

Part 4: Programmers Wanted

Most of the emulator is written in
68000 code, with C code handling the
less critical routines. It has been
suggested that I write my program
for the Amiga, because its superior
graphics would make it easier to
implement player missle graphics and
the other features. Since I have
never programmed the Amiga, I cannot
make the Amiga version. What I would
also like to do is write hardware
emulators for other computers, like
the Commodore 64, VIC 20, Color
Computer, Sinclair, etc. Anyone
proficient in 68000 programming that
would be interested in writing those
modules starting sometime next fall
or winter should contact me.

Until then, keep an eye out on your
local BBS for the ST Transformer
which I hope to have released in
June. I will update the situation on
the board I hang out on, Megabaud
416-243-9519. Anyone having any
suggestions on the program or who
can help me with the legal questions
can reach me on Compuserve or write
to me before May 1 ,1987 at 5023
148th Ave. N.E. #G207, Bellevue,
Washington

[ED.] In addition to this text sent
in by Darek. I would like to add that
I have spoken to this gentleman
myself and feel that he is entitled
to some type of official response
from Atari Inc. In the weeks ahead
and until we feel that Atari is
looking into this matter, we will
update you on a weekly basis and
next week, we will supply you with
a few names and addresses to send
off letters to. If we can produce a
loud enough voice as 8 bit owners,
we can perhaps persuade Atari to
respond.

>> Note: Darek told John Nagy that Alex did FINALLY call
>> after what was rudely and inordinate ammount of time.
>> Alex informed him that Atari would have to do ALL distributing
>> of it.. I'll try to get him to mail me a reply to post next week.

----------Article 2----------------------------

Supplied by the CHAOS BBS-
Reprinted From MICHIGAN ATARI
MAGAZINE by permission.


THAT WAS THE ATARI EMULATOR THAT WAS
by JOHN NAGY (C.H.A.O.S.)

An "800" emulator for the ST is a
reality!  I have seen it and talked
to the author.  DAREK MIHOCKA of the
LONDON, ONTARIO area, has written and
distributed several levels of beta
test versions on BBS's.  He
originally planned to make a emulator
for just about all the 6502 machines,
but has since broken the emulations
into separate versions for the APPLE
][, the ATARI, and soon the COMMODORE
64.  (YIKE!).

The version I saw ran no graphics and
did not support DOS functions.  But
in a telephone interview on February
22, Darek, a 20 year old college
student at Waterloo University
outside Toronto, told me that he has
now developed the emulation to
produce all graphics modes, DOS
support, and even DISPLAY LISTS!
Still to be developed are PLAYER
MISSLE GRAPHICS and SOUND.
Additionally, there seems to be a
string-handling bug in the ATARI
8-bit BASIC emulation but Darek
expects to have that corrected
shortly.  Ult