Jump to content
insomnia

GCC for the TI

Recommended Posts

On 7/22/2019 at 6:07 AM, Mobsie said:

The installer stop with an error, see the picture.

The picture shows that you are compiling with Clang. Try GCC. Even then I don’t know if it will work.  The build process works on Linux but doesn’t work on all flavors of Linux. Mac is *like* Linux, but they are not the same.

  • Like 2

Share this post


Link to post
Share on other sites
On 7/26/2019 at 3:12 AM, Mobsie said:

thank you all.

With help from PeteE i was able to build all on osx.

 

Hi Mobsie,

 

I'm trying to build on OS X El Capitan (last OS build my MacBook supports).  I have installed GMP and MPFR using MacPorts, but the scripts fail to find them and GCC fails to build.  Any idea on how to fix this?  Thought this might have been addressed in your setup.

Share this post


Link to post
Share on other sites
3 hours ago, klrw111-78 said:

I'm trying to build on OS X El Capitan (last OS build my MacBook supports).  I have installed GMP and MPFR using MacPorts, but the scripts fail to find them and GCC fails to build.  Any idea on how to fix this?  Thought this might have been addressed in your setup.

Here is the modified script I sent to Mobsie.  He got it to work, so perhaps you can too.

install-mac.sh

  • Like 3

Share this post


Link to post
Share on other sites
On 10/15/2019 at 1:03 AM, PeteE said:

Here is the modified script I sent to Mobsie.  He got it to work, so perhaps you can too.

install-mac.sh 3.69 kB · 4 downloads

Thanks for the script.  It showed me how to make the changes for my environment.  Everything worked up to the point of calling the linker for the gcc compile.  The errors involved failure to find symbols.  Going to re-install the Xcode setup and try again.

Share this post


Link to post
Share on other sites

I wrote a simple function today that seems to show unreachable instructions being generated: 

 

int hasRam() {
  volatile int* lower_exp = (volatile int*) 0x2000;
  *lower_exp = 0;
  *lower_exp = 0x1234;
  return (*lower_exp == 0x1234);
}

 

that compiled into the following:

 

        def     hasRam
hasRam
        clr  @>2000
        li   r1, >1234
        mov  r1, @>2000
        mov  @>2000, r2
        clr  r1
        ai   r2, >EDCC
        jeq  L13
        b    *r11
        jmp  L14
L13
        li   r1, >1
        b    *r11
L14
        .size   hasRam, .-hasRam

 

The instruction just prior to L13 is unreachable, and unnecessary.  compiled with -O2

 

[email protected]
 

  • Like 2

Share this post


Link to post
Share on other sites
22 hours ago, jedimatt42 said:

I wrote a simple function today that seems to show unreachable instructions being generated: 

 

int hasRam() {
  volatile int* lower_exp = (volatile int*) 0x2000;
  *lower_exp = 0;
  *lower_exp = 0x1234;
  return (*lower_exp == 0x1234);
}

 

that compiled into the following:

 

        def     hasRam
hasRam
        clr  @>2000
        li   r1, >1234
        mov  r1, @>2000
        mov  @>2000, r2
        clr  r1
        ai   r2, >EDCC
        jeq  L13
        b    *r11
        jmp  L14
L13
        li   r1, >1
        b    *r11
L14
        .size   hasRam, .-hasRam

 

The instruction just prior to L13 is unreachable, and unnecessary.  compiled with -O2

 

[email protected]
 

Interesting.

I can see that it has a rigid if-else pattern where 'return' is treated as an ordinary statement in each clause.

 

vs hand-coding, the compiler doesn't seem to make good use of registers. But I don't blame it. Compiler code-generation still  seems like magic to me.

 

I wonder if declaring lower_exp as register would help.

Also a register const int x = 0x1234;

 


Using one more register R0

    clr  r1
    li   r0,>2000
    clr  *r0
    li   r2,>1234
    mov  r2,*r0
    c    *r0,r2
    jne  L13
    inc  r1
L13    
    b    *r11

11 words vs 15

 

 

 

  • Like 2

Share this post


Link to post
Share on other sites

New laptop, new linux, new error building gcc - :)

 

New gcc ( 9.2.1 ) doesn't like some of the code used in the old gcc ( 4.4.0 ) :  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677

 

I found the solution applied in this issue works well ( coincidentally for a gcc for TI calculators 😞 https://github.com/debrouxl/gcc4ti/issues/11

 

cd into your install.sh destination directory, and then into the gcc-4.4.0 directory.  And apply the patch:  cgraph_node.patch

 

patch -p1 < cgraph_node.patch

 

Then re-run the install to resume the build.  I'm sure this could be rolled into the install.sh if @insomnia was so inclined.

 

[email protected]

  • Like 5

Share this post


Link to post
Share on other sites

With Windows 10 you can use Linux subsystem. Have anybody try gcc with 9900 patch on Windows 10 with Linux subsystem? Have anybody instruction for this?

Edited by Manic1975

Share this post


Link to post
Share on other sites
14 hours ago, Manic1975 said:

With Windows 10 you can use Linux subsystem. Have anybody try gcc with 9900 patch on Windows 10 with Linux subsystem? Have anybody instruction for this?

I've done it and it worked for me. There were some minor issues but it has been a fair bit of time since I did it. Just work the issues one at a time, I want to say they were all documented here for other systems (and that it worked better than cygwin ;) )

 

Share this post


Link to post
Share on other sites

Hello everyone,

 

Trying to compile on a Raspberry Pi 4, latest version of Raspbian.  Getting an error for binutils:

 

make[1]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1'
make[2]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/libiberty'
make[3]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/libiberty/testsuite'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/libiberty/testsuite'
make[2]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/libiberty'
make[2]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/intl'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/intl'
make[2]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd'
Making info in doc
make[3]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd/doc'
make chew
make[4]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd/doc'
make[4]: 'chew' is up to date.
make[4]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd/doc'
./chew -f ../.././bfd/doc/doc.str <../.././bfd/doc/../targets.c >targets.tmp
/bin/bash ../.././bfd/doc/../../move-if-change targets.tmp targets.texi
restore=: && backupdir=".am$$" && \
rm -rf $backupdir && mkdir $backupdir && \
if (makeinfo --split-size=5000000 --split-size=5000000 --version) >/dev/null 2>&1; then \
  for f in bfd.info bfd.info-[0-9] bfd.info-[0-9][0-9] bfd.i[0-9] bfd.i[0-9][0-9]; do \
    if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
  done; \
else :; fi && \
if makeinfo --split-size=5000000 --split-size=5000000   -I ../.././bfd/doc \
 -o bfd.info `test -f 'bfd.texinfo' || echo '../.././bfd/doc/'`bfd.texinfo; \
then \
  rc=0; \
else \
  rc=$?; \
  $restore $backupdir/* `echo "./bfd.info" | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
./elf.texi:11: raising the section level of @subsubsection which is too low
make[3]: *** [Makefile:394: bfd.info] Error 1
make[3]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd/doc'
Making info in po
make[3]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd/po'
make[3]: Nothing to be done for 'info'.
make[3]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd/po'
make[3]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd'
make[3]: Nothing to be done for 'info-am'.
make[3]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd'
make[2]: *** [Makefile:1094: info-recursive] Error 1
make[2]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd'
make[1]: *** [Makefile:3094: all-bfd] Error 2
make[1]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1'
make: *** [Makefile:717: all] Error 2

 

Here's the gcc version I'm using:

 

gcc (Raspbian 8.3.0-6+rpi1) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 

I've compiled all GCC for the TI on older versions of Raspbian, etc., without issue.

 

Any idea on what may up?

 

Thank you

 

 

 

Share this post


Link to post
Share on other sites
5 minutes ago, mr_gw454 said:

Hello everyone,

 

Trying to compile on a Raspberry Pi 4, latest version of Raspbian.  Getting an error for binutils:

 

make[1]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1'
make[2]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/libiberty'
make[3]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/libiberty/testsuite'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/libiberty/testsuite'
make[2]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/libiberty'
make[2]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/intl'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/intl'
make[2]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd'
Making info in doc
make[3]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd/doc'
make chew
make[4]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd/doc'
make[4]: 'chew' is up to date.
make[4]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd/doc'
./chew -f ../.././bfd/doc/doc.str <../.././bfd/doc/../targets.c >targets.tmp
/bin/bash ../.././bfd/doc/../../move-if-change targets.tmp targets.texi
restore=: && backupdir=".am$$" && \
rm -rf $backupdir && mkdir $backupdir && \
if (makeinfo --split-size=5000000 --split-size=5000000 --version) >/dev/null 2>&1; then \
  for f in bfd.info bfd.info-[0-9] bfd.info-[0-9][0-9] bfd.i[0-9] bfd.i[0-9][0-9]; do \
    if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
  done; \
else :; fi && \
if makeinfo --split-size=5000000 --split-size=5000000   -I ../.././bfd/doc \
 -o bfd.info `test -f 'bfd.texinfo' || echo '../.././bfd/doc/'`bfd.texinfo; \
then \
  rc=0; \
else \
  rc=$?; \
  $restore $backupdir/* `echo "./bfd.info" | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
./elf.texi:11: raising the section level of @subsubsection which is too low
make[3]: *** [Makefile:394: bfd.info] Error 1
make[3]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd/doc'
Making info in po
make[3]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd/po'
make[3]: Nothing to be done for 'info'.
make[3]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd/po'
make[3]: Entering directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd'
make[3]: Nothing to be done for 'info-am'.
make[3]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd'
make[2]: *** [Makefile:1094: info-recursive] Error 1
make[2]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1/bfd'
make[1]: *** [Makefile:3094: all-bfd] Error 2
make[1]: Leaving directory '/home/pi/source/gcc-ti99/build/binutils-2.19.1'
make: *** [Makefile:717: all] Error 2

 

Here's the gcc version I'm using:

 

gcc (Raspbian 8.3.0-6+rpi1) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 

I've compiled all GCC for the TI on older versions of Raspbian, etc., without issue.

 

Any idea on what may up?

 

Thank you

 

 

 

 

I think I forgot this before compiling:

 

export MAKEINFO=missing

 

 

Share this post


Link to post
Share on other sites

Hi to everyone,
Once again, I have to re-install GCC 4 TI. I have tried with the very latest installer hoping to get it installed easily...
I cannot see find the instructions on how to use the installer.
If I run it with "sudo ./install.sh /opt/gcc4ti"
I get these errors
...
configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.2+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
See also http://gcc.gnu.org/install/prerequisites.html for additional info.
If you obtained GMP and/or MPFR from a vendor distribution package, make
sure that you have installed both the libraries and the header files.
They may be located in separate packages.
./install.sh: 25: [: 1: unexpected operator
make: *** No rule to make target 'all-gcc'.  Stop.
./install.sh: 25: [: 2: unexpected operator
make: *** No rule to make target 'install'.  Stop.
=== Building libgcc.a ===
mkdir: cannot create directory ‘build’: File exists
make: *** No rule to make target 'all-target-libgcc'.  Stop.
./install.sh: 25: [: 2: unexpected operator
make: *** No rule to make target 'install-target-libgcc'.  Stop.
./install.sh: 25: [: 2: unexpected operator
=== Installation complete ===
"

Moreover I do not find the compiler binary in /opt/gcc4ti/bin nor in /opt/gcc4ti/tms9900/bin.

Could someone please write some installation step by step instructions?
 

Share this post


Link to post
Share on other sites
8 hours ago, Fabrizio Caruso said:

Hi to everyone,
Once again, I have to re-install GCC 4 TI. I have tried with the very latest installer hoping to get it installed easily...
I cannot see find the instructions on how to use the installer.
If I run it with "sudo ./install.sh /opt/gcc4ti"
I get these errors
...
configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.2+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
See also http://gcc.gnu.org/install/prerequisites.html for additional info.
If you obtained GMP and/or MPFR from a vendor distribution package, make
sure that you have installed both the libraries and the header files.
They may be located in separate packages.
./install.sh: 25: [: 1: unexpected operator
make: *** No rule to make target 'all-gcc'.  Stop.
./install.sh: 25: [: 2: unexpected operator
make: *** No rule to make target 'install'.  Stop.
=== Building libgcc.a ===
mkdir: cannot create directory ‘build’: File exists
make: *** No rule to make target 'all-target-libgcc'.  Stop.
./install.sh: 25: [: 2: unexpected operator
make: *** No rule to make target 'install-target-libgcc'.  Stop.
./install.sh: 25: [: 2: unexpected operator
=== Installation complete ===
"

Moreover I do not find the compiler binary in /opt/gcc4ti/bin nor in /opt/gcc4ti/tms9900/bin.

Could someone please write some installation step by step instructions?
 

 

Depends on your operating system...  This one still holds for most ubuntu, probably debians... 

 

 

Then I found with latest, ubuntu, I needed the patch described in this post:

 

 

[email protected]

 

 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Hi everyone!

I have managed to compile a slimmed-down version of my C game (https://github.com/Fabrizio-Caruso/CROSS-LIB).

I am using this Makefile: https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/makefiles.chase/targets/Makefile.gcc_tms9900_targets


There is a problem (repeated definitions) for which I am using a workaround to silence the warning/error.
 

I get a .cart and a .elf file (in the attachments here). If I attach the .cart file into classic99, I can start it but I get a repeating high-pitched sound instead of a hello world message as I expect in my code:

#include "system.h"
#include <conio.h>
void INIT_GRAPHICS(void) {
    set_text();
    charsetlc();
    textcolor(COLOR_WHITE);
    bgcolor(COLOR_DKBLUE);
    gotoxy(2,2);
    cprintf("Hello world\n");
    while(1){};
}

Could someone help me please figure out what is wrong?

 

ti99_cross_chase.cart ti99_cross_chase.elf

  • Like 3

Share this post


Link to post
Share on other sites

GCC for TI-99  calling conventions and program image details.

 

I have not used the GCC port for TI-99 but I am curious about providing a way to call C code from my Forth system. This is done in commercial Forth systems and I did this in the old days from a DOS Forth.

https://www.mpeforth.com/software/forth-cross-compilers/mixed-language-programming-using-sockpuppet/ )

 

Once you know the calling conventions and register allocations it's pretty straightforward.

 

Is there a document that shows the innards of an object file and the organization of the binary images?

 

Why would you do this? 

  • Forth can provide a nice debugger environment for C sub-routines allowing you to push parameters onto the stack frame interactively and call your C code from a command line
  • inspect and alter variables interactively, HEX dump arrays and thing like that after running pieces of code
     
  • The Forth programmer can use lib code from C to extend the Forth system functionality in the same way this is done in Lisp and Python. (remove wheel inventing)

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Somewhere way back in time, in this thread, Insomnia describes it... 

 

basically:

* functions are called with BL

* they respect R11 as the return address

* R10 is the stack pointer, counts down.

* parameters are passed in the current workspace as R1 - R8? maybe... I'm sure there is a limit ( it might start using stack after that limit ) 

* R10 should be the same when the function returns

* return value is in R1

* byte type parameters are placed in high byte of register (fact check me) 

 

BLWP/RTWP is not used, and R13-R15 are also generally not used. 

R12 is generally not used, - I've observed the general practice of abusing it in inline assembly, or properly using it for crubase in inline assembly - 

I don't think I've ever seen it generate code with R0 used. I abuse R0 in my inline assembly.

 

Object files produced are in ELF-32 format (or some elf format), gcc linker also produces an ELF file, gcc objdump tools are used to extract binary images linked to specified addresses ( like program images without the EA5 header ), other tools will convert the ELF to EA5 or ELF to cartridge bin.

 

 

 

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites

Yeah, after a bit of research, this was what I came up with for the GCC register usage -- I can't say 100% that it's correct, but it worked for me.

 

* TMS9900 GCC Register classification
* R0 - Volatile, Bit shift count
* R1 - Volatile, Argument 1, return value 1
* R2 - Volatile, Argument 2, return value 2
* R3 - Volatile, Argument 3
* R4 - Volatile, Argument 4
* R5 - Volatile, Argument 5
* R6 - Volatile, Argument 6
* R7 - Volatile, Argument pointer
* R8 - Volatile, Frame pointer
* R9 - Preserved across BL calls
* R10 (SP) - Preserved across BL calls, Stack pointer
* R11 (LR) - Preserved across BL calls, Return address after BL
* R12 (CB) - Volatile, CRU base
* R13 (LW) - Preserved across BL calls, Old workspace register after BLWP
* R14 (LP) - Preserved across BL calls, Old program counter after BLWP
* R15 (LS) - Preserved across BL calls, Old status register after BLWP

 

I can't say anymore where this came from or whether it's compiled from a variety of sources...

 

  • Like 6

Share this post


Link to post
Share on other sites

Hi all,

 

when I tried to build GCC, an error showed up when compiling the binutils:

 

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: dwarf.o:D:\Download\TI-99\gcc\binutils-2.19.1\binutils/dwarf.c:56: multiple definition of `do_wide'; readelf.o:D:\Download\TI-99\gcc\binutils-2.19.1\binutils/readelf.c:169: first defined here
collect2.exe: error: ld returned 1 exit status

 

My environment:
Windows 10
msys2
mingw32_64 10.2.0

 

The variable do_wide is defined in both dwarf.c and readelf.c. When linking, you then get the error because the generated file readelf.exe consists of, among others, dwarf.o and readelf.o.

 

Does anybody know a workaround or a solution for it?

 

Thanks in advance.

 

Share this post


Link to post
Share on other sites
1 hour ago, Kal El said:

Hi all,

 

when I tried to build GCC, an error showed up when compiling the binutils:

 

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: dwarf.o:D:\Download\TI-99\gcc\binutils-2.19.1\binutils/dwarf.c:56: multiple definition of `do_wide'; readelf.o:D:\Download\TI-99\gcc\binutils-2.19.1\binutils/readelf.c:169: first defined here
collect2.exe: error: ld returned 1 exit status

 

My environment:
Windows 10
msys2
mingw32_64 10.2.0

 

The variable do_wide is defined in both dwarf.c and readelf.c. When linking, you then get the error because the generated file readelf.exe consists of, among others, dwarf.o and readelf.o.

 

Does anybody know a workaround or a solution for it?

 

Thanks in advance.

 

Edit the code. Make them both static if they aren't declared for consumption by other modules... Then they won't escape the modules. Or if they do the same thing, remove one and fix the code to understand that. If you are lucky it doesn't turn into a rabbit 🐇 hole.

 

Mostly people have used cygwin and then moved over to WSL if they wanted this gcc on windows. The others have just used Linux directly. So by choosing ming32, you might be putting yourself on one of those bleeding edges. 

 

If you do get it to work, post a patch... Someone else will want it someday.

Share this post


Link to post
Share on other sites
On 12/27/2020 at 10:14 AM, Kal El said:

when I tried to build GCC, an error showed up when compiling the binutils:

 

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: dwarf.o:D:\Download\TI-99\gcc\binutils-2.19.1\binutils/dwarf.c:56: multiple definition of `do_wide'; readelf.o:D:\Download\TI-99\gcc\binutils-2.19.1\binutils/readelf.c:169: first defined here
collect2.exe: error: ld returned 1 exit status

 

On 12/27/2020 at 12:12 PM, jedimatt42 said:

Mostly people have used cygwin and then moved over to WSL if they wanted this gcc on windows. The others have just used Linux directly. So by choosing ming32, you might be putting yourself on one of those bleeding edges. 

This is also happening on Fedora Linux - GCC v10.2.1  I don't know when this started happening, although I was able to build previously with GCC v6.3.

 

I tweaked the code a bit, fixing the error above as well as some other instances of multiple definitions.  There are two ways for you to apply my "fixes".  Choose one:

 

1) gcc10-src.zip - this contains the updated source files.  Unzip this file into your copy of the binutils source.  Then build as you normally would.

 

OR

 

2) gcc10-patch.zip - this contains an updated install script and an additional patch file.  The patch assumes that @insomnia's original patch has run.  Unzip this to where the existing install script is and run.  This new install script runs @insomnia's original patch, then runs my new patch.

 

I didn't study the side effects of my code changes on binutils.  So if you use any of the binaries in binutils, and it doesn't do what you expect - let me know.  However, I was able to build a TI cart image and run it in Classic99.

gcc10-patch.zip gcc10-src.zip

  • Thanks 1

Share this post


Link to post
Share on other sites

Hi, watching this thread now as well as I intend to try converting one of my programs in C to the TI-99/4a target.

Have to say that this thread is enormous, with my first try at building the GCC for TI target failing miserably. So will reread this complete thread more carefully.

 

But if anyone already has a dummy proof guide on setting this up under Windows Subsystem for Linux (using Ubuntu), preferably in a way that does not screw up the ability to use GCC also still for building CC65 on the same machine (as my other targets that I build for now are Commodore 128 and Oric Atmos, and have chosen for now to use CC65 under Linux) other than stating 'just read the whole thread', please let me know ;-)

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...