GCC for the TI

[+MarkB]

On 7/19/2024 at 2:37 PM, jedimatt42 said:

People have had success in the past building tms-9900-gcc on Raspberry PI OS. There might have been a few additional prerequisites to install. I haven't heard of anyone trying on Bookworm. This and Ubuntu are both downstream consumers of Debian and the prerequisites are not really architecture specific. 

I've tested on bookworm and haven't had any issues.  I think the issue here is the "aarch64" architecture when building for arm 64, since it wouldn't have existed in the gcc-4.4 timeframe.  I'm waiting on delivery of an rpi5 to try it out for myself.

 

I've also resumed work on the latest gcc (14.1.0) which may solve the problem for us.  I'll start a new thread with details of how to build / download when I finish some more testing.

[speccery]

20 hours ago, MarkB said:

I've tested on bookworm and haven't had any issues.  I think the issue here is the "aarch64" architecture when building for arm 64, since it wouldn't have existed in the gcc-4.4 timeframe.  I'm waiting on delivery of an rpi5 to try it out for myself.

 

I've also resumed work on the latest gcc (14.1.0) which may solve the problem for us.  I'll start a new thread with details of how to build / download when I finish some more testing.

I have a rpi5 and can run the test later today. This gcc port is an impressive project! I recently installed the gcc with your install script on my rpi4, an Ubuntu box and WSL2 (I booted my Windows box for the first time in months to try it out). My test case has been compiling the Ghostbusters game - another great project. Compiling it has required some fiddling with Makefiles and paths but none of that is gcc related.

 

Sorry if this information is already available, but I was wondering if this port of gcc works on apple silicon Macs with current macOS releases? That would be great for me. I tried to compile the earlier versions of the gcc for macOS a while ago with limited success.

[+MarkB]

1 hour ago, speccery said:

Sorry if this information is already available, but I was wondering if this port of gcc works on apple silicon Macs with current macOS releases? That would be great for me. I tried to compile the earlier versions of the gcc for macOS a while ago with limited success.

I'm not a Mac user myself and have never tried it.  I think it can be done but it may run into similar issues with arm 64 support.

[speccery]

@MarkB I forgot to test this when I said I was going to do it.. sorry. Anyway, I just tested this with my rpi5. It's running the raspberry pi OS bookworm. Another thing I forgot was that I already was testing compiling using your install.sh and it did not work out of the box due to the aarch64 issue you mentioned. However, I already solved this earlier. The issue is that the configuration script config.guess doesn't know how to deal with aarch64. So I downloaded a new version of config.guess (I don't remember from where but I think it was from here:

https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD

I will anyway attach the version I used here. These were the steps I took:

# run installation
cd tms9900-gcc
./install.sh ~/ti/compiled # use here whatever installation directory you want
# The install.sh step above will fail but it also sets things up for the following.

# find where config.guess files are:
find . -iname config.guess

# assume new config.guess is downloaded to the tms9900-gcc directory. Copy it over.
cp config.guess build/binutils-2.19.1/config.guess
cp config.guess build/gcc-4.4.0/
# rerun install, it succeeded for me now
./install.sh ~/ti/compiled

With this stuff I was able to compile libti99 with the resulting gcc toolchain. I will next try to compile ghostbusters as my test case.

config.guess

[speccery]

@MarkB After once more wresting with Makefile paths with vgmcomp2 and ghostbusters, I did get it compiled on the RPI5 and it runs under js99er.net on the RPI5!

[+MarkB]

2 hours ago, speccery said:

@MarkB After once more wresting with Makefile paths with vgmcomp2 and ghostbusters, I did get it compiled on the RPI5 and it runs under js99er.net on the RPI5!

Excellent.  Are you running raspbian or ubuntu on your PI5?

[speccery]

2 hours ago, MarkB said:

Excellent.  Are you running raspbian or ubuntu on your PI5?

Raspberry pi OS (the changed name of Raspbian to that).

[+MarkB]

Before I start on the aarch64 testing, I rebuilt for bookworm / amd64 and it seems gcc4 has some bitrot.  I was getting build errors in various *.texi files that I hadn't seen before.  I've fixed these locally.  I'll push a 1.31 release once I finish the rpi testing.

In the meantime, to make installing a little easier for Linux users, and hopefully Windows WSL users, I've created a repo at https://ti99ers.com/tigcc (thanks @Gary from OPA)

If anyone wants to try this out on bookworm amd64, the instructions are as follows.  A little more complicated than I'd like due to the deprecation of apt-key but this is as simple as I have found a way to make it:
 

(these steps don't work - refer to the new gcc thread for proper instructions)

 

Just to add the advantage of doing the above means any updates will be automatically picked up.  For a once-off install you can also just fetch the deb directly from https://ti99ers.com/tigcc/pool/main/t/tms9900-gcc/tms9900-gcc_1.30_amd64.deb

 

 

Edited July 29 by MarkB
deleted broken repo add steps

[speccery]

17 hours ago, MarkB said:

Before I start on the aarch64 testing, I rebuilt for bookworm / amd64 and it seems gcc4 has some bitrot.  I was getting build errors in various *.texi files that I hadn't seen before.  I've fixed these locally.  I'll push a 1.31 release once I finish the rpi testing.

I indeed forgot to mention that when compiling on rpi5 I set an environment variable first before running install.sh:

export MAKEINFO=missing

This fixed the *.texi issues as they were not used but great that you have fixed it. Compiling on WSL worked for me. I don't mind building gcc myself but great to have apt support! Related to building gcc, I am not sure if your build script invokes make with the -j option to run on multiple cores in parallel. By habit I normally do that with something like -j7 to run 7 jobs in parallel.

[+MarkB]

5 hours ago, speccery said:

I am not sure if your build script invokes make with the -j option to run on multiple cores in parallel. By habit I normally do that with something like -j7 to run 7 jobs in parallel.

It doesn't use parallel build but yes it would be a good feature to add.
I'm trying to do the opposite right now as my rpi5 build keeps crashing when it draws too much current from my makeshift PSU 🙂

[speccery]

17 minutes ago, MarkB said:

It doesn't use parallel build but yes it would be a good feature to add.
I'm trying to do the opposite right now as my rpi5 build keeps crashing when it draws too much current from my makeshift PSU 🙂

Sorry to hear about the power issue, I went with the official rpi5 PSU since I've had my share issues with raspberry pi4s in the past. The official power supplies seem to work well.

[+MarkB]

5 hours ago, speccery said:

Sorry to hear about the power issue, I went with the official rpi5 PSU since I've had my share issues with raspberry pi4s in the past. The official power supplies seem to work well.

Thanks yeah I have one ordered.  I did a DIY job in the meantime but it isn't easy to supply enough current voltage through the IO header.

 

(actually my iPhone 20W charger works fine too - didn't think of that before)

[+MarkB]

On 7/27/2024 at 2:39 PM, speccery said:

With this stuff I was able to compile libti99 with the resulting gcc toolchain. I will next try to compile ghostbusters as my test case.

Did you add back in the tms9900 targets?  I had to manually add those in to the new config.sub file.  Or maybe it wasn't necessary to upgrade config.sub, just config.guess is enough?

[speccery]

9 hours ago, MarkB said:

Did you add back in the tms9900 targets?  I had to manually add those in to the new config.sub file.  Or maybe it wasn't necessary to upgrade config.sub, just config.guess is enough?

I only updated the config.guess file, that was the source of some definitions which derailed the compilation. I did not touch config.sub. I have to say that I don’t have a deep understanding how these work, I just followed what caused some definitions to not be there and config.guess was the problem.

[Fabrizio Caruso]

Hi everyone! I come back after quite a while.
Last time I was here, @MarkB was working on fixing several bugs and the versions I tried were unstable. @MarkB told to wait.

@MarkB, can I now retry GCC for TI?

Can I safely use it with https://github.com/tursilion/libti99 ?

 

[+MarkB]

2 hours ago, Fabrizio Caruso said:

@MarkB, can I now retry GCC for TI?

Yes please do.  I haven't had much time lately do any major updates but I'm not aware of any blocking problems either so AFAIK the latest version is stable enough to use.

PS - please check out the new thread as well where the first post contains up to date installation instructions

[Tursi]

2 hours ago, Fabrizio Caruso said:

Hi everyone! I come back after quite a while.
Last time I was here, @MarkB was working on fixing several bugs and the versions I tried were unstable. @MarkB told to wait.

@MarkB, can I now retry GCC for TI?

Can I safely use it with https://github.com/tursilion/libti99 ?

 

If you're up to it, and starting over anyway, consider using https://github.com/tursilion/libTi99All instead.

There may still be some small API changes to make, but it's proven on two titles now and most of what's left is just consistency and documentation. The older libti99 is deprecated and won't see further updates. (That said, I believe it works fine with the last posted version of GCC).

 

There are some API breaking changes that still need to be documented, but the main one is that the VDP address macros are function-style now instead of variable style (ie: VDPRD() instead of just VDPRD). This just helps on systems that don't access the VDP via memory mapped means.

 

I believe I still need to turn the peephole optimizations off for one breaking bug, but, I haven't tried anything from the new thread - I honestly had no idea why we started one and thought it was a fork.

 

[Fabrizio Caruso]

@Tursi Thanks for your suggestion.
Current Cross-Lib depends on gcc for ti + your old lib ( https://github.com/tursilion/libti99).
My primary goal is to see if I can build my 9 games (written with Cross-Lib) work with your old lib (i.e. with no change to Cross-Lib) and see if the bugs are really gone.
If this is the case, ideally, I would like not have a dependency with an external library given the fact that I am using very simple graphics that could be done by a few "VPOKES" (pokes in video ram).
If I fail to do this (as I fear because of lack of knowledge and time), I may see if I can get your more recent library.
 

[Fabrizio Caruso]

@MarkB I have some bad news. I have managed to install the newest version of GCC for TI on a second PC. As before I am using Tursi's old library.
It seems that the newest version of GCC for TI is more badly broken than the previous one for the purpose of building my own games. I can build 8 out of 9 of my games and all of them except the simplest 2 (the ones with the simplest code).
Before when I used the old version of GCC I could build all of them and I could get them all to work correctly after patching some of them in one or two lines.

At least for some of them it may be a problem with bitwise operations.

For example the game Horde fails in the part of the code that defines the position of arrows.
Maybe this line:
https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/games/horde/main.c#L1977
Or maybe some of the other operations that determine the value of `new_arrow_x`.

I have attached the binary for Horde (EA5 format).
I can provide all the other binaries.

I can try to better isolate all cases.

So, the situation is as follows:

- [KO] Chase broken (cannot complete the first level because not all enemies are spawned)
- [KO] Shoot won't compile (I need to investigate it)
- [OK] Bomber (very simple game and code: seems to work but I need to test it more)
- [KO] Snake (totally broken because the player dies once the game is started probably because the snake wrongly detects a collision with itself)
- [KO] Horde (sort of playable but wrongly position double fire but you need to play the game and get the power-up to get to see the issue)
- [KO] Verbix (cannot detect correct English 5-letter words)
- [KO] Stinger (sort of playable but some tanks are shown in wrong places and it may also have the same problems as Horde because it shares lots of code with it)

- [KO] Shuriken (some game elements are not spawn, e.g., bricks or shuriken walls)
- [OK] Trex (very simple game and code: seems to work but I need to test it more)

P.S.: All of my games have no issues when compiled with any other compiler for any other target (including native GCC for the native PC operating system).

XHORDE1 XHORDE2

[Tursi]

Just for kicks, try with "-fno-peephole2 -fno-function-cse"

 

no-function-cse will generate much tighter code.

 

I needed no-peephole2 to prevent a peephole optimizer bug (peep-movhi-cmphi)... I don't know if it was ever fixed.

 

 

[Fabrizio Caruso]

@Tursi@MarkB I still get the same issues (see list of bugs on each game) with -fno-peephole2 -fno-function-cse.
As already written I think the issue for Horde (and Stinger) is probably in

https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/games/horde/main.c#L1977
https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/games/horde/main.c#L1983
 

becase it fails exactly when it should shoot two arrows. So the problem seems to be somewhere here:
```

            if((number_of_arrows_per_shot==2)&&i)
            {
                offset = i-2*(bow_x&1);
            }
```

[+MarkB]

13 hours ago, Tursi said:

I honestly had no idea why we started one and thought it was a fork.

It was suggested at one of the zoom calls that it might be better to start a new thread.  The main reason was so that the first post of the thread could be edited and kept up to date with the latest version and so on.  And of course that this thread is > 10yrs old and has 47 pages !

[+MarkB]

5 hours ago, Tursi said:

Just for kicks, try with "-fno-peephole2 -fno-function-cse"

 

no-function-cse will generate much tighter code.

 

I needed no-peephole2 to prevent a peephole optimizer bug (peep-movhi-cmphi)... I don't know if it was ever fixed.

If it's the one I'm thinking it should have been fixed in 1.31:

 

    1.31 (#56)
    
    gcc patch version 1.31 and binutils patch version 1.11
    * Removed peephole for unaligned word mov
    * Fixed peephole where reg is not dead
 

edit: nvm, peep-movhi-cmphi is still in the code, I don't remember the issue tbh but will take a look

Edited October 2 by MarkB

[+MarkB]

1 hour ago, Fabrizio Caruso said:

@Tursi@MarkB I still get the same issues (see list of bugs on each game) with -fno-peephole2 -fno-function-cse.
As already written I think the issue for Horde (and Stinger) is probably in

https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/games/horde/main.c#L1977
https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/games/horde/main.c#L1983
 

becase it fails exactly when it should shoot two arrows. So the problem seems to be somewhere here:
```

            if((number_of_arrows_per_shot==2)&&i)
            {
                offset = i-2*(bow_x&1);
            }
```

Ok thanks, I'll try and find some time to investigate over next few days.

[Fabrizio Caruso]

@MarkB there are several other issues (unfortunately more than before your changes). Some of the other issues make the games just freeze.
I am trying to build some minimal example to make it easier for you.

My games provide a good test on how close GCC for TI is to an ANSI C compiler because I can compare the result with a dozen other compilers including recent native GCC.
Other people can just adapt their code to get what they want but this is not possible for me. I need a compiler that behaves like the other standard compilers.

Edited October 2 by Fabrizio Caruso