Some basic ASM issues...

[Jelonertz]

Hi,


I'm doing some sprite tests on my CPC+, and I'd like to understand if I'm doing anything wrong.


I have 6 sprites to build an image of 32x48. The idea is to update the data of the sprites with the new frames, to create an animation.


In order to eliminate the tearing, I do:
1) Install a interrupt handler


INSTALL_INTERRUPT_HANDLER:
di
im 1
ld hl, &c9fb
ld (&0038), hl
ei
ret


2) Wait for the vblank before uploading the new data


MAIN_LOOP:
ld b, &f5
VSYNC:
in a, (c)
rra
jr nc, VSYNC


call UPDATE_SPRITES


jp MAIN_LOOP


The UPDATE_SPRITES is basically to load the 0x600 Bytes of the new frame in to the ASIC RAM...


The problem is I see a lot of tearing, like there is no time to load the entire data during the VBLANK time, maybe?


Any suggestions?


Thanks,
Jelonertz

[andycadley]

A lot depends on the specific timing and how your update routine works. One option on the Plus is to set up a PRI at the end of the screen (or after the last sprite) and use that rather than VBL to time the update. That way you have all the extra time after the screen display too.


It's worth noting that sprites are disabled when they are being updated, which can make tearing worse if timing is tight.

[Jelonertz]

Thanks for your comments.


I'm attaching my source file (lots of improvements to do) so you can see and test what I'm talking about...


I'm using the WinAPE Assembler, and also testing it in a 6128 plus.


Thanks,
Jelonertz.

[McArti0]

INSTALL_INTERRUPT_HANDLER not work always.

0038 is also in LowROM and when LowROM is SELECTED then 0038 in RAM not work.

[Jelonertz]

Hi McArti0,


Do you have any example of how the Interrupt Handler should look like?


Thanks

[McArti0]

I am use this way

Code Select Expand


;factory addres interrupt in RAM (Here jumping RAM 0038 and ROM 0038)
org #B941
DI
JP custom_int_procedure

#org XXXX (bank1 or 2, #3fff - ~#a600)
.custom_int_procedure
...
...
...
.end_custom_int_prcedure
di
EX AF,AF'
JP C,#B978  ;-----
JP #B945     ;----- this 2 jumps continue real factory intrerrupt procedure. (work with 6128)




[andycadley]

If you aren't using BASIC or the Firmware (and if you're messing around with the Plus hardware there is a good chance you aren't), then you can just keep the Lower ROM turned off and simply intercept the IM1 jump point as you were doing. Obviously if you're actually writing cart software you can completely override this even in the Lower ROM itself so you can be much more flexible.

[McArti0]

debug your code by options menu Debug>Registers and Check Row Highlight.
and step F7 your code in the Debugger.

[McArti0]

Why Do You copy 1536 bytes? 


32x48 points in mode 1 (16x48 in mode 0) have 384 bytes. 


ps. LDIR copying 1byte/21clocks


4 000 000 Hz /21 clocks = ~190kBps and in one whole frame (1/50 sec) 3,8kB ...ONLY 


ps2...


and set variable ...

Code Select Expand


ld a, &70
ld (cSprite_x), a
ld (cSprite_y), a


[Jelonertz]

Because in the ASIC RAM, each sprite definition uses 0x100 Bytes. AFAIK you need to define the 16x16 values with a byte corresponding to the index you want to use in the palette.. On top of that, you have to change other sprite properties, like position, maginification, etc

[McArti0]

but 6 sprites update in one frame this is torture for Z80 


check  cSprite_y = 70

[Jelonertz]

Agree... That's why I thought I was doing something wrong...
So, if updating the content of the sprites in a single vblank is so painful (and we have 16 of them), when I look at Robocop2 GX4000/Plus version where the main char is also using probably 6 sprites, and you have several other hardware sprites, like the moving spikes, etc... How do they manage to update the sprites, then?

[redbox]

So, if updating the content of the sprites in a single vblank is so painful (and we have 16 of them), when I look at Robocop2 GX4000/Plus version where the main char is also using probably 6 sprites, and you have several other hardware sprites, like the moving spikes, etc... How do they manage to update the sprites, then?

By using RLE compressed hardware sprites.

[McArti0]

How do they manage to update the sprites, then?

Slower then one frame. RLE not make speed.

you may copy by n x LDI and copy since interrupt near Y place of sprites. this is speed.

[andycadley]

RLE and other techniques work, but they aren't the only way. A few things to get started with that are less complicated:


1) A big long chain of unrolled LDI commands is faster than an LDIR.


2) You don't need to do all your decision making as part of frame flyback. You can separate all that kind of logic out to a less time critical point, wait for frame flyback (or PRI) and then just immediately begin the copy.


3) You don't always have to use the same h/w sprite for the same object on screen. So if you only need 8 sprites on screen, you can use sprites 0-7, then start updating the next frames worth into sprites 8-15. When you're ready to swap things over you turn off sprites 0-7 and enable and position sprites 8-15, which is a relatively simple operation.


Then the next frame worth you repeat the process by drawing into sprites 0-7 while they are off and switch them over when you are ready.


4) If your game doesn't need to update at 50fps, you don't necessarily have to update every sprite on every frame. Sometimes you can juggle things around to give you more time.


5) If you want to get fancy, you can sort your sprites and then use the PRI so that you can wait until one is drawn and then immediately begin updating it, triggering raster interrupts as needed to introduce delays to ensure tearing is avoided. Usually by having the PRI just record the scan position and then the drawing code updating the sprites in Y-coord order but checking the last PRI position to see when it should wait a bit.

[McArti0]

Yet. Jelonertz, You are copying sprites in the wrong order.
Properly order 5,4,3,2,1,0 (From Head to legs). This way you are save time.

ps. Much Much better is have Head in sprites 0 and 1, Legs in sprites 4,5.

[Jelonertz]

Thank you all for your answers...


I fill a bit dumb here, but I prefer to ask... What's PRI? I just started with CPC, so there are tons of things that are popular for you, but still unknown to me

[McArti0]

Look some changing...

1) Screen down one character

2) Sprites Head 0,1 and Legs 4,5

3) LDIR to 6x256 LDI (very long code 512bytes but faster) (uses macro)

in the jpg you can see that sprite 5 was update faster then was plot on screen.

4) use asm structure: Variable EQU number (for magnitude sprite)

[andycadley]

Thank you all for your answers...


I fill a bit dumb here, but I prefer to ask... What's PRI? I just started with CPC, so there are tons of things that are popular for you, but still unknown to me

PRI = Programmable Raster Interrupt


It's one of the enhanced features of the Plus machines. Instead of having six fixed interrupts per frame, with very little control, you can instead set the PRI to trigger when a specific scan line is reached). Since you can re-program the register mid frame it effectively means you can trigger interrupts at whatever vertical position best suits your code.


Even in the most simple case you can set it up to fire just after the "playing area" part of your game and, by waiting for that to occur, then you'll know you've got all the bottom part of the screen, the frame flyback and the top border before you will run into tearing issues with sprites.

[Jelonertz]

Awesome guys!
Ty for all the info...


One last question here... Is it possible in the plus models to redefine the mode 0 palette, or we need to stick to the original 27 colors?


Thanks!

[McArti0]

https://www.cpcwiki.eu/index.php/Arnold_V_Specs_Revised#Colour_palette

[andycadley]

Yes, the colours can be selected from the full range of 4096 colours, however you need to make sure the firmware is out of the way (particularly the interrupts) because it resets the colours at the start of a frame as part of the flashing routine.

[Jelonertz]

Thanks,


Could you please post a brief example showing how to do that? So much to learn yet...

[McArti0]

at work CPC firmware

You must set &b7d2 to &FF,  &b7d3 to &FF,


     6128  ³ 464   ³ Size ³ Comments on the memory locations
     &B7D2 ³ &B1D7 ³ 1    ³ first flash period (SPEED INK - default  &0A @ 0.02 seconds)
     &B7D3 ³ &B1D8 ³ 1    ³ second flash period (SPEED INK - default  &0A @ 0.02 seconds)

AND REGULAR Set flash ink counter in &B7F8. (for example in interrupt)

Code Select Expand


push AF
ld A,&FF
ld (&B7F8),A
pop AF

You may do it in basic.  
And NOW 
OUT &7fb8,&b8   and Your palette inks is in &6400-&6421