SpritesMind.Net

TmEE co.(TM) wrote:OK, I'll run some tests when I've finished my exam tomorrow.

Awesome

AFAIK, the sampling rate is around 52KHz (53203424(PAL) / something), accuracy 9 or 10 bits on discrete Yamaha YM2612 and about 12 bits on Sega internal YM2612. The bit count is an estimate, which I estimated by listening the amount of aliasing noise produced and comparing with WAV files degraded t...

Hey guys, Not sure if this is the correct forum (or place) for this, but I'm looking for the resolution and length of the internal sine wave used by the YM2612, OPL2, and some other Yamaha FM chips. I *think* I remember TmEE mentioning the 2612 had a 9bit resolution on the sine wave, but no mention ...

AamirM wrote: Absolutely not. I hate hacks.

That's good to hear (just asking - you work fast )

AamirM wrote:I think Regen will be the first emu to run it correctly .

You're not using emulation hacks for specific games, right?

Moreover, some of those even run at H32, and you know that there things are a lot slower... Via DMA, 256x224 takes 4.797 frames to update the screen in H32 where as 320x224 takes 4.856 frames to update. Fairly close and you save vram space using H32. So it's not really slower - actually it's a hair...

And you've tested this on the real hardware? I would actually want to know from where did Sega get all those timings. Maybe they just took into account VBlank? Because this subroutine will continue sending data while in active scan. I mean, the Mega Drive isn't as slow as the tech docs say. Otherwis...

Sik wrote:Already saw that. And 10FPS (you) vs. 30FPS (me) *shot*

I'd like to know how you're getting a faster transfer rate than local to vram DMA? H40 mode with 224 active scanlines is 7380bytes per frame and you're transferring 17920bytes per frame without DMA!? Please explain.

org wrote:Breakpoints to access at address are usually called memory watches.

From my experience, memory watch is just that. To keep a display of a certain byte/word/whatever of an address. Breakpoint!=watch, though I'm sure some debugger somewhere switches around the terminology.

Also, there's no hardware volume specifically for channel 6? Or is that just in DAC mode? If not, then you should be able to work around that issue by shifting the lower 8bit part(only, not the MSB) to the right one bit. That will get half the volume for the lower part, but at the cost of outputtin...

True, it should be tested first. I have no plans to immediately write a player (got my hands full with a bunch of other projects). Though, given that I've seen this method working fairly decent on a 7khz timer to playback 3.5khz with double the bit rate by interleaving, I'm fairly certain 32khz is h...

That would make a 9 bit sample, not a 16 bit sample. Interleaving ADDS the samples. Two 8 bit samples added together gives a 9 bit sample. You would need a method of multiplying the samples to make two 8 bit sample yield a 16 bit sample. Hehe, well I forget a step. You need to play the lower eight ...

Yeah, all mixing and limiting would be done on the 68k side. All the z80 would do is stream the final output. HardWareMan use that way. He is on this forum, maybe it's worth for you to contact with him? Will do :D I was thinking, if one were to go the route where the z80 just wrote to the YM DAC an...

Yeah by "clipping" i also understand "limiting", no clipping is just "overflowing" and in this case it's very noticable even on a single byte. As Shiru said, limiting a sample is heavy and can't be handle on Z80 if you're already severals channels mix... Yeah, all mixing and limiting would be done ...

I'm pretty sure that I can hear one wrong sample (yes, just one byte or word) of mixed stream, if it broke waveform, i.e. if it's actual clipping (not limiting). If you'll do limiting, i.e. handle clipping as I said above - yes, it will be not so easy to hear. But it can't be measured in % of clipp...