Jump to content

Photo

GCC for the TI


447 replies to this topic

#401 tschak909 ONLINE  

tschak909

    River Patroller

  • 2,841 posts
  • Location:USA

Posted Fri Aug 10, 2018 3:07 PM

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



#402 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,845 posts
  • Location:Portland, Oregon USA

Posted Sat Aug 11, 2018 11:10 AM

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



#403 tschak909 ONLINE  

tschak909

    River Patroller

  • 2,841 posts
  • Location:USA

Posted Sat Aug 11, 2018 11:38 AM

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



#404 tschak909 ONLINE  

tschak909

    River Patroller

  • 2,841 posts
  • Location:USA

Posted Sat Aug 11, 2018 2:08 PM

I have grafted basic tipi support into PLATOTerm, code is here: http://github.com/ts...909/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



#405 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 788 posts
  • Location:The Great White North

Posted Sat Aug 11, 2018 3:25 PM

I have grafted basic tipi support into PLATOTerm, code is here: http://github.com/ts...909/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?



#406 tschak909 ONLINE  

tschak909

    River Patroller

  • 2,841 posts
  • Location:USA

Posted Sat Aug 11, 2018 3:43 PM

 
How big is the total binary?

8320 + 7680 at present.

Sent from my SM-G920F using Tapatalk

#407 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 788 posts
  • Location:The Great White North

Posted Sat Aug 11, 2018 8:47 PM

Ok so there is lots of room in the expansion memory card for that.



#408 tschak909 ONLINE  

tschak909

    River Patroller

  • 2,841 posts
  • Location:USA

Posted Sat Aug 11, 2018 8:54 PM

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



#409 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 788 posts
  • Location:The Great White North

Posted Sat Aug 11, 2018 9:49 PM

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.



#410 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 806 posts
  • Location:Belgium

Posted Fri Aug 17, 2018 3:23 AM

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.



#411 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 806 posts
  • Location:Belgium

Posted Sun Oct 21, 2018 6:05 AM

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:

Attached File  Screen Shot 2018-10-21 at 14.00.41.png   26.61KB   3 downloads

 

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 by TheMole, Sun Oct 21, 2018 10:30 AM.


#412 chue OFFLINE  

chue

    Moonsweeper

  • 291 posts

Posted Sun Oct 21, 2018 9:06 AM

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 by chue, Sun Oct 21, 2018 9:13 AM.


#413 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 806 posts
  • Location:Belgium

Posted Sun Oct 21, 2018 10:31 AM

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 by TheMole, Sun Oct 21, 2018 10:32 AM.


#414 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 788 posts
  • Location:The Great White North

Posted Sun Oct 21, 2018 5:05 PM

Modern C compilers are developing a reputation for having "nasal demons" due to the continuous efforts at optimization.

 

https://en.wikipedia...efined_behavior



#415 FarmerPotato OFFLINE  

FarmerPotato

    Chopper Commander

  • 143 posts
  • Location:Austin, TX

Posted Mon Oct 22, 2018 12:04 PM

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



#416 chue OFFLINE  

chue

    Moonsweeper

  • 291 posts

Posted Mon Oct 22, 2018 12:27 PM

cprintf("%c * %c = %c\n\n", ('0'+a), ('0'+b), ('0'+result));

 

Using chars like this results in this output

 

2, 3, 0



#417 FarmerPotato OFFLINE  

FarmerPotato

    Chopper Commander

  • 143 posts
  • Location:Austin, TX

Posted Tue Oct 23, 2018 12:31 PM

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?



#418 insomnia OFFLINE  

insomnia

    Star Raider

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

Posted Wed Oct 24, 2018 10:25 AM

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^8) * (B * 2^8) = (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...



#419 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,398 posts
  • Location:Germany

Posted Wed Oct 24, 2018 12:16 PM


Here's the math behind this:  Result = (A * 2^ 8) * (B * 2^ 8) = (A * B) * (2^16)

 

Has the world become any better after graphical smileys were invented?



#420 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,845 posts
  • Location:Portland, Oregon USA

Posted Wed Oct 24, 2018 12:19 PM

Is there any progress on:
Linker that can handle non contiguous ram
SAMS support


Sent from my LG-H872 using Tapatalk

#421 insomnia OFFLINE  

insomnia

    Star Raider

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

Posted Wed Oct 24, 2018 12:27 PM

 

Has the world become any better after graphical smileys were invented?

It has made math totally cool. :cool:



#422 OLD CS1 OFFLINE  

OLD CS1

    Technomancer

  • 5,701 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Wed Oct 24, 2018 12:33 PM

It has made math totally cool. :cool:

 

Totes.



#423 insomnia OFFLINE  

insomnia

    Star Raider

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

Posted Wed Oct 24, 2018 12:38 PM

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.



#424 --- Ω --- OFFLINE  

--- Ω ---

    HexaCoreRunner

  • 13,026 posts

Posted Wed Oct 24, 2018 1:13 PM

 

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!


  • RXB likes this

#425 insomnia OFFLINE  

insomnia

    Star Raider

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

Posted Thu Oct 25, 2018 8:32 PM

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






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users