Jump to content

Photo

GCC for the TI


447 replies to this topic

#426 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,323 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Oct 25, 2018 11:42 PM

Thanks for continuing to patch! It has really extended my interest in coding for the TI over the years. :)



#427 tschak909 OFFLINE  

tschak909

    River Patroller

  • 2,841 posts
  • Location:USA

Posted Thu Oct 25, 2018 11:46 PM

Yes. Between this version of GCC, and Tursi's libti99, I've been able to port PLATOTerm to the TI 99/4A :)

 

-Thom



#428 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • 688 posts
  • Location:Campbellsburg, KY

Posted Fri Oct 26, 2018 5:15 AM

Yes. Between this version of GCC, and Tursi's libti99, I've been able to port PLATOTerm to the TI 99/4A :)

 

-Thom

 

Thom,

 

Do you have PLATOTerm working properly yet with the PLATO Server?

 

Beery



#429 tschak909 OFFLINE  

tschak909

    River Patroller

  • 2,841 posts
  • Location:USA

Posted Fri Oct 26, 2018 8:14 AM

Nope, I am trying to get my hands on both a console and a TIPI, so I can debug this, as the turnaround times are terrible otherwise.

 

-Thom



#430 PeteE OFFLINE  

PeteE

    Chopper Commander

  • 168 posts
  • Location:Beaverton, OR

Posted Fri Oct 26, 2018 3:52 PM

Lately I've been getting this error when running install.sh: "raising the section level of @subsubsection which is too low".  This seems to be related to building the info documentation, which I will never use.  The workaround I've found is to set "MAKEINFO=missing" before ./install.sh on the command line.  Posting here for anyone else, and myself in the future when I forget.



#431 mindlord OFFLINE  

mindlord

    Star Raider

  • 85 posts

Posted Mon Oct 29, 2018 5:49 AM

I try to build GCC with the newest patch and all I get is:

mindlord@Myrthstation:~$ ./install.sh TMS9900NEW
Using these patches:
    binutils-2.19.1-tms9900-1.7.patch
    gcc-4.4.0-tms9900-1.17.patch

=== Creating output directory ===
=== Getting Binutils sources ===
=== Getting GCC sources ===
=== Make build directory ===
=== Decompressing and patching Binutils sources ===
=== Decompressing and patching GCC sources ===
=== Building Binutils ===
=== Building GCC ===
=== Installation complete ===

Nothing is in the folder. Not that I expected there to be. 



#432 chue OFFLINE  

chue

    Moonsweeper

  • 291 posts

Posted Mon Oct 29, 2018 6:38 AM

I try to build GCC with the newest patch...

 

 

Try removing the "build" folder and contents and see if that helps.  The folder should be in the same directory as the install.sh script.



#433 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 806 posts
  • Location:Belgium

Posted Tue Oct 30, 2018 6:57 AM

I can confirm that version 17 fixes the multiplication problem, so thanks for that!

I'm on to the next issue, which seems to be related to shifting of signed integers (and presumable longs as well). It get the following results:

Attached File  Screen Shot 2018-10-30 at 13.45.14.png   31.37KB   4 downloads

Attached File  Screen Shot 2018-10-30 at 13.44.34.png   37.2KB   4 downloads

 

This only happens with signed ints, not with unsigned ints where the results are as expected.

 

Just for context: this is the test code that I've used (fetch_input(a, b) fetches 'b' bytes from a file and stores it in memory location 'a') :

#define SHIFT1	 5
#define FETCH(x) fetch_input(&x, sizeof(x));
void test_shifts_int()
{
	int8 	input, fails = 0;
	int16	var = 0;

	cprintf("Integer shifts...");
	for (int i = 0; i < NUMLOOPS; i++)
	{
		FETCH(input);
		var = input << SHIFT1;
		if (input != (var >> SHIFT1))
		{
			cprintf("%d << %d = %d >> %d = %d\n", input, SHIFT1, var, SHIFT1, var >> SHIFT1);
			fails++;
		}
	}
}

 I believe this is breaking my sprite positioning and scrolling routines in Alex Kidd. Last known working version for me was patch 12.

 

 



#434 insomnia OFFLINE  

insomnia

    Star Raider

  • Topic Starter
  • 90 posts
  • Location:Pittsburgh, PA

Posted Wed Oct 31, 2018 12:09 AM

OK, I'm really embarrassed about this bug. It turns out that instead of emitting a right shift, we are emitting a left shift. As you discovered, this only affects signed integers.

 

I can only assume this was due to a cut-and-paste error somewhere that escaped testing.

 

This is a one-line fix, but I'll confirm that the rest of the shift operations work as intended before making another patch.



#435 mindlord OFFLINE  

mindlord

    Star Raider

  • 85 posts

Posted Wed Oct 31, 2018 5:46 AM

 
Try removing the "build" folder and contents and see if that helps.  The folder should be in the same directory as the install.sh script.

Thanks Chue, that was the missing puzzle piece.

Sent from my SM-J727V using Tapatalk

#436 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 806 posts
  • Location:Belgium

Posted Wed Oct 31, 2018 1:24 PM

This is a one-line fix, but I'll confirm that the rest of the shift operations work as intended before making another patch.

 

Sorry for drip feeding these bug reports, but I'm reporting them as I run into them. If you would prefer to send me a patch for me to test prior to you officially releasing it (and assigning a version number), I'd be happy to help, just let me know.



#437 insomnia OFFLINE  

insomnia

    Star Raider

  • Topic Starter
  • 90 posts
  • Location:Pittsburgh, PA

Posted Wed Oct 31, 2018 9:39 PM

A new patch is now available in the first post, and the installer has been updated as well.

 

So in this patch, we only have two fixes:

 

  Fixed 16-bit signed right shift
  Fixed 32-bit unsigned right shift
 

The 16 bit shift was shifting in the wrong direction, and the 32-bt shift was performing signed shifts.

 

TheMole found the 16-bit shift bug, and I found the other one after doing some automated testing. Hopefully that's the last of these kinds of errors.

 

 

 

Sorry for drip feeding these bug reports, but I'm reporting them as I run into them. If you would prefer to send me a patch for me to test prior to you officially releasing it (and assigning a version number), I'd be happy to help, just let me know.

 

Making new releases takes no effort at all, so don't worry about that. Also, I appreciate bug reports no matter if they are drip fed or not. Thanks for doing these tests, clearly my own testing has some gaps.



#438 tschak909 OFFLINE  

tschak909

    River Patroller

  • 2,841 posts
  • Location:USA

Posted Wed Oct 31, 2018 10:33 PM

@insomnia - You're hacking on a compiler, it's all edge cases from here down... :P :)

 

-Thom



#439 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,908 posts
  • Location:Denmark

Posted Wed Oct 31, 2018 11:58 PM

How do you install a patch?



#440 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 806 posts
  • Location:Belgium

Posted Thu Nov 1, 2018 5:41 AM

How do you install a patch?

 

In general, there's a utility called "patch" that you can use to apply a patch to a code base. However, in this case it's a simple matter of downloading the gcc installer, unpacking it, removing the old patch file from the unpacked folder and dropping in the new one. The install script looks for the patch file in the folder it is run from and calls the patch utility.



#441 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 806 posts
  • Location:Belgium

Posted Thu Nov 1, 2018 7:26 AM

I can confirm shifts are now working.

 

I'm on to the next problem though, I haven't identified the root of the problem yet, but I think it might be related to my use of function pointers. It seems like there's a problem passing variables. Passing literals as parameter seems to work, passing variables sometimes doesn't. I'll work on a more exact test case tonight, so hopefully I can come up with a more useful bug report :).



#442 mr_gw454 OFFLINE  

mr_gw454

    Star Raider

  • 50 posts

Posted Thu Nov 1, 2018 3:35 PM

Hello everyone.  Grabbed the latest version and ran the install.sh script (preceded with 'MAKEINFO=missing' as mentioned above to avoid that same error).  It made it this far and failed:

make[3]: Entering directory '/home/mrg/source/TI/build/gcc-4.4.0/build/libiberty/testsuite'
make[3]: Nothing to be done for 'install'.
make[3]: Leaving directory '/home/mrg/source/TI/build/gcc-4.4.0/build/libiberty/testsuite'
make[2]: Leaving directory '/home/mrg/source/TI/build/gcc-4.4.0/build/libiberty'
/bin/bash: line 3: cd: tms9900/libstdc++-v3: No such file or directory
Makefile:10623: recipe for target 'install-target-libstdc++-v3' failed
make[1]: *** [install-target-libstdc++-v3] Error 1
make[1]: Leaving directory '/home/mrg/source/TI/build/gcc-4.4.0/build'
Makefile:2475: recipe for target 'install' failed
make: *** [install] Error 2
=== Installation complete ===
 

Is the libstdc++-v3 library not built as part of this script?

 

Thanks for any help anyone can provide!



#443 chue OFFLINE  

chue

    Moonsweeper

  • 291 posts

Posted Thu Nov 1, 2018 4:34 PM

/bin/bash: line 3: cd: tms9900/libstdc++-v3: No such file or directory

 

See if my post here helps:

 

http://atariage.com/...e-ti/?p=3885112



#444 mr_gw454 OFFLINE  

mr_gw454

    Star Raider

  • 50 posts

Posted Thu Nov 1, 2018 5:23 PM

 

See if my post here helps:

 

http://atariage.com/...e-ti/?p=3885112

 

That helped -- thank you very much!



#445 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 806 posts
  • Location:Belgium

Posted Fri Nov 2, 2018 2:14 PM

So, the problem is not specific to function pointers...

 

In my game loop, I call a function to render the main character sprite to a RAM buffer. Since this needs a different approach for the 9918a and the F18A, I call this function via a pointer (so that I don't have to have if-then-else structures littered around the game code). The call looks like this:

(*alex_func)(action, (player.xpos >> 8) - scroll_x, (player.ypos >> 8), player.direction);

player.xpos and player.ypos are unsigned longs, and represent the player's position in the world. You can think of them as 24.8 fixed point numbers, as the least significant 8 bits are "subpixels". Hence the shift right by 8: this generates a pixel value.

 

scroll_x is an unsigned int, and represents the scroll position in the level. Action and player.direction are an integer and an unsigned char respectively that represent the player stance (walking, jumping, ...) and which direction he is facing.

 

If running on a 9918a equipped console, this points to the following function:

void put_alex(int stance, int x, int y, unsigned char direction);

Now, with version 12 of the patch, this worked perfectly. However, since then (I'm in the process of compiling a version of the compiler with each patch since 12 to identify when the problem started), the player sprite is stuck against the left side of the screen, which implies that whatever value player.xpos has, it comes in as 0.

 

First thing I tried was just calling the function directly:

put_alex(action, (player.xpos >> 8) - scroll_x, (player.ypos >> 8), player.direction);

But that didn't change anything. So probably not related to function pointers at all :).

 

Just to see if it was a problem with the calculation, I tried it with the literal value 16 (which is what ((player.xpos >> 8) - scroll_x) should evaluate to at the start of a level), like so:

put_alex(action, 16, (player.ypos >> 8), player.direction);

That indeed put the player at the right x-coordinate, but now the y-coordinate comes in as 0 making it so that the player is stuck at the top of the screen. Note that in the previous example, the y parameter did actually work as expected, so the problem just shifted from one parameter to another.

 

I also tried using an intermediate variable instead of putting the calculation in the function call, but that didn't make any difference.

 

Anyway, I do apologize for not being able to provide a straightforward piece of code that reproduces this behavior. I haven't exactly figured out what triggers it. Simpler programs don't seem to have this problem. Hope the above is useful anyway...



#446 Willsy OFFLINE  

Willsy

    River Patroller

  • 3,082 posts
  • Location:Uzbekistan (no, really!)

Posted Sat Nov 3, 2018 11:30 AM

How deep is the function call stack when this happens? Are you running out of stack space? (I wouldn't know how to test this in the C environment).

 

Mark



#447 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 806 posts
  • Location:Belgium

Posted Sun Nov 4, 2018 5:32 AM



How deep is the function call stack when this happens? Are you running out of stack space? (I wouldn't know how to test this in the C environment).

 

Mark

 

Good question, but I don't think I'm running out of stack space. The stack pointer is stored in r10, so easy to follow with the js99er debugger. It starts at 0x4000 and grows down. Upon entry of the put_alex function, the stack pointer is 0x3fd6 so only 42 bytes deep. There is code in the lower expansion segment, but it only goes up to 0x32dc so still plenty of room for the stack to grow further down (a little over 3k).

 

In terms of call stack depth, it goes like this:

main() -> do_level() -> _do_level() -> game_loop() -> put_alex(int stance, int x, int y, unsigned char direction)

 

(The do_level() -> _do_level() call may look a bit odd, but this is just to enable bank switching: main is in bank 1, do_level is a trampoline function in lower expansion memory, _do_level sits in bank 2). All of these, except for the last one don't pass parameters and rely on global variables for state, so maybe that's where I need focus my efforts. I'm going to try re-working the code to pass less variables, to see if that changes anything. But it did use to work in version 12 of the patch, and I don't see anything in the changelog that might have impacted parameter passing (I think :) ).



#448 tschak909 OFFLINE  

tschak909

    River Patroller

  • 2,841 posts
  • Location:USA

Posted Sun Nov 4, 2018 5:21 PM

now if I can just convince a certain someone to look at the RS232 routines... ;)

 

-Thom






1 user(s) are browsing this forum

0 members, 1 guests, 0 anonymous users