SpritesMind.Net

Interesting... but they're not exactly hardware patents. Some video game patents will include detailed descriptions of the hardware required (or preferred) but the hardware need not be unique, as in the case of console games. And you must look at the date the patent was filed, not the "publication" ...

I already pointed this bug out but Mike probably just missed it. In the init code (clearing work RAM and VRAM), clr.w d1 should be clr.l d1.

Fusion v3.63 fails 4 of 161 tests:

#127 SH2 MASTER ROM TO SDRAM (DMA)
#128 SH2 SLAVE ROM TO SDRAM (DMA)
#133 SH2 MASTER FRAME TO SDRAM DMA
#160 (32X MIDFRAME MODE SWITCH)

There are really only two issues remaining since the DMA problem is identical for those tests.

I wish I had time to work on this. It shouldn't be difficult to read the digital tracks (data & audio). Dumping them (reliably) might be a pain, though. I'll have to see if I can find some time.

- This test incorrectly sets the DMA transfer unit to 16-byte [4 longword]. As I understand it, this is an illegal setting because it requires longword access, which is impossible to/from the external memories of the 32X. As a result, the test reverts to a 2-byte [word] transfer unit. Nope. None of...

Did you mean to try this? Or are you sure it's 130, not 0x130?

Sorry, Mike, but you're gonna have to redo that patch. You need to set the security register ($A14000) before accessing the VDP. It should work on systems without TMSS, though. And you should probably change that clr.w d1 to clr.l d1 . Something like that may not cause a problem until the reset butt...

I am also very sure that I clear down all the vram on start up. I have no idea whats up with that. <snip> clr.w d1 GEN_INITL1 move.l d1,(a0)+ move.l d1,(a1) That could be a problem. EDIT: It looks like the MegaCart BIOS fudges the VDP mode registers (it unintentionally sets Mode 4!) before exiting....

I don't know what happened with the compilation. I think the first bytes of the .bin would be the header of the ROM, but when compiled, they get at other place in .bin Do you know why?? The link order is wrong. It is normally read from makefile.gen in the devkit. Nevermind that. Read this: http://g...

Yes, he has said that in the past but I wouldn't expect Steve to break a sweat attempting to fix a few of these errors. However, he is certainly welcome to do what he wants with Fusion; I provide these results merely as an FYI. That said, the recently released X-Men prototype fails to run in Fusion ...

Inspired by that thread and snkenjoi's ROM, I decided to write a quick demo. It's a bit of an experiment. * * TascoDLX 260-byte MegaDrive demo * * August 7, 2009 * * * What's it do? * ------------- * - passes TMSS check (should run on original hardware) * - sets up the vdp (registers, VRAM, CRAM [2 ...

Here is my final piece of code. With use of the trick I demonstrated before, and a little shifting around of the code, I managed to get it down to 32 bytes. Just trace the execution of this thing, it's beautiful. Nice, but it could be shorter. You get a free register load because of the stack point...

While I was digging through this ROM, I decided to give the latest version of Fusion (v3.61) a thorough test and report. For those who don't know, Mars Check Program is a program from SEGA (included in the 32X SDK) consisting of 161 hardware tests of the 32X. The program mainly tests documented feat...

I haven't set the mono bit you mentioned Nevermind then. I'm not sure it actually exists, and I think the other manual is better anyway. I tried the test ROM (Mars Check Program) -- it took a little convincing (read: hacking) -- but, in Fusion, PWM DMA works... on the slave, not the master. I haven...

Are you setting the PWM Control Register (at 0x20004030) correctly? Bit 4 is used to set mono mode but it's not listed in one of the manuals. Also, be sure to set the Cycle Register (at 0x20004032) but that should go without saying.