Which C compiler to use to compile modded TOS 2.06 ?

[ParanoidLittleMan]

I want to do something useful for Atari people: improving TOS 2.06 - and 3.06 too - they are pretty much same in GEMDOS part.

Sources are available, thanx to Otto Thorsten, but he is not interested in improving any TOS. I'm sure that there is a plenty of people who are interested in it .

Things are that sources, as they are can be compiled only with really not good Alcyon C compiler (by DRI ?) . And that means not only inefficient code, but actually inability to perform some needed changes - because problems with unsigned variables.

 

So, I'm asking those experienced with C, what C compiler would be good for this task: I have in mind some established C compiler for Atari, from past - Lattice C ? Or maybe going on some modern one. But then, what with needed TOS libraries ? Is m68k-atari-mint cross-tools good idea ? I did read good and bad things about.

Choosing good one is essential before going in long process of correcting source files for specific compiler.

[ParanoidLittleMan]

Count now !

[pixelmischief]

Sorry I missed this. I went through the same process a year ago - trying to find a good C compiler. My research led me to Pure C, if developing on the Atari, and gcc m68k cross-compile, if developing on the PC.

[ParanoidLittleMan]

Just little history, related: <a data-ipb="nomediaparse" data-cke-saved-href="http://forum.8bitchip.info/news-14/something-"href="http://forum.8bitchip.info/news-14/something-" new'-here-what-happened-at-af-)"="">http://forum.8bitchip.info/news-14/something-'new'-here-what-happened-at-af-)

Link entering fails with this, leads not to exact thread.

<a data-ipb="nomediaparse" data-cke-saved-href="http://forum.8bitchip.info/news-14/something-"href="http://forum.8bitchip.info/news-14/something-" new'-here-what-happened-at-af-)"="">

So, just bare txt copy: forum.8bitchip.info/news-14/something-'new'-here-what-happened-at-af-)

In Firefox: select it with mouse, then right click, Open link in new Window .

Edited December 25, 2018 by ParanoidLittleMan

[ParanoidLittleMan]

Jesus ! After some 5 editings it's now total mess . Sure, that's me who is culprit

[Atariforce]

Jesus ! After some 5 editings it's now total mess . Sure, that's me who is culprit

 

Great, more cross-posting forum drama.

At least now your forum posting skills are up to par with your half-assed 'adaptations'.

[ParanoidLittleMan]

For those who can read: there are problems with this forum's engine, scripts. I pointed at least 10 times on that visit counter will show 0 until someone replies - or in other words if 0 replies, you will not see real visit count (what is actually counted) but 0 .

Now I spotted other script error - entering some URL - precisely copy/paste some URL like this "forum.8bitchip.info/news-14/something-'new'-here-what-happened-at-af-)" via 'Link' icon in submission form may result in partial link . Well, I'm pretty sure that quote around 'new' is what makes it not working well. Thank you for problem report, we will working on fixing it ...

Here is example, without editing: http://forum.8bitchip.info/news-14/something-'new'-here-what-happened-at-af-)

Edited December 25, 2018 by ParanoidLittleMan

[pixelmischief]

Great, more cross-posting forum drama.

The only drama here is this bit you've started.

 

At least now your forum posting skills are up to par with your half-assed 'adaptations'.

 

I assume, then, that you will be providing links to your better work. No?

[guus.assmann]

Hello,

 

Maybe it's possible to compromise?

Most high level programming languages have the possibility to include code segments in Assembler. (or from other languages)

So you might leave the major part as is and only remove the parts that you want to improve.

That way, you could leave all library and other things as they are.

No need to adapt the source code (and other supporting files) for the other "C-dialect"

 

Maybe this also makes documenting the changes / work easier.

 

BR/

Guus Assmann

[ParanoidLittleMan]

Such "compromise" exists from very first TOS version. Parts are done in ASM, and used compiler certainly has ability to 'inline' it .

The idea was to not use Alcyon compiler, and I explained that there will be problem: "inability to perform some needed changes - because problems with unsigned variables." .

If I need to code complete FAT16 code, and that's not short - some 10 KB min (object code) in ASM, that means that I need still to disassemble complete 2.06 properly, and make changes in ASM (same as with 1.04) .

Then what is benefit of C sources ?

Idea was that find some better compiler than Alcyon, and use it. But , as may see, in exactly half year from when I started this thread nothing really constructive was added here. Not only here, nothing really constructive at exxos forum, where I actually started first with this.

So, all I can say is that I will not deal with TOS 2.06 and/or 3.06 improving. This year (2019) certainly not. There are many other things to do. For instance constant talking to people that read written more carefully

Then, using better compiler will result in faster code, so faster work. Yeah, let's do complete TOS in pure ASM ! Actually, I thought that MagiC was coded so, but I was wrong, it used same C + ASM source way. Maybe with bigger %-age of ASM, dunno .

Jokes aside - anyone think that doing it in pure ASM is not too crazy idea ? Pls. only those who want to participate in such project

[guus.assmann]

Doing this work in pure assembler is not crazy, but may be time consuming.

If done properly, the resulting code is generally faster than if a "high level language" is used.

Having the source in C-code must be a lot of help, provided that some comment is there or the code is not difficult to understand.

 

I wish I had some more knowledge on the 68000 programming, but I don't.

My capabilities are more on the hardware side. Replacing SMD, even a 144 pin chip is not a problem for me.

Or a PCB design including prototyping.

However, this experience is no use for writing software.

 

Coöperation on such a software project would be very helpfull.

But it's hard to find others, willing to commit to this.

Also, not everyone has the time or the drive to take on such a task.

 

BR/

Guus Assmann

[ParanoidLittleMan]

Good points Guus. So, I can count on you if want some PCB design ?

 

Doing some 150 KB code in ASM is actually not something that extremely large thing. Here I calculated with 196 KB ROM size of 1.04, where there are some font definitions, RSC data, what takes approx. 30-40 KB.

There are games with 100 or more KB pure ASM code. But that took really lot of time, and they did not it all at once - they used some old rutines, complete sections, maybe with smaller modifications.

I had long time ago some discussions at AF. Some C coders said that I will never be able to make FAT16 filesystem code in assembler. Yes, I was thinking about this about 10 years ago. Of course, all I can say is that it is bad idea to say to someone that will not be able to do something. You never know ... And I really don't know why they said it - because thought that I'm not good coder, or just thought that it is generally (practically) impossible.

Well, I done already some little longer ASM code - like HAGA, hard disk drivers, some video playback code - where it needed to be cycle accurate ... If I put all it together, I'm already over TOS 1.04 size

But that was made over 14 years.

Actually, I made FAT16 code in my Windows SW, Drive Imager http://atari.8bitchip.info/drimus.php

That's coded in C, of course - well not exactly for me. My C code is not exactly by rules, what they teach in schools. It is more like some ASM code in it structure, since I'm ASM coder. There is plenty of goto, for instance.

So, all it depends from available time, motivation, public interest for it. Doing FAT16 filesystem in 68000 ASM, and important is that it be as much possible compatible with existing TOS code - considering RAM usage - buffers, workspace, system variables ... Some of mentioned may take a lot of time if no proper and well commented C sources available. For instance, we have good description of main system variables for TOS (all versions). But other ones, mostly located in area $800-$Cxxx are TOS version specific. Same stays for TOS workspace. To have max. possible SW compatibility it should not use more workspace as original TOS versions - as main condition. That's not hard to achieve, but need special care to do it right.

Then, something what I certainly know better than most: hard disk driver support. It is little strange in TOS - like TOS (AHDI) BigDOS solution self is strange - hard disk driver SW needs to provide necessary buffer space for partitions larger than 32 KB, even it driver self doesn't need those buffers, FAT16 filesystem of TOS needs them (because solution with so called big sectors, instead 32-bit sector addressing) .

If I'd do same as EmuTOS team: making own hard disk driver solution, not compatible with what is in regular TOS versions, that would mean lot of compatibility problems. And that people who paid some commercial driver will be not able to use them.

I say that we need to assure compatibility level high as much it is possible. People wants to run old good SW in first place. And we are in era when floppies just becoming really problematic, together with drives ...