Preventing ink blink by firmware

[cpcitor]

Hello.

Along the way of make firmware calls available to C, I notice and try more.
MC SET INKS seems interesting because you supply it an "ink vector", a table of hardware color values, and it sends them.
You don't even need to make a loop over a bunch of values.
The aim here is simplicity, short (size-optimized) source code and generated ASM.
I used it and shaved some bytes.

The trouble is: SCR pack is not aware and overwrites those nice colors right after.

There is a possible heavy solution: disabling all interrupts (or at least the handling of interrupts by firmware), polling keyboard via custom routine, which makes more byte-hungry executables.

Is there a way to disable the color blinking performed by SCREEN pack without heavy options?
Is ink blinking performed in a block that can be somehow disabled separately? (KL * TICKER, etc).

Thanks!

[Docent]

Hello.

Along the way of make firmware calls available to C, I notice and try more.
MC SET INKS seems interesting because you supply it an "ink vector", a table of hardware color values, and it sends them.
You don't even need to make a loop over a bunch of values.
The aim here is simplicity, short (size-optimized) source code and generated ASM.
I used it and shaved some bytes.

The trouble is: SCR pack is not aware and overwrites those nice colors right after.

There is a possible heavy solution: disabling all interrupts (or at least the handling of interrupts by firmware), polling keyboard via custom routine, which makes more byte-hungry executables.

Is there a way to disable the color blinking performed by SCREEN pack without heavy options?
Is ink blinking performed in a block that can be somehow disabled separately? (KL * TICKER, etc).

Thanks!

You can remove frame flyback event that is used to change inks:

Code Select Expand


ld hl, &b7f9 ; &b1fe on cpc 464
call &bcdd

but it requires OS version specific code and there is simpler and more os friendly way - you can just change the two inks that are set to blink by the kernel:

Code Select Expand


call &bc02
ld a,14
ld b, 1
ld c, b
call &bc32
ld a, 15
ld b, 11
ld c,b
call &bc32

This will reset the screen pack and set two inks that have blinking colors to the same color thus giving non blinking inks

[cpcitor]

You can remove frame flyback event that is used to change inks:

Code Select Expand


ld hl, &b7f9 ; &b1fe on cpc 464
call &bcdd


Interesting! Will test!

You wrote "that is used to change inks".
Soft968 section 15 says: "The ink flashing frame flyback event is set up."
So, there is a flyback dedicating to changing inks. Cool!

I found another, simpler solution: call KL CHOKE OFF#BCC8 at the beginning of program.
It's portable and explicitly keeps keyboard and sound events.
One can event test it from BASIC instantly and it works.

More generally, is there a documentation somewhere about (ideally all) the flyback(s) setup by OS, what each of them do?

[Docent]

Interesting! Will test!

You wrote "that is used to change inks".
Soft968 section 15 says: "The ink flashing frame flyback event is set up."
So, there is a flyback dedicating to changing inks. Cool!

I found another, simpler solution: call KL CHOKE OFF#BCC8 at the beginning of program.
It's portable and explicitly keeps keyboard and sound events.
One can event test it from BASIC instantly and it works.

More generally, is there a documentation somewhere about (ideally all) the flyback(s) setup by OS, what each of them do?

I haven't found any such documentation, you can only find out by analyzing the code.
Anyway, os sets only 1 frame flyback event (used for ink blinking) and some audio and break events when needed.
Other events are also used by amsdos (for turning disk motor off) and basic (handling ON SQ, EVERY and AFTER commands)

[Longshot]

Is there a way to disable the color blinking performed by SCREEN pack without heavy options?

At each frame :
LD A,#FF    ; Max time counter
LD (#B7F8),A
B7F8 contents is the delay value for the color blinking...

[Docent]

At each frame :
LD A,#FF    ; Max time counter
LD (#B7F8),A
B7F8 contents is the delay value for the color blinking...

this will work only on 6128.

[Longshot]

this will work only on 6128.

Right. I had used this in B-Asic (not compliant with 464+ with ram extension)
The address for 464 is B1FD

ld hl, &b7f9 ; &b1fe on cpc 464
call &bcdd

This method is not more universal.
Don't know if the event disabled was "only for" ink blinking. (need to see at #D61 (6128))

[cpcitor]

Right. I had used this in B-Asic (not compliant with 464+ with ram extension)
The address for 464 is B1FD

This method is not more universal.
Don't know if the event disabled was "only for" ink blinking. (need to see at #D61 (6128))

I understood from @Docent comment earlier in this thread that this event indeed does only ink blinking.

Anyway, calling KL CHOKE OFF does the trick nicely. No need to fiddle with anything at each frame, the event is just cleanly unregistered.
Better, it must works on all CPC since it's part of the documented firmware interface. Only do it after SCR SET MODE because that one re-registers the event.

I found another, simpler solution: call KL CHOKE OFF#BCC8 at the beginning of program.