Feature Request: Suppress wait_recal call and immediately start executing dpram

[jaymzjulian]

Essentially, an advanced flag to NOT call wait_recal if, for some reason, I know better - the use case I'm doing is, for example, on the vxtron32 title screen I'm manually balancing two different dpram pages - one of which is very fast to execute (indeed, does no line drawing) but was causing a ram overrun. 

Currently I solve this by setting the framerate really high - but you actually can't go higher than 150fps, afaict (at least, when i set framerate to, say, 400, and request it back, that's what I get), and really in those cases i'd rather it not be called at all - i.e. i want to always call it on my first WaitForFrame call, but not necessarily again if i'm calling it a second time to deal with an error state or such like.

If only rom wasn't rom, i'd just nuke it myself with a codesprite

[Vectrex32]

Have you measured how much time the fast drawing list takes, i.e. by measuring the time you spend in WaitForFrame() and subtracting it from the frame rate?

[jaymzjulian]

I have measured this (i don't have my numbers to hand right now but I can post them later when I get near my vectrex) - I actually originally thought this was the problem, so I replaced it with a single nop codesprite.

It's not actually a problem in-game of vxtron, as an aside, because that timer has always run out when that happens - which is why I never requested this before - because even the smallest display list that actually draws things will take more than that couple of ticks that you get at 150fps.

How this came about, is that I noticed that the case of shoving the music load/store into a seperate codesprite flicker than I expected, and found the need to instrument it, since I thought the problem might be my codesprite.  Now, I don't know beyond that _where_ the sausage is made - it could well be the "shoving the display list into dpram" taking the wall clock time or such - since the code is approximately:

ClearScreen
CodeSprite(loadstore)
--> this one will _always_ take real wallclock time, because it has to wait for the last one to complete!
WaitForFrame           

--> gettick
ClearScreen
draw title
draw bg
draw menu
--> print now-gettick (always either 0 or 1, depending on where in the phi it falls )
WaitForFrame
--> print now-gettick2 (this actually does return within 0 or 1... which makes sense)

[Vectrex32]

I'm not sure I understand. You're sending music data to the Vectrex, and that's filling up the DPRAM? I presume you're sending many frames' worth of music at once?

- Bob

[jaymzjulian]

I'm not sure I understand. You're sending music data to the Vectrex, and that's filling up the DPRAM? I presume you're sending many frames' worth of music at once?

- Bob

I'm sending the music data separately because the rest _barely_ fits in dpram - it is sending 3 frames worth, which is 42 load/stores, which should take somewhere around 168 6809 cycles, but also around 210 bytes. (compare and contrast with any line draw, which while only a few bytes, will often take _way_ more cycles .  A 150fps wait_recal will take around 50x that wait time, of course.  I ended up losing significant visual fidelity when trying to send these two in dpram together, and am trying to avoid the far more complex code case of doing dynamic management of this for a simple case - after all, freeing 210 bytes of line draw requires removing around 40-50 lines, which is significant!

This is, obviously, def one of those not a deal-breaker corner case things - my theory was "don't call the unnecessary thing when we know we don't need it right now" should be a fairly easy flag to have exist, and one that i assume people wouldn't poke without needing to anyhow.  But, if it's actually a pain, i can live without it, obv - and am living without it .