At 5:59 pm +0100 23/9/99, Ian Collier wrote: >Here is an experiment. I'd do it myself if I thought there were any chance I >would get round to it before the Millennium... > >Have a counting loop, say "lp: inc bc; jp lp" (note that this takes 20 cycles >off-screen and 32 on-screen). > >Have an interrupt routine which says "pop hl; ei; ret".
Actually you mean "pop hl; ei; nop; ret" We know that the interrupt line stays active for a lot longer than this code will take to execute. The extra nop after enabling interrupts ensures that we get the next interrupt before executing the ret (if we execute the ret and then get another interrupt then we eat up our return addresses and die). Unfortunately it now means we spin round the interrupt handler for a hundred t-states or so, so the numbers we might get out of the counter loop are potentially bad. >Now push a return address, push the address of the loop, set bc to 0, enable >interrupts and halt. The first interrupt will cause a jump to the counting >loop, and the next one will cause an exit to the return address. There you >return the interrupts to normal and print out the value of bc. > >If the screen is off we expect an answer in the region of 5989. Someone >else can calculate what we expect when the screen is on, but more >importantly the answer gained in mode 1 will probably allow the contention >behaviour to be inferred. FWIW, here are the numbers I get - but note the issues above if anybody bothers with the calculation... Frame interrupt -> Frame Interrupt Mode 2 - 4, Screen on : 5049 Mode 1 , Screen on : 4291 Mode 3 - 4, Screen off : 5983 Frame interrupt -> Line Interrupt @ 0 (I'm assuming gives 60 lines of border) Modes 2 - 4 : 1298 (screen off or on gives same result) Mode 1 : 1015 HTH Andrew -- -- Andrew Collier ([EMAIL PROTECTED]) -- My other -- http://mnemotech.ucam.org -- .sig is a -- Part 3 Materials Science, Cambridge -- PDF file --
