ROM disassembly for TOS 1.4
Stephen Jacobs
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.
John Townsend
>
> 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 Of All Evil
>in article <94...@chinet.chi.il.us>, s...@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...@cs.yale.edu> |
| Bitnet: <fischer...@yalecs.bitnet> |
| UUCP: <fischer...@yale.UUCP> |
==================================================
Stephen Jacobs
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.
Hartmut Semken
>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 ha...@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...)
SML...@psuvm.bitnet
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 Kolenko
>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
Ken Badertscher
| [...] 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>
Stephen Jacobs
> 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.
>
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.
Jwahar R. Bammi
>ro...@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: ba...@dsrgsun.ces.CWRU.edu
GEnie: J.Bammi
Hartmut Semken
>>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.
Bill Rosenkranz
=ro...@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....
(my OTHER computers are cray-2/4-256's and Y-MP/832's, all of which can
be had with source code *8^)
Frans Meulenbroeks
>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 (meul...@cst.prl.philips.nl)
Centre for Software Technology
( or try: ...!mcvax!phigate!prle!cst!meulenbr)
Bob_BobR...@cup.portal.com
>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".
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 Northrup
<<< 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: t...@brspyr1.BRS.Com +------------------------------------------+
Bill Rosenkranz
=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 :^)
rose...@boston.cray.com
John Dutka
>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 |
| jdu...@wpi.wpi.edu | more than 34 feet." |
| jdu...@wpi.bitnet | -A WPI PROFESSOR WHO WISHES TO REMAIN ANONYMOUS |
Bob_BobR...@cup.portal.com
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
Brian Walker
[...]
>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..?
documentation, if you want.
Bill Rosenkranz
=In article <46...@hall.cray.com> rose...@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 |
=| jdu...@wpi.wpi.edu | more than 34 feet." |
=| jdu...@wpi.bitnet | -A WPI PROFESSOR WHO WISHES TO REMAIN ANONYMOUS |
(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...)
Steve Whitney
like GDOS drivers would be a tremendous shot in the arm for the state
of Atari software development!
--Steve