What could Atari have done better with the ST?

Ragstaff · Post by **Ragstaff** » Tue Aug 11, 2015 7:42 am

Greetings all. It's been a while since I've been here, thought I'd post a "silly" thread.
Pointless speculation but just for fun - what SMALL thing (or things) do you think Atari could have done to improve the life and success of the original ST? I think we've already seen discussions in the past where people say "it should have had a blitter... and a copper... and a 386DX processor, in built hard drive! 16MB of RAM! Voice activated, and it should have been cheaper!"

So some general guidelines are:

We are allowed the full use of hindsight which Atari didn't have at the time, so this isn't about scolding Atari or saying they "should have done X". This is about what "could" have been done, given we know where the industry went, what game and business trends occurred. So it could be a small mod that perfectly fits with what we know happened later.
Shouldn't add more than 10% to the price. I think at launch the 520ST was around $600US in 1985, $999 for the 1040 in Jan 1986. If you add too much to the price you're going into a space that the Amiga 500 covered well in 1987 $699US (although the ST would have been cheaper by then too), and ruin the ST's "power without the price". Back at launch in 1985, of course, the Amiga 1000 was $1295US. But we know we wouldn't have that budget advantage when 1987 came around. So I think the additions shouldn't make the 520ST more than ~$650 in 1985, and not more than $550 by the time 1987 rolled around.

There seems to be two directions to go.
One is to try to "patch" the ST's weaknesses against the Amiga which we know hurt it in gaming later in the 80's. We could try to add more colours, better graphics performance, better sound etc etc.
The other direction to go, which is better in my view, is to build on the ST's strengths over the Amiga (eg the strength it ended up having in music with the MIDI ports, or the raw computation power it had with the extra 0.5mhz, which made spreadsheets etc a bit quicker, and during the raytracing and fractal trends made the ST a little bit quicker to render images than the Amiga). You could focus on that, playing to it's strengths.

alexh · Post by **alexh** » Tue Aug 11, 2015 7:47 am

What does it matter? It's all dead and buried. Plus only Atari know the challenges of the day (the price of custom semiconductor chips, the cost of DRAM, the cost of marketing etc.)

The question should be what can we do better with our ST's today?

Ragstaff · Post by **Ragstaff** » Tue Aug 11, 2015 7:57 am

alexh wrote:What does it matter? It's all dead and buried.

It doesn't matter. Like I said, just for fun.

alexh wrote:The question should be what can we do better with our ST's today?

That's what the rest of the forum and tens of thousands of posts are dedicated to.

EDIT

alexh wrote:Plus only Atari know the challenges of the day (the price of custom semiconductor chips, the cost of DRAM, the cost of marketing etc.)

But they didn't know the future

Ragstaff · Post by **Ragstaff** » Tue Aug 11, 2015 7:58 am

Just to kick off some examples, some of my thoughts have been:

A chunky graphics mode. Playing to the ST's existing strenght. We know that the chunky-to-planar routines that coders have found on the ST mean it can do "new school" stuff better than the Amiga OCS - Ray's Wolf 3d port and many demos spring to mind. But if the ST had a chunky mode in 1985, it could possibly have surfed the FPS wave in 1991 and onwards to squeeze a little more life. Even if it was just an enhancement that came with the STE in 1989 it could have helped, but as we saw, developers were reluctant to cut out half the ST user base by making STE-only games. So this would have been cool, with a crystal ball, to put in the 1985 ST. And who knows what other uses may have been found in the mean time?
A simple blitter of some sort. This is more "patching" the ST to bridge it to the Amiga a little. The blitter would be nothing to challenge the Amiga's blitter of course, maybe even not as fast as the STE's later blitter. But the ST could have had a bit more dignity if it could scroll one image around smoothly without all kinds of programming tricks that took years to develop. No parallex scrolling, no half-screen sprites. Just imagine the crappy old ST games as they were, but with smoother scrolling and sprite movement. I really think that could have helped.

AtariZoll · Post by **AtariZoll** » Tue Aug 11, 2015 8:05 am

When I saw title, first thought was "oh no, not again!"

But your idea is good actually. However, you need to correct title - mistyping is there, and could would be better instead should .

Considering HW design and machine versions: they should (and only here I use word should) not use single side floppies at all. That made lot of troubles in near future, and worst of all - that is what actually caused Dungeon Master loading so slowly

But this is actually not a joke, but fact .

They could make video base address more flexible - so not on 256 bytes boundary, and that would cost practically nothing.

Horizontal scroll like in STE could be solved at minimal +cost - would need some extra logic in MMU and shifter.

On SW side, they could do much better Basic, better TOS 1.00. Better documentations. More system variables - for instance for simple mouse, joystick, keyboard state readings, then for hard disk support. Cookies could fit too (in shorter forms) in space free after system variables, and below $600 .
And maybe biggest mistake at start: setting ROM space in area of only 192 KB, what resulted in need to change ROM base address at STE, TT .

AtariZoll · Post by **AtariZoll** » Tue Aug 11, 2015 8:13 am

Ragstaff wrote:Just to kick off some examples, some of my thoughts have been:

A chunky graphics mode. Playing to the ST's existing strenght. We know that the chunky-to-planar routines that coders have found on the ST mean it can do "new school" stuff better than the Amiga OCS - Ray's Wolf 3d port and many demos spring to mind. But if the ST had a chunky mode in 1985, it could possibly have surfed the FPS wave in 1991 and onwards to squeeze a little more life. Even if it was just an enhancement that came with the STE in 1989 it could have helped, but as we saw, developers were reluctant to cut out half the ST user base by making STE-only games. So this would have been cool, with a crystal ball, to put in the 1985 ST. And who knows what other uses may have been found in the mean time?

A simple blitter of some sort. This is more "patching" the ST to bridge it to the Amiga a little. The blitter would be nothing to challenge the Amiga's blitter of course, maybe even not as fast as the STE's later blitter. But the ST could have had a bit more dignity if it could scroll one image around smoothly without all kinds of programming tricks that took years to develop. No parallex scrolling, no half-screen sprites. Just imagine the crappy old ST games as they were, but with smoother scrolling and sprite movement. I really think that could have helped.

Blitter in STE is not faster than blitter in Mega ST . And limiting factor is RAM speed actually.
Blitter as it is is actually very good for fine scrolling. But only few games used it - I know for sure only Ghost Battle. Look this:
http://atari.8bitchip.info/TestMe/HNH/HnH.html ST fine scroll .
You can perform full screen fine scroll with 50 fps in Mega STE .
However, as I said above, smooth scroll could be done with improved MMU+shifter only, so without extra and pricey blitter chip.

Ragstaff · Post by **Ragstaff** » Tue Aug 11, 2015 8:44 am

AtariZoll wrote:When I saw title, first thought was "oh no, not again!"
But your idea is good actually. However, you need to correct title - mistyping is there, and could would be better instead should .

Thanks, fixed!

AtariZoll wrote:Considering HW design and machine versions: they should (and only here I use word should) not use single side floppies at all. That made lot of troubles in near future, and worst of all - that is what actually caused Dungeon Master loading so slowly But this is actually not a joke, but fact .

That's a good one. Despite the relatively short time that single-sided drives were around, they added complexity for a long time after.

AtariZoll wrote:They could make video base address more flexible - so not on 256 bytes boundary, and that would cost practically nothing.

Horizontal scroll like in STE could be solved at minimal +cost - would need some extra logic in MMU and shifter.

That's great. I'm not a programmer so I don't know these things. It was that simple to fix, eh? If only!

AtariZoll wrote:On SW side, they could do much better Basic, better TOS 1.00. Better documentations. More system variables - for instance for simple mouse, joystick, keyboard state readings, then for hard disk support. Cookies could fit too (in shorter forms) in space free after system variables, and below $600 .
And maybe biggest mistake at start: setting ROM space in area of only 192 KB, what resulted in need to change ROM base address at STE, TT .

Another good one. OS and HW documentation I've heard lamented for many years, from a developers perspective. There could have been so much more software developed if some of these hurdles were removed at the start.

dlfrsilver · Post by **dlfrsilver** » Tue Aug 11, 2015 9:28 am

alexh wrote:What does it matter? It's all dead and buried. Plus only Atari know the challenges of the day (the price of custom semiconductor chips, the cost of DRAM, the cost of marketing etc.)

The question should be what can we do better with our ST's today?

Patching and correcting the original hardware defects would be indeed a good idea. A patch list of things to do to make the STF or the STE better would be great

Crazyace · Post by **Crazyace** » Tue Aug 11, 2015 9:31 am

My 2cents...

Chunky modes - also 256 colour chunky ( like the archimedes mode, with 16 pallette combined with fixed colours )
Faster 68000 - 10Mhz or 12Mhz if possible.
Writeable screen address registers
Writeable screen display start/end and display enable to allow fine scrolling and wider displays
Screen DMA like 8 bit and Amiga - so blocking 68k in 256 colour mode.
Full expansion bus rather than just cartridge port.

Ragstaff · Post by **Ragstaff** » Tue Aug 11, 2015 10:06 am

dlfrsilver wrote:
alexh wrote:What does it matter? It's all dead and buried. Plus only Atari know the challenges of the day (the price of custom semiconductor chips, the cost of DRAM, the cost of marketing etc.)

The question should be what can we do better with our ST's today?
Patching and correcting the original hardware defects would be indeed a good idea. A patch list of things to do to make the STF or the STE better would be great

Many changes needed to be "baked in" early, changing an individual ST now would break compatibility. But there may be some relevant ideas in the discussion!

Crazyace wrote:My 2cents...

Chunky modes - also 256 colour chunky ( like the archimedes mode, with 16 pallette combined with fixed colours )

Would have been nice but was hardware that could display 256 colours expensive to implement back then? It seems nothing had it, it must be for a reason? Frame buffer would have been 64kb, which isn't unusable on a 512kb machine (although for games, sprites, scrolling etc it would have been a lot more bandwidth required)

Crazyace wrote:Faster 68000 - 10Mhz or 12Mhz if possible.

I sometimes wonder about this one. I don't know how much more expensive a 10mhz 680000 was back then, also not sure if the whole motherboard would need to be brought up to 10mhz, which could have been expensive. Otherwise you have the CPU waiting on the hardware a lot, which could waste your precious 2mhz gainz

My similar thoughts are wondering if Atari could have been naughty and overclocked the 8mhz 68000 to 8.5mhz or 9mhz, and matched that speed on the motherboard (allowing the motherboard to safely run at 8.5 or 9mhz may have been expensive work though). Motorola may not have been happy.

Crazyace wrote:Writeable screen display start/end and display enable to allow fine scrolling and wider displays

I'm not a programmer, but I assume this is to make double and triple buffering easier? No need to copy frames into the frame buffer, just change screen address. The fine scrolling part is the MMU + shifter additions that AtariZoll mentioned above?

qq1975b · Post by **qq1975b** » Tue Aug 11, 2015 12:02 pm

This is interesting but I should shut up...Only members with a lot of ST hardware knowledge and programmers can help here (as AtariZoll did) because they know the bottlenecks and lacks they found on the ST that could be "easily" solved or predicted to have a more efficient machine.

Only few questions of things I have seen that are not (I think) expensive:

Stereo sound?
Fast ROM access?

One problem of the Atari back on that days was the need of two monitors...or monochrome monitor +TV (not very good quality)...but I don't know if this could have been easily solved...

Edit: With stereo sound I mean make the YM2149 work in a stereo way if needed (1 channel left, 1 right, 1 both or all three in left&right for mono mode)

exxos · Post by **exxos** » Tue Aug 11, 2015 12:25 pm

I'd be happy is they had the CPU which could run out of sync properly from the rest of the system. There probably would have been a lot more upgrades and properly would have kept the Atari alive somewhat longer.

Post by **joska** » Tue Aug 11, 2015 12:49 pm

I guess they could have done all sorts of things better with the hardware. But this was 1984/85. The ST was actually pretty marvellous. But IMO the one thing they really, really should have done was to spend a lot more time on the software. They should have made a better OS (Less bugs! A more feature rich AES and VDI) and delivered every ST with a proper development kit with a proper, powerful GUI construction tool and more programmer-friendly GUI libraries. Then we would have seen much more software for it, and much more powerful software.

junosix · Post by **junosix** » Tue Aug 11, 2015 12:50 pm

EDIT - just realised I made a massive post of my ideal ST timeline, completely missing the point of the original post! Yeah, reading through everyone else's responses I pretty much agree with the suggestions. 256 colours chunky (no need for a blitter then either? Could the hardware also be simplified by only having a palette of 256 colours rather than 512? Not necessarily a downside if you were allowed more colours on screen), hardware scrolling, STE sound from the start, with the late 80s ST revisions having a more Amiga-like soundchip by 1989 (maybe with 8 channels?)

swapd0 · Post by **swapd0** » Tue Aug 11, 2015 12:55 pm

I would be happy with three extras, IMHO they are very easy to implement.

- Chunky and planar mode
- Screen memory at any address
- Change video address at any time, not per frame.
- Use two pokey instead of yamaha sound chip?

Eero Tamminen · Post by **Eero Tamminen** » Tue Aug 11, 2015 6:14 pm

Ragstaff wrote:
Crazyace wrote:Writeable screen display start/end and display enable to allow fine scrolling and wider displays
I'm not a programmer, but I assume this is to make double and triple buffering easier? No need to copy frames into the frame buffer, just change screen address.

Changing screen address / using multiple buffers was no problem. However, there were alignment requirements which prevented smaller screen address changes needed for fine scrolling.

junosix · Post by **junosix** » Tue Aug 11, 2015 7:16 pm

swapd0 wrote:Use two pokey instead of yamaha sound chip?

The reason the YM2149 is in there is that it provided three functions - soundchip, parallel port, and floppy disk signalling, which I'm not sure the Pokey was flexible enough to do?

AtariZoll · Post by **AtariZoll** » Tue Aug 11, 2015 7:20 pm

Eero Tamminen wrote:..
Changing screen address / using multiple buffers was no problem. However, there were alignment requirements which prevented smaller screen address changes needed for fine scrolling.

Exactly . Some games use triple screen buffer: Giana Sisters, Hard 'n' Heavy .
Considering 256 color mode(s) - that would eat almost all RAM bandwith, so would slowdown CPU RAM access a lot. Something like Amiga HAM would be more appropriate . Don't forget that TT and Falcon RAM is 32-bit, in Falcon faster chips.

Crazyace · Post by **Crazyace** » Tue Aug 11, 2015 8:53 pm

With a main pallette of 512 colours, and 16 colour entries a 256 colour mode where 4 bits are pallette, and 4 bits replace lower bits of RGB (1:2:1) would allow a selectable 256 from 512 without much extra silicon.
With an 8MHZ 68000 it would only take all memory b/w during the active 320x200 area - 47% of a frame at 60Hz - a reasonable price for a higher res ( and a 640 pixel 16 colour mode would be the same )
If the 68k was overclocked to 9MHz the display could have matched the IBM mono modes ( 360/720 pixels wide screens ) with the 'normal' ST modes taking no hit, and 256 colour / 16 colour highres modes taking a 48% hit - not crippling )

calimero · Post by **calimero** » Tue Aug 11, 2015 9:14 pm

exxos wrote:I'd be happy is they had the CPU which could run out of sync properly from the rest of the system. There probably would have been a lot more upgrades and properly would have kept the Atari alive somewhat longer.

hi exxos! I love your thread about overclocking everything in ST

ST is really clean and tidy design. From plastic case down to CPU and memory milliseconds

but than I read that there are wasted memory cycles in ST, exaggerate refreshing of DRAM...

joska wrote:They should have made a better OS (Less bugs! A more feature rich AES and VDI) and delivered every ST with a proper development kit with a proper, powerful GUI construction tool and more programmer-friendly GUI libraries. Then we would have seen much more software for it, and much more powerful software.

if you are interested, there are infos from Mike Fulton regarding internal development of TOS (7 post/texts so far): http://www.fultonsoft.com/category/atar ... -atari-st/

btw what are bugs in TOS? I, as a user, never see some. If application works than it works rock solid!

Post by **joska** » Tue Aug 11, 2015 9:19 pm

AtariZoll wrote:Considering 256 color mode(s) - that would eat almost all RAM bandwith, so would slowdown CPU RAM access a lot.

I agree, the ST wouldn't be fast enough. In addition to the bandwidth issue, the CPU would have to shuffle around twice as much data. Bitplane graphics is not without advantages, especially when combined with a blitter.

I was always more of a "serious" user ("serious" in the sense that I used my ST for schoolwork and programming in addition to gaming) so for me a proper overscan mode would have been very useful. That would probably have benefited games and demos too.

calimero · Post by **calimero** » Tue Aug 11, 2015 9:27 pm

Crazyace wrote:Full expansion bus rather than just cartridge port.

What are limitations of ROM port?
- there are no write? AtariZoll (ppera) made fairly simple modification to ST that enable full speed read/write (~4MB/s)
- more than one device on ROM port? Is it possible?

Ragstaff wrote:Would have been nice but was hardware that could display 256 colours expensive to implement back then?

There was not at all support for chunk (non-index color modes) in VDI until development of Atari Falcon030. Read Mike Fulton post for more info, to see at what stage technology was back then: http://www.fultonsoft.com/revisiting-ge ... st-part-5/ (subsection: "A Palette-Based Abstract Virtual Device")

but maybe something like Crazyace said: like in Archimedes.

@crazyace can you explain 256 color mod in more details? I do not understand how it should work...

exxos · Post by **exxos** » Tue Aug 11, 2015 9:32 pm

calimero wrote: hi exxos! I love your thread about overclocking everything in ST
ST is really clean and tidy design. From plastic case down to CPU and memory milliseconds

but than I read that there are wasted memory cycles in ST, exaggerate refreshing of DRAM...

I not heard of "wasted cycles" someone else might know more about the RAM access than me

Glad you like the threads, even though not updated at the moment, I am still working hard on the stuff each day

I should probably update it actually

I don't think "clean and tidy" is a good description

When you really get down to it, the ST is a awful bit of kit. I think Atari had serious difficulty in getting the PCB layout correct to get good signals between various chips. As I found out on the MEGA ST, Atari seem to make things worse on those later machines. It is not easy when in the mhz range of signals and its probably why Atari had so many revisions of the motherboards. Overall, its a wonder any ST ever made ever booted at all things are really that bad. Mix that in with 16mhz boosters etc, and things turn into a huge headache

I think my vote would be that Atari got someone to design PCB's who knew what they were doing

But I guess that is a little harsh, as it was early computing years back in the 80s Atari of course did a great job with the ST machines. Just I wish they fixed PCB issues better or at least added in some resistors to problem signals.

mlynn1974 · Post by **mlynn1974** » Tue Aug 11, 2015 9:48 pm

Yes, idle speculation but a good bit of fun.

Atari should have:
1. Implemented a low byte for the video memory.
I don't know why this wasn't thought of at design time.
2. SIMMs from the beginning.
The ST was the first machine with 1Mb under $1000 but it would have been better to be able to upgrade the memory easily.
1Mb in every machine would have been a big plus.
3. No single sided drives.
Again cost for the first STs meant they had to use single sided drives, but doubles would have encouraged better\larger graphics by default instead of cramming onto a Single Sided for most of the life of the machine.

The good thing about all the machines back in the 80s was they all came with decent manuals and most were bundled with a decent version of BASIC so anyone could learn to program on them. They got that right!

calimero · Post by **calimero** » Tue Aug 11, 2015 10:28 pm

exxos wrote:I not heard of "wasted cycles" someone else might know more about the RAM access than me Glad you like the threads, even though not updated at the moment, I am still working hard on the stuff each day I should probably update it actually

well mc6809e and others discus regarding Shifter and CPU access memory and it looks like that memory had lot of bandwidth untaped:

http://www.atari-forum.com/viewtopic.ph ... 73#p201441

Atari-Forum