daniel@pkmab.se (Daniel Deimert) (11/19/89)
I have just got hold of my 1040 STE (Friday) and thought the
Net might be interested in some facts, which should be well known.
If they are or not... Well.. Read the following:
What it has
- Smooth one-pixel scrolling in hardware
- Two 8-bit D/A-converters for stereo sound
- RCA stereo output
- Blitter (thanks guys!)
- Six (6) joystick ports [Atari BUSINESS Computer, ha!]
- A palette of 4096 colors. almost useless with the RF-modulator
My first impression is that it could have been better. Much better.
Sure the scrolling is impressing. But the sound... Nah, I've heard
better. The future can't be playing raw sampled sound -- takes too
much memory.
Along on the language disk with handwritten label that follow are two
different demos, apparently written with Turbo C 1.1 (Yes, I've
disassembled them. I had to!) that shows the new capabilities.
Why not put them together, it would be more impressing!
The sound demo sounds good -- but the samplings are boring and really
not that good. You could have done better!
The scrolling demo consists of nine pictures in pattern of 3 times 3
screen where you can scroll softly to any point by moving the mouse.
Nifty!
But, listen now Atari, a large BUT. *No* documentation about the
new chips followed. Not even a list of adresses, not even a little
"read.me" on the language disk!
Why? Don't you want people to use these new features, just the
software houses, or what?
More information follows as soon as I manage to find out. Any
information about the STE can be posted to me. I will summarize to
the net if it's interesting.
[BTW, funny with the hbls in "desktop info"! Not much work, but
it really looks nice...]
--
Daniel Deimert, Fridstav. 4, S-715 94 Odensbacken, SWEDEN
Internet: daniel@pkmab.se
UUCP: ...{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!danielmitsolid@acf5.NYU.EDU (Thanasis Mitsolides) (11/20/89)
/* acf5:comp.sys.atari.st / daniel@pkmab.se (Daniel Deimert) / 11:13 am Nov 18, 1989 */ >What it has > > - Smooth one-pixel scrolling in hardware > - Two 8-bit D/A-converters for stereo sound > - RCA stereo output > - Blitter (thanks guys!) > - Six (6) joystick ports [Atari BUSINESS Computer, ha!] > - A palette of 4096 colors. almost useless with the RF-modulator How much memory? What kind of a monitor? What resolution? And what is the price? Just curious. Thanasis
daniel@pkmab.se (Daniel Deimert) (11/24/89)
In article <370002@acf5.NYU.EDU> mitsolid@acf5.NYU.EDU (Thanasis Mitsolides) writes: >>What it has >> [...deleted...] > >How much memory? What kind of a monitor? What resolution? >And what is the price? Just curious. 1 Mb of memory in the 1040 STE, as I said it's is a slightly modified 1040 ST. The same monitors as before. And as far as I can tell there's no change in resolution either (I heard some rumours about it having overscan -- but there's no way obtaining it in the desktop. If there is a bit somewhere, it's well hidden. BTW, the way of removing the borders on the ST by flipping scan frq don't work. The synch is different.) RRP in Sweden is 6500 SEK ($1 ~ 7 SEK i think), but it's not hard to get a discount of 10 per cent almost anywhere. -- Daniel Deimert, Fridstav. 4, S-715 94 Odensbacken, SWEDEN Internet: daniel@pkmab.se UUCP: ...{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!daniel
apratt@atari.UUCP (Allan Pratt) (11/28/89)
daniel@pkmab.se (Daniel Deimert) writes: >mitsolid@acf5.NYU.EDU (Thanasis Mitsolides) writes: >>>What it has >>> [...deleted...] >> >>How much memory? What kind of a monitor? What resolution? >>And what is the price? Just curious. >1 Mb of memory in the 1040 STE, as I said it's is a slightly modified >1040 ST. >The same monitors as before. And as far as I can tell there's no change >in resolution either [...] The changes in video are as follows: The color palette has 4096 colors, not the ST's 512. That's four bits each for red, green, and blue. You still get the same number onscreen at a time (4 or 16) but the shades can be finer, and you can get 16 true grey levels. The video address can be changed on a line-by-line basis. This makes split-screen stuff really easy. The video memory buffer can be larger than the screen. The screen then becomes a "window" onto this larger canvas. The video can start on any word boundary. Each line can be delayed by any number of bits. What this all adds up to is horizontal and vertical scrolling by bits, and split-screen effects which are effortless and not memory- or time-consuming. You can, for instance, load a large "landscape" into memory, like a whole Gauntlet level, and slide the "window" around by individual pixels, taking ZERO TIME rather than the huge time required to move the memory around. In addition, you can have the static (non-scrolling) part like the scores at the top or bottom: it won't have to be moved around, copied, or anything. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
scott@cs.odu.edu (Scott Yelich) (11/28/89)
> What this all adds up to is horizontal and vertical scrolling by bits, > and split-screen effects which are effortless and not memory- or > time-consuming. You can, for instance, load a large "landscape" into > memory, like a whole Gauntlet level, and slide the "window" around by > individual pixels, taking ZERO TIME rather than the huge time required > to move the memory around. In addition, you can have the static > (non-scrolling) part like the scores at the top or bottom: it won't > have to be moved around, copied, or anything. This sounds a lot like the old 8bits capabilities.... -- ----------------------------------------------------------------------------- Scott D. Yelich scott@cs.odu.edu [128.82.8.1] After he pushed me off the cliff, he asked me, as I fell, ``Why'd you jump?'' -----------------------------------------------------------------------------
chad@norge.dec.com (11/29/89)
Distribution: world Organization: Digital equipment Corporation, Nashua NH Return of the 8bits! Allan Pratt's description of the way video memory is addressed and divided up reminds me of the Atari 8bits and the power there! Sounds neato! Chad DEC has no opinions! The Amiga may be able to do it too but this is comp.sys.atari.st ------------------------------------------------------
esp_05@jhunix.HCF.JHU.EDU (Stdnt 05) (11/29/89)
You know, except for the color palette, I knew a computer with the new features of the STe. I think it was called the Atari 800. Hardware scrolling, ability to reload video shifter address every line, etc... EMR
laba-1aj@e260-3g.berkeley.edu (John Kawakami) (11/29/89)
In article <3421@jhunix.HCF.JHU.EDU> esp_05@jhunix.UUCP (Stdnt 05) writes: >You know, except for the color palette, I knew a computer with the new >features of the STe. I think it was called the Atari 800. Hardware >scrolling, ability to reload video shifter address every line, etc... >EMR Scrolling seems easier on the STE. On the 800, to get fine scrolling, you had to update address pointers AND delay/offsets. It sounds like the STE can do this strictly through offsets. I may be wrong though. How likely is it that we (users) can buy the new graphics chips and some patches to tap some of the new features?
dhe@uafhcx.uucp (David Ewing) (11/30/89)
In article <1824@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes: > The color palette has 4096 colors, not the ST's 512. That's > > The video address can be changed on a line-by-line basis. > This makes split-screen stuff really easy. > > The video memory buffer can be larger than the screen. > The screen then becomes a "window" onto this larger canvas. > > The video can start on any word boundary. > > Each line can be delayed by any number of bits. > > What this all adds up to is horizontal and vertical scrolling by bits, > and split-screen effects which are effortless and not memory- or Will this new graphics chip used in the STE be pin to pin compatible with the one currently in the ST? Can we actually BUY a STE graphics chip and put it into the ST? It would be nice if we could. -Dave ============================================================================== dhe@uafhcx.uark.edu David Ewing, University of Arkansas "What does God need with a Starship?!" Computer Science Engineering ============================================================================== ============================================================================== dhe@uafhcx.uark.edu David Ewing, University of Arkansas "What does God need with a Starship?!" Computer Science Engineering ==============================================================================
rehrauer@apollo.HP.COM (Steve Rehrauer) (12/01/89)
In article <1824@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: [ A description of some of the video nifties in the 1040STe. ] [ Later KBAD discusses some of the differences between the STe and TT video nifties. ] This has probably already been asked & answered here, but... The STe appears to be the first "ST" that offers fundamental hardware improvements that software can take advantage of. The TT, of course, is another beast altogether, although it will apparently be backwards compatible with "ST software". Obviously no one in their right mind will write STe software that isn't downwardly compatible to the existing STs (for awhile yet, anyway -- I HOPE!!). But it'd sure be nice to use the STe's video nifties when present. Is there an approved method for software to discover what platform it's running on, other than (KLUDGE ALERT!) checking the TOS revision #? Please tell me it IS so! (And also what it is! ;-) -- >>"Aaiiyeeee! Death from above!"<< | Steve Rehrauer, rehrauer@apollo.hp.com "Flee, lest we be trod upon!" | The Apollo System Division of H.P.
kbad@atari.UUCP (Ken Badertscher) (12/02/89)
rehrauer@apollo.HP.COM (Steve Rehrauer) writes: | Is there an approved method for software to discover what | platform it's running on, other than (KLUDGE ALERT!) checking the TOS | revision #? Yes, there is a new OS service offered in the ROM, beginning with STE TOS, called the Cookie Jar. The startup code in the new ROM versions set up an area of memory with "cookies" which describe various system configuration options, and with values for the cookies that describe what's actually there. The Cookie Jar documentation is available to developers now, and we will be making it available to the general public shortly. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>
dag@per2.UUCP (Daniel A. Glasser) (12/08/89)
In article <1842@atari.UUCP>, kbad@atari.UUCP (Ken Badertscher) writes: > Yes, there is a new OS service offered in the ROM, beginning with > STE TOS, called the Cookie Jar. The startup code in the new ROM versions > set up an area of memory with "cookies" which describe various system > configuration options, and with values for the cookies that describe > what's actually there. The "Cookie Jar" sounds to be similar to the "WIMP" directive that was (is?) in P/OS running on the DEC Professional series (325, 350, 380). WIMP stood for "What's In My Professional?". I'm glad that you folks have finally caught up with 1982 in that area, though you're still back in the mid-to-late 70's with most of TOS, and the early to mid 80's with GEM. Will the "Cookie Jar" ever appear in a revision to TOS for the older machines? Is there a reasonable way to detect that there is no cookie jar on a machine which a program can use? If it is a new XBIOS style function, the return value from the call to the system service would be a value indicating that an illegal function was called, which is enough to tell the program that there are no cookies. If calling this function on an older OS causes a buss error or similar unpredictable or unacceptable behavior, I'll be VERY dissapointed. -- _____________________________________________________________________________ Daniel A. Glasser One of those things that goes uwvax!per2!dag "BUMP!!!(ouch)" in the night. ---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711-----------
stephen@oahu.cs.ucla.edu (Steve Whitney) (12/08/89)
In article <881@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes: >The "Cookie Jar" sounds to be similar to the "WIMP" directive that >was (is?) in P/OS running on the DEC Professional series (325, 350, 380). >WIMP stood for "What's In My Professional?". I'm glad that you folks >have finally caught up with 1982 in that area, though you're still back >in the mid-to-late 70's with most of TOS, and the early to mid 80's with GEM. <stepping up onto my soapbox now...> You know, I try to ignore stuff like this, but I just can't this time. I'd send you nasty mail, but I want the people likely to be offended by this to see the response. First of all, the ST is a personal computer. The "Cookie Jar" is relatively new to that arena. Secondly, how do you know it's 1982 technology if you don't know how it's implemented or even the extent of what it does. I do, by the way but I have been asked not to disclose it until it's made public by Atari and I intend to honor that request. (Even thought I haven't signed the new non-disclosure agreement yet :-) It's quite well done, believe me. The REAL reason I replied to your posting is that it's offensive. If you ever expect to see more upgrades to TOS, you shjouldn't be discouraging those whose sweat and enthusiasm it will take to make it happen. _SOME_ of us appreciate the things Atari's doing of late (like TOS 1.4, HDX 3.x, cookie jar) and we'd like to continue to see improvements. If you want to scare Ken B. and others off the net, continue to offend them this way. Remember, they have constraints to work within, not the least of which is compatibility. The three enchancements I mentioned above are fine examples of how Atari (read Atari's engineers) has provided enhancements which increase the value of older machines without being incompatible with old software. <off the soapbox and back to comp.sys.atari.st> (more dross deleted) > _____________________________________________________________________________ > Daniel A. Glasser One of those things that goes > uwvax!per2!dag "BUMP!!!(ouch)" in the night. > ---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711----------- -- Steve Whitney "It's never _really_ the last minute" (())_-_(()) UCLA Comp. Sci. Grad. Student | (* *) | Internet: stephen@cs.ucla.edu UCLA Bruin--> { \_@_/ } GEnie: S.WHITNEY `-----'
kbad@atari.UUCP (Ken Badertscher) (12/09/89)
dag@per2.UUCP (Daniel A. Glasser) writes: | I'm glad that you folks have finally caught up with 1982 in that area [...] Thank you for slamming us about something which you admit you don't know about. | Will the "Cookie Jar" ever appear in a revision to TOS for the older machines? Not necessary. It's not a function call, it's a service provided by the startup code, and it isn't necessary on existing machines, because the services they provide are known. It is possible for people with exotic devices on older machines to have the drivers for said devices install a cookie jar in the auto folder, for example. | Is there a reasonable way to detect that there is no cookie jar on a machine | which a program can use? Yes. If the new system variable which points to the Cookie Jar is zero, you're on an old machine. | If calling this function on an older OS causes a | buss error or similar unpredictable or unacceptable behavior, I'll be VERY | dissapointed. (Warning, sarcasm ahead) As everyone knows well from following this news group, it is always our policy when enhancing the OS to make it as incompatible as we can. If it was hard to code, it should be hard to use. It was a tough decision to leave out of the Cookie Jar spec the feature which would have caused the machine to reboot on older TOS versions, but somehow we resisted the temptation. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>
dag@per2.UUCP (Daniel A. Glasser) (12/12/89)
In article <29836@shemp.CS.UCLA.EDU>, stephen@oahu.cs.ucla.edu (Steve Whitney) writes: > In article <881@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes: >> [extract from my posting omitted] > <stepping up onto my soapbox now...> > > First of all, the ST is a personal computer. The "Cookie Jar" is relatively > new to that arena. Actually, the DEC Professional series machines were also classified as "personal computer". Also, I never said that personal computers used up-to-date technology. It is just that said technology was introduced before, and was in common use by, 1982. Since this technology was available before the ST and TOS were on the drawing boards, I might expect product designers to have seen it as a possibility when they were specifying the functionality for the ST operating system. The people at fault here are mostly the DRI designers and programmers who had their heads stuck firmly in the sand of the CP/M world and had too little time to even do CP/M right for the ST platform. > Secondly, how do you know it's 1982 technology if you > don't know how it's implemented or even the extent of what it does. I do, > by the way but I have been asked not to disclose it until it's made public > by Atari and I intend to honor that request. [comment deleted] > It's quite well done, believe me. See the above about the age of the technology. I have a fairly good background in these things and have seen at least two systems where you not only get a list of what options and versions you've got installed on your system and the modes they may be in, but also pointers to routines that allow a program to hook itself onto the device with inclusive or exclusive access, etc. I won't go into detail here. The IBM-PC BIOS has had a very limited version of this feature since its introduction. > The REAL reason I replied to your posting is that it's offensive. If you ever > expect to see more upgrades to TOS, you shjouldn't be discouraging those whose > sweat and enthusiasm it will take to make it happen. _SOME_ of us appreciate > the things Atari's doing of late (like TOS 1.4, HDX 3.x, cookie jar) and we'd > like to continue to see improvements. > > If you want to scare Ken B. and others off the net, continue to offend them > this way. Remember, they have constraints to work within, not the least of > which is compatibility. The three enchancements I mentioned above are fine > examples of how Atari (read Atari's engineers) has provided enhancements > which increase the value of older machines without being incompatible with > old software. > <off the soapbox and back to comp.sys.atari.st> Well, I'm not privy to the cookie jar info at this time, but I believe that Allan Pratt can vouch for my credentials in the area of ST development. I've been developing software for the ST since 1985, and although Atari has lost track of my Registered Developer status over the years, I was a registered developer. In my previous position with the Mark Williams Company, I assisted and encouraged ST developers and end-users alike, helping them to program in the ST environment both through the development of the (IMHO) most complete and easy-to-port-from-other-systems-to C language programming system available (including a major hand in the documentation), but in long hours of phone support and hand-holding. I also used to talk with the Atari people via. telephone on a fairly regular basis. I've spoken in the past with various software people at Atari about changes and fixes to TOS which would maintain a high level of compatibility with previous versions but offer new and extended functionality to newer applications. I have always encouraged the development and improvement of the ST environment, and will continue to do so even now that I'm not actively developing commercial software for the ST. My comments to the network were to prod a bit more information out of the overworked and overloaded Ken B. and Allan P. and to let them know I'm still around. I don't believe that my comments will either discourage or even overly annoy those folks. I know what kind of constraints they are working under, and I understand why the evolution of TOS has been so slow, but the fact that I know these things inside and out does not prevent me from having an opinion and expressing it. Please don't take what I say in my rare critical postings as a damning of what the programmers and engineers at Atari are doing. Most people who have been on the net for more than a year know that I generally post constructive, positive and helpful information. I've been rather quiet for the last year, but that's because I have limited network access and not very much time to spend reading or posting messages. This reply is being made to the newsgroup because your flame at me was made to the newsgroup and I don't want people putting me in a class with the Atari-bashing denizens of this group. Please direct all flames in response to me via mail. -- _____________________________________________________________________________ Daniel A. Glasser One of those things that goes uwvax!per2!dag "BUMP!!!(ouch)" in the night. ---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711-----------
rwa@cs.AthabascaU.CA (Ross Alexander) (12/15/89)
stephen@oahu.cs.ucla.edu (Steve Whitney) writes: >In article <881@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes: >>[reasonable stuff about TOS, with references] ><stepping up onto my soapbox now...> >You know, I try to ignore stuff like this, but I just can't this time. I'd >send you nasty mail, but I want the people likely to be offended by this to >see the response. >First of all, the ST is a personal computer. The "Cookie Jar" is relatively >new to that arena. Secondly, how do you know it's 1982 technology if you don't >know how it's implemented or even the extent of what it does. [much more flamage] >If you want to scare Ken B. and others off the net, continue to offend them >this way. Remember, they have constraints to work within, not the least of [and yet more flamage]. Hey, Steve, do you know who DAG is ?? It's wise to listen carefully when he speaks... and if you disagree with him, stick to the facts and debate them on their merits. Are you familiar with the WIMP instruction? No?? Neither am I, but you seem to know that the cookie jar is a lot better, which is an interesting conclusion. Also, I think KenB is a little less timid than you imply. cheers, Ross