Programming in C on the CPC

[MacDeath]

Category:C - CPCWiki


Category:Programming - CPCWiki


as those articles are CPC oriented, it could be indeed nice to have some links.


The Category : C page would be nice for this, just add in it a paragraph and links.

Also a few mentions at the following pages :

SDCC - CPCWiki
Z88DK - CPCWiki

[Gryzor]

Quote from: Mochilote on 30 September 2012, 17:04:56One new tutorial:


-Sprites III: Transparency (C & ASM with SDCC)
Are the links to these tutorials also on the wiki?
It would be good to also have a list that others can look at.

I think a programming section would need to get organised...

[Xifos]

Hi,

another question, this time it's about sdcc.

Does this compiler support the undocumented Z80 instructions ?

Like ld ixh,a

[Marq]

Hi,

another question, this time it's about sdcc.

Does this compiler support the undocumented Z80 instructions ?

Like ld ixh,a

SDCC uses as-z80 internally. At least the inline assembly doesn't support the format you propose. Then again, IX/IY commands are (IIRC) just HL commands with a prefix of $dd of $fd, so you could write them like this:

_asm
.db 0xdd ; same as ld ixh,a
ld h,a
_endasm;

[arnoldemu]

Hi,

another question, this time it's about sdcc.

Does this compiler support the undocumented Z80 instructions ?

Like ld ixh,a

no. Well I could not get them to work.

[db6128]

I'm sure you knew to check this, but just in case, did you try calling them LX, HY, etc.?

[Xifos]

Well, that was just a question, it is not really a problem...
Thanks for the replies.

And i wonder : what is faster ?

ld ixh,a

ld (memory),a

The question is only for inline asm (for sprite routines, stuff that needs speed), i enjoy coding in c and sdcc seems to be a good compiler for cpc/cpc+.

[db6128]

And i wonder : what is faster ?

ld ixh,a

ld (memory),a

As per the Z80 manual and Kev's list of timings, LD (nnnn),A takes 4 NOPs whereas LD IXH,A is twice as fast at 2 NOPs.

Even though the 8-bit halves of the index registers are always 1 NOP slower than normal 8-bit registers, they can still be very useful when all the others are occupied. like on the outside of loops, etc.

[Xifos]

Thanks a lot guys !


I tried the .db 0xDD / .db 0xFD method !
It works !
(i had to use 0xFD for iy rather than ix because i was in a function and i think ix must not be modified in that case)

[Mochilote]

One new tutorial:

-Snake: Minigame with tile's, keyboard and sprites (C & ASM with SDCC)

-Updated the tutorial SDCC vs z88dk: Comparing size and speed of the binaries generated for Amstrad CPC including in the last test the results with the new version of z88dk v1.10.

[db6128]

(i had to use 0xFD for iy rather than ix because i was in a function and i think ix must not be modified in that case)

Two things from SDCC's official user manual:

The stack frame is similar to that generated by the IAR Z80 compiler. IX is used as the base pointer, HL and IY are used as a temporary registers, and BC and DE are available for holding variables. Return values for the Z80 port are stored in L (one byte), HL (two bytes), or DEHL (four bytes).

So, yes, this suggests that you should not be using IX. As for IY, maybe SDCC will use it between your blocks of ASM, which would mean you couldn't retrieve values if they're separated by C code. I don't know enough to guess whether changing IY might confuse SDCC if it is already using it as a temporary value between your sections of ASM.
However:

--reserve-regs-iy This option tells the compiler that it is not allowed to use register pair iy. The option can be useful for systems where iy is reserved for the OS.

[Xifos]

>db6128 and the others

Thanks for your detailed answers.
I used a push ix at the beginning of my asm routine and a pop ix at the end !
Better speed using ixh/ixl/iyh/iyl for storing values.

>Mochilote

Interesting tutorials !

[cpcitor]

Hi, the tutorial index is here: AMSTRAD CPC PROGRAMMING TUTORIALS and i am 'the someone' 

Hello,

These seem really interesting.

Once a forum discussion brings interesting facts or conclusions, everyone wins if those are included in the wiki.
As a first step, I mentioned your tutorial in Programming:Cross Development - CPCWiki


Feel free to review/criticize/correct.

[Gryzor]

Thanks for the edit

(I edited your post slightly since link generation is automatic)

[Optimus]

I have used IX/IY and their 8bit counterparts with SDCC. You only need to be careful to PUSH/POP IX/IY in the beginning/end of your asm code when it's inside a C function that you call.


Though, my SDCC framework uses SDCC2Pasmo from NoRecess, to use the Pasmo assembler with Maxam syntax I prefer, so iirc those where supported as hx/lx or hix/lix (don't remember).
But yes, the alternative is with db, that's how I did it in other assemblers years ago.

[Mochilote]

Two new tutorials:

-Keyboard: Reading HW, multiple simultaneous keypresses, redefine (C & ASM with SDCC)

-Fire: Attempt to make a fire effect and optimization (C with SDCC)


I hope you like it,


greetings.

[cpcitor]

-Keyboard: Reading HW, multiple simultaneous keypresses, redefine (C & ASM with SDCC)

It would be interesting to make explicit the pros and cons of using this rewritten keyboard scan routine, by comparing with the firmware routine.
For example comparing size, speed, resources used (registers, memory area, etc).

Also, if one chooses to use all CPC memory and wipe all firmware areas (save some for the stack), disabling the firmware and perhaps using one's personal interrupt handler, is it still possible to manually call the firmware keyboard scan routine (say, to save some bytes in my ROM-based game for Amstrad CPC 16KBs ROM Game Development Competition! ) ?

I hope you like it,

I do !
As a tutorial on how to read hardware from C, it's pretty nice.
If I use it I'll credit you for sure !

[AMSDOS]

It would be interesting to make explicit the pros and cons of using this rewritten keyboard scan routine, by comparing with the firmware routine.
For example comparing size, speed, resources used (registers, memory area, etc).

For the programs I do, KM TEST KEY (&BB1E) does the job adequately, though the more complicated the program and more players to go with it, resorting to the hardware direct maybe the only option, though I cannot get over the size of that routine, I'm not even going to try and understand all that C code that goes with it. 

[cpcitor]

For the programs I do, KM TEST KEY (&BB1E) does the job adequately, though the more complicated the program and more players to go with it, resorting to the hardware direct maybe the only option, though I cannot get over the size of that routine, I'm not even going to try and understand all that C code that goes with it. 

KM TEST KEY looks equivalent to BASIC's INKEY(number), which seems fine: both allow you to get the pressed status of each key as accurately as the hardware can tell.

I can understand constraints like "I killed the firmware-reserved part of the RAM, use my own interrupt scheme" to force someone into scanning the keyboard oneself, but you do not mention those reasons.

How can the "complication of the program" and the "number of players" call for direct hardware scanning ? What's specific in this case ?

[AMSDOS]

KM TEST KEY looks equivalent to BASIC's INKEY(number), which seems fine: both allow you to get the pressed status of each key as accurately as the hardware can tell.

I think so, though with KM TEST KEY - 'A' contains the key/joystick number and if found, the Zero Flag is false. If it's not found then the Zero Flag is true, Carry is False, 'A' & 'HL' are corrupt. The 'C' Register holds the Shift and Control Status and other registers are preserved.

I can understand constraints like "I killed the firmware-reserved part of the RAM, use my own interrupt scheme" to force someone into scanning the keyboard oneself, but you do not mention those reasons.

How can the "complication of the program" and the "number of players" call for direct hardware scanning ? What's specific in this case ?

i'm not the best person to explain why use Hardware instead of Firmware, though using Hardware could simply mean freeing up the area of memory occupied by the Firmware. From a number of players perspective, a game which has a number of players playing at the same time maybe more critical using Hardware over Firmware to deal with the number of signals coming in at the same time perhaps.

[Mochilote]

After reading your comments i have modified the tutorial to include keyboard firmware method from SDCC and the comparison with direct reading of HW:

-Keyboard: Reading HW, multiple simultaneous keypresses, redefine, Firmware vs. HW (C & ASM with SDCC)


Now that is more complete I hope that everyones like it 

Mochilote.

[AMSDOS]

After reading your comments i have modified the tutorial to include keyboard firmware method from SDCC and the comparison with direct reading of HW:

-Keyboard: Reading HW, multiple simultaneous keypresses, redefine, Firmware vs. HW (C & ASM with SDCC)


Now that is more complete I hope that everyones like it 

Mochilote.

I think the other problem with KM TEST KEY is Jumping to the appropriate area depending on if a result was or wasn't found. I wonder how that test would go if 'JP Z, _end_IsKeyPressed' was 'JR Z, _end_IsKeyPressed', in that situation if the condition is not met 7 clock cycles is only used, though 12 clock cycles if a key is found.

[MaV]

..., in that situation if the condition is not met 7 clock cycles is only used, though 12 clock cycles if a key is found.

That's basically right, but be careful! You're basing your instruction timings on the original information for the Z80. The CPC lengthens the cycles to a multiple of four, so 7 cycles become 8 (= 2 NOPs or 2us).

documentations:devices:z80 [Grimware]
Das Schneider CPC Systembuch: Anhang: Die Z80: Ausführungszeiten für die

cpcitor has created a PDF recently:
Craving for speed ? A visual cheat sheet to help optimizing your code to death.

[AMSDOS]

That's basically right, but be careful! You're basing your instruction timings on the original information for the Z80. The CPC lengthens the cycles to a multiple of four, so 7 cycles become 8 (= 2 NOPs or 2us).

documentations:devices:z80 [Grimware]
Das Schneider CPC Systembuch: Anhang: Die Z80: Ausführungszeiten für die

cpcitor has created a PDF recently:
Craving for speed ? A visual cheat sheet to help optimizing your code to death.

Oh okay that's interesting. That would mean a "JP Z,somewhere" would always be 3us regardless of what the condition is. "JR Z,somewhere" on the other hand would be 1us faster if the condition is not met and at worst no slower than a "JP Z,somewhere" if the condition is met. 

[db6128]

That would mean a "JP Z,somewhere" would always be 3us regardless of what the condition is. "JR Z,somewhere" on the other hand would be 1us faster if the condition is not met and at worst no slower than a "JP Z,somewhere" if the condition is met. 

Yes, and this is actually quite 'useful' from a programming perspective, although of course, a lack of slowdown would be far better! Another similar fact is this makes DJNZ the same speed as DEC r:JR NZ, which (again, although slower) simplifies optimisation when the B register is already in use, e.g. for OUTs. Speaking of the CPC and B, don't get me started on the CPC's way of doing I/O or is it really the Z80's fault here?