Home Page Forums MAME MAME SVN builds - new driver flood

I guess that establishes that the 2nd 'page' is a pixel higher in VRAM...

it could be a 'bug' in the hardware whereby once the scroll counter exceeds a certain value it ends up pulling from a line higher I guess?

or a bug in the CPU emulation when it's writing this data in the first place since we now know it's software rendered...

the videos I can find that look most like real hardware aren't doing it.

is that method of scrolling with a bitmap layer known to be used anywhere else?

It is, and what do you know, the split shows up there too. So it's not game-specific:



I've checked it out in UNZ and the VRAM has the same content, but the part after the split looks different in movement, like it "shakes" a bit.

Maybe it's a raster effect and there needs to be a partial update at the split?

horizontal splits are very uncommon... seems an unlikely option when it would have been easier just to write the data in the correct place in RAM, especially now we've seen it on multiple games.

this is compensating for something else, almost certainly.

if's probably just a case of 'if (xscrolltval + xdrawpos) > limit then used_yscrollval = yscrollval - 1' or similar instead to compensate for some hardware quirk.

Right, I misunderstood the problem. The docs seem to imply (as best as I can tell from the pictures) that a displayed line should wrap to the same line when the layer edge is reached but we are reading from the next line instead.

yep, that would actually be more logical and is how 99% of systems work, I thought r09 was showing that the unwanted data was on the same line after wrapping

See, that's what I meant by "missing something obvious", I actually thought the line just continued, I didn't realize it was ending there and wrapping back to the start. So yeah, it's just a matter of "if we reach the end of a line while scrolling, jump back to 0". I think I just confused everyone, sorry about that.

I'll try to take a look but I'll be pretty busy for the next week or so (as is everyone, I suppose), so may take a while.

no problem, just happy to see progress being made on the driver, the FM Towns Marty is one of the easier to use systems in MAME so emulation improvements are always good for showing it off to people without too much of a learning curve

Yeah, and it's kind of been a big story how much its improved this version. If we can fix this layer misalign and then concentrate on whatever other games don't boot we could be in really good condition for that system.

Haha, it turns out that once you understand things they are really easy to do.



For now I only have it working for the specific case in TNZS (16-bit layer with 4x zoom) but the code is generic enough that it should work with any configuration. Just have to do some testing...