Sleeple@UMass.BITNET (03/08/88)
Well I am new to the Atari world....so pardon me if I am greatly out of line. We have all been waiting anxiously waiting for the ROM upgrades from Atari. Why don't we, as responsible programmers, take this great moment and standardize! Yes...silly as it may seem, now is probably the best time to do it. With the new ROMs, may programs will have to be reworked anyway, so why not standard certain things while we are at it. Things like: ((Fonts....boy...this would be great ((Postscript driver....in fact...ALL printer drivers.... these are all I can think of off the top of my head....maybe you guys can think of more.....think of the power this would give the average user... Perhaps standardization of programming techniques, ie...rules, that programmer should stick to in order to keep compatability within different programs...... I know...I'm just asking for too much....so flame me if you really want.. Damian Roskill SLEEPLE@UMASS "I didn't hurt it, I killed it, it didn't feel a thing." --------------------------------------------------------------
rosenkra@Alliant.COM (Bill Rosenkranz) (03/09/88)
In article <880307110110123.AHJN@Mars.UCC.UMass.EDU> Sleeple@UMass.BITNET writes: >Well I am new to the Atari world....so pardon me if I am greatly out >of line. We have all been waiting anxiously waiting for the ROM upgrades >from Atari. Why don't we, as responsible programmers, take this great >moment and standardize! Yes...silly as it may seem, now is probably the >best time to do it. With the new ROMs, may programs will have to be >reworked anyway, so why not standard certain things while we are at it. [examples deleted...] > .....think of the power this would give the average >user... >Perhaps standardization of programming techniques, ie...rules, that >programmer should stick to in order to keep compatability within different >programs...... >I know...I'm just asking for too much....so flame me if you really want.. to a great extent, or at least a large extent, the manufacturer and OS designer really should define the standard. Ok, now that im awake and realize who am im talking about (atari corp./DRI) this is obviously asking far too much. first of all, atari has virtually no control over the OS: i don't even think they have source to much of GEM/TOS/GEMDOS/... it's difficult even to know the proper NAME of the OS and it's parts, let alone specific details. atari was not remiss in leaving a fair amount of discression up to developers and warned continously about using "non standard" or reserved things (sys variables, etc.). this puts the onus on developers to make sure versions of the OS do not effect their program's behavior. this is fine for most programs that do little or no "outside" things but not the case for programs relying on quasi-documented "features". what atari could do is realize that certain programming really helps refine their machine and try to accomodate the developers. they are, however, really not set up to do that and instead choose to respond with "ha, i told you so!". you are naive to think that programmers will magically band together and standardize the way things are done, especially those of us in it for the $$$. i really don't know how further standardization will give you any more power. for all its problems , GEM ain't too bad. -bill
hase@netmbx.UUCP (Hartmut Semken) (03/13/88)
In article <1370@alliant.Alliant.COM> rosenkra@alliant.UUCP (Bill Rosenkranz) writes: > >first of all, atari has virtually no control over the OS: i don't even >think they have source to much of GEM/TOS/GEMDOS/... it's difficult even >to know the proper NAME of the OS and it's parts, let alone specific >details. I think they have (al last Alan Pratt said he had the sources..). Names! Whats important about names? > atari was not remiss in leaving a fair amount of discression >up to developers and warned continously about using "non standard" or >reserved things (sys variables, etc.). Right. And the lack of *good* documentation is the difference to Mama Blue. They made an open system, documented it and money came. I believe, it was not only the appaerance of three magical letters (and the bucks behind them). >you are naive to think that programmers will magically band together >and standardize the way things are done, especially those of us in it >for the $$$. Why not? If Atari does nothing about it? If we all talk about the bugs and 'hidden features', tell the comunity about worarounds etc? > >i really don't know how further standardization will give you any more >power. for all its problems , GEM ain't too bad. My employer 'forced' me to do some work on a MAC II; I dislike GEM more and more.... hase -- Hartmut Semken, Berlin (West) (*east of West-Germany :-) hase@netmbx.UUCP I think, you may be right in what I think you're thinking. (Douglas Adams)
dmb@TIS.COM (David M. Baggett) (03/18/88)
Personally I think that the lack of standardization is the one thing that
has kept the ST from being major competition with the Mac. Atari is very
much at fault for this ("ha, I told you so" really doesn't cut it), expecially
considering that they were really pushing this thing as a "more serious" or
"business" machine. But this isn't just more complaining about the state of
atari's management, etc. etc.
Frankly, ST software as a group is a terrible mess. I certainly am not
criticizing the programmers for this (I am one and proud too), and I am
not saying the software runs poorly. The problem is that, from the beginning
we have not known a damn thing about how the various OS componens work GEM,
TOS, AES, Bios, etc. Much of the information has been discovered through
playing around -- hacking -- and has been passed through bulletin boards and
interest groups. Remember the "fine" Developer's Package? It was incomplete,
really unclear (and ambigous), and worse, frequently incorrect. That started
developers off on the wrong foot in the first place. The Abacus books helped
but they were vague and occasionaly wrong too. Rember the article in STart
about message passing between desk accessories (they used DEGAS as an
example)? That's exactly the kind of thing developers should have known
about and supported all along.
The point of all this raving is that, since everyone knew very little about
the machine and its OS initially, and since Atari never set forth any standards
to speak of, every developer found his own way of doing things. The result:
Incredible lack of portability and compatibility between applications.
This may sound like whining, but think about this: It is currently
impossible to write a "Juggler" program that works on all ST software (by
"Juggler" I mean a program that allows you to have more than one program
in memory and to switch between them). In fact, it's impossible to write
one that works on much software at all (Michtron's attempt only works with
straight GEM applications -- forget NeoChrome, Spetrum 512, and all those
other programs with hardware hacks (like HBL's etc.))
This is because there is no standard way of doing anything. No one told
developers that they shouldn't use HBL's. No one said not to mess with the
mouse handler. Everyone did these things (and who can blame them), but by
doing so any hope of upward compatibilty and portability was tossed out the
window.
Compaare this situation to the Mac. That machine has evolved so much,
and all the software still works. (Examples: The new multifinder which
does "fer real" multitasking on EXISTING applications, the 68020 upgrades
which cause no problems, upward compatability with the new Mac II's)
The ideal: A really good toolbox (like the Mac's) which would give
programmers good routines so they wouldn't have to hack their own in
gross, nonportable 68000 asm. I've been working on an ST animation program
for over a year, and I just recently looked at the mac toolbox (so I'm not
just some MacJunkie trying to sell you on my machine -- I don't even own
one). But wow. If we'd been blessed with a system like QuickDraw, you bet
this machine would have blown the mac and amiga out of the water.
So I think standardization is essential. It's probably too late for
the ST (at least the GEM ST -- there's still hope for a new OS), but maybe
Atari will eventually learn not to throw things on the market without good
documentation. Hardware is useless without software and software is useless
without documentation.
:-(
Dave Baggett
dmb@tis.com) (03/18/88)
I don't know whether standardization is the real problem. Everyone
I believe is aware of the fact that that if you do certain things
to a system that you don't accomplish with system calls, changing
resolutions, reading the keyboard, time etc you lose compatibility some-
where along the line. BUT unfortunately that seems to be neccessary
on the ST to get somewhat decent programs running. The OS is slow,
clumsy and incomplete in many parts ( DRI Code : GEM & GEMDOS ), so
you have to work around, add your own stuff to get programs that
run smoothly (or at all).
(Funny that the stuff written in machine language BIOS and Line A
seems to be more bugfree and complete, than the C-written part.)
In all other aspects I agree with Mr. Bagget.
--------------------------------------------------------------
Loveletters & Hatemail to : wallman@yalecs
Files to : WALLMANN@CTSTATEU (Bitnet)
--------------------------------------------------------------david@bdt.UUCP (David Beckemeyer) (03/20/88)
In article <8803172142.AA00829@TIS.COM> dmb@TIS.COM (David M. Baggett) writes: > Personally I think that the lack of standardization is the one thing that >has kept the ST from being major competition with the Mac. Atari is very >much at fault for this ("ha, I told you so" really doesn't cut it), expecially >considering that they were really pushing this thing as a "more serious" or >"business" machine. But this isn't just more complaining about the state of >atari's management, etc. etc. [ some deleted ] > This may sound like whining, but think about this: It is currently >impossible to write a "Juggler" program that works on all ST software (by >"Juggler" I mean a program that allows you to have more than one program >in memory and to switch between them). In fact, it's impossible to write >one that works on much software at all (Michtron's attempt only works with >straight GEM applications -- forget NeoChrome, Spetrum 512, and all those >other programs with hardware hacks (like HBL's etc.)) > This is because there is no standard way of doing anything. No one told >developers that they shouldn't use HBL's. No one said not to mess with the >mouse handler. Everyone did these things (and who can blame them), but by >doing so any hope of upward compatibilty and portability was tossed out the >window. [ more deleted .. but you get the point ] I agree wholeheartedly. I find it even more amazing that it was Atari policy (offical or otherwise, I don't know) to actually PREVENT information from being released to developers. I and several other developers have attempted to gain information regarding standards, and have even proposed standards to Atari. No response, Yes, No, or otherwise. I can remember official developer support personnel stating things like: "Well we don't plan on making standards for that. If you have a good way to do it, do it that way, and maybe propose it to us." Well I did that, but it didn't do me any good. Nothing ever became an offical "standard". I don't even know, has Atari ever anounced an offical way to do anything? (This doesn't include Alan Pratt, who has given excellent advice here.) With respect to Multitasking, it's even worse that the problems one finds using ST applications with a simple switcher. The GEM standards are at least minimally documented, and the damned applications don't even adhere to them (all those programs that wipe out the Desk Acc. windows etc. are examples). Where there is even less documentation, things are far worse. Not only do we need standards, but we need "recommended" work-arounds that have some likelyhood of working with future enhacements, such as multitasking (which is here now). I think the effort that Mark Williams Co. and myself (BDT) have put in is the only way it will happen. Atari will NWEVER do it. The developers now know more about the ST then Atari could ever tell us (many long sessions with a 68000 ICE and single stepping through the ROMS!). We don't really need them to make a good system out of the ST. We need to form some sort of a developer association with developers agreeing to support each other and working together to provide mutual compatibility. It worked for MWC and BDT, I think it can work on a larger scale. -- David Beckemeyer | "To understand ranch lingo all yuh Beckemeyer Development Tools | have to do is to know in advance what 478 Santa Clara Ave, Oakland, CA 94610 | the other feller means an' then pay UUCP: ...!ihnp4!hoptoad!bdt!david | no attention to what he says"
rnss@ihuxy.ATT.COM (Ron Schreiner) (03/22/88)
In article <187@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes: >In article <8803172142.AA00829@TIS.COM> dmb@TIS.COM (David M. Baggett) writes: >> Personally I think that the lack of standardization is the one thing that >>has kept the ST from being major competition with the Mac. Atari is very ... >I agree wholeheartedly. I find it even more amazing that it was >Atari policy (offical or otherwise, I don't know) to actually PREVENT >information from being released to developers. I and several other >developers have attempted to gain information regarding standards, and >have even proposed standards to Atari. No response, Yes, No, or otherwise. > ... >We need to form some sort of a developer association with developers >agreeing to support each other and working together to provide mutual >compatibility. It worked for MWC and BDT, I think it can work on a >larger scale. >-- David Beckemeyer has a good idea hear, but I don't think it will work unless the "association" supports all new software, from the ROMs up. Otherwise it would just become a collection point for bugs that don't get fixed. If the end user had a choice of who's ROMs he wants, he could tell Atari ( thru his local dealer ) that he would like a ST, but keep the ROMs and yes I do expect a monetary credit for them. If major players in the software publishing world put a sticker on the package that read, "Requires Color Monitor and ROMs by BDT", people are going to want the "ROMs by BDT". In general publishers that use a supported OS are going to provide better products. Can anyone tell me why companies like SubLogic have had products like "Jet" on the comming soon list for over a year? Or why Generic Software has not bothered to port many of there PC products to the ST, or for that matter release a new version of "First CADD", the only real ( bugs included ) thing they do for the ST? Given the current "TOS",.. ah forget it. Mr. Beckemeyer, put your stuff into ROMs and make them available, hey I'll even give you a great promotional slogan; "When it comes to ROMs for your ST, if they arn't BDT, TOS them back" -- Ron Schreiner AT&T Bell Labs ...ihnp4!ihuxy!rnss
bds@lzaz.ATT.COM (BRUCE SZABLAK) (03/22/88)
In article <2460@ihuxy.ATT.COM>, rnss@ihuxy.ATT.COM (Ron Schreiner) writes: > If major players in the software publishing world put a sticker on the > package that read, "Requires Color Monitor and ROMs by BDT", people > are going to want the "ROMs by BDT". I don't think this will fly for two reasons, the first is that an outside source OS will be vulnerable to hardware changes (revisions) in the ST. The second reason follows: > In general publishers that use a supported OS are going to provide > better products. Can anyone tell me why companies like SubLogic have > had products like "Jet" on the coming soon list for over a year? > Or why Generic Software has not bothered to port many of there PC > products to the ST, or for that matter release a new version of > "First CADD", the only real ( bugs included ) thing they do for the ST? I have a friend who develops PC software for a major publisher. When he asked if the publisher had any interest in doing ST software the response was that there is not enough potential market to for it to be worth while (especially considering the risk involved). Thus reason two: If there isn't enough money to be made porting PC software, is there going to be enough potential customers to warrant the cost of a new, incompatible OS? Especially as the potential market is an established base of ST's whose owners don't want to shell out big $$ for it? I don't think Atari is going to refund the $25 for the ROMS I bought 2 years ago...;-) Let's face it developers: the ST is a niche market providing opportunities for small companies. The PC market is much tougher nut to crack. Also, at the profit margins Atari is getting for the ST's (they're STILL cheaper than equivalently equipped PCs!), and also its potential for continuing sales in the near term (I fully expect that a 68030 running UNIX to capture people's imaginations in 1990) make further (costly) development efforts on Atari's part unlikely.
ftw@datacube.UUCP (03/23/88)
Say, I don't suppose that any of you other developers have received some
stuff from Atari recently, then.
Two days ago, I got some docs from Atari. They are:
S.A.L.A.D. (Still Another Line-A Document), and
(Unititled) a specification for the Mega expansion slots.
SALAD looks to be quite a nice document. It contains synopses of all the
Line-A functions, each with an example of its use, and cautions where
appropriate.
I haven't completely read through the description of the Mega-slots, but
I did glance at it. It of course has pin-outs of the connector, part
numbers for the mating connector, talk about what address ranges are safe
for folks developing hardware add-ons (there is a specific caution to
those who put memory on an expansion card), etc.
Also, there was a newsletter for developers enclosed that was supposedly
written with Microsoft Word on a Mega-4, and printed on the Atari laser
printer.
Hopefully this is a sign of more good things to come...
Farrell T. Woods
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
INTERNET: ftw@datacube.COM
UUCP: {rutgers, ihnp4, mirror}!datacube!ftw
"OS/2 -- Half an operating system"wes@obie.UUCP (Barnacle Wes) (03/26/88)
In article <187@bdt.UUCP>, david@bdt.UUCP (David Beckemeyer) writes: > We need to form some sort of a developer association with developers > agreeing to support each other and working together to provide mutual > compatibility. It worked for MWC and BDT, I think it can work on a > larger scale. Yah, yah, that's the ticket! I would seriously be willing to support such an enterprise. User's groups are the way users get support for their machines, what we need is a developer's group, perhaps a non-profit corporation or something. This would allow, even encourage, sharing of information. I might even be willing to donate some time; this is the first worthwhile venture I've heard of in quite a while. Wes Peters -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes
trb@stag.UUCP ( Todd Burkey ) (03/31/88)
In article <89@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >In article <187@bdt.UUCP>, david@bdt.UUCP (David Beckemeyer) writes: >> We need to form some sort of a developer association with developers >> agreeing to support each other and working together to provide mutual >> compatibility. It worked for MWC and BDT, I think it can work on a >> larger scale. > >Yah, yah, that's the ticket! I would seriously be willing to support >such an enterprise. User's groups are the way users get support for >their machines, what we need is a developer's group, perhaps a >non-profit corporation or something. This would allow, even >encourage, sharing of information. I might even be willing to donate >some time; this is the first worthwhile venture I've heard of in quite >a while. > Wes Peters This was recently discussed at our local Atari ST developers meeting here in the Twin Cities. We are looking at the issues involved in setting up an international developers group within the next several months. We discussed (argued actually) the merits of setting up an electronic newsletter (something that would consist of articles by us as well as columns of the question/answer variety.) Distribution of the newsletter would be via UUCP (USENET as well as local ST's running STadel/UUPC/UUCALL/etc), BBS's, and whatever other networks it makes sense to get the information out on. I've talked to Dale Schumacher and he indicated he might be able to clean up his UUCP mail handler to the point that anyone could run it connecting into their local USENET host (or maybe even just calling up other ST's running the program if he gets carried away :-) ). Rather than send individual mail messages to all the developers that I know are on the net to get feedback on setting up this 'group', I decided that the quickest way to get things going would be this plea to all developers. If you have any thoughts on the structure, organization, contributions (in terms of articles, sample code, etc), methods of dissemination of information, or anything else that may be topical of such a group, please send me mail and I will summarize to the net. -Todd Burkey trb@stag.UUCP P.S. David, I got your mail. Thanks for the willingness to support this...I can imagine people will have LOTS of questions about multi-tasking and the system in general (even more so after everyone starts writing about it :-) ).