MAME: Video handling

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
Pernod
Posts: 1340
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

MAME: Video handling

Post by Pernod » Tue Jul 18, 2017 4:52 pm

The video emulation of a Beeb in MAME is severely lacking, and so all machines have been tagged MACHINE_IMPERFECT_GRAPHICS for many years!

Whilst I understand most of the video circuitry and believe it to be mostly correct in my WIP there are still things I don't quite get. My main test case is Tricky's Frogger due to it pushing the video to it's limits. If that works then everything else should!

In the Frogger thread Tricky mentioned that
Each character row (8 pixels) is it's own "screen"
and MAME does seem to think the whole screen is 224x8. Can someone explain how this works and hint at where I should be looking to handle it?
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
tricky
Posts: 2950
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MAME: Video handling

Post by tricky » Tue Jul 18, 2017 6:39 pm

I'm sure someone (RichTW?) can explain it better, but R4 (+1) controls how many character lines are drawn before the 6845 starts again by reading the latched values for R12/R13, this is what I meant by "screen".
R7 determines when VSYNC happens and a little while (54 scan lines after the end I think) the next "field" starts to be displayed at the top of the screen (if you haven't pushed the display so far out of spec that it can't work out where it is supposed to be).
I think you will have fun with games that use vertical scrolling with "vertical rupture" (see RichTW's explanation - I think on RS). I guess technically Frogger uses it as it seems to be just multiple "screens" per "field", but AstroBlaster, Phoenix and my Vertical scrolling sprite demo go a bit further by changing R5 to give pixel vertical scrolling.
The feature I would really like to see supported well is the when you point the 6845 at &7C00..&7CFF (and &3C00..&3CFF B/B+) as this gives you the same address on each scan line until the end of the character ROW R9(+1) and so can be used to give N-height pixels without wasting memory or having to copy the same data multiple times. This was described a little in the Chess thread and there is a little more detail in the request on jsbeeb (copied here as I can never find where I put it).

Code: Select all

On a real beeb, setting R12/R13 start of display address gives the following results:
http://www.retrosoftware.co.uk/forum/viewtopic.php?f=73&t=1011&p=7920&hilit=%263c00..#p7729

&2000..&23FF displays &3C00+R12R13 wrapping after &3FFF to &3C00
&2400..&27FF displays &3C00+R12R13 wrapping after &3FFF to &7C00
&2800..&23FF displays &7C00+R12R13 wrapping after &7FFF to &7C00
&2B00..&23FF displays &7C00+R12R13 wrapping after &7FFF to &3C00

I don't have my original test app, but this might be OK.
10 *K.10O.|MREN.|ML.|M
20 MODE 7
30 DIGIT$="0123456789ABCDEF"
40 FOR X%=&3C00 TO &3FFF STEP 4
50 PROCSET
60 X%=X%+&4000
70 PROCSET
80 X%=X%-&4000
90 NEXT
100 Y%=&20
110 REPEAT
120 ?&FE00=12:?&FE01=Y%
130 Y%=Y%+1
140 A$=GET$
150 UNTIL0
160 DEFPROCSET
170 X%?0=ASC(MID$(DIGIT$,1+(X% DIV &1000),1))
180 X%?1=ASC(MID$(DIGIT$,1+((X% DIV &100) AND &F),1))
190 X%?2=ASC(MID$(DIGIT$,1+((X% DIV &10) AND &F),1))
200 X%?3=ASC(MID$(DIGIT$,1+(X% AND &F),1))
210 ENDPROC
Press any key to advance the start address by &100.
PS Good luck, that is quite a task you have set yourself.
PPS The code in b-em is pretty good, as I suspect is the jsbeeb implementation (neither support the bit above correctly though :()

User avatar
Matt Godbolt
Posts: 181
Joined: Mon Jul 31, 2006 10:02 am
Location: Chicago
Contact:

Re: MAME: Video handling

Post by Matt Godbolt » Tue Jul 18, 2017 6:48 pm

Thanks for the update tricky! I forgot jsbeeb still doesn't do the 7c00 thing properly (!) The bug you're referring to I think is https://github.com/mattgodbolt/jsbeeb/issues/132 - which is a Beeb only thing, right? :)

User avatar
Pernod
Posts: 1340
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: MAME: Video handling

Post by Pernod » Tue Jul 18, 2017 8:14 pm

tricky wrote:PS Good luck, that is quite a task you have set yourself.
PPS The code in b-em is pretty good, as I suspect is the jsbeeb implementation (neither support the bit above correctly though :()
Thanks, but the code in other emus combines the 6845, Video ULA, and other circuitry to get the desired result, so not easy to see what belongs to each device.

So are you saying the problem lies in the HD6845 implementation? This device is used in almost 100 other computers in MAME, not including arcade machines, so need to ensure any changes are correct and don't adversely affect other machines. I did make a change awhile ago that was specific to the HD6845 and inadvertently broke the arcade game Malzak, though did allow a hack be removed from the Olivetti drivers, so need to careful.

Just need to know where to focus my attention.
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
tricky
Posts: 2950
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MAME: Video handling

Post by tricky » Tue Jul 18, 2017 9:17 pm

Matt, the mode 7 mapping at &3c00 is model A/B and maybe B+, not on the master as far as I know. I think of it as a minor missing feature that has never been used afaik.

Pernod, are you referring to the "mode 7" mapping "bug" or something else?
When I looked at MAME, it didn't seem to do well with any unusual modes, so it is probably just missing a few features.

User avatar
Pernod
Posts: 1340
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: MAME: Video handling

Post by Pernod » Wed Nov 22, 2017 6:57 pm

I have some serious graphics corruption on the Master, any suggestions on what could cause this?
0063.png
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

Coeus
Posts: 1112
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: MAME: Video handling

Post by Coeus » Tue Dec 05, 2017 7:31 pm

tricky wrote:On a real beeb, setting R12/R13 start of display address gives the following results (see http://www.retrosoftware.co.uk/forum/vi ... 00..#p7729)::

Code: Select all

&2000..&23FF displays &3C00+R12R13 wrapping after &3FFF to &3C00
&2400..&27FF displays &3C00+R12R13 wrapping after &3FFF to &7C00
&2800..&23FF displays &7C00+R12R13 wrapping after &7FFF to &7C00
&2B00..&23FF displays &7C00+R12R13 wrapping after &7FFF to &3C00
Although I haven't worked through how to implement this I think it is exploiting a quirk of the combination of a bunch of NAND gates and an adder used to do hardware scrolling and it may be exploiting something that is necessary to get the scrolling to work on a 16K machine. This was presumably redesigned for the master which, obviously, never had a 16K version.

This is the logic from the schematic:
hscroll.png
So the lower 8 bits of the address from the 6845 go to the RAM as-is whereas the next most significant 4 bits are added to the value produced by the bunch of NAND gates before being fed to the RAM.

So, if my working out is correct, the truth table for that bit of logic is:

Code: Select all

MA12 C1 C0 B4 B3 B2 B1
 0   X  X  1  1  1  1
 1   0  0  0  1  1  1
 1   0  1  1  0  1  1
 1   1  0  0  1  0  1
 1   1  1  1  0  1  0
MA12 should be equivalent to A15 as seen by the processor. As an interesting quirk it looks like the adder is adding 1111 even when the address has not wrapped, i.e. gone to 8000 and above but then the carry input is tied high so that should mean the equivalent of adding 1000 which should set carry out high and leave S1-S4 as copies of A1-A4.

User avatar
tricky
Posts: 2950
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MAME: Video handling

Post by tricky » Tue Dec 05, 2017 10:32 pm

Pernod wrote:I have some serious graphics corruption on the Master, any suggestions on what could cause this?
0063.png
Looks like it thinks parts of the screen are in another mode!
Have you captured the memory and tried it in another emulator, in the unlikely event that it is actually the wrong values in memory (unrelated bug).

User avatar
ctr
Posts: 192
Joined: Wed Jul 16, 2014 2:53 pm
Contact:

Re: MAME: Video handling

Post by ctr » Wed Dec 06, 2017 1:56 am

This graphics corruption on the master could be caused by the code using OS lookup tables to render pixels. The lookup tables moved between the beeb OS and master OS so code that relied on them broke on the master. In other words, it wouldn't work on a real master. The successful text rendering supports this theory, but I am just guessing.

User avatar
Pernod
Posts: 1340
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: MAME: Video handling

Post by Pernod » Sun Mar 18, 2018 12:47 pm

Can anyone recommend some good test cases for testing the B+ shadow RAM and Master ACCCON registers?

Edit: The above video corruption was caused by not correctly selecting Shadow RAM on reads from VDU drivers, now fixed and looks good :)
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
Pernod
Posts: 1340
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: MAME: Video handling

Post by Pernod » Sat Apr 14, 2018 4:36 pm

I'm taking a look at improving the Electron video handling, and I think it's not actually that bad at the moment.
ThomasHarte wrote:Re: palettes and modes, switching palettes on the 100Hz interrupt is the most common way to hide program data within the display, given that there's no CRTC so you can't just redefine the display size to increase your room for program data.

More complicated things, off the top of my head, if memory serves:
  • Gauntlet (in the game menu), Kane and at least one of the flight simulators that is probably 737 Flight Path change mode mid display. The latter does it several times for a menu screen, switching between the 80-column and 40-column modes;
  • Southern Belle and Evening Star also use a palette swap to hide data, but trigger on a tape data-related interrupt;
  • Spy vs Spy switches to black at the 100Hz interrupt, then busy loops for a while, then switches back to colours. So it hides data in a thin band in the middle of the display;
  • Sphere of Destiny is almost entirely a busy palette-changing loop;
  • Firetrack switches between modes 6 and 5 after counting in a busy loop to get a hardware scroll.
With regards to the above test cases:
  • Gauntlet (in the game menu) - looks good
  • Kane - data showing at top of screen
  • Flight Path 737 - interesting test case, looks better than Elkulator but I have timing issues on the mode/palette changes
  • Southern Belle and Evening Star also use a palette swap to hide data - not tested
  • Spy vs Spy switches to black at the 100Hz interrupt - data in middle of screen not completely hidden
  • Sphere of Destiny is almost entirely a busy palette-changing loop - looks good
  • Firetrack switches between modes 6 and 5 after counting in a busy loop to get a hardware scroll - no comment for now
What is the 100Hz interrupt and how does it hide data?
Last edited by Pernod on Mon Apr 16, 2018 1:31 am, edited 1 time in total.
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
Pernod
Posts: 1340
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: MAME: Video handling

Post by Pernod » Sun Apr 15, 2018 12:01 pm

Improved the timing and Flight Path 737 looks good.
This menu is a great test for timing to ensure each colour band lines up with each option correctly.
0136.png
0137.png
Anyone know what 3D Pool does to look like this:
0138.png
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

ThomasHarte
Posts: 467
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: MAME: Video handling

Post by ThomasHarte » Mon Apr 16, 2018 1:17 pm

Sorry, I've used '100Hz interrupt' as an incorrect term for the real-time clock interrupt, because it plus display end are used to produce the 100Hz interrupt offered to paged ROMs.

So I've managed simultaneously to be both misleading and factually incorrect. It's a 50Hz interrupt.

As I treat Paul Boddie's document as the bible nowadays, which I'm sure you've discovered, so don't believe that the 100Hz is regular, as the real-time clock interrupt is fixed at every 40000 cycles but display end is at the end of that field's display which is either 312 or 313 lines since the previous depending on whether it's an odd or even frame.

I can't say I'm sure what's going on with your 3d Pool — that's where the graphics are supposed to be, but there should be a black background behind the text, inside a green border. The colour fringing on the text is correct. Has a palette write gone missing somehow?

User avatar
Pernod
Posts: 1340
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: MAME: Video handling

Post by Pernod » Mon Apr 16, 2018 4:54 pm

ThomasHarte wrote:I can't say I'm sure what's going on with your 3d Pool — that's where the graphics are supposed to be, but there should be a black background behind the text, inside a green border. The colour fringing on the text is correct. Has a palette write gone missing somehow?
It could well be a palette issue. Judging by my Spy vs Spy and Ravenskull screenshots it looks like we have an abundance of green!
0140.png
0139.png
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
Pernod
Posts: 1340
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: MAME: Video handling

Post by Pernod » Tue Apr 17, 2018 9:33 am

Found the bad palette write and everything looks good:
0141.png
0142.png
I believe the Electron in MAME is now about on par with Elkulator and certainly exceeds in configurability and supported peripherals. Timing is not 100% but is closer to the real thing than Elkulator. The only game that I'm aware of having issues is Firetrack.
Hope it gets some serious use after the 0.197 release.
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
davidb
Posts: 2253
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: MAME: Video handling

Post by davidb » Tue Apr 17, 2018 10:23 am

It looks very good now! :D Well done!

Have you tried Southern Belle? I previously thought it didn't work in Elkulator until I just tried it to check. It's possibly not quite right, as the attached screenshot shows.

I can also provide you with a couple of ROMs (yes, literally ROM images) that should exercise your emulation a bit. Is that interesting?
Attachments
Southern-Belle-Elkulator.png

User avatar
Pernod
Posts: 1340
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: MAME: Video handling

Post by Pernod » Tue Apr 17, 2018 10:42 am

davidb wrote:Have you tried Southern Belle? I previously thought it didn't work in Elkulator until I just tried it to check. It's possibly not quite right, as the attached screenshot shows.
Not yet, UEF is still not great and unable to load Southern Belle, no disc image of it either.
davidb wrote:I can also provide you with a couple of ROMs (yes, literally ROM images) that should exercise your emulation a bit. Is that interesting?
It's interesting, but if you're referring to palette changes during scanline then I doubt I'm there yet. Post some test cases and I'll see how it handles them.
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
davidb
Posts: 2253
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: MAME: Video handling

Post by davidb » Tue Apr 17, 2018 11:01 am

Maybe give these a try.

Use the title.rom file from inside this archive:
multirom-2018-04-17.zip
(33.26 KiB) Downloaded 23 times
Use the mgctitle.rom file from this one:
vertical-scrolling-2018-04-17.zip
(69.57 KiB) Downloaded 20 times

User avatar
Pernod
Posts: 1340
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: MAME: Video handling

Post by Pernod » Tue Apr 17, 2018 11:18 am

Excellent test cases, though unsurprisingly I need to work on the scrolling:
0143.png
0144.png
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
davidb
Posts: 2253
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: MAME: Video handling

Post by davidb » Tue Apr 17, 2018 1:59 pm

Don't let those test cases discourage you. They're quite challenging and Elkulator doesn't get them quite right, either. :)

Southern Belle is on the Five Star Games 3 disc, so perhaps you might like to try that. It didn't work for me using Elkulator but maybe I did something wrong.

User avatar
Pernod
Posts: 1340
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: MAME: Video handling

Post by Pernod » Tue Apr 17, 2018 2:41 pm

davidb wrote:Don't let those test cases discourage you. They're quite challenging and Elkulator doesn't get them quite right, either. :)
Not at all, though I've achieved what I wanted for this release. I'll be moving back to BBC video next as split modes haven't worked for maybe 10 years!
davidb wrote:Southern Belle is on the Five Star Games 3 disc, so perhaps you might like to try that. It didn't work for me using Elkulator but maybe I did something wrong.
I wish it was, it's shown in the menu but the MENU code clearly only handles 6 out of the 7 game options, and no sign of it on the disc.
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
davidb
Posts: 2253
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: MAME: Video handling

Post by davidb » Tue Apr 17, 2018 3:14 pm

I quickly created a disc image for testing. I'm not sure how useful it will be.
Attachments
SouthernBelle.ssd.zip
(15.47 KiB) Downloaded 13 times

User avatar
hoglet
Posts: 7694
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MAME: Video handling

Post by hoglet » Tue Apr 17, 2018 3:22 pm

One thing to be aware of with Southern Belle is that if there are additional ROMs in the system, then it doesn't seem to work quite right, because of the additional interrupt service time.

See:
http://www.stardot.org.uk/forums/viewto ... 38#p150938

User avatar
davidb
Posts: 2253
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: MAME: Video handling

Post by davidb » Tue Apr 17, 2018 3:46 pm

Thanks for mentioning that. It explains why running a ROM conversion of the game shows less of the playing area than it should do. I'd have to "unplug" the ROM it loaded from before jumping into the game code and I'm not too sure how I'd do that reliably. :)

User avatar
Pernod
Posts: 1340
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: MAME: Video handling

Post by Pernod » Tue Apr 17, 2018 4:27 pm

davidb wrote:I quickly created a disc image for testing. I'm not sure how useful it will be.
Thanks, but worse then Elkulator, I get nothing but a blank screen. I'll re-visit it when I can load it from UEF.
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
davidb
Posts: 2253
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: MAME: Video handling

Post by davidb » Tue Apr 17, 2018 4:32 pm

It does take a few minutes to start, but I also found that it never seems to get to that point when loaded from DFS.

User avatar
daveejhitchins
Posts: 4532
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: MAME: Video handling

Post by daveejhitchins » Wed Apr 18, 2018 6:25 am

hoglet wrote:One thing to be aware of with Southern Belle is that if there are additional ROMs in the system, then it doesn't seem to work quite right, because of the additional interrupt service time.
This is one of the issues that I wanted to 'fix' for the MGC e.g. disabling all ROMs other than the OS, BASIC and the MGC itself. I didn't get it working correctly, however, I aim to work on this (with help, in this case!!) for MGC MK II.

Couldn't something be added to Southern Belle to achieve something similar?

Another goal, for MGC, was DavidB's MGC scrolling intro screen - I just love it . . . There were a few issues to overcome e.g. Space in the Main ROM image (I believe I have a fix for this now) and life issues at the time. I'd still like to add it to MK I, though, and offer is as an upgrade for anyone who may want to change their Games list.

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ARA III, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

ThomasHarte
Posts: 467
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: MAME: Video handling

Post by ThomasHarte » Wed Apr 18, 2018 12:59 pm

Pernod wrote:
davidb wrote:I quickly created a disc image for testing. I'm not sure how useful it will be.
Thanks, but worse then Elkulator, I get nothing but a blank screen. I'll re-visit it when I can load it from UEF.
Make sure you've got the tape interface implemented correctly; if memory serves then it puts the tape hardware into output mode and feeds it bytes, with an interrupt trigger of new data received. Interrupt detection is independent of the mode; if you're triggering new data received only when the tape is input mode then Southern Belle will never display anything.

User avatar
davidb
Posts: 2253
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: MAME: Video handling

Post by davidb » Wed Apr 18, 2018 2:05 pm

I should write a test case for the tape interface palette/timer trick, just to make it easier (and quicker) to see if an emulator is handling it properly. Southern Belle takes ages to start even when it works. :)

I suspect that it doesn't work at all when run from DFS, as Elkulator manages the tape version OK but not a DFS-loaded version. Well, it didn't seem to get beyond a blank screen for quite some time, so perhaps it was eventually going to work. ;)

I got it to run "properly" from ROMFS by executing code to write zeros to addresses &2A0 to &2A3 just after loading the main executable, but before jumping into it. As you can see, it's not looking perfect, but compare it to the screenshot of the tape version in Elkulator that I posted earlier.
Attachments
SouthernBelle-ROMFS.png

ThomasHarte
Posts: 467
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: MAME: Video handling

Post by ThomasHarte » Wed Apr 18, 2018 3:39 pm

If you want to send a modified ROMFS copy to test in Clock Signal, I can definitely do that. It runs the tape-based Southern Belle and everything else I've ever thrown at it correctly.

Post Reply