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

Text File | 1997-04-16 | 22KB | 473 lines

=========================================================================

INFO-ATARI16 Digest         Tue, 19 Dec 89       Volume 89 : Issue  829

Today's Topics:
                         Commandline length?
                     Did I come from the desktop?
                         ICD driver software
                        Line F again (2 msgs)
                           Scanners for ST
           seeking midi sequencer/librarian software advice
                  USENET -> GEnie uplink now working
----------------------------------------------------------------------

Date: 19 Dec 89 09:18:29 GMT
From: mcsun!hp4nl!nikhefh![e-mail]  (Jos Vermaseren)
Subject: Commandline length?
Message-ID: <[e-mail]>

In article <[e-mail]>, [e-mail] (Joep Mathijssen) writes:
> Using Gulam and make, I want to link a program using TURBO-C.
> But there are so much .O-files that must be linked, that my list of
>

Its in the manual

Merry Christmas
Jos Vermaseren

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

Date: Tue, 19 Dec 89 11:31:40 SET
From: [e-mail]
Subject: Did I come from the desktop?

Hello all,

[I'm sorry that I reply only now to this message, but the recent amount of
 Info-Atari16 Digests gave me a hard time catching up.]

In Info-Atari16 #705, John M Williams ([e-mail]) said
in reference to my earlier posting:

>A recent article suggested three possible methods by which a process  could
>determine whether it was being run from the desktop or from a shell. I'd like
>to suggest another method which works for me. I don't suggest that it is
>foolproof however. It simply requires moving the basepage ptr up to its parent
>until it becomes null. If this requires three iterations then the program
>is running from the desktop. Any more and it is running from a shell.
[Code example omitted]

In Digest #734, nis!pwcs!stag![e-mail] (Dale Schumacher)
replies:

>Alright, I guess it's time to post this message again (is this the 3rd
>time now?).  The quoted message is mostly correct, but incomplete.  The
>situation is slightly different if you're in the /AUTO/ folder programs
>at boot-time.  I check for the text-base pointer pointing to ROM, as
>recommended by Allan Pratt @ Atari.  The following code (which, like John's
>code, assumes access to a basepage pointer) uses this "approved" method.
>I've also included a copy of <basepage.h> from dLibs for those who don't
>know the layout of the basepage structure.
[Code example omitted]

Finally, in Digest #740, portal!atari![e-mail] (Allan Pratt) joins
the discussion:

>[e-mail] (Dale Schumacher) writes:
>>I check for the text-base pointer pointing to ROM, as
>>recommended by Allan Pratt @ Atari.
>
>Yeah, well, that was before there were RAM TOSes running around. Caveat
>hacker.  No RAM TOS is supported by Atari (at this time) and most are
>illegal copies, making their users pirates, so it's not that great a
>hardship.

  Thank you all for replying.  One of the things I wanted to find out by posting
my original code samples was whether one can rely on the 'somewhat-documented'
facts one has to exploit to find out where the process came from.

   Is the three-times-iteration method approved?  Will it hold true in later
TOS revisions?  Same goes for my method, checking the os_magic pointer.  I took
pains to ensure that the code samples I sent out also work with TOS 1.6 (STE)
and TOS 3.0 (TT).  Dales version has the advantage of also detecting that the
program was started from the auto folder.  My version also works with RAM and
STE/TT TOSes.

   Maybe Allan can tell us if one or the other method will be supported by
Atari, or if there will be some kind of system variable that tells the current
process if his parent is a shell or the desktop.  Such a variable would also
make life easier for programs like Neodesk etc.

   A side note to Allan:  Take the ROM TOS 1.4, disassemble it, make it fully
relocatable, write a little RAM loader, and you have a RAM TOS.  Does that make
me a pirate???   [BTW: Such a RAM TOS is great for testing out little OS tweaks
and patches ... :-)]


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

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

Date: Tue, 19 Dec 89 11:35:01 SET
From: [e-mail]
Subject: ICD driver software

Hello all,

In Info-Atari16 Digest, Ray Wallace ([e-mail]) replied to
my query:

>In article <[e-mail]>, [e-mail]
>writes...
>>  BUT:  The included ICDFMT.DAT file says Version 3.00 and lists only "d" type
>>entries, ie. only disk drives, no more controllers, such as for my Maxtor.
>
>The following is from ICD's READ.ME file -
[Excerpt omitted]

   Thanks, Ray, for pointing this out.  The ARCUTIL program for VM/CMS wouldn't
even show the READ.ME file in the archive, let alone extract it, and I jumped to
conclusions.

>Sounds like you can't use ICDs V4 software with anything but OMTI, ADAPTEC,
>and embedded SCSI drives.

  What else is there?  Has anyone ever used SASI?  Also, can anyone recommend a
good, cheap embedded-SCSI tape streamer that can be hooked up to an ICD adapter?


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

Date: Tue, 19 Dec 89 11:32:18 SET
From: [e-mail]
Subject: Line F again

Hello all,

[I'm sorry that I reply only now to this message, but the recent amount of
 Info-Atari16 Digests gave me a hard time catching up.]

In Info-Atari16 #705, John M Williams ([e-mail]) said
in reference to my earlier posting:

>A recent article suggested three possible methods by which a process  could
>determine whether it was being run from the desktop or from a shell. I'd like
>to suggest another method which works for me. I don't suggest that it is
>foolproof however. It simply requires moving the basepage ptr up to its parent
>until it becomes null. If this requires three iterations then the program
>is running from the desktop. Any more and it is running from a shell.
[Code example omitted]

In Digest #734, nis!pwcs!stag![e-mail] (Dale Schumacher)
replies:

>Alright, I guess it's time to post this message again (is this the 3rd
>time now?).  The quoted message is mostly correct, but incomplete.  The
>situation is slightly different if you're in the /AUTO/ folder programs
>at boot-time.  I check for the text-base pointer pointing to ROM, as
>recommended by Allan Pratt @ Atari.  The following code (which, like John's
>code, assumes access to a basepage pointer) uses this "approved" method.
>I've also included a copy of <basepage.h> from dLibs for those who don't
>know the layout of the basepage structure.
[Code example omitted]

Finally, in Digest #740, portal!atari![e-mail] (Allan Pratt) joins
the discussion:

>[e-mail] (Dale Schumacher) writes:
>>I check for the text-base pointer pointing to ROM, as
>>recommended by Allan Pratt @ Atari.
>
>Yeah, well, that was before there were RAM TOSes running around. Caveat
>hacker.  No RAM TOS is supported by Atari (at this time) and most are
>illegal copies, making their users pirates, so it's not that great a
>hardship.

  Thank you all for replying.  One of the things I wanted to find out by posting
my original code samples was whether one can rely on the 'somewhat-documented'
facts one has to exploit to find out where the process came from.

   Is the three-times-iteration method approved?  Will it hold true in later
TOS revisions?  Same goes for my method, checking the os_magic pointer.  I took
pains to ensure that the code samples I sent out also work with TOS 1.6 (STE)
and TOS 3.0 (TT).  Dales version has the advantage of also detecting that the
program was started from the auto folder.  My version also works with RAM and
STE/TT TOSes.

   Maybe Allan can tell us if one or the other method will be supported by
Atari, or if there will be some kind of system variable that tells the current
process if his parent is a shell or the desktop.  Such a variable would also
make life easier for programs like Neodesk etc.

   A side note to Allan:  Take the ROM TOS 1.4, disassemble it, make it fully
relocatable, write a little RAM loader, and you have a RAM TOS.  Does that make
me a pirate???   [BTW: Such a RAM TOS is great for testing out little OS tweaks
and patches ... :-)]


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

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

Date: Tue, 19 Dec 89 11:33:58 SET
From: [e-mail]
Subject: Line F again

(Sorry for the last posting, correct subject, wrong file ...)

Hello all,

[I'm sorry that I reply only now to this message, but the recent amount of
 Info-Atari16 Digests gave me a hard time catching up.]

In Info-Atari16 Digest #714, fox!portal!atari![e-mail] (Ken Badertscher)
said:

> As an aside, I should point out that our VDI guy has put a lot of work
>into the blit code for the TT, and it's pretty phenomenal _without_
>hardware assist.  One other thing that will give a noticeable improvement
>is the lack of Line F compression in STE and TT ROMs.  The Line F
>compression adds a bit of overhead to AES operations, and desktop/window/
>dialog operations are noticeably sped up when the compression is gone.

Yes, Ken is right.  QuickIndex reports a GEM speed increase of 9% when those
blasted Line Fs are removed from the current TOS 1.4 version.


In Info-Atari16 Digest #714, mcsun!hp4nl!ruuinf![e-mail]
(Nico Verwer) asks:

> In article <[e-mail]>, [e-mail] (Ken Badertscher) writes:
>> [e-mail] (Brian Walker) writes:
>> | What did you do with the line F compression?
>> It's gone.  Because of the larger ROM space in the STE, (and TT), the line F
>> compression is no longer required to make the TOS ROM image fit.  With the
>> exception overhead gone, the AES moves along noticeably faster, too.
>
>Why didn't Atari use large ROMs for the 1040 in the first place? Using
>line-F makes upgrading to a 68020 and a floating-point coprocessor really
>difficult. Now it also appears that exception overhead seriously affects
>AES-speed 8-( !
>Were ROMs so expensive at the time that Atari felt they should decrease
>ROM-size at any cost, or is this a problem of the MMU, or what?
>Will there ever be a chance for 1040 owners to use a larger ROM-set,
>thus being able to painlessly use a 68020 running standard TOS? Is it
>possible to make a hack and solder the extra ROMs in? Or would you have
>to replace the whole motherboard with an STE-board (which has the same
>case anyway)?

  Note that the ROM image actually becomes SMALLER if you take out the Line F
codes.  Yes, that's right, the Line F handler and the jump table use up MORE
memory than they save.  So it's not a question of too small ROMs, but of
inadequate programming.  With a little work, you can make TOS 1.4 cooperate
quite nicely with an 68020/030.  The biggest obstacle is the way the timing
routines (for things like floppy delay etc) are implemented.  You have to
recalculate all loop counters and the like manually.  The cleanest way would
be to use a timer, and if you look closely at the TT TOS 3.0, you'll see that
the TT HAS AN EXTRA 68901 that is used for exactly that purpose!!!!

Finally, in Digest #742, att!chinet![e-mail] (Stephen Jacobs)
wonders:

>In article <[e-mail]> [e-mail] (Ken Badertscher) writes:
>>[e-mail] (Steve Rehrauer) writes:
>>| I know what you mean by "Line F", but what's the "compression" refer to re:
>>| ST ROMs?  (Usually I'm only this dense on Mondays & national holidays...)
>>
>>The line F compression I refer to is a method we used in ST ROM which
>>basically replaces common operations with line F instructions.  The
>>line F handler is able, by decoding the $Fxxx instruction, to determine
>>what operation to perform.  The handler then dispatches the exception
>>to the appropriate OS routine.
>
>This brings up the question of what the ROM code does instead. Have all the
>little line F routines been made into subroutines, with more-or-less ordinary
>subroutine linkages (I don't know the exact count, but there are A LOT of
>line F routines)?  Are the routines invoked by subroutine calls to a
>dispatcher (a la GEMDOS)?  Has the code been brought inline?

  There's a lot of Line F instructions in a relatively small part of the ROM,
the AES.  They fall in two groups:  'fast' subroutine calls, and a "save-some-
registers-unlink-stack-and-return" group.  The only difference is the registers
that are to be restored.  The handler looks at the Line F code, checks which
group it belongs to (the LSB determines that), branches accordingly.  If it's
a subroutine, the jump address is taken from a table.  If it's a restore-
register instruction, the register mask is decoded, and the requested action is
performed.  You can bet that this takes more time!!  I don't want to post code
samples since Atari probably won't like it.

  Unfortunately, the TOS14FIX.PRG that repairs those two TOS 1.4 bugs installs
a new Line F trap.  The solution is to fix the bugs within TOS while you're at
it anyway. :-)

  Enough operatingsystemology for today.  (Or is it TOSology? :-)


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

Date: Tue, 19 Dec 89 05:33 EDT
From: [e-mail]
Subject: Scanners for ST

I'm interested in getting a scanner for my ST.
The only one I know is made by Migraph (Federal Way, WA) and comes with
software that converts Easidraw to Degas ("Touch Up").

Scanner + software sell for about $490.

I'd be interested in compiling a fairly complete list of the available
products available either in the US or in Europe, so any answer is
welcome. If can include price, availability and popularity, even better.

I'm totally unaware of what exists out there, what features to expect,
what price to expect and... if this topic has been discussed on the
list recently (I vaguely remember seeing "Scanner" in the list of
topics of various digests in the past few months but as I wasn't in-
terested at the time, you know...)

Any help mucho appreciated.

Jacob

[e-mail]
[e-mail]

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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

Date: 17 Dec 89 21:54:39 GMT
From: [e-mail]  (Pivnik)
Subject: seeking midi sequencer/librarian software advice
Message-ID: <[e-mail]>

I am new to synthesizers and on a low budget and am looking
for recommendations for sequencer/ patch librarian software.

I don't own an ST yet and I was wondering if anyone had any comments
on the relative merits on the ST versus the 8 bit atari, Commodore 64/128
for setting up an electronic studio.  I would probably dedicate the
computer for this purpose.  Cost and minimizing hassles are the main
requirements.

Reply to me if you want and if I get a lot of responses, I'll summarize and
post to the relevent newsgroups.

Thanks,
Eric Pivnik
-----------------------------------------------------------
Eric C. Pivnik                  Nothing means everything.
[e-mail]            Some things mean nothing,
MITRE Corporation               But not all the time.
-----------------------------------------------------------

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

Date: 19 Dec 89 06:00:28 GMT
From: well![e-mail]  (David Small)
Subject: USENET -> GEnie uplink now working
Message-ID: <[e-mail]>

        It's time to announce that there is now a working uplink
from USENET to GEnie. Each note posted into comp.sys.atari.st is sorted
by topic, and uploaded to "Category 10" of the Gadgets RT on GEnie.
The link's been up around two weeks, and there's about 2,000 messages posted
there (we kept a backlog to build a "base").

        The link is one way. GEnie makes its living selling information
bases to the public, and doesn't want them downloaded and distributed freely.
There's something about an "anthology copyright" that I don't want to have
trouble with, either. I just want to get the maximum freedom of information
exchange possible between these networks; GEnie could *badly* use the
technical and international information posted here routinely.

        I wanted to let you know to prevent invading anyone's privacy.
GEnie acts just like another (receive-only) site, but many people here are on
GEnie as well. I also wanted to advise Atari employees of this. If someone
has a real need not to have their notes forwarded to GEnie, I will be happy
to put a "filter" on to prevent it by request; just email me at this net
address, okay? I don't want to cause anyone problems.

        On the uplink, we scan the "subject" field of the USENET note, and
use that to determine what "topic" the file goes into as a GEnie note.
For instance, this enables us to group all Spectre notes together, all
hard disk notes, all TT notes, and whatnot.

        While I see little possibility of GEnie notes being downlinked into
USENET (and it's just as well; the GEnie load might overwhelm USENET, and
anyway the cultures are different betwen the nets), I do see a very good
possibility of setting up a 2-way mail link, run through here. I am *very*
open to suggestions on this; I'm no Unix guru by any means.

        What I envision, and this would not take too much doing, is having
people send notes to the Gadgets UNIX machine
(at net address   !hplabs!boulder.edu!tcr!gadgets!genie), with some sort
of TO: (genie mail address). Going the other way,probably there would be
some sort of GEnie ID to send mail to (why not USENET?), and again,
an addressing line in the note -- TO: hplabs!well!dsmall. I believe I could
handle notes that "bounce back" or flop.

        Overall, I have found GEnie management to be quite positive to the
idea of a link, I think there's real hope for 2-way mail. Hacking the link
together took some doing; the primary problem is error-tolerant modem
communications.

        Anyway, I would like to solicit suggestions for how to implement mail
(just mail to this address), make sure that if anyone minds having their
replies uplinked, they let me know, and in general announce the net
connection.

        It seems to me like a benefit for everyone involved, especially
if/when 2-waymail gets going.

        Systems like Compuserve and BIX could also fairly easily be done,
now that the methodology is hacked through; also, other areas on GEnie are
expressing great interest in having a USENET uplink. Basically, folks,
USENET is perceived as the place where the people who know what they're
doing post notes.

        Again, GEnie is a read-only site. I'm not dumping the GEnie message
load onto USENET; mail is presently not up, but has a very good chance.

        Finally, yes, Gadgets does make a percentage of connect time people
spend in it on GEnie. However, before anyone starts talking about how we're
doing this to basically make money, let me point out that since the Gadgets
RT started, *all* profits made from GEnie have been sent *directly* outside
the company to the volunteers who maintain the RT, and who are underpaid for
their work, in my opinion. I personally am making nothing on this.

        Why do it? Because a long time ago, on the CERL site on PLATO, a
person named Sherwin Gooch, ex-PLATO, ex-Atari, and now with Apple,
introduced me to the hacker ethic and freedom of information exchange as
its primary goal. (No, not illegal exchange, you know what I mean). People
on GEnie, for instance, were desperate for TT news; it was available here
in abundance.

        If anyone feels this is wrong, I'll be more than happy to listen and
if convinced, drop the link. Likewise, if you think it's an alright idea,
don't care, or whatever, let me know.

        My WELL address is : !hplabs!well!dsmall,or [e-mail].
I don't always get on as much as I should.

        My UNIX machine downstairs, where the notes vector through to GEnie,
is !hplabs!boulder.edu!tcr!gadgets  [!dsmall if you want me]. I'm such a
net neophyte that I don't know *if* it's possible to do a dsmall@something for
my address, nor how. Heck, I don't know what FTP *is* or how to do it -- but
if someone wants to drop me email, or just a pointer on how to do it, I
would be grateful.

        Well, enough said. I hope this leads to good things -- GEnie users
getting good information on time, for instance.

        -- many thanks, Dave Small / Gadgets by Small

p.s. You realize I don't yet understand how to handle "prepared file to
include?" It keeps showing up at the top of my notes. Oh, for the time to
do more...

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

End of INFO-ATARI16 Digest V89 Issue #829
*****************************************