Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!think!ames!ucbcad!ucbvax!FINGATE.BITNET!MAILER-DAEMON
From: MAILER-DAEMON@FINGATE.BITNET (Mail Delivery Subsystem)
Newsgroups: comp.sys.atari.st
Subject: Returned mail: Deferred: Connection timed out during user open with op
Message-ID: <8707150242.AA15423@ucbvax.Berkeley.EDU>
Date: Tue, 14-Jul-87 22:43:44 EDT
Article-I.D.: ucbvax.8707150242.AA15423
Posted: Tue Jul 14 22:43:44 1987
Date-Received: Fri, 17-Jul-87 01:49:22 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 430


   ----- Transcript of session follows -----
554 qfAA09495: line 6: ... Unknown fudec host name

   ----- Unsent message follows -----
Received: by santra.UUCP (5.51/6.4.TeKoLa)
        id AA09495; Thu, 9 Jul 87 15:45:25 +0300
From: 
Message-Id: <8707091245.AA09495@santra.UUCP>
Received: by fingate Thu Jul  9 15:45:19
        from MAILER@FINHUTC.BITNET via rscs BSMTP.
Received: by FINHUTC (Mailer X1.24) id 5091; Thu, 09 Jul 87 14:54:51 FIN
Date:         Wed 8 Jul 87 14:51:34 PDT
Reply-To: Info-Atari16@Score.Stanford.edu
Sender: "Atari ST users forum (INFO-ATARI16)" 
Original-From: Info-Atari16 Digest 
Subject:      Info-Atari16 Digest V87 #263
To: , 
Original-To: ,

Info-Atari16 Digest   Wednesday, July  8, 1987   Volume 87 : Issue 263

This weeks Editor: Bill Westfield

Today's Topics:

                             MFP problems
                                STadel
                          Degas File Formats
                  Re: Unix Windows (source required)
                           BIOS re-entrancy
                                Curses
                        HDSCAN, bummer man...
                    Re: How can you send a BREAK?
                         Re: BIOS re-entrancy
                    Re: How can you send a BREAK?
                           Re: MFP problems
                        more DCFORMAT problems
                      Re: Mega-ST release date?
            Where can I get the latest version of UNITERM?
                   Re: MWC problem with 'long int'

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

Date: Mon, 22 Jun 87 12:56:36 CET
To: info-atari16@score.stanford.edu
From: HAHN_K%DMRHRZ11.BITNET@wiscvm.wisc.edu
Subject: MFP problems

I'm still trying to install my own timer, and stumbled over the
'fact', that the system's timer ('C') is said to generate a 200hz-
interrupt... As far as I can see it's installing procedure uses a
division factor of 64 (decimal, I suppose), and a counter that's
set to 192 (C0 hex). IF I believe my documentation which says that
the MFP 68901 uses a 4Mhz - clock cycle, then what? All the divisions
mentioned above wouldn't at all generate a 200hz-interrupt. Am I
wrong? What I need are the data and control values for getting a
one-millisecond resolution.
Any suggestions?
Yours in advance, Klaus.


  -- Klaus Hahn --



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

Date: 23 Jun 87 07:41:18 GMT
From: tektronix!reed!percival!edrury@ucbvax.Berkeley.EDU  (Ed Drury)
Subject: STadel
To: info-atari16@score.stanford.edu

  What is the current status of Citadel 3.1 for the ST? I have
not seen any news for some time.
  Also, is anyone interested in creating a snail mail STadel update
type thing. I am currently running v. 3.0c but am DYING for a uucp
capable STadel as a high percentage of my users are *nix account
users, my self included....


****************************************************************************
*    ..!{ucbvax,ihnp4,seismo}!tektronix!reed!percival!edrury            *
*                                       *
* "You should never wear your best trousers when you go out to fight for   *
* freedom and liberty."                                                    *
*        -- Henrick Ibson                                           *

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

Date: 23 Jun 87 07:36:17 GMT
From: tektronix!reed!percival!edrury@ucbvax.Berkeley.EDU  (Ed Drury)
Subject: Degas File Formats
To: info-atari16@score.stanford.edu

 degas  uses the following file format:
The first 2048 bytes fof the font file are divided into 128
groups of 16 bytes. Each set of which are a char. The 16
bytes are stored from the  top to bottom.
 The last two bytes are a WORD indciating whether or not the font is scaled too
 half it's normal
height.
  A DEGAS picture file uses the first two
bytes to determine resolution.
The next 32 to give color palette information and 32000 to give picture data.
 I hope this is of some help.

****************************************************************************
*    ..!{ucbvax,ihnp4,seismo}!tektronix!reed!percival!edrury            *
*                                       *
* "You should never wear your best trousers when you go out to fight for   *
* freedom and liberty."                                                    *
*        -- Henrick Ibson                                           *

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

Date: 23 Jun 87 00:43:14 GMT
From: ihnp4!upba!eecae!msudoc!las@ucbvax.Berkeley.EDU  (Larry A. Sheilds {runs
 Lunapark})
Subject: Re: Unix Windows (source required)
To: info-atari16@score.stanford.edu

I too would like UW source.
    thanks,
                                    ==larry
--
---------------------------
LARRY SHIELDS                        USENET: ...!ihnp4!msudoc!lunapark!larry
P.O. Box 6159                        BIX:  lshields
E. Lansing, MI 48823                 Compuserve: 70277,3677

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

Date: 23 Jun 87 18:16:36 GMT
From: iarocci@eneevax.umd.edu  (John Iarocci)
Subject: BIOS re-entrancy
To: info-atari16@score.stanford.edu

Anyone out there have any experience with making BIOS, XBIOS, and/or GEMDOS
calls recursively?  I'm writing a multi-tasking kernel, and trying to find
a safe way to allow multiple processes access to operating system functions.
My understanding is that upon entry to the BIOS trap routines, registers
are saved in savptr ($4a2).  However, the default save area contains enough
room for only three levels of re-entrancy.  Can this situation be resolved
simply by allocating a larger area of memory and setting savptr to point to
it?

Also, does anyone know if any conflics may arise if a process were preempted
in the middle of the BIOS, only to have another process make a BIOS call,
possibly the same one that was interrupted?  The same question goes for the
XBIOS and GEMDOS.  Thanks in advance for any help you can offer.


-------------------------------------------------------------------------------
| Bill Dorsey          'Imagination is more important than knowledge.'        |
|                                            - Albert Einstein                |
|     'He who has imagination without learning has wings and no feet.'        |
|                                            - Joubert                        |
| ARPA : iarocci@eneevax.umd.edu                                              |
| UUCP : [seismo,allegra,rlgvax]!umcp-cs!eneevax!iarocci                      |

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

Date:     Tue, 23 Jun 87 12:52 EST
From:     Matt Kimmel 
To:       Info-Atari16@SCORE.STANFORD.EDU
Subject:  Curses
X-VMS-To: CSNET%"Info-Atari16@Score.Stanford.edu"

Is there a version of Curses available for the ST?  If so, could someone
mail it to me?  Please write me in advance so that I don't end up with
20 copies of Curses in my mailbox.  Thanks!

-Matt Kimmel

Bitnet: KIMMEL@UMAECS
CSNet: KIMMEL@ECS.UMASS.EDU
Internet: KIMMEL%ECS.UMASS.EDU@RELAY.CS.NET
UUCP: ...!seismo!UMAECS.BITNET!kimmel

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

Date: 17 Jun 87 01:08:25 GMT
From: ptsfa!hoptoad!academ!uhnix1!uhnix2!uace0@ames.arpa  (Univ ATARI Comp
 Enthusiasts)
Subject: HDSCAN, bummer man...
To: info-atari16@score.stanford.edu

I still couldn't get the new posting to work correctly.  It exits arc saying
that there is a CRC error.  Perhaps the poster can send me a direct copy, or
perhaps not arc the file before uuencoding, or uuencode on the ST (preferred)
then send it on the net.  The file I have this time is the same size as the old
one, and spits out the same error.
I am of course referring to HDSCAN 1.3

- Mike
--
>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<      UACE
+  A Smith & Wesson beats a four of a kind!   +      uhnix2!uace0

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

Date: Wed, 24 Jun 87 11:14:08 EDT
From: Michael Fischer 
Subject: Re: How can you send a BREAK?
To: info-atari16@score.stanford.edu
In-Reply-To: , 24 Jun 87 03:20:17 GMT

johng@iscuva.UUCP (John Gardner) writes:
> The Atari developer's kit includes a function called Rsconf ...

This is an XBIOS routine built into TOS and not a part of the developer's kit.
It can be called from any language that provides access to the system
 primitives.

--Mike Fischer  

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

Date: Wed, 24 Jun 87 10:59:37 EDT
From: Michael Fischer 
Subject: Re: BIOS re-entrancy
To: info-atari16@score.stanford.edu
In-Reply-To: , 23 Jun 87 18:16:36 GMT

    Anyone out there have any experience with making BIOS, XBIOS, and/or GEMDOS
    calls recursively?

I've called a BIOS routine successfully from inside an RWABS handler, but I've
never been able to call a GEMDOS routine from there, presumably because
GEMDOS ==> RWABS ==> GEMDOS results in a recursive call on GEMDOS.  I'd
like to know how.

    I'm writing a multi-tasking kernel, and trying to find
    a safe way to allow multiple processes access to operating system functions
    My understanding is that upon entry to the BIOS trap routines, registers
    are saved in savptr ($4a2).  However, the default save area contains enough
    room for only three levels of re-entrancy.  Can this situation be resolved
    simply by allocating a larger area of memory and setting savptr to point to
    it?

Yes, I think so, but I'm not convinced that that is the only problem.  I tried
expanding the save area once and the recursive call still crashed.  Of course,
maybe I didn't do it correctly...

    Also, does anyone know if any conflics may arise if a process were preempte
    in the middle of the BIOS, only to have another process make a BIOS call,
    possibly the same one that was interrupted?  The same question goes for the
    XBIOS and GEMDOS.  Thanks in advance for any help you can offer.

Interrupting a BIOS routine at an arbitrary point seems very unlikely
to work, The BIOS manipulates hardware control registers, then waits
for the actions to complete.  Interrupting in the middle would be
disasterous.  For example, if you interrputed a disk read between
the seek and the actual I/O operation and then did another read,
when you came back to the first one the head would be in the wrong
place.  To write a good multi-taksing kernel, you should rewrite
the BIOS to put the current task in an I/O wait state when I/O has
been initiated and then go back to the process scheduler to see
if another task can be run.  Completion of the I/O would then be
detected by an interrput rather than by busy-wait loops as in the
current BIOS.  The BIOS itself would then have to worry about how much
concurrency to permit and how to schedule multiple requests.  Short
of a complete rewrite, your best bet is probably to set a lock when
the BIOS is entered and to make sure not to switch tasks while the
lock is set.  The same thing will probably also be needed for calls
to GEMDOS, XBIOS, and perhaps also VDI and AES or at least the line A
graphics routines.

Then there is the memory fragmentation problem.  While you can write
your own memory manager, TOS will continue to use its own Malloc,
unless of course you *replace* the GEMDOS version with your own
and TOS is clean enough to always go through the trap vector when
calling GEMDOS functions.

Doing a multi-tasking kernel right is a big job.  Modifying a system
like TOS to make it multitasking is perhaps even harder than starting
from scratch, especially without access to the sources.  Good luck!

--Mike Fischer
  

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

Date: 24 Jun 87 03:20:17 GMT
From: uunet!iscuva!johng@seismo.css.gov  (John Gardner)
Subject: Re: How can you send a BREAK?
To: info-atari16@score.stanford.edu

In article <8706230308.AA26681@ucbvax.Berkeley.EDU> SYSTEM@UVPHYS.BITNET (NAME
 NIK ZAPANTIS) writes:
>  I would like to be able to send a BREAK to my RS-232 port from my program,
>just like UNITERM does with the ALT L or ALT B key.
>
>Thank you in advance,
>
>Nik Zapantis


To send the break signal, you need to program the 68901's tsr register. If
you put in a hex 0x89 the RS232 port will now send the break signal. Write
tsr with a hex 0x81 to turn it off.

The Atari developer's kit includes a function called Rsconf and basically
if you do something like Rsconf(-1, -1, -1, -1, 0x89, -1); you turn on
break. The -1's tell this function not to change the parameter at that
location. The parameters appear like this,
  Rsconf(speed, flowctl, ucr, rsr, tsr, scr);

Later, JAG

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

Date: Wed, 24 Jun 87 10:59:52 EDT
From: Michael Fischer 
Subject: Re: MFP problems
To: info-atari16@score.stanford.edu
In-Reply-To: , 24 Jun 87 02:04:25 GMT

    I'm still trying to install my own timer, and stumbled over the
    'fact', that the system's timer ('C') is said to generate a 200hz-
    interrupt... As far as I can see it's installing procedure uses a
    division factor of 64 (decimal, I suppose), and a counter that's
    set to 192 (C0 hex). IF I believe my documentation which says that
    the MFP 68901 uses a 4Mhz - clock cycle, then what? All the divisions
    mentioned above wouldn't at all generate a 200hz-interrupt. Am I
    wrong? What I need are the data and control values for getting a
    one-millisecond resolution.
    Any suggestions?
    Yours in advance, Klaus.

A 200hz interrupt has a 5 millisecond period.  The numbers you give
are not far off, if the '64' is interpreted as a hex number (= 100 decimal),
for then the timer would interrupt every 100*192 clock cycles, or every
19.2/4 = 4.8 milliseconds.

--Mike Fischer
  Arpanet: 
  Bitnet:  

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

Date: 23 Jun 87 13:53:00 GMT
From: cca!mirror!datacube!ftw@husc6.harvard.edu
Subject: more DCFORMAT problems
To: info-atari16@score.stanford.edu

The patch to dcformat.uue that was posted on June 18 by pmt@sbcs.uucp does
not seem to fix the problem I have with the archive.  I don't appear to have
any truncated lines; my copy of ARC claims that both dcformat.prg and
dcformat.rsc have bad checksums.  Anyone else have this problem with
the dcformat archive? (Moshe, is this the trouble you had?)


            Farrell

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

Date: 24 Jun 87 04:04:36 GMT
From: necntc!adelie!mirror!xanth!src@husc6.harvard.edu  (Scott R. Chilcote)
Subject: Re: Mega-ST release date?
To: info-atari16@score.stanford.edu

In article <762@atari.UUCP> neil@atari.UUCP (Neil Harris) writes:
>
> I don't know how these stories get out.
>
>--->Neil Harris, Director of Marketing Communications, Atari Corporation

    Perhaps it has something to do with the fact that only one of every
forty or so messages directed at Atari induces a response, and in this
this case you ignored the principal question in order to sling mud at an
admittedly misinformed reply.

    My information came directly from an Atari distributor who merchandises
a local retail store where I work.  If and when you choose to provide
your distributors with correct information, then as an Atari salesperson I
will accurately relay it to the public.

    Your tolerance for lesser mortals is humbly appreciated.

-------------------------------------------------------------------------------
Disclaimer:  I said it, so I'll take the rap!
-------------------------------------------------------------------------------
src@xanth.UUCP                                                  Scott Chilcote

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

Date: 17 Jun 87 12:25:27 GMT
From: ptsfa!hoptoad!academ!killer!blaise@ames.arpa  (Walter Wilinsky)
Subject: Where can I get the latest version of UNITERM?
To: info-atari16@score.stanford.edu

Could some kind soul please post or E-mail me the latest version of
UNITERM, I think it is version 1.7b. I need kermit which is not in
the version of UNITERM that I have (1.6).

Thanks in Advance
Wally Wilinsky
{ihnp4,pollux,dj3b1}!killer!blaise


      ni

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

Date: 21 Jun 87 11:06:16 GMT
From: mcvax!unido!laura!@@seismo.css.gov  (Andreas Toenne)
Subject: Re: MWC problem with 'long int'
To: info-atari16@score.stanford.edu

Hi,

has anyone collected all known bugs in MWC 2.0 ??
I am quite happy with the old version (and I know all its bugs :-)
but 2.0 is probably better.

    Andreas Toenne
    U of Dortmund, IRB
    West Germany

    at@unido.uucp
    at@unido.bitnet
D

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

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