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!!
Quote from: Joseman on 14:17, 03 December 14
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:
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.
scr_set_flashing equ &bc3e
ld h,1
ld l,1
call scr_set_flashing
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!!
Quote from: Joseman on 14:17, 03 December 14
... 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.
Quote from: TFM on 23:20, 03 December 14
- 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?
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 (http://www.cpcwiki.eu/index.php/Gate_Array#Palette_sorted_by_Firmware_Color_Numbers)