|<< Newer||Article #104||Older >>|
Picking up from my last article on blitters, the next thing I was going to talk about was how to time a blitter. At a rough guess, if you have schematics handy, you can look at a blitter chip and do an approximation of how long a blit will take. A blitter chip, like a CPU, needs a clock, so that's a good starting point. For example, the blitter on the classic Williams games (Joust, Robotron, etc) runs at 4MHz. That means it's going to be limited to 4 million operations in a second.
But you can go beyond that. If you look at the width of the data bus that the blitter has, then you can tell how many bits it can operate on at a time. The Williams blitters have a 4-bit bus, and there are two of them running in parallel, so that's 8 bits per operation, or 2 4-bit pixels.
Taking the guessing game one step further, if there is only one address bus on the chip (as is the case for the Williams blitters), then it can't read graphics data from the source and write to a target at the same time. In fact, it will need to constantly swap back and forth between the source address and the destination address. So, assuming that it takes one clock to read a source byte, one clock to swap to the target address, one clock to write a target byte, and one clock to swap back to the source address, you're looking at 4 clocks per operation.
So, putting all this together, I'd have a first guesstimate that the Williams blitter could handle (4000000 clocks / 4 clocks per operation) * (8 bits per operation / 8 bits per byte) = 1 million bytes per second, give or take. So that's the ballpark to expect. I'm currently working on an update to the early Williams games that will factor this in, in the hopes that Robotron might slow down enough to match the arcade (a number of folks have noticed that Robotron runs too fast in MAME at the higher levels).
Of course, the ideal situation would be if we could measure this directly. Unfortunately with the Williams games, there's no obvious way to do it because the blitter HALTs the main CPU while the blit is happening, in order to gain full control over the systemwide address and data busses. If I had an oscilloscope and a PCB to play with, I could probably do some measurements that way. But there's no obvious software path to do it. (Okay, I lied, there is one: I could program the sound CPU to measure the timing, and then send start/stop signals to the sound CPU just before/after the blit is done. That might be worth trying.)
Fortunately, most later hardware that used blitters decided that it didn't really make sense to suspend the main CPU while a blit was happening, so they were designed to operate in parallel with the main CPU. These are generally known as an "asynchronous blitters". The Incredible Technologies blitters are like this. The nice thing is that this setup makes it relatively straightforward to measure how long blits of different sizes take to complete. Having done this now for the 8-bit IT games, I'll describe the gory details in my next blitter-related post.
Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/aaron8/public_html/index.php on line 34
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/aaron8/public_html/index-html.php on line 87