Tursi Posted October 26, 2018 Share Posted October 26, 2018 Thanks for continuing to patch! It has really extended my interest in coding for the TI over the years. 3 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 26, 2018 Share Posted October 26, 2018 Yes. Between this version of GCC, and Tursi's libti99, I've been able to port PLATOTerm to the TI 99/4A -Thom 4 Quote Link to comment Share on other sites More sharing options...
+9640News Posted October 26, 2018 Share Posted October 26, 2018 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 26, 2018 Share Posted October 26, 2018 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 Quote Link to comment Share on other sites More sharing options...
PeteE Posted October 26, 2018 Share Posted October 26, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
mindlord Posted October 29, 2018 Share Posted October 29, 2018 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. Quote Link to comment Share on other sites More sharing options...
+chue Posted October 29, 2018 Share Posted October 29, 2018 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. Quote Link to comment Share on other sites More sharing options...
TheMole Posted October 30, 2018 Share Posted October 30, 2018 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: 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. 1 Quote Link to comment Share on other sites More sharing options...
insomnia Posted October 31, 2018 Author Share Posted October 31, 2018 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. 5 Quote Link to comment Share on other sites More sharing options...
mindlord Posted October 31, 2018 Share Posted October 31, 2018 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 Quote Link to comment Share on other sites More sharing options...
TheMole Posted October 31, 2018 Share Posted October 31, 2018 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. Quote Link to comment Share on other sites More sharing options...
insomnia Posted November 1, 2018 Author Share Posted November 1, 2018 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. 5 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted November 1, 2018 Share Posted November 1, 2018 @insomnia - You're hacking on a compiler, it's all edge cases from here down... -Thom 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted November 1, 2018 Share Posted November 1, 2018 How do you install a patch? Quote Link to comment Share on other sites More sharing options...
TheMole Posted November 1, 2018 Share Posted November 1, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
TheMole Posted November 1, 2018 Share Posted November 1, 2018 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 . Quote Link to comment Share on other sites More sharing options...
mr_gw454 Posted November 1, 2018 Share Posted November 1, 2018 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 directoryMakefile:10623: recipe for target 'install-target-libstdc++-v3' failedmake[1]: *** [install-target-libstdc++-v3] Error 1make[1]: Leaving directory '/home/mrg/source/TI/build/gcc-4.4.0/build'Makefile:2475: recipe for target 'install' failedmake: *** [install] Error 2=== Installation complete === Is the libstdc++-v3 library not built as part of this script? Thanks for any help anyone can provide! 1 Quote Link to comment Share on other sites More sharing options...
+chue Posted November 1, 2018 Share Posted November 1, 2018 /bin/bash: line 3: cd: tms9900/libstdc++-v3: No such file or directory See if my post here helps: http://atariage.com/forums/topic/164295-gcc-for-the-ti/?p=3885112 Quote Link to comment Share on other sites More sharing options...
mr_gw454 Posted November 1, 2018 Share Posted November 1, 2018 See if my post here helps: http://atariage.com/forums/topic/164295-gcc-for-the-ti/?p=3885112 That helped -- thank you very much! Quote Link to comment Share on other sites More sharing options...
TheMole Posted November 2, 2018 Share Posted November 2, 2018 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 >> - scroll_x, (player.ypos >> , 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 >> - scroll_x, (player.ypos >> , 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 >> - scroll_x) should evaluate to at the start of a level), like so: put_alex(action, 16, (player.ypos >> , 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... 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 3, 2018 Share Posted November 3, 2018 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 Quote Link to comment Share on other sites More sharing options...
TheMole Posted November 4, 2018 Share Posted November 4, 2018 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 ). Quote Link to comment Share on other sites More sharing options...
tschak909 Posted November 4, 2018 Share Posted November 4, 2018 now if I can just convince a certain someone to look at the RS232 routines... -Thom 1 Quote Link to comment Share on other sites More sharing options...
Fabrizio Caruso Posted December 4, 2018 Share Posted December 4, 2018 Hi, Where are the latest installation instructions in this thread? Is it now compatible with cygwin 64-bit? Fabrizio 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted January 14, 2019 Share Posted January 14, 2019 Ok, this compiler fork has got some bugs. This is infuriating. Tursi was able to track down the issue with rs232_getbyte and rs232_setbyte, however, still being bitten in the arse with char and int idiosyncracies, and I need to find a way around them. Case and point, I have a routine in my protocol decoder, called Key, which does the following: given a Key: (a) If the key is less than 0x80, it's a keyboard key, ripple through the translate table, and send its appropriate one byte keycode. (b) If the key is larger than 0x80, it is a special output sequence (such as an echo packet, or a touch event), escape it and send it out as a three byte key sequence (a) has an additional constraint that handles access keys (e.g. international keys) Its code is the following: /*----------------------------------------------* * Key * * * * Send a 10-bit internal key. If a keyset * * key, translate, else send as escaped * * sequence. * *----------------------------------------------*/ void Key (padWord theKey) { if (theKey >> 7!=0) { io_send_byte (0x1b); io_send_byte (0x40 | (theKey & 0x3f)); io_send_byte (0x60 | ((theKey >> 6) & 0x0f)); } else { if (FlowControl == 0) theKey = PTAT0[theKey]; else theKey = PTAT1[theKey]; if ((theKey & 0x80)!=1) { io_send_byte (0x1b); io_send_byte (theKey & 0x7f); } else io_send_byte (theKey); } } Which gets translated to the following: Key ai r10, >FFFA mov r10, r0 mov r11, *r0+ mov r9, *r0+ mov r13, *r0+ mov r1, r9 sla r1, >7 abs r1 jne L86 mov @FlowControl, @FlowControl jeq L87 movb @PTAT1(r9), r9 srl r9, 8 li r1, >1B bl @io_send_byte mov r9, r1 andi r1, >7F mov *r10+, r11 mov *r10+, r9 mov *r10+, r13 b @io_send_byte L87 movb @PTAT0(r9), r9 srl r9, 8 li r1, >1B bl @io_send_byte mov r9, r1 andi r1, >7F mov *r10+, r11 mov *r10+, r9 mov *r10+, r13 b @io_send_byte L86 li r13, io_send_byte li r1, >1B bl *r13 mov r9, r1 andi r1, >3F ori r1, >40 bl *r13 mov r9, r1 sla r1, >6 andi r1, >F ori r1, >60 mov *r10+, r11 mov *r10+, r9 mov *r10+, r13 b @io_send_byte .size Key, .-Key even What the hell is going on, and why are values that are below 0x80 (e.g. 0x41 for A), sending a three byte sequence? This code works in nine other compilers, three of them GCC variants. It even works in Small C on Z80. I am beyond aggravated. -Thom Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.