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.