imi wrote on 2022-07-12, 09:58:

vvbee wrote on 2022-07-12, 07:28:

imi wrote on 2022-07-11, 21:48:

this works like 3 out of 5 times or so 😁 ...sometimes it needs a bit of help by setting the resolution manually.

What happens when it doesn't work?

the resolution is just off and so it doesn't switch to the correct preset, so I manually have to set it to the correct resolution and then it picks the correct preset.

If the wrong resolutions aren't random, you can try defining alias resolutions (Ctrl+A or something like that) so they'll be corrected automatically.

elianda wrote on 2022-07-11, 23:27:

Regarding the tune interval check:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vga2usb\Parameters\V2P80733\TuneInterval

The V2P80733 is my card, your ID may differ. You can set the value there to 0xFFFFFFFF, which is not possible in the GUI.

Thanks for the hint! It seems to create TuneInterval register key only after its value is changed from Epiphan Configure-window first time (ofc it can be created also by manually). I set it to 0xFFFFFFFF from the Windows register and after reboot Auto-adjustment interval is ghosted out from Epiphan Configure-window.

vvbee wrote on 2022-07-12, 15:06:

imi wrote on 2022-07-12, 09:58:

vvbee wrote on 2022-07-12, 07:28:

What happens when it doesn't work?

the resolution is just off and so it doesn't switch to the correct preset, so I manually have to set it to the correct resolution and then it picks the correct preset.

If the wrong resolutions aren't random, you can try defining alias resolutions (Ctrl+A or something like that) so they'll be corrected automatically.

yeah, I did that with some VESA modes, but sometimes it gets stuck on 720x400 for example when it should be switching to 640x400 or vice versa, it's understandable why that happens though ^^
but I have also had it occasionally happen that it doesn't switch correctly to higher resolutions.

also the switching to the preset is not the issue, it does that correctly as soon as it's on the resolution that is set as trigger (or an alias) it's just that it sometimes doesn't recognize the resolution has changed, or recognizes a false resolution
the latter is where an alias helps, only in case it does that consistently though, I had that be the case in Crusader for example where it would detect 848x480 instead of 640x480 consistently.

imi wrote on 2022-07-12, 15:48:

yeah, I did that with some VESA modes, but sometimes it gets stuck on 720x400 for example when it should be switching to 640x400 […]
Show full quote

vvbee wrote on 2022-07-12, 15:06:

imi wrote on 2022-07-12, 09:58:

the resolution is just off and so it doesn't switch to the correct preset, so I manually have to set it to the correct resolution and then it picks the correct preset.

If the wrong resolutions aren't random, you can try defining alias resolutions (Ctrl+A or something like that) so they'll be corrected automatically.

yeah, I did that with some VESA modes, but sometimes it gets stuck on 720x400 for example when it should be switching to 640x400 or vice versa, it's understandable why that happens though ^^
but I have also had it occasionally happen that it doesn't switch correctly to higher resolutions.

also the switching to the preset is not the issue, it does that correctly as soon as it's on the resolution that is set as trigger (or an alias) it's just that it sometimes doesn't recognize the resolution has changed, or recognizes a false resolution
the latter is where an alias helps, only in case it does that consistently though, I had that be the case in Crusader for example where it would detect 848x480 instead of 640x480 consistently.

I think this issue was also discussed a few years back on GitHub. The capture hardware apparently reports no difference between VGA modes 3 and 13h, so it's just one video mode and nothing to switch between automatically. I'm not sure if there's much to be done in terms of automation when the hardware fails to report a new mode, or does it unreliably. I guess in an extreme need you could bake some specific image analysis into the VCS source code. Maybe a filter where if a pixel at X,Y changes to a certain color and the video mode is so and so, switch to another mode. But that's a bit kludgy.

We had this discussion here as well, about e.g. distinguishing between 640x400 and 720x400. Also that basically every TFT shows 640x400 as 720x400 double sampling every ninth pixel.

At the moment I'd say the best approach is, if you know which one it actually is to allow only one of it for the 400 scanline mode. There is no way for a capture card to determine the correct number of horizontal pixels to sample automatically.

vvbee wrote on 2022-07-12, 19:15:

I think this issue was also discussed a few years back on GitHub. The capture hardware apparently reports no difference between VGA modes 3 and 13h, so it's just one video mode and nothing to switch between automatically. I'm not sure if there's much to be done in terms of automation when the hardware fails to report a new mode, or does it unreliably. I guess in an extreme need you could bake some specific image analysis into the VCS source code. Maybe a filter where if a pixel at X,Y changes to a certain color and the video mode is so and so, switch to another mode. But that's a bit kludgy.

yeah, my startech/micomsoft card did something like that where it would "crop" the image on every resolution change, but that led to other side effects as if the image on the resolution change had a black border it would "crop" too far.

the differentiation between 720x400 and 640x400 didn't matter as much with that one either as I could just oversample horizontally.

but yeah, nothing is perfect with VGA capture ^^

elianda wrote on 2022-07-12, 20:21:

We had this discussion here as well, about e.g. distinguishing between 640x400 and 720x400. Also that basically every TFT shows 640x400 as 720x400 double sampling every ninth pixel.

At the moment I'd say the best approach is, if you know which one it actually is to allow only one of it for the 400 scanline mode. There is no way for a capture card to determine the correct number of horizontal pixels to sample automatically.

One theoretical way of doing it in this specific context (VGA) would imply taking advantage of the fact that 640x400 is line doubled 320x200, whereas 720x400 isn't.

Consequently, if for example a capture card is set-up for 640x400 , and if the feed actually received is 640x400 (line-doubled 320x200), then each frame digitized at 640x400 can be decimated by a factor of 1/2 (to 320x200) and then line-doubled back to 640x400 essentially losslessly (assuming no noise and phase errors ). Doing this with a 720x400 feed digitized as 640x400 , will not be even close to lossless .

Assuming what I'm suggesting above is correct .

A capture card application's detection algorithm could :

a) assume 640x400 when ambiguous timings are detected
b) run a comparison between a captured frame (once every second, for example) and a decimated and re-line-doubled version of the frame
c) if the comparison in b) results in a match do nothing, if there is no match switch to 720x400

Then, assuming a switch to 720x400 capture has occurred, the same validation logic could be applied in reverse (if the comparison matches, switch to 640x400 , otherwise do nothing) to switch back to 640x400 when appropriate .

This would need to be limited to analyzing on the y axis since it is always sampled at 400 active lines (449 total) in both cases . Having pre-configured proper phase values for both modes for a given VGA card in advance would be a pre-requisite, of course .

Does that make sense, theoretically, and is it feasible to implement ?

In principle yes, but there are a few issues to solve:

Imagine you have a nearly empty DOS text screen with just a prompt, or even just black. Then the algorithm has not much data to determine the correct number of horizontal samples.
If you run the analysis algorithm permanently you could change the sampling later if you get enough content on screen, though quality would jump.

You assume you have perfect phase and alignment.

I would start with a higher number of samples, like 2 * 720 = 1440 x 400 and do the analysis on that. And the algorithm should be as robust that it gives also reliable results if the phase/alignment is not perfect.

If we're only talking graphics vs text mode, how about training a neural net to detect whether it's looking at a DOS prompt? I'm thinking text mode is typically starkly contrasted with graphics, and the AI check can probably run in real time.

a solution I always thought about would be interjecting directly on hardware and somehow draw a border around the visible area and maybe some machine readable visible code that includes the horizontal and vertical resolution off screen.
idk if something like that would be possible with just a custom graphics bios or driver for example.

vvbee wrote on 2022-07-13, 01:56:

If we're only talking graphics vs text mode, how about training a neural net to detect whether it's looking at a DOS prompt? I'm thinking text mode is typically starkly contrasted with graphics, and the AI check can probably run in real time.

Ok. Though, there is not "the text mode". You can train for 80x25 with 9 pixel wide chars, it will probably catch that but fail on other modes.
8 pixel wide char modes were very popular with Laptops to have 640 pixels for small TFT displays.
From my experience you have to test the algorithms and see which works best in what scenarios. None will be perfect.

A workaround is to use the MODE CON LINES=43 command. This changes the pixel clock of the textmode from 720x400 (900 h total) to 640x400 (800 h total). This may be a relic of an EGA mode (although the vertical refresh remains at 70Hz and the line count is unaltered).

This works on both a TNT2 and FX5200 I've tried so far, and you can even switch back to the 25 line mode right afterwards if you prefer it and the pixel clock will stay at 800px/line until a reboot or until some software twiddles VGA registers directly.

In this state both the textmode and 400p graphics mode can be captured pixel perfect seamlessly since they now both use the same pixel clock.

elianda wrote on 2022-07-13, 02:10:

Ok. Though, there is not "the text mode". You can train for 80x25 with 9 pixel wide chars, it will probably catch that but fail […]
Show full quote

vvbee wrote on 2022-07-13, 01:56:

If we're only talking graphics vs text mode, how about training a neural net to detect whether it's looking at a DOS prompt? I'm thinking text mode is typically starkly contrasted with graphics, and the AI check can probably run in real time.

Ok. Though, there is not "the text mode". You can train for 80x25 with 9 pixel wide chars, it will probably catch that but fail on other modes.
8 pixel wide char modes were very popular with Laptops to have 640 pixels for small TFT displays.
From my experience you have to test the algorithms and see which works best in what scenarios. None will be perfect.

Would it fail though? As far as I know, even basic nets get pretty good accuracy with handwriting that's all over the place. Beyond that, text and graphics look pretty different, so I'd expect the AI would have more than character shape to work with. Not sure though, and of course in practice there's always uncertainties.

this is a screenshot of windows millennium with start orb and things i used 98lite and revolutions pack. Used Millennium STEPUP edition on a fully patched 98SE system.

elianda wrote on 2022-07-12, 23:01:

In principle yes, but there are a few issues to solve: […]
Show full quote

In principle yes, but there are a few issues to solve:

Imagine you have a nearly empty DOS text screen with just a prompt, or even just black. Then the algorithm has not much data to determine the correct number of horizontal samples.
If you run the analysis algorithm permanently you could change the sampling later if you get enough content on screen, though quality would jump.

You assume you have perfect phase and alignment.

I would start with a higher number of samples, like 2 * 720 = 1440 x 400 and do the analysis on that. And the algorithm should be as robust that it gives also reliable results if the phase/alignment is not perfect.

Sorry for the delayed response.

Having a robust algorithm and oversampling the input signal is probably the most user-friendly approach, but not necessarily easy to implement. Additionally, that algorithm (or another one) would be needed to reliably do automatic phase adjustment/sizing algorithm. IMHO, if phase and size are off during ing a capture, there likely wasn't much point in getting the actual resolution (sampling rate) right to begin with .

Additionally, perfect (or nearly so) phase and alignment is not, IMHO, too much too ask. If one preconfigures a template for each each mode prior to the capture .

At the the end of the day, if someone is concerned with quality and proper sampling, I don't see a way around pre-configuration of phase and size prior to capturing, but maybe I'm wrong

That being said, if a reliable and practically feasible algorithm to handle everything (640 vs 720, auto phase/size adjustment, etc )could be implemented, it would make me happy .

EDIT: Some corrections

The alternative is to make it convenient for the user to make the switch. Keyboard shortcuts are obvious, but you could do audio triggers via microphone, read inputs from a foot pedal, use the phone as a remote, whatever's handy.

I did some testing with VCS, embedding a http server into the code that exposes a web interface on the local network that you can access with a phone, tablet, whatever. It would route actions from the interface to the program, giving you basic remote controls for setting the current capture resolution, viewing input signal info, etc. Maybe there's some practical pitfalls, but that's the theory.

Does this sound like a useful thing to anyone? I think it could be, like I know some people have their phone docked close by at the computer, so it could be convenient for toggling the capture resolution or viewing some basic runtime capture info without needing a second monitor or an extra keyboard.

After getting all the pieces together i was able to create the cheap capture setup i had in mind, i'm using a VGA2SCART ---> GBS control ----> vga to hdmi converter to get these results, i blame the cheap capture card for most of the blurriness but all in all it seems decent.

https://streamable.com/lenc26

https://streamable.com/yjp6dt

EDIT:Finally ludicrously sharp DOS capturing

EDIT2: I remember reading that jazz jackrabbit wouldn't scroll correctly on a matrox card (i think this information is still in the wiki) but it works perfectly on my G200
https://streamable.com/sptfnr

I had to lower my CPU speed with setmul but that means that the problem is related to the CPU's speed and not the GPU

I finally got my hands on a Datapath VisionRGB card.

And actually there are still some left. But you would probably need to live in france to get them. They are available on this french marketplace for just 70€:
https://www.leboncoin.fr/informatique/2251143540.htm
When I bought, it was saying there were 5, not its saying "multiple".
(I actually also bought an E2S in addition to, same vendor, but there was only 1 of that, which I am using here now, keeping the E1S as "backup").

Now...questions!

I downloaded the original software (program called VisionInstall v7.25.1) and also VCS251. Both work.
And while I see some benefits of VCS251, it also raises some questions:
Program (Duke 3D) is being started at 320x200 resolution.
Physical TFT Monitor is showing 720x400 resolution. Now I understand that 320x200 is usually interpreted that way due to text mode. However...
While Vision automatically identifies that as 720x400, VCS251 does not. Instead it identifies it as 640x480. If I then force the resolution to 640x480, its the same. If I force it to 720x400, its still the same. But if I then force it to 640x480 again, it breaks. I mean 320x200 should be the right one, so...why is the one program correctly identifying it, the other doesnt, but the one which doesnt, still shows it the right way...

Also there is a very slim black bar on the right side. On Vision you can just adjust the picture and show the correct segment. This does not exist in VCS251, or did I miss that?
Edit: This one can be fixed via presets.

A more "generic" question about the resolution:
If you have a game which is 320x200 and interpreted as 720x400, it still only got 320x200 pixels, right? So to get it pixel perfect AND to fix the resolution, you could do 1600x1200. But unless you got a 1920x1200 monitor, thats not an option, and especially for youtube this doesnt work.
So what's your prefered way?
Just keep 4/3 and scale without perfect pixel doubling? (->1440 x 1080)?
Slightly compromise and go for perfect pixel doubling but a slightly off ratio? (->1280x1200) (thats 1.28 instead of 1.333333)
Or anything else?

Capturing 320x200 as 640x400 or any integer multiple thereof will give pixel perfect capture as long as phase is adjusted properly.

Monitors always misdetect (or assume) as 720x400 (text mode) because the timings are identical (this is analogue, after all, so there are no actual discrete pixels, just voltage variations).