GCC for the TI

[cmcureau]

Just in case there is interest out there, I've added a simple example to my repository (and updated the docker container to add some ea5 utilities) that walks through how to build using libti99.

 

https://github.com/ccureau/tms9900-gcc

 

Happy hacking!

[Fabrizio Caruso]

Thanks a lot @cmcureau!

[Fabrizio Caruso]

Should GCC for TI be called GCC for TMS9900? or does it have specific dependencies on the TI99 computer roms and hardware?

What is to produce a functional binary for the TI99 that can be loaded into an emulator or real hardware?

I guess one needs a .crt file and maybe some specific compiler options and "packaging" tools.
Where can I get the .crt file(s) and compiler options and tools to produce a rom/tape/disk images?

[Fabrizio Caruso]

If I try to use tms9900-gcc as gcc to compile and link a list of files, I get the following linker error:
/opt/gcc4ti99/lib/gcc/tms9900/4.4.0/../../../../tms9900/bin/ld: cannot find -lgcc

I guess this is expected. Isn't it?

[+jedimatt42]

gcc is known to create code that can run on the Tomy Tutor (TMS9995) and I've used it to create a Hello World on the Myarc Geneve 9640 MDOS ( also TMS9995 )

 

There is no crt.o exactly... As the operating system on the 4A doesn't really have a TTY/keyboard abstraction that anyone uses... (<--- gross generalization for purposes of this context) If targeting a cartridge image you need an entry point function that sets the workspace pointer, then the gcc stack pointer (R10, or aliased as 'sp'), copies data from your linked image into the global variables (BSS) and then branches into your actual function/code... doesn't have to be called main.

 

This library here, https://github.com/tursilion/libti99, is a good place to start. There is a TESTLIB program built by the Makefile, and some crt_ea5.asm ( or .c ) can't remember. It uses another tool called ea5split that you can find in this thread, that will convert an .elf file into a sequence of Editor Assembler Option 5 loadable program image files. It is important when linking your modules into the .elf binary that the crt entry point function is first, or at least an assembly command that 'BR' branches to it, as ea5split assumes the beginning of your code is the program start address.

 

There are other beginning to end examples that vary in complexity:

 

There were a couple example .zips in post #1... I think a simple 8k rom cartridge example, and an ea5 example.

 

https://github.com/jedimatt42/tipi/tree/master/clients/tipicfg - uses libti99's conio routines, produces a simple ea5 program using ea5split, with a simple linker file

 

https://github.com/jedimatt42/fcmd - a very complex example that produces a cartridge image, and does bank switching. It uses objcopy and unix commands like 'dd' and 'cat' to craft the ROM image.

 

https://github.com/peberlein/turmoil - Here is a nice game example from PeteE on this forum. This build process can produce a cartridge image or ea5 from the same code...

 

You'll see these all have their own crt source file.

 

I've noticed that under some circumstances the compiler will generate calls to memcpy (such as 'char mutable_filename[16] = "DSK1.DEFAULT" , there is a memcpy in libti99, but I also think there are some utility functions like that in the includes with the compiler... I've never used the includes with the compiler...

 

-M@

[Fabrizio Caruso]

I am trying to use gcc for ti to compile my game Cross Chase.
Cross Chase can be compiled with standard GCC and other GCC derivatives but it fails with GCC for TI with a linker error:
ld: cannot find -lgcc

 

Cross Chase source code is spread over many files at different locations with lots of nested includes.

I have not been able to use any of the template examples (hello or hello2 examples here) for my game.

With all other GCC variants I simply use gcc with all the .c files and gcc takes care of linking the object files.

GCC for TI fails but if I pass the "-c", it does create the .o fails.

I am hoping to be able to link the produced .o files.

Is the error about "-lgcc" expected?

[+jedimatt42]

-lgcc requires you to have a library named libgcc.* that is on your library path at link time.

 

I have never succeeded in building libgcc.

 

If you remove the -lgcc from your build statement the linker should complain about missing symbols. If it doesn't, then you didn't need libgcc anyway. If it does report missing symbols, you just need to write a library that implements what is missing.

 

-M@

[Fabrizio Caruso]

@jedimatt42 How do I remove the -lgcc from my build statement?
I just build with tms9900-gcc file1 file2 ...

It would be cool if gcc for ti could be used with the very same syntax as gcc

[Tursi]

Someone needs to make libgcc build for the TI before that can happen - I've not been able to do it either.

 

You don't explicitly call the linker (tms9900-ld) anywhere? You can try adding "-nostdlib" to your build line to make it not pull in the standard libraries.

 

The odds are you'll then get a bunch of unresolved references, which unless you succeeded at building any of the GCC libs, you'll have to provide.

[Fabrizio Caruso]

Thanks! I do not use any input/output standard functions. I have a dependency with rand, which is easily replaced with a custum one.

[Fabrizio Caruso]

I am now close to getting Cross Chase compiled with GCC for TI:
"
ti99_tiny_no_graphics:
$(TI99_CC) $(TI99_OPTS) \
-I$(SOURCE_PATH) \
-D__GCC_BUFFERED__ \
...
$(TINY_FILES) \
$(CROSS_LIB_PATH)/rand/rand.c \
$(TOOLS_PATH)/ti99/cart_header.o \
$(TOOLS_PATH)/ti99/crt0.o
"
produces the following errors:
"
../tools/ti99/crt0.o: In function `_start2':
(.text+0x18): undefined reference to `__DATA_START'
../tools/ti99/crt0.o: In function `_start2':
(.text+0x1c): undefined reference to `__DATA_END'
../tools/ti99/crt0.o: In function `_start2':
(.text+0x22): undefined reference to `__VAL_START'
../tools/ti99/crt0.o: In function `L5':
(.text+0x28): undefined reference to `__DATA_END'
../tools/ti99/crt0.o: In function `L4':
(.text+0x2e): undefined reference to `__BSS_START'
../tools/ti99/crt0.o: In function `L4':
(.text+0x32): undefined reference to `__BSS_END'
../tools/ti99/crt0.o: In function `L10':
(.text+0x3c): undefined reference to `__BSS_END'
collect2: ld returned 1 exit status
make: *** [Makefile:4976: ti99_tiny_no_graphics] Error 1
"

[Tursi]

Looks like your crt0 is trying to do set up the C runtime, but can't find the labels. Where did you get this crt0? In mine, which is admittedly quite old, the only startup label is _init_data (which has a table after it).

 

If the toolchain has changed someone who's up to date may need to step in

[+jedimatt42]

My simplest example is this one:

 

https://github.com/jedimatt42/ti994a-32kmemtest

 

-M@

[Fabrizio Caruso]

@tursi I am not invoking the linker explicitly as gcc does this automatically.

My game can be compiled by standard gcc this way.

I am using the crt and linkfile from the hello2 example here.

I have no stdlib dependencies as I provide what I need myself.

I am probably doing something stupid.

[TheMole]

Does changing the definition of your segment pointers from "int" to "unsigned int" not help? I'm not sure if the signedness of these symbols would make it so that aren't found, but the values will overflow the range of an int, giving that we have a 16 bit address space. So try extern "unsigned int __VAL_START;" instead of "extern int __VAL_START;", etc...

 

Other than that, I see nothing wrong with your code. You are in fact explicitly invoking the linker though, that's what your ti99_cross_chase.elf target does in your Makefile.

[Fabrizio Caruso]

@themole I am not explicitly calling the linker in the ti99_tiny_no_graphics target. I just invoke gcc with no stdlib

[TheMole]

Well, you should, 'cause otherwise there's no way for your crt0 file to resolve those symbols, nor will the linker know how to organize your binary

Edited June 6, 2019 by TheMole

[Fabrizio Caruso]

@themole, I will try to use a cleaner Makefile target...
The current ti99_tiny_no_graphics target if used with the -c option, will produce the .o files.
I guess I just need to invoke the linker on those files + use the linkfile, crt and cart files.

I can try to invoke the compiler on each file but it fails because it does not find some files. I probably need to include some header files with some include option.

[Tursi]

(scratch) Sorry, I'm a step behind.

 

At this point everyone is guessing. Can you just post your makefile (at minimum, but a full project, even just a hello world, would let others help to solve the full issue)?

Edited June 9, 2019 by Tursi

[Fabrizio Caruso]

@tursi, I have already posted my Makefile here, which is a trivial one with just all the source files in one single target line and the -nostdlib flag.

It builds all the .o files as expected. It fails with the linking. I most probably need to run the linker command separately with the good linkfile.
I was hoping I could do it with a single command line as I do with standard gcc.

[+jedimatt42]

You should move your .c and .h files into the build system (Makefile, link file, crt*) of one of the examples in post #1.

 

Just my opinion. You'd be done already.

 

We can't answer your question because we don't practice the usage pattern you are advocating. Even the linker when run separate cannot produce a 4A binary. Additional steps will be required.

 

There are a million arguments to the gcc tool, some of them control defaults that it otherwise passes on to the ld tool. Since I always use the ld tool directly, as do all the examples I have seen, I think you are a pioneer in this space and will have to concede or educate us on your alternative approach.

 

-M@

[EtchedPixels]

Took me a while to find out where to look. Not the obvious place to find the TI99 GCC forum!

 

I've been giving it a spin with the Fuzix code and have a small set of fail cases (compiler crashes, aborts, internal errors, other flaws) when I try and build the Fuzix C library. If you can let me know how you'd like them. I've also fixed a small error in tms9900_output_ascii. If you have a string ending in '\' then the compiler doesn't quote the '\' and confuses the assembler completely. I chnged it to quote \ or nonprintables.

 

There's also another fairly fundamental problem I'm not sure how to tackle other than by telling the compiler to tack _ on all the variable names - if you do this

 

static int sp;

 

and then try and use it - boy does it get upset . It works for other non '_' using targets because they use an asm syntax that explicitly marks registers.

 

Alan

 

[TheMole]

18 hours ago, EtchedPixels said:

Took me a while to find out where to look. Not the obvious place to find the TI99 GCC forum!

 

I've been giving it a spin with the Fuzix code and have a small set of fail cases (compiler crashes, aborts, internal errors, other flaws) when I try and build the Fuzix C library. If you can let me know how you'd like them. I've also fixed a small error in tms9900_output_ascii. If you have a string ending in '\' then the compiler doesn't quote the '\' and confuses the assembler completely. I chnged it to quote \ or nonprintables.

 

There's also another fairly fundamental problem I'm not sure how to tackle other than by telling the compiler to tack _ on all the variable names - if you do this

 

static int sp;

 

and then try and use it - boy does it get upset . It works for other non '_' using targets because they use an asm syntax that explicitly marks registers.

 

Alan

 

Oh, cool! I'd really love to see Fuzix on the TI!

[Mobsie]

Hi all,

 

i was not able to install on osx. 

The installer can’t download the files, what is strange because they exist.

 

I downloaded myself and disable it in the installer script.

 

Then the installer make huge stuff, also make the destination path and put a lot inside.

 

But the tms9900-gcc is missing for example.

 

The installer stop with an error, see the picture.

 

Any idee? or could someone post a ready to use osx build?

 

The docker version is running, but this i don’t like, i want it native.

 

Thanks

[HackMac]

Hello, Michael,

 

I'd love to help you. However, I don't feel like reading through the previous 20 pages of messages. Only waste of time. So I can only guess.  Which would certainly not help you.
I suspect that a header file could be included twice. But I am not there in the detail. I would have to follow all the steps you have taken.

 

From my point of view it is no miracle for the failures with your attempt to set up the tool chain, and/or to produce the source code. I wouldn't even be motivated to start working through the gibberish, although it's an interesting project.

 

As constructive criticism to insomnia I can contribute the following:
On the first page all versions of the patches are available for download, that's quite good. But unfortunately I can't see what an interested user should do. (Without reading more than 20 pages of comments.) What, an installer? What is that supposed to do? Is it a kind of build script? It's certainly independent of the platform, isn't it? Do these patches build on each other? So should you apply each patch one by one, or is it enough to just use the last one? What is the base of the patches? What are the requirements to build your own gcc? (Regarding the tool chain with version numbers.)

It seems to me like in the 90's when you sent patches by mail. Terrible! If this procedure had proved itself, patches would still be exchanged today. But the world continues to turn and the opportunities are evolving. Nowadays one should use more modern technologies, which GIT really makes available to everyone. Just create a fork from the master of the gcc repository and maintain a branch with your TMS9900 extensions. (Or include the gcc sources as a git module for your extensions in the repository, like I do with XDT99 on my XDT-Wrapper project.) Occasionally rebase your branch onto the latest master of the gcc. Furthermore, you should provide some build scripts, like for commonly used make or cmake, etc.
This increases the acceptance by a multiple: Clone, build - done! It can be sooo simple...
Everything else is crap!

 

No harm meant!