Jump to content

Photo

GCC for the TI


345 replies to this topic

#326 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 760 posts
  • Location:Belgium

Posted Tue Nov 7, 2017 7:12 AM

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 by TheMole, Tue Nov 7, 2017 7:26 AM.


#327 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,386 posts
  • Location:Silver Run, Maryland

Posted Tue Nov 7, 2017 7:24 AM

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



#328 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 760 posts
  • Location:Belgium

Posted Tue Nov 7, 2017 7:26 AM

*double post*


Edited by TheMole, Tue Nov 7, 2017 7:27 AM.


#329 Fabrizio Caruso OFFLINE  

Fabrizio Caruso

    Space Invader

  • 44 posts

Posted Tue Nov 7, 2017 7:39 AM

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



#330 Fabrizio Caruso OFFLINE  

Fabrizio Caruso

    Space Invader

  • 44 posts

Posted Tue Nov 7, 2017 8:36 AM

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?



#331 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 760 posts
  • Location:Belgium

Posted Tue Nov 7, 2017 8:50 AM

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.



#332 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,465 posts
  • Location:Denmark

Posted Tue Nov 7, 2017 11:46 PM

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.



#333 lucien2 OFFLINE  

lucien2

    Moonsweeper

  • 284 posts
  • Location:Switzerland

Posted Wed Nov 8, 2017 12:15 AM

 

 

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



#334 Fabrizio Caruso OFFLINE  

Fabrizio Caruso

    Space Invader

  • 44 posts

Posted Wed Nov 8, 2017 2:44 AM

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

https://github.com/F...uso/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 by Fabrizio Caruso, Wed Nov 8, 2017 4:16 AM.


#335 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 760 posts
  • Location:Belgium

Posted Wed Nov 8, 2017 5:11 AM

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.

#336 Fabrizio Caruso OFFLINE  

Fabrizio Caruso

    Space Invader

  • 44 posts

Posted Wed Nov 8, 2017 6:41 AM

@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 by Fabrizio Caruso, Wed Nov 8, 2017 6:33 PM.


#337 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,823 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Nov 9, 2017 11:56 AM

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.

#338 Fabrizio Caruso OFFLINE  

Fabrizio Caruso

    Space Invader

  • 44 posts

Posted Thu Nov 9, 2017 12:22 PM

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



#339 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,823 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Nov 9, 2017 1:32 PM

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?



#340 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,823 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Nov 9, 2017 7:38 PM

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?



#341 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 760 posts
  • Location:Belgium

Posted Fri Nov 10, 2017 1:23 AM

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.

#342 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,823 posts
  • HarmlessLion
  • Location:BUR

Posted Fri Nov 10, 2017 3:39 AM

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.

#343 Fabrizio Caruso OFFLINE  

Fabrizio Caruso

    Space Invader

  • 44 posts

Posted Fri Nov 10, 2017 12:24 PM

@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!

 



#344 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,823 posts
  • HarmlessLion
  • Location:BUR

Posted Fri Nov 10, 2017 1:25 PM

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



#345 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 760 posts
  • Location:Belgium

Posted Tue Nov 14, 2017 4:29 AM

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



#346 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,823 posts
  • HarmlessLion
  • Location:BUR

Posted Tue Nov 14, 2017 11:38 AM

 

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






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users