T6950 does support the status register with the 5th bit flag and the indication of its plane (tested on the real thing). Status register and support of undocumented modes have nothing to do each others, why do you mix them ?

Apart that, even if IMHO certain kind of discussions are totally dull, the fact that some 9928 are buggy does not make a fully documented feature out of the msx standard (9918/28/29 share the same TMS manual and specs).

T6950 does support the status register with the 5th bit flag and the indication of its plane (tested on the real thing). Status register and support of undocumented modes have nothing to do each others, why do you mix them ?

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.

Apart that, even if IMHO certain kind of discussions are totally dull, the fact that some 9928 are buggy does not make a fully documented feature out of the msx standard (9918/28/29 share the same TMS manual and specs).

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?

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

so nothing t do with T6950

Citar

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 order to say that this or that feature is not part of msx standard, you should point an official document that tells a certain thing is not mandatory or not included.Hardly I believe you will be able to find such exception in official documents, that will point to official TMS manuals for the description of the vdp HW, which in turn describe the status register with 5th sprite flag and the rest.

If you find it, chapeau!, if not, what you just are telling is that there are some buggy machines from the very early series of msx that can could have a glitches with this feature. Nothing to do with compliance to the msx standard.

Do you know why the z80 has undocumented instruction ? Because the very early series of that chip were buggy and did not support properly 8 bit operations on IX/IY registers, so Zilog decided to not include in official documents the buggy instructions, that have been fixed in later productions.Would you say that games that use undocumented instructions for z80 are out of msx standard? Never the less, msx standard includes z80 only for its "official" part, and in theory, there could be some early machine mounting one of first versions of the buggy z80 chip...

Citar

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?

Sorry, IMHO you are mixing msx standard definition with what you think should be the good practices to not incur in problems with some machines. It's a personal view, respectable but I wouldn't claim that it is the msx standard. And naturally, in 2014, I have another view.Using only msx bios and only mainstream features you wouldn't have had a large part of the homebrew products or a single demo. But this, as any religion war, is a dull discussion.

In order to say that this or that feature is not part of msx standard, you should point an official document that tells a certain thing is not mandatory or not included.Hardly I believe you will be able to find such exception in official documents, that will point to official TMS manuals for the description of the vdp HW, which in turn describe the status register with 5th sprite flag and the rest.

If you find it, chapeau!, if not, what you just are telling is that there are some buggy machines from the very early series of msx that can could have a glitches with this feature. Nothing to do with compliance to the msx standard.

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.

Do you know why the z80 has undocumented instruction ? Because the very early series of that chip were buggy and did not support properly 8 bit operations on IX/IY registers, so Zilog decided to not include in official documents the buggy instructions, that have been fixed in later productions.Would you say that games that use undocumented instructions for z80 are out of msx standard? Never the less, msx standard includes z80 only for its "official" part, and in theory, there could be some early machine mounting one of first versions of the buggy z80 chip...

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.

Sorry, IMHO you are mixing msx standard definition with what you think should be the good practices to not incur in problems with some machines. It's a personal view, respectable but I wouldn't claim that it is the msx standard. And naturally, in 2014, I have another view.Using only msx bios and only mainstream features you wouldn't have had a large part of the homebrew products or a single demo. But this, as any religion war, is a dull discussion.

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.

dioniso, sorry if i'm direct, but this kind of discussions return too frequentlylet's stay on the msx standard: ascii documents say "TMS9918 or equivalent" maybe I'm missing something: where do you find exceptions on the 5th sprite flag ?

If there is no exceptions in official documents, machines with buggy chips are just buggy machinesIf you avoid that feature to make your code work even on those machines, it is remarkable, but I'd never say that it is to comply the msx standard.

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.

Please, TMS9918 does not have screen 2 support. It was introduced with TMS9918A. It is the main difference between TI-99/4 and TI-99/4A. The latter has TMS9918A which support screen 2, the former has TMS9918, without screen 2.Look here http://shawweb.myzen.co.uk/stephen/artic6.htm (Screen 2 in the TI world is called "bitmap mode" )

Would you tell that screen 2 games are not msx standard ? I think that taking too literally that ascii document about msx2 does not lead very far. Same issue about z80 undocumented opcodes, I would keep using them despite the 2 M1 cycles ;-)

I think that, if a conclusion can be drawn, we should be less manicheist in telling what can be done and what cannot be done because out of the msx standard (and again, I feel stupid in touching this topic here and now - in 2014, after about 30 years of the death of the msx standard).

About the status register and the 5th sprite flag, I can help you only about the tests I did on my Panasonic turbo R and on a philips 8020 from a friend. The split screen polling the 5th sprite flag was working as expected.

[edit]Anyway coding screen 1 games has its appeal as you can swap freely between a number of tilesets loaded in vram. Even with screen 1 color limits it is possible to have decent results.

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-47Enemies will not flicker while the 32 bullets will appear in alternate frames

AR, we are two MSX users who think the same about what a game/demo should be. About the standards, it seems what ASCII themselves said is quite incongruent.

My only point was to see if most of the MSX have the 5th sprite flag and it seems so. I know of some users who will never use that; I respect their opinions, too.

I don't have much time now; I have to read your last two messages slowlier and deeply. I have just read you can have more than 4 sprites horizontally. That's something I will investigate in your messages and links. When I did some test (about a year ago) with synchro-code in IM2 I tried to show 4 sprites on the left and then change the SAT to place the same ones (or lower/higher planes) just to the right ... and the first one on the left just disappeared. I thought it was not possible to place more than 4 hardware sprites in a row. As I said, I will see that again after having read your messages.

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 timeIf 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 DionisoI'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).

x DionisoI'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.

I'll try this new approach. Yesterday in the night I couldn't [edit] quite get it to work. Somehow I was missing the flag being set.

So I'll set the last sprite (plane) at y=60, do some things, and before the raster is at that y=60 I'll do a loop to "freeze" until the bits 0-4 have that sprite plane. I'll tell you later or the next days.

halt;do some stuff

last_plane:in a,($99)and 31cp 31 ;it doesn't have to be the 31st plane, it could be cero, for instance.jp nz,last_plane

;splitscreen

I'll try that to achieve the same I do here with synchro-code, with SCREEN 2 on the higher and lower parts of the screen and SCREEN 3 in the middle. The quality of the video is not good; the scroll part is supossed to be soft.