Waiting time for firmware to change colors

[Joseman]

Hi guys!

I'm doing some piece of coding of 2 loaders  for 1 game (will tell you more about this game), i've a question about firmware changing colors...

This behaviour happens on other loaders of mine and, when i read official loaders they seem to aproach the problem with different timings and codings, If i change  colors with firmware and i don't do a loop wasting time, then it's clearly visible on the screen what i'm doing if i'm writing to the screen for example. This behaviour is obviously the time that the firmware takes to change the colors and other code runs before the change is finished.

My question is: what's the correct timing to waste before doing other things waiting for the firmware to end with the color change?

Thankyou!!

[arnoldemu]

Hi guys!

I'm doing some piece of coding of 2 loaders  for 1 game (will tell you more about this game), i've a question about firmware changing colors...

This behaviour happens on other loaders of mine and, when i read official loaders they seem to aproach the problem with different timings and codings, If i change  colors with firmware and i don't do a loop wasting time, then it's clearly visible on the screen what i'm doing if i'm writing to the screen for example. This behaviour is obviously the time that the firmware takes to change the colors and other code runs before the change is finished.

My question is: what's the correct timing to waste before doing other things waiting for the firmware to end with the color change?

Thankyou!!

I can't remember if it depends on speed ink or not.
firmware has two palettes to do colour flashing. speed ink defines the time between changes to make the flash.

I can't remember if you need to wait that long or it will refresh the colours always.

If you are not using flashing colours then you need to wait for the first time it sets the palette.

try this first:

Code Select Expand


ld b,2 ;; number of vsyncs
wait_col_change:
call mc_wait_flyback ;; wait vsync
halt
halt
djnz wait_col_change


mc_wait_flyback returns true if vsync is active, or waits until it becomes active. the two halts makes sure the vsync has completed, so that second time through the loop it waits for the start of vsync correctly.

2 vsyncs: one time you may see vsync but it hasn't used your colours yet, second time it should use them.

If this doesn't work use firmware functions to change the speed ink rate (e.g. 1,1) and then use the code above.

Code Select Expand


scr_set_flashing equ &bc3e

ld h,1
ld l,1
call scr_set_flashing


[Joseman]

Hi arnoldemu

It's working!, for the moment the loaders with your code doesn't seem to replicate this behaviour.

The problem was that... sometimes my code was working sometimes not, in the same loader and game!!, I suppose depending of the situation of the disc drive motor and the delay to read the data...

I wanted to know the exact time for the wait and your code seems right!

Thank you!!

[TFM]

... If i change  colors with firmware and

Well, just don't do it! Disable interrupts and do it by hand.


If you want to use the firmware, then don't waste time with a loop. Just...
- Do firmware color change
- Write color values to &7Fxx to change colors immediately.
This way you can leave the firmware intact, interrupts working and you don't have to wait.

[Joseman]

- Do firmware color change
- Write color values to &7Fxx to change colors immediately.

But the number color data is not the same, this means that i have to traslate 2 times de color number, or there is any calculation to convert a firmware color directly to hardware color?

[TFM]

That's right. You need a conversion table, but that's not a problem, it's only 27 bytes long.


This table should be somewhere in the cpcwiki... here we go:


Gate Array - CPCWiki