NOTE: THIS POST IS OUTDATED. PLEASE SEE THIS LINK FOR COMPILER INSTALLATION

So, yesterday DrDnar mentioned getting a C compiler up and running for the new CE edition, so that's what I went and did. Now, there are quite a few things to keep in mind when getting things up and running, but I will go through them all in order to make your life a little easier. Of course; this still means that routines need to be written in assembly or C in order to do graphics or anything useful, which will probably be part of my next project. So, here are the steps you need to set up a C IDE for the TI84+CE.

First, grab the Zilog Developer Studio II, available here: (It is free, although you do have to register and things; they send you a link to download once you do that.)
http://store.zilog.com/index.php?option=com_ixxocart&Itemid=1&p=product&id=29&parent=5

Now, once you have everything installed in the directory of your liking, run ZDS2Ide.exe (for me it is in C:\Program Files (x86)\ZiLOG\ZDSII_eZ80Acclaim!_5.2.0\bin) Or you can search for it if need be.

Here is a full-fledged tutorial for what I know now.

First, open the IDE and select "New Project..." from the [FILE] tab.


Next, configure it to these options:


Press [CONTINUE], and then deselect the Startup item.


After that, select development item 2 (It doesn't really matter)


Skip past setting the ROM and RAM address, and just press [FINISH].

There you go. Now; go to [FILE]->"New File..."


Save said file inside of your project folder


Now, change the compiling mode to "Release":

The next step is to click on [PROJECT]->"Add Files..." and add that file to the current project:


Now go to [PROJECT]->"Settings..." or press [ALT-7]. Under the Linker menu, in "Objects and Libraries", make it look like this:


Next, go to the "Output" submenu. Check to make sure that the path is what you want it to be: (Also disable IEEE mode)


Now, under the "Commands" submenu, Choose "All RAM", and select the "Additional Directives" Checkbox. Click on the "Edit..." button, and input the following: EDIT: Fixed some things, copy text below

Copyable Text:

Code:


Almost there! Now; under the "General" menu in the settings window,
just make sure it has the right output location:


Select "Clean" from the [BUILD] Tab:


And you are done! Now, to write actual programs, use this button and start of code:


Copyable text:

Code:

Of course; a crt0.o or something would be especially useful, as it would get rid of all those pragma's

Download the CE.h file here:
http://myimages.wdfiles.com/local--files/start/CE.h
If you press that button and everything works just dandy; then you are ready to begin programming in C. Good luck!

Now, the next step is to go into the Release directory and locate the .hex file that was created. This is in Intel Hex format, so I made a program that goes from Intel Hex to 8xp, exactly like the old convHex except I don't get paid for it. Simply drag and drop the hex file on here; or run it from the command line. It will then create the calculator program that you can send via TI-Connect and such. Here's what it looked liked when I dragged and dropped things:

ConvHex: http://myimages.wikidot.com/local--files/start/ConvHEX.exe


--After Drop--


NOTES:
The USE_OS_CRT define basically just tells the compiler whether or not to use the included C runtime library in the OS. Otherwise, it will append the routines to your program. Note that it will only include functions used, not the whole thing. Useful if you want fast RAM execution, or a smaller program size. Not all routines have been found as of yet though; but luckily there are quite a few to make a substantial difference.
I will make a better tutorial on how to really do things when I figure out everything myself.

Here's what the main C code looks like:

Code:

And thus; I hail this as the first CE community program written in C. Where shall we go next? I think something like the Arduino syntax could be very useful, or something along those lines.
Aslo, here's a list of the size of things:

Code:

Great work! I'd be interested to know if there's a documentable process you followed to set this up, because I had different ZDS and source paths and had to change those in your manually created linkcmd file to get the project to build. Copying a hello world project and manually editing the linkcmd file to create new project doesn't sound ideal.

So, now that this is underway, I have a couple questions:

How would you like File IO to work?
Any functions that should be required?
Sprite/graphics routines?
And any other functions/features?

Every other day Mateo you make me want to buy a CE more and more.

Now that I have front-paged this awesome achievement, I should actually answer your questions:
Probably access to AppVars? Actually, considering that Doors CSE sets up a virtual hierarchical file system, I'd really like if programs had access to it. That level of abstraction (ie, the ability to mkdir(), dir(), and so on) sounds like something that Doors CSE should provide, so I may be getting off-topic. It might be worth considering transferring lots of UserMem into a file when it's fopen()'d (a la opening an edit buffer the way the OS does) and then removing it on fclose().
I think looking at what we have available on the Prizm (see this useful routines page and this useful routines topic) might be a good place to start brainstorming.
Yes! But I'm not sure what.
I think the ability to pull in TI float support is a must.

In this post, I'll focus on suggestions I feel useful, known from the TI-68k/AMS platform. I'm not despising existing work for the TI-Z80 platform, it's just that I'm incompetent about it, and should therefore not attempt to talk about it, especially to people who are more knowledgeable about it than I am


IMO, there should be two complementary levels of file I/O, like in GCC4TI. See the pages linked from https://debrouxl.github.io/gcc4ti/hdrindex.html for more information:
* native VAT functions exposed by the OS, whatever they are, for efficiency reasons. In GCC4TI, they're in the vat.h header file, and are based on the native memory management functions from alloc.h;
* something relatively close to stdio.h C11 / POSIX routines, implemented from the native VAT functions, for portability reasons: https://debrouxl.github.io/gcc4ti/stdio.html .


* various C helpers for misc OS / hardware functionality, such as interrupt handling (GCC4TI intr.h), timer handling (GCC4TI intr.h for the hardware ports + system.h for the timer ROM_CALLs), memory management (alloc.h), keyboard scanning (kbd.h), screen mode setting (pretty much N/A on TI-68k, besides GrayAdjust in gray.h) setjmp/longjmp (setjmp.h), why not the peek/poke series (peekpoke.h) if it can be made to work in a non-GCC-compatible compiler;
* it is very important that headers defined by the C standard - the likes of stdint.h, inttypes.h, stdbool.h, stddef.h, stdlib.h, string.h, the trivial iso646.h though that is rarely used - be available, to ease porting to the TI-eZ80 platform. For porting Lua and p14p, I did some work in that area for GCC4TI.
* in the longer term, USB port communication - if exposed in a callable way by the boot code / OS, which was far from granted, last time I saw a discussion about that.

If the TI-eZ80 calculators had a monochrome screen, I'd suggest a grayscale routine, but...

You may import, adapt (the base ROM_CALLs aren't the same anyway...) and improve upon some of the open source code in GCC4TI. fwrite has been known to be suboptimal for over a decade, but efforts to improve it were stalled by someone on "it would probably make the program larger" grounds...


Obviously
Unclipped sprite routines, clipped sprite routines, line / rectangle / circle functions, etc. One set of routines per screen color depth. All such functions had better be written in ASM for both size and speed reasons, of course.
On the TI-68k/AMS platform, ExtGraph (TI-Chess Team production, nowadays https://github.com/debrouxl/ExtGraph ) has the widest API. However, few functions are not written in ASM, so you could look at it for API inspiration, but not much else.


I agree with Kerm's suggestion.

Awesome work, that should really help with native coding popularity on the platform

So, I tried, and I have issues making the whole thing work, though:
- Installed ZDS (on Wine, on OS X), works fine
- Open the project, works fine
- Tried to "Build all", didn't work, because some paths were hardcoded in the project file you gave (the one at the end, for the libraries, and they were even in DOS format thing with tildes for name greater than 8 chars).
So, I changed that manually in the project file to point to the location on my computer. After some tries, it built
- I got a .hex file, as expected.
- Getting an .8xp out of it with the convHex.exe program "worked", but the file it made was invalid, according to TI-Connect, so I couldn't transfer it.
- So, I copy/pasted the hex actual content into TI-Connect CE's program editor (with the Asm84CEPrgm token at the beginning)... but when run on a 84+CE, it doesn't crash or error, but enters an infinite loop.

What am I doing wrong ?

Just in case, here's what the hex file looks like :

Code:


PS: I was just trying the Hello World project, nothing else.

I think this changes my opinion about the lack of the serial I/O port.

Well, the hex is in Intel Hex format, so it needs to be converted first. As for the Hello World project, I just followed the steps above to create a new project, and then copied the code into the the new project, compiled, and converted, and it worked. The actual project file has trouble with relative linking, so that's one thing I'm going to try and explore more.

For everyone else: Sounds like a good plan! Probably going to begin with File structures and things, stuff like fopen() in order to get things rolling. I will post more here as I work on things, but there is a ton of stuff to comment on up there.

EDIT: And some more questions. Since the library of routines is going to be the same for most all programs, would it make sense to have the functions in an appvar or something already on-calc? Not all of them, of course, but useful ones that are used a lot. It would greatly reduce program size.

Also, as for graphics routines, how do you guys want to handle the palettized bpp modes? I was thinking that we should start with 8bpp as the standard, as routines will need to be modified and such for each different mode. 8bpp is a nice mode, in my humble opinion.

Do we know what they're using for the compiler? Is it just some in-house thing?


Just as an fyi, "palatalized" is a linguistics/phonology term, not a synonym for "palettized"

So like a shell kinda? Could that be integrated into DCE if it ever comes to the CE?

Haha, oops. Fixed that. Chrome likes to highlight it as incorrect, for some reason.


Basically, sort of like how DCS provides routines. Since these are going to have to be present anyway, it would make sense to have an archived version or something of them sitting already on the calc, so that way duplicates don't start using up all of the memory.

There are easier things to whip up in our lists than file support


That's the eternal question of duplicating stuff across programs (TI-68k/AMS and TI-(e)Z80 native standalone programs, sometimes called "_nostub" whereas most of them do have e.g. startup code) vs. using a common base of non-native code to save some space (TI-68k/AMS so-called "kernels" whose reputation was damaged by the unreliable ones, TI-Z80 so-called "shells")
The truth in the matter probably leans towards some common base indeed, especially given that shells are more popular on the TI-Z80 series than they are on the TI-68k/AMS series.

Because of my obvious bias, I'd like to hope that Doors C[SE] will be able to provide these routines to programs, so is there a way we can easily modularize things to allow the libraries to be provided by a static blob for now, and a shell later, once/if that's a possibility? I'm exerting as much diplomacy as I can to argue for why the community should have a freeware App key, and I hope it'll come to pass sooner or later, so I'd like to be optimistic and hope Doors C[SE] will be available in some form later or (ideally) sooner.

This looks promising! Now I can wish for a CE even more (and still decide over an HP Prime)!

Wait... C compiler.... CE Compiler!!!!!!! (pun of the day)

RAM-resident TI-Z80 ASM "shells" and TI-68k ASM "kernels" have been extremely popular options over the past 15+ years. FlashApp signing key would be nice, but is in no way mandatory - not to mention it's unlikely that we'll get it, despite efforts by Kerm, Adriweb and others.

Okay; so here are some of my thoughts and ideas:

There could be a library with CE function calls in an AppVar, or something along those lines.
When a C program starts; it copies the AppVar to the safRAM locations cmdPixelShadow->saveSScreen, thus providing 52290 bytes of available library space. ( Also, there is still 16800 bytes available, as is the whole of usermem, pretty much )
Version information could precede the library, as to prevent bad addressing.
This would allow for:

Functions to be located in archive, so if a memory reset occurred, the library wouldn't be deleted.
Executing functions would reside in RAM, so that way they wouldn't be weighed down by flash wait states.
Also, dynamic lookup of functions wouldn't have to happen, which could speed things up.
Since it is a fixed RAM address, this means there will be a reduced possibility of having insufficient memory.

Thoughts/Ideas? Thanks!

<put TI-68k old-timer (graybeard) hat to speak of doomsday>
Beware of fixed addresses in a flat addressing space platform, kids !
</put TI-68k old-timer (graybeard) hat to speak of doomsday>


I'm aware that fixed addresses have worked well on the TI-Z80 series for 15+ years. In the TI-68k scene, whose 68000 provides the great flat addressing space feature, addresses were fixed on the 92 non-Plus, and on the early 92+ and 89 OS releases... until they became variable with each and every new OS release. As a result, programs using fixed addresses started wrecking havoc, destroying internal system variables...
Equally obviously, the authors of a number of buggy programs were gone, and the community didn't do a good job of updating download sites with big fat red warnings, or spending time making fixed versions of the programs (all the more some of those programs were closed-source).
End result: buggy programs plaguing users for years. This is precisely what I was referring to above by 'so-called "kernels" whose reputation was damaged by the unreliable ones' (or "kernel"-based programs doing crap, I should have added).

The TI-eZ80 series obviously remains closer to the TI-Z80 series than to the TI-68k series, but TI nevertheless imported several key items from the TI-68k series: flat addressing space, binary format for OS upgrades and FlashApps. Address instability next ?


Technical solutions for avoiding (well, as much as possible) fixed addresses in the library clients include, and are not limited to:
* embedding the target locations of the safeRAM inside the library itself (after the magic+version number), so that the client code knows where to copy;
* storing the library entry point's address either through a safeRAM area somehow "fully safe" (on the TI-68k/AMS platform, unused areas of the vector table were used, because that lies in RAM), or inside the appvar. In such a case, the library entry point had probably better be a RAM-resident TSR, because Flash-resident code would be subject to garbage collection woes;
* using some kind of hook (parser hook, etc.) to trigger the library entry point.

The library entry point would take care of copying the library to RAM, relocating the program, and whatever else needs to be done before and after the program executes.

Well, I do indeed see the wise reasoning behind not using the fixed addresses. However, this means that it would be virtually impossible to do anything, as if RAM locations changed, such as the pointer to the VAT or system table, or the OP variables were to change, that would mean that writing any assembly program would be useless because OS RAM locations would differ on each new version. This would mean that every new OS update would require completely new programs to be written for it, which I don't see TI doing, especially to maintain compatability with their own apps, but that may just be me... Anywho, those are definitely valid concerns! Any other ideas/suggestions that anyone may have?

I imagine if we stored the library's entry points within the library itself, that could also work? Kind of silly, and hackish, but it would make sure everything was working properly.

Well, this is precisely what the successive versions of Ndless have had to deal with for over five years
Between the first generations of Ndless, it was necessary to recompile the program. Nowadays, many programs targeting OS 3.1.0.392 originally can run unmodified on 3.6.0.546/550 and 3.9.0.461/463, thanks to the OS version abstraction layer.

On the TI-68k/AMS platforms, "kernels" had some OS / hardware abstraction layer features, based on a custom system of relocations (extra relocations, on top of AMS's built-in relocations, embedded into the program's data).
Said system of relocations could make it possible, on the TI-eZ80 series, to abstract away the pointer to the VAT, system table, OP variables, and a list of maybe several dozen of the most important internal system data structures.

On the one hand, there is some obvious cost to using an OS version abstraction layer. On the TI-68k/AMS series, it was partially offset by compressed relocation formats.
On the other hand, after all, the TI-eZ80 series has the exact same amount of physical RAM and physical Flash memory as the 89T does, and the real speed of its processor became quite a bit closer to that of the TI-68k series, even if it remains behind due to memory access slowness, fewer and smaller registers. IOW, the idea of using a thin OS version abstraction layer (of maybe several dozen variables, as I wrote above) is much less insane on the TI-eZ80 series as it used to be on the TI-Z80 series


On the TI-68k/AMS platform, neither TI's FlashApps, nor third-party FlashApps, were caught red-handed trashing internal system variables. So either they didn't perform direct internal system variable access (probably >99%), or they did it in a safe way, by retrieving the address from somewhere else (akin to the address / value hacks in TIGCC/GCC4TI - I know, I made most of them ^^).
I know the TI-(e)Z80 series are historically different, with direct internal system variable access. That's clearly more efficient, but more risky.

EDIT: I see you edited your post while I was replying to it, so I missed the paragraph you added.

I'm not exactly sure what you have in mind, but it would have to be done in a way that survives garbage collection.
On the TI-68k series, the Flash execution protection, normally activated for all of the archive memory (except when running MaxMem-patched AMS 2.xx on HW1, or tiosmod+amspatch'ed OS) also gets in the way.