TOS after 32 years - what could be done better ?

News,announcements,programming,fixes,game patches & discussions.

Moderator: troed

Petari
Trusted Guru
Trusted Guru
Posts: 558
Joined: Tue Nov 28, 2017 1:32 pm

TOS after 32 years - what could be done better ?

Post by Petari » Mon Dec 18, 2017 2:54 pm

This is mostly hypothetical thinking, I don't think that anyone will make some improved TOS replacement now. We have already some - probably MagiC is the best. EmuTOS wants to be compatible on some level, and offers very little new. Don't talk here about Mint and like, which must load from disk on top of TOS. So, it must fit in 192KB ROM, maybe in 256 , and work with 512KB RAM.

Yes, it's easy to be smarter after battle. So let's do it :D

One of bigger flaws by me was input handle of TOS - reading of kb. input, mouse, joystick was not solved well. Partially because poor and incomplete documentation. That caused that SW worked only on lower TOS versions - lile only TOS 1.00 and maybe 1.02 .
So:
1: Better documentation for programmers

2: Global system variables for input devices, on fixed addresses - that solves all input problems easily. And there is space for. Maybe should go over $800, so can read from user mode.

TOS allocates RAM in simple way: from bottom to top - only screen is at top by default. Programming game, especially graphic card is easier with fixed screen address (Flight Simulator) . So, many games just set start address at some loc, after TOS workspace, and used what is above it up to 512KB Phystop. As new TOS versions arrived, they needed more RAM for workspace - although, there is one exception - TOS 1.02 needs more than 1.04.
So, some games will work only with 1.00 because RAM conflict. Not to mention conflict with hard disk driver SW.
We can say, programmers of games were culprit - but could they predict those changes in RAM usage ?
Could DR make some alternative RAM usage scheme, for SW what is not relocatable ?
I say yes, and that would be actually not that hard - just setting TOS workspace to top of the RAM. Or after 512KB - then for instance hard disk driver would load not in low RAM, so no conflict with game code.
Above would be 3.

Some other things to improve, not gaming related ? For instance floppy related.
4: supporting 800KB format, faster read - latest happened actually at TOS 1.04 or 2.06 (?) - there is skew, what improves transfer speed significantly.

Latest for today: hard disk support. It was very weak in TOS 1.00, just little better in 1.02, acceptable in 1.04. But there is again same flaw as with floppies - they are DOS compatible, but only partially. They are little endian, what is complication for TOS, so then, why not full DOS compatibility ?
Up to 32MB hard disk partitions are same as in DOS. After it not. This is why we need special TOS/DOS compatible partitioning. Large sector way is not so efficient as system used in DOS. I don't know was is selected because some copyright problems with MS, but it seems not likely - you can not protect format, only code. I tend to think that it was pure lack of motivation at DR, to make it better.
5: Better BIG FAT16 partition parameters. (In short) . With it, partitions could go without bigger problems up to 2GB .
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
exxos
Site Admin
Site Admin
Posts: 5027
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: TOS after 32 years - what could be done better ?

Post by exxos » Mon Dec 18, 2017 8:07 pm

I think if all machines were shipped with TOS206 my from the start then things would probably be a lot better.. But of course that did not come until sometime later.. I think TOS was just basically rushed to much.. Or maybe on unfair to say that, but more of they did not really have time to get everything correct right from the start..

I can't really comment much on this as I do not know much about the operating system. But I can say there is clearly lack of proper documentation the operating system. And of course each version has much changes in various parts of the operating system just causes even more confusion.

I would assume that the STE documentation, particular towards the blitter, were not documented properly as software houses did not make use of the blitter much. But then this could be on purpose because of backwards compatibility issues with the STF.. Of course games developers want to sell one game across as many machines as possible, so using the blitter would limit the game to that machine only.

Of course if games developers made use better of the hardware, maybe more people would have purchased their games as they would be better, and maybe Atari may have survived a little longer if there was more active games developments on their later machines.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

stephen_usher
Posts: 193
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: TOS after 32 years - what could be done better ?

Post by stephen_usher » Mon Dec 18, 2017 10:41 pm

exxos wrote:
Mon Dec 18, 2017 8:07 pm
Of course if games developers made use better of the hardware, maybe more people would have purchased their games as they would be better, and maybe Atari may have survived a little longer if there was more active games developments on their later machines.
The biggest problem here was that the 1040STF(M) was so much more expensive that it was beyond most people in the UK (at least) could afford. Adding after-market RAM upgrades was more economical, but this, of course, didn't add the blitter. If the 520ST(F)(M) had included the blitter chip too then the games would have made use of it.

As for TOS, it was a quick and dirty port of GEM/68K so as to ride on the back of the Apple Macintosh hype. It was announced only a couple of months after the Mac was launched. I remember the news report in "Your Computer" magazine.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.

User avatar
arf
Posts: 67
Joined: Sun Oct 29, 2017 9:30 am

Re: TOS after 32 years - what could be done better ?

Post by arf » Tue Dec 19, 2017 1:20 am

exxos wrote:
Mon Dec 18, 2017 8:07 pm
I think TOS was just basically rushed to much..
Oh yes:

Landon Dyer - ST part I
Landon Dyer - ST part II
--
Against signature spam!

Petari
Trusted Guru
Trusted Guru
Posts: 558
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS after 32 years - what could be done better ?

Post by Petari » Tue Dec 19, 2017 8:00 am

arf wrote:
Tue Dec 19, 2017 1:20 am
...
Landon Dyer - ST part I
Landon Dyer - ST part II
Great ! Only this 2 links were worth for starting this thread :D Will read whole soon - first need to prepare some quantity of beer to calm self down :lol:
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
arf
Posts: 67
Joined: Sun Oct 29, 2017 9:30 am

Re: TOS after 32 years - what could be done better ?

Post by arf » Wed Dec 20, 2017 3:24 am

Petari wrote:
Tue Dec 19, 2017 8:00 am
arf wrote:
Tue Dec 19, 2017 1:20 am
...
Landon Dyer - ST part I
Landon Dyer - ST part II
Great ! Only this 2 links were worth for starting this thread :D Will read whole soon - first need to prepare some quantity of beer to calm self down :lol:
Hehe :-) Mike Fulton replied in the comments of Landon, btw.
--
Against signature spam!

User avatar
arf
Posts: 67
Joined: Sun Oct 29, 2017 9:30 am

Re: TOS after 32 years - what could be done better ?

Post by arf » Wed Dec 20, 2017 4:10 am

Petari wrote:
Mon Dec 18, 2017 2:54 pm
This is mostly hypothetical thinking, I don't think that anyone will make some improved TOS replacement now. We have already some - probably MagiC is the best. EmuTOS wants to be compatible on some level, and offers very little new. Don't talk here about Mint and like, which must load from disk on top of TOS. So, it must fit in 192KB ROM, maybe in 256 , and work with 512KB RAM.
You started the thread, so you’re setting the tone. Saying that, follows my “but” :lol: I’m having a different view. My Atari socialisation happened in Germany, and the settings here were a bit different …
  • Basically no-one had a SF354 (singlesided) except very early adopters who then replace it quickly. Of course I don’t have item count data, but after 1986 none of the big software companies offered to deliver larger software packages on SS/DD disks. Some of them offered to deliver for an extra price the smaller singlesided ones, but that quickly vanished, too.
  • Like no one I knew had only a colour screen. All of them had either only the SM124, or a NEC Multisync II, and could go for ST high res, therefore, or an additional colour screen. For sure there’s been a feedback loop, as most of the professional ST software that has been created in Germany focussed on ST high in the first years. Colour happened to be an option only for gaming, not for work, until the graphics cards arrived in 1989-90.
  • And no one went on with 512 KB RAM. Sure, some early adopters had to start with it, but replaced that quickly with one of the countless offers, from students ("I pimp your ST for small cash, no warranty whatsoever") to professional companies, with either 1 MB or going directly to 2.5 MB.
Therefore, the limitations you set would of course match the reality of 1985 that Atari had. As no one of us might own a time machine, this would be a rather hypothecial what-if-game. If you want to evaluate "what could we do know", the goals would be IMHO different.

Having said that, I disagree on some of the detected flaws&solutions you posted. Please have in mind the above environment when judging my opinions.
Petari wrote:
Mon Dec 18, 2017 2:54 pm
One of bigger flaws by me was input handle of TOS - reading of kb. input, mouse, joystick was not solved well. Partially because poor and incomplete documentation. That caused that SW worked only on lower TOS versions - lile only TOS 1.00 and maybe 1.02 .
Which exact problem do you have in mind? I can’t remember having trouble with the HID input system.
Petari wrote:
Mon Dec 18, 2017 2:54 pm
TOS allocates RAM in simple way: from bottom to top - only screen is at top by default. Programming game, especially graphic card is easier with fixed screen address (Flight Simulator) . So, many games just set start address at some loc, after TOS workspace, and used what is above it up to 512KB Phystop. As new TOS versions arrived, they needed more RAM for workspace - although, there is one exception - TOS 1.02 needs more than 1.04.
So, some games will work only with 1.00 because RAM conflict. Not to mention conflict with hard disk driver SW.
Hm, games of that era don’t really need an operating system, they need a bootloader and ignore most of the OS afterwards. And that results in the problems you described. If a game handles an ST like it is a supercharged C64, then problems arised after more powerful machines were in the store. With power comes change, and 100% compatibility on the hardware level isn‘t possible. That’s why there is an OS to separate the requests and serve the client’s programme, no matter what the underlying hardware is. For action-packed games using the VDI was a no-go back then, too limited, too slow - not because the concept is b0rken, but because the original ST *and* VDI has been rather slow. For normal casual games (like Hanse, Wizard Royal …) even a GEM environment would’ve been useable.

Unfortunately, most of the programmers decided to implement everything from scratch, each time for each game, menus, buttons, UI … instead of a one-time fix of what’s bad in the OS and experiencing the improvement for all programmes. This only changed slowly in 1988-1989, with QuickST and TurboST, and then Sven & Wilfried made a boom with NVDI. They fixed the VDI bugs by replacing the flaky routines, went for speeeeeed and added a GDOS. Sorry for re-telling the history you all already know (*yawn*, I know), but it serves my point and your question. NVDI fixed what Atari’s programmers should have done right in the first instance. We know the reasons why they didn’t, but NVDI is not really an addendum for the ST, but a fix for patchy, flaky original routines and it serves the original idea to have GDOS with every machine.
Petari wrote:
Mon Dec 18, 2017 2:54 pm
Some other things to improve, not gaming related ? For instance floppy related.
4: supporting 800KB format, faster read - latest happened actually at TOS 1.04 or 2.06 (?) - there is skew, what improves transfer speed significantly.
Hm, why is that really an operating system issue? TOS can handle 800 KB disks well, once these are formatted, even with spiraling and interleave for 11 sector disks. The only 'need' that I see here would be to integrate "PumpUp" or "Hyperformat" (Jürgen Stessun and Claus Brod really drove the innovation here) formatting routines into the DESKTOP.
Petari wrote:
Mon Dec 18, 2017 2:54 pm
Latest for today: hard disk support. It was very weak in TOS 1.00, just little better in 1.02, acceptable in 1.04. But there is again same flaw as with floppies - they are DOS compatible, but only partially. They are little endian, what is complication for TOS, so then, why not full DOS compatibility ?
Up to 32MB hard disk partitions are same as in DOS. After it not. This is why we need special TOS/DOS compatible partitioning. Large sector way is not so efficient as system used in DOS. I don't know was is selected because some copyright problems with MS, but it seems not likely - you can not protect format, only code. I tend to think that it was pure lack of motivation at DR, to make it better.
5: Better BIG FAT16 partition parameters. (In short) . With it, partitions could go without bigger problems up to 2GB .
Sure, having DOS FAT16+partition compatibility baked into TOS would be nice. But coming back on my first question: Do you want to fix history, or fix today’s problems? :) Even with a time machine and a TOS that would from day 1 support 100% MS-DOS compatible partitions -- that would not have really helped the user, as data exchange with PCs back then meant "floppies" or "RS232", but never ever a hard disk swap. PCs had MFM, RLL or AT-Bus, the Atari had ACSI. No end user would’ve swapped the PCs HDD and walked over to the Atari …

And for today, I read in several forums about clever ways of swapping CF cards and so on between PCs and STs, with clever ways of handling the sometimes problematic byte swap issue. For me, that’s not a real-world problem, as I don’t want to walk back-and-forth, or swap media, walk over, start working, to discover that another file is missing, stop working, eject the media, walk back … I prefer a terminal with RS232 for small files, PARCP was really a game changer that helps me a lot for larger file sets, and there’s quick-enough-cheap-but-not-so-easy-to-configure NetUsBee.

To sum up, if I could turn back time, I’d ask Tramiel to give some engineering superpower before the release of the ST towards GEMDOS (fix the nasty FOLDR and other bugs, with input-redirection, hard disk handling), fix some smaller AES bugs, and have a basic, error-free GDOS included in 256KB ROMs. That would’ve fixed the major software problems I see with the ST from 1985.

If it is about today, I’d jump on the EmuTOS efforts and help with code, if only my programmer skills would be better. Sure enough, a few years ago it’s been a rough ride with EmuTOS, but nowadays it’s really useable, and I would like to add bitter needed AES components, that DR/Atari never offered, and that got re-implemented for applications and GEM libraries time over time: radiobuttons, check buttons, drop-down-lists, tabs, such components. Only the former exist, there’s more to do. That should be part of the OS, not of each app.

YMMV
--
Against signature spam!

Petari
Trusted Guru
Trusted Guru
Posts: 558
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS after 32 years - what could be done better ?

Post by Petari » Wed Dec 20, 2017 5:14 am

Arf, I think that you did not get it . This is not 'time machine' kind, not even remotely related with having single or 2 sided floppy drive. This is about simple things what authors of TOS just could do better in that time, with given limitations of ROM space. My list is short, and surely can add a lot. What would be point of this thread.

You added some, but your reply is off topic in part, talking about how games were done in that time, while obviously had no much experience with games.

Floppy case: there is support for all kind of format, but Desktop's formatter is limited. It may be not strictly part of OS, but is part of ROM TOS.
That would require max some 300 bytes +, including skew . Hyperformat - no. OS should not support unreliable solutions.

I don't know even was DOS solution for Big FAT16 partitions released, established in 1984 second half. After reading those linked memories, I wonder that hard disks work at all with TOS 1.00 :D That solution with large sectors is typical - rushed one.

Considering EmuTOS: I don't see it as proper TOS replacement. It improved in many things, but I seen some really strange ideas of it's authors. For instance built in hard disk driver system is not compatible with some SW - and then they blame coders of that SW, not their incompatible way. They even blame coders of famous Spectrum 512 - not supporting that GEM of SW is just plain stupid. And I'm done here with EmuTOS, better stop, they could come here and pollute the thread, forum :lol:

It is just that thanx partially to some discussions I tend to think that DRI was not good choice. Then, Tramiel wanted too much in short time - in complete new HW, CPU, user interface. They (who were behind those major decisions ?) misjudged completely requirements for GUI OS. But it is so usually at workplaces - those at top, who getting bigger salaries, shares are not on necessary level. Then those down need to be much smarter and work overtime. I don't need time machine and plane to travel in California, 1984. I experienced similar things here, where I am :(
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
arf
Posts: 67
Joined: Sun Oct 29, 2017 9:30 am

Re: TOS after 32 years - what could be done better ?

Post by arf » Wed Dec 20, 2017 6:13 am

Petari wrote:
Wed Dec 20, 2017 5:14 am
Arf, I think that you did not get it . This is not 'time machine' kind, not even remotely related with having single or 2 sided floppy drive. This is about simple things what authors of TOS just could do better in that time, with given limitations of ROM space. My list is short, and surely can add a lot. What would be point of this thread.
Thanks for the clarification. But I listed my wishlist: fixed VDI, add necessary AES components, add GDOS. Go to 256kB right away …
Petari wrote:
Wed Dec 20, 2017 5:14 am
Floppy case: there is support for all kind of format, but Desktop's formatter is limited. It may be not strictly part of OS, but is part of ROM TOS.
That would require max some 300 bytes +, including skew . Hyperformat - no. OS should not support unreliable solutions.
Hyperformat is both a method and a programme. For the parameters and unreliability - adding additional tracks at the end is indeed flaky, I agree. But going to 11 sectors isn’t in my experience.
Petari wrote:
Wed Dec 20, 2017 5:14 am
Considering EmuTOS: I don't see it as proper TOS replacement. It improved in many things, but I seen some really strange ideas of it's authors. For instance built in hard disk driver system is not compatible with some SW - and then they blame coders of that SW, not their incompatible way. They even blame coders of famous Spectrum 512 - not supporting that GEM of SW is just plain stupid. And I'm done here with EmuTOS, better stop, they could come here and pollute the thread, forum :lol:
Which incompatibility in the case of hard disk drivers? And where did they blame Spectrum 512 coders? Happy to receive a PM, as this is OT.
Petari wrote:
Wed Dec 20, 2017 5:14 am
It is just that thanx partially to some discussions I tend to think that DRI was not good choice. Then, Tramiel wanted too much in short time - in complete new HW, CPU, user interface. They (who were behind those major decisions ?) misjudged completely requirements for GUI OS. But it is so usually at workplaces - those at top, who getting bigger salaries, shares are not on necessary level. Then those down need to be much smarter and work overtime. I don't need time machine and plane to travel in California, 1984. I experienced similar things here, where I am :(
Well, I think the team creating the Atari did a great job, given the circumstances. And of course they could have done better, given more resources, more time, better management, peace on earth. But this is a discussion that’s not very constructive, nothing’s ever ideal …
--
Against signature spam!

Petari
Trusted Guru
Trusted Guru
Posts: 558
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS after 32 years - what could be done better ?

Post by Petari » Wed Dec 20, 2017 6:41 am

I just don't like that general "great job" opinion. I like to go in details. This thread is not about being constructive, but about being realistic toward our beloved, and yet flawed machine(s).
Here is that EmuTOS incompat. list: https://github.com/emutos/emutos/blob/m ... atible.txt
Explaining exactly that hard disk driver incompat. here would be way too long. I can start new thread about it, But not today. Just to say that I see some similarity in behavior of EmuTOS and Hatari team with behavior of DRI people - so this is little on topic :D
Namely, they, OS, C programmers often act as some superior ones toward game programmers for instance. That's just wrong - game programming at top level is extremely hard, demanding. ST coders needed years to achieve some level of it. Additionally, thanx to poor docs for Atari ST, game programmers needed to discover many things self, which should be in docs.
I have Atari ST ProfiBuch since 1987, and I still see errors there - yesterday found that ICONBLK structure description has error. Somehow, I think that it is not ProfiBuch error, they just copied there Atari, DRI doc content.
"Nothing is ever ideal" - no, that with DR was not even decent level.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Post Reply