Gens 32 Surrial

Shadow · Post by **Shadow** » Fri Nov 13, 2009 4:06 pm

Today i downloaded latest version Gens 32 Surrial V1.86 SE
Aaaaaaaa! i don't know what they do!

but sound completely broken! i run Sonic and Knuckles and it produce distortions and loud bass! i remove all improvements which selected by default and notice this is copy of Gens! bad idea add things which actually don't supported in real thing!

and 192000Hz this is impossible, no no i can't find speakers which can produce this sound rate

Because analog signal is 22050Hz and it can do output to digital 44100-48000Hz

I search new software and try to find good side's and in Gens 32 i don't find any good unique stuff for me, i don't say what is bad emu, but i can't understand at all

Maybe this emu only for fun?

Yeah my first emu was Gens 2.10 thanks to Stйphane Dallongeville he really exellent coder, after Gens 2.10 second emu was Kega Fusion 3.52 after 8 months Kega Fusion 3.61 and now Regen 0.96-0.972 and Kega Fusion 3.62-3.63 i never forgot past time and history of all my lovely emus, i every week read history of each emu

When i do mistakes or can't understand something:

http://www.megaupload.com/?d=M7PP2GEL

Yes this is my Dark Side, sometimes i can't understand myself! i always choose side before do something important, actually i very smart man, but too closed most time, my hobby read books and journals, now i have unlimited free time, unfortunately i have big problems with health, this problem started in past time when me was 13 years and now me 23 years, i still alive, please wish me good health, i need it

Thanks friends

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Nov 14, 2009 9:11 am

high sample rate allows for better representation of frequencies, even if you do not have speakers to play back this sounds... your sound card has filters on inputs and outputs anyway that cut off everything above ~20KHz.

a 22025Hz sine signal is more of a square wave rather than sine at 44100Hz sample rate, since there's only 2 samples per period... now at 192000Hz you'd have quite a few more samples per period thus better representation of the signal.

Shadow · Post by **Shadow** » Sat Nov 14, 2009 9:15 am

Maybe you right, but my Realtek HD ALC889A and all drivers which i try, not work well with 192000Hz if only 96000Hz or 48000Hz work perfectly for me

Shadow · Post by **Shadow** » Sat Nov 14, 2009 3:48 pm

I understand..... Gens 32 Surreal for Sonic the Hedgehog Hacks, i read some info about this emu, one man writed what Regen and Kega Fusion may lock up on some Sonic hacks

Now i understand it

King Of Chaos · Post by **King Of Chaos** » Sat Nov 14, 2009 4:08 pm

Which Sonic hacks? All the ones I've played work fine - it must be something those making the hacks are doing wrong.

Shadow · Post by **Shadow** » Sat Nov 14, 2009 4:17 pm

For example: Sonic 1 Brother_Trouble, Sonic 1 Secret, Sonic 1 Sonya and Silver, Sonic 1 Ring Rush, and others hacks

King Of Chaos · Post by **King Of Chaos** » Sat Nov 14, 2009 5:52 pm

The few I've tried listed there work fine in Kega and Regen.

Shadow · Post by **Shadow** » Sat Nov 14, 2009 6:06 pm

Yes but some these hacks may hang on some levels or in title screen
for example try this: Sonic 2 Rockman Chaos, "Sonic 1 S3 Edition" in this game just press twice button and game hang!

King Of Chaos · Post by **King Of Chaos** » Sat Nov 14, 2009 6:53 pm

Ehhh, I tend to avoid ones like this. Sonic Megamix and Sonic Boom are damn good hacks though.

Chilly Willy · Post by **Chilly Willy** » Sat Nov 14, 2009 7:51 pm

From what I've seen, the Sonic hacks that crash emulators are because the emulator is working PROPERLY. Many of the people working on Sonic hacks have a devilishly hard time remembering that the 68000 generates a fault when words (including instructions) and longs fall on odd boundaries. Some emulators ignore this while fetching words and longs to gain just a little more speed, so those hacks that put data or code on an odd boundary run on some emulators, but not on others... or on real hardware.

When a hack catches my interest, I usually burn it on my flash cart and play it on real hardware to see if it has this problem. If it does, I report it to the person doing the hack. An example is Sonic MegaMix - updates sometimes failed on real hardware as they kept forgetting to make sure they keep to even boundaries. I've reported the failure a couple times, which they then fixed.

Huge · Post by **Huge** » Sat Nov 14, 2009 11:54 pm

I refuse to care about sonic hacks until someone makes an edit where Sonic is replaced by Zupapa.

Shadow · Post by **Shadow** » Sun Nov 15, 2009 3:42 am

Yes i know what Gen 32 Surrial inaccurate emu, Regen and Kega 100% correctly work and just hang on illegal instructions

TmEE co.(TM) · Post by **TmEE co.(TM)** » Mon Nov 16, 2009 7:19 am

Chilly Willy wrote:From what I've seen, the Sonic hacks that crash emulators are because the emulator is working PROPERLY. Many of the people working on Sonic hacks have a devilishly hard time remembering that the 68000 generates a fault when words (including instructions) and longs fall on odd boundaries. Some emulators ignore this while fetching words and longs to gain just a little more speed, so those hacks that put data or code on an odd boundary run on some emulators, but not on others... or on real hardware.

When a hack catches my interest, I usually burn it on my flash cart and play it on real hardware to see if it has this problem. If it does, I report it to the person doing the hack. An example is Sonic MegaMix - updates sometimes failed on real hardware as they kept forgetting to make sure they keep to even boundaries. I've reported the failure a couple times, which they then fixed.

soooo true.... I've been helping to fix some hacks on that regard... for example, the S-Factor had all MOVE #0 replaced with CLRs and well you know what happens when you CLR on VDP

Shadow · Post by **Shadow** » Mon Nov 16, 2009 10:30 am

Uhh! Gens 32 surrial can't run in fullscreen mode i try all plugins render methods but not work, all graphic like a big glitch meshed up

Yeah i run it on Win XP and all work fine, still not work on Vista, bad!

I think this emu have problems with video cards and work differently on others video cards

Bass too loud in this emu, ughh bad taste, i don't love loud bass, because even in my real thing with TV set this impossible

it cause distortions and clicks in my realtek alc889a

i think sound output in Gens 32 do +2DB this wrong! it can't be more than +0DB

I big expert in recording audio and video and 100% sure what sound output must be limited to +0DB because overdriving to much may cause distortions and another problems with speakers and sound cards.

My last motherboard was with Realtek ALC888 she give powerful bass in games and what happen if i try use Gens 32 surrial? it will be horror bass! my current motherboard have normal sound, and it most accurate sound than ever! all my old motherboards have inaccurate sound standard problems: blurry sound, clicks, distortions, eternal bad audio drivers, and other nasty things

I think what people try to make sound in Gen 32 close to modern MP3 sound tracks, but it wrong! it kill our good past time! if it will happen in all emus, this is will be end for original Mega Drive 2, i pray this is not happen in future, for example in 2025 year

I always play these games, no matter how much time gone and in 2040 i always help with emulators, i promise, Sonic the Hedgehog never die

How i love find bugs in emus and PC applications!

GManiac · Post by **GManiac** » Mon Nov 16, 2009 10:37 am

TmEE co.(TM) wrote:the S-Factor had all MOVE #0 replaced with CLRs and well you know what happens when you CLR on VDP

Why so? I thought MOVE #0 and CLR are working internally the same way if you look from the side of MMU or RAM. I mean if you perform instruction:
MOVE.B #0,Addr
or
CLR.B Addr
then next steps are performed: after decoding opcode and reading data (for MOVE) CPU generates data byte of #0, then it places it on data bus and Addr on address bus and then this data byte is sent to RAM to address Addr. This step is handled by Memory Management Unit (I dunno how this thing is called exactly), so VDP can't know what instruction CPU used indeed.