tschak909 Posted August 10, 2018 Share Posted August 10, 2018 Can somebody run the TST program on this disk, on a real TI and press the following keys, and report the following scancodes? https://drive.google.com/open?id=1SWZKRz7vVUr91FXSibrCuuK6Wem-PZ7i A B C D E F G H CTRL-A CTRL-B CTRL-C CTRL-D CTRL-E CTRL-F CTRL-G CTRL-H FCTN-A FCTN-B FCTN-C FCTN-D FCTN-E FCTN-F I am seeing values back from my test harness on Classic99 that don't match up to the documentation I am seeing (ctrl keys seem to have bit 8 set.) Also, is it possible by utilizing kscan or manually scanning the keyboard to get e.g. a shift-CTRL-<key> combination? -Thom 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted August 11, 2018 Share Posted August 11, 2018 Ok running it. i get the screen, what is supposed to happen when I hit a key? just seems to sit there nevermind i got the test program up assume its 0xXX and I'm listing the XX A 41 B 42 C 43 D 44 E 45 F 46 G 47 H 48 CTRL-A 81 CTRL-B 82 CTRL-C 83 CTRL-D 84 CTRL-E 85 CTRL-F 86 CTRL-G 87 CTRL-H 88 FCTN-A 7c FCTN-B be FCTN-C 60 FCTN-D 9 FCTN-E b FCTN-F 7b Greg Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 11, 2018 Share Posted August 11, 2018 ok, so that matches up. looks like libti99/tms9900-gcc does its own little munging of the CTRL and FCTN keys, but it's consistent, so good. Thanks! I've got a preliminary key mapping in PLATOTerm now, I just need to get some serial stuff working.. -Thom 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 11, 2018 Share Posted August 11, 2018 I have grafted basic tipi support into PLATOTerm, code is here: http://github.com/tschak909/platoterm99 But, now it seems I may be running into memory collisions, because the program is crashing unstably, regardless of whether the I/O routines are called, or not. can somebody look and see what I may be doing wrong? -Thom 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted August 11, 2018 Share Posted August 11, 2018 I have grafted basic tipi support into PLATOTerm, code is here: http://github.com/tschak909/platoterm99 But, now it seems I may be running into memory collisions, because the program is crashing unstably, regardless of whether the I/O routines are called, or not. can somebody look and see what I may be doing wrong? -Thom How big is the total binary? Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 11, 2018 Share Posted August 11, 2018 How big is the total binary? 8320 + 7680 at present. Sent from my SM-G920F using Tapatalk Quote Link to comment Share on other sites More sharing options...
+TheBF Posted August 12, 2018 Share Posted August 12, 2018 Ok so there is lots of room in the expansion memory card for that. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 12, 2018 Share Posted August 12, 2018 Yeah, that's what I thought, current linker config plops the TEXT segment at $A000, which puts it square at the start of expansion himem, while DATA gets pointed to $2000, which expansion lomem... I'm at a loss... -Thom Quote Link to comment Share on other sites More sharing options...
+TheBF Posted August 12, 2018 Share Posted August 12, 2018 Good thing you are using a "portable" language. It's never as simple as language designers would have us believe. 9900 is pretty fussy about word alignment. Since your code was written for 8-bitters before, is there any possibility that some code is not falling in aligned addresses? Pure speculation here. Quote Link to comment Share on other sites More sharing options...
TheMole Posted August 17, 2018 Share Posted August 17, 2018 I have no idea how this is possible, but the compiler creates different code under macos and under ubuntu for me. It's a bit frustrating, but after the last update last year (v16) I haven't been able to compile my game to a working state anymore. Version 12 is the most "stable" version for that specific project. Quote Link to comment Share on other sites More sharing options...
TheMole Posted October 21, 2018 Share Posted October 21, 2018 (edited) Okay, I'm trying to identify where stuff is going wrong for me by putting together as-short-as-possible test programs for pieces of code that don't give the results I would expect. So I've built a program which runs a number of basic math operations (addition, subtraction, multiplication, division and modulo) on each of the 6 number types (char, int and long in their signed and unsigned variations). I use a list of pre-defined input values for these operations, and have run the same tests on a PC where I've stored the results in a binary file which I then compare to the results I get on the TI. I got strange results even for basic operations (unsigned char multiplications), so I wanted to test them without the whole test harness. When running this simple code (using Tursi's excellent conio from libti99): volatile uint8 a = 2; volatile uint8 b = 3; volatile uint8 result = a * b; cprintf("%d * %d = %d\n\n", a, b, result); I get this result: I'm declaring the variables volatile to stop the compiler from optimizing the operation away (if I remove the volatile keyword, it does give the desired result, but the dissassembly shows it's just doing the multiplication at compile time...). The value in memory is indeed zero, so it's not a bug in the cprintf routine. It's also worth pointing out that I don't declare my variables volatile in the regular test program where the inputs are read from a binary file stored in the cartridge. Could someone else try this to verify they get the same results? Edited October 21, 2018 by TheMole 1 Quote Link to comment Share on other sites More sharing options...
+chue Posted October 21, 2018 Share Posted October 21, 2018 (edited) I can confirm that I get the same results as TheMole. 2 * 3 == 0 when using volatile variables. Edit: My GCC info tms9900-gcc (GCC) 4.4.0 20090421 (TMS9900 patch 1.16) Edited October 21, 2018 by chue Quote Link to comment Share on other sites More sharing options...
TheMole Posted October 21, 2018 Share Posted October 21, 2018 (edited) Well, al least it's not just me then . I should also point out that using ints instead of chars does yield the correct result, even with volatile variables. Edited October 21, 2018 by TheMole 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 21, 2018 Share Posted October 21, 2018 Modern C compilers are developing a reputation for having "nasal demons" due to the continuous efforts at optimization. https://en.wikipedia.org/wiki/Undefined_behavior Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 22, 2018 Share Posted October 22, 2018 Well, al least it's not just me then . I should also point out that using ints instead of chars does yield the correct result, even with volatile variables. I wonder if the uint8 is not promoted to int before being placed on the stack? Try cprintf("%c * %c = %c\n\n", ('0'+a), ('0'+b), ('0'+result)); Quote Link to comment Share on other sites More sharing options...
+chue Posted October 22, 2018 Share Posted October 22, 2018 cprintf("%c * %c = %c\n\n", ('0'+a), ('0'+b), ('0'+result)); Using chars like this results in this output 2, 3, 0 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 23, 2018 Share Posted October 23, 2018 Well, al least it's not just me then . I should also point out that using ints instead of chars does yield the correct result, even with volatile variables. It looks like the uint8 are not being promoted to int before multiplication, as they should, or conversion back to uint8 is not correct. Can you find the assembly source for this case? Quote Link to comment Share on other sites More sharing options...
insomnia Posted October 24, 2018 Author Share Posted October 24, 2018 I'm currently working on a fix for this. The problem is that char values stored in registers occupy the upper byte, When multiplying two register-stored values, the result is in the upper word of the 32-bit result. When multiplying memory-stored values, the char-to-int promotion occurs as expected, and the result is in the lower word of the 32-bit result. For extra fun, when multiplying register-stored and memory-stored values the result is stored in the middle two bytes of the 32-bit result. It's difficult to control how values are stored, so currently char multiplication can give unexpected results (as has been shown already). I'm working on a fix to force all char multiplications to be first converted to register-storage format, and to extract the correct portion of the result. Here's the math behind this: Result = (A * 2^ * (B * 2^ = (A * B) * (2^16) Before the operation completes, the resulting value needs to be converted to register-storage format, with the value stored in the upper byte of the result register. Here's an example of what I'm trying to achieve: mpy r1, r2 * Value A stored in register R1, value B in R2, result in [r2,r3] * The resulting char value is stored in the low byte of R2 swpb r2 * Move result to high byte of R2 to convert to register-stored format The problem I'm having is that I can't get the compiler to recognize that the the low word of the 32-bit result is clobbered by the multiply. This means that any value stored in R3 in the example above will be destroyed by the multiplication, but the compiler will assume it's still valid. That error value will propagate through the code and have unpredictable results. I can't just promote all char values to int values either, The value we want will then be stored in the low byte of the 32-bit result, and we would still need to convert to register-stored format. Bear with me, a fix should be coming soon... 7 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 24, 2018 Share Posted October 24, 2018 Here's the math behind this: Result = (A * 2^ * (B * 2^ = (A * B) * (2^16) Has the world become any better after graphical smileys were invented? 2 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted October 24, 2018 Share Posted October 24, 2018 Is there any progress on: Linker that can handle non contiguous ram SAMS support Sent from my LG-H872 using Tapatalk Quote Link to comment Share on other sites More sharing options...
insomnia Posted October 24, 2018 Author Share Posted October 24, 2018 Has the world become any better after graphical smileys were invented? It has made math totally cool. 1 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted October 24, 2018 Share Posted October 24, 2018 It has made math totally cool. Totes. Quote Link to comment Share on other sites More sharing options...
insomnia Posted October 24, 2018 Author Share Posted October 24, 2018 Is there any progress on: Linker that can handle non contiguous ram SAMS support The linker can already handle non-contiguous memory. The problem is that the program loader needs to copy that code from its storage location to the active location. The crt0 code in the example programs can handle this for basic cartridges and EA5 files, but more complex designs need to have additional code written. Unfortunately, the compiler will never natively support SAMS, We really don't want that anyway. SAMS support is something that needs to be in something like an OS layer. We would never be able to make the compiler smart enough to handle all the use cases, and we don't want to have two compilation outputs (one for a system with a SAMS card, one without). I'm slowly working on a replacement OS for the TI which automatically handles SAMS usage. It isn't ready yet, and might not be useful for your project anyway. 4 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted October 24, 2018 Share Posted October 24, 2018 I'm slowly working on a replacement OS for the TI which automatically handles SAMS usage. It isn't ready yet, and might not be useful for your project anyway. You have my full and undivided attention sir... and THAT does not happen very often! Do tell! 1 Quote Link to comment Share on other sites More sharing options...
insomnia Posted October 26, 2018 Author Share Posted October 26, 2018 OK, it's patch time! The first post has been edited to include the new patches and an updated GCC installer. The compiler is fairly mature at this point, so there's not many changes here: More strict checks for address in BL commands Optimization for 32-bit left shift by 8 bits Optimization for 32-bit logical right shift by 8 bits Fixed 32-bit right shift by more than 16 bits Fixed 8-bit multiplies The big news here is fixing 8-bit multiplies. This was first seen by TheMole, so thank you for the find. There's also some edge cases that got worked on in 32-bit shifts. These are nothing major, and were not likely to have been seen by too many people. I found these problems and the BL addressing mode bug while working on my OS project. I don't want to derail this thread, so look here for details on that: http://atariage.com/forums/topic/282474-linux-like-os-for-the-ti Anyway, thanks to everyone for continuing to find bugs. I love to swat 'em so don't hold back if you find one. PS: My blog is majorly out of date, I should do something about that... 6 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.