Tilegen

[Ian]

Bart if you get a chance to test on real he again. See if you can write some code to test the tilegen.

Want to see if you can update it mid frame and cause some tearing. Could just swap the mask table or something. Want to see if tearing happens. Might give me an idea how to fix the rolling start bug.

If irq2 is the start of vblank. Games usually update the tilegen here. But a bunch also send updates at 66% of the frame or where the ping pong bit flips. Lost world does this for the flash effect when you shoot but I've never noticed tearing on the real hw.

[Bart]

Bart if you get a chance to test on real he again. See if you can write some code to test the tilegen.

Want to see if you can update it mid frame and cause some tearing. Could just swap the mask table or something. Want to see if tearing happens. Might give me an idea how to fix the rolling start bug.

If irq2 is the start of vblank. Games usually update the tilegen here. But a bunch also send updates at 66% of the frame or where the ping pong bit flips. Lost world does this for the flash effect when you shoot but I've never noticed tearing on the real hw.

Tilegen code is easy. But... the EPROM sockets are really starting to malfunction from the constant re-seating (they're not made to handle that sort of stress). I need to develop an app that will let me load from the PC so that ideally, I could just swap out the ROMs one last time and then transfer from PC from then on. This will likely not be doable until end of October at the earliest.

However! In the meantime, we could try to develop a program and test it in Supermodel using my libmodel3 framework. I'm a bit pressed on time for the next few weeks but if you'd like to have a go at writing the C code, it's really simple. I can supply you with the cross-compiler I built years ago and give you a really easy skeleton program to work with. I have functions for syncing to VBL and using the timebase registers from C code so it's actually pretty simple. The test logic would need to be devised.

[Ian]

I checked the latest version of mame
Scud doesn't get very far in mame .. actually it locks up pretty early.
However I did notice that the scrolling bug issue doesn't exist in mame ...

https://youtu.be/F1ttfo3KUYw?t=410

Maybe worth checking out ?

[Ian]

Spotted this in the mame source ..
https://github.com/mamedev/mame/blob/ma ... gaic24.cpp

Code: Select all

         for(y=0; y<384; y++) {
            hscr = (-hscrtb[y]) & 0x1ff;
            if(hscr + 496 <= 512) {
               // Horizontal split unnecessary
               draw_rect(screen, bm, tm, bitmap, mask, tpri, lpri, win, hscr, vscr,        0,        y,      496,      y+1);
            } else {
               // Horizontal split necessary
               draw_rect(screen, bm, tm, bitmap, mask, tpri, lpri, win, hscr, vscr,        0,        y, 512-hscr,      y+1);
               draw_rect(screen, bm, tm, bitmap, mask, tpri, lpri, win,    0, vscr, 512-hscr,        y,      496,      y+1);
            }
            vscr = (vscr + 1) & 0x1ff;
         }

Note in the 2nd case it does a horizontal split? But they are doing 512-scroll value ? Not 496-scrollValue. Maybe the issue is here?

[Bart]

This logic is equivalent to what Supermodel is doing. The layers are 512 pixels wide and the hscroll value represents the starting pixel offset to begin rendering at, between 0 and 511. MAME apparently draws the line using some sort of rectangle draw call. If the hscroll is large enough that a wrap from pixel 511 back to pixel 0 occurs within the visible (496 pixel) display area, then they need to make two draw calls because the calls themselves do not handle wrapping.

So, 512-496 = 16 pixels are hidden to the right of the display edge when hscroll=0. If hscroll > 16, you will hit pixel 511 and then have to go back to pixel 0. For example, if hscroll = 17, you need to render pixels 17-511 (that's 495 pixels), and then pixel 0 again (which makes 496). MAME breaks this case up into two calls (17-511 and 0). But if hscroll is e.g. only 8, then you can do it in one single call because the wrapping point is never hit: pixels 8-503.

If MAME is doing anything different, my guess is it has to do with how the mask (they may call them "window" or "stencil") bits are interpreted and/or some difference in frame timing.

[Bart]

Let me explain a bit more about what is happening when you see "Rolling Start":

1. The tile generator has 4 layers each of size 512x512 pixels: A, A', B, B'.
2. Imagine the 496 pixel display area (in fact, the entire 512 pixel display line, too) can be divided into 32-pixel wide columns. Each tile is 8 pixels wide. So if hscroll=0, each column contains 4 tiles. If hscroll&7 != 0, the tiles are shifted and a column might contain 4 tiles plus a partial tile.
3. For a given scan line, within any of these columns, only two of the 4 layers may be displayed at a time. Tiles from either A or A' (but never both), and tiles from either B or B'.
3a. Put another way, for any pixel on the screen, only two tile layers were drawn: a bottom layer and a top layer (the bottom layer is visible only if the top layer pixel is transparent). These two layers are one of A/A' and one of B/B'.
4. The selection between e.g. A or A' is determined by a bit mask layer that I call the "stencil mask" or simply "mask" (in the giant comment at the top of the file, I have a section describing it). There is a mask for each of the 512 lines (384 visible lines). The mask is 512/32 = 16 bits.
5. The mask is not affected by scrolling. It operates on the screen after scrolling has been performed.

What is happening with "Rolling Start" is that this text is being scrolled across the screen but, without the masking logic, it would wrap and repeat. So it would look like two banners repeating closely one after another. The mask is used to hide part of it and only display one instance. If you print out the mask values for one of the banner lines, you will see bits shifting across the screen in sync with scrolling, something like:

Code: Select all

Frame 0: 0000 0000 0000 0000
Frame 1: 0000 0000 0000 0001
Frame 2: 0000 0000 0000 0011
Frame 3: 0000 0000 0000 0111
Frame 4: 0000 0000 0000 1111
Frame 5: 0000 0000 0001 1111
...
Frame N: 0001 1111 1100 0000
Frame M: 0011 1111 1000 0000
...


Here I've pretended that the banner is 7 columns wide -- I don't remember the actual value. It's longer, though. As "Rolling Start" scrolls across the screen, every 32 pixels or so, the game should be updating this mask. Somehow it's off.

At the edge of the banner, the mask doesn't line up. It is pretty easy to modify the tilegen code to draw the mask and you'll see the misalignment. This could be due to frame timing or it could be that there is some sort of fixed pixel offset applied to the mask. I can't remember if MAME applied a fixed offset. I also can't remember what Charles MacDonald's excellent System 24 document said about this topic. But I did at one point dig into both and couldn't find anything that worked correctly. If I fix the problem by adding a fixed offset, Magical Truck Adventure or some other game breaks (the attract mode has some scrolling text and I *think* it also uses masking).

I hope that made sense.

[Bart]

This masking functionality would be trivial to test on the real hardware but I would like to first be able to devise a system to load programs directly from the PC via the joystick inputs.

[Ian]

That's mame. Notice the garbage on the left side. Thing is, would you ever seen this on real hardware? I am sure there is a certain amount of over-scan on CRT

[Ian]

One idea ..
I wonder if we could simply capture all the data from the tilegen (in the emulator) and just send it to the real h/w for testing.
Ie freeze a frame of scud rolling start, then save the data.
If we did that we could eliminate any kind of timing problems. I think the tilegen is compatible between all the different h/w revisions? So could maybe test that that on a step 1.0 board?

[Bart]

Overscan isn't an issue here: the visible area is 496 pixels. Overscan is what lies beyond and is there to afford the monitor's electron beam some tolerance. The display hardware defines where the visible region begins and ends and is unlikely to emit garbage beyond it because it knows when it is in the overscan portions of the line. Usually, they emit a solid color, defined either by a hardware register or taken from some particular palette slot. This garbage column in MAME would be visible on the actual display and therefore it is a bug in MAME.