Hey blastar. Good to see you back here. I was actually just talking about you on a Neo Geo forum! Was wondering how your robot platformer is going?
I actually found some code yesterday that Razoola had posted in your ChunkyMode thread that waited for a particular display line. So I used that (Thanks Razoola!). Then I ran my code segment and then I made another function to read the display line number after the code had finished. So I will probably use that now. I think this might be more accurate than using colors (it can be hard to count lines with colors). I do like the Job Meter idea though - shows a good representation of how long each task takes,
BTW Is it possible to change background color in middle of a line on real hardware? Because on MAME it only seems to update a line at a time
So can you actually read the timer on the Neo Geo then? It didn't work when I tried it. I checked the tech wiki and it implies you can't read it. It says that reads on Timer-Low and Timer-High are instead mirrors of REG_VRAMADDR and REG_VRAMRW. I was wondering if there is another way to do it?
I have a piece of C code in a loop that could get run maybe 700 times a frame. Eventually i will need to make it fast as possible. So just thinking ahead to when I have to optimize it.
I thought the background color could be used to get an exact reading of how many screen lines it takes up - since it would show partial lines too. It's a shame MAME can't do that, then there wouldn't be that palette ram issue. Oh well...
If it's not possible to read the actual Timer. I thought of a way to get the exact time taken by a piece of code. I *think* this would work
First REG_LSPCMODE could be used get the number of complete display lines taken
Then at the end of the piece of code to be tested set a value in memory to 1. Then repeatedly (over successive frames) run a timer interrupt that interrupts the code at different points on the final display line to check if this memory location has been set to 1 yet. It could be done it in smart way - e.g. first check halfway through the line, then half that distance and so on.
It would be a bit over-kill to program but for very time sensitive routines it would be useful to measure small incremental gains when optimizing them