MAME: Video handling

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
Pernod
Posts: 997
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: 1916
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: 163
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: 997
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: 1916
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.

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

Re: MAME: Video handling

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

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

Re: MAME: Video handling

Postby 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: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MAME: Video handling

Postby 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: 94
Joined: Wed Jul 16, 2014 2:53 pm

Re: MAME: Video handling

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


Return to “emulators”

Who is online

Users browsing this forum: kieranhj and 4 guests