No Fragments Archive 12: Textmags & Docs/nf_archive_12.iso/MAGS/TEXTMAGS/ATARI16/INFO89.ZIP/INFO89/406.TXT

Text File | 1997-04-16 | 20KB | 511 lines

Info-Atari16 Digest   Tuesday, August 22, 1989   Volume 89 : Issue 406

This weeks Editor: Bill Westfield

Today's Topics:

                         Screen flicker, top
                 Dallas SmartWatch & software for it
                      Re: Multitasking revisited
Anyone coming to the Duesseldorf Atari exhibition on friday Aug 25th ??
                        Re: Curses for the ST
                 Re: CMI Processor Accelerator Board
                      Re: Multitasking on the ST
                  Re:  Info-Atari16 Digest V89 #370
                          Re: Mac emulation
                            Loyal to Atari

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

Date: 14 Aug 89 13:01:09 GMT
From: romeo![e-mail]  (Bob Currier - DCAC Network Comm. Specialist)
Subject: Screen flicker, top
To: [e-mail]

Greetings,

This weekend, while noodling around with animation, I came across a
most puzzling phenomena.  My graphics displayed fine while on the
lower part of the screen (I am using a monochrome 1040), but when
my little critters got about 30 or 40 pixels from the top they
started to get a bad case of the flickers.  I was using Vsync() to
control flicker, and it seemed to work well, except for this
twilight zone.

I pulled my hair out for a couple of hours on this one, dug thru all
my books, and finally, at about 1 a.m., in the premier issue of START,
found a comment in an article about al graphics that went like this:

"...vsync, but you will still see flicker near the top of the screen.  This
is a problem that can only be dealt with by very complex multiple screen
flipping techniques..."

So, does anyone know of this problem?  What causes it? And, Virginia, how
can I eliminate it?


Bob Currier
[e-mail]
[e-mail]

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

Date: 15 Aug 89 11:20:53 GMT
From: cs.dal.ca!iisat!brains![e-mail]  (George Seto)
Subject: Dallas SmartWatch & software for it
To: [e-mail]

Dallas SmartWatch & software for it:

  Andrew Como @ bnlux0.bnl.gov writes :

 > I was given some software to run the clock that was written by some
 > now-defunct software house in Calif (the name escapes me).  The software
 > doesn't seem to work with the clock inserted in any of the ST's rom
 > positions.


 > Has anyone sucessfully written software to run the clock chip on the
 > 1040 ST?

   Yes, a fellow named Bill Penner from Washington/Oregon way wrote a program
called AREAL, which is up to version 3.31 currently. There was an article in
a magazine called ST-Xpress which published an early version of the program.
The current version of the software works either under the ROMS (you MUST
have a ROM in the socket) on the main board, or under ROMs in the cartridge.
The software is supplied with a configuration program and two versions of the
program. One works in the AUTO Folder, and the other is an accessory. The
program will also accept as many SmartWatches in as many socket positions as
you have ROMS for. In a 6 rom system with cartridge, that could be as many as
10 Smartwatches. It can set each of them independently, you could have the
time zones for quite a bit of the world in your computer.
 Check your local BBS's for this software. It is definitely worth getting.


 >Also the Dallas Semi chip is rather bulky in the 1040 ST ..basically
 >I'm gonna have to cut the power supply housing to make it fit.  Does
 >anyone know of a cartridge time clock?


  There are several cartridge time clocks. The two most popular also allow
other functions as well. DeskCart from QMI is one, and BackPack from a
company in Britain.

   Does that help? Hope so. Where abouts are you located, Andrew?
--
   -===------===-    From George Seto at Cerebral Cortex BBS System
  -==-==----==-==-   [phone] 3/12/2400 8N1 24h/7d
 -==-------==------  [e-mail]
  -==-==----==-==-   uunet, utai, watmath!dalcs!iisat!brains!george_seto

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

Date: 15 Aug 89 09:34:29 GMT
From: uhccux![e-mail]  (Yuan 'Hacker' Chang)
Subject: Re: Multitasking revisited
To: [e-mail]

In article <[e-mail]> [e-mail] (That's me!) writes:
>    Alright!  8)  If I want to run spell-checking on a document in
>my word processor, heck, re-write the word processor so that it
>runs in the background.  After all, I don't need a full blown
>multitasking environment for something as simple as spell-checking in
>the background.
>        [same for database, spreadsheet, and CAD]

In article <[e-mail]> [e-mail] (Scott Flinn)
 writes:
-
-In fact, since this discussion began, I have carefully monitored my usage
-of multitasking while using the multivarious UNIX boxes around here, and
-I can honestly say that, since Greg Csullog's original article first
-appeared, I HAVE NOT BENEFITTED FROM MULTITASKING.  I am doing task
-SWITCHING like its going out of style, but I just can't keep up with
-more than a couple of things.

    I didn't say that I want to run a database, a spreadsheet, a CAD
program, and a word processor ALL at the same time.  In fact, I don't see
how you got the idea that I'm adding fuel to the multitasking vs. task-
switching war.  8(
    In the original article to which I was following up to, the author
was wondering why a full-blown multitasking system should be necessary,
when you could find programs that push themselves to the background.  What
I was trying to point out was that user programs do not have to know about
being in a multitasking/switching system, because the system takes care of
the details.  Think what happens if TOS doesn't provide file services for
user programs, and each single program must handle raw disk I/O in order to
use a disk drive.
--
Yuan Chang                       "What can go wrong, did"
UUCP:      uunet,ucbvax,dcdwest!ucsd!nosc!uhccux!yuan
ARPA:       uhccux![e-mail]               "Wouldn't you like to
INTERNET:  [e-mail]         be an _✓A_✓m_✓i_✓g_✓o_✓i_✓d
 too?!?"

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

Date: Wed, 16 Aug 89 12:47:30 SET
To: [e-mail]
From: [e-mail]
Subject: Anyone coming to the Duesseldorf Atari exhibition on friday Aug 25th ??

Hello all,

  .... this mainly concerns European readers of the digests.

  The 1989 Atari exhibition takes place in Duesseldorf starting Friday, August
25th though Sunday. I'm going on friday, and I'd like to know if there are
people on the net who are also going and might be interested in a meeting to
exchange info and anything else one might be interested in.

  Please reply directly to me, unless you're willing to organize something.

----------------------------------------------------------------------------
Bitnet:  VBRANDT@DBNUAMA1 (will go away late '89)      Volker A. Brandt
          UNM409@DBNRHRZ1 (soon)                       Angewandte Mathematik
UUCP:    ...!unido!DBNUAMA1.bitnet!vbrandt             (Bonn, West Germany)
ARPAnet: [e-mail]

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

Date: 15 Aug 89 17:17:41 GMT
From: sumax!amc-gw!pilchuck!ssc![e-mail]  (Phil Hughes)
Subject: Re: Curses for the ST
To: [e-mail]

> There is a curses library/source for ftp on him1.cc.umich.edu.
> I used this package to port TETRIX about 2 months ago (which has since
> been posted to the net).

Anyone know where this can be uucp'd from.
I don't have ftp access here and this is something
that I will need in the coming months when I port a translation
program from UNIX and DOS(ug) to the ST.
--
Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155  (206)FOR-UNIX
    amc-gw!ssc!fyl or uunet!pilchuck!ssc!fyl or attmail!ssc!fyl

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

Date: 16 Aug 89 07:57:53 GMT
From: well![e-mail]  (Steven Robert Fordyce)
Subject: Re: CMI Processor Accelerator Board
To: [e-mail]

> I can report a success story at installing the CMI accelator board.

[STuff deleted]

> One question... the red fly-wire, documentated as connected to R4
> on the 520st, and un-connected on the Mega-st... what is its purpose?
> At least for me, the board seems to work regardless of whether or not
> the red wire is connected.  My copy of the st schematics (which admittedly
> might not match the motherboard revision I have) shows R4 as being in
> the midi data current loop circuitry.

This is the interupt for the blitter.  That's why it isn't needed on a
Mega, which already has a blitter.  Of course, it is only needed on a 520,
or 1040 if a blitter is installed on our board.

> A note on the manual... the way I read it it implies that you get 16mhz
> operation by closing the jumper, and 8mhz by leaving it open.  However
> on my system it's just the opposite; 8mhz when the jumper is closed,
> 16mhz when it's open.

What you said is correct: the manual is in error.  Sorry!  We are currently
rewriting the manual.

> What are the recommended parts to use the fastrom sockets directly on the
> board?

Standard 1 megabit (128k x 8), 200 ns or faster parts.  These will be
available from us programed with 1.4 as soon as we get a license from
Atari, which we expect real soon now.

> What is the definition of the "expansion" pins?

We will be anouncing an expansion product that will plug into that when we
are done with it.  But in any case, here is the pinout:

            Pin    Definition
             1    +5
             2    A04
             3    A03
             4    A02
             5    A01
             6    EN1*
             7    EN2*
             8    UDS*
             9    LDS*
            10    AS*
            11    DTACK*
            12    GND
            13    GND
            14    GNB
            15    NC
            16    D00
            17    GND
            18    +5
            19    D01
            20    D02
            21    D03
            22    D04
            23    D05
            24    D06
            25    D07
            26    FC0
            27    FC1
            28    FC2
            29    IPL0*
            30    IPL2*
            31    RESET*
            32    READ
            33    8M
            34    GND

If this seems like an odd collection of signals, it is because we had a
specific purpose in mind for the connector and we included only those
signals we needed for that purpose.  The row of pins starting with the pin
closest to the CPU are numbered 1-17.  The next row is 18-34, with pin 34
next to pin one.  EN1 and EN2 are two decoded addresses.  8M is a buffered
8 MHz clock.


By the way, the 1040 version of our board will be shipping next week.

                        Steven R Fordyce
                       uunet!sequent!calvin!stevef

Creative Microsystems, Inc., 19552 SW 90th Court, Tualatin, Oregon  97062, USA
For customer service, call Lillian Carter at [phone], FAX [phone]

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

Date: 16 Aug 89 08:58:52 GMT
From: mcvax!hp4nl!phigate!philmds![e-mail]  (Leo de Wit)
Subject: Re: Multitasking on the ST
To: [e-mail]

Sorry to bother who it might not concern, but due to a mailer problem I'll
have to try it this way.

    Leo.


>From phigate!hp4nl!hp4nl.nluug.nl!cs.utexas.edu!MAILER-DAEMON Wed Aug 16
 09:56:41 1989
Received: by dts.philips.nl; Wed, 16 Aug 89 09:56:31 -0200
Received: by philips.nl; Wed, 16 Aug 89 09:31:43 +0200
Received: from [128.83.139.9] by hp4nl.nluug.nl with SMTP
          id AA22560 (5.58.1.14/2.14); Wed, 16 Aug 89 08:49:38 MET
Date: Wed, 16 Aug 89 01:49:07 CDT
From: phigate!cs.utexas.edu!MAILER-DAEMON (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Posted-Date: Wed, 16 Aug 89 01:49:07 CDT
Message-Id: <[e-mail]>
Received: from uunet.UU.NET by cs.utexas.edu (5.59/1.39)
    id AA02583; Wed, 16 Aug 89 01:49:07 CDT
To: <@hp4nl.nluug.nl,@phigate:leo@philmds>
Status: R

   ----- Transcript of session follows -----
Unknown host: meadow
550 <meadow![e-mail]>... Host unknown

   ----- Unsent message follows -----
Posted-Date: Wed, 16 Aug 89 07:58:25 -0200
Received-Date: Wed, 16 Aug 89 01:49:07 CDT
Received: from uunet.UU.NET by cs.utexas.edu (5.59/1.39)
    id AA02571; Wed, 16 Aug 89 01:49:07 CDT
Received: from hp4nl.nluug.nl by uunet.uu.net (5.61/1.14) with SMTP
    id AA05718; Wed, 16 Aug 89 02:48:54 -0400
Received: from phigate by hp4nl.nluug.nl with UUCP via EUnet
          id AA22332 (5.58.1.14/2.14); Wed, 16 Aug 89 08:12:38 MET
Received: by philips.nl; Wed, 16 Aug 89 08:02:59 +0200
Received: by dts.philips.nl; Wed, 16 Aug 89 07:58:25 -0200
Date: Wed, 16 Aug 89 07:58:25 -0200
From: [e-mail]
Message-Id: <[e-mail]>
To: meadow![e-mail]
Subject: Re:  Notes on multitasking

Hi Bill. In your letter you write:

|I really wish it would rain more in California.

Sometimes, when it's been good wheather for a long period (that is a
rare occasion here in Holland, but this summer was like this) I long
for a few dark and rainy days - ideal for a nice project.

|You know that when you are going to multitask programs with disk usage,
|things such as the DTA address, Fsfirst-Fsnext chains, current drive and
|directory, and probably several other things have to be saved on context
|switch.  You may also have a problem with the OS's terminate calls.

Yes, I know (B.T.W. several people told me this; there seems to be both
a fairly large interest in this subject as general knowledge of the
traps and pitfalls). The strong point of my design is that it is
synchronized with GEMDOS calls (and for CPU bound processes there's a
different solution). GEMDOS calls, as you'll probably know, save their
registers on the current process's basepage and stack. As far as DTA
address, current drive / directory is concerned, this is also
information that is kept on the basepage with the process.
Fsfirst-Fsnext chains are kept in your disk transfer buffer (the
information to find the next is found from the first 20 bytes). This
buffer also resides within your process (and DTA, a pointer on the
basepage, points to it).

Terminate calls are no problem at all. Processes that run detached ('in
the background') get a special parent: a basepage in the multitasking
kernel itself which returns control to the dispatcher (that frees the
process slot). Ordinary processes just end the usual way (their process
slot will be taken again by the parent). I even implemented kill() and
signal() calls to be able to stop and restart or kill processes (even
coredump). Also alarm(), sleep(), and pause() have been implemented
(yesterday).

|I tried a number of methods for multitasking including Desk Accessories,
|VBI, and 200 Hz system timer - all before I found out about saving disk
|info.  Maybe it would work better with this implemented.

You have to take great care when interrupting GEM, this is not built to
be multitasking. I use VBI for CPU bound processes; after a time slot
has been used up, and if the process is in user mode, it switches to the
dispatcher as through a GEMDOS call (the registers are saved on the
process's basepage and stack), since I know I'm not interrupting GEMDOS
right now.

|
|What we really need is a multi-tasking TOS 2.0 on ROMS (dream on - Atari will
|release it's TOS/Unix machine and then forget about ever multitasking TOS)

Sure, but like TOS 1.4 this can take quite a while; for the GEM part it
would mean a general redesign (the GEMDOS part, in all its simplicity, is
very easy to make multi-tasking; that's just what I did).

|Good luck - it should prove interesting.

It sure is; thanks for your interest & concern.

Cheers,
         Leo.

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

Date: Wed, 16 Aug 89 09:36:11 EDT
From: [e-mail] (R. Kushnier)
To: [e-mail]
Subject: Re:  Info-Atari16 Digest V89 #370

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

Date: 16 Aug 89 13:19:32 GMT
From: crdgw1!minerva![e-mail]  (B. S. Oplinger)
Subject: Re: Mac emulation
To: [e-mail]

In article <[e-mail]> [e-mail] () writes:
>
>Are there any legal problems in using a Macintosh emulator (such as Aladin
>or others)? What I need is a quoteable source, no rumours! Maybe the legal
>situation in different countries is different.. So what is it like in
>Germany and in Switzerland?
>
In order for an emulation of the Mac to work, the data contained
in the Macintosh Roms must be used. If the emulator is software
based, the data is contained in the program itself. If it is
cartridge based the data is in the (EP)Roms. The only legal way
to use the data in Apple's Macintosh Roms is to use the Roms
themselves. Period, end of story, in any country that abides by
international copyright laws. Eproms or software copies are
illegal.

    If that doesn't bother you the Happy Cartridge basically
states in their advertising that MAC roms may be copied and the
eproms used in the cartridge along with a pirated version of the
Spectre 128 software.

    If on the other hand, you at least try to be civil about
things, I recommed the Spectre 128. It does fully Mac emulation,
you can print with about any printer using Grapple LS as the
print driver (I recommend buying a driver for you specific
printer though, as I find the grappler less than optimal), use
real SCSI devices (if an interface, like on the back of Supra
Drives, exists that you can use), and so on. Dave Small, the
maker of the Spectre, has produced updates on an about 6 month
cycle, each one corrected bugs and added new features. The
support seems to be there.

    Finally, the hardware required to do Mac emulation on the
Atari. IMHO you need 2 Megs of memory and at least 30 Megs of
hard drive. You can get by with less, but....

    Hoped this answered your question.

    Brian

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

Date: 16 Aug 89 13:13:00 GMT
From: mailrus!caen.engin.umich.edu![e-mail]  (Brian J
 Denheyer)
Subject: Loyal to Atari
To: [e-mail]

Who wants to be loyal to a company that doesn't upgrade the operating system
in a regular manner or announces lots of vaporware ?

Not me.

On the other hand, you get what you pay for.

I went out looking for a new computer and thought, gee, maybe I'll get
a Mac or an Amiga.

Ha !

Anybody looked at the price of a Mac/SE with a 20 MB hardrive lately ?
$2700 or so is what you can expect to pay.  That extra $700-$800 (above a
 similar ST) goes into
things like OS upgrades.  The Amiga is better, but they don't have the
nice crisp mono display that the ST has (which I find to be very easy on the
 eyes).
In the meantime I'd have to learn how to program a new machine, just when I've
 learned
to really use GEM efficiently, and give up about $500 in software that I have
 BOUGHT.

So I'm upgrading to a Mega-2 and if I really want a Mac I'll
go out and buy Spectre GCR.

The sad part is that the ST can do anything that a Mac can do except that nobody
has bothered to write the programs.  You can get a program called Mathcad for
 the
Mac which I'd really like.  There is absolutely no reason why the program could
 not
be ported to the ST except for the fact that the software houses don't think
 that
they'll make enough money in the ST market.

The only thing that differentiates the two machines as far as I'm concerned is
 the
software which is available. (Hypercard would be nice, and lightspeed C).  All
 of that
software could easily be written to run on an ST !

It also seems to have very knowledgeable and
enthusiastic users, and that's the aspect of owning an Atari which I have
 enjoyed the
most (Yes I had an Atari 800 - great machine !).

In the meantime the ST is a fun machine to hack on, and I'm able to
use it for everything I need to do (Laser C is no slouch).
That, ultimately, is what is important.

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

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

ə