ticalc.org
Basics Archives Community Services Programming
Hardware Help About Search Your Account
   Home :: Archives :: News :: Feature: 68K Programming Guidelines

Feature: 68K Programming Guidelines
Posted by Nick on 26 April 2000, 01:42 GMT

François Revol, a French programmer, brings up some interesting points in our next feature, talking about establishing guidelines for coding in 68000 assembly.


Ti68k open programming guidelines

With the increasing number of z80 based TI calcs, we have come to an incredible list of shells, at least 3 for every model, each having it's own 'API'. Of course, some of them were designed to be compatible with others like CrASH for Ash... But it's far from ideal.

Of course, on the 68k scene, there are only 3 models (but how many ROM versions ? How many Hardwares ?) but it might change in the future... And don't count on TI engineers to help you to stay compatible...

One project that will help us (IMO) is [tie], which would allow to fill the gap between the Ti92 and the 92+/89 models... I think the most important function needed is heaplock, which must be in the ROM, but we need to locate it.

Another project that I think is the best thing that happened to the Ti68k world since Fargo is Prosit. Multitasking on the is a great and fun thing. And it's only the beginning.
The main reason Prosit isn't so popular is the fact it doesn't allow DoorsOs programs (games particularly) to be loaded (and so multitasked). The problem is DoorsOs progs, DoorsOs itself and TI'ROM aren't designed for that. The keyboard is the perfect example: every program reads the keyboard port directly.

The best design would be to isolate all hardware access in libraries (and even the ROM calls like file access, ...) so that, by changing a library, manually or even within an exec() function, we could run a program both under plain DoorsOs and Prosit, and [tie]. (Another great thing would be porting Prosit to [tie] when it gets enough stable...).

Another problem is the link: There is the standard cable, the IR-Link, the HF-Link... Wouldn't it be good if the progs could access any of these devices without any change ? The neat thing would be a networking protocol which should drive indifferently a 2 calcs cable, an IR net, or an I2C wired calc net. It is on my project list.

An important point is the language: since we are now able to use C or Pascal instead of ASM, it is possible that a library written in ASM will be used by a C program, or be replaced by a new version written in C. So it is important to always follow the C calling convention (even TI engineers do it !) for library calls at least.

Another step will be writing a C standard library, which would allow porting nice programs from the UNIX world... It is also on my project list ;-)

All these stuff would allow both DoorsOs/[tie] and Prosit to run a program.
An example would be a program which uses grayscales. Under DoorsOs it uses the standard gray4lib. Under Prosit it calls a special gray4lib which tells Prosit to allocate a virtual screen and disable the GUI untill a hotkey swaps to an other screen...

Modular programming is sometimes harder to get used to, but I think it is worth to. Something I use in my progs is to include a file named "config.h", common to all progs, in which a CONFIG.BAT writes the target (92/92+/89), the language (English, French,...), and I have a structure MAKE.BAT tree to help build the progs (Have a look at prosit_apps.zip, there is also a nice Othello game for Prosit in bonus).

Last thing: don't assume your programs will be compiled under DOS/Winblows! I had so many problems with DOS specific stuff under Linux... I still don't understand why so much people bother using DOS/Zin, as Linux is so great... :-((

My ultimate goal is to be able to surf the net on a TI (I mean not using any trick like Telnet83, but a real TCP/IP stack and stuff). What about you folks, do you think it is possible ?

I suggest the following to be discussed as a "Ti68k Open Programming guidelines" Request For Comment (RFC ;-))

  • Be as modular as possible
  • Try to comment the source code (I know it's hard to do)
  • Always use the C calling convention
  • Isolate I/O in libraries
  • Try to think of possible 'wrappers' on ti92 for something that doesn't exist.
  • Think about both 92 and 89 screen/keyboard


Well, what do you people think?
Talk amongst yourselves :-)

 


The comments below are written by ticalc.org visitors. Their views are not necessarily those of ticalc.org, and ticalc.org takes no responsibility for their content.


Re: Feature: 68K Programming Guidelines
Sebastian Reichelt  Account Info

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!

     26 April 2000, 06:13 GMT


Re: Re: Feature: 68K Programming Guidelines
nerdguy  Account Info
(Web Page)

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

     26 April 2000, 07:17 GMT

Re: Re: Re: Feature: 68K Programming Guidelines
Free_Bird Account Info
(Web Page)

Umm, what's your point actually?

     26 April 2000, 15:55 GMT

Re: Re: Re: Feature: 68K Programming Guidelines
ExTmoo  Account Info

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

     28 April 2000, 17:38 GMT


Re: Re: Re: Feature: 68K Programming Guidelines
Reno  Account Info

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

     28 April 2000, 22:03 GMT

Re: Feature: 68K Programming Guidelines
Samir Ribic  Account Info
(Web Page)

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.

     26 April 2000, 09:07 GMT

Re: Re: Feature: 68K Programming Guidelines
kyle2003  Account Info

Hey, pretty neat.

     26 April 2000, 13:46 GMT

Re: Re: Feature: 68K Programming Guidelines
Free_Bird Account Info
(Web Page)

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

     26 April 2000, 15:57 GMT

Re: Re: Feature: 68K Programming Guidelines
Kenneth Arnold Account Info

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

     26 April 2000, 22:24 GMT

Re: Re: Feature: 68K Programming Guidelines
ZenZagg  Account Info

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

     27 April 2000, 01:46 GMT


Re: Re: Feature: 68K Programming Guidelines
Mayo Jordanov  Account Info
(Web Page)

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

     27 April 2000, 04:14 GMT

Re: Feature: 68K Programming Guidelines
Free_Bird Account Info
(Web Page)

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

     26 April 2000, 15:58 GMT

Re: Re: Feature: 68K Programming Guidelines
GordonChil  Account Info

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

     27 April 2000, 08:03 GMT


Re: Re: Feature: 68K Programming Guidelines
Zeljko Juric  Account Info
(Web Page)

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

     27 April 2000, 08:51 GMT


Re: Re: Re: Feature: 68K Programming Guidelines
Scott Dial
(Web Page)

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.

     27 April 2000, 11:10 GMT

Re: Re: Re: Re: Feature: 68K Programming Guidelines
David Phillips  Account Info
(Web Page)

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.

     28 April 2000, 03:28 GMT

Re: Re: Re: Re: Feature: 68K Programming Guidelines
Zeljko Juric  Account Info
(Web Page)

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

     28 April 2000, 10:00 GMT


Re: Re: Re: Re: Feature: 68K Programming Guidelines
Patrick Davidson  Account Info
(Web Page)

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

     30 April 2000, 01:07 GMT

Re: Feature: 68K Programming Guidelines
BeautifulGeorge  Account Info

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.

     26 April 2000, 19:26 GMT

Re: Feature: 68K Programming Guidelines
William Tipton  Account Info

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

     26 April 2000, 22:40 GMT

Re: Feature: 68K Programming Guidelines
mysteryegg  Account Info
(Web Page)

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)

     27 April 2000, 00:10 GMT

1  2  3  4  

You can change the number of comments per page in Account Preferences.

  Copyright © 1996-2012, the ticalc.org project. All rights reserved. | Contact Us | Disclaimer