Help with SDCC

[mr_lou]

I'm trying to get a simple SDCC example working. More specifically, I'm looking at the tutorial from NoRecess.
I'm running Ubuntu, where SDCC is part of the repository (and for some reason already installed... maybe I've tried it earlier).

It seems to compile fine. But I can't make it run in emulator.
run"main" just gives me either Ready or Line too long.
memory &3999:load "main",&4000 just gives me Syntax error.

Who can tell me what I'm doing wrong?

EDIT:
sdcc --version returns this:
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.9.0 #5416 (Feb  3 2010) (UNIX)

[AMSDOS]

I'm trying to get a simple SDCC example working. More specifically, I'm looking at the tutorial from NoRecess.
I'm running Ubuntu, where SDCC is part of the repository (and for some reason already installed... maybe I've tried it earlier).

It seems to compile fine. But I can't make it run in emulator.
run"main" just gives me either Ready or Line too long.
memory &3999:load "main",&4000 just gives me Syntax error.

Who can tell me what I'm doing wrong?

EDIT:
sdcc --version returns this:
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.9.0 #5416 (Feb  3 2010) (UNIX)

Have you used the HEX2BIN program to generate the BIN file? SDCC compiles two files from the original C file, one with a ".asm" extension the other with ".ihx", to get it working on the Z80 you use HEX2BIN on the ".ihx" file to produce the BIN file which can be executed on the Amstrad! 

[mr_lou]

Have you used the HEX2BIN program to generate the BIN file? SDCC compiles two files from the original C file, one with a ".asm" extension the other with ".ihx", to get it working on the Z80 you use HEX2BIN on the ".ihx" file to produce the BIN file which can be executed on the Amstrad! 

Yes I have. I'm following the tutorial. It is the BIN file generated by hex2bin I can't get running.

EDIT: I also tried this way without luck, although without his libs.

[mr_lou]

Hmm.... part of the problem seems to be with cpcxfs command:
cpcxfs disk.dsk -f -p main.bin

Looking at that file in ManageDsk afterwards, says the file is of unknown type.
But adding the bin file manually with ManageDsk, telling it it's a binary file that starts at &4000 and has entrypoint at &4000 doesn't make it work. It just resets when I call &4000

Code: [Select]

#include <stdio.h>

int main()
{
    int a;

    for ( a = 0; a < 10; a++ )
    {
    printf("Hello");
    }

    return 0;
}


[AMSDOS]

Yes I have. I'm following the tutorial. It is the BIN file generated by hex2bin I can't get running.

EDIT: I also tried this way without luck, although without his libs.

I'm just wondering if that file has a header? If it hasn't that's the only other thing I can think of which maybe giving you that problem! If it hasn't got a Header then a program like the Lara Monitor will be able to Load it as a '.com' file and from that you can save it as a Binary file (I think).

[mr_lou]

When importing it into ManageDsk, it says "AMSDOS header not found".
Then I exported it with Amsdos header, and imported it again. Then it said "AMSDOS header found".

But the result in emulator hasn't changed.

[AMSDOS]

When importing it into ManageDsk, it says "AMSDOS header not found".
Then I exported it with Amsdos header, and imported it again. Then it said "AMSDOS header found".

But the result in emulator hasn't changed.

Unfortunately that's the only thing I can think of which does that error.    I've tried that approach using .COM files and ASCII files on my Emulator which returns that sort of error. Perhaps put Protext on there if you haven't got it and open the file just to see what it's doing, maybe it's still an ASCII ASM file disguised as a BIN file which isn't. At least that would help to know what it is. If it's all Rubbish coming up in the editor, then it maybe a .COM file, get Lara the monitor program which can load COM files and save them as Standard Binary Files. Fraid I don't really know why that error is coming up after the Header has been attached, ASCII files don't have Headers and if they aren't BASIC programs saved as ASCII file:
 

Code: [Select]


SAVE"<filename.bas>",a

They won't load with the regular:
 

Code: [Select]


LOAD"<filename.bas>"

command.
 
.COM files are Binary though without a header, everytime one of those is loaded is assumes the program is located at &100 - length can vary, sometimes ending with a EOF marker, files generally works in chunks (blocks) of 128 bytes I think (in CP/M Stat can be used to show the number of Blocks in a detailed directory listing).

[Octoate]

Hi,
can you please attach the compiled file and the ".opt" file, which contains the SDCC output? I guess this will help to see what's wrong with the file. Maybe without the printf (because of the massive overhead)?
I also would update to a more recent version of SDCC, because the compiler got significant improvements for the Z80 backend during the last versions - especially the brand new 3.1.0. --opt-code-size option .

[mr_lou]

Files attached.

[Octoate]

Ok, I checked the compiled file (main.bin) with WinCPC and loaded the file directly into the emulator memory (Load binary file - Memory address &4000). It get's correctly loaded and works fine. So you have a problem loading the file.
I created a DSK image with ManagaDSK, too. To do this, I used "Create DSK" and added the file with "Force BINARY". You then have to enter the start address (&4000) and the entry point of your program (&4000) - ManageDSK then can create the AMSDOS header. After that, you can save the disk image.
In the emulator you can load it from BASIC as usual: MEMORY &3FFF:LOAD"main.bin",&4000:CALL &4000
That's all :-).

[mr_lou]

I've tried that procedure you describe, several many times, and I always got the same error.
I just tried again, and didn't get any errors. It just types Ready.

I then tried adding a printf("Hello"); in the source, compiled again, used the same procedure - and I still only get a Ready. No output.

Files attached. Where's my output?

EDIT: Never mind. I see now that the compiler gives an error on the printf command. I guess that's why nothing ever changed.... 

[Octoate]

Ok, I had a look at your new test example and got an error when compiling the main.c file. The problem was (besides the missing include for the stdlib), that you have a cross-compiler here, which doesn't know its execution environment, which means that the printf() function needs a implementation of the putchar(char c) function. I changed your code to provide that function:

Code: [Select]

#include <stdio.h>

int main()
{
    char a;

    for ( a = 0; a < 10; a++ )
    {
printf("Hejsa");
    }

    return 0;
}

void putchar (char c) {   
    __asm
ld      a,4(ix)
call    0xBB5A
   __endasm;
}

The great thing about that is, that you can also implement a putchar() version, which uses another hardware interface (e.g. the CPC Booster or an other serial interface - yay, remote debugging ) for your debug messages.
Btw, don't be scared by the code size of your example. The printf() function is really a beast and wastes a lot of memory to support all those different format encodings. It is better to implement your own printf() function instead.

[mr_lou]

Thanks for the help Octoate. It would seem that all the trouble I had was mostly because of that missing putchar thingy then...

I'm wondering, is there any official CPC lib for SDCC, like there is CPCRSlib for Z88DK?

[Octoate]

Well, during the last months, the maintainer of the Z80 backend of SDCC and the developers of Z88dk are working together to make SDCC compatible to Z88dk (have a look at the release notes of SDCC 3.1.0 and the Z88dk forums). It also shouldn't be a problem to port the CPCRSlib to SDCC, because it's mainly the assembler syntax, which needs to be adapted.
A problem with an own library is that you mostly have different requirements for such an library. E.g. do you want to use the firmware to save memory or do you want to use your own routines for speed? If you don't want to use the firmware, you have to provide everything by yourself, but what? Sound routines? Disk routines? Graphic routines? It is also possible that you need special, for your environment optimized routines, which aren't available in this library. All this points are problems for a general purpose library.

[TFM]

Well, if you use the firmware ... then why use C? Just use Basic, it will make no difference - in speed.

[mr_lou]

Well, if you use the firmware ... then why use C? Just use Basic, it will make no difference - in speed.

Good point.

I would like to avoid slow firmware calls in the main loop, because as TFM/FS says, otherwise I could just use BASIC. Everything outside the main loop can use firmware calls.
I'd love to have this project started up with someone who's a genius at CPC assembler. I'm even willing to pay for it.

[mr_lou]

Well, I've been trying to get several stuff working with SDCC today without luck.

I think examples here are there are contradicting themselves. Some say that variables passed to assembler is always on ix+4, while I see other example that seems to pick them from other places, e.g. ld hl,#2.
I don't get why some examples (all about SDCC) contains numbers like 0x12 while others do #12, and some even do #0x12.

Can someone write me an SDCC example that simply fills the screen? This is what I thought would do it:

Code: [Select]

void main() {

int addr;
for (addr=0xc000;addr<0xffff;addr++) {
poke(addr);
}
}

void poke(int a) {
__asm
; Tried several stuff here:
ld (a),255  ; poke a,255? No?
; ok then what about this:
ld hl,a
ld (a),255 ; Just another way of poking? No?
; Then what?
__endasm;
}


[demoniak]

I don't know SDCC, but I've read NoRecess's tutorial, and I think you should try this :

Code: [Select]

void main() {

int addr;
for (addr=0xc000;addr<0xffff;addr++) {
poke(addr);
}
}

void poke(int a) {
__asm
  ld h,(ix+5)
  ld l,(ix+4)
  ld (hl),255
__endasm;
}

[demoniak]

Or you can try this :

Code: [Select]

poke(a)
    int a;
{
_asm
  ld h,(ix+5)
  ld l,(ix+4)
  ld (hl),255
_endasm;
}

main() {
int addr;
for (addr=0xc000;addr<0xffff;addr++) {
poke(addr);
}
}



[mr_lou]

Thanks for trying, but I keep getting different errors, like these:

main.c(5) : error 101: too many parameters
main.asm:55: Error: <a> machine specific addressing or addressing mode error
main.c(1) : error 7: Old style C declaration. IGNORED 'poke'

[mahlemiut]

I'm not familiar with SDCC specifically, but moving the variable declaration inside the function should fix at least that last error.

eg:

Code: [Select]

poke(a)
{
    int a;
    _asm
    ...

[mr_lou]

Isn't helping. No matter how I put it (and I've tried a ton of different ways now), I keep getting a shitload of errors.

main.c(4) : warning 112: function 'poke' implicit declaration
main.c(4) : error 101: too many parameters
main.c( : error 7: Old style C declaration. IGNORED 'poke'
main.c(15) : error 141: two or more data types in declaration for 'poke'
main.c(15) : error 1: Syntax error, declaration ignored at 'poke'

Back when I tried Z88DK I don't recall have this many problems. But SDCC seems to be the preferred choice nowadays. So far I don't quite understand that.

[AMSDOS]

Well, if you use the firmware ... then why use C? Just use Basic, it will make no difference - in speed.

Rubbish, there is a big difference in Speed, perhaps you should try it someday instead of criticising it! 

[mr_lou]

Well, it can easily be settled by coding a simple drawing in C and BASIC and time both of them.

[Octoate]

Demoniak is on the right way, but he uses the Maxam-style assembler syntax, but to do this, you need to use Norecess' assembler syntax converter, because SDCC uses the ASXXX assembler, which uses a different syntax. You have to change the code to this (untested):

Code: [Select]

void main() {

int addr;
for (addr=0xc000;addr<0xffff;addr++) {
poke(addr);
}
}

void poke(int a) {
__asm
  ld h,5(ix)
  ld l,4(ix)
  ld (hl),255
__endasm;
}

Another important thing is that you can't use variables, which are passed in the function declaration, directly in the assembler code. You have to read them from the stack. That's why you have to manually load 'hl' with the value of 'a'.

The speed should be faster than BASIC even when using the firmware routines, because the code wouldn't be interpreted and it creates smaller executeable code, of course.