On 26 Apr 2011, at 13:47, Geoff Winkless <[email protected]> wrote: On 26 April 2011 13:15, Thomas Harte <[email protected]> wrote: You end up having to contend with the video during the move so you're still talking about significant slowdown. You might get 25fps scroll but that would take most of your bus time, leaving you not much time to do anything else. Quite apart from the significant amount of hardware you'd have to add of course.
The 25fps is based on a hypothetical chip having the same access as the CPU does currently. I also disagree about the significant amount of electronics on the grounds that Zilog's native DMA part cost less than $10 even in 1989, and the z80 has a halt line so the mechanics of pausing it aren't all that complicated. Filled vectors are going to be not a huge amount quicker unless you make the hardware a lot smarter - you'd spend most of your time setting up the external registers to fill objects one line at a time. Based on profiling my filled vector code (not the stuff I've released, better stuff), something like 80% of the total cost is the filling, and something like 50% of the cost of the filling is CPU logic rather than memory bandwidth. So the difference would promote a game of Mercenary graphical complexity from unplayable to playable. Failing that, I really don't think video adjust registers could have > cost that much. So you've a horizontal register and a vertical > register, each capable of taking values in the range 0 to 7 and will > offset the pixel output by that amount on the screen. They're timing > delays on the video output, essentially, but they buy you up to 8 > frames of scrolling with very limited redraw costs, and that gives you > enough time to prepare the next major offset on a secondary screen. If > memory serves, you get a similar thing for free in the 6845 that > appears in the BBC, Amstrad and VGA adaptors. > > What's the advantage over the writable screen-address idea? As far as I can see that involves more hardware and is way more complex to code for. As stated, this is an alternative idea, that occurs in the situation where the screen address can't be made editable for some other reason. There's no programmatic advantage to it, but it shifts the burden to the hardware on the other side of the analogue conversion, giving different options for where you can fit it into the silicon budget. It's only really useful in mode 4 if you need pixel-by-pixel horizontal scrolling. I guess it's useful on the Beeb (and indeed in Sam Mode 2) because there are 4-colour (and 2-colour) modes so byte-by-byte would be 8 pixels at a time. But Mode 2 is just such a horrible hack I pretend it doesn't exist :) Horizontal or vertical, and it (or any of the other options discussed in this thread) would have made the vast majority of early-1990s games implementable on the Sam, making it a better market proposition and hence likely increasing sales by some percentage. Other market factors would have been the same, but I'm sure MGT would have found even, e.g. a 20% increase in sales to be useful. Plus, you know, we'd all have been able to play Strider. For definite.
