Okay, now you lost me again. You want to go into details, not being constructive but realistic. So what is the goal of the discussion? Have a base upon which "someone" can start reprogramming a modern yet compatible TOS?
And right the 5-6 entries is about programs assuming things that are not documented. Perhaps we just want two different things - I’d like to have a more modern, less buggy TOS, that is API-compatible so that it can run the majority of GEM software. It seems to me that you’d prefer a 100% compatible TOS, where undocumented memory locations stay at the same place as before. To me, that’s not that relevant, because games don’t use the OS anyway, so why would I put a modern replacement "under" them? Games would not benefit from it.Petari wrote: ↑Wed Dec 20, 2017 6:41 amHere is that EmuTOS incompat. list: https://github.com/emutos/emutos/blob/m ... atible.txt
Now this turns towards having more like a "who does the real stuff" thing. I met excellent people doing GEM apps in C, Modula-2 or Pascal (hey Thomas, Christian, Sven, Wilfried, Alex, Thomas, Christian, Alvar, …), and excellent people coding demos in TurboAss (greetings to TSCC!). So I’d like to stay out of that treacherous water of "these guys are always like …", sorry.
Agreed. I would like to extend that to "all programmers on the Atari TOS platform". Ataris docs were incomplete and buggy. Many people tried to fix that, be it some engaged employees at Atari, or 3rd party programmers like Julian F. Reschke, Dave Small, Claus Brod, Uwe Seimet, Eric Böhnisch, Geiß & Geiß and so on. That’s a huge disadvantage over "more complete" systems like the Apple Macintosh, but it has been also a huge potential to drive things forward. Many protocols, improvements, implementations and conventions that the Atari TOS platform lacked were (successfully) defined by 3rd parties - XHDI, XBRA, MiNT, MagiC, NVDI, OLGA, GemScript, WINX … The impact 3rd parties had on the OS-level is much richer on the Atari platform, than it was for e.g. MS Win or Apple Mac OS.
Well, the Profibuch of 1987 is outdated since 1992 or so, when the updated Profibuch has been released. And there has been errata to that release. I agree, when I’ve been doing some programming, that the multitude of locations for documentation and appropriate programming style has been headache-inducing sometimes. I changed the way my application enters the supervisor mode at least 4 times, because of new conventions or better behaviour with multitasking OSses like MagiC, Geneva, MiNT+N.AES … for such a simple thing of "give me the cookie jar, please". There should’ve been an OS function for that …
Code: Select all
/* get pointer to Cookie Jar */ LONG *cookiejar = (LONG *) Setexc(0x5A0/4, (void (*)())-1);