Connecting a DOS PC to a PVM

[mvsfan]

as another option, If you have the space for one, Gateway made some large 4:3 CRT VGA monitors, up to 36". Search for Gateway Destination monitors. Sony also has the PGM series.

[BubbaMc]

A bit of a bump here but I thought it was amazing that you got this to work, especially on a BVM A(!) which is very picky about the signals fed to it.

If it worked on all 3 games that you tried it might work on everything that uses 320x200 resolution.

I'm going to get hold of an S3 Trio3D card and give it a go myself. If anyone is interested, I found a list of supported cards here:

http://mirrors.arcadecontrols.com/VGATV ... ility.html

Well colour me purple and call Barney. I actually finally managed to get a usable image on the screen that carried through to games as well.

Firstly, I really wanted to try MON-ARC, so I went ahead and purchased the cheapest compatible card for it, a Matrox G400. To my disappointment that route proved to be a waste of money, time and effort. All it got me was a garbled image on my B&O TV.

So I thought, either the fault was with my TV, or with that sync combiner cable that I had built myself. Because the G400 was supposed to work.

To take both out of the equation I decided to test the PC setup on my BVM A. I first tried with my sync combiner cable, but no dice. Next I busted out the classic VGA to BNC cable, and used the crude T-adapter H&V sync combining. This, once again gave me nothing usable on screen with the G400, so advice against acquiring that card for MON-ARC.

As a last resort I decided to test that S3 Virge card that I had. That card does not work with MON-ARC, but was the only card that gave me a stable picture in the text prompt via VGATV.

This time lady luck lifted the old skirt for me. I got a stable image, and not only in the text prompt, I managed to launch DOOM, Wolfenstein 3D and Monkey Island 2 in 15khz, all working, and looking amazing, scanlines and all.

One thing to note, VGATV would only work if I used the /ISP option to invert sync polarity. Perhaps this is necessary due to the crude T-adapter sync combining that I had resorted to. Now, I wonder why my sync combiner cable was a dud.

I also spent some time getting a USB gamepad to work in DOS. Wasn't easy, but worth the trouble as now I can play PC games in a console-like manner, on a 15khz TV with scanlines.

Huzzah!

Next challenge will be to miniaturize this hideous setup so it will be more palatable to my sensitive aesthetic senses.

[kamiboy]

None is my surprised than myself to be honest. Though I do think such a setup would benefit from a device that kicks own TTL level RGBHV signal from the PC to TV level RGBS. Such things do exist and are sold here at some online arcade shops.

[BubbaMc]

I suppose the best way to play a mode 13h game on a 15khz CRT would be via a TSR that rasterizes the 320x200 source inside a 240p window without scaling leaving a 20 pixel gap at the top and bottom.

Then one can manually correct the aspect ratio by stretching the V-size of the display using a service menu.

A bit of a hassle, but should result in a pretty good picture quality, in theory.

Just to clarify, did it end up working in the same way your theory above describes - with the black bars on the top and bottom?

With my setup I envision creating a DOS boot disk loads VGATV whenever I intend to use the BVM A, and let the hard drive boot the machine when using a regular PC monitor.

Btw I have an Extron 203Rxi which should take care of any sync conversion issues, it does a great job with regular VGA and have fed 15khz RGBHV signals through it from my Amiga with success.

[kamiboy]

I don't remember whether there were black bars or not. It all looked pretty good though, and that is a pretty good plan with the boot disc. Personally I have the TSR set to load by default because I only use the PC with my BVM.

[BubbaMc]

Cool.

The only pain in the ass will be the 70hz to 60hz conversion, I'm expecting some screen tearing and choppy motion on some games, but I'll report back here with my findings in a few weeks if I do manage to get it going.

Actually come to think of it I don't remember any framerate locked fast paced or scrolling games on DOS anyway, so the framerate conversion thing might be a total non-issue.

Haven't touched DOS proper in nearly 20 years so this should be interesting!

[Fudoh]

Actually come to think of it I don't remember any framerate locked fast paced or scrolling games on DOS anyway, so the framerate conversion thing might be a total non-issue.

actually yes. Especially late dos titles (early to mid 90s) were capable of extremely smooth scrolling.

[BubbaMc]

Actually come to think of it I don't remember any framerate locked fast paced or scrolling games on DOS anyway, so the framerate conversion thing might be a total non-issue.

actually yes. Especially late dos titles (early to mid 90s) were capable of extremely smooth scrolling.

Got any games in mind?

I'll test them

[Fudoh]

I have a hard time thinking of anything that didn't offer smooth scrolling in the later DOS era. Do you have the means to test a 200p70 title at its original refresh rate ?

[kamiboy]

Frame rate conversion does not take place. I doubt any DOS game was written to run at 70fps. Most were frame locked to something more sensible, so they should work fine when the frame rate is bumped down to 60. I think doom is locked to something in the 20s or 30s. That is why the frame rate will not get smoother than on a Pentium even if you run it on a modern PC capable of DOS.

It has been a while since I wrote anything for DOS but if I remember correctly i frame locked my programs by starting a timer, doing all the rendering and then waiting for a set amount of time to pass from start of the timer. The set time interval to wait will determine your actual frame rate, not the graphics mode refresh.

[BubbaMc]

I have a hard time thinking of anything that didn't offer smooth scrolling in the later DOS era. Do you have the means to test a 200p70 title at its original refresh rate ?

Not right now but hopefully in a few weeks I will, currently getting some parts together for a DOS rig based on this video: https://www.youtube.com/watch?v=fcAqRbFFQPU&t=1388s

Just found a cheap VGA card on ebay that's supposed to be fully compatible with VGATV so I'll get back to you all soon

[BubbaMc]

Edit: nevermind, I found the latest DOS version here: http://reocities.com/SiliconValley/hori ... /vgatv.zip

-------------------------------------------------------------
Does anyone have a copy of the DOS VGATV driver?

I can only find the Windows version here: http://mirrors.arcadecontrols.com/VGATV ... river.html

[orange808]

Frame rate conversion does not take place. I doubt any DOS game was written to run at 70fps. Most were frame locked to something more sensible, so they should work fine when the frame rate is bumped down to 60. I think doom is locked to something in the 20s or 30s. That is why the frame rate will not get smoother than on a Pentium even if you run it on a modern PC capable of DOS.

It has been a while since I wrote anything for DOS but if I remember correctly i frame locked my programs by starting a timer, doing all the rendering and then waiting for a set amount of time to pass from start of the timer. The set time interval to wait will determine your actual frame rate, not the graphics mode refresh.

Regardless of the developer's strategies, the software was still not designed to run with a 60hz display. Each timed draw would still be based on the native refresh.

[kamiboy]

What do you mean by each timed draw? Timing for framecaps are best implemented around the system clock, which is not related to frame rate. If the frame capping is based around counting frames, like waiting for two raster retraces in a row as an easy way of frame locking to 35fps then, yeah, the game would not run right in 60fps.

Of course none of that matters if the game engine is sophisticated enough to advance the game engine based on elapsed time unit of time rather than elapsed number of frames.

[orange808]

What do you mean by each timed draw? Timing for framecaps are best implemented around the system clock, which is not related to frame rate. If the frame capping is based around counting frames, like waiting for two raster retraces in a row as an easy way of frame locking to 35fps then, yeah, the game would not run right in 60fps.

Of course none of that matters if the game engine is sophisticated enough to advance the game engine based on elapsed time unit of time rather than elapsed number of frames.

Nobody queried the system clock. Most DOS software was designed to run as fast as possible without frame skip or frame cap.

The best implementation?

Limit the execution of the game logic based on the timer and let your frame buffer update in free run. That way, the recommended target hardware and newer faster machines will always display the game at the same speed--regardless of how many FPS the game actually produces. You may be pushing the same image to the frame buffer hundreds of times on new hardware, but it would make no difference.

Unfortunately, this was rarely done.

[kamiboy]

Any DOS game that is written to run as fast as possible would run too fast on newer machines anyway. This was a problem with the very earliest games written when IBM PC speeds did not vary very much, and those were the CGA/EGA days.

I doubt many games written for mode 13h were so sloppily implemented as by then the problem of varying PC speeds were known. But the proof is in the pudding, I ran all the games of interest to me in VGATV mode and they all ran fine. So they are either frame capped, or use a gameplay timer.

[orange808]

Any DOS game that is written to run as fast as possible would run too fast on newer machines anyway. This was a problem with the very earliest games written when IBM PC speeds did not vary very much, and those were the CGA/EGA days.

I doubt many games written for mode 13h were so sloppily implemented as by then the problem of varying PC speeds were known. But the proof is in the pudding, I ran all the games of interest to me in VGATV mode and they all rand fine. So they are either frame capped, or use a gameplay timer.

Wing Commander and Ultima 7 are not EGA. They are not capped.

[BubbaMc]

I get that we're not giving our TVs a signal that it expects, but what I find odd is that we both used the same setup and got wildly different results — hence why I assume the video card is at fault.

Which chipset exactly were you using?

Take a look at the compatibility list here:
http://mirrors.arcadecontrols.com/VGATV ... ility.html

If your S3 Trio64v+ card doesn't have the 764 chip and 2MB video ram then it can't be expected to work properly according to that list. Try again with a different card

Also the Windows version is compatible with more cards:
http://mirrors.arcadecontrols.com/VGATV ... ility.html

Here's the homepage for VGATV (both versions) if anyone needs the executables:
http://mirrors.arcadecontrols.com/VGATV ... river.html
http://mirrors.arcadecontrols.com/VGATV ... river.html

edit: a quick google suggests that the Trio64v+ uses the 765 chip, which is not listed in the compatibility matrix. Pretty sure this is what your issue is.

[BubbaMc]

Does anyone know of any 15kHz monitors that will accept a 70Hz refresh signal?

BTW, Mon-Arc is still available here if anyone's interested (this could output 70Hz, whereas VGATV seems to be strictly 50 or 60Hz only): http://mirrors.arcadecontrols.com/Mon-A ... wnload.htm

[maxtherabbit]

Resurrecting this since I'm playing with VGATV. Some games actually run slowly when forced to 60Hz. Tyrian and Charlie the Duck are two examples I've personally tested.