GCC for the TI

[TheMole]

You can actually ignore that, check if the binaries are created in the directory you chose for the install script tms9900/bin/tms9900-gcc should be there

Edited November 7, 2017 by TheMole

[+Lee Stewart]

As no one else here has said anything about it, it probably is not germane, but are you starting from the right directory, i.e., is the relevant ‘bin’ directory the current directory? It seems that a lot of paths in the makefile script are relative to it.

 

...lee

[TheMole]

*double post*

Edited November 7, 2017 by TheMole

[Fabrizio Caruso]

It has created tms9900-gcc despite the final errors!

 

The compilation of a simple standard hello world code fails due to missing stdio.h. This may be expected. Isn't it?

 

I will try your own hello world example..

[Fabrizio Caruso]

Is the error about libstdc++ the reason why no stdio.h is found? Or is the lack of stdio.h just expected because not (yet) implemented?

[TheMole]

There is no full-fledged stdio.h implementation available for the TI. Usually one would either roll their own I/O functions, or use Tursi's excellent libti99 (or a hybrid approach) which can be found here: https://github.com/tursilion/libti99

 

Basic stdio-type stuff like putc and getc are fairly straightforward to implement so if that's all you need I don't see many issues. printf style functionality should be doable via va_list, but if you can avoid going that route you can get much better performance by building your strings yourself (int2str style functions are available in libti99). Finally, if you're planning on doing disk i/o, you should probably learn a bit about the TI's record and image based file system, the standard unix style approach doesn't really map that well onto the TI paradigms. There too, libti99 is your friend!

 

If you can share specifically what you want to achieve, I'm happy to look at the best implementation strategy with you.

[Asmusr]

Hi

 

All commands in produce the same result: nothing is displayed and nothing is done with the input file.

I have attached a snapshot.

 

Fabrizio

 

 

After installing Cygwin and Tursi's tms9900 directory I'm getting the same: nothing happens when you execute the commands.

[lucien2]

 

 

After installing Cygwin and Tursi's tms9900 directory I'm getting the same: nothing happens when you execute the commands.

 

Same here on Cygwin 1.7.9 (2011).

It works on Cygwin 2.9.0 (latest version).

[Fabrizio Caruso]

@TheMole the reason why I need GCC for TI and I need it almost full ANSI including macros is my project:

https://github.com/Fabrizio-Caruso/CROSS-CHASE

 

where I am writing a universal game for ALL 8-bit computers from the 70s and 80s (some consoles and handhelds as well).

I am making a special exception for our beloved 16-bit computer because it is from the same 8-bit era.
It is currently compiled by different tool-chains and compilers including both Z88DK compilers, CC65, WinCMOC.

 

Currently CROSS-CHASE supports more than 50 configurations for almost 40 different computers (more than the ones shown on GitHub).

Most systems have sound and some have some graphics.

The game uses THE SAME code for ALL targets (+ few specific bits in some cases).
This is achieved by using abstractions and lots of macros.

The goal is not to "port" the game but to adjust the code so that the very same code and Makefile can be used to generate a Ti99 version.

Edited November 8, 2017 by Fabrizio Caruso

[TheMole]

Yes, I remember the original topic on this. I don't think that's a problem, as you're already using an abstraction layer so it should be straightforward to get it up and running without effectively having to "port" it by - for instance - implementing what you need from conio.h for the TI.

 

From your original post though

Ideally I would like to have conio.h for input/output but I can live without it as long as I get:

1. [output] a function to print a given ASCII character at x,y

2. [input] a function to read the keyboard without waiting for a key press

I imagined that you needed nothing in the sense of libraries, except for those two functions. If you could provide a list of interfaces you need, I'd be happy to look at creating a platform specific shim layer that works for you.

[Fabrizio Caruso]

@TheMole
MINIMUM:
The minimum requirement for my game is to have something equivalent to
- textcolor(chosen_color); gotoxy(x,y); cputc("c"); -> display charactr c at x,y with color chosen_color

- if(kbhit()) {do_something(cgec()); } -> read keybord and/or something similar to read the joystick input
- something to display text and numbers (possibly padded with front zeros) at a given position on the screen

Remark: conio.h (with coordinates starting at (0,0)) is the de-facto standard on ALL 8-bit tool-chains (Z88DK, CC65, WinCMOC).
Having some conio.h implementation (e.g., as macros) would imply instant ports to the TI99 from all 8 bit systems as well as DOS.

EXTRA:
My game supports sound and graphics as extra options on many targets:

- for the sound effects (all short sounds because I am not using interrupts in almost no target)
I am using the following APIs:

1. PING_SOUND(), TICK_SOUND(), TOCK_SOUND() -> very very short sounds with different frequencies
2. ZAP_SOUND() -> short sound with an increasing frequency
3. EXPLOSION_SOUND(), SHOOT_SOUND() -> short noise effects with different frequencies

- for better graphics I am using primarily user-defined characters (and sprites in some experimental versions).
I do this in different ways because each compiler/linker and target has different ways to achieve this result.

FUTURE EXTRA:
I may also implement some abstractions for a simple intro music and/or between-levels music through something like PLAY_NOTE to play a note of a given instrument for a given voice but this is not yet decided in details. The idea is to have some APIs to play music that should work even on systems with 1 voice and produce the second and third voice whenever such voices are supported by the target hardware. So the main music should be single-voice and second and third channels should provide some extra music effects. The music is supposed to be the same for all targets that support some sound output.

Edited November 9, 2017 by Fabrizio Caruso

[Tursi]

Same here on Cygwin 1.7.9 (2011).

It works on Cygwin 2.9.0 (latest version).

That makes sense to me, I downloaded a new install of Cygwin on a fresh machine to build it.

[Fabrizio Caruso]

I used the latest 64 bit Cygwin installation on three different computers

[Tursi]

I used the latest 64 bit Cygwin installation on three different computers

 

Well, there's the missing piece of data -- I built it for 32-bit.

 

I've confirmed here that there is no output when I run under the 64-bit version of Cygwin.

 

We're past that anyway, right? You have a working compiler now?

[Tursi]

Well, I coded up a conio implementation for libti99, but I need to test it (and push it, if github ever lets me log in...). I used the cc65 header as a reference since it wasn't a standard include, and it had a reasonable set of functions. The only one I'm not sure about is printf -- did varargs get into the compiler?

[TheMole]

Well, I coded up a conio implementation for libti99, but I need to test it (and push it, if github ever lets me log in...). I used the cc65 header as a reference since it wasn't a standard include, and it had a reasonable set of functions. The only one I'm not sure about is printf -- did varargs get into the compiler?

Ah, you beat me to it .

Yes, I believe va_lists are supported, I seem to remember having used that feature all the way back in 2012.

[Tursi]

Hehe, I figured I'd be racing someone. I've finished testing and pushed the working code to GitHub - in addition I updated testlib with examples. The only thing I deliberately didn't do was printing floats from cprintf - I didn't feel like working that out tonight. I used this page as a function reference: www.cc65.org/doc/funcref-14.html

 

The nice side effect is libti99 now has a much nicer console text library, so I'll probably deprecate the old functions (although the only one I'll probably remove is the old printf, since that'll be confusing...) Of course the older code is much less intelligent and cares more about performance than functionality, so the rest can stay.

 

Two things I noted - I couldn't do vcprintf because passing va_list arguments caused errors I didn't dig into (or care much about, honestly), and in patch 14 of the compiler that I have installed, puff() failed to decrypt its string in testlib. I'll have to update my local compiler to see what's up.

[Fabrizio Caruso]

@Tursi, great to know we will have a conio implementation. Please let me know when it is ready and available.
My game would be a good non-trivial test.

I have two important suggestions:

1. Be careful with the implementation of kbhit and cgetc:
- kbhit should not consume the input. it should ONLY detect any keyboard press
- cgetc/kbhit should be able to detect continued key press.

A partial test to see if kbhit is corrrectly working is the following function that should do what one would expect from it.
You can use it more than once in a simple test to see that it is working correctly.

void WAIT_PRESS(void)
{
while(kbhit())
cgetc();
while(!kbhit())
{
};
cgetc();
}

2. Please use the (0,0) as coordinates for upper left corner as in CC65, Z88DK and WinCMOC and not as in some DOS implementations. Using CC65 as template is a good choice!! It is the template used in Z88DK and WinCMOC!

[Tursi]

@Tursi, great to know we will have a conio implementation. Please let me know when it is ready and available.

 

1. Be careful with the implementation of kbhit and cgetc:

- kbhit should not consume the input. it should ONLY detect any keyboard press

- cgetc/kbhit should be able to detect continued key press.

 

2. Please use the (0,0) as coordinates for upper left corner as in CC65, Z88DK and WinCMOC and not as in some DOS implementations. Using CC65 as template is a good choice!! It is the template used in Z88DK and WinCMOC!

 

It's already ready and available. I completed testing it last night.

 

kbhit/cgetc are documented to work with the concept of a keyboard buffer -- that conflicts with the concept of continued keypress IMO, and so I deliberately made it not do that. That's my personal preference, I guess. Call "key=kscan(5)" instead if you want the "currently pressed" key at any time, you can just use a #define in your code to make that happen. As for coordinates, yes, I'm a programmer, I count starting at 0.

 

This thread isn't the right place to go into details of libti99 though, it's more of an aside to Insomniac's work.

[TheMole]

Hehe, I figured I'd be racing someone. I've finished testing and pushed the working code to GitHub - in addition I updated testlib with examples. The only thing I deliberately didn't do was printing floats from cprintf - I didn't feel like working that out tonight. I used this page as a function reference: www.cc65.org/doc/funcref-14.html

 

The nice side effect is libti99 now has a much nicer console text library, so I'll probably deprecate the old functions (although the only one I'll probably remove is the old printf, since that'll be confusing...) Of course the older code is much less intelligent and cares more about performance than functionality, so the rest can stay.

 

Two things I noted - I couldn't do vcprintf because passing va_list arguments caused errors I didn't dig into (or care much about, honestly), and in patch 14 of the compiler that I have installed, puff() failed to decrypt its string in testlib. I'll have to update my local compiler to see what's up.

 

Tried compiling the latest version on github, but the build fails because of a missing rule for the vdp_fastscrnscroll.o target. There's no source file in the repository that seems to be a match for that target, so I guess it somehow didn't get uploaded to the repository. I did get it to build perfectly fine by removing the reference in the Makefile. I'll play around with the new conio.h functions as soons as I have some time, if only I could come up with a suitable cross-platform game to try...

[Tursi]

 

Tried compiling the latest version on github, but the build fails because of a missing rule for the vdp_fastscrnscroll.o target. There's no source file in the repository that seems to be a match for that target, so I guess it somehow didn't get uploaded to the repository. I did get it to build perfectly fine by removing the reference in the Makefile. I'll play around with the new conio.h functions as soons as I have some time, if only I could come up with a suitable cross-platform game to try...

 

Ah, thanks for the note! I pushed the missing file. It just scrolls a little faster by using a bigger static buffer (256 bytes static instead of 4 bytes on the stack). Watching 80 columns scroll was hurting my feelings.

[TheMole]

I've been trying to port Super Uwol to the TI. It's a pretty nifty little game, written almost entirely in C for the Sega SG-1000 (which is basically an MSX/Colecovision in another case). It uses a library for all it's hardware access, and targets the same VDP as ours, so it should be doable.

 

However, in the process of cleaning up the code and making it "gcc ready" (it targets SDCC, which has its own dialect for certain functionality such as flagging variables as volatile and direct memory access), I stumbled into what might be a gcc bug:

themole@ubuntu:~/uwol/SuperUwol/dev$ make
tms9900-gcc -c uwol.c -Os -Wfatal-errors -o uwol.o

----8<-----------8<------
cut out a bunch of warnings here regarding implicit casts and pointer conversions
----8<-----------8<------

In file included from uwol.c:73:
In file included from uwol.c:76:
In file included from uwol.c:81:
engine/enengine.h:88: internal compiler error: output_operand: invalid expression as operand
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Makefile:42: recipe for target 'uwol.o' failed
make: *** [uwol.o] Error 1

it should be noted that these "h" files actually contain fully implemented functions, not just function prototypes. Also, line 88 in enengine.h is the last line in the file, so there isn't much context to glean from that. I can provided access to the code in question on my server if that would help.

[insomnia]

Yep, sounds like a compiler bug.

 

If you can point me to your source code I'll take a look

[+arcadeshopper]

ubuntu 17.04 needs apt-get install tree for install.sh

 

fails in make

 

Makefile:394: recipe for target 'bfd.info' failed

Makefile:1094: recipe for target 'info-recursive' failed

Makefile:3094: recipe for target 'all-bfd' failed

got it to build fine on my 16.04 machine. ¯\_(ツ)_/¯

[unhuman]

Thanks @Tursi for the video... I watched it and have used it extensively.

 

@Insomnia, A few things that would be great to get added to the first post:

1. If you are using Cygwin, apparently you gotta use the 32 bit version. I started with 64 bit and had problems. Of course, maybe that was because I missed what appears below

2. export CFLAGS="-g -o2 -Wno-error" is very important. Tursi highlighted this, and I didn't see it elsewhere in the thread. But, I've been flying around quite a bit.

3. The installer script didn't work for me. Of course, I tried it with 64 bit. Could also be b/c it's missing CFLAGS.

 

Right now I'm going to compare what I can do with C versus XB.

 

Let the game (writing) begin!

 

-Howie

Edited February 26, 2018 by unhuman