[CPC] Output file name, screen border, emptying keyboard buffer

[RobertK]

Here are a few questions/issues/wishes, I have recently obtained a Ulifac device so that I can now test everything easily on my real 464:

1. -o hello creates a hello.cpc file on the disk. I would prefer the file on the disk not having the extension .cpc, but instead .bin.
The advantage would be: if the file is named hello.bin, you can load it with
RUN"hello"
But if the file is named hello.cpc, you have to load it with
RUN"hello.cpc"

2. The screen border is blue by default, is there a way to change its colour? Same for the foreground colour which by default is cyan.

Code: Select all

textcolor(WHITE);
textbackground(BLACK);

does not work, the foreground colour always stays in cyan.

3. Is there a way to programmatically clear the keyboard buffer? Either any target-specific trick, or is there even a console function that would do this?
On the CPC, a short key press has a much longer effected than on other targets.
E.g. when my program goes from screen A to B and then to C, I would like to use the X key to always return to the previous screen. When pressing X on screen C, I would like to clear any present keyboard input when getting to B, in order to prevent from further returning to screen A.

[Timmy]

I also wanted to chime in about making the CPC output to be a disc file with a .bin extension inside it.

It's otherwise a lot of work to type the extra ".CPC" part every single time when you want to test a compilation quickly.

(Note: .BIN is for binaries, there is also a different extension for basic programs but we're making binaries anyway.)

I can't comment on the other points as I don't use the console libraries for now.

[Timmy]

So I just spent two hours today to look a little bit into how appkame worked.

Anyway, it seems there is an option available.

It seems that this one option will remove the dreaded .CPC extension, and can be used like this.

Code: Select all

zcc +cpc -lndos -lm -subtype=dsk -create-app "-Cz-o game1" -zorg=16384 -o 10.bin cpctest10.c

I'm sure you can figure out which option, it's the odd one out.

But at least my test program works now without .CPC. Big yay!

(Test program in a future thread, not to disturb this one.)

[dom]

AFK. —hardware-keyboard is available.

Is bordercolour() not implemented?

[RobertK]

1.

It seems that this one option will remove the dreaded .CPC extension, and can be used like this.

Code: Select all

zcc +cpc -lndos -lm -subtype=dsk -create-app "-Cz-o game1" -zorg=16384 -o 10.bin cpctest10.c

Thank you Timmy, that removes the extension.

2.

Is bordercolour() not implemented?

Ok, that was obvious - bordercolor(BLACK); turns the border black.

I had never used that function before, so I had to ask...

Same for the foreground colour which by default is cyan.

Code: Select all

textcolor(WHITE);
textbackground(BLACK);

does not work, the foreground colour always stays in cyan.

Having just compiled ansivt52.c...

AnsiVT52_CPC_320x200.jpg

...I finally understand it: the default screen mode is mode 1 (320×200), which has four colours only, and white is none of them.
So those who want more colours need to switch to mode 0 (160x200).

3.

AFK. —hardware-keyboard is available.

That solves my problem, thanks!
What exactly does "hardware keyboard" mean? What's the effect of this option?

[dom]

There's a function cpm_set_palette(int pen, int colour) where colour is (I think) form this table: https://www.cpcwiki.eu/index.php/CPC_Palette so you can redefine the colours as you wish.

What exactly does "hardware keyboard" mean? What's the effect of this option?

Where available this reads the keyboard hardware directly, bypassing any firmware/rom calls.

For example on +zx by default we rely on picking up the value from (23560) which is populated by the interrupt. Specifying --hardware-keyboard on +zx will directly read port 254.

On +cpc, by default we'll use the firmware functions km_read_char/km_wait_char but specifying --hardware-keyboard will talk directly to the PPI and AY chip to bypass the firmware.

[RobertK]

There's a function cpm_set_palette(int pen, int colour) where colour is (I think) form this table: https://www.cpcwiki.eu/index.php/CPC_Palette so you can redefine the colours as you wish.

Ah, cpc_set_palette() it should be, from cpc.h. So White is colour #26, and by trial and error I found out that pen #3 is used for the default foreground colour in mode 1, so

Code: Select all

cpc_set_palette(3, 26);

turns the screen to white-on-black, thanks!

[dom]

Thanks for reading through the typos.

I've now changed the -subtype=dsk generator to not add a .cpc suffix. Hopefully there's no knock-on effects.

[Timmy]

Perhaps it's nice to also have a suffix option just in case someone wants .BIN (or something else) for instance?

Probably easier to add now than later.

Also note: it might be advisable to not mix hardware music/sound routines with hardware keyboard routines. Because they are talking to the same chip, this might go wrong. If you're calling them separately, it should be fine. (I have not tested this, though.)

[dom]

The CPC is a bit of a horrible machine at times.

However, in this case hardware-keyboard excludes the firmware so there's no danger of clashes on the side.

The music players only write up to register 13 so don't touch the registers used for keyboard etc, they also don't split register select/write so the only potential issue would be if you were scanning keyboard in the interrupt but playing music in "user space". Which would be an odd way to do things.

[RobertK]

I've now changed the -subtype=dsk generator to not add a .cpc suffix. Hopefully there's no knock-on effects.

That's fine now, thank you, there are no side-effects.

I have finally released my remaining three programs for the CPC, things are working better now than when I last visited this target (long time ago).
I like the CPC's 160x200 mode, I have made Deepspace versions for both resolutions (320x200 and 160x200).

[Timmy]

But at least my test program works now without .CPC. Big yay!

(Test program in a future thread, not to disturb this one.)

Phew... I only now realised I already posted the demo program before in https://z88dk.org/forum/viewtopic.php?t=11776

Nothing changed much since then. Not reposting the program again.