If this works then:
- Grauw is wrong, despite having attached a logic analyser and spent considerable time on it;
- all empirical results which had pointed in that direction were wrong;
- as a result, all existing emulators and everything else is wrong; and
- the staff at Yamaha weren't very smart.
In that scenario I guess the conversation at Yamaha might have gone something like this:
"Hey, shall we use all of the available memory bandwidth to offer more colours and/or pixels of output?"
"No, let's just read the sprite attribute table four times"
"Oh, cool, so if we've enough time to read 128 entries from the sprite attribute table, shall we offer a 128-entry sprite attribute table?"
"No, we'll just reread the same entries several times."
"Umm, okay. Then shall we allow for reuse of sprite output shifters opportunistically, sometimes to break the eight-a-line barrier?"
"No."
EDIT: courtesy of Grauw, Wouter, et al's very hard and generous work, here's the access timing for both the Yamaha VDPs and the TMS, per line from a follow-up article:
So, same comment as before:
See Grauw's timing documentation. If you're in a bitmap mode and have reached cycle 130 then sprite locations and contents have been locked in for the line that is about to be serialised. There is no means to change any aspect of sprite output for that line after that point. You are going to get at most eight sprites displayed on your line, full stop.
There seems to be a disconnect here; people that achieve great things on 8-bit hardware by pushing boundaries do so by understanding how the hardware works and using it ingeniously. This is very different from just denying reality.
- the sprite attribute table is read only once per line;
- you cannot get more than eight hardware sprites on a line, because:
- the sprite attribute table is read only once per line.
Note I didn't write the VDP timings article, I just host it on the MAP to give exposure to this great resource. The real research was done by the openMSX team and wouterv in particular.
About more than 8 sprites per line, I don't think it is possible, you can see in the chart when exactly when each sprite coordinate is read (in advance for the next line). With my understanding of the VDP I see no way to surpass it. However by all means give it a shot, you either make a fantastic new discovery or you expand your knowledge, both are good things 
.
Note I didn't write the VDP timings article, I just host it on the MAP to give exposure to this great resource. The real research was done by the openMSX team and wouterv in particular.
About more than 8 sprites per line, I don't think it is possible, you can see in the chart when exactly when each sprite coordinate is read (in advance for the next line). With my understanding of the VDP I see no way to surpass it. However by all means give it a shot, you either make a fantastic new discovery or you expand your knowledge, both are good things .
Obviuously there is no way just because of the reasons you pointed.
But let TomH to try hard. Everyone has the right to believe in fairy tales. ;-)
I fully agree. Deciding in advance that something is impossible deprives you of the opportunity to discover something new. Extensive knowledge of a subject can certainly show that it is very unlikely, but experimentation often produces unexpected results.
Some one might have said scrolling the screen in 2 directions at once is impossible because he didn't think of that one thing that was documented wrong. And all that blindly trust that experience wouldn't even have tried it.
So keep experimenting! And except to be very wrong very often!
