Home Page Forums MAME MAME BBC Video WIP

I now think a per-pixel timer would be overkill. The CRTC registers are defined in characters, so a per-character timer should be sufficient. Typical values would be 128 horizontal characters of which 80 are displayed. Would this appease your performance concerns?

If I need to take this option could you elaborate on what it would involve, any examples of it's usage?

I'd prefer to implement something like MC6845_UPDATE_CHAR that enhances the use of the 6845, but doesn't affect machines using MC6845_UPDATE_ROW that don't make changes during scanline.

I still think a timer per character cell is going to be a lot of overhead. All the CPUs and various other things like the POKEY sound chip implement device_execute_interface. If you go this way, you can cause synchronisation when things actually change rather than running a pessimistic timer.

Alternatively you could use a timer that triggers at the end of a scanline, but trigger partial updates when something happens that affects rendering. You can check the time in the current executable device's domain at the point where you get a register change etc. to work out how far through the line you are. This would work well enough if only a single executable device (e.g. CPU) can cause register changes,

Can someone explain what screen->update_partial(vpos) actual does, and when/how it should be used?

update_partial() draws the screen until the specified vertical position. You use it when video parameters change (e.g. on systems that can rewrite the palette per-line or something of that nature).

I simply don't have the understanding of the video hardware and timing, to tackle this properly yet.
I can mix the screen modes, as shown here in Elite, but the black band is constantly moving suggesting a timing issue. At this point I don't know whether the issue is with how I've setup the screen or something with how I'm using the 6845, or the 6845 itself.
I keep returning to it every few months in the hope that I'll get a little further with every fresh look.

I guess you need to study the game code to see how it's deciding when to change the parameters?

it could be some horrible case where it depends on precise emulation of waitstates etc. if the software has no real way to know the beam position from the hardware outside of manual cycle counting

it's also possible you're not forcing a partial update when the relevant video registers change (because really, using force partial updates is an optimization so that drivers don't have to draw the entire screen line by line in all cases) There are things like 'VIDEO_UPDATE_SCANLINE' if you want to force MAME to do a partial update for every single line (which is still really not 100% accurate to hardware, as some can update during the horizontal scan too, there's a SNES game that quite famously uses horizontal and vertical timing effects to change the palette for a handful of pixels in order to make a shadow, then changes it back, and no, MAME doesn't handle that case)

Accurate timing and video emulation built around it is hard on many levels tho, and for quite a few cases MAME isn't best suited to handle it.

I realise that, but my lack of screen/video knowledge is not helping either I already use VIDEO_UPDATE_SCANLINE in the Electron driver which works great, but don't think this helps when using the mc6845 device.

In mc6845_device::recompute_parameters the last thing it does is to reset m_line_counter = 0. This is definitely not helping my use case, removing it gives me a stable image but I lose the lower part of the screen after the resolution change. Feels like a step in the right direction, not sure yet how this would affect any other machines.

Wow, over 6 years since I last posted to this topic.

I have Elite fully working, and many others that change screen resolution mid-screen, with minimal changes to mc6845_device (just remove the m_line_counter = 0 at the end of recompute_parameters).



Ideally I also want to use set_show_border_area(true) but am now convinced this is fundamentally flawed as it changes the visarea which then breaks the vblank timing when screen->reset_origin() is called. Anything that then relies on accurate VSYNC interrupts is then broken.

Wouldn't it make more sense to have the show_border_area property at a lower level, in screen_device? This would allow screen_device to allocate the correctly sized bitmap without disrupting visarea and derived timings.

The screen device is already flawed when it comes to the timings based on visible area. If you need accurate timing for sync signals, etc. you really need to generate them from the CRTC device itself. Does the 6845 device provide vertical blanking and/or sync signals independent of the screen device?

The 6845 doesn't have a meaningful vertical blanking signal, but it does produce VSYNC, and a lot of systems rely on that.

6845 visible area configuration, as currently emulated, is fundamentally flawed because of the way some software abuses the device by reconfiguring the screen many times per frame.