Code instrumentation is a subject that’s discussed constantly in Oracle-land, probably because Oracle’s server is instrumented pretty well. Once you’ve debugged or tuned an application with embedded instrumentation code you can never go back to just guessing – it’s too frustrating.<\/p>\n
<\/p>\n
Every now and again it occurs to me that there are some aspects of software development that have always been important and will remain important no matter the operating system, language or application. Instrumentation is one of those aspects. At the danger of appearing to make light of the subject (which I am definitely not) I’m often amazed by the similarities between the issues and solutions in old-time 8-bit machine code programming and the much more complex software and hardware environment we work with today.<\/p>\n
<\/p>\n
One of the key challenges in ZX Spectrum game programming was the avoidance of graphics flickering on the screen during play. These days I assume it’s much easier with the prevalence of dedicated graphics chips and the like, but the only way to display game graphics on a Spectrum was to take some numbers containing the bitmap images and copy them (quickly) into the memory locations that were mapped to the screen. The trick was to avoid being part of the way through copying the graphic as the raster (the thing in the TV that displays the image) passed through that location on the screen. If the two interfered – ‘flicker, flicker’, as my mate Joffa used to say.<\/p>\n
<\/p>\n
There were lots of different approaches to this problem, but what tended to be consistent was the attempt to do as much work as possible in the time between the raster hitting the bottom of the screen (when an interrupt would be generated) and the raster reaching the top of the displayable area (excluding the border). So what we did was write an interrupt service routine to display all of the graphics and that would be automatically invoked when the screen had been refreshed. The screen draw routine would work frantically to try to have everything redrawn in (and I hope I remember this correctly) the next 14200 T-states or processor cycles during which the raster flew back to the top of the screen and drew the top border area.<\/p>\n
<\/p>\n
So what’s this got to do with instrumentation? Well, how were we to know where the raster was on the screen when a particular bit of code was executing – which was crucial? We simply changed the border to different colours (which was a very light-weight instruction) so that we could see on the screen just how far the raster had travelled down it at a particular point in our code. If the colours started to indicate that we were straying into the displayable area, there was a chance of flicker. Simple but extremely effective! It was also a great way of seeing the ‘profile’ of your code – which bits were taking too long<\/p>\n
<\/p>\n
On a side-note, this is also the reason why you’ll quite often see Spectrum games try to put as much static high score information and the like at the top of the screen, to give the programmer more time to display the playable area 😉<\/p>\n
<\/p>\n
P.S. I’m posting this via email – hope it works kay.<\/p>\n","protected":false},"excerpt":{"rendered":"