msx/msxtr.cpp: Move MSX Turbo-R machines to their own file and implement some devices.

[wilbertpol]

No description provided.

[holub]

@wilbertpol new z80 code has been merged: #12423
If you want yours as a incremental extension to a parent take a look how was it done for z80n: holub/mame@z80-gen...next-n-gen

Alternately you can generate whole set of instructions. Feel free to ask me for any help.

[holub]

It's hard to trace how much is the difference compare to original z80 in r800. But quick look tells me that z80n from the link above must be your best friend in this situation

[wilbertpol]

It's hard to trace how much is the difference compare to original z80 in r800. But quick look tells me that z80n from the link above must be your best friend in this situation

Yes, I will check out the changes to the z80 core.
The differences between z80 and r800 instruction-wise are very minor; 1 undocumented instruction became documented and addition of a few multiplication instructions. A lot of undocumented instructions did get removed though. Also the cycle timings changed a bit.

If I have questions I know where to find you, thanks.

[holub]

It's hard to trace how much is the difference compare to original z80 in r800. But quick look tells me that z80n from the link above must be your best friend in this situation

Yes, I will check out the changes to the z80 core. The differences between z80 and r800 instruction-wise are very minor; 1 undocumented instruction became documented and addition of a few multiplication instructions. A lot of undocumented instructions did get removed though. Also the cycle timings changed a bit.

If I have questions I know where to find you, thanks.

In this case you can scrap most of your work :)
You still can change timings the way you did in this PR
New instructions can provided exactly same way as for z80n
Bear in mind you must avoid local vars between case statements - for this we use shared TDAT, TADDR, etc

[rb6502]

In CPU cores making them shared between opcode handlers often makes sense, but you don't have to. This pattern works fine, for instance:

case 42:
{
    uint32_t local_variable;
}
break;

[holub]

In CPU cores making them shared between opcode handlers often makes sense, but you don't have to. This pattern works fine, for instance:

case 42:
{
    uint32_t local_variable;
}
break;

That's fine. I was talking about the case where varaible scope cross mem access. This one potentialy escape from the execloop and will not be able to re-enter.
Luckaly it will be catched during the compilation of generated code.

[wilbertpol]

Converted to draft, checking out the z80 core generation.

[rb6502]

Can I get the merge issue fixed and this squashed down to a single set of changes? It's a bit difficult to follow what happened over the course of this PR given the massive changes.

[wilbertpol]

Ah, I was not aware that a merge conflict got introduced lately.
If it makes things simpler I can also do a separate PR for only the R800 cpu core changes?

[cuavas]

The memory interface on the R800 is different though – it effectively uses a “fast page” mode where consecutive accesses from the same 256-bye block are one cycle faster. It lacks the automatic free-running refresh, too. Does the piplelining complicate instruction timing calculations (e.g. are there purge cycles after branches or complications with djnz)?

[wilbertpol]

The memory interface on the R800 is different though – it effectively uses a “fast page” mode where consecutive accesses from the same 256-bye block are one cycle faster. It lacks the automatic free-running refresh, too. Does the piplelining complicate instruction timing calculations (e.g. are there purge cycles after branches or complications with djnz)?

Yes, I know.
I have not been able to run tests yet to verify behaviour of the fast page mode or the updated refresh. Just as I do not have test cases for checking dma or interrupt levels, although these will be harder to test since we do not have machines that use this functionality. So I have not implemented these things here yet.

I have no idea if there are complicated timing calculations due to the pipelining. I have not come across documentation describing that yet.

[wilbertpol]

I have extracted the cpu changes into a separate pull request: #12530

[wilbertpol]

I'll split this up into separate pull requests