Jump to content
IGNORED

GCC for the TI


insomnia

Recommended Posts

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

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 months later...

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:

post-33891-0-97583900-1540123275_thumb.png

 

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
  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

  • Like 7
Link to comment
Share on other sites

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.

  • Like 4
Link to comment
Share on other sites

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

  • Like 6
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...