It seems to work on the TMS 9918 but it's buggy on the TMS 9928 and TMS 9929.

And, don't forget, that not all MSX1 have a TMS. For example, the SONY HB-10P has a Toshiba T6950 instead; so you can't do things like mix mode here.

This topic has been talked several times through the years. I can't find all the post about that; do the research if you want to. In one of them it was pointed out what I told you before about the 9928 and 9929.

Also, there is a user who spotted a MSX1 which didn't check the 5th sprite flag properly. It's not so a strange computer but a SONY HB20: Page 6 of this thread. There, it was said what I have already told you, that the flag which detects the fifth sprite was not compulsory in the beginning for the MSX1 computers so some brands, like SONY, used another VDP instead of the TMS; detecting the 5th sprite is not a "must" for the computer for being a MSX1. Having at least 8K RAM, a Z80, 1 or 2 Joysticks, etc ... is compulsory; the 5th sprite flag, not.

In the last comment I said -adding some more information to this topic- that there are more issues with some MSX1 computers, like the (in)famous mix mode. I am not mixing anything here.


If discussing a topic about MSX compatibility / programming, in which I am VERY MUCH interested, is a "totally dull conversation" for you, what are you doing in this forum?

TMS is no official document for MSX at all. The ASCII Technical Handbook is the official one: read the standards there.


That a MSX machine doesn't have a feature like the 5th sprite flag and another one (most of them) does have that feature doesn't mean that the first machines are buggy. Your code is buggy, since it doesn't work in all machines which are 100% compliance with the MSX standard ASCII established.


Again, those early MSX machines are not buggy. If you know that some features were improved in later MSX machines and you code only for them, you are creating something which doesn't work in all MSX machines, obviously, you are coding something not 100% MSX compliance.


My first message to you was: "Hi, AR. We had this discussion in 2006. I think the 5th SPRITE rule is not 100% MSX compatible: there some issues with some MSX1 (with 9928 and 9929)."

I wanted to bring some light/new perspective, since this topic has been very deep discussed here in the past years. Maybe what some users said was not properly proved and you did. I have some games myself which use the mix mode (my code is buggy in some MSX1 machines since I am ignoring those MSX1 which are 100% ASCII MSX compliance but doesn't have that later feature) and if the 5th sprite works on most MSX machines, I will use that instead of the synchrocode I am using now for a little slpitscreen. Obviously, you decided to take the conversation to a non productive field.

You are mixing topics here: standard (that was my only interest: a "it doesn't work in all machines but in most of them" would have been great) vs MSX practices. You are putting words in my mouth I didn't say: "you are mixing msx standard definition with what you think should be the good practices". I tell you, you are completly wrong. I don't think coding following only the standard should be the good practice. You said that; I never did.

As I said, asking a technical question about programming/hardware, in a MSX forum, in the development thead, is not a "totally dull conversation". Something you already said twice.

You can end your messages with "Sorry, IMHO (in my humble opinion)" but you are still being unpolite.

In the Technical Handbook it's said TMS9918. In the TMS9918A, which is an improved version of the TMS9918, the 5th sprite flag is already listed. I just can't find the datasheet of that first TMS9918 (TMS9918A with less features).

Related topic: I have just had a look at another ASCII book, the MSX Technical Data Book English version, 1984. And in page number 10, under MSX hardware specifications, where the MSX standard is, it is said"CPU Z80 compatible (...) 1 WAIT in M1 CYCLE", which would leave undocumented instructions with the registers IX and IY out of the standard, since they take 2 cycles in M1.

Back to topic. If we ignore these last messages and go back to what I wanted to know: did you (you and friends) test this feature in several (many?) MSX1 computers. As I said, I would like to implement this if it works on most (not necessarily all) of the MSX1 machines.

Dioniso
Just a contribution

http://www.msx.org/forum/development/msx-development/msx1-vdp-statusregister-details

Do you know what does not work properly on status register of 9928/29 ?  Is it bit 6 or the bits 0-4 ?

Normally, reading the status register during the tracing of the active area returns the last sprite plane processed if the 5th sprite flag is 0, or the last 5th sprite plane found if the 5th sprite flag is set.

Ideally you could not poll bit 6 at all, before swapping the two SATs.
You only need to know how many sprite planes are used in the upper part on the screen and wait to read that value in bits 0-4 of the status register.
In any case, you will miss the right split point if by chance you get with 5 sprites on the same line somewhere in the upper part of the screen, as the plane counter will stop, reporting the last 5th sprite plane.

Said that, for managing tons of bullets on the screen, a quick an safe way is to accept some controlled flickering and go for sprite reversal.

If you want up to 64 sprite on the screen, create a SAT with 64 entries in RAM and copy it to VRAM on Vblank from the top in odd frames and from the bottom in even frames.

If you have less that 64 valid entries in the SAT in RAM, you could arrange things in order to have flickering only for bullets (just place them at the beginning and at the end of the virtual SAT).

E.g. you can have
- bullets in plane 0-15,
- enemies in planes 16-31,
- bullets in planes, 32-47
Enemies will not flicker while the 32 bullets will appear in alternate frames

This allows also to have more than 4 sprites per line.

Clearly not a compatibility issue rather anything ranging from hw bug to not reliable verification of the issue.
TMS clones support 5th sprites and even TMS doc say about this.

In the ascii docs there is TMS or EQUIVALENT but equivalent means that is functionally interchangeable by definition so if TMS support 5th an equivalent of TMS MUST ALSO support 5th flag

Conclusion: your discussion is a non-sense. Instead an ipotetic TMS like chip that does not have 5th flag feature IS NOT standard by definition.

update:
I've just tested: there is no need of 5 sprites on the same line to do a clean screen split.

It is sufficient to place one single sprite on a known plane as placeholder, say plane 31, and poll the last 5 bits of the status register.
This latter keeps counting the processed sprites, and even if it shows the last plane where the 5th sprite condition has happen, it is sufficient to read it twice to get the actual number of processed sprites.

In the end, willing to use two sats, you can show up to 31+32 sprites at the same time
If you place your placeholder on plane 31, in the ISR routine you have to poll for that value in the last 5 bits of status register before swapping the sats.




The sacrifice of the last sprite from the upper SAT is worth of extra 32 sprites.

x Dioniso
I'm pretty sure that all the chatting about status registers and 5th sprite detection is due to a well know fact: if you read the status register while its flags are being set you will miss the flag bits. It is normal and documented and due to the fact reading the status register resets the flags.
But if you read the last 5 bits twice or more (as my polling code does) you cannot incur in the above problem.
If you find a tms9928 I'll send you a test rom.

[edit]
Obviously, telling out of the msx standard something that seems not working, isn't, let me be polite, a good idea (read it as an attempt to not start another dull flame war on religious subjects).



 

I guess I'm missing something. With the 5th sprite flag or the sprite plane polls I just get into an infinite loop ... I'll see that again tomorrow night and try to make it work.