Home Page Forums MAME MAME BBC Video WIP

The outputs of the 6845 can be used to drive a screen (it will generate HS/VS signals) but often they're further processed by something else, which is actually in charge of the screen and is responsible for the real HS/VS signals generated. For example, on the Amstrad CPC, the Gate Array assumes this role (for HS at least, can't remember VS)

In such cases it's up to the other hardware if it actually uses these signals directly, or further manipulate them / selectively ignore them in certain situations. In that sense the outputs of the 6845 can become more like a suggestion, with the signals often having additional delay before they're passed on to the display. I think you can also entirely ignore the 6845 HS/VS in some cases, and just use externally generated HS/VS signals as long as your timings are reasonable.

That's how a lot of the more abusive tricks end up working on real hardware (many are also very fussy about the specific CRTC model as some allow readback of certain registers that tricks rely on, while others don't)

The 6845 does provide good HS and VS signals, we're not using any timings from screen_device. It's the fact that screen_device controls screen updates and this is now updating non visible areas of the bitmap (no way of avoiding this), and both the screen and mc6845 base their timers assuming they only cover the visible area, so they're out of sync. Should I be using screen->reset_origin() to ensure they're in sync?

Giving the screen the option to display border would negate these issues as it would still be aware of the visible area to update, rather than the intended bitmap size, and would also still provide System Information dialog with active area size.

You can’t make the screen device’s “visible area” mean anything other than the size of the visible portion of the output bitmap, or all hell will break loose. Far too many things depend on that all the way through MAME’s render stack and in external scripts.

The 6845 getting out of sync with the screen device is annoying. I really need to fix that properly, but it requires a chunk of time at once because I can’t leave it broken while fighting other fires.

Agree 100%, the 6845 set_show_border_area(true) option simply cannot work for anything that depends on any timings. So are there any other suggestions for creating a bitmap larger than the defined visible area, or we stuck with stretching games to fill the screen for now? (See Boffin and E-Type screenshots earlier in thread, both define a visible area considerably smaller than the actual screen)

You’re still thinking about it the wrong way – the fix isn’t to allow the screen device to display something larger than its defined visible area. It’s to fix things so the 6845 doesn’t drift from the screen device.

It’s possible to fix, but it requires major surgery to the 6845, which is risky due to the number of things that depend on it. I’m not too keen on trying to help someone else do it, because it ended in disaster last time I tried to help someone work on the 6845. Apparently considering more than one use case is a bit much to expect.

Right. 6845 tricks like 8088 MPH didn't make sense to me when I thought of the 6845 as the source of truth. But they make perfect sense when you realize the monitor is.

As I've said multiple times, our 6845 core does too much, and it doesn't make sense to try fixing it and pretend it won't break for anything else.
It needs a separate core, picking up any of the heavyweights and start working there.

Yeah, an "n6845" to use OG terminology. Make it do the heavy hitters (8088 MPH, the BBC stuff, the Amstrad stuff) and then all the simple cases should port right over.

There's full in-depth documentation for the amstrad available if someone feels like it.

https://shaker.logonsystem.eu/ACCC1.8-EN.pdf