Jump to content

Photo

Which C compiler to use to compile modded TOS 2.06 ?


11 replies to this topic

#1 ParanoidLittleMan ONLINE  

ParanoidLittleMan

    Stargunner

  • 1,682 posts

Posted Fri Jun 29, 2018 11:58 PM

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.



#2 ParanoidLittleMan ONLINE  

ParanoidLittleMan

    Stargunner

  • Topic Starter
  • 1,682 posts

Posted Tue Jul 17, 2018 8:29 AM

Count now !



#3 pixelmischief OFFLINE  

pixelmischief

    Stargunner

  • 1,288 posts

Posted Sun Jul 22, 2018 7:20 PM

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.



#4 ParanoidLittleMan ONLINE  

ParanoidLittleMan

    Stargunner

  • Topic Starter
  • 1,682 posts

Posted Tue Dec 25, 2018 4:16 AM

Just little history, related:  <a data-ipb="nomediaparse" data-cke-saved-href="http://forum.8bitchi...-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.8bitchi...-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 by ParanoidLittleMan, Tue Dec 25, 2018 4:27 AM.


#5 ParanoidLittleMan ONLINE  

ParanoidLittleMan

    Stargunner

  • Topic Starter
  • 1,682 posts

Posted Tue Dec 25, 2018 4:30 AM

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



#6 Atariforce OFFLINE  

Atariforce

    Star Raider

  • 64 posts
  • Location:France

Posted Tue Dec 25, 2018 6:06 AM

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

 

Great, more cross-posting forum drama.

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



#7 ParanoidLittleMan ONLINE  

ParanoidLittleMan

    Stargunner

  • Topic Starter
  • 1,682 posts

Posted Tue Dec 25, 2018 6:43 AM

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.8bitchi...appened-at-af-)


Edited by ParanoidLittleMan, Tue Dec 25, 2018 6:46 AM.


#8 pixelmischief OFFLINE  

pixelmischief

    Stargunner

  • 1,288 posts

Posted Tue Dec 25, 2018 7:43 AM

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?



#9 guus.assmann OFFLINE  

guus.assmann

    Moonsweeper

  • 371 posts
  • Location:Netherlands City EDE

Posted Mon Dec 31, 2018 7:17 AM

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



#10 ParanoidLittleMan ONLINE  

ParanoidLittleMan

    Stargunner

  • Topic Starter
  • 1,682 posts

Posted Tue Jan 1, 2019 3:18 AM

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 ! :-D  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 :)



#11 guus.assmann OFFLINE  

guus.assmann

    Moonsweeper

  • 371 posts
  • Location:Netherlands City EDE

Posted Tue Jan 1, 2019 7:58 AM

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

#12 ParanoidLittleMan ONLINE  

ParanoidLittleMan

    Stargunner

  • Topic Starter
  • 1,682 posts

Posted Tue Jan 1, 2019 9:44 AM

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 ...






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users