New experimental MiSTer emulator

[lushprojects]

New observation: The scaler copes OK with characters that have horizontal or vertical lines. It's just diagonals that judder. Obviously the scaler isn't coping well with situations where adjacent lines on different fields have different content.

[hoglet]

New observation: The scaler copes OK with characters that have horizontal or vertical lines. It's just diagonals that judder. Obviously the scaler isn't coping well with situations where adjacent lines on different fields have different content.

What video signal format are you actually trying to output to the analog monitor?

If you are trying to output 576i Analog Video, like a real Beeb, that will work with a TV/Monitor's SCART input, then you need to completely bypass any scaling that MiSTer is trying to do.

If you are tring to connect to a TV/Monitor's VGA input then it gets more complicated:

1 - You need a TV/Monitor that supports VGA with 50Hz VSYNC (most don't)

2a - You need a TV/Monitor that supports VGA with 15.625KHz HSYNC (most don't)

-- or --

2b - You need a scandoubler/deinterlacer that will generate 31.250KHz HSYNC. Just scan-doubling an interlaced signal with different odd/even fields (like MODE 7) looks awful. Doing a proper job of de-interlacing is difficult.

-- or --

2c - You need to enable the vga_mode setting when in MODE 7. This makes the Beeb FPGA Core generate lines at twice the line rate with the odd/even fields mixed. i.e. a 576p signal.

Even doing all this, a 50Hz/31.250KHz signal is a non-standard VGA signal. So many VGA monitors will not handle it will.

Dave

[lushprojects]

Thanks Dave,

I understand what you're saying and it would be pretty easy to setup any of the options for one output. The snafu is that MiSTer conventionally outputs both analog and HDMI simultaneously. MiSTer forks the signal after it's output from the core and has one path going to the VGA socket for analog output and another going to the HDMI (terrible ASCII diagram below). You have to try and make the signal work down both paths. The "ScanDoubler" seems to be a misnomer in the HDMI path. It's really an effects patch for CRT etc.

You can put a real ScanDoubler in the VGA path, but by default it's just a transparent pass through.

A further convention is that the VGA connector doesn't necessarily carry VGA compatible signals. A lot of cores just output PAL RGB signals and users use a custom lead to feed that to SCART inputs on TVs.

Code: Select all

                    +- Scaler and "ScanDoubler" -- HDMI Connector
Core Video Output --+
                    +- Sync Muxing (Optional) -- VGA Connector

So, my plan would be to output 576i to the VGA connector (not comatible with actual VGA, but compatible with the MiSTer VGA->SCART path). That will be done by having the core generate real BBC signals and pass them straight through to the VGA. The only problem is that for Mode 7 that doesn't work well though the HDMI path currently so I need to dig into whether the HDMI path can be tweaked so I can get both outputs looking nice at once.

[lushprojects]

PS - at least the above is what I *think* happens, but I might be completely wrong!

[hoglet]

I understand what you're saying and it would be pretty easy to setup any of the options for one output. The snafu is that MiSTer conventionally outputs both analog and HDMI simultaneously.

OK, now I understand the problem.

Can a MiSTer core tell if there is actually a HDMI monitor attached and adapt it's behaviour accordingly?

For example, does the HDMI_WIDTH input become 0 if there is no HDMI monitor attached?

Dave

[lushprojects]

Can a MiSTer core tell if there is actually a HDMI monitor attached and adapt it's behaviour accordingly?

Interesting question. There doesn't seem to be anything exposed over the API to the core that allows it to detect if there is anything connected to HDMI. HDMI_WIDTH retains the last value if you unplug HDMI.

The API to the core only exposes a fraction of the information being processed by the platform, so there might be a signal in the internals, but I am not sure I want to start customizing the platform code.

TBH it's probably OK to just put a manual option in the menu. It's klunky, but probably OK for real use-cases.

[DutchAcorn]

The original MiSTer BBC Micro core has mode 7 working over hdmi+analogue, can the mode 7 implementation in the experimental core benefit from what is done there?

[hoglet]

The original MiSTer BBC Micro core has mode 7 working over hdmi+analogue, can the mode 7 implementation in the experimental core benefit from what is done there?

When you say it's working over HDMI, can you comment on whether the character rounding looks correct?

A close-up photo of some text would be great.

I'm operating somewhat blind here, because I don't have a MiSTer system myself to experiment with.

Dave

[DutchAcorn]

The original core does not have character rounding. They look pretty poor compared to the core lushprojects shared.



Original core HDMI:

CF36546A-15EE-452C-BFCB-016FC6D54235.png (80 KiB) Viewed 2127 times

Original core RGB:

7630E40F-9FAA-4F91-8CB5-4CB71056FE6D.png (106.52 KiB) Viewed 2127 times

Lushprojects core HDMI

A974DDBF-C6AD-4B8D-870D-97B78315D545.jpeg (22.74 KiB) Viewed 2127 times

Real BBC RGB (for comparison)

83F58BC9-30A0-42D5-9068-1408CC156970.png (94.03 KiB) Viewed 2127 times

[lushprojects]

The original MiSTer BBC Micro core has mode 7 working over hdmi+analogue, can the mode 7 implementation in the experimental core benefit from what is done there?

The problem is that there isn't enough lines in a TV signal to support rounded characters unless you turn on interlace.

If you don't have the character rounding then there is no problem. You can just generate a non-interlaced 16kHz signal which also converts nicely to HDMI.

If you have character rounding then you either need 16k interlaced analogue which has bad quality when converted for the HDMI, or 32k analog with no interlace which breaks compatibility with TVs and 16k monitors.

On the whole I think the easiest is to have a menu option and let people choose what works for them.

[hoglet]

On the whole I think the easiest is to have a menu option and let people choose what works for them.

I think this is the best of the available options.

Dave

[DutchAcorn]

Any idea why HDMI is apparently fine with mode 0-6 in interlaced mode (default setting for the model B) but has issues with mode 7?

[lushprojects]

Any idea why HDMI is apparently fine with mode 0-6 in interlaced mode (default setting for the model B) but has issues with mode 7?

The scaler used to generate the HDMI seems to work fine if adjacent lines on odd/even interlaced fields have the same content. That's why Modes 0-6 work and also why vertical and horizontal lines in Mode 7 are OK (on my verison using 576i for M7). With character rounding on the adjacent lines on M7 charaters with diagonals are different, and the scaler doesn't cope well with this.

Possibly tweaking the scaler could fix it, but I haven't found a way yet. I am going to try the user option route today.

[DutchAcorn]

I realize you were just sharing a core that was tuned to your requirement for others to enjoy and that analogue video out was not one of those requirements.

So again, thanks for your work on this core, very much appreciated!


To me the analogue RGB video is one of the MiSTer features that you obviously can’t find in an emulator and gets it much closer to a real hardware experience.

[lushprojects]

No problem. I appreciate the comment! The analogue output was something that I had meant to look at, but just not quite so soon.

I've just uploaded a version https://github.com/sharpie7/BeebFpga_Mi ... 220306.rbf which allows you to choose the format of the analogue output for Mode 7.

If you set 'M7 Analogue Video' to '576i' in the menu you should get analogue ouputput in M7 that works with your monitor. Let me know.

It will be interlaced, so have the judder, but that is of couse the authentic BBC Micro experience!

[DutchAcorn]

Works great!

No visible judder, a nice stable image on my 15KHz monitor.

[lushprojects]

Works great!

Great!

[j6wbs]

Just a quick note to say thanks to lushprojects for sharing these new versions of the Beeb core (and hoglet for everything he does), I have installed and played with it, and it is wonderful to see Mode 7 correctly on my MiSTer at last. I’ll be excited to follow along with any updates. Thanks for all your hard work on this.

Jez

[tricky]

Great work.
Is it best to subscribe on github to spot updates?

[lushprojects]

Great work.
Is it best to subscribe on github to spot updates?

Yes. I'll post them there

[DutchAcorn]

....
Thanks for posting the Music 500 disk. I will add that to my collection.

Did you find the M5000/M500 collection links posted on the forum? See here: viewtopic.php?f=2&t=15780

[lushprojects]

I just posted a small update which improves HDMI output when sending Move 7 interlace to the analogue video.

It turns out that MiSTer does let you pass odd/even field information to the scaler (I was looking in the wrong plage and didn't see this), and if you do this then it does generate better output in Mode 7. However, it's still generally better to use Mode 7 progressive if you using the HDMI output so I've kept the menu option.

[DutchAcorn]

Is there a way to save the cmos settings for the Master core? With the DFS selected as a file system it currently boots with the unsupported ADFS file system selected. It would be nice to be able save the cmos aettings with FILE “9” (1770 DFS) (and, for example, mode 128).

Is it ok if I notify the MiSTer fpga forum of this experimental core? It is a major step-up from the current crippled game-jukebox core, others will likely be interested.

[lushprojects]

Is there a way to save the cmos settings for the Master core? With the DFS selected as a file system it currently boots with the unsupported ADFS file system selected. It would be nice to be able save the cmos aettings with FILE “9” (1770 DFS) (and, for example, mode 128).

I can certainly change the default for the file system.

Actually storing the CMOS settings would take some more effort, but might be possible if I have time. I wonder actually if the "Master" modes could be added to the boot option (maybe as with a fallback to the BBC modes if booting on a BBC B). I will do some digging.

Replied privately re the other forum.

[DutchAcorn]

There is a graphics issues that seems to be present on all the cores; in mode 0 the screen is cut off by one pixel on the right. HDMI output as well as analogue.

It is quite clear in Starship Command:

[lushprojects]

There is a graphics issues that seems to be present on all the cores; in mode 0 the screen is cut off by one pixel on the right. HDMI output as well as analogue.

Ah ha. I see it on mine too. I will investigate.

[lushprojects]

There is a graphics issues that seems to be present on all the cores; in mode 0 the screen is cut off by one pixel on the right. HDMI output as well as analogue.

The problem is that the horizontal blanking period is starting just before the last pixel on the line is output. The blanking timing coming from the 6845 appears to be right (relative to HYSYNC), but the pixels appear to be a little later than they should be - likely one pixel delayed. Not sure why this is at the moment. @hoglet might have some good ideas (if he is reading this).

[lushprojects]

There is a graphics issues that seems to be present on all the cores; in mode 0 the screen is cut off by one pixel on the right. HDMI output as well as analogue.

Just uploaded a new release that should fix that. Let me know if it works for you.
https://github.com/sharpie7/BeebFpga_Mi ... 220317.rbf

I had to add a delay to the horizontal blanking to stop it cutting off the last pixel in the line. The pixels now seem to fit 100% with the blanking signals.

I am not sure why this should be necessary if the simulation is correct, but pragmatically it seems to work. Interested to know @hoglet's thoughts when he next looks in.

[hoglet]

I am not sure why this should be necessary if the simulation is correct, but pragmatically it seems to work. Interested to know @hoglet's thoughts when he next looks in.

I've been away from home this last week. Back now so I'll have a look at this over the weekend.

Dave

[DutchAcorn]

There is a graphics issues that seems to be present on all the cores; in mode 0 the screen is cut off by one pixel on the right. HDMI output as well as analogue.

Just uploaded a new release that should fix that. Let me know if it works for you.
https://github.com/sharpie7/BeebFpga_Mi ... 220317.rbf

I had to add a delay to the horizontal blanking to stop it cutting off the last pixel in the line. The pixels now seem to fit 100% with the blanking signals.

I am not sure why this should be necessary if the simulation is correct, but pragmatically it seems to work. Interested to know @hoglet's thoughts when he next looks in.

Seems to work fine, thanks for the fix!

Of course I don't know if an added delay impacts the accuracy of the core.