SpritesMind.Net

Yeah lots of timing sensitive things in CD emulation, I spent good deal of time on this too, and it's still mostly wrong all around, just enough to get games running. Maybe I should get back to this someday.. Is Radical Rex working for you, Eke? Never got that one running (neither did Gens at that t...

So they still make those things?

As for checking if they work, perhaps get a MD1, solder a socket there and test those chips to be sure.

You could also run your code in a loop and increment a counter on each iteration, then register vsync handler that would read and reset the counter. This way you get times/vsync value that's easy to understand, you can easily calculate how much time per frame it uses and how much you have left for o...

There is also this Flux cart that might do this but I never really investigated how it works.

http://www.youtube.com/watch?v=Oswpqv22TIg

Just a reminder of something I ran into before that may concern this: don't forget that any C code that directly uses hardware MUST be compiled at -O1! If you compile at or above -O2, the compiler reorders the code for better speed regardless of whether hardware may go nuts due to the reordering. A...

Here is my IDA disassembly from the times I worked on this:
http://notaz.gp2x.de/misc/gen/vr_idb.zip

It's not commented but it has some symbol names.

But it's doing surprisingly well, makes me fear that some day they'll pass the Turing test!

The manual makes an obscure reference to setting RV=1 before accessing on-cart FRAM/SRAM, but that always freezes the machine and I think that's more about memory at $200000 than the SRAM control at $A130F1. If you are running from 88xxxx do note that this mapping disappears when you set RV, so you...

I was talking about Masyanaya's new cart HardWareMan posted about.

According KRIKzz doc his hardware also stopped touching 400000-7fffff in later firmwares, because of CD I assume.

If you look at the docs for the hardware (he does post those along with much of the source for the OS and drivers), it's not ALWAYS responding that way, but only when in certain operating modes. Sounds good then. Edit: where are the docs, only given when you buy it? there is no any problems with CD...

HardWareMan wrote: 10. 6MBytes ROM support (for example Kabal UMK3 hack)!

Hmh, doesn't that mean it always responds above 400000, what could cause problems with SegaCD?

Hm, are those bitfields there to make it look cool or are you coding just with a hex editor?

Also, does the SVP render graphics data directly in the 4-bit tile format (I guess doing a lot of read-modify-write operations to insert new polygons), or is there some hardware assistance involved? I know on the 68000 side there are some memory areas that swizzle memory around, but nothing but the...

Had a chance to run my test again and a130xx looks safe (open bus in both 32x and MD modes, I also have MegaCD attached), except the MARS part: http://notaz.gp2x.de/md/img/a130xx.jpg If you decide to drive DTACK yourself there is plenty of unused space in a20000-bfffff range, also perhaps could use ...

From what I remember whole A130xx range is readable (as it always is, even without 32X) and "MARS" is not mirrored anywhere. IIRC only MARS part is driven, everything else is floating, but I need to recheck (away from my gear now).