News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_mr_lou

Help with SDCC

Started by mr_lou, 09:50, 11 December 11

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

TFM

Quote from: CP/M User on 08:55, 14 December 11

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

Bullshit! If the firmware calls are the same, you just have CALLs left in the program, so the speed difference can be ignored. Instead of telling me shit you should better make a test on a real CPC. I already did decades ago.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

mr_lou

Wow... I can't get anything at all to work with SDCC

__asm
    ld a,( ix + 4 )     ; Notice spaces. Gives error: <q> missing or improper operators, terminators, or delimiters
    ld a,(ix+4)         ; Notice no spaces. Gives error: ?ASlink-Warning-Undefined Global 'ix' referenced by module 'main'
__endasm;

So whether my code works or not depends on something as simple as spaces in my code...? Wtf?
Who'll step up and defend SDCC here?

TFM

Not me. I intended to set it up for me too, but since it makes you so much problems...  :(

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

mr_lou

Quote from: Octoate on 21:39, 14 December 11
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):

Doesn't matter one bit how I write it. I've tried 3 million 7 thousand 2 hundred and 5 different ways now.
Trying your version still gives me
main.c(5) : error 101: too many parameters
That's the line poke(addr);

Octoate

Ok, I had a look at it and used this code:


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

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


Which compiles, but crashed when I started it in the emulator. This code assembles to (.lst file):


                              1 ;--------------------------------------------------------
                              2 ; File Created by SDCC : free open source ANSI-C Compiler
                              3 ; Version 3.1.0 #7066 (Nov 22 2011) (MINGW32)
                              4 ; This file was generated Wed Dec 14 23:05:17 2011
                              5 ;--------------------------------------------------------
                              6 .module pokeexample
                              7 .optsdcc -mz80
                              8
                              9 ;--------------------------------------------------------
                             10 ; Public variables in this module
                             11 ;--------------------------------------------------------
                             12 .globl _main
                             13 .globl _poke
                             14 ;--------------------------------------------------------
                             15 ; special function registers
                             16 ;--------------------------------------------------------
                             17 ;--------------------------------------------------------
                             18 ;  ram data
                             19 ;--------------------------------------------------------
                             20 .area _DATA
                             21 ;--------------------------------------------------------
                             22 ; overlayable items in  ram
                             23 ;--------------------------------------------------------
                             24 .area _OVERLAY
                             25 ;--------------------------------------------------------
                             26 ; external initialized ram data
                             27 ;--------------------------------------------------------
                             28 ;--------------------------------------------------------
                             29 ; global & static initialisations
                             30 ;--------------------------------------------------------
                             31 .area _HOME
                             32 .area _GSINIT
                             33 .area _GSFINAL
                             34 .area _GSINIT
                             35 ;--------------------------------------------------------
                             36 ; Home
                             37 ;--------------------------------------------------------
                             38 .area _HOME
                             39 .area _HOME
                             40 ;--------------------------------------------------------
                             41 ; code
                             42 ;--------------------------------------------------------
                             43 .area _CODE
                             44 ;pokeexample.c:1: void poke(int a) {
                             45 ; ---------------------------------
                             46 ; Function poke
                             47 ; ---------------------------------
   0000                      48 _poke_start::
   0000                      49 _poke:
   0000 DD E5                50 push ix
   0002 DD 21 00 00          51 ld ix,#0
   0006 DD 39                52 add ix,sp
                             53 ;pokeexample.c:6: __endasm;
   0008 DD 66 05             54 ld h,5(ix)
   000B DD 6E 04             55 ld l,4(ix)
   000E 36 FF                56 ld (hl),#255
   0010 DD E1                57 pop ix
   0012 C9                   58 ret
   0013                      59 _poke_end::
                             60 ;pokeexample.c:9: void main() {
                             61 ; ---------------------------------
                             62 ; Function main
                             63 ; ---------------------------------
   0013                      64 _main_start::
   0013                      65 _main:
                             66 ;pokeexample.c:11: for (addr=0xc000;addr<0xffff;addr++) {
   0013 11 00 C0             67 ld de,#0xFFFFC000
   0016                      68 00101$:
   0016 7B                   69 ld a, e
   0017 6A                   70 ld l, d
   0018 D6 FF                71 sub a, #0xFF
   001A 7D                   72 ld a,l
   001B DE FF                73 sbc a, #0xFF
   001D D0                   74 ret NC
                             75 ;pokeexample.c:12: poke(addr);
   001E D5                   76 push de
   001F D5                   77 push de
   0020 CDr00s00             78 call _poke
   0023 F1                   79 pop af
   0024 D1                   80 pop de
                             81 ;pokeexample.c:11: for (addr=0xc000;addr<0xffff;addr++) {
   0025 13                   82 inc de
   0026 18 EE                83 jr 00101$
   0028 C9                   84 ret
   0029                      85 _main_end::
                             86 .area _CODE
                             87 .area _CABS



Here you can see that the poke() function is inserted before the main() code. So you have to call &4013 and then, the example works.
You get this behaviour, because the example of Norecess uses no crt0.s startup code, which directly jumps to the program code. I'm not a C programmer and would have to look deeper in the SDCC documentation to find more about that issue. A small workaround is to always define the main() function before all other functions you want to call.
--

AMSDOS

Quote from: TFM/FS on 21:39, 14 December 11

Bullshit! If the firmware calls are the same, you just have CALLs left in the program, so the speed difference can be ignored. Instead of telling me shit you should better make a test on a real CPC. I already did decades ago.

Your the one talking the Bull Dust, there is no way you can expect to get the same speed out of a Generic BASIC code Vs using the Firmware and you did say:

QuoteJust use Basic, it will make no difference - in speed.

Even my TP examples enhance through using the Firmware, as tested on a real CPC, because it's Compiler Vs Interpreter - a C Compiler will return the same.
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

mr_lou

Thankyou! Finally an explanation for that weirdness. Finally I feel I'm getting somewhere.

So I guess that means I need a bunch of CPC specific lib-files? I guess I need to copy the sources from here to somewhere. Or is there a better more updated source?
I can't just place them in my project folder? So I have to replace the original files that comes with SDCC, which might be a problem for two reasons. SDCC is part of the repository and installed that way. I can still replace such files (if I can find their location), but wouldn't they just be overwritten again next time there's an update for SDCC?

I tried downloading the latest version of SDCC via svn, but was unable to compile it. It kept complaining about missing programs I needed, such as flex and I forget the other one. I installed those, and then it complained about some boost library missing, which I'm currently installing....

mr_lou

Quote from: CP/M User on 08:33, 15 December 11
Your the one talking the Bull Dust, there is no way you can expect to get the same speed out of a Generic BASIC code Vs using the Firmware and you did say:

Even my TP examples enhance through using the Firmware, as tested on a real CPC, because it's Compiler Vs Interpreter - a C Compiler will return the same.

I think I asked the question earlier, where Executioner (I think it was) said that there wouldn't be much of a different between a draw call from BASIC and a draw call from assembler. Because it's the same firmware call you're making.

You two stop this silly argument, and simply code a simple draw example in BASIC + C or assembler, and then we can all see the result.

HAL6128

#33
this one works...

Quote
void poke( unsigned short a;)
{
__asm
    ld h,(ix + 5)
    ld l,(ix + 4)
    ld (hl),255
__endasm;
}
main()
{
unsigned short i;
for ( i=0xc000 ; i<0xffff ; i++)
    {
    poke(i);
    }
    return 0;
}

"unsigned short" is a integer range from 0 to 65535
...pretty slow mc-code generated (1,2 seconds), but it's fun to programm in C.

in comparison:

0,2 seconds for that mc with the same result:

           org &4000
           ld hl,&c000
loop    ld a,&ff
           ld (hl),a
           inc hl
           ld a,l
           or h
           jr nz,loop
           ret
...proudly supported Schnapps Demo, Pentomino and NQ-Music-Disc with GFX

mr_lou

#34
Quote from: hal 6128 on 14:02, 15 December 11
this one works...

No it doesn't.

main.c(7) : warning 85: in function poke unreferenced function argument : 'a'
main.asm:55: Error: <q> missing or improper operators, terminators, or delimiters
main.asm:56: Error: <q> missing or improper operators, terminators, or delimiters
main.asm:57: Error: <a> machine specific addressing or addressing mode error

Remember, this thread is about (the somewhat troublesome) SDCC - not just general C-coding.
To make it work in SDCC, it must be written like this:


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

void main() {
    unsigned short addr;
    for (addr=0xc000;addr<0xffff;addr++) {
        poke(addr);
    }
}

TFM

#35
Quote from: CP/M User on 08:33, 15 December 11

Your the one talking the Bull Dust, there is no way you can expect to get the same speed out of a Generic BASIC code Vs using the Firmware and you did say:
 
Even my TP examples enhance through using the Firmware, as tested on a real CPC, because it's Compiler Vs Interpreter - a C Compiler will return the same.

TP uses NOT the firmware, it uses CP/M routines. So stop telling crap.

Quote from: mr_lou on 08:44, 15 December 11
I think I asked the question earlier, where Executioner (I think it was) said that there wouldn't be much of a different between a draw call from BASIC and a draw call from assembler. Because it's the same firmware call you're making.

You two stop this silly argument, and simply code a simple draw example in BASIC + C or assembler, and then we can all see the result.

You are right. However I did that before (using BASIC and a Basic Compiler for the native CPC OS, as the IOLIB the allows to run C programs under the native CPC-OS. Result: speed difference less than 5%).

The other guy is obviously not even able to discriminate between firmware and CP/M. Obviously Small C (for example) and TP as well as Modula 2 use CP/M routines whereas Basic (compiled or not), BCPL and C versions for Amsdos use the native CPC-OS firmware.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

HAL6128

#36
interesting:
because both codes works within the tool "Code:Block" (link from octoates website). This tool compiles the code with the help of SDCC.
I have in both cases a working asm/binary for the CPC.

If I'm going to compile directly from Windows-Shell CMD than only your last code generates no error messages and a working asm???

Hello TFM,
is it possible to use your FIOLIB with SDCC? If yes, how?
...proudly supported Schnapps Demo, Pentomino and NQ-Music-Disc with GFX

mr_lou

#37
Quote from: hal 6128 on 16:40, 15 December 11
interesting:
because both codes works within the tool "Code:Block" (link from octoates website). This tool compiles the code with the help of SDCC.
I have in both cases a working asm/binary for the CPC.

If I'm going to compile directly from Windows-Shell CMD than only your last code generates no error messages and a working asm???
I don't know what version of SDCC you have installed, or if there are any changes since v2.9.0 which I'm using. Currently uninstalled though, as I'm trying (again) to install v3.1.0 from svn.
Regardless if I succeed or not, I need to know where I find and replace the files from here: http://www.cpcwiki.eu/index.php/SDCC_and_CPC
crt0.s
putchar.s
and possible the other libs there.

EDIT: The Code::Block thingy is useless to me since I'm on Linux. Even though Code::Blocks IDE does exists for Linux, and even is part of repository, the CPC project file is using Windows executables, so I can't use it.

EDIT 2: It seems I finally managed to install v3.1.1
sdcc -v
SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 3.1.1 #7107 (Dec 15 2011) (Linux)
But there are no changes.

Where do I put the crt0.s and putchar.s file?

TFM

Quote from: hal 6128 on 16:40, 15 December 11
Hello TFM,
is it possible to use your FIOLIB with SDCC? If yes, how?

Well, I assume yes. Originally I inteded to set up SDCC this weekend on my Laptop, but when I see how much problems it creates for others, then I already loose a lot of interrest and will rather use my scare spare time for assembler coding ;-)

To adapt it you have to alter the assembler syntax to that assember used by SDCC - and maybe some smaller stuff. It works well with Small C under CP/M Plus though.
Nurgle (I guess it was him) once told me that FIOLIB runs well with Z88DK. If you get along with SDCC well, it shouldn't be a problem. Let me know if I can help in any way (however I got no idea about SDCC now).

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

mr_lou

Alright, progress finally.

Here's how to do it, if you're running Linux and want to use SDCC

1) Download SDCC from svn co https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk/sdcc sdcc but don't compile yet
2) Edit device/lib/z80/crt0.s and device/lib/z80/putchar.s and replace the contents with those from here.

;; FILE: crt0.s
;; Generic crt0.s for a Z80
;; From SDCC..
;; Modified to suit execution on the Amstrad CPC!
;; by H. Hansen 2003
;; Original lines has been marked out!

        .module crt0
    .globl    _main

    .area _HEADER (ABS)
;; Reset vector
    .org     0x100 ;; Start from address &100
    jp    init
   
    .org    0x110

init:

;; Stack at the top of memory.
;;    ld    sp,#0xffff       
;;    I will use the Basic stack, so the program can return to basic!

;; Initialise global variables
    call    gsinit
    call    _main
    jp    _exit

    ;; Ordering of segments for the linker.
    .area    _HOME
    .area    _CODE
        .area   _GSINIT
        .area   _GSFINAL
       
    .area    _DATA
        .area   _BSS
        .area   _HEAP

       .area   _CODE
__clock::
    ret
   
_exit::
    ret
   
    .area   _GSINIT
gsinit::   

.area   _GSFINAL


;; FILE: putchar.s
;; Modified to suit execution on the Amstrad CPC
;; by H. Hansen 2003
;; Original lines has been marked out!

    .area _CODE
_putchar::       
_putchar_rr_s::
            ld      hl,#2
            add     hl,sp
       
            ld      a,(hl)
            call    0xBB5A
            ret
           
_putchar_rr_dbs::

            ld      a,e
            call    0xBB5A
            ret


If you accidentially compiled before doing this, or if there for other reasons exists the following files in the device/lib/z80 folder, then delete them first:
putchar.lst
puchar.sym
putchar.rel
crt0.lst
crt0.sym
crt0.rel
3) Now compile using
./configure
make
sudo make install
4) Edit your ~/.bashrc file to include the PATH to the sdcc bins
5) Now you're ready to go.

I still need an explanation to why crt0.s want all programs to start at &100 though. That makes no sense to me since I can't load anything there. I can't run"main" either. So unless you compile using --no-std-crt0 you're fucked.
And I'd still like very much to be able to just run"main" instead of needing to memory &3fff:load"main",&4000:call whatever_address_main_ended_up_on - because that's just plain silly too.

You'll find various examples online which just won't work for you. This example, for example

void DisplayChar( char c )
{
__asm
     ld a, ( ix + 4 )
     call &bb5a
__endasm;
}

main()
{
     const char *textPtr = "Hello World !";

     while( *textPtr != 0 )
     {
         DisplayChar( *textPtr );
         textPtr++;
     }

__asm
     call &bb06
__endasm;

     return 0;
}

- won't compile on your Linux box. But if you rewrite it to look like this:


void DisplayChar( char c )
{
__asm
     ld a, 4(ix)   <-- changed
     call 0xbb5a  <-- changed
__endasm;
}

main()
{
     const char *textPtr = "Hello World !";

     while( *textPtr != 0 )
     {
         DisplayChar( *textPtr );
         textPtr++;
     }

__asm
     call 0xbb06   <--- changed
__endasm;

     return 0;
}

- then it works. People say that's seemingly because SDCC is using asxxxx assembler, which can seemingly be changed using the --asm= command parameter. I tried putting --asm=z80asm but that didn't do me any good. So not sure if there is a way out of this, or if we're stuck with asxxxx syntax.

TFM

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

mr_lou

Did a small test to compare the draw call from BASIC vs SDCC. Seems to me SDCC is actually slower!

SDCC source

void drawLine(short x1, short y1, short x2, short y2) {
x1;x2;y1;y2;
__asm
ld e,8(ix)
ld d,9(ix)
ld l,10(ix)
ld h,11(ix)
call 0xbbc0; Move to x1, y1
ld e,4(ix)
ld d,5(ix)
ld l,6(ix)
ld h,7(ix)
call    0xbbf6; Draw to x2, y2
ret
__endasm;
}

void main(void) {
short x;
for (x=0;x<600;x+=10) drawLine(x,0,300,400);

__asm
    call 0xbb06; Press key
__endasm;
}


BASIC source

for x=-300 to 300 step 10
origin 300,0
draw x,-400
next


For some stupid reason I can't load the binary file into memory, print some stuff and call the starting address later. Then it resets. I have to call the starting address right after load. Can you tell me why?

HAL6128

#42
Quote from: TFM/FS on 17:36, 15 December 11
...
Nurgle (I guess it was him) once told me that FIOLIB runs well with Z88DK. If you get along with SDCC well, it shouldn't be a problem. Let me know if I can help in any way (however I got no idea about SDCC now).

I'm going to try "Code:Block" with that Z88DK compiler at weekend. Small-C under CP/M is also available, but first have to check the handbook for handing it. ("Code:Block" is just a hat for serving compilers. Maybe Phactory from norecess is also an alternative?)

@mr_lou: Is it - maybe - because of the org command in crt0.s that programs will always start at &100? Isn't it also possible to add an header with "Start" and "Entry Point" address with managedsk? (Don't know if it works under Linux & Wine??).
Quote
;; FILE: crt0.s
;; Generic crt0.s for a Z80
;; From SDCC..
;; Modified to suit execution on the Amstrad CPC!
;; by H. Hansen 2003
;; Original lines has been marked out!

.module crt0
.globl _main

.area _HEADER (ABS)
;; Reset vector
.org 0x100 ;; Start from address &100

...proudly supported Schnapps Demo, Pentomino and NQ-Music-Disc with GFX

mr_lou

Quote from: hal 6128 on 21:13, 15 December 11
@mr_lou: Is it - maybe - because of the org command in crt0.s that programs will always start at &100? Isn't it also possible to add an header with "Start" and "Entry Point" address with managedsk? (Don't know if it works under Linux & Wine??).
Yes I am pretty sure it is the crt0.s file that is to blame for the starting address being &100.
But why was that chosen in the first place? Because Z80 can be found in many other non-CPC devices? Ok, then why does the alternative crt0.s file at CPCwiki also contain that start address?

Yes, both the SDCC compiler and ManageDsk can decide what the starting address is. It just has no effect. Starting address is still &100 even though I compile with this:
sdcc -mz80 --code-loc 16384 main.c
wine /home/sirlou/Programmer/ManageDsk.exe -L"disk.dsk" -I"main.bin"/MAIN.BIN/BIN/16384/16384 -S"disk.dsk"
But if I do this:
sdcc -mz80 --no-std-crt0 --code-loc 16384 main.c
wine /home/sirlou/Programmer/ManageDsk.exe -L"disk.dsk" -I"main.bin"/MAIN.BIN/BIN/16384/16384 -S"disk.dsk"
then starting address is correctly set at &4000

(The ManageDsk stuff is running via wine, and I borrowed the command from the CodeBlocks project).

I'm finding all of this very difficult, and often illogical. I can't figure out how to include e.g. the amsgraph library either. Everything seemed much simpler with Z88DK. I suspect I'll just go back to Z88DK.

Octoate

Quote from: mr_lou on 20:31, 15 December 11
Did a small test to compare the draw call from BASIC vs SDCC. Seems to me SDCC is actually slower!
No, it isn't. Your code isn't ok! You are using signed values, which gives an overhead to the compiler, because it will generate code which checks the sign bit. Just change all "short" values to "unsigned short" and you will get a performance gain about ~9 percent over BASIC.
Then you put a "ret" at the end of the method... If you do that, you will cause a stack overflow, because the clean-up steps won't run, because you added the "ret" command (see compiler output).

Quote from: mr_lou
wine /home/sirlou/Programmer/ManageDsk.exe -L"disk.dsk" -I"main.bin"/MAIN.BIN/BIN/16384/16384 -S"disk.dsk"
If you are already using "wine" with ManageDsk, then why aren't you using it with the Code::Blocks example. All called commands can be changed in the project settings and I tried to comment everything in the README file... Btw, the Pasmo assembler is also available under Linux.
With this setup you then can work with Maxam style assembly syntax, Norecess' examples and my Code::Blocks template...

Quote from: mr_lou
I'm finding all of this very difficult, and often illogical. I can't figure out how to include e.g. the amsgraph library either. Everything seemed much simpler with Z88DK. I suspect I'll just go back to Z88DK.
It's only difficult, because the different tutorials were mixed up (Norecess' and the one by Hans Hansen). The question is, what you want. If you want to use SDCC without different tools, you cannot use Maxam style assembly syntax and have to learn a new assembly syntax.
If you don't care to use an other assembler backend (pasmo) and tools (SDCC2Pasmo), you can use the tutorial by Norecess and my Code::Blocks template - only under Linux you have to use the Linux version of pasmo and need to change the call to SDCC2Pasmo to "wine SDCC2Pasmo".

Btw, the developers of Z88dk are currently in the progress to allow SDCC to be used as a backend for Z88dk. They realized that you need an ANSI-C compiler nowadays and see that the optimization is far superior.
--

mr_lou

Quote from: Octoate on 22:32, 15 December 11
If you are already using "wine" with ManageDsk, then why aren't you using it with the Code::Blocks example.
Short answer. Because SDCC2Pasmo doesn't run under wine. I tried.

mr_lou

Quote from: Octoate on 22:32, 15 December 11
No, it isn't. Your code isn't ok! You are using signed values, which gives an overhead to the compiler, because it will generate code which checks the sign bit. Just change all "short" values to "unsigned short" and you will get a performance gain about ~9 percent over BASIC.
Well, at first the code did actually use unsigned shorts, but I removed those because I thought there might be cases where I wanted to draw a line from -100 to 100. And in all fairness, BASIC also uses signed values. So saying that the code isn't ok, doesn't add quite up in my opinion.

Quote from: Octoate on 22:32, 15 December 11
Then you put a "ret" at the end of the method... If you do that, you will cause a stack overflow, because the clean-up steps won't run, because you added the "ret" command (see compiler output).
Of course, silly me. I forget that it's really just a "plain" C function that of course returns on its own. doh

Quote from: Octoate on 22:32, 15 December 11
If you are already using "wine" with ManageDsk, then why aren't you using it with the Code::Blocks example. All called commands can be changed in the project settings and I tried to comment everything in the README file... Btw, the Pasmo assembler is also available under Linux.

With this setup you then can work with Maxam style assembly syntax, Norecess' examples and my Code::Blocks template...
It's only difficult, because the different tutorials were mixed up (Norecess' and the one by Hans Hansen). The question is, what you want. If you want to use SDCC without different tools, you cannot use Maxam style assembly syntax and have to learn a new assembly syntax.
If you don't care to use an other assembler backend (pasmo) and tools (SDCC2Pasmo), you can use the tutorial by Norecess and my Code::Blocks template - only under Linux you have to use the Linux version of pasmo and need to change the call to SDCC2Pasmo to "wine SDCC2Pasmo".
I see that the pre-configured Code::Blocks project is using SDCC2Pasmo, which I tried running with Wine without luck. Therefor I'm pretty sure I won't be able to use that preconfigured project.
Initially I did want to use Maxam style assembly, mostly because of the support from all of you I'd need along the way though. Although I must admit, I don't like the "$c000" way of typing values. "0xc000" looks much better to me. But ASXXXX has other silly things.
I have been playing around with the Linux pasmo earlier though, but plain assembly coding will never be me. That's why I went with Z88DK last time.

Quote from: Octoate on 22:32, 15 December 11
Btw, the developers of Z88dk are currently in the progress to allow SDCC to be used as a backend for Z88dk. They realized that you need an ANSI-C compiler nowadays and see that the optimization is far superior.
Yes, all roads point to SDCC, which is why it bugs me that it's giving me such trouble. Each little step takes 3 days. :-(
I think I'll give it a rest now. Sparetime hobbies are supposed to be the relaxing counterpart to the stressing work, not the other way around. ;-)

But I really appreciate the help you've given me so far.

HAL6128

Quote from: mr_lou on 21:31, 15 December 11
Yes I am pretty sure it is the crt0.s file that is to blame for the starting address being &100.
But why was that chosen in the first place? Because Z80 can be found in many other non-CPC devices? Ok, then why does the alternative crt0.s file at CPCwiki also contain that start address?

Maybe it's out of a history manner due to that CP/M apps on Z80 Computer start at &100?? (Just a guess... don't know)
...proudly supported Schnapps Demo, Pentomino and NQ-Music-Disc with GFX

mr_lou

#48
Updated the draw comparison thingy.

SDCC is faster than BASIC now, but not much. (And I still think it's cheating a bit using unsigned shorts).

RUN"compare

EDIT: Could mention, that the SDCC version is only about 4% faster than the BASIC version. So it's debatable if it's worth it.

Can anyone come up with a faster solution?

mr_lou

120 Euro or $150 to the coder who'll assemble (in ASXXXX syntax) my library for SDCC, based on the javax.microedition.lcdui.Graphics class.
I don't need all the methods there though, and some of them needs special adaption for the CPC.
We'll take it slowly, one method after the other. MSN or IRC correspondence necessary.

Example:
drawLine(int x1, int y1, int x2, int y2)
Must take 4 ints (even though you'll probably say unsigned shorts are better).
Must draw a line from coordinates x1,y1 to x2,y2
Coordinates 0,0 is in the upper left corner, as opposed to the lower left corner in BASIC

MSN: mr_lou@vip.cybercity.dk
IRC: mr_lou on proxy.epiknet.org channel #AmstradCPC or irc.freenode.net channel #cpc

Powered by SMFPacks Menu Editor Mod