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]. The HPEN/LPEN fixes both correct the screen position they're based from. Previously they were taken from the start of the TV scanline, but they should be from the start of the right border area, which is also where both frame and line interrups are triggered. The fix didn't make a huge difference to Defender, but it stopped the main scroller in Geoff's BSD demo from jumping up and down! The older problem with Defender was due to poor instruction timings, which interfered with the HPEN frame syncing. It caused the game speed to be very variable, ruining all Chris's hard work! That's why the infamous anti-emulator code was added, which timed the interrupt period and would only work if it was perfect. Dave Laundon enhanced the SimCoupe core to apply memory contention in the right mid-instruction positions, which fixed the remaining problems with instruction timings. Defender then passed the timing test and the game ran at the correct speed, so everyone was happy. > Support for unresponsive ASIC? Sounds kinda weird :) What's > that either? :) It's something I ran into when testing the initial port and register states when SAM is first powered on. I flashed a custom ROM image (based on the Speccy ROM), but I couldn't get anything to display on the screen. Even after changing it to set the palette and border colour I only got a black screen. It was eventually tracked down to the ASIC being unresponsive after the first power-on. Writes to any of the ports it managed (palette, border, paging, etc.) had no effect, and reads from them always returned zero. Adding a delay to the start of my test ROM cured it, and a further test to measure the unresponsive period showed it was always around 49ms. It may explain the reason for the loop in BC at the start of the real SAM ROM, though Andy Wright didn't remember quite why it was needed. The pre-production SAM ROMs we got from Simon Goodwin lack the BC delay, so they might not work on modern hardware. I changed it to be optional in SimCoupe after Colin reported at least one of his SAMs wasn't affected by it - I've no idea why it would only affect some machines. On the subject of SAM quirks, don't miss the lower border effect in Andrew Collier's Fred 65 menu (ftp://ftp.nvg.ntnu.no/pub/sam-coupe/disks/demos/MNEMOtech/MnemotechMenu65.z ip). Expand the view size in SimCoupe using View -> Border Size -> Large (TV-visible), and look under the main scroller... Si
