Google, first result: SDK, patches, docs, drivers.

http://www.mindflux.com.au/products/iis/vfx1.html

Downloads are retrievable through web.archive.org.

Anyhow, sounds fascinatig, though I guess it's simply too rare hardware to emulate (unless you implement it yourself/pay someone to do it).

It says it is an invalid zip file when I download the SDK.

I'm implementing it myself.
So far I've gotten it to recognise the fake VFX1 in Super Karts, and it initialises it, but I haven't implemented the reading yet.
I think I may have gotten it to recognise it in SkyNet too, but I'm not sure, because it never seems to try to read it.

By the way, I'm probably going to emulate it on a Vuzix VR920 and eMagin Z800.

archive . org + pkzipfix -> seems to work
I've attached the files that are present after the installation of that SDK.

Thank you! This will be incredibly helpful.
I have to search for the programmers' documentation now. I would have thought it would be with the SDK, but it isn't.

As it seems to use the int33 interface only, did you check ralph brown's interrupt list?

Only the Hewlett Packard mouse check is listed for the range of values that VFX1 uses.

The VFX1 does also use ports. I think it uses the ports 0x300..0x303 by default. And I know some VFX1 games do write to those ports (for the graphical side of it) even while they use interrupts for the tracker.

With any luck I have implemented the data reading now. Now I just have to make some way of feeding data to it, and test it.

OK, it's working in Super Karts. I made the view just spin around at a constant rate. Now I just need to make it read the VR920.

I'm thinking maybe I should aim to get it to support VR920, Z800, and TrackIR.

What's the correct way to add an environment variable to the autoexec.bat without it crashing on shutdown?

I had to add it to the Sound Blaster module to get it to stop crashing. But it definately doesn't belong in the Sound Blaster module. Basically I just need to add a "SET VIPPORT=300" line.

I'm also working on adding stereoscopic support to DOSBox. I'm currently emulating 3D BIOS, LCD BIOS, and VFX1. The interfaces to those three are emulated fine, but now I need to do the actual stereoscopic rendering.

The problem is... I don't have a clue how DOSBox does its rendering! It is clear as mud. Actually I have a few clues, but nothing makes sense yet.

I know the rendering itself is done by SDL, using the SDL functions. On top of that is the GFX layer in sdl_main. On top of GFX is the RENDER layer in render. On top of the RENDER layer is the VGA layer in vga_draw.

What I need to do is access the unscaled pixel data, presumably from the frame buffer, and then separate out the odd and even lines into a left view and a right view. Then the scalers can be run separately on the two views, or maybe could be run on the final frame. A final frame would be produced (for now with red/cyan glasses), then it would be stretched out and displayed like normal.

So does anyone know how data gets from the frame-buffer to the screen and passes through those various layers? I'm particularly confused about what is happening in vga_draw.

And don't forget my other question about adding autoexec lines.

VGA_SetupDrawing() chooses the drawing handler (if any), so check what
the respective game uses. Most common case should be VGA_Draw_Linear_Line(),
so the following refers to that function.
vga.draw.linear_base is the base of the graphics memory, see VGA_Draw_Chain_Line()
for some nontrivial example of rendering the graphics memory into a line buffer.

How should the output look like for that vfx1? The input is an image of say
640x480x16 where the lines are alternating, what would the output look like?
(two 640x240x16 images which are somehow sent to the vfx1 device
without caring about what is displayed on the rendering screen?)

Also have a look at VGA_DrawPart() which schedules the line rendering.

Well the code used for the soundblaster module doesn't crash it seems, so
stick to that (create a similar module class which is registered in dosbox.cpp,
use an AutoexecObject to add the environment line).

Thank you, that's very helpful.

On a real VFX1 the graphics output doesn't come from the graphics card, it comes from the VFX1's VIP card, which the VFX1 is plugged into. A normal monitor would still be plugged into the graphics card, and would presumably still be displaying the scene normally. But the VIP card will read the graphics card's framebuffer via the VESA feature connector, interpret it based on some settings the game wrote to the VIP card, and converts the data to two screens, scales it to 278x204 (the HMD's resolution), interprets the data via its own two palettes (which have to be set independently of the graphics card's palettes by the game), and displays the two screens, one on each eye.

I'm not trying to support real VFX1s though, because they are no longer available, and require an ISA slot for the VIP card to plug into (ISA slots are not the same as PCI slots).

I'm trying to emulate it on a Vuzix VR920, or eMagin Z800, or maybe any kind of stereo display or a tracker like TrackIR.

> VIP card will read the graphics card's framebuffer via the VESA feature connector

http://www.hardwarebook.info/VESA_Feature
This connector only provides on-screen data. You will have both pictures on the normal VGA output.

Funny thing, this hardware: http://www.zalman.co.kr/eng/product/view.asp? … dx=331&code=032 seems to work exactly the same way as VFX, i.e. using alternating left-eye/right-eye lines. You wouldn't have to do anything but make sure lines are scaled differently.

Actually the VFX1 seems to expect the data to be in 320 x 4 pages x 240 format. And the game needs to tell the VR920 to page flip by setting the page for each eye to one of those four pages. Basically it is the old quad buffered stereo.
Which means the VGA mode is set to 640x480, and on the VGA it looks like the left half of the screen is for the left eye and the right half is for the right eye, but whenever you move you notice that every second line is one frame behind what it should be.
So far I have only tested one VFX1 stereo game and that is the descent 2 demo.
I don't have the VFX1 SDK documentation. Maybe it was from the days when documentation always meant a physical book.

Making sure the lines are scaled differently is the ridiculously hard part, since the DOSBox scaler code is hideously complicated and totally undocumented. In comparison the vfx1.h is easy to understand (but still almost impossible).

By the way, I'm also emulating 3D Bios and LCD Bios, and possibly will add a way of putting it into interlaced 3D mode for those games that just render in 3D without telling any of the software or hardware.

3D Bios is considerably simpler. It just makes the current mode interlaced, with a line for each eye. And it comes with a function that puts it into VESA 320x400 mode.

Anyway, all the 3D mode detection stuff is working (at least for Descent 2), and the games always believe the 3D hardware is there. Now I just need some way of actually changing the rendering pathway in DOSBox.

I'm also having a problem with some games not recognising the VFX1 tracker, including descent 2. The interrupt 33H VFX1 interface is hideously complicated, so it is only sort of working.

the DOSBox scaler code is hideously complicated and totally undocumented.

I don't see why you need to move on to the scaler level, that's completely
independent from the graphics hardware emulation and rendering.
If you want to output the image data to some external device, grab the frame
buffer data at the functions mentioned above, and forward them without changing
the dosbox window output.
If you need to change the output size/number of windows or whatever, please
explain exactly how this is supposed to work on real hardware.

wd wrote:

I don't see why you need to move on to the scaler level, that's completely
independent from the graphics hardware emulation and rendering.

I guess that was in reply to my post. The TFT screen in that link is 3D capable: Both images are displayed at the same time, interlaced, and the screen has a polarizing filter that polarizes pixel lines alternatingly. Viewers then just wear cheap and light "glasses" which are just two polarizing filters that match the appropriate lines' polarization.

To support that output device, there's no special hardware code needed, it just needs a scaler that scales those interlaced source images to a likewise interlaced output image.

The real hardware will be one of the following (in the order that I probably want to implement them in):

* An ordinary monitor with red/cyan anaglyph glasses.

* A VR920 or Z800 plugged into the VGA port. This could be either the only monitor, or showing the same thing as the ordinary monitor in clone mode, or part of a multi-monitor extended desktop. Stereoscopic display requires rendering the left frame, then rendering the right frame, then rendering the left frame again, at 60 frames per second.

* A stereoscopic display compatible with the nvidia stereo driver.

None of these will be displaying in the native resolution of the emulated stereo device, especially since that device will probably have its vertical resolution halved. So I thought it would make sense to run it through the same scalers and rendering code where possible.

I'm not planning on emulating both the monitor and the vr display at the same time.

At this point I'm not assuming that it will necessarily be run fullscreen, or at a predetermined resolution. (The last one does have to be run fullscreen though). So I want to have the same display options as DOSBOX normally has, but unpacking and scaling the image into two buffers, before rendering either one buffer at a time, or combining the two into a single output image and rendering that.

Oh, and I probably should also provide a way of rendering to an interlaced display like Zalman. Although that is the first one I have seen for a while that uses that stereo format.