Jump to content

ZeroByte

Members
  • Posts

    433
  • Joined

  • Last visited

  • Days Won

    29

ZeroByte last won the day on October 6

ZeroByte had the most liked content!

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

ZeroByte's Achievements

  1. They’re just paying the high early-adopter price that will eventually lead to it becoming affordable to the masses. Like in the 50s, the rich were called the jet set.
  2. So... what I'm looking into doing is just collecting the PCM samples and figuring out the sample rate / bit depth / etc from the VGM file in my pre-processor. My thought is to load those into memory along with a generated index file from my preprocessor. Then inject "play digi X" messages into the music data stream. I'm not sure about the analysis / packaging part just yet.... Question for you: is the DAC always always ALWAYS 12-bit data on YM2612? I know the sample rate is not really defined, as that's a product of how fast samples are written to the DAC, but I imagine that any given game was probably consistent - but that is probably a bad assumption. Perhaps if I keep track of delta-T and N-samples played, I can compute the sample rate for a given playback and generate "play digi" commands that include sample rate to be used. Assumptions - nobody was ever a mad lad enough to do things like compress the digis by having data inteded to be played back with various portions looped in order to get the real sound - e.g. a sample with an attack, a piece of the sustain, and then a decay. It's possible, and given how precious storage space was back then, it may be that games did in fact use techniques like this. For now, I will be happy if I can just get the PCM drum track working for my Sonic the Hedgehog music conversion demo that I posted earlier - you know, for completion's sake. If whatever tactic I use works in the general case would be "Bonus points" but not required as a success metric for me.
  3. I did OPL on-system but it took an 8k LUT. YM2612 and YM2203 would be able to use the same LUT. It’s for converting the note frequencies, which unless there’s some algebra I haven’t done that can simplify the conversation, these calls require large numbers. For now, I’m pre-converting them into my own byte stream of YM2151+PSG writes. This method means it’s fast on X16 but may consume more space. Usually PSG is the big culprit.
  4. Yeah, I've looked into Sega PCM translation (because Deflemask uses it for 2151 tunes) and that's not going to be trvial to support. It's going to have to mix several channels of PCM and IIRC, resample prior to mixing. I've already made SN7XXXX, AY, ~SID, 2612, 2203, and OPL conversions to X16. Simple square PSG is pretty easy to convert. It's things like non-white noise that don't translate well. Once my current demo is done, I may try doing NES APU next. As for using the bit bang DAC techniques of other chips, I'm not a fan. Seems like a waste of CPU when VERA has a PCM FIFO.
  5. Amazing. I can tell you that the 2151 is very similar in most ways to YM2151. There are 3 major differences: Voice 2 can use independent frequencies for all 4 operators of that channel Voice 5 can act as a DAC for digital audio playback Mysterious SSG register left over from the 2151's ancestor, the YM2203 (Sega's own internal how-to document just says "don't use this" Feature 1 can kinda/sorta be approximated for certain combinations of frequencies, but it's 90% not compatible Feature 2 is supported on X16 (obviously) via a standalone PCM FIFO in VERA. (and it's much better than the one in the 2612 which has NO FIFO) Feature 3: ? (I don't know much about it, but some people bang on it for strange effect apparently)
  6. The only portion of this music that is not currently supported is the PCM drum track. The way Sega Genesis PCM works is insane already (imagine VERA PCM but without a FIFO), and the way it's encoded in VGM is even more crazy to interpret and extract properly, so for now, pretend Sonic only gets drums whenever he's riding Yoshi. I fully intend to clean this importer up to more useful standards for sharing it with the community. As it stands now, it's full of special cases, etc - but it can import lots of types of VGMs to X16. It exports into my own music stream format which is also still not quite finalized. More to come!
  7. Stand up a Linux VM in Virtual box? Or build it on a RPi? If you have trouble, Ill PM one to ya.
  8. Pretty sure this arrangement exists because at the time it was designed, the 65c816 was still being considered.
  9. Ahh! That was the correct answer! (or at least I'm 99.9999% sure it is - obviously Strider may say I'm wrong too - lol)
  10. I just looked up a video of the Amiga version, and omg it's awful.
  11. The busy delay is incurred after each and every write to the YM data port, not just KeyON/OFF. I worked with @StephenHorn on the box16 emulator project while he was refactoring that emulator to use the new BSD-licensed YMFM core library. I've learned quite a bit about how this chip works. R38 has several inaccuracies in the YM implementation - the core it uses does not emulate the busy behavior at all. You can bang away on it all day long and it won't skip a beat. The library just handles it. Furthermore, I don't think the IRQ functionality is emulated, and I also think the timer behavior might not be implemented either - I'll go re-test this and let y'all know... Box16 has extended the YM support in several ways - it supports YM IRQs as well as busy flag behavior. Some of this has been a matter of the group's interpretation of other example code and/or the official YM2151 application manual. In other words, the current behavior in Box16 is our best guess as to the real behavior. Stephen has done an excellent job integrating this code and dealing with a colossal time synchronization nightmare, by the way. Kudos to his hard work! One of his decisions was to make these "enhancements" be disabled by default to maintain functional parity with the official emulator. They are activated by command-line arguments. Interestingly, when testing the accuracy improvements, one of my VGM playback routines went nuts and played an entire song back in less than 1.5 seconds. It turns out that the original VGM data stream contains commands that enable YM IRQs. My player just used WAI as a poor man's IRQ handler to wait for VSYNC. Thus it mistook these YM IRQs as VBLANK IRQs. The player was built to read the busy flag though, and even with strict enforcement of the busy state, the player doesn't drop any updates, so that seems to work properly. After removing the IRQ enable messages from the VGM, it plays back perfectly on Box16 even when it enforces busy flags. Real Hardware? The big question is how will this work on the real thing? As I said above, the behavior is currently our best guess based on other sources, none of which being real hardware. One thing I can say is that @SlithyMatt's Chase Vault game works on real HW, and the game's YM routine uses busy flag reads to ensure that it does not write to the chip when it's busy - so that's a good sign. Beyond that, I've sent a basic read test program to Kevin, as the YM reading functionality has never been subjected to testing on X16 hardware the way writing has been. So far, the "hello world" results are interesting. Kevin's only been able to test at 2 and 4MHz which the math says should work just fine on YM. 8MHz is the really important one, but as the system is currently experiencing other 8MHz-related problems, Kevin wasn't able to test at 8MHz. In short - the test program successfully read IRQ status flags w/o any errors at 2 and 4 MHz. Interestingly, the busy flag read test never observed the flag's having been set, but I think there might've been a bug in my code. I'm personally convinced that the write delay specification is actually a little bit different in reality than you might expect from reading the application manual. That is, I strongly suspect that the "64 YM clock delay" is not a minimum but a maximum. The data sheet definitely has other errata, and I'm convinced this is just another example. I have a real YM to test with, but don't have everything lined up enough to be able to put it on a breadboard and do real testing just yet. If I can get that done, I'm definitely going to poke around with the real chip's busy state flag to see what makes it tick. YM and write performance / overhead: As for writing performance with the YM, I'd like to point out that in my experience with generating byte streams of PCM writes and FM writes, the FM music data streams are much smaller than the PSG streams. This is completely to be expected. That's because the FM chip does so much of the modulation in hardware that you don't need to update it nearly as often to get decent-sounding music. PSGs must be constantly modified for every little thing, be it pulse width modulation, vibrato, etc - all of which is done in hardware on the FM chips. Consequently, you end up performing SIGNIFICANTLY fewer writes to an FM chip than you do a PSG over the course of a tune. Still, sitting around for ~144 clock cycles waiting on the chip to finish chewing the last bite is not ideal. I believe one way to handle YM writes may be to queue up the writes into a ring buffer, and have an IRQ that empties the ring buffer. You can set the YM's timers to run a little slower than the actual rate the YM could drain the buffer in order to cut down on the IRQ overhead. This would have the effect of spreading the load evenly throughout a frame if that's what you'd like to do. Kevin has confirmed that the YM2151's IRQ line is indeed connected to the system, so this should be doable on the real system.
  12. To me the #1 reason I like the YM chip is that it sounds like it does. I like the fact that both the FM and PSG sounds can work together could make for some truly great stuff.
  13. They've started a Super Metroid playlist, and wow - the first track is the mysterious statue that blocks the way to the final area - that track sounds mind-blowing on the original synths with uncompressed samples. The Mother Brain fight is pretty amazing too.
  14. The arcade version uses a YM2151. I bet the Commander X16 could do a near-perfect port.
  15. What's funny is that in a way, they made the revelations from the gigaleak just that much more special by virtue of their own secretive nature. If they just put all that stuff in "bonus features" sections like an assets gallery and had commentary nodes like Valve does - then people would've thought it was cool, but when it's been a mystery for years and years, with people slobbering gleefully whenver so much as a single unused asset gets mined from a ROM image.... well, the gigaleak makes people feel like they're holding a winning lottery ticket during a total eclipse on Christmas day.
×
×
  • Create New...

Important Information

Please review our Terms of Use