Sprite Parsing Timing and MAME Question - Page 1

I have a couple of questions I need help with. Thank you

1) I made a simple raster effect on the Neo Geo (using the Dev Kit) where I change a sprite's x and y position down the screen. I am using MAMEUI32

I noticed when I updated the y position register to move the sprite AND at the same time updated the height value to 0 to turn it off (I did this as a test). It moved and displayed the sprite but didn't turn it off until the next line. Is this correct on a real system? To sum up - if i want to turn a sprite off, do I have to turn it off a line earlier?

Also If this behaviour is correct are there other sprite attributes that must be changed at different times? e.g. the character to be displayed or color palette, zoom values etc

2) I am using MameUI32. The version that came with the devkit. I tried to use a modern version of MAME : MAME_64 but it wouldn't recognize the modified puzzledp ROM that the devkit outputs. How can I make it run it anyway on MAME-64? MAMEUI32 will let me run the ROM anyway

I'd check that you're even allowed to change the sprites during the refresh on the real hardware, I don't do Neo Geo dev but I remember to have read that some attributes are latched and it made multiplexing difficult.
However as far as other retro consoles go, it's normal to have to wait one line, the hardware is rendering in the line buffer a bit in advance, and sometimes even fetching the sprite attributes even further ahead

Hi Brunni. I *think* you can you change everything - because the graphics chip reads the sprite attributes before rendering/drawing them. I know you can't change palette RAM outside of a vertical or horizontal blank though or it messes up the display

I have now found from the tech wiki that parsing is done at line n-2. That makes sense for switching the sprite off. But it says rendering (into the line buffer) is done at line n-1 but that is the one where in MAME it seems you can change the X and Y positions of the sprite. Perhaps MAME is not accurate? Actually thinking about it now, I am not counting the lines in a very accurate way! So more likely my calculations are off. I'll do some tests

This is what the tech wiki says for rendering (below) so it should be possible to change all attributes of a sprite on the fly

Rendering

Read active list ($8600+ or $8680+) to get sprite #
Read SCB2 zoom values ($8000+)
Read SCB3 Y position, height, and chain bit ($8200+)
Read SCB4 X position ($8400+)

The tile # and its attributes are also read from slow VRAM.

It's hard for me to test on real hardware at the moment. But that's a good idea for the future. I do have a Neo SD. I could probably do it with that.

Good news! I got my virtual cart to run on MAME64 and it behaves exactly the same as MAMEUI32

I have done some tests on MAME (checking the vertical beam register) and this seems to be correct from the tech wiki (which I have now found). I made a mistake because the first line of my raster routine was not being displayed and it threw my line counting calculations off

Parsing for a raster line N is done during line N-2
Rendering is done during line N-1
Finally the line is ready for output just at the right time.

But it seems like I can still change values *during* each of these lines and still have them accepted which is strange to me. e.g I can still change the ypos + height during line N-2 and the X and Y values etc during line N-1 and then they will be accepted so that the line displays on line N just fine. This confuses me

I am new to this though so I could be misunderstanding?

I'm sure MAME will not be exactly the same as real hardware anyway. I will just get on with the coding now and play around with it until it works