VOGONS


3dfx voodoo chip emulation

Topic actions

  • This topic is locked. You cannot reply or edit posts.

Reply 20 of 386, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

I just started working on main registers (i.e. fbiinit*) and dac; had some troubles with dac register, was borrowing some ideas from mame on this but there was a small difference on pc implementation. No triangle handling yet.
Last weekend I managed to build a debug version of glide2x.dll with msvc6 inside dosbox, starting from official linux sources; this allows us to debug from inside dosbox the calls to the hardware and easily detect what's going on.
I'm attaching the dll sources, they may be of interest for someone.

Attachments

  • Filename
    glide2x_linux_src.zip
    File size
    1.25 MiB
    Downloads
    716 downloads
    File license
    Fair use/fair dealing exception

Reply 21 of 386, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

I thought of posting the sources I'm working on. At the moment just few regs are handled and next step should be lfb access handling.
The idea is to work on porting a piece at a time, but I'm open for suggestions.
Just a note on memory: the whole 16mb space is handled by the class Voodoo_PageHandler, 4mb for register space, 4mb for lfb and 8mb for textures; direct access is not allowed and only readx/writex should be used.

Attachments

Reply 22 of 386, by sliderider

User metadata
Rank l33t++
Rank
l33t++
Harekiet wrote:

Thought aaron giles already did a full software voodoo emulator with MAME

That's probably because there's a lot of Jamma boards out there with 3Dfx chips on them so some form of emulation would be necessary to run the games but how would you strip the emulator code out of MAME and incorporate it into DOSBox without violating his IP?

I'd like to see virtual 3dfx card that supports more modern standards, though. It would be kinda fun to see DX 9 games running under Glide with full shader and texture support.

Reply 24 of 386, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

A question for the experts: while debugging the dll functions from msvc inside dosbox, sometimes an access to the voodoo memory generates an error in dosbox, which blames for missing byte handler in reading/writing memory; that should never happen since byte access is not supported. This actually does not happen when launching a game directly (no debug). Any clue?

Attachments

  • byte access.PNG
    Filename
    byte access.PNG
    File size
    14.78 KiB
    Views
    8625 views
    File license
    Fair use/fair dealing exception

Reply 25 of 386, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

What do you mean "byte access is not supported"? Since your handler is derived
from PageHandler any non-dword (or maybe unaligned) access may trigger a
byte access, or am i missing something?

Easiest thing to do anyways is to put a breakpoint onto that function and check
the call stack when it's it (game under visual studio in dosbox under visual studio,
that should work!!!).

Reply 26 of 386, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

according to the documentation:

9.2 Memory Accesses All Memory accesses to SST-1 registers must be 32-bit word accesses only. Linear frame buffer accesses ma […]
Show full quote

9.2 Memory Accesses
All Memory accesses to SST-1 registers must be 32-bit word accesses only. Linear frame buffer accesses may be
32-bit or 16-bit accesses, depending upon the linear frame buffer access format specified in lfbMode. Texture
memory accesses must be 32-bit word accesses. Byte(8-bit) accesses are not allowed to SST-1 register, linear frame
buffer, or texture memory space.

it happens during register read, which should be always a 32-bit access.
Putting a bp in a game under visual studio in dosbox under visual studio (quite confusing isn't it?) just shows few mem calls starting from dyn code up to readb handler; what should I look for?
Is there a way to force aligned memory access for my page handler?

Reply 29 of 386, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Putting a bp in a game under visual studio in dosbox under visual studio (quite confusing isn't it?) just shows few mem calls starting from dyn code up to readb handler; what should I look for?

Other way round: in the visual studio that debugs dosbox (outermost level)
put a breakpoint at the readb function that has the E_Exit() in it.

I don't know why there would be a difference if the game is run under a debugger,
but maybe they are intercepting some page accesses (initialization etc.)
which would produce this error if they tried to "emulate" the access. This would
mean that the game (voodoo part) may or may not work when the debugger
is attached to the game.

In general of course you can access the address-space as you like, question is
what the voodoo hardware/memory controller does (as hal says it may even have
some deterministic effect), so just add the respective handlers+logging.

Reply 30 of 386, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

here's the call stack.

In general of course you can access the address-space as you like, question is
what the voodoo hardware/memory controller does (as hal says it may even have
some deterministic effect), so just add the respective handlers+logging.

I added empty readb/writeb methods, it does not crash, as expected, plus it seems it keeps reading and writing to registers correctly...

Attachments

  • Filename
    debug.PNG
    File size
    40.36 KiB
    Downloads
    487 downloads
    File license
    Fair use/fair dealing exception

Reply 34 of 386, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

If so then that visual studio+game thing would not work on real hardware.

Any way, most likely it's something simple as visual studio checking what
type of memory there is (i'm getting a dword access to a page i don't know,
let's see (==byte read) if it's a rom page).

Reply 39 of 386, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

As a quick hack you can try to set vga.mem.linear to the lfb memory when switching the voodoo on and using the same resolution/color depth as the desktop had.

If you provide the needed tools/patch/information I could try to implement that part in a more proper way.

1+1=10