Apart from a desire for part uncontended memory (ala the Spectrum) and a hardware scroll, a simplified blitter would have been advantageous (eg, give it start address, end address, length, tell it to go and then it replaces the z80 on the bus until the copy is complete; even with the CPU having to do a lot of lifting around the outside and run some other logic that'd give you a 25fps scroll if that's what you wanted it for, or filled vectors if you prefer).
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. Standard comments about hindsight apply, of course. On Tue, Apr 26, 2011 at 12:46 PM, Geoff Winkless <sam-us...@geoff.dj> wrote: > On 26 April 2011 10:55, Chris Pile <chris.p...@blueyonder.co.uk> wrote: >> >> Mmmm, not sure I would have like hardware scrolling to be honest. It >> would probably >> have meant a glut of scrolling marioesque platform games. Which - for me >> - is a whole >> lot less desirable than infinite ball demos! > > Yes, scrolling platformers become possible, as do scrolling shoot-em-ups > (doing it in Mode 2 doesn't count), but it also means you can open up to > innovative stuff like Thrust and Exile that would never have been possible > on a 2MHz processor. You also get much more responsive text editors, basic > editors etc. > >> >> Some sort of blitter to chuck large blocks of data around at high speed >> would have been >> a *very* nice addition. That 24k screen really is too much for the old >> Z80 to cope with! > > Eugh... _another_ thing to add to Simon's memory contention list? :) > A blitter would have been costly both in terms of electronics and in terms > of memory T-states. When I said "free" I meant it - a single OUT statement > could set the memory start address and everything else would have stayed the > same, with the extra port taking the ASIC equivalent of a couple of sets of > gates. I guess the current screen address currently just gets reset to 0 > every frame - but if you wanted to save the extra electronics required for a > screen address register you could make it so the software had to reset it > every frame interrupt. Actually that's silly, there wouldn't need to be any > per-frame reset logic, just some logic so that when when bits 13 and 14 are > both set they're both immediately cleared (0x6000 -> 0x0000) > On 26 April 2011 10:54, Simon Owen <simon.o...@simcoupe.org> wrote: >> >> Just those two could have made a huge difference to what was possible. >> *sniffs* I do vaguely remember Simon Goodwin explaining why SAM missed out >> on hardware scrolling, but I can't remember the details. I think it was >> something RAM access related, so perhaps the change to use dedicated VRAM >> would have made it easier? As a hardware n00b I've no real idea! Anyone? > > > I don't see how changing the start point within a 24k rolling window would > make any difference to the RAM timing - you still have to access the same > data the same number of times and at the same rate. > My hardware experience is pretty limited though, so I'm not going to start > contradicting Mr Goodwin. > G
