GCC for the TI

[+jedimatt42]

I am happy to write up a guide for my own benefit and share it. I don't recall it being challenging the last time I did this. The prerequisites change with each release of Ubuntu, potentially.

 

Most of my 4A software depends on this stack.

 

But generally you start with post #1, follow those instructions. Then when an error is encountered, use the topic search function here, with a distinct minimal snippet of the error, and proceed...

 

Successful build has always produced a pile of errors at the end (for me, but in parts I didn't need, latest build scripts produce a successful build). 

 

It builds uniquely named executables and installs them in the directory you specify, so it never breaks your existing compilers for gcc or other things.

Edited March 13, 2021 by jedimatt42

[+jedimatt42]

I've performed a fresh Ubuntu 20.10 virtual machine installation, and then performed the steps in this installation guide...  (edit updated guide in this post: 

 

The promise of Ubuntu on WSL """Should""" work the same. 

Edited March 13, 2021 by jedimatt42
Newer guide a few posts later...

[xahmol]

Thanks @jedimatt42 . Will definitely try to use that (when time permits).

[xahmol]

Update: Many thanks @jedimatt42 . The install seems to work and was very easy and idiot proof with your instructions and install script. Much appreciated!

Now will proceed to learn to make my first TI hello world, learn specifics about the TI graphics and learn how to do file access hopefully.

[+jedimatt42]

19 minutes ago, xahmol said:

Update: Many thanks @jedimatt42 . The install seems to work and was very easy and idiot proof with your instructions and install script. Much appreciated!

Now will proceed to learn to make my first TI hello world, learn specifics about the TI graphics and learn how to do file access hopefully.

 

I have an update, that covers some other linking/file-format tools I forgot about... they are convenient, I use them with my smaller projects... And I'm renaming the guide so it stands out a little better in this thread's attachment list:

 

tms9900gcc-Ubuntu-Installation-Guide.md

 

[xahmol]

Thanks again! Have a fully functional environment now. Able to build your memory test example and run it in Classic 99. Even build my first Hello World progam. Which works, but I see I really have to learn about TI graphic modes first and what to use when.
I basically want a text screen, but with the ability to color each char independently. See in my quick test that set_text() only gives monochrome. But at least the code worked apart from the colors!

 

Any suggestions for good sample C source or even completed programs/games writtten in C for use with tms9900gcc that I can learn from? Apart from your memorytester of course.

Edited March 14, 2021 by xahmol

[+Lee Stewart]

19 minutes ago, xahmol said:

I basically want a text screen, but with the ability to color each char independently.

 

Part of what you will learn about TI-99/4A graphics is that the TMS9918A Video Display Processor cannot “color each char individually”. In Text mode, all chars will have the same color. In Graphics mode, the color table supports only 32 character sets for ASCII 0 – 255, which means changing the color for 8 contiguous chars at once. If you change the color of ‘A’, i.e., color for character set 8, the colors for “@ABCDEFG” will all change to that color.

 

You could effectively do what you want in Bitmap mode, which allows color changes at a granularity of 8 horizontal bits (each “character” is 8 dot rows, 8 bits wide), but your “character” set would be frustratingly complicated—theoretically possible (I think), but hardly worth the effort.

 

...lee

[Tursi]

Possible, yeah, but you pretty much have to treat the bitmap screen like a bitmap screen to pull it off. There's no text mode on the standard VDP that can color each character independently.

 

The F18A can do it if you want to lock your program down to it's feature set.

 

 

[xahmol]

Well, I take your word for it as you definately know much more about programming the TI than I do and Tursi obviously knows his own library much better than I do, but I actually just compiled the Testlib of the libti99 library, and there the sample code seems to indicate that I can do what I am looking for in either set_text64_color(); mode or set_bitmap(0);.

 

Also I see that set_text64_color(); mode does seem to support conio.h bgcolor and textcolor functions.

// set_text64_color - sets up simulated 64-column text mode in bitmap mode - 64x24
// Inputs: none
// this version enables the screen and sets the KSCAN copy for you
// Use bgcolor and textcolor functions from conio to change colors.
void set_text64_color();

 

So that should do what I am looking for? Or do I miss something?

I am inclined on using text64 mode as that means standard conio color functions seem to work (so no rework of code needed coming from CC65). Also no need to squeeze the screen from 40 to 32 columns but even some extra screen real estate.

 

Do not want to go to F18A only modes as I do not have one (yet at least), and I want to be able to run the code at least on my own original machine ?

Edited March 14, 2021 by xahmol

[+9640News]

1 hour ago, Lee Stewart said:

 

Part of what you will learn about TI-99/4A graphics is that the TMS9918A Video Display Processor cannot “color each char individually”. In Text mode, all chars will have the same color. In Graphics mode, the color table supports only 32 character sets for ASCII 0 – 255, which means changing the color for 8 contiguous chars at once. If you change the color of ‘A’, i.e., color for character set 8, the colors for “@ABCDEFG” will all change to that color.

 

You could effectively do what you want in Bitmap mode, which allows color changes at a granularity of 8 horizontal bits (each “character” is 8 dot rows, 8 bits wide), but your “character” set would be frustratingly complicated—theoretically possible (I think), but hardly worth the effort.

 

...lee

It's not easy, but there does exist code with some tweaking one could probably use as a foundation for writing individual characters with independent colors in a graphics mode on the TI-99/4A.  Mike Riccio wrote GEME as a test case for the Geneve, and he coded for the 512x212 screen, that writes characters from an 8x8 pixel character definition.  Never tested, but his coding allowed one to also define other fonts of various sizes. And, if one is looking for other fonts, I would refer them to CSGD's massive font collection.

 

Mike's coding allowed one to pass characters/strings to his calls, which would then write the string to where you wanted to place them on the screen.  I'm fairly sure the code could be modified. It would sure beat writing from scratch.  With a SAMS, I could easily see storing various fonts.

 

The big issue I see would be speed as the 4A is about a third of the speed of the Geneve and then if you wanted to scroll said screen, things would get really slow.

 

I have attached the GEME source to this post from out of 9640 News, Volume 3, #3.  It is not Mike's original code as I started adding things to it to try and move it forward that never materialized.  Still though, Mike's code is all there.

 

Beery

GEME-ARK

[webdeck]

19 minutes ago, 9640News said:

It's not easy, but there does exist code with some tweaking one could probably use as a foundation for writing individual characters with independent colors in a graphics mode on the TI-99/4A.  Mike Riccio wrote GEME as a test case for the Geneve, and he coded for the 512x212 screen, that writes characters from an 8x8 pixel character definition.  Never tested, but his coding allowed one to also define other fonts of various sizes. And, if one is looking for other fonts, I would refer them to CSGD's massive font collection.

 

Mike's coding allowed one to pass characters/strings to his calls, which would then write the string to where you wanted to place them on the screen.  I'm fairly sure the code could be modified. It would sure beat writing from scratch.  With a SAMS, I could easily see storing various fonts.

 

The big issue I see would be speed as the 4A is about a third of the speed of the Geneve and then if you wanted to scroll said screen, things would get really slow.

 

I have attached the GEME source to this post from out of 9640 News, Volume 3, #3.  It is not Mike's original code as I started adding things to it to try and move it forward that never materialized.  Still though, Mike's code is all there.

 

Beery

GEME-ARK 92.38 kB · 5 downloads

Going to college brought my Geneve work to a halt for the most part.  Once I got introduced to more powerful Unix workstations and Macs, it was hard to go back.  ?

[xahmol]

Well, I am intending on converting a board game, so speed would not be a real bottleneck. No scrolling or stuff like that.

I would need the ability to redefine the charset though, and hopefully also a way to copy a screen from memory and to memory.

Still very novice as TI programming (used to do TI BASIC 38 years or so ago, but only recently reacquired a TI), so hope to do so with C libs from others and be able to reuse my existing CC65 code.

 

[xahmol]

But it might be an issue that as I now understand, the graphic modes I want to use are apparently bitmaps mode, making screens of course significantly bigger in memory size to copied around with. That might be an issue in memory constraints.

Will do further exploration first, but any pointers/examples are very welcome.

[+arcadeshopper]

But it might be an issue that as I now understand, the graphic modes I want to use are apparently bitmaps mode, making screens of course significantly bigger in memory size to copied around with. That might be an issue in memory constraints.
Will do further exploration first, but any pointers/examples are very welcome.

Most people use the character mode when making games because you can control the colors of the characters and redefine them so that usually works pretty well the big concern is how detailed you want the graphics to be if you want them to be super detailed then you have to use bitmap mode but remember that colors can only be within the same eight pixel group even in bitmap mode you'll see that in a lot of converted pictures where it looks like little 8-bit blocks of color chunks you can't do each individual pixel as a color

Sent from my LM-V600 using Tapatalk

[xahmol]

Think the best illustration of what I want to do is the game I want to convert on Oric Atmos target, see:

https://github.com/xahmol/ludo

This has been done in text mode with redefined charset.

Edited March 14, 2021 by xahmol

[PeteE]

3 hours ago, xahmol said:

Think the best illustration of what I want to do is the game I want to convert on Oric Atmos target, see:

https://github.com/xahmol/ludo

This has been done in text mode with redefined charset.

Check out the Magellan thread for a nice tool for mocking up screens for the TMS9918A and F18A graphics modes, be sure to check the last page of the thread has a link to Asmusr's latest version 4.0.0.  It will give you a good feel of the limitations and possibilities of each graphics mode.  The above image should definitely be a good fit for Graphics 1 Color Mode, making some adjustments to fit in 24 lines.

[xahmol]

12 minutes ago, PeteE said:

Check out the Magellan thread for a nice tool for mocking up screens

Thanks! Good suggestion, actually just found that tool myself as well from the startpost and reading that thread. Will definitely start there, as building the screen has to be my start anyway and this seems the best tool to do so.

Looks like CharPad for the Commodore 64 that I already have been using.

[Tursi]

6 hours ago, xahmol said:

Well, I take your word for it as you definately know much more about programming the TI than I do and Tursi obviously knows his own library much better than I do, but I actually just compiled the Testlib of the libti99 library, and there the sample code seems to indicate that I can do what I am looking for in either set_text64_color(); mode or set_bitmap(0);.

Both of those are bitmap mode.

 

64 characters was a popular size because 256 / 64 gives you 4 pixels for each character. You have to treat it as a bitmap mode, so you draw the pixels then draw the colors.

 

I didn't write the 64 column mode, but it's fair to say I know the hardware reasonably well after 35 years of continuous development.

 

[xahmol]

Thanks for all the tips. Will continue researching and ask my questions that doubtlessly will be coming in new topic as not to hijack this topic any further  

[xahmol]

Yes! Finally! Finally have my first very small hello world with a Magellan made screen compiling and working.

Was really not understanding why it was not working, as I did everything exactly the same as the Memtest example that was working. Until I realised a cartridge .bin image filename needs to end on C..... Duh.....

That took me some time. But glad it works now! Can start to build now and see if I can fit all in the TI contraints.

 

To do still is to learn how to do disk access via TIPI from C code (as I yesterday got my TIPI working). As I am completely blank on how disks were operating on the TI in the past (never had a disk for my TI) that will take some learning still.

See the Libti99 libtary has DSR functions, assume I need to use those? Any working code examples in C on how to work with a TIPI with those?

Edited March 20, 2021 by xahmol

[+jedimatt42]

The TIPICFG source in the TIPI repo on github uses libti99's DSR routines to read and write.

[xahmol]

7 minutes ago, jedimatt42 said:

The TIPICFG source in the TIPI repo on github uses libti99's DSR routines to read and write.

Great! Then I should be able to work from that. Plan to use that for the functionality to save and load savegames.

[xahmol]

21 minutes ago, jedimatt42 said:

The TIPICFG source in the TIPI repo on github uses libti99's DSR routines to read and write.

Checked now and that seems certainly workable, can follow the code and seems not too complicated.... (hope I do not underestimate something).
Funny is that I had the repo actually already open in a browser tab from installing my TIPI yesterday. Thanks! Looks like I definately will need to credit Jedimatt42 in my source (next to PeteE for giving pointers on how to work with Magellan).

[xahmol]

Question: any ideas / good code examples for a semi randomiser function in C for the TMS9900-GCC compiler?

 

I saw this in PeteE's Turmoil example:

static u16 random(void)
{
	static u16 seed = 0xaaaa;
	static const u16 random_mask = 0xb400;

	asm volatile (
		"srl %0,1  \n\t"
		"jnc 1f    \n\t"
		"xor %2,%0 \n\t"
		"1:        \n\t"
		: "=r"(seed)
		: "0"(seed),"m"(random_mask)
	);
	return seed;
}

This works, but gives exactly the same sequence of random numbers on every execution. So I need something to make the seed semi random as well. On my Oric Atmos target I used the clock() function for that (which gives CPU cycles since start) as that almost never is exactly the same twice depending on user input (no one presses Press key to start exactly the same moment every time).
Suggestion how to do that for the TMS9900-GCC target as it seems not to have a clock() function in LIBTI99?

[Tursi]

That's an old routine that I've been pushing around since I learned it from the Dreamcast community, who picked it up from somewhere else... it's a nice routine in that it guarantees to return every number in the sequence once before repeating (except 0), and it's very fast.

 

To get a different sequence, you need to change the seed... when I use it I keep the seed external so that I can do that. Then you can take the seed from any source of entropy you like.

 

What I find works well, is any time you are waiting for the user (title page, statistics page, any input at all), just call random() as part of the loop. It's difficult to get the same starting point each time and so you'll normally get a pretty good result out of that.