MAME: Video handling

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
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 3:50 pm

I've attached an archive containing two ROMs to this message. If it crashes with data on the screen while loading then you need to swap the ROMs around so that the other ROM starts first. Hope that makes sense. :)
Attachments
SouthernBelle-ROMFS.zip
(16.15 KiB) Downloaded 17 times

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 3:55 pm

You might also want to try the other ROMs I posted earlier to see if they also work in Clock Signal, Thomas. ;)

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

Re: MAME: Video handling

Post by tricky » Wed Apr 18, 2018 5:02 pm

Pernod wrote:...I'll be moving back to BBC video next...
If you have to add any debugging code to get the 6845 etc implemented correctly, it would be great if you could leave it accessible.
I did have to write a mini sim to get some of my games working, but a debugger would be great.

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

Re: MAME: Video handling

Post by ThomasHarte » Wed Apr 18, 2018 9:55 pm

davidb wrote:You might also want to try the other ROMs I posted earlier to see if they also work in Clock Signal, Thomas. ;)
Assuming this is of the smoothness intended, success!

I'm about to test Southern Belle, but have discovered a bug in inserting a second ROM. So will be back to comment on that in the near future. A screenshot of the tape version is attached. And, for the record, I make it 11 seconds of a blank screen before the menu appears. That's with fast loading enabled; I haven't bothered to check whether it's loading anything while blank but I strongly suspect not.
Attachments
Screen Shot 2018-04-18 at 17.52.08.png

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

Re: MAME: Video handling

Post by ThomasHarte » Wed Apr 18, 2018 10:11 pm

Obviously this could very easily be an emulation problem, but having inserted the Southern Belle ROMs in reverse order so that they'd load, I actually got a worse-than-Elkulator output as attached.

So in the configuration I tried, the only ROMs present are the OS, BASIC and the two Southern Belle ROMs. No Plus 1 ROM is anywhere in the memory map, and neither is anything else. I don't know if that's maybe too artificial?

EDIT: actually, by eye, the ratio isn't too far off what you'd expect from a real-time clock/end-of-display split. Probably just coincidence?
Attachments
Southern Belle ROMFS.png

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 10:53 pm

Interesting. Elkulator displays a black screen for a long time then shows the high speed run (demo). It may show a menu beforehand, but not 11 seconds after loading supposedly finishes, and I don't sit and watch the emulator so, when it finally shows something and I notice, that's what I see. I haven't tried it on a real Electron so I don't know what to expect, but it's a warning sign that you see something so different (and much quicker).

Recording a video of the tape version with my Elkulator fork, I see that the high speed run appears 3 minutes and 45 seconds after loading of the second file completes.

It's good to know that the MGC title works as expected for you. That's what it does on real hardware - you can't argue with that! ;)

Sorry to pernod for diverting your thread with this discussion. I hope you find it useful! We can take it elsewhere if you like.

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

Re: MAME: Video handling

Post by ThomasHarte » Wed Apr 18, 2018 11:03 pm

Apologies from me too.

Based on a quick check: it is loading while the screen is blank. So that's the timing discrepancy. If I turn off synthetic emulator fast loading, it is indeed blank for several minutes.

For me, using the Stairway to Hell copy, it always launches to the select difficulty / load saved run / view high speed run menu. But if I sit and wait for about 30 seconds, then it launches into its automatic demo.

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 11:43 pm

Just to finish up my side of this digression, I should say that I was loading using Elkulator's "Really Fast" loading option. Switching it off after loading the second file, I still get a couple of minutes or so of black screen until it finally shows the high speed run - no menu first.

Anyway, if either you or pernod need more test cases or ROM versions, just let me know and I'll try to oblige. :)

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

Re: MAME: Video handling

Post by Pernod » Thu Apr 19, 2018 12:51 am

davidb wrote:Sorry to pernod for diverting your thread with this discussion. I hope you find it useful! We can take it elsewhere if you like.
No problem, it's all relevant for testing. I tried your ROMFS version of Southern Belle and again just a blank screen, so very likely need to overhaul the tape interface. Very much appreciate everyone's assistance so far, and will return to the Electron after I've looked at a couple of BBC issues.
- Nigel

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

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

Re: MAME: Video handling

Post by Pernod » Thu Dec 06, 2018 1:36 pm

tricky wrote:
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.
I'm taking another stab at this!

You initially setup the 6845 to define the visible area 224x256, and MAME reconfigures the screen accordingly, no problem. But you then reconfigure the 6845 to be 224x8 for each character row, why doesn't this cause the visible area to be reduced to 8 lines? Every time you program R4 MAME is wants to reconfigure the visible area so under what condition shouldn't this happen?
- Nigel

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

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

Re: MAME: Video handling

Post by tricky » Thu Dec 06, 2018 3:27 pm

Continue expecting lines to be as "long" as they were last measured (64us?) and start a new one below the previous one after that time.
There will be a "known" time after the hsync (centre to simulate a PLL) that the beam starts on the left.
Keep counting/drawing lines, (in the Frogger case) in batches of 8 until you hit a vsync, then count another 54ish lines and start again at the top.
AFAIK, the hsync is the only thing that can cause the line "length" to change, and the vsync is the only thing that should move the drawing to anywhere other than the next line. I suspect that the 54 scan lines is how long it takes the beam to "fly back" up.
R4 doesn't configure the "visible" area, only how long to wait before latching R12/13 and when to insert the next offset lines and probably reset some other internal counters.
It is probably best not to think of setting up the screen with the 6845, but rather when it will trigger internal events, that at some point (hopefully ~20ms apart) will cause a vsync to start the next frame.
e.g. FPS should not be measures by multiplying registers together, but by counting vsyncs.
A screen capture should grab everything emitted between vsyncs, although you might want to add a border or MAX() it with other recent frames.

EDIT: Take note of the size of each counter so as to wrap at the correct point. I doub't than any code will intentionally rely on this, but if the code misses a vsync, waiting 0xFFFFFFFF 6845 cycles/lines/rows to hit another would be a problem.
Last edited by tricky on Thu Dec 06, 2018 3:31 pm, edited 1 time in total.

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

Re: MAME: Video handling

Post by Pernod » Thu Dec 06, 2018 7:38 pm

tricky wrote:
Thu Dec 06, 2018 3:27 pm
It is probably best not to think of setting up the screen with the 6845, but rather when it will trigger internal events, that at some point (hopefully ~20ms apart) will cause a vsync to start the next frame.
e.g. FPS should not be measures by multiplying registers together, but by counting vsyncs.
A screen capture should grab everything emitted between vsyncs, although you might want to add a border or MAX() it with other recent frames.
Thanks, I understand what you're saying, just need to work out how to implement this in the MAME eco-system without affecting any of the 100+ other machines that use the 6845 variants. I had a look at other CRTC implementations in MAME and they all seem to do the same, a register is changed that may affect the user visible area so reconfigure the output screen, clearly not how they work. I suspect the majority of machines simply setup the CRTC at startup and the visible area is never changed. I know the PC CGA card has a hack to improve the 8088MPH demo so hopefully anything I improve will help that too.
- Nigel

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

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

Re: MAME: Video handling

Post by tricky » Thu Dec 06, 2018 11:29 pm

Does mame support the CPC as they also use vertical rupture (and may have been the ones to coin the phrase). The c64 does other crazy stuff although not with a 6845.
I guess R3 isn't handled as it would be by a CRT, that will also fail on some CPC games.
I guess it would take a while to find out what other bodgrs are on top of or rely on the current 6845/CRT simulations.
I would think that the BBC/CPC emulator implementations would be more in the spirit of new mame, but probably clash with "if it ain't broke, don't fix it".

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

Re: MAME: Video handling

Post by Pernod » Fri Dec 07, 2018 11:02 am

The CPC is certainly supported, but never tried it and wouldn't know which software to look at to determine how good the video handling is. It's video handling looks overly complicated and seems to bypass the 6845 for anything timing related, preferring it's own custom solution. It would be frowned upon if I went this route with the BBC. I need to make the 6845 suitable for all in the hope any improvements will also benefit other machines.
Last edited by Pernod on Fri Dec 07, 2018 11:03 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
tricky
Posts: 2947
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MAME: Video handling

Post by tricky » Fri Dec 07, 2018 2:44 pm

Last time I looked, MAME went very detailed on some things, but displaying GFX was almost treated as 6845+VideoULD+SA5050+screen is not much more than a bitmap and fixed way of indexing it.
B-em would probably be a good place to start then.
I guess you might have to disentangle the Video ULA, or at least the palette optimisations related to it.
I can't think of an instance where "doing it properly" wouldn't work, except maybe the CPC instance where something is built on top.
You could try (Super) Edge Grinder on the CPC, it doesn't go too mad.

Post Reply