Assembly code to generate a crt0 for Doors CS programs with SDCC (should be assembled with sdasz80):


Code:

Build with
Code:


And an example C program (using the ti83p.lib library provided by TISDCC):

Code:


Build it with the following command line (allocates variables at AppBackupScreen = 0x9872):

Code:


(wabbit is wabbitsign, makebin comes with sdcc, and cutbin is a little python script I just wrote).

Source for cutbin:

Code:

If anyone knows what ALEs are or how to use them, you should be able to modify the C code to contain an appropriate array of ALE names instead of hard coding the symbol to a null pointer.

http://dcs.cemetech.net/index.php?title=ASM_Header#Normal_Header

There seems to be more and more talk of C with z80--I was under the impression that this results in terrible code, is that no longer the case?

I was just about to ask the exact same question. If it's actually feasible to write games and programs for Doors CS in C now and have them fit inside the 8KB limit, that would be a massive step upwards. Particularly with the TI-84 Plus C Silver Edition coming soon.

It has been possible for a while. You just need to know your limitations, that's all. I _did_ post a guide to using SDCC with TIOS

It's been possible for, like, ever. We're not asking about the possibility, but rather the feasibility and the quality of the code that would be produced. My interest is in how good the code is for someone who's neither a great C nor z80 programmer.

Being a good C programmer is probably requisite. One of the motivations for the LLVM stuff AHelper and I've been looking at, is because a lot of the optimizations in SDCC are the result of hand tweaking, and LLVM is designed to have powerful optimizing capabilities and static code analysis.

So if we can get most (or all) of the Ti Z80 Asm BCALLS into one C include file, C might actually take off as a semi-major programming language for the Ti 83/4/+/BE/SE calcs?

I think it could - you just need a lot of optimizations. I wonder if such a program could be compiled as a multi-page App - in that case, I think that C might even overtake ASM as the weapon of choice.

Well, I wouldn't hold my breath anytime soon...
it seems like there are a few different ways to write the Hello World program in C (whereas there is really only one "right" way to write it in say, TI-BASIC or Axe or Z80 Asm)

But yeah, I think that if C really does become optimized for the ti z80, then we might get alot of new programmers

I've tried looking at the tutorials and resources for these things, and I'm just really confused at the process involved, with what I need to do and how I need to run and build things - especially since I'm a Windows user, and this seems suited to Linux use. Is there a coherent, updated set of resources somewhere that I can get to for building TIOS programs in C?

Yes, it can, if you know what you're doing.

Works the same anywhere.

* Write code
* Compile code to (typically relocatable) object files
* Link object files into machine code
* Put machine code into a TI file format.

For a simple compiling test on Windows (assuming you have all of the necessary tools):

Code:

Thanks very much, Elf. I got all the right tools and got something compiled, but it crashed my emulator. Hopefully I can see if there's anything wrong with my build process.

Is the cutbin program that comes with TISDCC defective? I'm not using the program itself, but I did snarf its lib, like you directed, and its cutbin, which you did not.

EDIT: It isn't cutbin at all - the program header looks fine, and the icon looks coherent - a 16x16 square. In fact, the sample program runs all the way to pressing Enter, and then WabbitEmu gets thrown into the debugger and is running at the beginning of memory. When I reset the calculator and turn it back on, "Hello World" does appear on the screen, and then I get the RAM Cleared message.

EDIT 2: And the error has to do with the compilation process itself. I tried commenting out all of the code inside main() and still got the error. I think that the call stack must be set incorrectly, and it's not jumping back to the right spot. Also, I noticed that DispInt(char) looks wrong - it has two or three digits each on separate lines.

EDIT 3: Here's my C source:
Code:

... and the ASM file it generates:
Code:

Does that look right to you?
I should also say that I'm using DCS 7 beta 2, and my calc is running 2.53 MP. And it's definitely the C program - a pure ASM program (Invalid Tangram) works just fine).

EDIT 4: And as if all those addendums weren't enough, here's a Windows batch file I wrote to compile my program (note that it's named helloworld.c and that ti83p_dcs.rel is in the same directory as my source:
Code:


EDIT 5: In fooling with the WabbitEmu debugger some, I noticed that it never appears to even reach the ret at the end of the program - I set breakpoints on all the rets in the 100 or so bytes after 0x9d9e, where the program starts, and none of them were hit. Which seems to me as if the stack is being messed up somewhere.

* bump *

Hi, I edited my last post with my issues. Do you see anything that could be the cause of my calc crashing when I try this?

EDIT: Eureka! I found it! (But I have no idea what to do about it...)
This is the important part of the assembly source (what it should be):

Code:

And here's how that code ends up getting compiled - and compiled very wrongly:

Code:

For some reason, SDCC is writing the wrong address for the jump instruction, causing the >$C000 check to trigger and the calculator to reset. Is there a way I can fix this, or is this a bug in SDCC?

EDIT 2: And I fixed it! Instead of doing a "jp exit", do a "jr exit"! Because "_exit" is typically really close to the label that jumps there (since the description and icon are pointed to), it should work. However, it seems that there is thus a bug in how SDCC writes jp instructions, because the code is now:

Code:

It appears that SDCC is only writing the LSB for absolute jump instructions, not both the LSB and the MSB. Thus, the stray "ret" that appears so easily now was meshed into the jp instruction, causing the processor to enter never-never land. Bug report time!

Make sure you have the newest version of SDCC, not the one that comes with the tisdcc package on ticalc.org. iirc, I installed mine off of MacPorts, and haven't had any of the problems you're describing.

I am using the newest version for Windows (SDCC 3.2.0a for Win32). The command "sdcc --version" outputs:

Code:

I'll try reinstalling, just in case anything is wrong here.

EDIT: Same problem. I don't even need to run it in order to tell because the jp version is exactly the same size as the jr version, even though it should be one byte larger.

EDIT 2: And it appears that the bug is in sdasz80, not sdcc itself. I just wrote a program with a huge while(1) loop that forced sdcc to write an unconditional jp instruction, and it wrote both bytes just fine. I think that sdas makes a mistake in writing the rel file from the crt0.
Oh, and I can't help but admire how smart of a compiler sdcc appears to be - I filled up the loop by writing complex math expressions, but if I didn't use the result later, it would exclude the code from the program.

EDIT 3: OK, now that my build environment is somewhat working, I tried to add functions to ti83p.lib so that I could get cracking. However, it appears that SDCC has changed significantly since the lib was compiled: I'm getting lots of syntax errors such as tokens not being recognized and such. Should I just start from scratch?

So I compiled the first bit of assembly code on the topic (the one thats supposed to replace crt0.s?) and it compiled to ti83p_dcs.sys

Is that correct?