Path: utzoo!mnetor!uunet!husc6!uwvax!dogie!uwmcsd1!ig!jade!ucbvax!BINGVAXB.BITNET!POSTMASTER From: POSTMASTER@BINGVAXB.BITNET Newsgroups: comp.sys.atari.st Subject: Returned Network Mail Message-ID: <8801120151.AA09087@ucbvax.Berkeley.EDU> Date: 12 Jan 88 01:48:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 481 Your mail is being returned to you. Reason for return is: %MAIL-E-NOSUCHUSR, no such user VY9074 at node VAXB Returned mail follows: ------------------------------ Received: From CANADA01(MAILER) by BINGVAXB with Jnet id 3155 for VY9074@BINGVAXB; Mon, 11 Jan 88 20:48 EST Received: by CANADA01 (Mailer X1.24) id 3152; Mon, 11 Jan 88 20:43:24 EDT Date: Mon, 11 Jan 88 13:46:29 PST Reply-To: Info-Atari16@Score.Stanford.edu Sender: INFO-ATARI16 Discussion From: Info-Atari16 Digest Subject: Info-Atari16 Digest V88 #12 To: andrew stoffel 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 ". 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 ************************** -------