For me, I am happy to share my opinion or knowledge on topics like this, but what someone else does with that is up to them. If they want to do a test anyway, who am I to deny that. I can respect not taking people at face value without fully understanding and/or confirming it myself.
For the same reason, when someone finds some new information, I want to have full understanding and sufficient confidence that it is indeed correct before adding it to the MAP , so that I can stand fully behind the information and aren’t spreading new misinformation. For example, in the YJK article I haven’t updated the formula for rounding the blue component yet because I want to first test and confirm it myself, even though I’m already 99% sure of the outcome.
So I don’t see why we would need to deride people for wanting to do some tests.
I used to do alot of lab work and once I required to synthesize a certain compound. It could not be done. The articles said it could not be done and all the evidence suggested that it could not be done so I had a stupid hunch. I just tried it because ohw well socl2 is not that expensive anyway. Got the compound against all odds. We could not explain the effect so we never published the method but up to this day thats how they would make the stuff. This was not the first time it would happen. I have seen alot of absolute stupid against all egidence **** in the field. Wierd stuff like that happens all the time and does not get explained. It is very rare but it does happen. It doesn't mean it happens alot though. Had stupid hunches before leading to zero results but out of the 200 hunches thats particular one got me somewhere. So yes still ultra skeptical but open for unexplainable results that people sometimes call a miracle.
The difference here is that the VDP is a fully-deterministic human-designed system. The rules were designed and completely known by a single human being, unlike nature where we just figure out what we can.
I don't think I have anything else to add, other than that I'm 100% certain on the validity of the line of thought: (i) the VDP runs at six times the clock of the Z80; (ii) therefore it obviously must reload the sprite attribute table four (?) times for, errr, some reason (umm, but I guess not on a Turbo R because on that the clock multiple is different); and (iii) somehow this isn't visible when directly observing the bus with a logic analyser.
Yeah but maybe (there probably isn't, but maybe) there was a mechanism that could fool the VDP into forgetting it already read the sprite information, so it reads it again. That idea wouldn't be that crazy. Just like the VDP not noticing the start of the border if you change the screen height just before it reaches it. In "normal" operation this would never happen but with a few well timed events you can trick the VDP into doing something it shouldn't be able to. Displaying pixels in the border area even when all official manuals tell you that you cannot do this.
So yeah, this "multi sprite trick" is very probably not possible but a lot of the tricks used in demo's are based on undocumented features/glitches of the hardware. So a "fully-deterministic human-designed system" can still show some strange behaviour if not every conceivable option was thought of in advance. Or maybe it was thought of by the designer, but he/she didn't think it would be an issue.
Even after 40 years I believe some secrets are still to be discovered on MSX. Even in the VDP.
Yeah but maybe (there probably isn't, but maybe) there was a mechanism that could fool the VDP into forgetting it already read the sprite information, so it reads it again.
I'd be stronger than "there probably isn't" but to the main point: reading the sprite attribute table plus the contents of the selected subset of the sprites it describes costs 80 bytes. The Yamaha VDP is smart with paged-mode accesses though, so that's achieved in only a net total of 360 cycles even though fully-random accesses would cost six cycles each.
360 cycles is more than a quarter of the budget for a given line. It's more than 50% of the time dedicated to fetching pixels.
Where do you think the extra 360 cycles is going to come from in this magical world where a sprite table reload were somehow forced?
(And, briefly, back on the nonsense that the VDP probably reads it four times anyway: it wouldn't even have time to, even if there were no pixels or external slots)
The principle that there are still unknowns, one of them probably does something interesting is all well and good, but it's crazy to deny the things that are known in pursuit of logic-breaking wild-goose chases.
I didn't had the courage to read all the pages in details, but I don't understand why people who think they can overcome the MSX2's limit of 8 sprites per line don't simply make a technical demo to validate their theory? ¯\_(ツ)_/¯
I don't think I have anything else to add, other than that I'm 100% certain on the validity of the line of thought: (i) the VDP runs at six times the clock of the Z80;
OK. that's does not prove anything, only that the external clock is faster than z80 one. External bus operations could be even slower.
(ii) therefore it obviously must reload the sprite attribute table four (?) times for, errr, some reason
Obiously ? What is the reason? to flex the muscles? ;-)
there is a timing diagram out, obtained with a logic analyzer placed on the bus pins, that fully proves that your assuptions are wrong. And contrary with your assumptions those probed datas are a a fact, objective things.
and (iii) somehow this isn't visible when directly observing the bus with a logic analyser.
What a logic analyzer record is what is happening on the bus. there is no a fancy visionary and invisible action taking place here. Just what happens.
I didn't had the courage to read all the pages in details, but I don't understand why people who think they can overcome the MSX2's limit of 8 sprites per line don't simply make a technical demo to validate their theory? ¯\_(ツ)_/¯
Because simply a similar demo would not work because it is simply impossible given the vdp architecture to overcome this limitation.
OK. that's does not prove anything…
I’m aware of these things, just summarising the logic presented which is causing so many other people to respond with “oh, don’t be dismissive, who knows?” and other such polite equivocations with which I disagree.
For me the work hosted by Grauw establishes definitively that eight sprites is your lot, and I’m surprised by the degree of what I consider magical thinking that others seem to be willing to engage in.
