> Simon Owen wrote: > Simon Cooke wrote: > > Interesting... Defender uses HPEN/LPEN... any idea how it > > uses it? > > It uses HPEN monitoring to track whether it's running late with the current > frame. I believe it still expects to be over the main screen area after > completing certain tasks, and if it's into the border it runs straight into > the next frame without waiting for the frame interrupt to be signalled in > the status port. The game uses the stack for lots of the drawing > code/lists, so runs with interrupts disabled at all times [you can confirm > that in the SimCoupe debugger by pressing U for 'execute until', and > entering 'ei' for the expression - the breakpoint will trigger next time > interrupts are enabled, which never happens].
Simon's explanation is correct. I will expand (from memory!) why I used this method: As we all know, the SAM is *seriously* underpowered. To ensure Defender ran at a constant (99.9% of the time!) 50-fps, all available horsepower needed to be squeezed from the old Z80! Often the fastest way to shunt data around is via the stack, so I used the stack to dump/erase sprites and also used a stack-based linked list for the world entities. The landscape also uses a stack-based dumper, this pops off a value which is added to the current landscape pixel position, moving the position either up, down or up/right, down/right. The mini-landscape used in the scanner is processed in a similar way. Even the 16 background stars are processed using a stack-based routine! Couple this with plenty of code unrolling, in-lining of graphics data and also screen-line interleaving of sprite dumping the game holds on to the magic 50-fps. With so much stack activity occurring, often in crucial data areas, any unexpected interrupts would be a disaster. So Defender runs a constant DI state. This is fine, but introduces the problem of frame-syncing via the v-blank interrupt. Because of the DI state it is not possible for Defender to trap the v-blank interrupt. Instead, a simple polling loop on the status port has to be used. Again, this is fine if you can complete all in-game processing before the next v-blank. Defender does (just!) for 99.9% of the time. This is where the problem lies. If you miss the v-blank, but you still wait in the status polling loop after all in-game processing, you effectively "see" the next v-blank and not the one you really wanted to see, because you missed it! This has the effect of dropping the game to 25-fps visually, and halves the speed of all sound effects. This is so very obvious to both eye and ear!!! Unacceptable! As Defender only just misses the frame v-blank when things are hectic on-screen it was totally unforgivable to allow the game to stutter to half its speed, ruining both the game and its playability. The solution was not to wait if we had missed a v-blank, but simply continue processing the next game-loop as if we had just seen a v-blank. This is simple if you can set a flag on a v-blank interrupt. In Defender's case this is not possible, so an alternative method for detecting missed v-blanks was used. Enter HPEN! Put simply, I read the HPEN value after processing approximately 50% of the in-game functions (50% *never* misses v-blank) and then read it again after all in-game processing is done. Then a few calculations determine if we missed the last v-blank. If so, then don't wait for a v-blank and simply blast into the next game loop. The effect is a slight visual stutter on missed frames, and no real change in the sound effects. 100% preferable to the 25-fps visual drop and audible slowdown of all effects! In fact, the visual stutter is almost exactly the same as the real Defender machine when it, too, misses frames. The exception being that SAM Defender doesn't bother "hyperspacing" entities off-screen on missed frames, which the real Defender does when it trys to claw back some precious CPU time!! ;-) Job done! :-) Chris.
