Same to the 6301V, but RAM from 0x40 to 0xff.

Cordially.

Internal I/O from 0x00-0x18
And yes, RAM 0x40-0xff.

I also had to do some fixes to the m6801 CPU core to make the Yeno 301 XL work:
https://github.com/mamedev/mame/comm...068c0a5e3af164 (the DDR4 fix)
https://github.com/mamedev/mame/comm...6ad3ae80c0c3dc
https://github.com/mamedev/mame/comm...82a4a7acfcb290

Yep, I've already downloaded these m6801 changes yesterday and use it in my MAME 0.261 version, but of course I can't port these files back to 0.220, so I'm curious if the Yeno 301 XL will work in CB-Emu!?

BTW, your new method of using xc/yc instead of the usual x/y coordinates in the layout is really annoying - I have to change dozens (if not hundreds) of values to make it work in MAME 0.220.

__________________
Meine Webseite: https://fhub.jimdofree.com/

Yeno 301 XL won't work without those fixes.

MAME artwork 'newer' features like the repeat func, or blend modes, or xc/yc, they make it easier for me to manually write those .lay files.
Yeah I can imagine it's annoying to convert back. I think it's something like x=xc-(width/2) and likewise for y.

Are you sure?
I'm not using the 'standby' and 'nvram' features of your drivers, so maybe those fixes have no effect for my version!?

Or are any other code parts in your driver not working without them?
If yes, then I don't even try to implement the 301 XL in my version ...

__________________
Meine Webseite: https://fhub.jimdofree.com/

Yes I'm sure, I had a WIP driver that had major problems, until I did those bugfixes to the CPU emulation.

You can still try.
The DDR4 problem can be worked around with if you do something like this in the driver machine_reset:
m_maincpu->space(AS_PROGRAM).write_byte(0x05, 0xff);

And the illegal opcode fixes, the ones I linked should be easy to copy over to an older MAME.

I've now made the usual changes for these 6301 devices and with the above line the Yeno 301 XL is at least starting, but apart from the buttons (producing beeps) nothing else works: no leds and also the sensor board is 'dead'.
Well, I've looked at these files, but there are hundreds of changes, and the current m6800 files are so different to the version I'm using in 0.220 (although already updated some time ago), that I won't even know where to start with any "copy over".
So this Yeno 301 XL will definitely not make it into CB-Emu.

__________________
Meine Webseite: https://fhub.jimdofree.com/

Hi,

Now everyone can answer my question from a month ago:

https://www.schachcomputer.info/foru...ead.php?t=6960

Cordially.

WARNING WARNING : The Yeno 301XL use illegal opcode interruption (trap vector) as subroutine with parameter (codes $00 $02 $42 $87 $CF, of course illegal opcode) .

Cordially.

Does someone have a working Constellation Junior? (Mychess's one is broken)
And can you try this?

Push white pawn from D4 to D5, does the D5 sensor take longer to register?

Or, same with the queen:
white pawn to E3, black don't care
white queen to G4, black don't care
white queen to G5 **here, sensor response is slow**, black don't care
white queen to G4 **sensor response is slow again**

So, with any vertical 1 square move from 4th to 5th rank, or backwards, the chessboard sensor response is slower than with other moves.

If it happens on the actual chesscomputer too, then it's not a fault in the emulation.