What could Atari have done better with the ST?

[Mindthreat]

@Mindthreat: I forgot something to say in my first comment of your first comment: you are off topic. You just criticize, but did not say anything about better solutions.
For instance, the monitor case. How Atari should solve sharp, non-flickering resolution of 640x400 px monitor without it cost a fortune in 1985 ?
If it would support color modes, then it will be: very expensive, cost more than 2 monitors what were released then. + high-res mode would be not so sharp on color CRT with color masks. What Atari did was actually very good and solution for everyone: who wanted only to play games and maybe little programming could go without buying any monitor. Who wanted serious work bought mono monitor. And people with money bought color monitor (too) .
I would say that it was really good policy/design .
Finally, TOS was not made to impress people with it's speed. But you talk rather about part of it: Desktop (as is pointed already) . I would not call it slow, and icon sizes were good, considering that it is not Windows 95 and later, and never were there many icons, so large ones fit without problem even in low res. Desktop did it's purpose well - starting SW, some basic informations, floppy format and copy functions. Who wanted more and faster could choose among thousands of diverse utilities.
Should I say now that Windows and it's Desktop (Explorer) is utter crap because I use Total Commander in most time ?

My response was to what they could have improved upon or had done better with the ST, but you're right, I didn't provide solutions. Atari should have had something that would have allowed for all programs/games to run on any output provided, even if it meant games in B&W., or programs crammed into a tiny window instead of isolating it to one specific output only and after a quick Google search, as stated before, I found that a muli-sync monitor would have resolved this issue but it wasn't something that Atari offered and price for such a monitor is a different topic really. I'm not sure what hardware restrictions there were or why it was only one or the other but that's how it was. I checked out the 1435 (Never owned one but would love to, only ever had the SC1224 and SM124) and it doesn't appear to be Multisync, just a 1084 in Atari casing. *And apparently there was a solution for this, to run monochrome-only programs you could use to emulate Hi-Res mode called Sebra, though I know nothing about it and it's not a solution provided from Atari directly.

So TOS wasn't made for speed... well then, maybe that's something they should have worked on and improved. How they do that is beyond me but it clearly didn't happen anyways, even almost 10 years later.

And when I mentioned how overly large or huge the icons were on TV, I was suggesting that the improvement could have been for smaller icons (even if a little bit) but I thought that would've been obvious. I remember resizing windows and moving around icons or the general refresh of it all being painfully slow in color but maybe I'm wrong or maybe something was wrong with my ST, but I don't think so because I definitely remember the Falcon being the same way without an accelerator... I am going from memory and I did state that it's been a long time since I've touched one. I did have the flashback though as stated to watching the Computer Chronicles video so I did see it again and the slowness hit me again. I don't come with full criticism and I'm not bashing the ST by any means, I like the machine and definitely plan on getting another one (STe) when the right one crosses my path. If we want to start another thread on what Atari did right with the ST and how great it is, I'll post in that one too and assure you, the good outweighs the bad.

[DarkLord]

I have to admit, I don't "get" the whole TOS is slow thing.

Sure, the very first, original TOS left a lot to be desired, but lets not forget
the phrase, "for its time".

I'm still running TOS v1.04 on my Mega ST4 and even with my Adspeed accelerator
turned off, it's not "painfully" slow.

<shrugs>

[Retrogamer_ST]

Those are "mono compatible" games, not mono-only games.
I maintain that for most users a colour monitor was enough. In the whole library of ST software there wasn't much that required monochrome, and the real professional software that did was for people who could easily afford a monochrome monitor. Iirc none of that software like Calamus was very cheap at the time

There's a lot of mono only games. I have hundreds of them.

Just about every of them is Public Domain, and in german only. SM124 was very popular among the german Atari ST users.

About serious software. I used lots of serious appz, some of them was mono only and some of them could be used in medium resolution as well. The option to use medium resolution was only there if the user didn't owned a monochrome screen. Always run your appz in high if you're using an emulator or owning a Atari SM 124 because it's lightyears better quality. Higher resolution, no scanlines and a much more stable screen to work with.

When i first got my SM 124 in the 80's it was like looking at a paper, rock steady and pin sharp.

[galax]

I maintain that for most users a colour monitor was enough.

For many users a mono monitor was essential- in places such as Germany it was the default. 'Most users' seemed to use their purchase of a home computer as a way to slip a games console past their parents (I have an amazing Chinese NES clone built into a PC-style keyboard that took this to the extreme), so you are probably correct in that statement.

A mono monitor was the first piece of hardware I bought for my ST, it cost about £100, which was equivalent to 6 weeks paper round or 4 full-price games The family 14" TV had an RGB input and was fine for games, I lusted after but never seriously considered a colour monitor at about double the price of mono. I used Macs on work experience at a printers at around the time I got my ST, and got used to the stable, crisp, high resolution mono monitors- an ST was the only realistic way of me achieving a similar display at home.

I had a bunch of copied mono only software I would never have been able to afford such as Calamus, and later bought stuff such as GFA Basic, Protext and Devpac, which would have run in medium res but not with the crisp text and high refresh rate. Spent many hours programming and word processing. For me the ST was a mac-like high res mono machine, that as a bonus I could also use to play fun games and mess around with art programs etc.

How Atari should solve sharp, non-flickering resolution of 640x400 px monitor without it cost a fortune in 1985 ?
If it would support color modes, then it will be: very expensive, cost more than 2 monitors what were released then. + high-res mode would be not so sharp on color CRT with color masks. What Atari did was actually very good and solution for everyone: who wanted only to play games and maybe little programming could go without buying any monitor. Who wanted serious work bought mono monitor. And people with money bought color monitor (too) .

It was an amazing solution, it is hard to appreciate the how difficult a problem a cheap high resolution display was, now that we are used to ultra-stable, cheap, and high resolution colour LCD displays.

Atari should have had something that would have allowed for all programs/games to run on any output provided, even if it meant games in B&W.,

The mono monitor refresh rate is different to both NTSC and PAL colour, timing sensitive programs (e.g. most games) would have just crashed or gone horribly wrong, and even those that ran would have been at the wrong speed, a generally pretty awful experience. If you mean calculating pixel colours like those colour/mono display 'emulators' did, this would have required more horsepower than even a dedicated 68000 to keep up.

There's a lot of mono only games. I have hundreds of them.

Just about every of them is Public Domain, and in german only. SM124 was very popular among the german Atari ST users.

About serious software. I used lots of serious appz, some of them was mono only

There was some incredible German PD software, both 'serious' and games- as far as I remember almost all mono-only. It helped for me that at the time I was learning German, the occasional error message would confuse me though

[christos]

I have to say that the earlier TOS version do seem a bit slow on a machine without a blitter. Blitter machines on the other hand are just fine. Also there is no problem with the accelerators either. It's a much better experience.
Still graphical environments at that time were also quite slow so it's not a big difference. The Amiga workbench was faster for moving windows, resizing etc but TOS isn't that far off. Especially at the part where disk access was involved.

The other thing atari could have easily added was hardware scrolling. That would have helped the machine a lot with the games.

[Eero Tamminen]

When i first got my SM 124 in the 80's it was like looking at a paper, rock steady and pin sharp.

And the picture in it looked better than on Macs at school. Monitor was larger and had higher refresh rate.

Vconsole under MiNT made my STfm pretty decent Unix terminal later in its life when I started to move into Linux etc.

[Retrogamer_ST]

When i first got my SM 124 in the 80's it was like looking at a paper, rock steady and pin sharp.

And the picture in it looked better than on Macs at school. Monitor was larger and had higher refresh rate.

Vconsole under MiNT made my STfm pretty decent Unix terminal later in its life when I started to move into Linux etc.

A fun fact

The tube in SM 124 was made by Goldstar. In that time Goldstar was a both hit and miss, a company that often made low budget electronics. Perhaps Atari was picky about SM 124 because this monitor was truly awesome for it's time.

Later Goldstar changed name to LG and today it's a big name all over the world.

[calimero]

When i first got my SM 124 in the 80's it was like looking at a paper, rock steady and pin sharp.

And the picture in it looked better than on Macs at school. Monitor was larger and had higher refresh rate.

I can confirm that ST has better monitor than Mac Classic since both are on my table:

[AtariZoll]

I think that we said almost everything about monitors, so let's talk a bit about lacking expansion bus.
Such thing existed on almost every home computer of that time, but Atari choose so called closed architecture - with some special connectors - as DMA/ACSI, cartridge . They even sold laser printer for ACSI port. I think that it was dictated in big part by idea to self sell peripherals - like Megafile and similar. But, as it was many times before and later. third party manufacturers just offered better and cheaper solutions. In case of hard disks ICD was ahead for instance.
On the other side, that closed architecture caused other expansions as more complicated, and hard to build in machine - like RAM expansions, accelerators, ROM expansion or just simple TOS change - all it needed special solutions with daughter boards and similar.

So, as I said it years ago in similar thread, Atari should do universal expansion bus from start, and that would not raise price much more than cartridge port (used not much, and then used mostly not as ROM expansion) - instead 40 pins, it would have about 80 .

[qq1975b]

Absolutly right. Third party developers focused more on PC (& Amiga).
It was PC's long term strengh (VGA;AdLib,SCSI...cards).

[rabindranath72]

One of the ST designers (he has a blog as DadHacker) mentioned the possibility of implementing a cheap and simple but "proper" MMU (offering very simple forms of protection and relocation). With a socketed 68000, replacing the latter with a 68010 (probably already cheap by then) we could have had a true multitasking OS (he mentions there were talks of porting UNIX). I'd emphasise: true multitasking, not like the Amiga OS's which is more a "cooperative" scheme that requires the applications to "behave" (yeah I always get a good laugh when Amiga users talk about AmigaOS being a true preemptive OS).
Seeing MINIX run better on a 8088 (which implements a simple protection scheme in hardware) than on an ST is painful

[calimero]

^
First, I agree with dadhacker sugestion regarding MMU (maybe we could have virtual memory before 68030 )

But why do you say that amiga os was not preemptive? Amiga kernel, exec, was preemptive (it could interupt proces and switch to another without consensus from app/proces itself) but what amiga lack is memory protection (no mmu).

I read that SUN solve MMU problem in early SUN workstations with TWO mc68000 - one would run code one step ahead and there was mechanisim to alert other mc68000 if there was ilegal memory address.

[AtariZoll]

One of the ST designers (he has a blog as DadHacker) mentioned the possibility of implementing a cheap and simple but "proper" MMU (offering very simple forms of protection and relocation). With a socketed 68000, replacing the latter with a 68010 (probably already cheap by then) we could have had a true multitasking OS (he mentions there were talks of porting UNIX). I'd emphasise: true multitasking, not like the Amiga OS's which is more a "cooperative" scheme that requires the applications to "behave" (yeah I always get a good laugh when Amiga users talk about AmigaOS being a true preemptive OS).
Seeing MINIX run better on a 8088 (which implements a simple protection scheme in hardware) than on an ST is painful

I was experimenting with memory remapping some years ago. It was connected between MMU and RAM, of course. Basically, it is simple. Indeed, that and memory protection in MMU would not add much to costs.
But idea of Unix on low priced home semi professional computer in 1985 seems too early for me. TT and Mega STE were machines where it would fit ideally. Don't forget that virtual memory requires hard disk - without it it is practically useless.

[joska]

I'd emphasise: true multitasking, not like the Amiga OS's which is more a "cooperative" scheme that requires the applications to "behave" (yeah I always get a good laugh when Amiga users talk about AmigaOS being a true preemptive OS).

Preemptive multitasking does not need an MMU. Both MiNT and MagiC are good examples of preemptive multitasking on a 68000.

[AtariZoll]

I think that here some confusion was made - first talking about MMU, memory protection, then preemptive multitasking. What is not same thing.
True that multitasking can work without MMU and memory protection . But only with applications following rules, and not writing anywhere in RAM.
Memory protection will prevent that app write in OS workspace or other app's memory segment. MMU can make app written for specific RAM area to run in different physical RAM space.

[rabindranath72]

I know they aren't the same thing, I was talking about the AmigaOS type of multitasking which isn't really pre-emptive, with the additional problem of a lack of MMU which requires the applications to behave. Sorry for the confusion.

[joska]

I was talking about the AmigaOS type of multitasking which isn't really pre-emptive,

In what way isn't AmigaOS really preemptive?

[rabindranath72]

I was talking about the AmigaOS type of multitasking which isn't really pre-emptive,

In what way isn't AmigaOS really preemptive?

Because strict preemption doesn't require a task's cooperation to be preempted; but this doesn't happen in AmigaOS. I think Linus Torvalds was the first to point out this fact, and IIRC he called AmigaOS's multitasking policy more "collaborative" than pre-emptive. IIRC AmigaOS is always in user mode, so Exec (the scheduler) doesn't really have any privilege. With no context switch, it means OS's response is quite fast, but the downside is that any application can hog the system if it doesn't voluntarily relinquish control to Exec.

[joska]

An AmigaOS process can explicitly disable pre-emption, that's true. But when multitasking is enabled, it *is* pre-emptive. MiNT and MagiC has similar mechanisms to allow programs to run in a single-tasking mode.

[rabindranath72]

An AmigaOS process can explicitly disable pre-emption, that's true. But when multitasking is enabled, it *is* pre-emptive. MiNT and MagiC has similar mechanisms to allow programs to run in a single-tasking mode.

Yeah, but a task shouldn't be allowed to disable pre-emption at will; the decision shouldn't be in the task's control. Hence the exception Torvalds raised with the concept of AmigaOS being pre-emptive.

[AtariZoll]

.... IIRC AmigaOS is always in user mode, so Exec (the scheduler) doesn't really have any privilege. With no context switch, it means OS's response is quite fast, but the downside is that any application can hog the system if it doesn't voluntarily relinquish control to Exec.

I don't think that it's possible that AmigaOS is always in user mode. Simply, because all interrupts are performed in supervisor mode, and OS handles them normally. Multitasking OS should be able to break app at any moment, and that's possible only with CPU interrupt. And on Atari, with SW not designed for multitasking that's only way for switching between apps.
I don't know about Amiga OS, but if it is on app. that perform some task switch related OS call, it is really not some hmm. quality multitasking. And it must be in user mode when performs that task switch OS call - very strange, especially it it is via trap But I forgive them - it was 1985/87

[rabindranath72]

.... IIRC AmigaOS is always in user mode, so Exec (the scheduler) doesn't really have any privilege. With no context switch, it means OS's response is quite fast, but the downside is that any application can hog the system if it doesn't voluntarily relinquish control to Exec.

I don't think that it's possible that AmigaOS is always in user mode. Simply, because all interrupts are performed in supervisor mode, and OS handles them normally. Multitasking OS should be able to break app at any moment, and that's possible only with CPU interrupt. And on Atari, with SW not designed for multitasking that's only way for switching between apps.
I don't know about Amiga OS, but if it is on app. that perform some task switch related OS call, it is really not some hmm. quality multitasking. And it must be in user mode when performs that task switch OS call - very strange, especially it it is via trap But I forgive them - it was 1985/87

Who said AmigaOS was a quality OS?

[joska]

Yeah, but a task shouldn't be allowed to disable pre-emption at will; the decision shouldn't be in the task's control. Hence the exception Torvalds raised with the concept of AmigaOS being pre-emptive.

Well, you wouldn't want to use an Atari ST or Amiga 500 where you could not disable multitasking

AmigaOS multitasking is quite "proper" IMO, especially when you take the age (1985! Name any other personal computer with a "proper" multitasking OS from 1985.) and very limited hardware into consideration.

[joska]

[I don't think that it's possible that AmigaOS is always in user mode. Simply, because all interrupts are performed in supervisor mode, and OS handles them normally. Multitasking OS should be able to break app at any moment, and that's possible only with CPU interrupt. And on Atari, with SW not designed for multitasking that's only way for switching between apps.
I don't know about Amiga OS, but if it is on app. that perform some task switch related OS call, it is really not some hmm. quality multitasking. And it must be in user mode when performs that task switch OS call - very strange, especially it it is via trap But I forgive them - it was 1985/87

Of course Exec also use Supervisor mode. When someone say that Exec runs in user mode they refer to the fact that you don't call the OS via traps, but via a function table. So any user call to the OS is done in user mode, and will be pre-empted just like any other user code. I find this rather elegant.

Exec does not depend on the processes to do any sort of OS-call to switch task. It has a scheduler and - unless multitasking is specifically blocked by a process - will preempt any process.

[AtariZoll]

Of course Exec also use Supervisor mode. When someone say that Exec runs in user mode they refer to the fact that you don't call the OS via traps, but via a function table. So any user call to the OS is done in user mode, and will be pre-empted just like any other user code. I find this rather elegant.
Exec does not depend on the processes to do any sort of OS-call to switch task. It has a scheduler and - unless multitasking is specifically blocked by a process - will preempt any process.

And why is call from only user mode possible better than some trap ? Function table ? That's very inappropriate name of something what is much more than function table. What is that "function table" if not OS call ? I see here pretty much confusion and bad terminology.
I must say that it is not proper preemptive if depends on app and how often it will process that OS access - to call it so. Unless someone is very wrong about how Amiga really switching apps.