🚀 go-pugleaf

--------------- A copy of your rejected mail message follows ---------------

Received: by CANADA01 (Mailer X1.24) id 3167; Mon, 11 Jan 88 20:43:44 EDT
Date:     Mon, 11 Jan 88 13:46:29 PST
Reply-To: Info-Atari16@Score.Stanford.edu
Sender:   INFO-A16@CANADA01
From:     Info-Atari16@Score.Stanford.EDU
Subject:  Info-Atari16 Digest V88 #12
To:       PETCHER@GW.SCRI.FSU.EDU,
          DUBRAVK@FSU

Info-Atari16 Digest   Monday, January 11, 1988   Volume 88 : Issue 12

This weeks Editor: Bill Westfield

Today's Topics:

                Re: Exactly what IS in a reg dev kit?
                 questions Re: Hard drives for the ST
                         Re: 40 folder limit
                  Print Master icons -- what is PD?
            Re: Zoomracks (i.e. Hypercard's predecessor?)
                        Re: speeding floppies?

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

Date: 1 Jan 88 13:11:49 GMT
From: ihnp4!alberta!auvax!rwa@ucbvax.Berkeley.EDU  (Ross Alexander)
Subject: Re: Exactly what IS in a reg dev kit?
To: info-atari16@score.stanford.edu

In article <4462@watdragon.waterloo.edu>, rfpfeifle@violet.waterloo.edu (Ron
 Pfeifle) writes:
> I've seen alot of flames about the registered developer kits.  But I don't
> even really know what's in them.
> Would someone out there who knows please enlighten me (us) as what exactly
> are the contents of a "registered developer's kit"?
> (Just the facts, ma'am)
> Ron


OK.  We (Athabasca University Computing Services) got our kit sometime
in September or October of 1986.  I cannot speak for later Developer's
Kits than that.  Honestly, I can only say that it was better than the
doc's I got from DRI when I first got CP/M - you old CP/M hackers out
there can go from there ;-)  For the rest of you, I can only say that
reading and using the docs supplied was a little like playing Adventure
- except that it's a lot slower and more frustrating.  If some kind
soul hadn't posted the "Proffesional GEM" (by Tim Oren) stuff to the
net, and if I hadn't gone out and bought the MWC package, I don't think
we would have ever done anything interesting with our 1040's.  Sigh.


To start, there is a very large stack of paper, perhaps 5 or so inches
thick (8.5" x 11" paper, double sided xerographic copies).  I have it
in three two-inch ring binders, and they are _full_.  The quality of
the reproduction is a little disappointing, but readable; the only
frustration is that occasionally the copies are skewed so that some
text falls off the edge of the page.  This is not too much of a problem.

Volume 1: (about 580 pages)

    a nondisclosure agreement

    some waffle about 'please write portable code in case we decide
        to fool around with the hardware specs'.

    some blank SPR (bugreport) forms.  If I had used these things,
        I would have needed 20 times as many as are supplied.

    keycode table errata list

    writeup on the ACSI buss (interface & protocol) [hard disk port]
    + listing of (23Jul85) hard disk driver as example of ACSI stuff.

    Introduction to Gem Programming (DRI): this is the IBM version,
        it does not exactly conform to the supplied software.
        Pretty obscure in places, but valuable to the initiated.

    GEM Programmer's Guide - Vol 1, VDI (DRI): a description of the
        low-level graphics primitives in _excruciating_ detail,
        plus a little bit about the non-existant GDOS, and some
        very useful info on font files.  This is a reference
        work, very few examples of actual use.  It is pretty
        complete, but again more useful to the initiated than
        the novice.

    GEM Programmer's Guide - Vol 2, AES (DRI): a description of the
        higher level stuff in GEM, such as the window and event
        libraries, menus, manipulation of icons, et c., et c.
        Again, a reference document.  Lots of info if you know
        what you're looking for, but not a tutorial at all.

Volume 2: (about 400 pages)

    GEM DOS 1.0 specs (DRI): calling conventions & stuff.
        Readable, useful.  Includes C bindings.

    Hitchhiker's Guide to the BIOS: for a change, a really pleasant
        piece of doc on the BIOS - has a few errors, and can get
        a little self-indulgent (and obscure), but still a solid
        source of info on the low-level stuff.  Lots of neat
        stuff on how booting is performed, & c.

    Line-A Technical Reference Manual:  detailed discussion of the
        bit blt code, parameters, & how to call it.  rather
        confusing organization, and again the attempts at humour
        can be irritating on the 500th reading.  Not for the
        faint of heart.

    Intelligent Keyboard (IKBD) Protocol:  really good writeup of
        how the mouse, joystick, and keyboard work.  I wish _all_
        the docs were this good.

    BIOS listing:  a listing of the ST's BIOS.  I sure wish this
        had been the listing output by the assembler, as it is
        there is no symbol table or hex listing, so it's a pain
        to follow the code around.  But handy when you have to
        know _exactly_ how something works.

Volume 3: (about 600 pages)

    DRI 'C' Language Programming Guide for CP/M 68K: this is the doc
        for the (in)famous Alcyon C.  Ugh, blech, ack phfft!  I
        cannot say anything good about the thing.

    DRI CP/M 68K Operating System Programmer's Guide:  this is the most
        useless thing you could imagine.  It has nothing to do with
        TOS at all.  The only good thing is that it explains a few
        things about SID, the linker, and the assembler.  Otherwise
        it only confuses anyone who doesn't realize it has nothing
        to do with using the ST.

    Kermit User's Guide, Fourth Edition:  I never used this & have
        no intention of ever using it.  We have ZMODEM :-). But
        it looks well enough written.

    Engineering Hardware Specification of the Atari ST Computer System:
        A good quick overview of the ST.  Terse and pithy.

    Western Digital WD1770/1772 5-1/4" Floppy Disk Controller/Formatter:
        This is a typical engineering component data-book sort
        of description; very, very complete and includes
        examples of anything you would need to know, and a lot
        of stuff you don't need to know (like pinouts).  Aimed
        at engineers.

    MIDI Specification 1.0:  Now this is a real prize.  It's
        exactly one page long, and says 'for more information,
        please contact...' and gives the address of the IMA.
        Really!  Somebody was working overtime on this, I'm sure.

    (Untitled): long, unreadable & boring description of the STC504
        and SMM804 printers.  Typical Japanese-style (no racial
        slurs intended) printer manual organization of jillions
        of tables, everything cross referenced to something on
        another page.  NO examples.

    (Untitled): etch masks and schematics for building ROM
        cartridges, plus mechanical drawing of connectors.  OK,
        I guess; my ex-wife, who does this sort of thing for a
        living, wasn't very impressed. Me, I do software :-)

    United Technologies/Mostek MK68901 Multi-function Peripheral:
        Just like the WD1772 writeup.  More stuff than you ever
        wanted to know, or thought possible.

    Schematic Diagram:  a schematic for a 520ST.  two 14" x 11"
        sheets, hard to read, and not the best organization.
        Still, it's enough to figure out things like 'which bit
        in the 68901 do I fiddle to assert DTR on the serial
        port' and that sort of thing.


--

And that brings us to the end of the stack of paper.  In summary,
there's a whole lot of information here, but d*mned little guidance.
It really needs something like the "Proffesional GEM" series to get
the newcomer started - as it is you're so busy reading about every leaf
on every tree you have no idea at all what the forest looks like ;-) !

Also, there's no master index.  Some of the separate documents are
indexed, but you have to know which one to look in first, which means
plowing through all 1600 pages at least once.  You can bet that takes
some time...

"And now, Ladees and Gennelmun, in the center ring!  It boots, and who
knows, maybe you can even do developement with it!  (I sure had a h*ll
of a time, though.)  The amaaazing Atari Developer's Software Toolkit!"
This sorry collection comes on 5 single-sided flops.  I hereby list
them:

Flop 1 - C Compiler, Assembler, and .H files

    The dreaded Alcyon C compiler.  At the risk of redundancy, let
me restate my earlier comments:  Ack phfft!!  The poorest commercial C
compiler you ever met.  Generates assembly output, useful for deciding
what kind of bugs it has introduced into your code this time around...
Slow, buggy, and not even full K&R much less ANSI.  Daryl (the other
hacker in this shop) struggled with it for about 3 months and even got
some stuff to work :-) but I wouldn't touch it with a barge pole.

Flop 2 - Linker, Libraries, Thing to make Linker output executable

    An amazingly slow linker.  Libraries with some *nasty* bugs in
them.  And a hack to get CP/M 68K executables to run under TOS.  Gag me
with a spoon...

Flop 3 - Utilities: Debugger, Kermit, and some C runtime environment asm code

    I sort of like SID, probably because I used it under CP/M so
much.  We never did use the supplied KERMIT.  The other stuff was ok,
but pretty ho-hum; no RAMdisk or anything remotely useful like that.
The APSKEL.C (application skeleton - sort of a 'hello world' for GEM)
was a good thing, although I think that programmer should be shot; his
style makes my teeth ache.

Flop 4 - Icon Editors and Resource Construction Set, plus Doodle C source

    Again, having source code as an example is a really fine thing.
The only problem is that since it's designed to compile under Alcyon,
you spend most of your time wondering "now why is he doing that?"
instead of seeing "oh, so that's how you do <arbitrary GEMish thing>".
The RCS is useful and pretty completely undocumented (there are a few
hints in 'Introduction to GEM Programming' (Vol 1), but nothing like a
real write up anywhere).  To an experienced GEM hacker, of course, it's
all pretty obvious.  Took me a long time.  Of the two supplied icon
editors, only one is useful (the other is just too primitive), and even
it has a few annoying bugs - I could never get it to save both an icon
and it's mask in one file...  but maybe that's me & not it.  Bets,
anyone?

Flop 5 - Emacs, various source and a doc file

    Well, lessee - Doodle (again), a demo of how to use the forms
library, a copy of a very early Mark Williams Co. emacs, and a tutorial
doc on how to read/write floppies by directly twiddling the WD1772
(which, by the way, appears in printed form in the pile of paper...).
The emacs I considered a great thing, since I use it on Un*x all the
time (I'm in it now, as a matter of fact).  The rest is nice to have,
although my criticism of impenetrable Alcyon style still holds.  To bad
they didn't give source for the emacs, though.

--

And that's it.  There's no shell supplied, instead they have an
incredibly klugey 'batch processor' to invoke the various & sundry
programmes required to do anything interesting like, say, getting a
compile-and-link done.  No RAMdisk to help speed things up.  The real
prizes are the ICED icon editor, the RCS, and the emacs.  The Alcyon C
compiler, the assembler, linker, and libraries are a disaster.  The
debugger is ok but primitive.  The source code is good but obscure
because of the Alcyon bug-workarounds (or lack-of-feature workarounds).

Now, having waded through all this p*ssing and moaning, what would I
recommend instead?  For a start, go out and get a copy of the Mark
Williams C package.  Not too many bugs, nice Un*x compatability
libraries, ok shell & tools (you know, stuff like egrep and tail and
wc), source for an emacs, pretty good (but not quite complete) GEM and
VDI docs, and a RAMdisk.  In all, not a bad package deal.  I have
hacked on it pretty heavily and like it well enough.  Secondly, get a
subscription to START Magazine (with the disks!).  Thirdly, get ahold
of the Proffesional GEM series by Tim Oren - this is a must have.
I don't know about a Resource Construction Set, though; we're using DRI
RCS 2.0, but maybe you can get a copy of the KUMA version.  And I'm
still looking for a really good icon editor.  I also recommend GULAM,
and the ZMODEM that was posted about 6 months ago.  Or Uniterm - that's
a good solid piece of freeware too.

Short list of things to stay away from:  any of the bloody useless
Abacus Software books (except maybe vol 13, "ST Disk Drives", which is
almost useful).  These things are just copies of the DRI stuff, with
gratuitous errors added to avoid copyright infringement :-(

Any other suggestions from the other hackers out there?  I want to get
down off this soapbox, my feet are tired :-)

--
Ross Alexander,
Athabasca University,
alberta!auvax!rwa

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

Date: 1 Jan 88 19:52:56 GMT
From: braner@tcgould.tn.cornell.edu  (braner)
Subject: questions Re: Hard drives for the ST
To: info-atari16@score.stanford.edu

[]

I wonder: is the 18 inch limit on the length of the cable connecting
the ST to the Atari SH204 hard disk (stated in the user manual) the
real technical limit?  Would be very nice to have a, say, 3 feet cable.
(I hate fan and motor noise.)

Does anybody have a disassembly of AHDI.PRG?  I have a strange bug, and
suspect that AHDI.PRG fiddles with high RAM.  Could that be?  Is there
an alternative driver program for the Atari HD?

- Moshe Braner

PS: how can I persuade PC-Ditto to read partitions D: and E: from inside
MS-DOS?  I am trying out PCD 3.0 on 1040ST, mono, SH204 HD, and _did_ put
"device=pc_dhd.sys" at top of config.sys.  "Dir d:" prints either garbage or
an empty list of files.  The PCD docs say that reformatting the HD is _not_
required (unless you want to autoboot MS-DOS from the HD, in which case you
must let MS-DOS reformat partition C:).  Partition C reads OK (and I did
not reformat it).

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

Date: 1 Jan 88 17:04:08 GMT
From: clyde!watmath!water!ljdickey@rutgers.edu  (Lee Dickey)
Subject: Re: 40 folder limit
To: info-atari16@score.stanford.edu

In article <575@pyuxe.UUCP> crc6@pyuxe.UUCP (C. Colbert) writes:
:See Atari Explorer Spring 87 (Vol 7 no. 2) page 27
:
:"Mike Schmall, Atari system programmer involved in upgrading the ST
:operating system, talked about how the new OS revision will affect Mega
:system performance:... In addition, we've made some changes that
:overcome natural limitaions of the original OS, such as the 40-folder
:limit."
:
:They also mention an upgrade to existing machines, adding blitters and
:new roms.
:
:Charles Colbert


My guess is that this is an oblique reference to the program FOLDRXXX.


--
 L. J. Dickey, Faculty of Mathematics, University of Waterloo.
 ljdickey@watmath.UUCP        UUCP: ...!uunet!watmath!ljdickey
 ljdickey%water@waterloo.edu    ljdickey@watdcs.BITNET
 ljdickey%water%waterloo.csnet@csnet-relay.ARPA

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

Date: 1 Jan 88 16:28:55 GMT
From: clyde!watmath!dalcs!silvert@rutgers.edu  (Bill Silvert)
Subject: Print Master icons -- what is PD?
To: info-atari16@score.stanford.edu

It is clear from recent mail that I have received that commercial
PrintMaster are getting mixed up with PD icons.  Since I run a BBS this
is something I have to be careful about, and I thought it might help to
identify the three commercial libraries that I am familiar with.  Here
is a list of the first 4 icons in the three library disks published by
Unison World.  If you have a library that begins with these icons, it is
probably pirated.

PrintMaster, usually called SLIB or STANDARD library:
    Christmas Tree, Menorah, Cake, Easter

Art Gallery I, usually called ULIB
    Santa, Snowflake, Star of David, Black Cat

Art Gallery II, usually called GALLERY2
    Snow Scene, Conductor, Crown of Thorns, I Forget

I don't have the commercial Fonts and Borders disk, so I can't comment
on what is PD in that area.

To tell the truth, the Art Gallery series is pretty crummy, and the PD
libraries are better.  I bought them cheap and still felt ripped off.
However, copyright is copyright.

--
Bill Silvert, Modelling/Statistics Group, Biological Sciences Branch
Bedford Institute of Oceanography, Dartmouth, NS, Canada B2Y 4A2
    UUCP: ...!{uunet,utai,watmath}!dalcs!biomel!bill
    CDN or BITNET: biomel@cs.dal.cdn

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

Date: 1 Jan 88 16:06:41 GMT
From: dayton!ems!nis!stag!trb@rutgers.edu  ( Todd Burkey )
Subject: Re: Zoomracks (i.e. Hypercard's predecessor?)
To: info-atari16@score.stanford.edu

In article <1987Dec31.203153.28991@gpu.utcs.toronto.edu>
 parora@gpu.utcs.toronto.edu (Pavneet Arora) writes:
>
>I was just reading this quarter's STart magazine (Wint87), and came across an
>article on Zoomracks - an ST product which sounds a lot like Hypercard for the
>Mac.  One major difference being that Zoomracks has been around for 3 years.
Yep, I got the Zoomracks II version while at Comdex over a year
ago...it lets you store degas pictures as part of your
datasets...among other features.
>
>Why hasn't this product come to light earlier?   One thing I did notice was
>that the screens used in this article gave a definite edge to Hypercard
>since there were beautiful graphics mixed with text.  Is this a shortcoming
>of Zoomracks?

Yes, and no...It depends upon how much you really depend on graphics.
I like the Zoomracks approach because it got more information on the
screen at once (although it looks like a mess if you were expecting
graphics.) But then, I also am the type of person that turns off my
icons on the ST display and just use narrow vertical boxes of text
file names for my desktop view (to see more files). From a programmers
point of view, I still have yet to come up with a use for hypercard
(I've played with it and am not impressed enough to upgrade my wifes
Mac just for that). Zoomracks II seems to have a lot of power and
macro programmability to it, but give a person a good database, a good
spreadsheet, and a good word processor and they will probably be more
happy in the long run.

I know that a lot of the MCC people down in Texas are doing Hypertext
based applications (which hypercard was derived from). It would be
nice if they tried porting some of their stuff over to the ST's (they
are currently SUN and Symbolics based.) I think the Mega's would make
a nice engine for their needs (and things like the ABAQ would fit into
their longer term AI stuff where they are really going to need the
horsepower). If I remember right, MCC stands for Micro-electronics
Computer Consortium and is a research organization funded by 20 or so
large companies in the US to develop new technology in a variety of
computer and IC design specific areas...

  -Todd Burkey
   trb@stag.UUCP

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

Date: 2 Jan 88 09:43:43 GMT
From: ptsfa!well!dsmall@tis.llnl.gov  (David Small)
Subject: Re: speeding floppies?
To: info-atari16@score.stanford.edu

In the referenced article, there's much discussion about speeding
up floppies from Michael Stein.

There's no point in using a disk with interleave on it on the ST; the
ST is more than capable of 1:1 reads and writes. Since the ultimate
limiting factor is the head rubbing against the media at a certain speed,
and the ST is doing r/w as fast as physically possible, there's no
possible gain there.
  It is dangerous to remove the seek verify bit in the manner you have.
Let's say you step to a new track. The head rattles back and forth
awhile as it settles. During that time it is reading well enough to
return track dta to the controller, yet the head is still wobbling. If you
try a sector write, which lasts 16 msec, during this time, it's written in
a yo-yo pattern on the disk -- and is often unreadable the next time.
  This comes from hard experience; I did this on the Magic Sac Motivator, and
could consistently kill the first sector of each track. Weird, but true.
  You're right that a full disk rev is saved. A better way is to just twist
the track two sectors around, leaving one sector (#9 or 10) for the settle
time and one sector (#8 or 9) for the seek verify. Then you don't lose any
time at all track to track, and keep full compatability with unmodified
ST's. That's how we did Twister.
   As for using the index pulse as the delay time for seek, well, maybe. On
9 sector tracks you'll get away with it.. remember, 16.667 millisec per sector.
On 10 sector tracks you won't, there is no room. But worse, the step only
happens on the next-sector-read command, which may take awhile to
happen, all of which time the disk is spinning.
  Since you're stuck with 30 msec head settle, and lots of machine have
seek-with-verify, I think it's the optimal solution to twist the track by 2.
You just can't physically get data off multiple tracks any quicker without
speeding up the RPMs of the drive.

  .. perhaps we should plug it into a 220 Volt outlet?

 -- Thanks, Dave

dave small/bottlewasher/data pacific inc

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

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