Next Generation Emulation banner

1 - 7 of 7 Posts

·
Premium Member
Joined
·
423 Posts
Discussion Starter #1
I *think* you'll like this :

Tonight another heroic effort was submitted to mame : http://git.redump.net/mame/commit/?id=c82d72b3394b6e9a969b42474df3d503684d36a4

Samuele Zannoli actually implemented emulation of the NV2A register combiners, as used by the Chihiro emulation in MAME! I'm feverishly searching for screenshots of this work, but haven't found anything yet.

This code doesn't do lighting yet, and will probably be slow as hell, but you can bet the output will be very accurate - perhaps even pixel-perfect once all issues are ironed out.

As for speed - perhaps some caching and precalculation could be added, or some sort of hybrid dynamic recompiling engine. But even without that, this is actually a significant step towards chihiro (and by extension Xbox1) emulation!


I don't know about you guys/gals, but the mere fact this code has landed tells me the chihiro emulation in mame has progressed further than one would think (judging by the lack of chihiro/xbox1 discussion in various mame-related forums).

My cautious guess is, that by the end of this year MAME -chihiro will start running a few devkit samples, maybe even a simple game!

Cheers, PatrickvL
 

·
Premium Member
Joined
·
423 Posts
Discussion Starter #2
[Update from http://git.redump.net/mame/commit/?id=c54e8dfdf7017a484c0a0f5653f2e56a37159c6f ]

chihiro: few updates to the i386 processor and chihiro driver. [Samuele Zannoli]
- adds lots of mmx and sse opcodes to the i386 processor
- adds the fcomip x87 opcode
- adds a "UINT8 *memory(UINT32 &size)" method to the naomi_gdrom_board device that returns the size and a pointer to the decrypted gdrom data (used by chihiro)
Then for the chihiro driver:
- adds basic stuff for the Nvidia audio APU
- adds the "chihiro curthread" debugger command, shows information about the current active thread
- adds the "chihiro irq,<number>" debugger command, to generate an interrupt with irq number 0-15 by hand
- adds more patches to let the software run even if usb is not implemented
- adds the Chihiro Type 1 baseboard/mediaboard features to let the system load the gdrom games
- adds incomplete save state support
- adds support to the Nvidia 3d accelerator to draw primitives where the vertex data is not stored in a vertex buffer but contained in the command stream

i386: don't take an smi until current instruction is complete (nw)
 

·
Registered
Joined
·
7 Posts
http://git.redump.net/mame/commit/?id=78a5dc2cf7b3003f27f485727b471d2ee8d4681d
Chihiro.c: [Samuele Zannoli]
- add more patches needed until usb is implemented
- add support for more texture formats and drawing primitives to the 3d accelerator
http://rbelmont.mameworld.info/?p=855
Samuele Zannoli has continued to plug away at the Xbox 1-based Chihiro hardware, with the result that OutRun 2 now boots and (very slowly) shows a few 2D screens. I don’t think it does anything more, but I could just be impatient.







UPDATE: Haze was more patient and got to this 4th screen, after which it crashes:

 

·
Registered
Joined
·
358 Posts
Whoah amazing progress!
 

·
Premium Member
Joined
·
423 Posts
Discussion Starter #6
Yeah, I've been drooling over this too - it's truly amazing! (BTW, the textures on the fourth screen seem to be using the DXT1 or DXT3 format, judging by the 'jaggy' colors.)

I have no doubt that Samuel, RB, Haze or some other hotshot MAME dev ;) will fix the crash in the coming months. Let's hope that this mayor leap motivates MAME devs to work on speed-improvements all across the board; CPU, GPU, memory, interrupts...

If you look at the combiner_* functions in http://git.redump.net/mame/tree/src/mame/drivers/chihiro.c you can seen there's a ****load of work being done per-pixel. I imagine that once the crashes are gone and the renderer works more-or-less correctly, lots of things can be sped up by pre-computing them (like creating render delegates beforehand, transforming case statements into lookups, adding quick-paths to "simple" pixel combiner operations, etc).

To me, this is the most interesting MAME progress since years! Congrats!
 

·
Premium Member
Joined
·
423 Posts
Discussion Starter #7
I really don't know where to put my comments on this code, so I'll just put it down here:

I've compared the code handling (maddress == 0x1810) with (maddress == 0x1818).

1810 = NV2A_VB_VERTEX_BATCH = primitive drawing using a starting-index in the active vertex buffer
1818 = NV2A_VERTEX_DATA = primitive drawing using attribute values straight from the push buffer

Right now, 1818 handles TRIANGLE_FAN, TRIANGLE_STRIP, QUADS and QUAD_STRIP
While 1810 "only" handles TRIANGLE_STRIP and QUADS

Merging these two implementations would already expand the matrix of supported primitive types per method.

What's needed for that, is a method-dependant way to calculated where the attribute data is coming from. That shouldn't be too hard (famous last words).

Anyway, after this merge, POINTS, LINES, LINE_LOOP, LINE_STRIP, TRIANGLES and POLYGON will reduce to one implementation.

This is especially helpfull when adding support for methods 1800 (NV2A_VB_ELEMENT_U16) and 1808 (NV2A_VB_ELEMENT_U32), as the actual support for that would become "trivial" (one "only" has to add address calculations for those - the primitive-drawing code doesn't have to change).

Just my five cents, just ignore me. I haven't coded one line of MAME/MESS code ever, and my Dxbx days are already 2 years past.... :p
 
1 - 7 of 7 Posts
Top