Home Page Forums MAME MAME BBC Video WIP

All bbc machines are currently tagged with MACHINE_IMPERFECT_GRAPHICS due to incorrect rendering when anything unusual is written to the 6845. To improve this I'm using bbcb_flop:froggerr as a test case as it really pushes the bbc video system to it's limits by using the 6845 in innovative ways. See it in action at http://bbcmicro.co.uk//jsbeeb/play.php?autoboot&disc=http://bbcmicro.co.uk//gameimg/discs/Disc108-FroggerRSCB.ssd

Many games change the screen size to reduce video RAM usage, and this game runs at 224x256. It doesn't set the 6845 to this size though, it defines multiple 'screens' as the screen is being updated. So R4 is set to 0x00 (1 character row/8 scanlines) and R12/13 point to RAM, and these are updated during HSYNC? This allows the same area of RAM to be repeated in different parts of the overall screen.

The bbc currently uses MCFG_MC6845_UPDATE_ROW_CB for rendering but due to all these 'screens' being defined at 224x8 then we only see the first 8 scanlines stretched full height of our output. How should I handle this?

I'm thinking I need to use a fixed size canvas and introduce MC6845_RECONFIGURE to stop the 6845 from resizing my screen, then rewrite MC6845_UPDATE_ROW to render in the active area only.

That sounds like the tricks 8088 Corruption does to the 6845 on the CGA card. Carl might have some insight, he has that kind of working.

Yup, I added MC6845_RECONFIGURE for that. Just use MCFG_VIDEO_SET_SCREEN(nullptr) to prevent the 6845 from calling screen_device::reconfigure itself.

Thanks, I did look at that but didn't realise the significance of MCFG_VIDEO_SET_SCREEN.

Am now thinking a different approach is required and not use MCFG_MC6845_UPDATE_ROW_CB but instead implement MCFG_SCREEN_UPDATE_DRIVER in a similar way as the amstrad driver. The 6845 feeds a Video ULA that generates RGB (like Amstrad) and using MCFG_SCREEN_UPDATE_DRIVER should give me more control over the timing that's required to get this right.

MCFG_SCREEN_UPDATE_DRIVER basically means you're ignoring the 6845. It works well for a lot of cases, but I can't imagine it's the right solution to software playing tricks with the 6845

After the significant Electron improvements I'm now back into BBC video.

Simply setting MCFG_MC6845_SHOW_BORDER_AREA(true) improved things and now realise why I need to use MC6845_UPDATE_ROW, to have access to hbp and vbp to ensure the active area is positioned correctly. It's preferable to show the border as software can and does move the active area around, I guess artwork will need updating.

In all of my new screenshots there are remnants of previous screens in the non-active areas, Boffin shows CAVE 1, E-Type should be just the game in the center and not E-Type in the borders. I realise in MC6845_UPDATE_ROW I'm only plotting the active area, should I be blanking everything else in here, any examples?

It's definitely heading in the right direction but need to look into interrupt timing for anything that uses split-modes such as Elite.

There are a couple of recent games that re-configure the 6845 during a scanline, and must be timed to the pixel. Is this currently possible to implement in MAME, or should I ignore for now?

Boffin: was originally stretched to fit screen, now correct size into overscan.


Carnival: was stretched and bad timing, now correct size and palette changes.


Icarus: was stretched to fit screen, now correct size.


E-Type: was stretched to fit screen, now correct size but palette changes not 100%.

Are you drawing when the display is disabled? For the cgenie I have:


From https://git.redump.net/mame/tree/src/mame/drivers/cgenie.cpp#n335

That makes no difference. In mc6845_device::screen_update it only calls draw_scanline (which calls m_update_row_cb) for the visible region, yet I have remnants all around this region.

Maybe I need to use m_begin_update_cb to clear the bitmap?

Edit: I see you use MC6845_BEGIN_UPDATE in cgenie to clear the bitmap

Internally the 6845 just uses emu_timers which get calculated based on whatever is configured in the registers so it does support updating those while the screen is being drawn. This is used on other platforms for doing split screen tricks.

Using
certainly fixes my blanking issues in Boffin, where the 6845 is not re-configured during the screen update:

but for Carnival that re-configures multiple 6845 screens during the update I'm inadvertently clearing the playing area:

For another game that creates multiple 6845 'screens' during a single scanline I'm failing to see how MC6845_UPDATE_ROW could ever be called more than once per scanline, as each 'screen' is configured. These 'screens' are configured as 1 character high so would need MC6845_RECONFIGURE to force drawing all scanlines. But in MC6845_RECONFIGURE I can't just ignore changes in visarea.min_y/max_y as in isa8_cga_device because it has to change between teletext and graphics modes. Due to these limitations I'm again considering switching to MCFG_SCREEN_UPDATE_DRIVER where I should have full control of what I plot on the whole scanline.

Doing your own is a solution of course, but I would love to see some generic improvements to the 6845 so that all drivers benefit.

I'm going to put that harder: fix the 6845 to work. Abandoning it is both cowardice and poor documentation value, and I will not look kindly upon any change lists that do so.

I'm not saying there's anything wrong with the current 6845, the real device doesn't output the video yet we have MC6845_UPDATE_ROW to do just that. The BBC has a VideoULA to output video RGB which takes the various 6845 outputs MA, RA, CURSOR, DE to generate video for the whole screen, not just the last area the 6845 was configured for. The amstrad driver uses the 6845 in a similar way and doesn't use MC6845_UPDATE_ROW, is that wrong?

I need to do some more testing but will probably submit current progress with borders and fixed blanking using MC6845_UPDATE_ROW. I'm not expecting this to break anything (apart from artwork) and will certainly improve many games that simply reduce the screen size to save video RAM.

Could it be related to this display bug in the CPC driver? -> http://mametesters.org/view.php?id=6864

I think that's related more to setting up for differing frame rates, where the driver just bases the frame rate on a machine config setting.

If this is referring to improving mc6845_device::screen_update then I agree.

Out of curiosity, why would Machine Information report different Video resolutions depending on whether MCFG_MC6845_SHOW_BORDER_AREA is true or false?
false:

true:

because it shows the current visible area size, which is obviously different if borders are showing..

Obviously, was a case of typing before thought.

Do any other drivers handle changing of the pixel clock during a scanline? This will be required to handle split modes vertically rather than the more commonly used horizontally split.

So the 6845 currently has a scanline_timer but I really need a pixel_timer. Would it makes sense to implement this in my MC6845_UPDATE_ROW or would a new MC6845_UPDATE_PIXEL be the way to go?

Again just thinking out loud for guidance.

MAME doesn't really support "horizontal partial updates" at the moment, and it definitely doesn't support changing resolution within a line. If you've got horizontal resolution changes within a line, you need to render at lowest common multiple. A per-pixel timer would kill performance. If you need to render per-pixel, you'd be better off making the video chip implement device_execute_interface and letting the scheduler deal with it.

Yeah, I need to get back to the horizontal partial update thing after my current large project lands. Gotta get those French Touch demos perfect.

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.

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