[roondar]

Originally Posted by VladR

Yeah, I just noticed that HRM mentions the following:
So, since I won't be using disk during frame, I should have 3 additional DMA cycles available per scanline, right ? Meaning, if there is no sprite, 68000 will get those 3 additional DMA slots (assuming no other higher-priority device wants access) ?

Well... Yes and no.

Yes, those cycles are now technically available to the CPU
And no, the CPU could already interleave with disk or sprite DMA in such was no cycles appear to be lost (i.e. the disk DMA cycles slot into the cycles the CPU is not on the bus in the first place).

Sorry to harp on about it, but it's all about interleaving. The 68000 normally only accesses the bus every other DMA cycle (this is not quite 100% true, but it's true enough for our purposes). The cycle it doesn't access the bus, it's doing internal stuff. It looks a bit like this:

68000 solo:
C-C-C-C

68000 with refresh, disk, sprite or audio DMA:
CDCDCD

- = no memory access
C = CPU access
D = DMA access

So in these cases the CPU technically can't access the bus all the time because other DMA is active on certain slots. But, due to the CPU limits for accessing the bus in the first place it doesn't actually slow down due to these forms of DMA access.

Perhaps it's helpful to remember that Sprite, audio, disk and refresh DMA cycles occur at set times during the scanline and never overlap one another, so CPU interleaving stays possible all the time.

So, even at HiRes:4bpl, looks like I still get 16 Sprite slots, meaning I can still have 8 sprites at any scanline ?

Yes, assuming you're not using horizontal hardware scrolling or horizontal overscan this is indeed correct - you get to use all 8 sprites.

Yeah, I was looking for a ballpark figure, and this is definitely way more precise than a ballpark
Not to mention that it will be a feat if I even get an average of over 50% of CPU cycles during DMA lock-out

Yeah, sorry.. I'm kinda like that

Besides, since I want a 30fps lock, I will have to reserve a CPU Spike buffer of at least 20-25% of a frame time - e.g. somewhere around ~40,000c, which will be burned by WaitTOF () to make sure the game is always smooth.
I could probably accept a very occasional framedrop, like one framedrop in 5-10 seconds, but no more than that.
..snip..
updating 30 squadrons each frame would certainly kill a lot of cycles...

It's certainly going to be a challenge. Will be interesting to see how viable it ends up being. Would be pretty awesome if it worked!