Quote:

I think that a SCC implementation is not better if it can be cheated or not. After all, I'm not sure that SCC chip was designed for being detected (at least in a strange or tricky way).

The point is to implement all SCC registers, and try to emulate the real hardware as close as possible. If I can cheat it, using SCC registers or real hardware behaviour, that would mean the implementations is not "perfect", that is what openMSX is aiming for.
Of course the "tricks" I will use are not really important, since they are not used in any Konami game.

Quote:

>> Of course the "tricks" I will use are not really important, since they are not used in any Konami game.

That's the point

You mean that if Konami doesn't use it in their games, it is not a worth thing?
So SCC specifications is what Konami uses, not what SCC can do (?!)
Then SCC can not be used in demos/games out of "official" especifications?
I don't think so.

A good example of this is the 'test' or 'deformation' register that is present on both SCC and SCC+ (albeit in different locations). Konami does not use it at all, but it's interesting nevertheless.
Also, the Z80 and the VDP are also used out-of-spec in some games/programs. Should emulators declare these softwares incompatible? I think not.

Quote:

Also, the Z80 and the VDP are also used out-of-spec in some games/programs. Should emulators declare these softwares incompatible? I think not.

Well, in this case let's say 'compatibility is not 100% guaranteed' which doesn't mean necessarily 'incompatible'.

Anyway I remember that R800 was said to be 100% Z80 compatible. Nevertheless there are some undocumented Z80 instructions not working fine on R800 (AFAIK).

I think that using undocumented features implies a (minimal) risk. When developing, you may accept that risk or may not. Many people do accept it (including software houses). I have written some pieces of code using 'incompatible' features as well.

But my humble opinion is that I cannot guarantee compatibility if I use undocumented features.

Maybe this is a good issue to be continued in another thread.
(The initial thread was about debuggers, do you remember?)

Quote:

Then SCC can not be used in demos/games out of "official" especifications?

I didn't say that

It was a question, not an afirmation

Anyway, all SCC registers are undocumented as far as I know, since Konami did not released any official document/information. Some time ago I saw a photo showing what looked an official SCC document, but don't think it was released.

About built-in debugger; my vote goes for NO$MSX

Quote:

Anyway I remember that R800 was said to be 100% Z80 compatible. Nevertheless there are some undocumented Z80 instructions not working fine on R800 (AFAIK).

True, the Z80 'SLL' instruction (Shift left, insert 1) which is undocumented is replaced on R800 by another undocumented instruction, TST. I should test it once... It's either a non-destructive AND, or something else. It shows the lineage of the R800, being that it's not based on a Z80, but another processor (e.g. Z800 or Z180).
If you for this reason do not want to call the R800 Z80-compatible, then the V9938 isn't TMS9918 compatible either, because it's missing some undocumented screenmodes.

Quote:

Maybe this is a good issue to be continued in another thread.

There's not much more to say, is there?

Quote:

>>If you for this reason do not want to call the R800 Z80-compatible, then the V9938 isn't TMS9918 compatible either, because it's missing some undocumented screenmodes.

Of course I think R800 is Z80-compatible! What I mean is that using undocumented features may be 'dangerous' in some cases (though it happens rarely)

Quote:

True, the Z80 'SLL' instruction (Shift left, insert 1) which is undocumented is replaced on R800 by another undocumented instruction, TST. I should test it once... It's either a non-destructive AND, or something else. It shows the lineage of the R800, being that it's not based on a Z80, but another processor (e.g. Z800 or Z180).

TST == non-destructive AND

I can say that r800 isn't all 100% compatible with z80, thus sll instruction dont't work on r800 a game that iam didn't work on this mode on 2 o 3 years, and nobody known why. Did you remember this Guillian?

I didn't, but I do
Yes, you told me something about it... why?

Anyway, today I started my new SCC detection rutine. I hope it could be used to improve openMSX (an others, of course)

Quote:

I didn't, but I do Yes, you told me something about it... why?

I ask you about if the problem could be undocument instruction of z80, but you said me that all undocument instruction was made document on r800. How i thought that you was a msx guru I lookup on other things.I lost 2 years of my life for youuuuuu

Y dice el KNM que tu web es una paja, que no funcionan los enlaces y no se actualiza y tal y tal ...

Quote:

>> I ask you about if the problem could be undocument instruction of z80, but you said me that all undocument instruction was made document on r800. How i thought that you was a msx guru I lookup on other things.I lost 2 years of my life for youuuuuu

I'm astonished :|
It is not fair to blame me about it. (I don't remember exactly it, but...) If it took 2 years to find that bug, you are the worts coder I have seen XD

Quote:

Y dice el KNM que tu web es una paja, que no funcionan los enlaces y no se actualiza y tal y tal ...

Astonished again!

All links (in the link section) works perfect. So, why don't you test it by yourself before complaining? If there is any problem, just tell me it, I'll fix it. Easy.