MAME: Video handling

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

MAME: Video handling

Postby 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, etc.

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

Re: MAME: Video handling

Postby 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+[I think]) 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: 153
Joined: Mon Jul 31, 2006 10:02 am
Location: Chicago
Contact:

Re: MAME: Video handling

Postby 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: 933
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

Re: MAME: Video handling

Postby 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, etc.

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

Re: MAME: Video handling

Postby 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.


Return to “emulators”

Who is online

Users browsing this forum: pau1ie and 3 guests