saj@chinet.chi.il.us (Stephen Jacobs) (08/29/89)
One of the more useful tools in programming the ST is the commented ROM
disassembly in the Abacus ST Internals book (English translation of the
corresponding Data Becker book, I think, but I'm usually wrong). Now
that TOS 1.4 is filtering out, can anyone tell us if a corresponding
disassembly of that ROM is going to be available soon? My (probably
inaccurate) assumption was that Atari influenced what was published in
the Abacus book by saying what they would object strenuously to having
published, and that at least one subsequent book went too far; and therefore
can't be brought into the US. Anyway, whatever I can get, I want.
And a small love-note to the Atari contingent: IBM did it, even though
some of them must nearly have died doing it: they published a complete,
official ROM disassembly. Many developers did exactly what you don't want
us to do: they exploited internal code and data structures. Their code
broke when new DOS versions used the ROM code differently. Some of them
learned their lesson. Near-clone ROMs took more victims. But on balance,
I think you'll find pretty nearly complete agreement that the published
ROM code has helped the PC. An Atari-authorized, commented disassembly of
TOS 1.4 as of a given date (say the delivery date of the first production
lot?) would help programmers enormously. And if Atari emulated IBM even
further by charging $100 for the disassembly (I hope they would charge less),
sales would even give the company a shot in the net profit. ??
Steve J.towns@atari.UUCP (John Townsend) (08/31/89)
in article <9401@chinet.chi.il.us>, saj@chinet.chi.il.us (Stephen Jacobs) says: > > One of the more useful tools in programming the ST is the commented ROM > disassembly in the Abacus ST Internals book (English translation of the > corresponding Data Becker book, I think, but I'm usually wrong). I disagree completely. People should use the documented OS calls. They shouldn't fumble around inside the Operating System looking for calls and data structures that weren't intended for their use. > And a small love-note to the Atari contingent: IBM did it, even though > some of them must nearly have died doing it: they published a complete, > official ROM disassembly. Many developers did exactly what you don't want > us to do: they exploited internal code and data structures. Their code > broke when new DOS versions used the ROM code differently. Some of them > learned their lesson. Near-clone ROMs took more victims. But on balance, > I think you'll find pretty nearly complete agreement that the published > ROM code has helped the PC. An Atari-authorized, commented disassembly of > TOS 1.4 as of a given date (say the delivery date of the first production > lot?) would help programmers enormously. > Steve J. I can't believe what I am hearing! You state my case for me. Programmers depended on the things they read in the IBM disassembly and when things changed their code broke! Isn't that a good enough reason for not releasing disassembled or source versions of sections of the Operating System? My job at Atari is support. I am one of the people that has to take calls from irate customers that are mad because their favorite program breaks on their new computer (with MEGA TOS ROMs) and I am the one that has to tell them that it's because the manufacturer of the software didn't follow the rules when writing his/her program. Most of the time, Atari gets the blame (in the customer's eyes) for these problems with software, when in reality it's the software that is at fault. Anyway, there's my position on disassembled versions of TOS. -- John Townsend ames!atari!towns Atari Corporation
root@yale.UUCP (Root Of All Evil) (09/01/89)
In article <1666@atari.UUCP> towns@atari.UUCP (John Townsend) writes: >in article <9401@chinet.chi.il.us>, saj@chinet.chi.il.us (Stephen Jacobs) says: >> >> One of the more useful tools in programming the ST is the commented ROM >> disassembly in the Abacus ST Internals book (English translation of the >> corresponding Data Becker book, I think, but I'm usually wrong). > >I disagree completely. People should use the documented OS calls. They >shouldn't fumble around inside the Operating System looking for calls and >data structures that weren't intended for their use. > > ... > >Anyway, there's my position on disassembled versions of TOS. Things just aren't so simple. Yes, I agree that people should follow the rules and should use the documented OS calls. The problems come when: (1) The documentation is inadequate to determine what the "rules" are. (2) The OS calls are inadequate to accomplish the task at hand. The TOS documentation is still far from adequate. Developers still do not have the promised TOS 1.4 release notes, and many important aspects of the system are as yet not properly documented, even in the developers kit. By looking in commented source code, one can often determine what the intended rules are. Without the source code, one is forced to resort to trial and error to find something that happens to work (which may well violate the unstated rules and not work in future releases of the OS). In the cases where the OS calls are inadequate, the alternative to "fumbling around inside the Operating System" is often to not write the application at all. If people religiously stuck by the rules, we wouldn't have reset-proof ramdisks (what is the documented OS call to allocate a block of memory that survives a warm boot?), nor would people have been able to survive the bugs of TOS 1.0 so well for so many years, since the TSR patches that we can throw away with TOS 1.4 couldn't have been written in the first place! Of course, developers should try to write their programs in a way that makes them as widely useable across different platforms as possible, but that doesn't imply that if a program will not be usable on all platforms, now and in the future, that it shouldn't be written. Many programs require special features or equipment not available on all machines, e.g. color screens, hard disks, more than 512K of memory, scanners, printers, etc. Such programs should make clear what their requirements are, including any dependencies on particular releases of the operating system. The support problems come when programs aren't clear about their OS dependencies and customers aren't aware that different versions of the OS exist. ================================================== | Michael Fischer | | Arpanet: <fischer-michael@cs.yale.edu> | | Bitnet: <fischer-michael@yalecs.bitnet> | | UUCP: <fischer-michael@yale.UUCP> | ==================================================
saj@chinet.chi.il.us (Stephen Jacobs) (09/01/89)
John Townsend (who gets to pick up the pieces for Atari after third-party
programs break) disagreed with my request for an official Atari ROM disassembly
analogous to what IBM did with the PC. He took my concession that use of
undocumented features by PC programmers resulted in a lot of mayhem as an
adequate argument against publishing such a listing. But my point was that
even with that mayhem, the PC world has benefited enormously from the
availability of ROM listings. There are always data structures that are only
adequately explained with "Look: here's how we use this". There are clever
routines that one can learn from studying. Sometimes there are even OS bugs,
stuff that doesn't do what it's supposed to, or has side-effects that didn't
seem worth mentioning when it was documented. The PC world got better programs
sooner because the ROM listing was available, and after about the third round
of program-breaking upgrades, developers got the idea that you don't count
on anything staying the same unless it was specifically promised. We've had
some of those 'told 'ya so' upgrades from Atari already. I'm inclined to
believe that they WILL break any program that depends on undocumented
features. But when I'm trying to write to a screen that is already guaranteed
to be video mode 1; or to understand why I can't open any more files (and
my counter of open files says zero), that disassembly is precious.
Steve J.
hase@netmbx.UUCP (Hartmut Semken) (09/02/89)
In article <9401@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: >One of the more useful tools in programming the ST is the commented ROM >disassembly in the Abacus ST Internals book (English translation of the >corresponding Data Becker book, I think, but I'm usually wrong). The Data Becker book has only the BIOS disassembled, at last my copy... >Now >that TOS 1.4 is filtering out, can anyone tell us if a corresponding >disassembly of that ROM is going to be available soon? My (probably >inaccurate) assumption was that Atari influenced what was published in >the Abacus book by saying what they would object strenuously to having >published, and that at least one subsequent book went too far; and therefore >can't be brought into the US. Anyway, whatever I can get, I want. Well, there is a discompilation (re-assembly to C source) of the (almost) complete GEMDOS (including reassembly of Bios, XBios and AHDI) in a book called "Das TOS Listing". This one is published by the Heise-Verlag, not Data Becker. Did Atari block publication of this in USA? The book is german. Still want it? hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP Dennis had stepped up into the top seat whet its founder had died of a lethal overdose of brick wall, taken while under the influence of a Ferrari and a bottle of tequila. (Douglas Adams; the long dark teatime...)
SML108@PSUVM.BITNET (09/03/89)
On the subject of TOS 1.4 Rom disassemblies.... I'm all for it, there's no better way to learn a hodge-podge of dirty tricks than looking at the work of code wizards with carnal knowledge of the machine they write for. Sure for the most part one should use docuemented calls, but there ARE cases where this simply isn't practical. In my case, I wrote a handler to play 16 bit samples through a board my brother built, and if I had used "documented" calls to read the MIDI port to get synth input, the thing would have only been able to play at approx. 4 Khz with 8 voices rather than the 16 it currently plays at. So what if the machine got changed, I can easily write an update, and I would think that if I ever get anyone to market it, they would rather have the power than the portability....
ignac@electro.UUCP (Ignac Kolenko) (09/04/89)
In article <3355@netmbx.UUCP> hase@netmbx.UUCP (Hartmut Semken) writes: >Well, there is a discompilation (re-assembly to C source) of the >(almost) complete GEMDOS (including reassembly of Bios, XBios and AHDI) >in a book called "Das TOS Listing". This one is published by the >Heise-Verlag, not Data Becker. Did Atari block publication of this in >USA? > >The book is german. Still want it? (tried to email to you, but it bounced, so i'll post here instead:) sure!!! is it only available in germany? the discompilation, is it commented in german only?? nevertheless, if it is C source, then it sure would be handy to have. anyways, i'd sure like to have more info on this book. Das TOS Listing could become the new atari bible, giving ST Internals the rest it deserves!!! btw, what is the legallity of such a publication. is this the reason that this book is not available in the us??? -- =====Ignac A. Kolenko (The Ig) watmath!watcgl!electro!ignac===== co-author of QuickST, and the entire line of Quick Shareware!!!! "I don't care if I don't win, 'cause I don't care if I fail" from 'Youth Of Today' by SUBURBAN DISTORTION
kbad@atari.UUCP (Ken Badertscher) (09/04/89)
root@yale.UUCP (Root Of All Evil) writes: | [...] Many | programs require special features or equipment not available on all | machines, e.g. color screens, hard disks, more than 512K of memory, | scanners, printers, etc. Such programs should make clear what their | requirements are, including any dependencies on particular releases of | the operating system. The support problems come when programs aren't | clear about their OS dependencies and customers aren't aware that | different versions of the OS exist. Absolutely true! THANK YOU for recognizing this. It is the cause of many of the support calls recieved here at Atari - a lot of programs do not contain adequate "requirements" listings. To their credit, some dealers do a very good job of informing customers just what they need for a particular piece of software. B&C Computervisions in Santa Clara, CA is a good example, they do a great job of labeling the European games they carry (some of which do not work on Megas, or Rainbow TOS). Another consideration, though, is that the OS sources are in a constant state of flux, and they are not pretty. It would take nearly as much effort (probably more!) to "clean them up" so that they could be released, as it would to better document TOS. Given the choice, I'd rather see that effort go into better TOS documentation. Finally, if you have a specific question about something that isn't covered to your satisfaction in the developer documentation, please call or write to Atari developer support. They bust their butts answering developer questions all the time. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>
saj@chinet.chi.il.us (Stephen Jacobs) (09/05/89)
In article <1677@atari.UUCP>, kbad@atari.UUCP (Ken Badertscher) writes: > Finally, if you have a specific question about something that isn't > covered to your satisfaction in the developer documentation, please call > or write to Atari developer support. They bust their butts answering > developer questions all the time. > Having asked for ridiculous favors and kinds of help from Atari developer support (and having been taken care of effectively and politely), I'll second and more Ken's praise. As far as one-to-one help goes, the support staff is wonderful. However.....they can't help me with problems I don't understand well enough to explain. One specific example (taken care of in TOS 1.4, but this was a year ago) happened while I was adapting Steve Grimm's uupc distribution to Mark Williams C. I couldn't use (or even understand) his code to get the old RS232 port settings using Rsconf(). I would have had a hard time explaining to a support person that some public domain code used undocumented features in a way I didn't understand. Solution: read the ROM disassembly. I'm still kinda shaky on VBL queue routines and interrupt handlers (in principle, I understand, but..): there are examples in the ROM disassembly. I have some ideas for a product that would depend critically on a CD-ROM drive being able to read non-High Sierra formats. Can Atari's? I don't know. I don't understand CD ROM well enough to ask the right questions, but given code, I could tell how much was controlled in software, how much in hardware. I'm not asking for beautiful; and definitely: what Atari hasn't promised will stay the same will definitely change (may even change without any change in version numbers). But the more specifics there are about how TOS works, the better we can use it. And frankly, I'd be glad of an official, self-consistent disassembly WITHOUT comments, if that was possible. Again, it seems to have worked for the PC (although IBM did make it beautiful). And please don't interpret anything I say as remotely anti-Atari. I just got a good strong dose of PC and MAC, and it reminded me why I like my ST so much. Maybe the BEST, maybe not, but powerful and friendly to BOTH users and programmers. Steve J.
bammi@dsrgsun.ces.cwru.edu (Jwahar R. Bammi) (09/05/89)
In article <1677@atari.UUCP>, kbad@atari (Ken Badertscher) writes: >root@yale.UUCP (Root Of All Evil) writes: > >as it would to better document TOS. Given the choice, I'd rather see that >effort go into better TOS documentation. Dunno about this. The version of the developer kit that was first shipped to us came with full rom listing in english. i can honestly say that we learnt more from those listings than any of the other stuff atari shipped in the kit. Why they stopped that prctice is beyond me, and what perplexes me more is the present short-sightedness. Come on guys, take a look at unix. think how it got to where it is in the first place. Next take a look at the pace of Gnu development. Sure someone has to filter the gems from the crud ... bang: {any internet host}!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi domain: bammi@dsrgsun.ces.CWRU.edu GEnie: J.Bammi
hase@netmbx.UUCP (Hartmut Semken) (09/06/89)
In article <1060@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes: >>The book is german. Still want it? >(tried to email to you, but it bounced, so i'll post here instead:) Oh god. This bounce back should be over by now. Try ...!uunet!unido!netmbx!hase. Works. >anyways, i'd sure like to have more info on this book. Das TOS Listing >could become the new atari bible, giving ST Internals the rest it >deserves!!! Well, it is handy when used together with other documentation (like the MWC Lexicon and Tim Orens progem articles) The book has C-source listings for Gemdos and disassemblies of AHDI.PRG, Bios, Xbios and parts of VDI. The sources and comments descibe the way, a function works. It is not possible to "roll Your own" Gemdos-replacement. The second volume (planned since the first one showed up) never made it, probably because of legal action against it. It was planned as discompilation of VDI and AES (and probably DESKTOP.APP)... >btw, what is the legallity of such a publication. is this the reason >that this book is not available in the us??? It is still availeble in Germany. The publishers never thought about a translation to English (as far, as I know). This could be the reason for it not being availeble in the US. The publication is as legal as the "Internals" book: the german "Internals" (Atari ST Intern, Data Becker) was a "compacted reprint" of the development system docs. hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP Dennis had stepped up into the top seat whet its founder had died of a lethal overdose of brick wall, taken while under the influence of a Ferrari and a bottle of tequila. (Douglas Adams; the long dark teatime...)
rosenkra@hall.cray.com (Bill Rosenkranz) (09/07/89)
In article <1677@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes: =root@yale.UUCP (Root Of All Evil) writes: = =| [good comments about bad application s/w requirements docs] = = Absolutely true! THANK YOU for recognizing this. It is the cause there are SOME of us who write "compliant" code *8^) = Another consideration, though, is that the OS sources are in a constant =state of flux, and they are not pretty. It would take nearly as much =effort (probably more!) to "clean them up" so that they could be released, =as it would to better document TOS. Given the choice, I'd rather see that =effort go into better TOS documentation. as anyone knows who has worked with unix before, the "best" documentation (for that particular OS) is the source code. i'd MUCH rather have fully documented source for the OS than an (often) incomplete or erroneous manual. the src for TOS is readily available to anyone with a disassembler (and an ST, of course!) but it is quite tedious to wade through that mire to find how something works. those of us who have had a few years experience with the ST can easily find out just how something works, just by a quick peak at the src (the "ultimate" documentation). thos of us with 1985 versions of the developer's docs know just how many bugs were in the docs, let alone the OS! having src in electronic form could also allow developers to fix bugs and pass them on to atari for inclusion in the next release. that would be be like having a satellite s/w staff of a few hundred people. atari could release some sort of source code control system which the public would be obliged to follow (if they want their mods incorporated) and atari could have the final word in whether or not to incorporate any and all mods. the src released should be the TRUE src frozen at ROM burn time, not some pre-pre-pre-release version. heck, i'd even volunteer to help comment it! just think how much more "friendly" atari would seem to developers (over, say, commodore) if they say "hey, here is the full source on disk, guys". i don't expect much action on this, but it would sure be nice.... -bill rosenkra@boston.cray.com (my OTHER computers are cray-2/4-256's and Y-MP/832's, all of which can be had with source code *8^)
meulenbr@cstw01.prl.philips.nl (Frans Meulenbroeks) (09/07/89)
In article <3388@netmbx.UUCP> hase@netmbx.UUCP (Hartmut Semken) writes: >The second volume (planned since the first one showed up) never made it, >probably because of legal action against it. It was planned as >discompilation of VDI and AES (and probably DESKTOP.APP)... The rumour I head was that there was some kind of disagreement between the author and the publishing company. I have vol. I and have ordered vol II back in '87. Every time I inquire about it the bookshop says that it is postponed, and will be available half a year later. Frans Meulenbroeks (meulenbr@cst.prl.philips.nl) Centre for Software Technology ( or try: ...!mcvax!phigate!prle!cst!meulenbr)
Bob_BobR_Retelle@cup.portal.com (09/08/89)
Bill Rosenkranz sez: >just think how much more "friendly" atari would seem to developers (over, >say, commodore) if they say "hey, here is the full source on disk, guys". Drop by your local B.Dalton Booksellers or Waldenbooks book stores, and take a look at the *multi-volume* set of Amiga documentation that's available to ANYONE (without having to pay a $300 "initiation fee") Then check out the Apple Macintosh "Toolbox" series of books covering the essentials of programming for the Mac... again, available over the counter to ANYONE who wants the knowledge... Then ask yourself what is Atari Corp trying to do by keeping all this info "secret"...? BobR
tim@brspyr1.BRS.Com (Tim Northrup) (09/08/89)
Bob_BobR_Retelle@cup.portal.com writes: <<< random comments removed >>> >Then check out the Apple Macintosh "Toolbox" series of books covering the >essentials of programming for the Mac... again, available over the counter >to ANYONE who wants the knowledge... > >Then ask yourself what is Atari Corp trying to do by keeping all this info >"secret"...? I wouldn't say it's ALL secret. I find the Compute! set of technical reference manuals for the ST comparable to the Mac "Toolbox" series. They give the essentials for all GEM/BIOS/XBIOS calls, which is all your supposed to be using anyway, at least if you want it to run from ROM to ROM. Or is there some information you need that these books don't contain? -- Tim -- Tim Northrup +------------------------------------------+ +---------------------------------+ GEnie: T.Northrup | UUCP: uunet!crdgw1!brspyr1!tim | Air Warrior: "Duke" | ARPA: tim@brspyr1.BRS.Com +------------------------------------------+
rosenkra@hall.cray.com (Bill Rosenkranz) (09/09/89)
In article <21985@cup.portal.com> Bob_BobR_Retelle@cup.portal.com writes:
=i said:
=>just think how much more "friendly" atari would seem to developers (over,
=>say, commodore) if they say "hey, here is the full source on disk, guys".
=
=Drop by your local B.Dalton Booksellers or Waldenbooks book stores, and take
=a look at the *multi-volume* set of Amiga documentation that's available to
=ANYONE (without having to pay a $300 "initiation fee")
do these include src code? i thought not.
actually, when i thought about switching development platforms, i priced
these and it amounted to something like $120 or so. add $200 for a decent
compiler (i don't know amiga s/w prices so don't flame...this is just a
guess) and you come upto atari's $300 mark. since i got the dev kit way back
when for $200 (from xanth), it seemed like a pretty good deal (compiler,
docs, reduced prices on h/w, consultation, etc). i STILL use alcyon,
despite it's many shortcommings (except, of course apratt's aln which is
an excellent linker).
=Then ask yourself what is Atari Corp trying to do by keeping all this info
="secret"...?
good question. the answer, of course, lies in profit margins. atari didn't
(and still doesn't) need to do much to launch the ST. the "community",
especially in germany, keeps it afloat. i suspect that they may get a
rude awakening with the TT, depending on who they thing the target market
is. if it is the public at large (i.e. non-commercial, like the ST),
they can probably get away with similar practices and succeed. if it is
commercial, then they would die unless they can sell a million of the
suckers in the first year. maybe they can. inertia will carry it then.
the up-and-comming conehead, beckmeyers, DC, et al will hack away to try
and make a buck...
when u consider that u can run many mac AND ibm programs on the ST, it is
really a nice system, thanx to the hard work of so many talented programmers.
the last people atari (or any micro vendor) should want to rile is these
types of developers. they are the ones who made the ST a success (someone
once said: "software without hardware is an idea; hardware without software
is a space heater"). if developers want documented src for the os, atari
should just give it to them. they CAN get the ROM src themselves, but it
wastes SO much time which could be better spent developing s/w to sell more
h/w. if I were JT, i'd certainly do whatever i could to help the third
party s/w vendor, no matter how small, especially if it really didn't
cost me anything. if the src was in C, release it in C, not disassembled
code, please...
i used to complain mightily about various "quirks" in the ST os. now i
just accept them and work around them. part of the problem was my own
inexperience with microcomputer systems and the low-end s/w market in
general. people who succeed in this market (or any market, for that
matter) look past these problems and just DO IT. people who constantly
complain will never make it. if you made a bad decision, either live with
it or move on to something new...
part of the problem with the ST for more casual programmers (i.e. those
not relying on their efforts to pay the rent) is the lack of third party
books for the ST. i can find numerous books describing how to write
TSR's and device drivers for the PC. how interrupts work. what interrupts
are available. hardware interfacing. etc. NONE for the ST. you have to
figure it out for yourself or have to be professionally trained in 68k
h/w design.
my idea of s/w (before the ST) was $50,000+ packages running
on crays and cybers (even blue boxes :^). big finite element and CFD
codes. NASA...GM...you know, BIG stuff...
for me, if i wanted to develop s/w for a unix box, i'd pick a dec/sun/next/
hp-apollo/etc box over an atari and sell to companies rather than hobbyists
(i would tend to favor linear address spaces *8^). only corporations and
universities buy them, and they tend not to pirate your work (since they
have far deeper pockets to go after if they did).
=BobR
BillR :^)
rosenkra@boston.cray.comjdutka@wpi.wpi.edu (John Dutka) (09/10/89)
In article <4630@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes: >do these include src code? i thought not. Page D-1, Amiga ROM Kernel Reference Manual: Libraries and Devices - the first page of a section titled "Include Files," which it includes (no pun intended). It contains C-Language include files. Page E-1 - The Section titled "Printer Driver Source Code," containing the source code to some of the Amiga printer drivers. This particular book cost me only $34.95... I believe this is the 1.1/1.2 version... -- | John Dutka | "No matter how big a straw, you can't suck water up | | jdutka@wpi.wpi.edu | more than 34 feet." | | jdutka@wpi.bitnet | -A WPI PROFESSOR WHO WISHES TO REMAIN ANONYMOUS |
Bob_BobR_Retelle@cup.portal.com (09/10/89)
Tim Northrup commented that info about the ST is available from the Compute! book series.. Yes, that's true, but once again, it's a case of the "third party" bailing Atari out and relieving them of the responsibility of supporting their products in anything resembling the way other computer companies support THEIR products. Both the Amiga technical manual series, and the Apple Toolbox books are produced by the company that manufactures the computer. Wouldn't it be wonderful if Atari Corp would produce documentation whicwould be complete and "official", and available to anyone who wanted it, "over the counter", without having to "join the fraternity" by coughing up $300..? Atari has been promising better documentation forever... it's pretty obvious that this is a VERY low-priority item with them. We're facing the obsolscenc of the ST without ever having had any real "official" and easily available information about it...! BobR
walkerb@tramp.Colorado.EDU (Brian Walker) (09/12/89)
In article <22030@cup.portal.com> Bob_BobR_Retelle@cup.portal.com writes: [...] >Both the Amiga technical manual series, and the Apple Toolbox books are >produced by the company that manufactures the computer. > >Wouldn't it be wonderful if Atari Corp would produce documentation whicwould >be complete and "official", and available to anyone who wanted it, "over the >counter", without having to "join the fraternity" by coughing up $300..? By the way, Atari sells the documentation separately so you buy just the documentation, if you want.
rosenkra@hall.cray.com (Bill Rosenkranz) (09/13/89)
In article <3914@wpi.wpi.edu> jdutka@wpi.wpi.edu (John Dutka) writes: =In article <4630@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes: =>do these include src code? i thought not. = = [he describes a few headers and a driver example] i mean the entire OS, not just a few header files. atari provides all the header files ON DISK that u need with the dev kit. i mean src to the BIOS of the computer... my admitedly quick glances at the ROM kernel and other amiga books looked pretty good, but it would be impossible to see how accurate the documentation is. =This particular book cost me only $34.95... if you get all 4 or 5 amiga books (readily available in many bookstores) you end up paying over $100 (not bad, actually) but you get no compiler. atari $300 is actually quite reasonable by comparison, especially since atari decoupled docs from compiler in the dev kit. (i have the original, so i don't know how things work now w.r.t. dev kit). =| John Dutka | "No matter how big a straw, you can't suck water up | =| jdutka@wpi.wpi.edu | more than 34 feet." | =| jdutka@wpi.bitnet | -A WPI PROFESSOR WHO WISHES TO REMAIN ANONYMOUS | -bill rosenkra@hall.cray.com (BTW: does anyone know if MINIX-ST uses BIOS/XBIOS/GEMDOS? i suspect it uses BIOS/XBIOS and does its own GEMDOS. can u still get at line-A from minix? some day i'll get around to buying it...)
swhitney@hprnd.HP.COM (Steve Whitney) (09/14/89)
I'm not really in favor of a TOS disassembly, but source for things like GDOS drivers would be a tremendous shot in the arm for the state of Atari software development! --Steve