SpritesMind.Net

TmEE co.(TM) wrote:Sure.

Tomorrow I'll probably make another emu detector... which no emulator passes


BTW, AamirM, I noticed that your emu's screen is few pixels bigger and it causes lots of slowdown on my PC. The 320x240 screen is 320x247... can you fix it ?

Also, the YM2612 PCM/DAC is not very good too, only Fusion emulates it almost perfectly (it has one flaw).
A proggy to test PCM and a real HW recording : http://www.sega-16.com/forum/showthread.php?t=4091

Sure I'll fix it. You will have to wait for 0.7

Hm ... A good emulator, sound pleasant. But there is a couple of comments:
1. In "Sub Terrania" melodies a periodic strange sounds happens and BGM sounds different. Here is the record of melody "Carousel". For test purpose, you can use my PD-ROM's. I used emulator for P4.
2. I want to an advanced debugger (for M68K with all kind of breaks)! If you made it - I'll to trash all other emulators of MD.
PS My configuration is:
CPU - Intel Celeron @3GHz, 1GB RAM, Sound Blaster Audigy (SB0090) and I use Windows XP Corporate Edition.

Not a really feature request, but my thoughts about things which will be good to see in (distant) future versions:

Developing and hacking features. Something like in Gens KMod - VRAM, palette, sprite list, and VDP registers view, YM2612 and PSG registers view (and YM2612 registers dump), enable/disable VDP planes, etc. Powerful debugger will be most important, of course.

TAS features - movie recording with re-recording support, frame advance, etc. I think, it's impossible to make this emulator compatible with modded version of Gens, which currently used for TASing. But if Regen will have good TAS features combined with high accuracy, it surely can replace Gens (like modded FCEU replaced Famtasia few years ago).

It will be great to have accurate and really universal emulator, which will be suitable for all purposes - just playing games, homebrew developing, TASing, etc. For now, people forced to use many different emulators for different purposes.

Hi,

The debugging features are the most requsted ones. Most of the debugging things Shiru and HardWareMan mentioned are already under progress and you will be seeing them soon.

stay safe,

AamirM

AamirM wrote:... Most of the debugging things Shiru and HardWareMan mentioned are already under progress and you will be seeing them soon.

WOW! Can't wait for this!
BTW About mirroring. The ROM size could not be a multiple of 2^. Therefore, we should do "AND" not by size-1, but by the number of bits used in addressing. For example, look at this ROM: "Story of Thor" (aka "Beyond Oasis"). It takes from $000000 to $2FFFFF, not $3FFFFF, but mask should be exactly $3FFFFF or you get bugs. And "Flashback" takes from $000000 to $17FFFF. And you get an error, if try do this: "Address AND $17FFFF". In case of "Flashback" the mask must be $1FFFFF.
I clearly explained?

Hi,

I forgot to mention that it will be a different build of Regen because the debugging features are slowing down the emulation.

AamirM wrote:Hi,
I forgot to mention that it will be a different build of Regen because the debugging features are slowing down the emulation.

For me, it's does not matter. I don't care about perfect speed when debugging some things. But, it must be quite fast or close to realtime, because when you trying to catch some access to somewhere it may take a lot of time. Let it be a "debug mod" of normal emulator.

HardWareMan wrote:

AamirM wrote:... Most of the debugging things Shiru and HardWareMan mentioned are already under progress and you will be seeing them soon.

WOW! Can't wait for this!
BTW About mirroring. The ROM size could not be a multiple of 2^. Therefore, we should do "AND" not by size-1, but by the number of bits used in addressing. For example, look at this ROM: "Story of Thor" (aka "Beyond Oasis"). It takes from $000000 to $2FFFFF, not $3FFFFF, but mask should be exactly $3FFFFF or you get bugs. And "Flashback" takes from $000000 to $17FFFF. And you get an error, if try do this: "Address AND $17FFFF". In case of "Flashback" the mask must be $1FFFFF.
I clearly explained?

exactly, that what I wanted to say
but on cartridge, PROM have always size factor of 2, no ?
in this case, 300000-3FFFFF area would return 0x00 or 0x FF?

Is it possible to do a real genesis debugger which work as GDB ?
I mean : you can interface it with IDE as Code::Blocks and you can watch your variables, do step by step execution etc... like a real debugger ! That would be totally awesome ! But i do know that is a lot of work

Eke wrote:but on cartridge, PROM have always size factor of 2, no ?
in this case, 300000-3FFFFF area would return 0x00 or 0x FF?

Every cartrige do this different way. It can be full-size PROM with free space filled by same byte (usually 0xFF). I test one cartrige with 2 PROMs, first one was $200000, second - $100000, so total size was $300000. And second PROM just shows twice (i.e. $300000-$3FFFFF was exactly same as $200000-$2FFFFF). So, this depend on inside organization of cartrige.

Hi,

For people using Linux, I have uploaded the Linux version. Tell me how it goes.

stay safe,

AamirM

AamirM wrote:Hi,

For people using Linux, I have uploaded the Linux version. Tell me how it goes.

stay safe,

AamirM

Holy crap! That's slow!! It runs Sonic 3 slower on my 2.4 GHz X2 than my PSP.

Maybe something is wrong with the way the timing is handled.

Seems to me people really love the hacking/development/debugging tools the most.

I'm keeping track of any bugs/issues found in Regen, as well as people's feature requests here. If there's anything I missed, please tell me.

Chilly Willy wrote:

AamirM wrote:Hi,

For people using Linux, I have uploaded the Linux version. Tell me how it goes.

stay safe,

AamirM

Holy crap! That's slow!! It runs Sonic 3 slower on my 2.4 GHz X2 than my PSP.

Maybe something is wrong with the way the timing is handled.

Really??? Runs fine on my pentium 1.6 Ghz. I'll llok into the problem. Thanks for reporting.

AamirM wrote:

Chilly Willy wrote:

AamirM wrote:Hi,

For people using Linux, I have uploaded the Linux version. Tell me how it goes.

stay safe,

AamirM

Holy crap! That's slow!! It runs Sonic 3 slower on my 2.4 GHz X2 than my PSP.

Maybe something is wrong with the way the timing is handled.

Really??? Runs fine on my pentium 1.6 Ghz. I'll llok into the problem. Thanks for reporting.

I guess I should give some more info about the system. I'm running 64 bit Ubuntu 7.10 (with the latest patches from the repo). According to synaptic, libsdl is 1.2.11-9 (latest in the Ubuntu repo). I use an nvidia 7900GT with the driver installed by the proprietary modules handler (v100.14.19). The CPU is an AMD Athlon X2 4600. I don't use desktop compositing because that interferes with the sync to vertical blank with the current code in 7.10. The upcoming 8.04 seems to fix this, but those fixes aren't backported yet.

The program runs consistently slow... like it's full speed, but waiting twice as long as it should for each frame. It's not speeding up and slowing down like you'd expect if it were having trouble reaching full speed. That's why I thought it might be timing related.