> Umm... Well you can't read and write the same byte in the same cycle; but > you're right, if the 79000 frames figure is correct that would be usable. > However I'm not sure it is: system clock is 6MHz, so 6M T-states per second, > that's 120,000 every frame (6M/50). That's about 30,000 memory cycles in > screen-off. > If you were going to invest in significant graphics hardware you'd be better > off with scalable hardware sprites that aren't in system memory at all and > having a 4-colour screen and using full 128-colour sprites for the > interesting stuff. Admittedly they don't help you with 3d but at least you'd > have half the memory to move around and half the contention to worry about. > G
Well, no, that's why I costed for doing the full screen twice in two frames — a read and a write, plus some useful CPU time (even after drawing a new row or column of pixels so that it's a scroll), at 25fps. Though I think your main point is correct; if graphics ability were the main objective then you'd be looking at a quite different route, not a bunch of little tweaks or minor additions. And we're told that a selectable screen start address was considered but not possible in the current design, so the real question is what else do you jettison and how do you do it within the constraints beyond mere final manufacturing cost. It's an interesting thought experiment, but it is predicated on one particular aspect being elevated in importance in such a way as to violate the original design goals. Vaguely related: has anybody here ever played with one of those FPGAs?
