Thread: Z80 Compiler (for Ti)

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.

Originally Posted by Elysia

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.

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

Originally Posted by matsp

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.

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.

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

Originally Posted by Elysia

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

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.

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.

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

Code:

sdcc sourcefile.c

This will compile, assemble and link your source file.

From http://72.14.253.104/search?q=cache:...&cd=2&gl=ca#21

In other words, something like this might do it . . .

Code:

C:\Windows>cd "\Program Files\SDCC"

C:\Program Files\SDCC>sdcc sourcefile.c

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.

[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

Originally Posted by Dave_Sinkula

Where is the obj\Debug\main.o dependency introduced?
[edit]And isn't your attempt successful?

Well, if I try the command line manually, I get "fopen: failed on main.c".
Obviously it can't find the file file. So how to get Code::Blocks to specify the actual path?

Originally Posted by robwhit

Download the doc package and read sdccman.txt, Chapter 3.

No thanks. I've been looking over that damn manual several times but haven't any success.