The additional 43+k makes the difference of doing 9.5khz@4bit vs 11.11khz@4bit. That's not bad at all. But you'll have to redo the pointer table.Quote:
Originally Posted by Stef
Printable View
The additional 43+k makes the difference of doing 9.5khz@4bit vs 11.11khz@4bit. That's not bad at all. But you'll have to redo the pointer table.Quote:
Originally Posted by Stef
Indeed, that allow a small increase on bitrate and may be worthly. Again, i guess i will see that in a "second" pass :) Right now i'm on vacation and take benefit from the sun and the swimming pool but i plan to get back to that asap ;)
Hi Stef!
maybe you can take a look in Fatal Fury 2, for me this game have alot of good voices samples for a fighting game
https://www.youtube.com/watch?v=rsagnHYscPs
Or Mortal Kombat II Unlimited
https://www.youtube.com/watch?v=9LBqJ-RtZmg
Its a hacked game but he has the best voices samples in a fighting game of mega drive and runs fine in my flashcart
Good Job Stef!!! ;)
If after Stef finish this project he can do the same with Slammasters can charge me an enhanced color hack for this game as I did for Street Fighter 2 SCE!Quote:
Originally Posted by Barone
Erf... i can't do it for each game ! A lot of games has a custom driver to play PCM (different command, different SFX encoding, different playback rate...) and definitely that requires some work to disassemble the driver, reverse engineering it and develop a new compatible driver which improve playback quality.
And you also need to modify the game code itself to upload your new driver and disable Z80 interruptions... definitely not an easy task !
I'm doing it for SF2 because it is a very famous game known for its poor voices quality...
Then i will have a look in others games as SSF2, SOR2 / SOR3 and only it they use similar driver maybe i will try to do something ;)
By the way, about SF2, the new driver is almost complete, i really don't like how the code turned out but it does its job... I will do something better / more generic latter and it will be integrated in SGDK.
The pitch seems a bit lower in the new driver so i guess i made small mistakes in my cycle counting (it's really a pain to fix it every time you change one instruction), also the bad point is the lag introduced. Because of the buffering (i am using 4 x 256 bytes buffer) and the low sampling rate we can detect a gap between the moment we push button to play voice and moment where voice is actually played... it's not that bad on real hardware (emulator add more lag due to their sound buffer) but still we can detect it.
Now i need to modify the game code, to remove "disable Z80 command" when DMA is used, then i will have to modify the driver itself.
The thing is that right now i'm using the VInt to detect start of vblank but SF2 extends VBlank :-/ if they really do DMA before VInt time then my driver won't fix the problem (or not completely) so i hope that is not the case. Otherwise i will have to use a more complex way to allow "custom blank period" in the Z80 driver.
I've been thinking, and a really awesome feature for a high-level assembler to have would be a cycle padder. You write whatever code you want, and you wrap it into a "cycles 200 {...}" primitive thingy. The assembler takes care of adding "nops" or equivalent to each branch to make it take the number of requested cycles.
That would save so much work, the assembler already knows how many cycles each instruction takes so why is the programmer doing this work manually? Seriously we programmers sometimes do things by hand that computers were made to do!
Indeed in my case that would save me a lot of time ! But hey, I don't think there is any assembler supporting that type of feature ;-)
Given assembler translates to machine code surey it's impossible without it being a hardware feature?Quote:
Originally Posted by Stef
High-Level Assembler, basically it's an assembler that besides supporting direct machine code, features higher level primitives to make code easier to write.Quote:
Originally Posted by matteus
Best example is NESHLA:
http://neshla.sourceforge.net/condit...dex.html#while
This is all just pretty machine code, the instruction I mentioned above would just be a primitive like this, you give it a parameter and it generates the corresponding machine instructions.
Note that it's not the same as a C compiler, this is still pure machine language with pretty syntax. For example "ifs" and "whiles" can only have as a condition the exact same test the machine instructions for jumps do.
Some news about my project :)
I made the rom modifications to remove "Z80 disable instruction" on DMA and also included the new driver.
Here is a first version which only include the modification to remove the "Z80 disable instruction" on DMA :
https://dl.dropboxusercontent.com/u/...sf2_mod_v1.bin
If you try this rom in an emulator (except very accurate ones) you will notice how voices are better now (well as much than 4.8 Khz allow). This is because almost emulator does not emulate the BUS interaction with Z80. On real hardware however it still sounds crappy (maybe a bit less than initially, but still really crap).
Now here is the second modified version :
https://dl.dropboxusercontent.com/u/...sf2_mod_v2.bin
This version includes my new sound driver but right now the result is still far from perfect. There are several issues about it :
- The first one, and it is a big one, is the latency issue. Because i'm using 4x256 bytes circular buffer length, everything is timed on this and while it does work quite well for 16 Khz playback, it does not work well for low rate as 4.77 Khz. This comes from the fact that 1 buffer length (16000 Hz / 256) is just below a NTSC frame in term of time (which is perfect), so new command are handled at each frame and usual sound latency is 4 frames which is small enough and not really noticeable. But 4770 Hz / 256 is a bit above 3 frames ! So the latency can be as big as ~14 frames (which is really noticeable).
- Even worse, because of this important latency we can now miss some SFX commands when they are too close (separated by 1, 2 or 3 frames) and it's exactly what happen :-/ Some voices or drums are missing...
- Another problem is that DMA is probably starting a bit too soon and so voices are still not perfect (definitely better but not as good they could be), hopefully i believe only one small DMA retains the bus, the others ones happen in vblank and the driver is protected against them.
- There is also a 'pop' at initialization but hey i don't mind too much about this one right now ;)
I plan to fix the lag issue by shortening buffer (that requires some modifications in the sound driver). Ideally i would have preferred to use higher sample rate but i really want to start with originals samples and having them sounding right ;)
New version :
https://dl.dropboxusercontent.com/u/...sf2_mod_v3.bin
I used shorter buffer (64 bytes) and so there is less latency but unfortunately even 3/4 frames is noticeable depending the music (Ruy stage for instance, we immediately heard there is something wrong as beat should be synchronized on FM instruments)... ideally the music should be modified for the driver. Also there is still some missing PCM sfx, when they happen too close to each other, i believe i have something a bit wrong in my driver about priorities, have to check that...
I'm very dumb. Has the new rom with best audio quality possible been posted yet ? Or is this sf2sce updated audio version still a work in progress ? Why not ssf2, does it have a different audio or mapper engine that will make it more difficult than sf2sce ? I believe somebody here worked on a pc engine sf2 graphic and audio update but idk if that rom was posted either.
Not the finale version as there is an issue to fix about missing sfx (i won't be able to do more improvements on latency).
Also latter I may try to use better samples. I wanted to do sf2ce first as imo it's a better game than ssf2 but if ssf2 use the same driver then I can patch it easily later :-)
Amazing project, stef.
I can't share your thoughs about SFII:SCE being better than SSFII, though. Even when both being rushed snes ports, not taking any advantage from MD other than unplayable speeds when maxed, at least SSFII have better use of palletes and some minor technicals improvements.
Crapcom :/
It sure is. SSFII is pretty lame on both SNES and Genesis IMO.Quote:
Originally Posted by Stef
By the way, I played the lastest version yesterday and it's really cool to notice the better sounding drums. I think this game will sound very good once you manage to debug your driver and improve it a bit.
Looking forward to it, Stef. Keep up the good work!
dr apocalipsis> I agree they made a better work on GFX but on others points it does not really outperform sf2ce, the music is so weak.
Barone> thanks :) yeah i really need to fix that small issue about missing SFX, it's really annoying. The latency is a problem too, i think i can reduce buffers size to 32 bytes (using 64 right now).
It's a dream to play Street Fighter II 'on my mega drive with quality samples!
Fantastic work! Long live to this project!
Thanks :) That also show how capcom fucked up this part in the megadrive conversion ;)
Here is a new version :
https://dl.dropboxusercontent.com/u/...sf2_mod_v4.bin
The latency is ok now, reduced buffer size to 32 bytes, and write buffer is only separated from read buffer by 2 segments (it was 3 as my circular buffer is 4 segments length). I cannot do any shorter latency else i will start to experience reads over write position in some case... hopefully latency is almost not perceptible now :)
I fixed a minor bug in the priority thing but it did not fixed the missing SFX bug :-/ my Z80 driver does some stuff a bit differently (as the internal counter update), maybe the 68k sound driver was using it for something after all. Also i can really heard that even if samples are far better than in the original game they are still a bit scratchy because of the early DMA. That is something i will try to fix at some point too.
Really impressive
Version 4 is awesome already, great job Stef!
Thanks!
Just tried it on my CDX. The sound is much better then original game. Very impressive. I cant wait to play future versions.
Thank you for answering. In one thread, a guy here made a pc engine fix and I saw people ask him about if the cloud could move in blanka stage on md. Could this be done in your next rom update while you incorporate even better audio ?
Thanks guys ! I really want to make it as it should have been ;)
phoenix>
I really don't plan to make that type of changes, things as "cloud scrolling" in Blanka stage or others patch requiring heavy code modifications.
The problem is that we don't have the source code so for any change we need to disassemble and find which part to patch and how to do it (insert new code, changing route...). It's actually *a lot* of work for small benefits. I'm patching the PCM driver because this part is isolated and independent from the rest of the game code (working on Z80 cpu with its own memory) and also because this part is really poor in the original game !
I'm struggling to notice a difference but then I've not listened to the originals in months! Any chance someone can do some comparisons? :D
Thanks for the answer. Do you think "rom version 5" will be the final, best audio quality version ? Can't wait to try that out on real hardware like my model 1 with my everdrive.Quote:
Originally Posted by Stef
Fantastic!!! I have to try it in my everdrive but even in Fusion is soooo much better!
There is always way to do better ;) Right now i used original samples and i want to keep them at least to get a more authentic patch (only the crappy PCM driver is modified). But yeah i would like to have the next version as the "good" one (no more missing SFX at least). Later version (if they exists) will probably be based on different sample bank (4 bits at higher rate for instance) and so not as "authentic"...Quote:
Originally Posted by phoenix
Actually it's normal that it sounds a lot better with Fusion ;) even the first version i posted (which still use the crappy driver) sounds really good in Fusion as i removed the Z80 disable command. But it sounds crap on real hardware while version 4 sounds a lot better.Quote:
Originally Posted by Tor Landeel
When next version will come i will make a youtube video to show difference between "before" and "after". Believe me, it is *very* noticeable ;)Quote:
Originally Posted by matteus
Another fantastic work Stef! This is really awesome.
http://i2.kym-cdn.com/photos/images/...52/203/52c.jpgQuote:
Originally Posted by matteus
Ok Stef, bare with me I'm not too sharp but I want to ask you these questions. Maybe you could copy and paste these questions and answer all ?
The Genesis max audio frequency is 22.000 hz, half the quality of a cd that is 44.100 hz yes ?
So a game containing music soundtracks and sound fx at 22.000 hz would end up being a huge game/rom yes ?
So I guess many companies used half of that for certain sounds, like 12.000 hz or lower ? Anywhere from 4 hz to 12 hz for sampled voice samples and maybe 22 hz for the Genesis synth sounds / instruments ?
Only one channel is for audio samples ?
How big would an update of your rom be using 12 hz for sound fx and instrumentals? Or are you going to compress (from a program you have for vg sound quality I guess or even Adobe or ?) the arcade sf2 sound quality sounds from I guess 44.100 hz directly to 12 hz or even 8 hz to save space or ?
I'm only saying this because most everdrives could handle like a 5mb rom so maybe create a rom that size using best audio quality as possible ?
I'm interested in the hz/frequency/sound quality for sound fx and instrumentals you will be using. I think you said 4 hz for sound fx? 12 bit or 12 hz is very crunchy but kind of tape cassette clear, using 22 hz for all sounds, half a cd which is 44.100 hz, would be too much for Genesis ?
Cool :) hopefully my comment didn't come across as trolling because it most definitely wasn't :)Quote:
Originally Posted by Stef
No. 53 kHz actually.Quote:
Originally Posted by phoenix
And you can't express the quality of audio just using frequency, that's oversimplification.
It also depends on the number of sampled/PCM sfx and instruments. Some games on the Mega Drive use mostly FM-generated sfx and FM-generated drums (a lot of games, like Sonic, use PCM drums for better sounding drums), such games will save a lot of ROM space compared to the ones using lots of PCM sfx and good quality PCM drums. FM music and sfx consume very little ROM space.Quote:
Originally Posted by phoenix
That's one of the reasons why some multi-platform games (SNES/MD) have more content on the Mega Drive. The Lion King, for an examples, has several in game sfx which are FM-based on the MD and they were completely cut on the SNES, probably 'cause they would take some crucial ROM space if they were redone sample-based (mostly using ADPCM in the case of SNES AFAIK).
Castlevania Bloodlines is a game where most of its audio is using just FM, including the drums in the soundtracks. There's just a few short voice PCM samples for some enemies' moans and stuff like that. Despite being released in 1994 (when 16 Mbit and 24 Mbit cartridges weren't exactly rare), it uses an 8 Mbit cartridge.
That game, though, also uses stuff like mostly jointed bosses (several small sprites composing a boss; each of those small sprites being moved independently but coordinated in order to give you the impression that it's one huge sprite being animated - it takes a lot of CPU resources to do it, so usually SNES games have noticeable slowdown with jointed bosses - Pitfall's last boss is a good example for comparison - or just use choppily animated bosses to replace them) (Bloodlines' Golem and Gear Steamer bosses are good examples: http://www.spriters-resource.com/res...s/21/22552.png and http://www.spriters-resource.com/res...ets/6/5793.png) (Compare those sprite sheets with these bosses from Rondo of Blood: http://www.spriters-resource.com/res...s/10/10344.png - which ones do you think require more space?) instead of traditionally animated ones also to save space while trying to preserve the animation quality.
On top of that, you also have the Mega Drive graphics system (chunk-based vs planar-based on the SNES) being a lot better for using compression and that, combined with the more powerful CPU, allowing for some degree of on the fly decompression which you'll hardly obtain on the SNES.
The SNES, however, has the advantage of supporting ADPCM sample playback while the Mega Drive has to use the regular PCM, which is not compressed and thus require quite some extra space.
So, in other words, the Mega Drive games will only suffer badly with ROM space if you use the hell out of PCM-based sfx/voices and high quality PCM drums 'cause PCM demands a lot of space (and in such scenario, the SNES would require less ROM space 'cause ADPCM audio data would be quite smaller in comparison).
Again, the frequency ALONE doesn't determine how much space the audio data would require. Like Tom and Stef were saying some posts ago, you could have 8-bit 4.5 kHz PCM data having the same size of 4-bit 9 kHz PCM data; so the bitness also matters, for an example.
And the use of 22 kHz PCM sfx and/or drums would depend on an audio driver which could perform the playback competently at such frequency. Stef can give you a lot more details in such aspect, but it depends on the number of PCM channels you want to have and the efficiency of your audio driver code; to begin with.
Like I said before, the FM-based sounds can use higher frequencies than 22 kHz.Quote:
Originally Posted by phoenix
But for PCM sound using the same bitness, yes, lower frequency means less ROM space used. IIRC, Mortal Kombat II uses 13-15 kHz PCM and Samurai Shodown 8 KHz PCM, to give you an idea of what those "good sounding" games are using on the Mega Drive.
By the specs, yes. But in practice you could have up to 4 PCM channels using software mixing while still having some FM music if you had a competent audio driver.Quote:
Originally Posted by phoenix
Some games using multiple PCM playback on the Mega Drive are: WWF Wrestlemania: The Arcade Game, Mortal Kombat 3, Ultimate Mortal Kombat 3, Flashback.
Some older games used the PSG to playback the samples, like Space Harrier and After Burner.
Super Hang-On uses the PSG for most of its sfx so it doesn't cut the music due to samples playback like some other early games - Altered Beast playback the voice samples using the FM PCM channel but halts the music to do so.
Adobe??? Man, most of the "modern" compression schemes require a VERY powerful CPU, something worlds and worlds more powerful than the MD's CPU.Quote:
Originally Posted by phoenix
The arcade samples of SFII are nowhere near to 44 kHz. Have you ever played that game on the arcades?
Something like 4-bit 11 kHz samples playback would make it hard for you to notice any difference between the MD version and the arcade version if they were using the same samples and mostly identical compositions.
To use that 5 MB/40 Mb mode in regular Everdrives you'd have to change the mapper of SFIISCE, and that isn't happening for the sake of how pointless it is since the game has still 8 Mbit to expand using the regular mapper.Quote:
Originally Posted by phoenix
That extra 1 MB would already allow for any necessary improvement in the quality of the samples used in the game. But once you're using bigger higher quality samples, you'll have to re-build the pointer table which indicates where each sfx/voice is inside the ROM.
And Stef would also need to customize his audio driver once again in order to play samples of higher frequency and bitness.
Again, it's not that simple.Quote:
Originally Posted by phoenix
And if want cassette sound, the SNES is the system for you. Oh, maybe cassette underwater... cassette underwater inside a bathtub and with the bathroom door closed actually. ;)
Nope we can't really say that. The YM2612 is generating sound at 53 Khz and so you may assume that if you can feed up the DAC at this speed you should be able to have 8 bits PCM at 53 Khz. In reality however when you try to feed the DAC that fast it looks like it can miss some writes... Tiido reported to have observed usual limit to ~26 Khz but from my tests i can still heard differences until 32 Khz (and i tested on different systems). So we can say the limit is between 26 Khz and 32 Khz ;)Quote:
Originally Posted by phoenix
Indeed ! But you can use 4bit ADPCM compression to reduce rom usage, still 22 Khz 4 bits ADPCM eats about 660 KB per minute (and so 1.3 MB for one minute of uncompressed 22 Khz PCM).Quote:
So a game containing music soundtracks and sound fx at 22.000 hz would end up being a huge game/rom yes ?
Yeah, almost games used between 4 Khz and 12 Khz samples, maybe 16 Khz for specific PCM requiring high frequencies...Quote:
So I guess many companies used half of that for certain sounds, like 12.000 hz or lower ? Anywhere from 4 hz to 12 hz for sampled voice samples and maybe 22 hz for the Genesis synth sounds / instruments ?
Again the YM2612 sound / instruments are FM synthesized so you cannot speak about rate (if you consider the YM2612 generation rate, then it's 53 Khz but well you should not take it, just think it's "high enough").
The YM2612 only has 1 hardware PCM channel (in replacement of FM channel 6), so basically i would say yes... but you have the Z80 CPU to drive all the sound, so a good driver will be able to do software mixing and so allow 2, 3 or even 4 PCM channels.Quote:
Only one channel is for audio samples ?
One of the trick i can use is to replace 8 bits PCM by 4 bits ones so i directly jump to 9.5 Khz (at the cost of depth quality but it should be better than low rate)...Quote:
How big would an update of your rom be using 12 hz for sound fx and instrumentals? Or are you going to compress (from a program you have for vg sound quality I guess or even Adobe or ?) the arcade sf2 sound quality sounds from I guess 44.100 hz directly to 12 hz or even 8 hz to save space or ?
then by using empty space i guess i can even get 12 Khz samples without increasing the size of the rom.
Of course we could eventually use 22 Khz 8 bits samples, but honestly, that would require a big rewrite of my driver... Because of some restrictions and how work the original driver (i need to be 100% compatible) i had to make some weird things we should avoid normally and so i probably can't get 22 Khz playback while maintaining this retro compatibility (game code has to be modified to use the new driver instead of mimicking the old driver).Quote:
I'm only saying this because most everdrives could handle like a 5mb rom so maybe create a rom that size using best audio quality as possible ?
Edit: just realized Barone already replied, sorry for the double response then !
Very insightful :) cheers Barone and Stef! MD sound has always been a weak point of mine. So what actually causes the scratchyness on the sample playback in SF2CE the way the driver plays the sample or the sample itself?
Improvement via your sound driver would suggest the driver?
The scratchyness is caused by a single thing : the BUS contention.Quote:
Originally Posted by matteus
When you play sample from the Z80, sometime it does request the 68000 BUS (master bus) to fetch the sample from the ROM.
The problem is that when you use the DMA it locks the master bus during the transfer and so the Z80 is locked if it try to use the master BUS at same time, then your sample pay is scratchy.
To avoid this problem you have to avoid fetching sample when DMA occurs. So the question is how to do it ?
Well usually DMA occurs during VBlank because they are way faster during VBlank than during active period.
Hopefully you can know when VBlank start on Z80 with the VInt. So what we do is that we put some specific code on VInt to not fetch data from the master during all the VBlank period (I use cycle counting but we could even use the YM2612 timer for that).
But then if you can't access the master bus how do you read your sample ? easy ! you just buffer sample in the internal Z80 memory (8 KB which is more than enough for that) and here we go. That is what my driver does... of course it is more complex than just fetching sample on the fly but it also allow important optimization for mixing operation (don't need to change the slow bank register each time) so buffering is definitely the way to go when you work with PCM with Z80.
Have you started experimenting with a 4bit/9.5khz driver yet? I really curious to see how that sounds.Quote:
Originally Posted by Stef
One thing I never understood, is why Sega never made a cheap audio chip on cart. A simple DAC with a small cache, or a self feeding DAC from rom. I mean, NES had waaaayyy more complicated addon chips than that (all sorts of audio chips with more channel and some with extra DACs too). And the SNES put whole CPUs on carts (SA-1).