Talk:Atari ST

Two new questions that the internet hasn't been able to answer so far

(I'm the author of the long post below, and it's been a while since there was any new discussion on here, so I don't feel bad about suffixing this; it sort of counts anyway).

One: What exactly are the resolution and timing specs of the ST's high rez mode, and/or the SM124? I've had multiple responses come back when trying to look this up. It's 70Hz... no, it's 72Hz... no, it's 71.2... It's got a 31.5kHz line rate, a 35.8kHz one... and no-one, but no-one knows how many lines actually make up a full vertical scan including the blanking period, even though it's reasonably well known for the colour modes, at least for 50Hz (313 or maybe 315).

It doesn't make a great deal of odds, but I was trying to find it out for some of my own daydream doodling and found that nobody, not even some quite detailed technical references, actually knows for sure. It's not in Atari's own internal documentation, it's not in the SM124 manual, it's not anywhere.

From my own attempt at figuring it out from first principles... 71.2Hz sounds just about overprecise enough to be believable, and as the shifter's data rate is in lockstep with the CPU, it should pump out twice as many pixels per second as in medium rez, four times that of low. It has twice the usable vertical rez but the same horizontal, which suggests twice the line rate (31.3 to 31.5kHz depending if you base it off PAL or NTSC; given that it's an American machine, probably the latter)... which along with the increased refresh gives us an overall progressive frame of 442 lines. Plenty enough for a decent top/bottom border and Vblank/Vsync (480i within a 525 frame leaves 45 blank lines... 486i leaves 39), but not enough for 480, 448 or even 432, which may also explain the limited vertical rez in colour modes, as they tried to keep the video RAM area the same size throughout for simplicity.

Which all sort of fits, but I have no way to be sure short of hunting out an SM124 of my own and then grabbing an oscilloscope from somewhere and bodging up some way of sampling it. And there's no references of course so it's hard to cite in-article.

Please, does anyone know this information more concretely?

Second question... just what is the shifter rate and memory access interleave, for real? The information further down this thread (and I think in-article too?) says it's 1:1 ... the CPU/etc get a turn, then the shifter gets a turn, etc. But the available video modes and some other timing charts (which say, e.g., a PAL ST has 512 cycles but 128 "NOPs" per line, with four pixels per NOP (4 pixels x 4 bits = one 16-bit memory word)) suggest more of a 3:1 CPU:shifter relationship (2Mhz / 4MBs for video, not 4/8), and it presumably isn't a problem of the shifter sending an address to the RAM and then being made to wait for a cycle, as the Amiga uses a similar 1:1 scheme when operating purely from "Chip RAM" (witness the boost in processing speed when non-vidchip-accessible "fast RAM" is added), but can dump approximately twice as much visual data to screen per second (i.e. at 640x200, it can show 16 colours, not 4, and the ECS allows a 1280-wide, 4-colour mode with very little change to the architecture).

What exactly is going on, here? Is it possible, with some twiddling about and replacement of ROM routines (and maybe soldering a wire here and there) that the ST could be granted a 16-colour medium resolution mode? (4-grey hi rez or 256-colour low rez would need rather more work than just doubling the data rate and allowing all 16 registers to be used with a 640-pixel display) ... Or is there something fundamental I'm just not quite getting? 193.63.174.211 (talk) 13:44, 24 May 2013 (UTC)

I can't help with the first question, but I have some information concerning the second.

There are 512 CPU cycles per scanline. It takes four CPU cycles for the CPU to perform a read or write. 512/4 gives 128 NOPs per scanline. During the first two CPU cycles the CPU places an address on the address bus. The MMU uses this address to perform a memory access on the next two cycles. RAM is fast enough however to perform a read or write in two CPU cycles, but the CPU isn't fast enough to take advantage of this, so while the MMU is reading the CPU address bus, it performs a memory access for the SHIFTER. And while the CPU is reading or writing to RAM during the last two cycles of its four cycle read or write, the SHIFTER is preparing its next address. This interleaving of accesses rarely slows the CPU down except in a few cases where an instruction takes a non-multiple of four cycles. Between 3% and 7% instructions are made to wait. During the blanking periods, RAM is refreshed instead of being read for output to the display. These length-of-two CPU cycle memory accesses are often called odd and even memory cycles.

The Amiga works in the very same way, except that more memory access cycles are available to both the CPU and display hardware. The CPU isn't constrained to access memory on four CPU cycle boundaries and the display hardware has access to every memory cycle if needed. For example, a 16-color 640x512 display will access memory every two CPU cycles. This does block the CPU during the display period, though the CPU still has access to memory during the blanking intervals. There is no way to allow the Atari ST's shifter access to memory every two CPU cycles, so 640x200 is limited to four colors. — Preceding unsigned comment added by 166.147.120.173 (talk) 19:28, 30 July 2013 (UTC)

Cool, thank you. It sounds a bit complicated even if it makes sense in operation :) ... I've been getting dribs and drabs of information about how it actually works on successive tries at finding out down the years and this helps tie it together that bit more. MMU is actually hitting the memory almost constantly in some cases, but the shifter actually just gets 16 bits every 4 cycles (so, 320 cycles across the active part of the screen, with effectively 4 bits each...). Does that then mean that the "interleaved bitplanes" are organised so you have 4 bits of one plane, then 4 of the 2nd, 4 of 3rd, 4 of 4th in low res... or 8 of first, 8 of second in med... and of course flat bitmap in high? I've also wondered how the heck you fill the shift register properly without any kind of buffer if only able to read one 16-bit location each cycle. Seemed like you'd need an 8-byte buffer otherwise.

And also I guess it means you COULD mod the shifter somehow to run at 2x speed, and the MMU to lock the CPU out during the active period (or make FGPAs that worked in place of each), requesting a word twice during each of the 80 macrocycles instead of just once, so you could have 4-level greyscale in mono (and, heck, whilst you're at it, 16-level with half H-rez), and 16 colours in 15khz 80-column mode? Maybe even some companion chip or whole new shifter that could provide a whole raft of new registers to take advantage of a 256-colour (from 4096 - or more?) low rez mode, or.... ((whole bunch of alternative ideas thought up whilst getting coffee but not worth boring you with))?? Of course there would be a speed penalty, to the tune of 160 extra CPU-bus cycles (or 40 memory cycles...) being blocked per line, also meaning that audio, disc transfer, etc couldn't use the RAM either. Thus 32000 CPU / 8000 memory accesses per frame (assuming no overscan), or 1.60 - 1.92 - 2.23 million CPU / 400k - 479.5k - 569.6k memory accesses per second (PAL, NTSC, Mono), out of the 5.77 to 6.4 mill / 430.4 to 600k that were initially available. So apparent speed, depending on resolution and what operations are being performed, may appear to drop to as low as 75% - or even just over 60% - of normal... which may be considered an acceptable loss for the improved graphics. Presumably it wouldn't be desirable when working with MIDI or high-rate audio or disc transfer applications, as it would interfere with DMA just as much as it would the CPU, and thus potentially disturb not only speed but also regularity and latency (lots of "jitter", at display line frequency, though it would of course not be quite as bad in hi-rez as the bursts of non-video activity would come twice as often, albeit being half as long), which was generally considered one of the ST's strengths. For some things it might not make too much difference though... either those which only did light processing, or were much more bound by internal CPU delays than memory RW (and a good programmer could organise things to start such operations just before the active display period and save all the memops for the blank instead). And really, the STe should have had a DMA sample rate based on multiples of display frequency anyhow, and a very small buffer/audio shifter (like, maybe 4 samples worth) to allow 31.25 / 31.47khz, 41.6~42.0, 20.8~21.0, 10.4~10.5 (and 6.25, 12.5, 25.0...) if desired... (ie 2x line freq, 8/3, 4/3, 2/3 ... and 2/5, 4/5, 8/5) on top of 15.63/15.74, 7.8/7.9, 5.2/5.3. Obviously Mono would bring its own challenges................... augh, I've digressed again. Let's just sign off :D 193.63.174.115 (talk) 15:41, 26 February 2016 (UTC)

response to points raised on this page

In response to points raised on this page (i have done a bit of editing on the main article page but have both got tired, and think the following thoughts are too informal/inappropriate/unfounded to go on there):

• The upper right image is definately an ST, but a very early one without internal disc drive, hence the mouse connecting in the upper right corner instead of the difficult underneath-the-keyboard position. Further evidence for this - the Falcon having a darker grey case, with keys that were darker than the main casing, almost charcoal coloured (the reverse of the ST, which had lighter keys than the case), also the "early" Falcons (the only ones that made it to market) pretty much aping the STE bodyplan, with internal floppy drive in the upper right position, etc. Plus it's doubtful anyone with enough cash to throw around to buy a Falcon would have run it plugged into an ancient SM124 (proper code? the original atari colour monitor, anyway) or screenshotted it that way, loading a bare desktop in ST-low with the classic ugly green background (as graphics were supposed to be it's forte). If I remember right it loaded as a pale blue background, too.

• Oh yes, it had custom chips alright. Just not anything of the calibre of the Amiga, even after the STE came along (it's sound and graphics hardware still being slightly outclassed, merely not in the same laughable manner). However, what it did have tended to be a bit more solid than the Amiga... especially in the memory, serial port and disc drive departments.

• Wow, desk accessories, I forgot all about them :D something that you wouldn't see outside of the Mac until Windows 95 came along (with the system tray). Does it really count as multitasking though? It's similar to the MultiTOS of the MegaSTE and Falcon - holding one application completely frozen in memory while you work on another, then reanimating it and putting the currently active one to sleep when you want to switch, about as multitasking as most people still currently get with Word and Excel but not truly deserving of the title - but not even as sophisticated. It's just a maximum of six very simple programs, e.g. a palette control —panel, that you can pull up over your current (GEM only) program... and deactivate it at the same time. However, it's arguable that some other accessory programs achieved a degree of time-sharing multitasking; background music applications (argh!), time-delay screensavers, etc, as well as a plethora of viruses (most notably Cookie Monster and Slow)

• The Atari - Amiga - Commodore - Tramiel origins hullabaloo as reported on the page as it stands correlates closely from what was reported of the origins in magazines of the time when I first owned an ST (1990 onwards), and so, although it's likely only anecdotal in remit, I feel a little more inclined to believe it.

• Also these were the sources for "ST" meaning Sam Tramiel and "TOS" being the Tramiel O.S... make of that what you will! :)

• It did do better "overseas" than in the US, in Germany in particular... they loved it, and the TT too. No good reason why as far as I know, perhaps Microsoft and Apple were very slow on the draw to make versions of DOS, Windows and MacOS that could spiele Deutsch. Even in the UK, which seemed to be a pretty good market for the machine (various big names in the software biz both coming from here and cutting their teeth on the 16/32), Germany was notorious as having a passion for all things TOS, and was the venue for several of the biggest/best computer expos featuring a decent proportion of Atari stuff.

• The bee thing, personally I think it's just to show that the computer is "busy" in an easily understood fashion for newbies. Probably just to be different, and to be cute (particularly if you got one of the hack programs that animated the cursor with interrupts, so the wings flapped)... everyone else and their mother with a WiMP OS used an hourglass, after all, and it's probably a lot less annoying to stare at during a long-winded operation. It's a busy bee, that M68k.

contemporary Mac OS' used a wristwatch icon or a black & white beachball. only windows and OS/2 used an hourglass.

• Regarding it's place in education, I don't know if it really did that well. Several educational packages were available for it, but they did seem more home-oriented than focussed at schools. I only ever saw it used once, in a music/computing department (both hooked up with MIDI leads AND showing an animation - early multimedia?) when doing the visiting rounds of potential secondary schools around '91 or '92. Mainly through primary school and early secondary it was BBCs, 80186 (!) PCs, and the ever-present Acorn Archimedes. By the time I was doing sequencing in higher-year music classes (mid 90s), the focus was mainly on Acorns (did you know they came with MIDI, too? and some really, really horrible software even compared to 5-years-older ST freeware... Acorn Sibelius... yuck) and already shifting onto rather underspecced-but-catching-up PCs with MIDI adapter joystick-port plug-ins (really had to wait until the quicker 486s, they just couldn't keep pace with Windows and Sequencing at the same time, unlike the 68000... very odd). I persevered and did mine on the trusty 1040 STFM and a cheap Roland E15 synth, though :) Shame really, as it could do some great things education-wise, and not only in music - anyone remember The Magic Storybook, as featured on Rolf Harris' Cartoon Time? Or Talespin, or a hundred other creativity packages that would stil be fantastic today with a bit of an update?
• I remember Magic Storybook well, as I wrote it and appeared on Rolf Harris's Cartoon club with my daughter Rebecca. I agree that if updated to a modern PC it would still offer excellent creativity beyond anything available today. However the whole program was written by myself including coding, most graphics, sound effects and music. This was only possible due to the inbuilt capabilities of the Atari ST and the Amiga and the excellent software basic programmes of STOS and AMOS. Given time and an equivalent PC based package it could be rewritten but the graphical and audiovisual demands of todays sophisticated user would probably mean a team of people and a large budget. RMWD 12:19, 26 March 2006 (UTC) Richard Dunn

Oh wow, dude, you're a legend! I'm kind of shamed to admit we never stumped up the money to register any of our shareware to full versions (I was pretty young at the time, so somewhat out of my hands...) but that would have been one of them if the family had more funds. Certainly great fun to play with and pulled its weight in later years when the ST had been relegated to our 486's (!) poor cousin in keeping OUR cousins occupied (MSB, Thomas the Tank engine, Noddy... Buggy Boy :) and away from the PC. Never mind that it also kept us away from it as it was still fun :D Are you still coding? 82.46.180.56 23:55, 7 September 2007 (UTC)

• We really, really need to get some more up-to-date images for the software screenshots. Could nothing newer than 1989 be found? I didn't get into the ST scene until 1990 and it was just beginning to properly flourish. Was this was a renaissance, or just it becoming, slowly, a lot more popular in the UK whilst dying a grisly death in the US (where, I guess, most wiki contributors are)? There's a TON of great-looking examples that could be used, from 1990 thru to at least '94 or '95 (didn't get a PC at all until '95, and ST Format & a couple others soldiered on for at least another year).

Thanks for your patience... I had a lot to say... I really liked that old thing, and I've just realised, as it's been sat in my cupboard gathering dust (needs the joystick socket re-soldering), I missed it's "20th birthday" due to work pressures and other such chaos :( (it would have been 20th November 2005 - going by the license date in it's TOS "About" screen)

--- Tahrey1043 --- (yeah.. i'm also a VW fan, thats a handle from a Polo messageboard ;)

• I've deleted references to the mouse/joystick ports being in easier places on the STE - they were definitly still under the keyboard on mine (Bought in 1993). The left panel most definitly contained just the enhanced 15-pin joystick ports, the cartridge slot, and the MIDI connectors. Sadly I'm about 800 miles from mine, else I would take a picture. Tohya 12:36, 29 March 2006 (UTC)

I think there are a couple of mistakes on the page:

• The ST definitely had custom chips. The page http://www.sothius.com/hypertxt/welcome.html?1040stfm.html has pictures of every chip on the 1040ST. The CPU, the Motorola MC68901P (timer etc), sound, floppy, keyboard/mouse, midi and serial line controller were off-the-shelf chips. But even the earliest STs had 4 custom ships (GLUE, Shifter, MMU, DMA), and since the Mega ST they had five (Blitter).
• BTW i dont think it is a good idea to list these components in the overview
• It's wrong that over the years TOS got cooperative multitasking. Even the earliest version, TOS 1.0, had cooperative multitasking. However, you could not use it to run several applications simultanously. Only 'accessories' run parallel to the main application. When Atari finally released MultiTOS, TOS had preemptive multitasking. So either it should be said that it had simple multitasking from the beginning, or it should be said that it was single-tasking and only late versions got preemptive multitasking.

• The picture in the upper right corner of the page seems to be from an Atari Falcon, not from an Atari ST.

I noticed that the image is of unknown status. I'm pretty sure its a copyvio from Atari advertising. In any case, I own an STfm so I'll take a photo of mine and upload it under the GNU FDL.

The ST in education

The Atari ST was used in the ICS computer music course until PC soundcards gained in capability and popularity.

The ICS course included the ST, a MIDI keyboard and music software. The ST was dropped for a PC as ICS expanded their PC courses with 80286 and 80386 based computers.

ICS, or International Correspondence Schools, originated in 1891 as the Colliery Engineer School of Mines expanded its courses beyond the fields of mining, railroads and ironwork/construction.

I haven't been able to find more about ICS other than at some point in its early history it was based in Scranton, Pennsylvania.

If anyone can find a current website for ICS or a decent history of the school, please add the info.

Segment on naming

I commented out these sentences from the opening paragraph:

This is a plausible explanation, since the Atari ST also used a bumblebee as the busy mouse 
pointer image, which might be a reference to Jack's birth name (although the phrase "busy as 
a bee" was probably the more likely inspiration).

I have a few problems with this block of text:

• It doesn't say what Jack's birth name is (it is "Idek").
• It doesn't say what that name has to do with a bumblebee. Does "Idek" mean "bee" in Polish? I have no idea, and neither does the reader, because the article doesn't say.
• If it's Jack's birth name, why is it plausible that it is named after Sam?

In other words, it's a huge big mess. If there's a real explanation here, let's write it clearly, and move it to a "naming" subsection rather than leading off the article with it.

Also, the only source I could find for the theory that ST stands for Sam Tramiel is — you guessed it — Wikipedia. Can someone find a real reference that this belief had at least some traction? Otherwise, we should delete it as original research. Nandesuka 21:03, 5 September 2005 (UTC)

I can't provide documentation, but personal recollection indicates that we hypothesized ST and TOS expanded to "Sam Tramiel" and "Tramiel Operating System", mostly as a joke, back in the day (the day here probably being 1987 or 1988). -- Metahacker 23:35, 5 September 2005 (UTC)

I believe you, but using that as a source would be original research. Maybe we could find an Atari magazine or online "fan" site that discusses this issue? Nandesuka 00:04, 6 September 2005 (UTC)

ST was officially meant to stand for Sixteen-Thirty Two, referring to the 16-bit internal, 32-bit external architecture of the 68000. The follow-on product was named TT (32/32). Jim Tittsler

It is my recollection that the ST = Sam Tramiel was not only baseless speculation at the time, but I recall an interview with Sam Tramiel where he said it stood for 16/32 for the 16-bit external and 32-bit internal architecture. I believe the TT name put any remaining speculation to rest. I also recall that the same interview provided what the "T" in TOS meant (and it wasn't Tramiel, I think it was actually "The", but the memory is not clear). I'm not sure that explanation resonated, so the "Tramiel" theory continued. At any rate, I'm going to be bold and remove the ST = Sam Tramiel speculation from the article. -- Doug Bell 03:52, 7 January 2006 (UTC)

Although it's a bit late, I'd like to provide the answer, as it is simple: Tramiel's birthname is "Trzmiel", which is bumblebee. I'd suggest to restore the section on the "bumblebee cursor", with an appropriate comment that it actually is an urban legend. LMB (talk) 13:30, 4 January 2010 (UTC)

Just to add my tuppen'orth, the line always spun in ST Magazines (like ST Format) was the "Sam Tramiel" and "Tramiel OS" one, which might be where the urban legend comes from - unless they were just blindly repeating an existing one of course. But then, where do any of the other letter designations (and indeed, number codes) on the mid-80s machines come from? The _suffixes_ to the ST line make sense, but that's about where it starts and ends. 193.63.174.115 (talk) 15:47, 26 February 2016 (UTC)

Overseas Market

Need more info on the ST overseas, especially Europe, as they did way better than in the U.S. Pelladon 22:11, 20 October 2005 (UTC)

Also needs to discuss the DRAM shortages and tariffs that limited availability of the ST computers in the U.S. (STs were built overseas). The tariffs were to counter the Japanese dumping DRAM chips into the U.S. market. To counter the tariffs, Atari planned to open a US manufacturing plant, but the DRAM shortage delayed this. Atari did file suit against Micron Technology for price gouging. Europe didn't have this problem, so they had no shortage of computers and accessories. This was around 1988. --Pelladon 18:45, 21 April 2006 (UTC)

... As it turns out: http://www.atarileaks.org/ 24.23.210.81 (talk) 11:03, 19 April 2013 (UTC)

Would a tariff on DRAM per se also affect devices containing it? My ST appears to have been "Made in Taiwan", which it probably somewhere that also had a memory factory... or would have been able to import from Japan fairly cheaply and easily. After which you just transport the finished computers, already boxed, to the US for sale... 193.63.174.115 (talk) 15:49, 26 February 2016 (UTC)

Amiga, early history, etc.

The article is currently worded to suggest that Tramiel seriously considered using the Amiga technology, and was upset when they couldn't. I can't say for sure, but I don't believe this is the case.

I believe Tramiel bought Atari largely for its name, distribution and manufacturing. When he took over he fired practially everyone in the engineering and programming teams, ending development of all the Warner-era products. One of these was the advanced 68k-based workstation project.

I also believe that he basically saw Atari as a shell that he could dump his surviving Commodore people and recreate the company as Commodore II. "That'll show Gould!!". I'm not sure he even knew what projects Atari had on the go at the time.

Consider: if he really wanted to use an existing design for his 32-bit entry, he could have used the other workstation being developed. Alternately he could have just not pissed off the Amiga team. Does anyone have any reason to suggest that he could not have used the Amiga for his next machine, if he had wanted to?

No, I think he sued Commodore over the Amiga because he could. If you follow the logic above he was still furious over being ousted from Commodore, and this was simply one more way to piss them off.

Maury 12:39, 21 October 2005 (UTC)

But how do you know any of this? The only proof is the contract signed by Atari and Amiga. When Commodore bought Amiga, they broke Atari's contract, hence the lawsuit. I read an interview with RJ Mical (co-designer of the Amiga) where he stated Amiga ran out of money, which is why they went to Commodore. Maury, you're putting your own opinions and analysis in all this, and that is NOT what Wikipedia is about. --Pelladon 01:16, 24 October 2005 (UTC)

RJ Mical is well known among Atari historians as big a huge source of missinformation, who came on later in the design life and had personal gripes with the Tramiels because of the whole Handy/Lynx issue. There have been plenty of interviews and records on the Atari Inc. side (please don't confuse the contract with Atari Inc. to have been with Atari Corp./Tramiel - another of RJ's missinformation), and the suits and purchases are a matter of public record and were reported in newspapers, business periodicals, etc. of the time. --Marty Goldberg 19:49, 5 August 2006 (UTC)

Let me see, bottom falling out of the home gaming market, the cash cow. Atari Games (arcades) still with Warner. No cash flow. Tons of debt. So how is Tramiel supposed to not fire people? Wall Street loaned Tramiel lots of money, and they wanted results. You're not making any sense at all. --Pelladon 05:25, 25 October 2005 (UTC)

comparisons with megadrive

The sentence in brackets wondering why the ST didn't recieve many megadrive ports seeing as the systems were so similar, specifically mentioning them having the same Yamaha soundchip is erroneous and misleading.

Whilst The systems share the same 68000 CPU, thats about where the similarities end. The megadrive had relatively advanced 2d sprite, playfield and scrolling hardware, as well as a far higher on screen colour palatte (64 colours, although as this was made up from 4 16 colour palattes, each having to share one transparant colour, the practical total was 61 colours)

Regarding the soundchip, whilst both system have chips of yamaha design, they are totally different models with vastly different specifications. The Megadrive soundchip is a 6 channel FM synth of the sort commonly used in arcade machines and synthesisers in the 80s, where as the ST has a 3 channel PSG, of vastly inferior specifications (infact it's the same soundchip used in the 128k spectrums, and the amstrad CPC series)

The ST would be no more capable of running 'megadrive ports' with little coding effort than it would a port from any late 80's arcade hardware. Everything the megadrive does in hardware, the ST developer would have to kludge in software, and still require cpu time left to run the 68000 code of the megadrive original.

When you go beyond the fact the cpu is the same, and the soundchip was designed by the same company, there is little wonder that the ST was incapable of running megadrive or even amiga games towards the end of it's life, it simply was an inferior design when it came to running games. The amiga ended up being a more robust gaming platform and survived a few years more, although it too struggled to quite match the megadrive perfomance in certain types of 2d game, where the megadrive had the advantage of arcade style sprite/playfield handling.

As such i've removed that comment, as it directly contradicts the previous statement, and incorrectly suggests the megadrive and ST were relatively comparible in 2d game performance, so as to make a megadrive port a trivial thing.

It would have required some creative recoding for more complex games (maybe not that many as a lot of MD/Genesis titles were fairly simple platformers or shooters), a little graphical sacrifice and a complete musical overhaul, but I reckon it would have been largely up to the task for a lot of them. Sonic the Hedgehog made it to the Master System and Game Gear in mechanically very similar form, even if the level design was altered and graphical/audio quality reduced - an ST version would have been in-between and quite a bit closer to the MD original, given it's processing and graphical power was much more similar to the 16 bit machine than the 8 bits; it wouldn't have been lacking for scroll speed or sprites if the programmers had been canny, there's enough very fast ST shooters (eg Stargoose, Goldrunner; or even the example games with STOS working nicely in an interpreted BASIC environment!) that prove this point. Similar for a huge number of other titles, including e.g. Desert/Jungle Strike, Streets of Rage. I also note with interest that excepting the Sonic series, all the games available in currently marketed mini-Genesis consoles (of which I and my brother have a couple; Street Fighter II/Ghouls and Ghosts, and Sensible Soccer/Mega-Lo-Mania/Cannon Fodder) received wide cross-platform release including the Atari and (the animation-heavy SF2 excepted) didn't have much to compare between them on these two machines. I suspect it's more of a licensing issue and available media storage size compared to ~800kb floppy (later MD cartridges pushing 1mb thru to a "massive" 3mb of ROM, just short of the SNES 4mb monsters - however a lot of this may have been "wasted" on richer graphics and sound, and could have been worked around by splitting levels across discs) than one of pure processing grunt.

The reason there were no ports is simple ; the St was realeased in 1985, the Megadrive had it's best years from 1989-1994, they were not contemporaries.

As it happens, the ST had better performance in 3D than the Megadrive.203.26.122.12 (talk) 07:23, 16 June 2009 (UTC)

Absolute tosh, and I can prove it to you with a simple photo if you like: My "mini megadrive" plug'n'play console that has Mega Lo Mania, Sensible Soccer, and Cannon Fodder available to play, sitting next to the floppy discs of the ST versions of said games, which came out around '91~92. And it's not particularly unexpected for a fully bitmapped display computer with lower colour fidelity (and thus less data to move) to be better at rendering 3D environments than a sprite-and-tile based one. Though the latter's architecture did mean it eventually got a rather iffy port of Duke Nukem 3D, whereas the best the ST could come up with was a Wolfenstein knock-off. 193.63.174.211 (talk) 13:01, 24 May 2013 (UTC)

(my game examples are maybe a little dodgy, but they're the best I can come up with given the late hour, poor memory, and a games collection that thanks to a tight budget didn't often expand much beyond the discs supplied with the machine bought 2nd hand, a few pirate menudiscs from a friend, and magazine covers) 82.46.180.56 23:51, 7 September 2007 (UTC)

I found a photo of Jack Tramiel signing autographs at an expo in ally pally in prob 1988. Shouls I scan it and post it here ? robin48gx.

Please do, but it would be better served in the Jack Tramiel article. —Pixel8 16:15, 22 April 2006 (UTC)

neutrality dispute?

where? also... NEOchrome RULES!!! I loved that program... its far superior to any (affordable) pc equivalent. Umm, yeah. WookMuff 08:43, 26 April 2006 (UTC)

I have had a close read of this section and can't see anything that is portraying a particular POV. Tag removed.

Megabytes and Mebibytes

Personally, I believe that listing examples of the ST memory as 512 kilobytes but 1 mebibyte (rather than 1 megabyte) to be confusing. Although Italic texttechnicallyItalic text 1024kb is a mebibyte (that's 1024 kibibytes, not 1024 kilobytes), this is a naming convention that's not used as often as megabyte. Certainly in the original days of the ST, it was marketed with memory listed in megabytes, and to me it's rather pedantic to list memory in mebibytes here (especially as the kilobytes here are still kilobytes, and not kibibytes).

Will anyone be offended it the "MiB's" are changed to "MB's"?

Does anyone other than wikipedia use those bizarre terms??? --Pelladon 04:43, 17 May 2006 (UTC)

No. Some loser put those terms there and they should go back to using their SpeaknSpell. — Preceding unsigned comment added by 74.167.57.21 (talk) 22:33, 22 November 2015 (UTC)

I saw them in other places before Wikis were actually invented, but I still find the terminology absolutely ridiculous and some kind of strange modern politically correct thing as to not alienate those who are incapable of remembering that computer memory and storage units run in powers of 2 rather than 10... I was au fait with kilobytes being 1024 and megabytes being 1024 x 1024 whilst still in primary school (even if i couldn't remember the exact size of a meg without using a calculator). It's probably necessary I guess for the sake of encyclopaedic clarity, but still annoying as all hell and I refuse to RetCon my units in daily life as I've never heard the kibi/mebi/gibi/etc terms vocalised (the memory chips in my laptop are still staunchly five-twelve-meg). Maybe when we're more acclimatised to terabytes (tebibytes?) it'll be more widespread as the difference between the two systems will be practically 10% (1TiB = 1099511627776 bytes) - far more significant than the difference between 512000 and 524288 bytes for 512k... 82.46.180.56 23:32, 7 September 2007 (UTC)

Re-arrange?

I've done some minor cleanup, but I'd like comments on something a little more major.

As the article was before my edits, the "debut" section of the history included not only the debut, but a sort of rambling description of some of the follow-on models. Much worse, the Description section switched back and forth between historical details of the machine's introductions, as well as a description of the systems themselves.

I propose this should all be collected into the history section. That is, following Debut, there would be sections for the STfm's, the Megas, the STE's, and finally the Falcon. The description section would then discuss the "baseline" ST, with much-reduced subsections for the differences in the STE's and Falcon.

What say you all?

Maury 20:18, 5 July 2006 (UTC)

Feel free to improve the article, but check your facts and leave your Tramiel bashing out of it. Thanks. Pelladon 02:07, 6 July 2006 (UTC)

GEM stuff

Atari had originally intended to include GEM's GDOS (Graphical Device Operating System), which allowed programs to send GEM VDI (Virtual Device Interface) commands to drivers loaded by GDOS. This allowed developers to send VDI instructions to other devices simply by pointing to it.

What are the 'other devices'? What is this the main/preferred device? This section has been modified and now it is unclear. In a previous version the last sentence was actually this:

Devices can be hardware or software, so it's not limited to just printers. What's not clear about that? --Pelladon 17:55, 8 July 2006 (UTC)

This allowed developers to export high-resolution graphics to printers, plotters and other peripherals.

This sentence seems very useful, as it captures the idea that the 'graphics display' was somehow retargetable (something of which I was unaware). Shouldn't this idea be incorporated somehow?

--GrimRC 86.4.53.107 21:31, 7 July 2006 (UTC)

GDOS was device driver support, the sentence implies that it was a printer/plotter extension, which isn't wrong but you didn't need GDOS for printing high res to printer/plotters (some CAD programs had their own drivers for plotters). GDOS was important for vector graphics which were then extended to desktop publishing using outline fonts. GDOS really needs to go in the Atari TOS section. --Pelladon 16:59, 8 July 2006 (UTC)

---

Another removed sentence is this:

This ment (sic) that using GDOS generally required a reboot in order to load it into the operating system.

I thought this was true. Is it? Isn't this seeming inflexibility of TOS mildly interesting?

--GrimRC 86.4.53.107 21:31, 7 July 2006 (UTC)

The early versions did had bugs, but I've not heard of any issues with the newer GDOS versions. --Pelladon 16:55, 8 July 2006 (UTC)

---

And another removed sentence:

Performance problems in GDOS were supposed to be addressed by the BLiTTER chip, a hardware-based BitBlt implementation. This too was unavailable at launch, and would not appear in any of the ST designs until years later.

Isn't this (somewhat?) true? It at least seems plausible.

--GrimRC 86.4.53.107 21:31, 7 July 2006 (UTC)

No the Blitter was only for Line-A graphics. --Pelladon 16:55, 8 July 2006 (UTC)

Amiga contract

It was during this time in late July/early August that Tramiel representatives discovered the original Amiga contract. Seeing a chance to gain some leverage Jack immediately used the contract to countersue Commodore through its new subsidiary, Amiga, which was done on August 13th.

Hmm, kinda difficult to countersue when Commodore didn't own Amiga at the time (Tramiel discovered the contract before the Amiga/Commodore deal). Citation needed. Also, parts of this section reads like original research. —Pelladon 05:48, 4 August 2006 (UTC)

Regarding not owning Amiga, your statement is not exactly true. The purchase was announced in June of '84, money was exchanged, and the sale completed that August after approval by the board. Jack Tramiel discovered the contract after the Amiga/Commodore deal was announced and after his engineers were sued in late July (which included an attempt by Commodore to get an injunction on the production of the ST). He had in fact considered buying Amiga that previous April/May under his TTL company, and had meetings with the executives and engineers (Jay, etc.) but they decided against it after realizing he'd be dismissing most of them. At the time he knew nothing of the Atari/Amiga deal. (This is where a lot of the confusion comes from, most of it trumpeted by RJ Mical). He then moved on to discussions with Atari Inc., which were on and off again through May/June before Warner/Atari finally approaching him again and completing the sale. After moving all Atari Consumer properties (which included the buildings, projects, etc.) under Atari Corp., they immediately froze all projects pending evaluation. As stated (and I personally conducted the interview with his son Leonard), it was not discovered until Leonard and another employee were going through the records all during late July/early August to see what they had "inherited" in buying Atari Consumer. It was then Leonard discovered the cancelled check and terms. The "countersue" was a tactic pursued to do the exact same thing - stop Commodore's purchase of Amiga and in effect freeze its access to the Amiga computer to get Commodore to drop their suit against the Atari Corp. engineers and the feezing of the ST. Much of this material was also published in "On The Edge: The Spectacular Rise and Fall of Commodore" by Brian Bagnall. --Marty Goldberg 19:44, 5 August 2006 (UTC)

All the more reason to have citations. This is interesting stuff, but you have to be careful of NOT putting your analysis into this. Wikipedia wants facts and verifiable sources. If you have a sourceable quote from Leonard (that can be used to explain the countersue), that would be great because right now, that's your analysis. BTW: how come the info from the Wall Street Journal was discarded? The part where Commodore settled in favor of Atari? —Pelladon 02:19, 6 August 2006 (UTC)

I'm reading over articles from the WSJ, and a lot of what you're saying isn't substatiated. I strongly suggest you find references and citations to back up your story. more to follow...—Pelladon 07:56, 8 August 2006 (UTC)

Pelladon a) I'm not a newbie to Wikipedia, and I'm not prone to contributing "speculation". b) I'm a well known researcher and writer in the video game history arena and the video game industry in general. Much of what I shared in the rewrite is from personal interviews with the people involved over the last 6 years for a book that's being written and was also shared in interviews published online as well as the previously mentioned Commodore book. Curt Vendel also has most of the paperwork involved in the original Atari Inc./Amiga contract (as well as a plethora of other important paperwork). The one cited in this entry that appears on his site is simply the one he's put up so far. However, the suits you want citations on are a matter of public record. As far as the Amiga purchase being announced in July, here's an example: http://www.amigau.com/aig/2ndamiga.html. As far as the suits - From the August 21st New York Times at the time: "In July, in a separate court action, Commodore obtained an injunction against four former Commodore employees recruited by Mr. Tramiel. The injunction bars them from disclosing Commodore trade secrets in their new jobs at Atari." From the 06/20/85 San Jose Mercury news : "Both sides are claiming victory after a U.S. District Court judge in Philadelphia ruled that four Atari Corp. engineers wrongfully took confidential information when they left their jobs at Commodore Business Machines Inc. of West Chester, Pa. In an opinion filed Wednesday, Judge John P. Fullam ordered that the material be returned to Commodore. But he also cleared the four of charges of stealing secret computer tapes from Commodore". Likewise according to Leonard when I spoke to him (which was also backed up by other employees and paperwork), the ST was 95% done by the time his father bought Atari Consumer from Atari Inc. (the OS was the main part of the development left), which was bought for manufacturing and shipping rights. (Because of the time frame, this also strongly suggests that Shiraz did take the work he had been doing on a 68000 system with him from Commodore, which is also mentioned in the Commodore book). They had no clue about the deal ahead of time, Leonard still has the stamped (cashed) check he discovered in fact during the search through all of July (the freeze of all projects was done July 3rd). When the deal was discovered in late July his father used it as leverage (citing the chip issues published at the time in the New York Times article I quoted from) to get Commodore to back off in typical Jack style. The idea that they were to rely on Amiga technology for the ST was actually what was speculation (and the New York times correctly puts "and by some accounts" when mentioning it rather than presenting it as fact like other newspapers did), and further propogated by the spin put out by RJ. Everything I've said is substantiated, if you don't believe me then talk to Curt - as the largest Atari collector, archiver, and historian, he's always willing to help people out. --Marty Goldberg 16:40, 8 August 2006 (UTC)

Strongly suggests? There you go again, you need to put a sourceable reference, no ORIGINAL RESEARCH. Hey if you want to write a book on this, great, but Wikipedia is about sourced facts, not analysis. BTW: I never saw anything from Atari stating they were to use Amiga tech (other than the contract, that was the first and only reference). —Pelladon 16:52, 8 August 2006 (UTC)

No, there you go again. "Strongly suggests" was in reference to a side note I was mentioning about Shiraz during this "debate". Why present it as evidence that everything else I'm saying is "analysis" when they had nothing to do with each other? Unless you're here just to argue. This is not based on "analysis" (as some of the Wall street journal articles you seem to want to quote was). It is not a "proposed theory", these are things stated by the individuals involved in interviews. Likewise, its also been published in the previously mentioned Commodore book already. I've given way to much time to this and gone out of my way to give several references already and leads if you want more, I'd be happy to take this to wiki admins if you want to continue this route. --Marty Goldberg 17:06, 8 August 2006 (UTC)

MIDI

It was also the first home computer with integral MIDI support.

What about the Yamaha CX5M - this had a midi port and I am sure was launched in 1984. It was an MSX compatible. CX5M Info

Peter 81.99.41.208 21:50, 4 October 2006 (UTC)

The problem is that the CX5M was specifically a Music Computer and targeted as a music device only, and was only promoted as such (in fact it sold only though Yahama music equipment dealers). As you quoted, the ST was a "home computer". It was a general purpose computer designed for home use that also entered the music device market (as well as other markets). --Marty Goldberg 22:06, 4 October 2006 (UTC)

I don't agree. At least here in Norway, the Yamaha MSX computer was marketed as a home computer, although it probably sold mostly in music stores since that was where Yamaha's distribution channel was. You could make a similar claim about the ST being a "Music Computer", since running sequencer software was the one niche it actually managed to carve for itself. 84.48.79.209 00:20, 10 August 2007 (UTC)

First computer with a fully bit-mapped color GUI

Just being curious, when was the Atari ST released, and how does this compare to the Amiga 1000? The article says September 1985 for "full retail sales", whilst the Amiga 1000 has July 24 1985 for "introduced", with shipping also being in September. Does anyone have more exact dates for either of these machines? Mdwh 01:22, 7 May 2007 (UTC)

I'm pretty sure the Amiga was first- the monochrome only ST systems shipped first; there was a wait for the color ones. —Preceding unsigned comment added by Petchboo (talk • contribs) 13:31, 29 February 2008 (UTC)

Unless you're clueing us in on the existence of some rare variant of the machine that can ONLY display in monochrome, then I figure it probably still stands. The issue would have been a shortage of colour MONITORS, nothing to do with the computer itself. You could have bought one of those early "mono only" ones, and then a compatible colour monitor as soon as one was introduced (though really, you probably could have got by with a composite CGA (or Amiga RGB!) monitor and a converter cable), and boom - a full colour, bitmapped GUI computer.

So that brings us back around to the initial question: Which one went on sale to the general public first? 193.63.174.211 (talk) 13:06, 24 May 2013 (UTC)

Atari ST Graphics and Video Speed

I will be in the future write about the speed of the ST graphics hopefully soon.

Atari ST 512 Color Graphics

I will be showing some examples and comparisons to the Amiga hopefully soon.

Edited and made some corrections

I made a few, mostly minor, technical corrections. I also removed two full sentences:

"It had an innovative single-chip graphics subsystem (designed by Shiraz Shivji) which shared the full amount of system memory, in alternating clock cycles, with the processor, similar to the earlier BBC Micro and the Unified Memory systems that have become common today."

The above is a very nice looking paragraph, but there are more wrong statements in it than right ones. With so many wrongs and inaccuracies, I don't know how to replace the sentence with something correct in a similar "spirit". So I removed it.

"To make matters worse, the built-in floppy disk drives could not read as many tracks on a floppy disk as the built-in floppy disk drives on older models. While this was not a problem for most users, some games used the extra tracks as a crude form of copy protection and as a means of cramming more data onto the disk, and formatting as many as 86 tracks on an "80-track" disk was a common space-expanding option in custom formatting utilities".

The issue of how many tracks some ST drives supported, is not specific to ST vs STe. This topic has no place in that section.Ijor (talk) 01:37, 21 July 2008 (UTC)

I think it's important to talk about the memory in the ST. It gave a clear advantage over other computers including the Amiga. A 1 or 2 megabyte ST for example could use all of it's memory for graphics or sound with no wait states because 8 Mhz Ram went to Video, and 8 Mhz Ram went to the processor. This caused problems for accelators but made the ST a very fast 8 Mhz computer.

Rowbeartoe (talk) 19:07, 17 October 2008 (UTC)

Memory in ST is 4MHz (3.5Mhz in Amiga) not 8MHz. "Even memory accesses are given to CPU/Blitter/DMA while odd cycles are reserved or used by Shifter". ~CK 9:51, 5 Mat 2012 (UTC) — Preceding unsigned comment added by 95.41.251.15 (talk)

Man, I'm not sure, you know? The available resolutions, and the information I've been able to find about pixel timings etc, seem to suggest it's more like 2Mhz (and therefore 4MB/s, on a 16-bit bus, for the entire scan cycle), on a 3:1 interleave, not 1:1. The actual viewport, using the default modes (no overscan tricks) doesn't even crack 2MB/s with NTSC, and even less with PAL. I don't know why they would do this other than to make the shifter cheaper (and quicker to rush to market also), but it does mean the ST maybe gets a slight extra CPU and I/O speed boost vs the Amiga... which itself can display up to twice the bit depth (within it's own hard palette-register limits) in otherwise matching screen modes, suggesting almost twice the available video memory bandwidth... (the 7.14/8.00 timing difference only then evidencing in the width of the display within the border; the Amiga's pixels would have been wider than the ST's by about 12%, but it could still have had as many of them as the ST's borders were pretty fat) 193.63.174.211 (talk) 13:13, 24 May 2013 (UTC)

The extra cycles during the blanking periods are unusable to the CPU (or blitter on the STe) so no boost over the Amiga (except in RAW clock rate). On the Amiga they are usable and this reduces the clock rate advantage of the ST. — Preceding unsigned comment added by 166.147.120.173 (talk) 19:35, 30 July 2013 (UTC)

Just as a clarification to anyone scanning the talk page for extra info not in the main article, you can ignore much of this as it's actually inaccurate bunk and lax speculation on both sides (mine - which was 193.63.174.211 - and the others). Since then with some other research:

I'm afraid your understanding of how dram works is way off. The minimum speeds you're looking at concern CAS changes with RAS not changing. This doesn't happen on either machine. Memory access is assumed to be completely random. That means that RAS and CAS are both strobed on each memory access. A 68000 at 8MHz is going to need 500ns for a memory access. The DRAM is going to get both a row address and a column address during the 250ns towards the middle of the CPU memory access cycle. The numbers are a little longer on the Amiga, but the principle is the same. What this means is that memory can provide new data every 250ns (on the ST). While the CPU gives the MMU the address, the MMU is already completing a 250ns access for the shifter. This interleaving works almost all the time. There are cases, however, when the CPU starts a memory access after having run two cycles of internal processing. When it tries to initiate a memory access the MMU is already getting an address for the shifter. This forces the CPU to wait two additional cycles during the memory access. An instruction that normally takes 10 cycles, for example, will take 12. Things are a little different on the Amiga. If the display is currently not accessing memory, the CPU can initiate a memory access on any two cycle boundary. A six cycle instruction will still take six cycles if no other DMA is occurring. This is what reduces the ST's clock rate advantage over the Amiga. — Preceding unsigned comment added by 71.180.173.100 (talk) 23:59, 30 August 2018 (UTC)

Minimum memory speed for SIMMs or other upgrades is 120ns (vs 140ns for the Amiga), or in other words, 8Mhz (and ~7.2Mhz), giving a potential peak of 16mb/s on a 16-bit bus - however, there's a 1-cycle latency between the address being asserted and the data being available, and there's no burst transfer available, so it's actually half that. The MMU divides time evenly into 2-clock chunks between CPU and video during the active period, meaning the shifter gets 160 of the available 320 cycles, in 80 2-cycle chunks, during each of which it pulls a 16-bit word from the RAM. The cycles are at 8mhz, the shifter reads a word every 4th cycle (as it gets half the cycles, and can only read during half the ones it gets), meaning it's effectively 2mhz (and, with 16-bit words, 4mb/s). But the memory still has to be able to accept requests from the CPU, DMA controller, etc the rest of the time, and address assertions still count as a thing it "does" even if it's not accepting data input or producing output, so, it's 8mhz. (And the shifter pixel clock is actually 8, 16, or indeed 32mhz depending on resolution...).

The actual arrangement is a little complex, which is why the MMU is needed - the 68000 needs 4 cycles between asserting a read address and being able to read the data, whereas the shifter can take it straight away if so desired. So the CPU throws an address at the MMU, which puts it in the "CPU memory request" bucket, then directs its attention to the Shifter, providing it with a previously requested word from memory (it had actually sent the address to the RAM at the same time the CPU was making its own request). The Shifter then immediately asks for another address in the very next cycle, which the MMU chucks in the "shifter request" bucket at the same time as sending the CPU address to the memory, returning the data from that to the CPU on the next cycle. And if said data was a "read next address" instruction, the CPU may well immediately turn around and make a new memory read request of the MMU, which it puts in the CPU bucket at the same time as making the next request on behalf of the shifter, then giving that data to the shifter, which then asks for another address, which the MMU accepts whilst sending the CPU address.... etc. Or at least that's how it goes the whole time the shifter has a high voltage asserted on its "video active" pin, basically directly connected to another one on the MMU (which should also have a "video data ready" pin that sends a prompt to the shifter to accept whatever's on the bus as its new data). Hence even though the actions themselves are quite simple, you need a dedicated, custom-masked glue chip to deal with it all, else trying to sort it in software becomes a nightmare. For its complexity, though, the design is actually pretty elegant and works literally like clockwork (the syncopated up-up-down-down of the two chips both doing the same slightly delayed thing with the RAM via the MMU puts me rather in mind of a mechanical pendulum-clock escapement). The shifter also has a little of its own logic on board of course, in order to keep track of what mode it's in, count cycles and lines to know when to turn the active pin on and off (and to revert to showing border), deal with generating Hsync and Vsync, etc.

And the CPU can use whatever cycle it wants during the blanking periods AFAICT, it's not lockstepped to the beat of the shifter-MMU drum during that time unless some clever programmer or hacker has convinced the machine to display active video information in the overscan area (otherwise the shifter just shows the border colour, ie palette index 0). It's just unlikely that it *will* do, or that it'll go far adrift if it does, as so many 68000 instructions take a multiple of 4 cycles, and most of the odd-number ones are relatively long (11 cycles or more), so there's only so many of them you can fit into the remaining 192 clock cycles or less (dep. on resolution) on an active line, before it's re-synced by the video reactivating. Of course, in the upper/lower borders, anything goes. And if it's e.g. a Mega STe, or TT, it can effectively access the memory bus every 2 bus ticks (the former being a 16mhz CPU on an 8mhz bus, and the latter 32 on 16, with the additional benefit of a small on-chip cache to smooth over the cracks and burst-mode things in/out of single memory pages possibly on a 1-tick-per-transfer basis...), making the border areas potentially MUCH faster in terms of memory access than the display area.

Oh, and memory transfer speeds I've seen measured for the 8mhz ST are in the 2.6mb/s range when doing pure data shunting - compared to 2.3 for a 7.1Mhz, no-fastRAM Amiga. Which seems realistic for something which is capped at 4mb/s max most of the time and 8mb/s as its ultimate speed limit even with no display at all, and has enough other things to deal with other than pure reading/writing... 193.63.174.115 (talk) 16:15, 26 February 2016 (UTC)

Addendum: just to highlight the hairiness of all this, even just skimming another tab I had open in the background after closing this one, I came across some more forgotten reminders - the CPU actually DOES stay in 4-cycle lockstep throughout, because the MMU actually switches to running precautionary DRAM refreshes when the shifter is inactive (each memory read refreshes the RAM anyway, so whilst its active, there's no need for active refreshing - but if no CPU/etc access can be guaranteed outside of that time, you have to keep juicing it up about every 12 microseconds to avoid data fade). It doesn't actually need to do it anywhere near as often as it does, and is actually quite wasteful of potential execution speedups and energy use - but the simplest, cheapest, and most predictable (in terms of code execution times and synchronisation) method was to just spec the CPU (DMA, Blitter, etc) as having bus access for 2 cycles of every 4, and either the shifter or the refresh circuits being in play for the other 2. And the ST was all about cheap, simple, reliable, and easy to understand. Quite how they managed to drag a full 2.6mb/s out of it, then...

Also the memory was apparently specified for 250ns instead (though they cut corners by getting 262ns parts and overdriving the voltage very slightly so they would still work OK), which is a bit strange. The recommendation for buying STe SIMMs was always "120ns if at all possible, though you can chance your arm with 140 or 150 if you're prepared for potential failure". Maybe there's some crucial difference between SIMMs and raw DRAM chips that mean the former need to be rated for twice the speed of the latter? Or more correctly, that the latter can get away with being half the speed of the former (...and of the actual bus, too ... 250ns is really only equivalent to 4mhz)...?! 193.63.174.115 (talk) 16:57, 26 February 2016 (UTC)

Screenshots

Most of these seem to have been deleted with the like subsequently taken out by some autobot. They are mirrored here and the page looks much better with them. Anyway they can be restored? 212.159.69.172 (talk) 21:31, 7 June 2009 (UTC)

They were deleted because of image policy at Wikipedia. Non-free images (including screen shots) are to be kept to a minimum, and if possible replaced with free images. --Marty Goldberg (talk) 23:40, 7 June 2009 (UTC)

How the heck do you replace an illustrative screenshot with a "free" equivalent? It's a picture that shows what the program looks like when it's running. Surely it comes under "Free Use", unless you're suggesting they're all verboten? (Are you Nintendo?) 193.63.174.211 (talk) 13:15, 24 May 2013 (UTC)

"Tramiel's desire to replace nearly everyone at Amiga"

In the 7th paragraph of "Amiga contract".

Could that be right? Surely "Amiga" should be "Atari" DHR (talk) 17:46, 27 May 2010 (UTC)

"Atari already had several prototypes of computers which were superior to both the Amiga and ST"

In the last paragraph of "Amiga contract".

The supporting reference says "may very [sic] have been systems far superior to the ST's and the Amiga's were already completed". That hardly justifies the definite statement of superiority in the Wikipedia article.

My feeling is that the Atari ST was a very good design ("superior") because it was so minimal and yet powerful. Anecdotal evidence: when I bought one early on (1985 or 1986) it was perhaps half the price of an Amiga and actually superior for my applications (due to the mono monitor).

Changing the claim to "technically more advanced" is more plausible but there is precious little support for even that claim.

Since the team or teams that designed these prototypes were apparently dissolved, the chances of actually producing them quickly would seem low. DHR (talk) 18:02, 27 May 2010 (UTC)

Atari got through more advanced prototype designs than I've had hot dinners. There's a very good chance that it's true, but it ultimately means nothing as they never followed through on any of them, probably because, at the time, their final development and manufacturing cost - and therefore sale price - would have been prohibitively astronomical. 193.63.174.211 (talk) 13:17, 24 May 2013 (UTC)

Wavetable synthesis?!

The Amiga had sample-based synthesis, not wavetable-based. Totally different, only Creative started to mix these up for marketing purposes when they came out with AWE32. 178.48.242.69 (talk) 19:11, 11 March 2012 (UTC)

• The Amiga really does offer direct hardware support for wavetable synthesis, though in an admittedly limited way. The audio hardware was capable of directly playing multiple arbitrary waveforms of arbitrary lengths at arbitrary rates and included the option of using the wavetable of one channel to pitch modulate or volume modulate (or both) the wavetable of another channel. It was also common to use the CPU to handle a wavetable's envelope by writing to separate volume control register using an arbitrary volume control wavetable for each voice. And there was of course an interrupt driven mode where the audio hardware could signal the CPU to provide a channel's DAC with a new value for output making wavetable synthesis possible in software. I think Octamed was an example of this. Mc6809e (talk) 08:36, 21 June 2012 (UTC)

It probably all hinges on exactly what you consider "wavetable". If it's just playing samples from memory as if they're instruments, then any DMA sample replay hardware counts (like the Amiga's Paula, and the STe's soundchip), as does arguably the YM2149 once people figured out how to replay dodgy 4-and-a-half bit PCM audio through it.

However the definition I would recognise is one where you have specific hardware reserved for the task, with samples held either in ROM or in dedicated RAM, and it optionally takes the place of an actual synth chip in a manner transparent to the main computer. The simpler type (presenting as its own device to the computer, with a fixed amount of dedicated RAM that has to be pre-loaded with sample data) would be something like the Gravis Ultrasound card for the PC. A more complex and up-to-date one would be the Creative Soundblaster AWE derivatives, which have a bank of samples in a large (and sometimes socketed) ROM or pre-filled but updateable Flash chip, and can either be directly manipulated by particular software, or addressed by any General MIDI compatible software via the operating system as if it was a more normal OPL-based synth card.

What the Amiga had was more analogous to a Creative Soundblaster Pro with its OPL chip removed - not much more than a glorified 8-bit stereo DAC with some DMA and basic SFX functions incorporated to it. If you had a soundtracker running on the PC, or a game that used digital sound effects, the card would get an instruction from the CPU to pull particular sample data from memory, at a particular rate, and render it to the speakers via the DAC (with channel mixing either done on-card or by the CPU with the result stored in RAM or sent direct to the card, depending on actual hardware and software implementation) with suitable volume, panning, etc. Which is pretty much also what the Amiga and STe do. No dedicated sample RAM or ROM, no onboard functions that mean the CPU can chuck some very simple control sequences at it without needing to load sample data and/or a tracker program from disk but still get high quality music out of the red & whites... 193.63.174.211 (talk) 13:28, 24 May 2013 (UTC)

• I think what you're asking for is more than what is required for wavetable synthesis. The goal of wavetable synthesis in my view is to get beyond the fixed simple waveforms, such as sine, square, triangle wave, etc, and to allow arbitrary waveforms as the basis for synthesizing a new output waveform. With this in mind, it seems to me the requirement that samples be stored in ROM or flash is a step backward!
• In any case, the Amiga hardware is more than just a DMA driven DAC and this is what separates it from other systems like the Atari STE which are limited to simple playback of a waveform at a fixed rate. The Amiga hardware is more like a synth with the waveforms completely exposed and changable. Like other synth chips, waveform output frequency is controlled through a single register and can be changed while the waveform is being output. Likewise volume. There is also a control register which allows AM and FM modulation of one stored waveform by another. Granted, the number of voices is limited, but I still think the system meets what is minimally required for hardware wavetable synthesis.

Must say I've never, ever heard of that onboard AM/FM modulation thing before - can you post some kind of reference for that? As much as I knew, the STe's replay was actually slightly better than the Amiga, in terms of what a single channel could do (obviously it only had 2 instead of 4, but there was the YM alongside it), even if it needed slightly more CPU intervention. Amiga was fixed at 28khz for one thing, wasn't it? Whereas the STe could base its replay off a core 50, 25, 12.5 or 6.25khz rate (and, of course, be directed to either hold the current sample value, load the next and wait, or free-play until further notice / until a countdown timer zeroes out). However, I will have to go ask my local friendly chiptune community about this...

BTW the word I think you were looking for there isn't so much just "wavetable" as full-on "soundfont"... 193.63.174.115 (talk) 16:26, 26 February 2016 (UTC)

1040ST - First PC with 1Mb RAM?

This is clearly not true, unless you somehow exclude the Macintosh Plus which was released before the 1040ST (on January 16, 1986).

The cited BYTE article doesn't make this claim, but does support the $1/kB claim

--- Agree, the cited BYTE article is from March, and touts it as "upcoming". Not to mention, hadn't IBM made 1 MB standard in the PC-AT 5170 by then? This has been an unsourced claim for over 2 years, I'm removing it. 2601:1C2:1200:2E16:4862:4154:8A6E:E263 (talk) 07:57, 22 May 2021 (UTC)

Reference # 19 mistake

Hello I would like to bring to the attention of the author/s of the Atari ST article that the statement obtained from reference 19 is incorrect. The source referenced (Infoworld) actually states the complete opposite of what is written in the Wikipedia article - the Atari ST is NOT a Tramiel corner cutting product.

Thank you 217.65.57.154 (talk) 03:23, 23 March 2022 (UTC)

Atari ST Sales

Hi, sorry but the Atari ST sales of 2.1 million units is wrong. There's and article from ST Format magazine issue 20 (March 1991), page 7 where Atari announced it has sold 2.5 million ST-computers worldwide by the end of the year 1990, and 500 000 of them were in the UK at the time.

https://www.atarimania.com/mags/hi_res/atari-st-format-issue-020_7.jpg 84.231.221.42 (talk) 07:43, 23 April 2024 (UTC)