Printable View
I know there was some thread about it way back, but I don't know how much information could be salved from it.
Just looking to see if there's a nice C/C++ compiler for Z80. There should be, right?
So does anyone know anything? It's unfuriating to type BASIC on the calc itself, not to mention that it actually crawls.
Any tips would be appreciated.
I'm pretty sure IAR has a Z80 compiler. However, C++ for 8/16-bit processors tend to be beyond what you can expect to find - consider that you only have a maximum of 64KB of addressable memory at any given time, so code and data can't realistically be that big.
--
Mats
I almost expected C++ wouldn't work, but will do fine in this case, then. I'll check it out and see if I can find a compiler. Thanks.
(Although, I can't seem to find any download for the Z80 IDE/compiler on the site...)
I found that, too, but there doesn't seem to be any download link.Quote:
Originally Posted by matsp
I'd contact them and ask if you can have a demo license for that.Quote:
Originally Posted by Elysia
--
Mats
Yep, seems to be the only way.
There's an open source compiler for the Zilog Z80. It's called Small Device C Compiler. I haven't done anything with it, but it seemed like a good compiler.Quote:
Originally Posted by Elysia
It's retargetable
provides full set of data types
allows for inline assembly
don't no what your into, but IAR compilers are usually expensive! Or the evals are limited
Small Device C Compiler Link:
http://sdcc.sourceforge.net/
Awesome! Debugger, as well. Good tip! Excellent! Thanks!
I was the author of the old thread on this subject, never really did get it working. Although i was using the same compiler as jake123 suggested. Elysia, please let me know if you get it working :)
I don't know how to set up Code::Blocks to compile properly with it. It seems to complain in the linker.
Compiling: main.c
sdcc: Calling preprocessor...
sdcc: Generating code...
sdcc: Calling assembler...
Linking console executable: bin\Debug\Test.exe
obj\Debug\main.o: cannot open.
sdcc: Calling linker...
sdcc: Calling linker...
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings
Perhaps building on the command line will show you what's going on [yes, that's very old-fashioned, but sometimes the old-and-tried methods work better].
--
Mats
I agree. Only, I don't know how to figure out how to see how Code::Blocks calls the compiler or linker.
And manually calling the compiler is out of the question. That's something I don't want to do.
But surely to figure out what you NEED to tell code::blocks to do, you will need to know how to call the compiler itself.Quote:
Originally Posted by Elysia
By the way, you can always use (gnu,n,d)make to compile the code.
--
Mats
The IDE supports the compiler, and has options for it, so I figure it can do that by itself.
This isn't Linux; this is Windows.
Despite that, using the command line will help you find out what the options are and how to combine them to produce the right stuff.Quote:
Originally Posted by Elysia
I [admit that I'm old and] use command-line all the time in Windows to get things done that I could not get done if I tried to do it with GUI. It also doesn't "hide" from you things that you may need to know.
--
Mats
But this is exactly why I left Linux. I don't like command lines. I hate them. I can use simple stuff. Such as "chkdsk c:" or "calc" or things like that.Quote:
Originally Posted by matsp
But calling compilers and stuff via command line is not my idea of Windows. And apparently it is not the idea of Microsoft either since they build graphical user interfaces and avoid littering things with CLI.
I also believe in Microsoft's vision, and that is why I use Windows. GUI is not optional, it is a requirement. You should never have to use CLI if you don't want to.
Yes and no. Command line interfaces are clunky, but they are precise. And sometimes that is more important than the neatness that you get from the GUI environment.Quote:
Originally Posted by Elysia
I started programming before DOS was in general use [I used DOS 2.2 for quite some time too], so I guess I'm more experienced with that.
But be that as it may - I'm not trying to say that you should ALWAYS build the app via command-line - rather that if you figure out how to build it, then you can hopefully fix the Code::Blocks problem in the configuration for Code::Blocks [I presume it's something you can configure].
--
Mats
Yeah, I get what you say, but I'm friggin' tired of it and I'm not going to bother. A program that cannot run from a graphical interface is a broken program.
This is incredibly frustrating, just as with most things multi-platform. Especially when develop on linux.
I know what you mean by the CLI being frustrating but it's not really that bad.
I put the command in the history typing it out once and then just up arrow enter and it's done again when I need to rebuild. If I need it for longer than that, I put it in a makefile and do the history thing with that (make enter up arrow enter).
It's not that hard.
You can also make the IDE call your makefile.
So it's not really that hard. Just some setup.
Problem is that don't understand what "basic" setup must be done.
No docs about this sort of thing. No, no. You're expected to figure out everything yourself. Typical Linux.
Did you try adding the compiler to the PATH? That's often considered a "basic" setup step and it usually needs to be done.
Sure, it's already set in "PATH".
You should try the command line. It doesn't look too difficult.
From http://72.14.253.104/search?q=cache:...&cd=2&gl=ca#21Quote:
Using SDCC
3.1 Compiling
3.1.1 Single Source File Projects
For single source file 8051 projects the process is very simple. Compile your programs with the following command
This will compile, assemble and link your source file.Code:sdcc sourcefile.c
In other words, something like this might do it . . .
You'll have to find out which directory sdcc was installed in. I'm not sure how it's set up, but you may be able to run the compiler from any directory, if it's in the path.Code:C:\Windows>cd "\Program Files\SDCC"
C:\Program Files\SDCC>sdcc sourcefile.c
[edit] Not sure how this applies to Z80 programs, if there are any differences at all. [/edit]
As usual, I have no idea on how to call the stupid compiler or linker, because there's no step-to-step guide as how to compile something and the commands, etc.
Here's what Code::Blocks does:
-------------- Build: Debug in Test ---------------
sdcc.exe --out-fmt-ihx -mz80 --profile --verbose --debug --out-fmt-ihx -mz80 --profile --verbose --stack-auto --debug -ID:\Program\SDCC\include -c main.c -o obj\Debug\main.rel
sdcc: Calling preprocessor...
sdcc: Generating code...
sdcc: Calling assembler...
sdcc.exe -LD:\Program\SDCC\lib -o bin\Debug\Test.exe --out-fmt-ihx -mz80 --profile --verbose --debug --out-fmt-ihx -mz80 --profile --verbose --stack-auto --debug obj\Debug\main.rel
obj\Debug\main.o: cannot open.
sdcc: Calling linker...
sdcc: Calling linker...
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings
Where is the obj\Debug\main.o dependency introduced?
[edit]And isn't your attempt successful?
Seems like several things are repeated in the command line - which seems to indicate something being wrong in the settings for the Code::Blocks
--
Mats
Download the doc package and read sdccman.txt, Chapter 3.Quote:
Originally Posted by Elysia
Well, if I try the command line manually, I get "fopen: failed on main.c".Quote:
Originally Posted by Dave_Sinkula
Obviously it can't find the file file. So how to get Code::Blocks to specify the actual path?
No thanks. I've been looking over that damn manual several times but haven't any success.Quote:
Originally Posted by robwhit
Code blocks sucks, it took me an hour to figure out how to get the thing working, then again, I never did get it working.
Then if someone can suggest anything better except for Dev-C++/GCC or whatever it was, then I'll happily listen. I can't even figure out what the resulting linked file is and what the Ti actually accepts.
What happened to Visual C?Quote:
Originally Posted by Elysia
I'm not under the impression that it supports additional compilers.
It wasn't designed to compile for other platforms than Windows.
I assume you installed codeblocks without having it install the gcc compiler ya?
Yes, that's what I did, since I have no need for the compiler.
Did you look into tigcc?Quote:
Originally Posted by Elysia
Quote:
Originally Posted by Dave_Sinkula
It looked like you were trying to build an Intel hex file that you were calling it an .exe.Quote:
Originally Posted by Elysia
I though this was saying to compile the .c into a .rel, and then link the .rel into an ".exe", and having no errors or warnings.Quote:
sdcc.exe --out-fmt-ihx -mz80 --profile --verbose --debug --out-fmt-ihx -mz80 --profile --verbose --stack-auto --debug -ID:\Program\SDCC\include -c main.c -o obj\Debug\main.rel
sdcc: Calling preprocessor...
sdcc: Generating code...
sdcc: Calling assembler...
sdcc.exe -LD:\Program\SDCC\lib -o bin\Debug\Test.exe --out-fmt-ihx -mz80 --profile --verbose --debug --out-fmt-ihx -mz80 --profile --verbose --stack-auto --debug obj\Debug\main.rel
obj\Debug\main.o: cannot open.
sdcc: Calling linker...
sdcc: Calling linker...
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings
I would normally expect some .a type of file output from the linker which is then later translated into a .hex file for use with programming into the calculator. But then I'm not familiar with your system.
Nope, but I will. It looks interesting. Thanks.Quote:
Originally Posted by Dave_Sinkula
Well, as I mentioned, since there's no documentation on the thing, I'm stabbing in the dark. Checking or unchecking the thing has no effect. The problem is that Code::Blocks doesn't supply the full path to the compiler.Quote:
It looked like you were trying to build an Intel hex file that you were calling it an .exe.
I though this was saying to compile the .c into a .rel, and then link the .rel into an ".exe", and having no errors or warnings.
I would normally expect some .a type of file output from the linker which is then later translated into a .hex file for use with programming into the calculator. But then I'm not familiar with your system.
Tigcc is indeed one might IDE, but it's for Ti-89+ and I have merely a Ti-84. Tried building n' compiling, but no luck in transferring any of the files it produced. Incompatible.
Perhaps it might work, perhaps not. I dunno.
I don't think the Ti-89 uses the same processor, does it?
of course it supports additional compilers. I was using Intel compiler with itQuote:
Originally Posted by Elysia
and Lint (which is not compiler itself, but operates as if it is...)
And destination platform depends on the compiler - not IDE
You're right. It does support other compilers.
But then, do tell me how to integrate another compiler into it, because I don't know.
Post on the codeblocks forums blasting them for their inadequacies (sp?)
Blasting the developers of an open source project (or the project itself, on its own forum) provided to you at zero price will only get you flamed, and rightly so. Asking for help, or reporting a bug/the lack of a declared feature might get you somewhere.Quote:
Post on the codeblocks forums blasting them for their inadequacies (sp?)
Intel compiler adds itself into External tools menu and modifies the project filesQuote:
Originally Posted by Elysia
PCLint is added into the External tools menu and creates some "Lint project file" based on the project
I would start with the mak-file type project and look here http://msdn2.microsoft.com/en-us/library/f2ccy3wt.aspx
to see If I can just replace several Envionment variables to point to the new compiler instead of Microsoft compiler, so that nmake will run these external tols instead of defualt ones...