Help Compiling TOS 2.06/2.08/3.06 in any language

[troed]

This mixture has been verified to produce a binary exact copy of all tos 3.06 versions i could find.

Color me impressed! That's fantastic!

/Troed

[ThorstenOtto]

Excuse my scepticism but this: "This mixture has been verified to produce a binary exact copy of all tos 3.06 versions i could find. " is really hard to believe. How could you get a 1:1 copy of something which is compiled by different compiler, not even using all the original files but stuff from EmuTOS instead?

The 1:1 copy must of course be compiled by Alcyon. I only used GCC during development to (cross-compile) on the host, because that was much faster than switching to the emulator first every time, and because the error messages are better. In fact, the output from GCC won't produce anything usable. And the files from EmuTOS are only header files which don't produce any code by themself, and a small tool used in the build process, that is not part of linked executable. If you don't believe it, try it out

[AtariZoll]

Hi,

This mixture has been verified to produce a binary exact copy of all tos 3.06 versions i could find.

Serious people would add some notes, guides to how compile. I don't see anything of it.

Then you didn't even bother to read the docs.

Yes, translating RSC is possible with RSC editor, and in TOS there is regular RSC structure, so can extract it and edit

But there is no easy way to get that changed RSC file back in the ROM. Besides that, the ROM also contains a header that describes where to find it and how long it is (as well as the size of the default desktop.inf), which is not part of the RSC file itself.

GemDOS is only German.

The only message from gemdos is "SYSTEM HALTED" when it runs out of folder slots, and that one is in english, for all language versions.

Thorsten

Well, let as reproduce it - give instructions for compiling. There is no any DOC in this BZ2 archive, any notes. May be not your fault, since not you uploaded it.
Why archive is called tos306de ? Misleading indeed. I don't remember exactly about GemDOS messages, it was long time ago I translated. Was not everything in RSC.
What is with TOS 2.06 - since it is in question here ? What about resulting binary ? Really hard to believe that we can get exactly same binary using different compiler, sources ...

[joska]

Yes, translating RSC is possible with RSC editor, and in TOS there is regular RSC structure, so can extract it and edit

But there is no easy way to get that changed RSC file back in the ROM. Besides that, the ROM also contains a header that describes where to find it and how long it is (as well as the size of the default desktop.inf), which is not part of the RSC file itself.

This is taken care of by the TOSpatch scripts.

[ThorstenOtto]

Well, let as reproduce it - give instructions for compiling. There is no any DOC in this BZ2 archive, any notes. May be not your fault, since not you uploaded it.

There supposed to be a README file in it. Apparently it is missing, for unknown reasons. Its not much, but should give at least some hints.

Basically, all you need is
- A good enough command line shell. In my case i was using the builtin mupfel from the GEMINI desktop.
- Make sure that the bin directory from the archive is on your path. Mostly important for make, using GNUmake will NOT work.
- type make
- enjoy

Why archive is called tos306de ?

Because thats the version i originally started with, and that is built by default. The other versions came later.

Misleading indeed.

If all you can do is rant about other ppls work, then do it better. Good luck.

What about resulting binary ? Really hard to believe that we can get exactly same binary using different compiler ...

[/quote]

See my previous post. Of course you can't expect a different compiler to produce the exact same binary, you have to use Alcyon for that. I would be rather disappointed if GCC would produce such stupid code as Alcyon...
In fact quite some time in the project was spent in fixing at least some of the quirks of the Alcyon compiler in order not to crash at every syntax error, leaving corrupt assembler files around.

sources...

It's magic, isn't it?

[AtariZoll]

...
If all you can do is rant about other ppls work, then do it better. Good luck.

Such attitude will not help you. I came here to help thread starter. Then seen your posts. My critic is constructive, and if you expect some recognition of your work, try to do things on way that people can use it without hassle. Spending lot of time on doing this, and nothing on making clear for people what is it ... Ah, and maybe I do better what I do

[ThorstenOtto]

Serious people would add some notes, guides to how compile. I don't see anything of it.
My critic is constructive

..very constructive...

try to do things on way that people can use it without hassle.

Not my fault if you can't type make in a shell. And if you don't know what a shell or make is, then that archive just isn't for you. It's not my task to teach you the basics of development.

[AtariZoll]

OK, I'm done here. In one reply you talk about need for specific compiler, then in other saying that just need to type make ...

[troed]

Thank you @ThorstenOtto - the description you have given is perfectly sufficient for anyone to try to recreate binaries themselves.

/Troed

[crashman]

Thanks to Thorsten Otto for his work.
Thanks Atarizoll, troed, joska and everyone for it's help.

Don't fight please.

[ijor]

That source tree was used as a basis. However the different versions found on the net are not related to any specific TOS version, most of them do not even compile. My goal was to have a complete source of something that produces the real rom versions of TOS 3.06 (and now also 2.06, since they are mostly identical).

Very interesting work. Congratulations!

How close are TOS 3.06 and 2.0? I'm not familiar with TOS 3.X, but I thought that the Bios should be quite different.

This mixture has been verified to produce a binary exact copy of all tos 3.06 versions i could find.

And what about 2.06? You didn't try? It's not so easy? Or you don't care so much about TOS 2.X?

The 1:1 copy must of course be compiled by Alcyon

Did you tweaked the code generation? I would assume there are multiple version of the Alcyon compiler, possibly with some minor code generation that might affect binary compatibility. Even the assembler probably matters. And I guess that no all versions are available?

And the files from EmuTOS are only header files which don't produce any code by themself,

Well, there is still at least "startup.S" that claims EmuTOS copyright. I'm not a lawyer, and personally I don't really care too much. But it might be better to remove EmuTOS copyright since there is probably no EmuTOS code left there. May be it still has variable names and comments from EmuTOS? If so, perhaps you should put something like "portions copyright EmuTOS" instead.

[umberto1st]

See what you get for asking!

[BlankVector]

And the files from EmuTOS are only header files which don't produce any code by themself,

Good! This makes sense. I couldn't understand how EmuTOS own code (unrelated to Atari code) could produce the very same binary result as Atari code. As your binary does not contain any EmuTOS code, it doesn't violate the EmuTOS license. This is good (regarding to EmuTOS concern).

So you only used some parts of EmuTOS headers. I read somewhere that API couldn't be copyrighted (to be verified). So that any header could be reused (again, to be verified).
My advice is: get whatever you need from EmuTOS headers (types, structs, defines, prototypes...), put that in your own header, remove comments, remove copyright notice, and voilà. There will be no remaining mention of EmuTOS in your sources, so no possible confusion.

and a small tool used in the build process, that is not part of linked executable.

As long as this tool (which one?) keeps its copyright and is still redistributed under GPL (even modified), there is no problem with that.

Well, there is still at least "startup.S" that claims EmuTOS copyright. I'm not a lawyer, and personally I don't really care too much. But it might be better to remove EmuTOS copyright since there is probably no EmuTOS code left there.

Exactly.

BTW, Thorsten, I remember that thanks to your new expertise on this topic, you found a few tricky bugs in EmuTOS own sources, and you provided fixes. Thanks for that.

[ThorstenOtto]

How close are TOS 3.06 and 2.0? I'm not familiar with TOS 3.X, but I thought that the Bios should be quite different.

If you mean 2.06: they are almost identical. The main differences are that 2.06 probes for the MegaSTE clock, while 3.06 probes the NVRAM and its clock. The entry point of the dispatcher will only work on 68010+ in 3.06, while the 2.06 versions check the _longframe variable. And very early in the startup code are some '030 specific initializiations in the 3.06 version (MMU for example).

GEMDOS, AES and DESKTOP are completely identical. VDI is only different in that the 3.06 contains the routines for the 8planes low-rez mode of the TT.

And what about 2.06? You didn't try? It's not so easy? Or you don't care so much about TOS 2.X?

See above. Both 2.06 and 3.06 can be produced from the sourcecode.

Did you tweaked the code generation?

Not really, because that would defeat my purpose. Tweaking the code generation would produce different code that i can't verify anymore. I did fix several bugs though to make it not crash all the time.

I would assume there are multiple version of the Alcyon compiler, possibly with some minor code generation that might affect binary compatibility. Even the assembler probably matters. And I guess that no all versions are available?

Yes, a few. It turns out that he compiler in the dev-kit mostly resembles the v 1.02a of the CP/M version. But apparently different parts of the tools and library where originally compiled by different compiler versions, which gave me quite some headaches.

And the files from EmuTOS are only header files which don't produce any code by themself,

Well, there is still at least "startup.S" that claims EmuTOS copyright.

Oops yes. Especially the startup module does not have anything to do with EmuTOS, its quite different. Maybe that slipped in when i compared it to what is done in EmuTOS.

[joska]

Basically, all you need is
- A good enough command line shell. In my case i was using the builtin mupfel from the GEMINI desktop.
- Make sure that the bin directory from the archive is on your path. Mostly important for make, using GNUmake will NOT work.
- type make
- enjoy

I tried to build it on my Milan but did not succeed. With gnu make it appeared to build everything but failed to link the TOS image. When setting PATH to point to the included bin folder I could not build it at all. With memory protection enabled make.ttp crashed due to a memory violation, with mp disabled I got an "Error 1792" immediately.

I also tried to build it under TOS but some of the files had long filenames so make could not find them.

So it looks like this currently can only be built under an emulator with a host filesystem that supports long filenames.

[ThorstenOtto]

With gnu make it appeared to build everything but failed to link the TOS image.

Did you remove the GNUmakefiles? Otherwise they will be used. That might compile, but will use gcc. Its a configuration i actually used only during development and is not supposed to actually produce something usable. It would also explain why linking fails.

When setting PATH to point to the included bin folder I could not build it at all.

Any error messages you got? Or did it crash?

With memory protection enabled make.ttp crashed due to a memory violation, with mp disabled I got an "Error 1792" immediately.

Hm that sounds strange. It *might* work with GNUmake if you make sure that the "normal" Makefiles are used, but i never tried that because gmake requires MinT, and the various parts of the Alcyon package already had problems under SingleTOS.

I also tried to build it under TOS but some of the files had long filenames so make could not find them.

Only a few of them (Makefile.common for example). In theory this should not prevent them to be found. But i have no real machine to proove that. If all else fails, and this is the only problem stopping the build, i can just change their names.

So it looks like this currently can only be built under an emulator with a host filesystem that supports long filenames.

The host filesystem supports it, but since its Singletos that is runnig, only short filenames are seen.

[joska]

Did you remove the GNUmakefiles? Otherwise they will be used.

No, I did not remove those files.

Hm that sounds strange. It *might* work with GNUmake if you make sure that the "normal" Makefiles are used, but i never tried that because gmake requires MinT, and the various parts of the Alcyon package already had problems under SingleTOS.

I believe it was one of make.ttp's children that crashed. As you say, Alcyon probably does not work correctly under MiNT.

I also tried to build it under TOS but some of the files had long filenames so make could not find them.

Only a few of them (Makefile.common for example). In theory this should not prevent them to be found. But i have no real machine to proove that. If all else fails, and this is the only problem stopping the build, i can just change their names.

Maybe in theory, but in real life those files were not found However, the problem could also be that Alcyon does not work correctly on the 060. I should try to build it on my STE instead, but it was getting late last night so I stopped after trying under TOS on the Milan.

[Arne]

However, the problem could also be that Alcyon does not work correctly on the 060.

Ehemmm... using coal to fuel a nuclear fusion reactor... no that can give problems.
Maybe you have to dig out a TOS 1.00 ST and a SH204 to resemble the equipment Atari engineers had at hand when using Alcyon.

[ThorstenOtto]

Maybe in theory, but in real life those files were not found

Thats strange, but could be fixed easily.

I believe it was one of make.ttp's children that crashed

I just tried on MinT, and yes, its the preprocessor (cp68) that dies with a privilege violation. That happens also without memory protection. And it happens also to the other passes parser(c068) and codegenerator(c168). Thats most likely because those exes are the original (unmodified) ones from the alcyon package and still contain bugs from the c-library.

However, the problem could also be that Alcyon does not work correctly on the 060.

Its more likely that mint is the problem here. I tried it on Aranym, which emulates a '040.

So it looks that you currently have to run some kind of SingleTOS. Unfortunately, there is no easy fix for that.

[ijor]

This mixture has been verified to produce a binary exact copy of all tos 3.06 versions i could find.
...
See above. Both 2.06 and 3.06 can be produced from the sourcecode.

I understood that. My question was if the 2.06 build also gives a binary 100% identical to the original TOS.

[joska]

So it looks that you currently have to run some kind of SingleTOS. Unfortunately, there is no easy fix for that.

Not really a big problem, I will make another attempt at this tonight. Thanks for your efforts!

[ijor]

So you only used some parts of EmuTOS headers. I read somewhere that API couldn't be copyrighted (to be verified). So that any header could be reused (again, to be verified).

I'm not so sure about API. Isn't the whole Oracle vs Google lawsuit precisely about that? But in the worst case, the API is not actually copyright EmuTOS but Atari's.

But I understand (again, I'm not a lawyer) that variable names do can be copyrighted? Again, not that I really care

[ThorstenOtto]

[quote="ijor"]
I understood that. My question was if the 2.06 build also gives a binary 100% identical to the original TOS.
[/quote

Yes, it does. At least for the language specific version that i could find to verify, that are
de - german,
uk - United kingdom
us - USA
fr - French
sg - Switzerland (German)
sv - Sweden

Missing are es(Spain) and it(Italy). Apparently, there have never been any officialy released versions of 2.06 and 3.06 for these languages, at least i could not find one on the net. For all the other languages though, the language specific parts (resource files, newdesk.inf and keyboard tables) did not change between 2.05 and 2.06, so these are currently built with resource files extracted from 2.05.

Similar for 2.08 btw (the ROM found in STbooks). I only can verify us, de, fr from versions which where posted here some time ago. The ROMs for other languages should be ok, since the STBook-specifics are not language dependent, but the STbook ROM also contains some pseudo filesystem in the 2nd 256k of the ROM with some helper programs; i'm not sure wether these were language specific.

[joska]

I also tried to build it under TOS but some of the files had long filenames so make could not find them.

True, the files were not found. However, it had nothing to do with the filenames. That was just a coincidence (reference to Makefile.common is the first reference to a file in the makefile). The real problem is that mupfel (Gemini shell) or make does not understand forward slashes.

[crashman]

Hi,

I've compiled it without errors in Gemini with mupfel.
The only real problem was to add to mupfel all the command needed, in it's *.ttp form.
mv.ttp, awk.ttp, sed.ttp
Adding the path of the bin to the system it's also necessary.
And, if using Hatari, removing a "NUL" from the makefile.common
it don't really cares about long filenames.

I can only be grateful to Thorsten Otto and thank him publicly for all his hard work and patience with me and my lack of knowledge in compiling...

Thanks Thorsten!!!