Ti68k open programming guidelines

I know this may sound strange:

In my opinion, the place to start everything we are looking for is right here. For example, we should, first of all, make up a standard language. I personally like Pascal best, and write all my great Windows programs in Delphi, but TI-GCC is just great and fast. I also wrote a Windows IDE for it, but the ticalc.org people were too lazy to post it yet (I did upload it three days ago).

The second thing is Prosit. Certainly a great system, but with some flaws. Here is what might solve everything: You could write a very high-level, object-oriented language, which you don't have to type, but program visually just by clicking with your mouse on identifiers (in Windows/Linux/MacOS). Then you could interpret it at runtime. Since it is not text, but all relative addresses, it should run fast enough for GUI applications, as long as all routines perform operations that are complex enough and cover up a wide enough range that the time required to call them doesn't really matter (like Windows COM). Such programs wouldn't be real programs, but for example strings. Real programs could be run in single-process mode like from a shell.

Of course this sounds like a lot, but I know it's possible. One thing about ticalc.org is that everyone helps contribute to the whole archive, and I imagine that a lot of people would help on this if it gets started. The amount of good programming that is done on this "market" is just great, and it's all more or less done by students like me!

Size, Size, Size!!!!!!!!!!!!!!!!!!!!
We only have ~300k in RAM, and ~500k in archive

Umm, what's your point actually?

lol - you're certainly fired up over.. something.. :-)

I thought it was 188k RAM and 720k archive....

TCP/IP under TI89? YES, it is possible. I ported TinyTCP to TI89 using TIGCC compiler. Currently it is 7200 bytes long, but contains all required layers
SLIP, IP, TCP and FTP. At this moment it downloads via FTP file from fixed IP address, but I think that I can finish full FTP, SMTP, POP3 and HTTP clients remaining in 8K limit (breaking this limit under AMS2.03, HW2 is so ugly hack that will not work in next version of AMS). Do not expect "bells and whistles" user interface with such a small RAM. This means to download file via FTP you should type:

user anonymous
pass billgates@linux.org
cwd /pub/ticalc
type i
retr manual.txt
quit

And if you want to read your mail to type

user billgates
pass dollar
list
retr 1
retr 2
quit

To send mail

mailto <balmer@microsoft.com>
replyto <billgates@linux.org>
Hi Balmer, I am so happy after I
leaved Micro$oft and moved to Open
Source world.
.
quit



As I used other's source licensed under GPL, the source will be published.

At this moment I test it using program NOS, radio amateur program for TCP/IP under MS DOS. I still did not test with modem and real provider. As Graphlink has no flow control (CTS/DTR lines) collisions occur, but TCP/IP from time to time does retransmissions.

I would like to test the program under Linux. I have RedHat 5.2, but I can not establish SLIP withot flow control. slattach can not work under Redhat, while DIP always reestablish hardware flow control.

I do not plan to implement Telnet, due to small screen. If I implement HTTP, it will be also rudimentar, you will see text on screen scrolling.

Hey, pretty neat.

This sounds like it's going to rock...

Hmmm... which link do you have?

As for an FTP client, just recompile one of the GPL'ed Linux ones. A few things would need to change (like saving files, I/O, and Unix system calls), but the FTP handling code and everything is already there.

Of course when Linux is ported to the TI-89/92, we won't have these problems. And I think that it definately is possible. Any experienced C / ASM programmers please listen up -- together we can get this done! (start with uClinux -- uclinux.org)

Kenneth

I would really like to be able to connect to a chat network or online bbs with my 89, hope u get the ISP support worked out

I'm not sure if you guys are assuming you will have to run the calcs using dialup modems, since the minimum number of cables to connect to ethernet is 4 (as far as i know == TR+, TR-, RC+, RC-) and the calc has only two possible output contacts.
Anyways, if i'm wrong, please let me know :))

Mayo

Well, of course TI uses C calling conventions! The ROMs were written in C!

Well, that's the most inexpensive way to go. If they were to code in assembly then they'd have to teach all the programmers to code in assembly and how would you like to debug that thing. Oh my. :)~ C has it's limitations but come to think of it, it's pretty darn(I'm from UT) good. :)

And, as I can see, they used a C compiler which is not a very good optimizer. When I looked the ROM code, there are a lot of places which are poorly coded. In my opinion, TI-GCC produces better code than a compiler used by TI...

GCC is definantly does not generate the most optimized code... It can't even decide to use a bsr instead of a jsr. That's just a simple little mistake, think how many larger more wasteful ones there are probably.

The GNU C compilers are nice, but I don't think any compiler for x86 has come close to the performance of Watcom's compilers. I've used Watcom C/C++ 10.6 for the last four years (version 11 was the final release, but they discontinued it and I can't find a copy :( and it's simple the best compiler I've ever seen. They did an excellent job, and made programming for DOS32 a great experience. Too bad there aren't any compilers of that quality (or are there?) for 68k.

You are absolutely right, but the compiler used by TI generates much worse code.

Actually, that sort of thing is the exception, not the rule, for GCC's output. The reason being that it doesn't think about where a function is when generating a call to it, something which it often doesn't even know.

That aside, that jsr will be made into a PC-relative JSR when assembled if the other function is in the same file. A PC-relative JSR takes the same amount of time as a BSR, and is the same size as a bsr.w (though it is 2 bytes more than a bsr.s). So really all that loses is 2 bytes of space, and no execution time.

Within a function, it does usually generate very good code. Try looking at the code it generates for fairly complex functions before deciding whether it's any good. While not always the best possible code, it's usually close to it.

As a small example, I've attached some code below for people to look at. This code is actually a portion of a quicksort routine. What it does is searches an array of ints right-to-left for the first item less than or equal to a given value, and returns the pointer to it. Also it returns the low bound of the array if nothing is found.

Here's the C code:

static int *find_lower(int pivot, int *low, int *j)
{
do {
j--;
} while ((*j > pivot) && (j > low));
return j;
}

And here is the output from "tigcc -S -O2 -fomit-frame-pointer test3.c"

.file "test3.c"
gcc2_compiled.:
__gnu_compiled_c:
.text
.even
find_lower:
move.w 4(%sp),%d1
move.l 6(%sp),%d0
move.l 10(%sp),%a0
jbra .L2
.even
.L7:
cmp.l %a0,%d0
jbcc .L3
.L2:
cmp.w -(%a0),%d1
jblt .L7
.L3:
rts
nop

Notice that the main loop of this contains four lines of code, and GCC is smart enough to use pre-decrement addressing. I don't really think you can get much (if any) better than this. (Well, you could speed it up by storing pivot at *low, and then restoring the low from a temporary variable at the end. But, that would be changing the design, not the code generation).

This is only a small example, and for the entire quicksort routine I wrote, some parts weren't quite as good as this. However, the above should show quite clearly that TI-GCC can generate good code. And as for some of the other problems: the latest versions of GCC do have a new optimization in them which should speed other things up; hopefully a new TI-GCC based on them will be available soon...

i think the best way to make the 89 and 92+ compatible would be to use a library to control the key and screensize. that way you would only need different libraries, not ports of the programs themselves.

standards:
first someone needs to make them
people will disagree on what they should be so the people involved in making these standards should be well known in the community (i.e. Joe W etc..)
everyone in the community will have to hear of them in order to implement them into their programs
ticalc.org could help w/ this probably

and linux..
why dont more people use it
probably because they dont know how
90% of computer users dont even start to have a clue how their comp works
if their comp came
they wouldnt use windows either if it didnt come preinstalled
the first time i tried to install linux.. i chalked it off for too hard.. kinda like the first time i tried assembly
then i read alot and got it installed
then i read alot more and got X workin..
next i have to get my internet workin..
i dont use linux alot now because i cant get online and most of the games i have are for windows.. so i use it for development or when i need some actually control over my machine
o well..
later

Do 89 users really need to worry that much about size? Well, yes, if half of your programs don't run when archived (not to mention libraries... yes I know some kernals have attempted to solve the problem). The whole purpose of libraries was to save space, but it does seem that many of the newer programs are using their own libraries shared by no other program. Rather odd to me... then there are always those stand-alone ASM progs that don't require kernals/shells...
While it would be great to unify all the programming techniques, it seems that programmers like experimenting with their own ideas right now, which is especially true with the new progs out for the 89. I'm just thankful that I've managed to avoid crashes for the last few ones... hooray for AMS 2.0x recalling archived memory...

In any case... as for the internet connection... it could work. While we're at it, couldn't we implement java to make the calcs compatible with telling machines around the world? (just kidding)... of course, the browser wouldn't take up the space of say netscape or IE, but would probably mimic Opera or some other small browser (I just worry once people want customizable skins like NeoPlanet... NO hotjava)... cell phones check email...

Oh... another thing... could this collaboration end up making TI calculators competitors of handheld organizors? just a thought... (now here's an idea... connect a digital eye to the link port, and you can turn your calc into a Newton! okay... maybe not)