It looks like the GPIO pins are numbered starting at 0.
I referred to usual connector pin numbering starting from 1. Below are links to pictures which show the correct pin and possibly the easiest method which involves scraping some solder mask off the ground plane and adding a blob of solder.
After this mod it's recommended to detach DExx board from DE10-Nano when using some other firmware that drives the said GPIO pin.
sofakng wrote:
Also, I've successfully connected my DOS VGA PC to the DExx but I'm having a few issues.
1) Adaptive Line Multiplier using Line 4x (1920x1440p) cuts off the image and the image is distorted. I've tried both the VGA 640x400 and VGA 720x400 presets.
2) Pure Line Multiplier has an almost perfect image, but it's still slightly cut-off and looks soft (ie. Line 3x Generic is only 1600x1200 resolution on my 1440p monitor)
3) Scaler image looks perfect but is very blurry.
(A)LM modes are not the most suitable here since 4x 400 lines = 1600 lines, thus cropping is significant on 1440p monitor. With scaler you can set scaling algorithm to Nearest for sharpest picture.
OK - Thanks. I was wondering how you were multiplying 400p into 1440p but now I understand (ie. cropping).
The scaler looks very, very good at 1440p using Nearest (and the correct sampling preset) but the picture is still a bit unstable even after the modifications.
GPIO(2) -> GND using GPIO1 and de10n_gpio1 firmware: (extremely unstable, doesn't stay synced for more than a second or two) https://youtu.be/6UvA2LM7S14
sofakng wrote:The scaler looks very, very good at 1440p using Nearest (and the correct sampling preset) but the picture is still a bit unstable even after the modifications.
Is the source 70Hz? That would put more strain on the hardware compared to 60Hz, and 2560x1440@70Hz is way beyond capability of DE10-Nano. You could try if setting framelock to "Off (60Hz)" helps, but it may be that you need to settle to 1080p output if 1440p is not stable in your setup.
Yeah, I was just about to post that actually... (re: 70 Hz)
I've tried setting framelock to off (60 Hz) but it doesn't improve much. I understand that we are pushing the chip beyond it's limits though.
Thanks so much again for the help!
EDIT: Actually, I'm seeing the same issues at 1600x1200 and 1920x1080 (both at 70 Hz). Much lower resolutions (ie. 720p) don't seem to have the issue though.
Is it possible my DIY cable can cause these types of issues or it most likely the limit of the FPGA?
sofakng wrote:I've just tested my NESRGB console with the DExx and the scaler can output 1920x1440 (framelock on) with no issues at all.
Additionally, 2560x1440 also works (which doesn't work at all on the VGA PC) and the DE10-Nano FPGA doesn't feel nearly as hot.
Any 480p source you could try out to understand whether the issue occurs with any higher-res input (which are more taxing to the system) or just with the specific PC? Make also sure you use a PSU capable of supplying at least 2A.
marqs wrote:Any 480p source you could try out to understand whether the issue occurs with any higher-res input (which are more taxing to the system) or just with the specific PC? Make also sure you use a PSU capable of supplying at least 2A.
I'll see if I can find a 480p source and give it a test but I'm not sure what I have that can output SCART/RGB...
The power supply I'm using is USB-C PD PPS (100W) that supports 5V @ 4A so it should be OK.
Would you consider adding the ability to discard every other line and format it back to 320x200 (for processing) like you mentioned on the previous page? That should cut the processing requirements in half, right?
I'm primarily concerned about playing CGA/EGA DOS games which are 320x200 as you mentioned.
Any plans to add HDR for the DExx-vd, or is that only going to appear on the OSSC Pro?
The RT5X can flag the HDMI output as HDR10 (and results are very accurate on a calibrated monitor!), but doesn't have 720p120 with black frame insertion. The DExx-vd has the latter but not the former. If one of these could do both, we'd be all set as long as we have access to a quality HDR display with high nits capability (which often lacks any kind of flicker to clear persistence blur--OLED TVs do have BFI but don't have enough nits full screen, especially for 1080p, and also to compensate for the black frames).
fernan1234 wrote:Any plans to add HDR for the DExx-vd, or is that only going to appear on the OSSC Pro?
The RT5X can flag the HDMI output as HDR10 (and results are very accurate on a calibrated monitor!), but doesn't have 720p120 with black frame insertion. The DExx-vd has the latter but not the former. If one of these could do both, we'd be all set as long as we have access to a quality HDR display with high nits capability (which often lacks any kind of flicker to clear persistence blur--OLED TVs do have BFI but don't have enough nits full screen, especially for 1080p, and also to compensate for the black frames).
The HW should be able to set the needed (Infoframe?) metadata to flag signal as HDR, but output remains at 24bit so it is arguable whether you can call it proper HDR. For unlocking TV's full brightness potential it could be fine in any case.
marqs wrote:The HW should be able to set the needed (Infoframe?) metadata to flag signal as HDR, but output remains at 24bit so it is arguable whether you can call it proper HDR. For unlocking TV's full brightness potential it could be fine in any case.
Thanks for the reply! That's true, though I imagine 24bit will be more than adequate for digitized retro consoles. Great to hear the HW can do it! I'm sure there's other pressing things to do, but looking forward to it on an eventual FW update.
If anyone is sitting on the fence about dexx, I recommend grabbing one. Some of the higher line multiplier and scaler modes are excellent on on a large flat panel. 1920 x 1440 and 2560 x 1440 get a big dirty chef's kiss from me.
Also adding my vote to the concept of using dexx with the IO board. Would be excellent to be able to use dexx via HDMI and analog at the same time. Only issue with current design is the dexx IR receiver needs to be moved
sofakng wrote:Are you talking about using the MiSTer I/O board at the same time as the DExx?
If so, yeah that would be pretty awesome... (although I personally use the digital i/o board so I can use dual SDRAM sticks)
Yeah the MiSTer IO board. Be a nice feature to have for streamers and such.
Been having my first proper play around with the dexx recently, gotta say, that 2560 x 1440p mode is so clear and crisp - definitely my favourite feature of the dexx so far. Few issues left to figure out how to get it working on my HD CRT, but for flat panel it's awesome.
Are there any alternate points for the IR sensor that we can move it to? I think this would allow the board to fit under the MiSTer I/O shield.
Also, if anybody has any designs for a case or supports for the DExx I would also be interested. It's a little heavy hanging off the DE10-Nano. (I'm just using foam to support it for now)
There’s potential to just remove the IR receiver, fit the DE10, IO board and dexx back together and then reattach the IR. It could potentially be inserted through the IO board, as it has holes in the PCB that appear to directly align with the position of the IR.
A problem with this approach, is the the legs of the IR receiver could make contact with the traces on the IO board PCB. Whether this has impact on functionality is another matter. Could always try to use fine tape or heat shrink to insulate the IR receiver pins. Another issue is that the IR receiver legs may not be long enough, meaning a new receiver may be required.
I recently received my DExx-vd_isl and it is fantastic! I tested a bunch of consoles, and a few MSX computers, and only found a few issues.
Using GBI 240x360 mode with GBIHF, the aspect ratio is wrong in adaptive line multiplier mode. It seems to be scaled to 4:3, I think.
For 480p input resolutions at 2560x1440 in adaptive line multiplier mode, the Generic 16:9 preset does not have the correct aspect ratio, it is thinner than the Generic 4:3 preset.
rezb1t wrote:I recently received my DExx-vd_isl and it is fantastic! I tested a bunch of consoles, and a few MSX computers, and only found a few issues.
Using GBI 240x360 mode with GBIHF, the aspect ratio is wrong in adaptive line multiplier mode. It seems to be scaled to 4:3, I think.
For 480p input resolutions at 2560x1440 in adaptive line multiplier mode, the Generic 16:9 preset does not have the correct aspect ratio, it is thinner than the Generic 4:3 preset.
Hopefully these can be fixed in a future update!
LM horizontal multiplication factors are currently statically set and not yet tested for all possible combinations, but it's easy to fix these cases. A longer term solution would be calculating them dynamically as done in scaler mode.
sofakng wrote:I've been testing more with the DOS/VGA 720x400 and 640x400 and I noticed something.
If I use the [Generic] sampling preset I can output 1920x1440@70 without any instability. The picture looks perfect and doesn't lose sync or shift.
However, if I change the preset to anything except [Generic] then it introduces terrible horizontal shifting/instability.
Does the generic sampling preset use less lines making it easier on the DE10-Nano or can there be another issue?
Generic sampling preset with much higher sampling rate may indirectly affect the characteristics of the noise induced on ground plane. The GPIO tiedown workaround should have a major improvement so it's strange that didn't work for you.
rezb1t wrote:I recently received my DExx-vd_isl and it is fantastic! I tested a bunch of consoles, and a few MSX computers, and only found a few issues.
Using GBI 240x360 mode with GBIHF, the aspect ratio is wrong in adaptive line multiplier mode. It seems to be scaled to 4:3, I think.
For 480p input resolutions at 2560x1440 in adaptive line multiplier mode, the Generic 16:9 preset does not have the correct aspect ratio, it is thinner than the Generic 4:3 preset.
Hopefully these can be fixed in a future update!
LM horizontal multiplication factors are currently statically set and not yet tested for all possible combinations, but it's easy to fix these cases. A longer term solution would be calculating them dynamically as done in scaler mode.
I've been now annotating sampling presets with source aspect ratio and started to wonder if GBI preset should actually be 240x320 with AR of 3:2 instead of 240x360 with 4:3 AR? In most cases either one should be fine, but the latter would have advantages in a few corner cases assuming there's no UI elements outside of 320px height.
marqs wrote:I've been now annotating sampling presets with source aspect ratio and started to wonder if GBI preset should actually be 240x320 with AR of 3:2 instead of 240x360 with 4:3 AR? In most cases either one should be fine, but the latter would have advantages in a few corner cases assuming there's no UI elements outside of 320px height.
Yep there's no UI on GBIHF, which is the only version of GBI that can do the 240x360 mode, so this should be safe to do without worry of anything getting cut off the screen.
In addition to reducing it to 240x320, I think it would also be worthwhile to drop every other line, this would allow for 9x scaling for 2560x1440 which would fill the screen vertically. I'm not sure how difficult this would be to do, though.
marqs wrote:Generic sampling preset with much higher sampling rate may indirectly affect the characteristics of the noise induced on ground plane. The GPIO tiedown workaround should have a major improvement so it's strange that didn't work for you.
I've checked continuity between GPIO 2 and GPIO 12 and GPIO 30 (the GND pins on the GPIO header) and GPIO 2 is definitely grounded properly so I'm not sure either.
Can you explain the difference between the sampling presets?
Are you saying that the generic sampling preset is more demanding than the 640 or 640x400 sampling rates?
Last question -- is it possible to control the DExx using TCP or serial or anything besides the IR remote?
marqs wrote:Generic sampling preset with much higher sampling rate may indirectly affect the characteristics of the noise induced on ground plane. The GPIO tiedown workaround should have a major improvement so it's strange that didn't work for you.
I've checked continuity between GPIO 2 and GPIO 12 and GPIO 30 (the GND pins on the GPIO header) and GPIO 2 is definitely grounded properly so I'm not sure either.
Can you explain the difference between the sampling presets?
Are you saying that the generic sampling preset is more demanding than the 640 or 640x400 sampling rates?
Last question -- is it possible to control the DExx using TCP or serial or anything besides the IR remote?
Thanks!
As a simplified answer, generic sampling preset selects sampling rate based on output resolution while dedicated sampling presets have a fixed sampling rate. For 640x400 preset, sampling rate would be higher with generic preset in practice which means that ADC chip runs at higher frequency and also results to more traffic between FPGA and DDR3 memory. All that could make one think generic preset should be more prone to issues but unfortunately the problem is not that straighforward as there are various side effects. It appears that issues are more likely to arise when sampling clock and output pixel clock (both coming from DExx) are at very different frequencies. The signals might run close to each other on DE10-Nano PCB (of which layout unfortunately is not public) which could be part of the issue.
Control via TCP / serial is not currently implemented but it's something someone could look into. I'd prefer serial (USB Blaster JTAG UART) since TCP/UDP would be limited to boards with ethernet.
Design of custom framebuffer IP to enable rotation, screenshots and lower latency in scaler mode is one on the next things on todo. I should be able to start working on it after summer.
@marqs: any update regarding the rotation feature? I guess summer has passed already
Dexje wrote:@marqs: any update regarding the rotation feature? I guess summer has passed already
Addition of CRT modes and porting tasks to DE10-Nano HW stole the focus so scaler processing chain work got sidetracked. Now those are in quite stable state so it'd be better moment to start designing custom framebuffer IP supporting low-latency mode, rotation, screenshots etc. Before that a proper simulation enviroment would need to be set up since the design needs to interface with (not that great) Intel IP and bitstream compilation time already exceeds 10min which hinders prototyping. A dedicated scaler pipeline project could be the best approach with features eventually moving from that sandbox to ossc_pro / DExx-vd_isl firmware.
Is it possible to use a Time Sleuth and the DExx for lag testing 1920x1440 (4:3) from the MiSTer?
I think the DExx scaler adds up to one frame of lag, so I'm wondering if there is some combination of settings between the Time Sleuth and the DExx to use line multiplier mode and test the 1920x1440 (4:3 flag) latency?
EDIT: I forgot that the DExx only accepts analogue input so that won't work.
Maybe the DExx can integrate a built-in lag tester of some sort?
For the life of me I can't get the OSD menu to display...so I'm stuck, I don't have the 20x2 OLED (I ordered it earlier today though). Board came from VGP pre-soldered.
Cabled up, installed today's firmware on SD.
It boots fine, I can hear audio from my CPS2 coming from the monitor. I get the test pattern and a brief OSD flashes up:
"Test pattern
720x480. 59.94Hz"
I have the OSSC remote, when I press Menu I can see a flash of the green LED on the de10 but no OSD.
sofakng wrote:Is it possible to use a Time Sleuth and the DExx for lag testing 1920x1440 (4:3) from the MiSTer?
I think the DExx scaler adds up to one frame of lag, so I'm wondering if there is some combination of settings between the Time Sleuth and the DExx to use line multiplier mode and test the 1920x1440 (4:3 flag) latency?
EDIT: I forgot that the DExx only accepts analogue input so that won't work.
Maybe the DExx can integrate a built-in lag tester of some sort?
Which lag you specifically want to test? If you just want to test display lag with 1920x1440 source, then Time Sleuth (if supported or possible to request custom fw) or DE10-Nano with a sensor should be enough.
