Nice! I am currently using this nMediaPC case.
https://www.newegg.com/black-nmediapc-htpc-6000b-atx-media-center-htpc-case/p/N82E16811204037
I’m fairly certain in will accommodate my Z170S and GTX 1070 after I finish my R&D.
I’m honestly kind of hoping it won’t. 
Once I get my living room painted and a new OLED TV mounted on the wall… I might like to try this case and do away with my TV stand.
https://www.newegg.com/space-gray-thermaltake-core-p-series-atx-open-frame-chassis/p/N82E16811133153
It reminds me of this case I saw a couple years ago:
This one looks pretty elegant and stylish. Dust might be an issue over the long term though.
Just in case everyone is as far behind as I am… there have been some new cores added to RA. a5200, (Which makes running both Atari800 and Atari 5200 ROMs a lot easier by using separate cores.) WASM-4, (Which is already on my list.) Same CDi, (Which greatly increases the CDi playable library.) Arduous, (Which has now been added to my handheld list.) and Jump 'n Bump.
Also added to my list but will just needs a TV7 Mod. (So far the games I’ve tried are fairly pointless but it runs and looks good so…)
I love the fact that advances in RA will make this a never ending project!
Thanks to @TVsIan I will be adding the Interton Electronic VC 4000 to my MAME SL list.
It doesn’t require the traditional software list method so was missed during my search. I wonder how many other systems have been missed for the same reason. 
The graphics are simple, and the game controls a bit weird, but it does have 37 games in the SL which is more than some systems. 
I can’t get the NDS presets to work properly with the touch screen. I’m using melonDS in Touch Mode, but when the shader is applied the viewport is not aligned with the boundaries of the touch screen. So basically you need to click not where the screen is displayed but where it would be displayed without the shader, if that makes sense. What am I missing?
I have no experience using touch mode with the Mega Bezel.
Does it work correctly with the handheld border shader?
Other discussions by @hunterk lead me to believe not. I will assume you need to use a standard overlay with touch mode.
No indeed. So is it an issue with this core specifically? What’s odd is that the touch screen correctly understands scaling, if the window is in 1x 2x 3x or whatever, the touch screen zone is still placed correctly, but when an shader is applied it doesn’t follow.
Basically what happens is the core outputs an image and the touchscreen surface corresponds to this image. Then the shader adjusts the image by scaling and moving it, and the touch screen area is unchanged, and therefore doesn’t match the image you see.
To have a fix for this we would have to send the new window coordinates of the scaled and moved screen out of the shader, which is not part of the framework.
So if you really need the touch screen interaction then you’ll have to use a standard overlay like Duimon suggests. I don’t think there is any way around this at the moment.
I see. But I’m not sure it can be solved by an overlay, can it? With the DS in mind if I want the final result to look like that screen posted in the OP I’d still need a border around the rendered area. Even if I find out how to do that, the problem might be still the same. Unless the overlay is able to resize the whole image + touch area. Hm.
Makes me wonder though, how do you all use your DS games, without the touch screen? Mouse mode has awful acceleration on my end.
The mouse is mapped to the right joystick on a gamepad.
I believe the overlay system is compatible with touch mode. I have overlay versions of my graphics in my overlay repo.
https://github.com/Duimon/Retroarch-Overlays
I can help you with the coordinates if you’d like to try them.
Here is my NDS Vertical Alt overlay using the “lcd-grid-v2-nds-color.slangp” shader.
For 4K the needed info is:
X Position = 1363
Y Position = 83
Width = 1112
Height = 1976
Screen gap = 70
If gap distance is more important to you than screen size, my NDS Vertical (Not Alt) has the ideal gap distance.
I updated the above info with accurate coordinates taken from Photoshop.
If you are using DeSmuME you can create a DeSmuME.cfg text file and put it in your /config/DeSmuME folder.
DeSmuME.cfg contents:
aspect_ratio_index = "23"
input_overlay = ":\overlays\Duimon\Nintendo_NDS\NDS_Vertical_Alt.cfg"
input_overlay_opacity = "1.000000"
custom_viewport_height = "1972"
custom_viewport_width = "1106"
custom_viewport_x = "1367"
custom_viewport_y = "85"
This assumes you have put my “logo” overlay set in Retroarch\overlays\Duimon\
It also assumes you are using Windows. For Linux you would have to define the path ":\overlays\Duimon\Nintendo_NDS\NDS_Vertical_Alt.cfg" without the :\.
You will also need a “DeSmuME.opt” with at least…
desmume_screens_gap = "70"
desmume_screens_layout = "top/bottom"
Also in the config\DeSmuME folder.
Thank you very much for your help, this is all working perfectly 
So… I used my Potato graphics as my new standard overlays. The overlays are 4K while the Potato have been resized, using the “Mitchell” algorithm, to 1920x1080.
My Potato source is using a perfect mask, generated by the Mega Bezel, that can be used to get screen coordinates for the overlay configs. I have updated the above with new coordinates taken from this mask. (The difference is slight.)
I will be adding my potato source to my Mega Bezel source repo very soon, along with a guide in the overlay folder on getting the coordinates with Photoshop, Affinity Photo, Paint.Net, and Gimp. (For Gimp I will make use of a python script that displays coordinates.)
I will also be adding an example core config and a guide for it’s use.
Once I have the guides done I will add it to my GitHub Pages site as well.
The source is in the repo. To keep the size of the source repo below 10GB I created a new…
…repo. Guides are yet to be completed.
Edit: I need to split the commit into batches. It will be done later today.
I am thinking about handling the source for the overlays differently.
I think I will create a guide on how I created them, using the Mega Bezel tools, and include only some source. The vast majority use the same coordinates, and the PSDs are only two masked layers, one with a drop shadow.
I will still create the other guides, since they will benefit the community, and the methods can be used for any overlay.
It just doesn’t seem prudent to take up almost 3GB of GitHub space for something that can so easily be recreated.
FYI: somehow vectrex is upsidedown now I put everything on latest version today…
Hardware cores may or may not flip the viewport, and it can change with core updates. Use the flip viewport vertical parameter.
somehow this option did not flip the vectrex overlay , so I rotated alle images in Graphics\GCE_Vectrex\Vectrex_Overlays
The Gel Layer, which is the layer that contains the Vectrex screen overlay, also has a flip vertical parameter.
We have been dealing with inconsistent hardware rendered cores for a long time and @HyperspaceMadness has added a solution for “just about” everything you might encounter.
Which reminds me… I flipped the Vectrex overlays while waiting for a fix and forgot to flip them back. I will do so ASAP.