A question to Mega Drive/Genesis musicians out there.

Discussion in 'Discussion and Q&A Archive' started by MarkeyJester, Oct 31, 2016.

  1. AURORA☆FIELDS

    AURORA☆FIELDS so uh yes Exiled

    Joined:
    Oct 7, 2011
    Messages:
    759
    And I want to chime in on what Markey said, I am going to be releasing my work as open source soon enough anyway, so its not like I would see stealing content as this huge issue some people claim it still is.

    Does that mean I can disassemble TNL and steal all dat smooth animation and teh arts? =)
     
    FireRat likes this.
  2. Clownacy

    Clownacy Retired Staff lolololo Member

    Joined:
    Aug 15, 2014
    Messages:
    1,016
    Let's just agree to disagree before this thread completely derails.
     
    ArcaniaCQ and EMK-20218 like this.
  3. amphobius

    amphobius spreader of the pink text Member

    Joined:
    Feb 24, 2008
    Messages:
    970
    Location:
    United Kingdom
    Whilst I think you know what my answer will most likely be, I'm more interested in the finer details of what your plan actually is!

    My opinion when it comes to sample playback on the DAC is that I want something that will avoid quality loss, free from the stops that are usually inhereted from Z80 based drivers (well, except when that gritty sound is desirable, but I digress). I know you're capable of doing that and I remember you sending me some stuff long ago where you managed high quality sample playback via a Z80 based sound driver - I'm concerned about what would come from having to also mix two seperate streams in software. If you say you can manage to do this without sacrificing quality I'm keen to know what your ideas are! I remember that for TNL you had some sort of buffer system, and my naive guess would be that something similar would come into play with this?

    Don't consider this as me questioning your ability, rather trying to figure out what the scope is. Hope it works out well.
     
  4. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    Well, the main problem is, there's not enough space in Z80 RAM to store all of the samples you could ever need, so the access window into 68k memory is necessary, but, if you intend on reading two samples at a time, you have to keep switching back and forth. This creates a problem as the window switching port takes in one bit at a time, a simple example:

    Code:
    		ld	(hl),a
    		rrca
    		ld	(hl),a
    		rrca
    		ld	(hl),a
    		rrca
    		ld	(hl),a
    		rrca
    		ld	(hl),a
    		rrca
    		ld	(hl),a
    		rrca
    		ld	(hl),a
    		xor
    		ld	(hl),a
    		ld	(hl),a
    In this instance, hl = 6000, and a = the 68k upper bits FF8000. That is a lot of time to spend on changing a window address, it is a crying shame they didn't have it constructed to accept a full byte and a single bit, rather than each individually. However, there are ways of getting around this, one of which is thanks to the fact that the code may only be processed in RAM, this limitation forces you into the blessing of modified code:

    Code:
    DAC1_Switch:	ld	(hl),b			; 2 - 07		; 0000 0000 1
    		ld	(hl),b			; 2 - 07		; 0000 0001 0
    		ld	(hl),b			; 2 - 07		; 0000 0010 0
    		ld	(hl),b			; 2 - 07		; 0000 0100 0
    		ld	(hl),b			; 2 - 07		; 0000 1000 0
    		ld	(hl),b			; 2 - 07		; 0001 0000 0
    		ld	(hl),b			; 2 - 07		; 0010 0000 0
    		ld	(hl),b			; 2 - 07		; 0100 0000 0
    		ld	(hl),b			; 2 - 07		; 1000 0000 0
    Here, hl = 6000, but registers b and c = 0 and 1 respectively. Now, each samples window address does NOT need changing very often, just every 8000 bytes of the sample, which is in VERY short instances, so, we can modify the instruction to load b or c depending on the address we want, and then leave it like that for the next 8000 bytes while it's switching back and forth, I also believe this method has also been used in quite a few Mega Drive titles, at the near end of its life. Another factor I look into abusing, is once switched to a sample, it'll load not just one byte, but a series of bytes from that one side to a buffer, and then switch to the other. This means that the window switch needs to occur less often.

    The process will also require a lot of staggering, a few sample bytes will need to be flushed off here and there at odd intervals, this'll mean that the playback will need to be one series behind (to allow the second sample to be fused with the first in the buffer), so, we'll assume that the driver is loading the 2nd series of samples, while the driver is playing back the 1st series of samples. The window is switched to sample 1, a byte is flushed from the 1st series buffer, then the 2nd series of bytes are loaded from sample 1, then another byte is flushed from the 1st series buffer, then the window is switched to sample 2, a byte is flushed from the 1st series buffer, then the 2nd series of bytes are loaded from sample 2 and fused to sample 1, then another byte is flushed from the 1st series buffer. If the byte is flushed out at regular intervals inbetween the loading/fusing process, it should keep the playback smooth and consistent. We should also be able to load more than we play, which'll allow the driver to stop loading samples during 68k halts, but still allow ti to playback what it already has, meaning, not quality loss caused by chopping of the sample.

    Some optimisation techniques need to be included too of course, such that I have planned from a prototype I did about three years ago. To load data out of a specific location/table/RAM space, I was able to use the stack, and simply use the "pop" instruction to load word data to registers more quickly. Little things like this will need to be heavily abused and influenced.

    As I've said though, this is nothing but theory right now, the truth is, while I know these methods will work, I honestly cannot tell you what sample rate we're looking to get, we could end up getting as little as 12kHz, which would be a real bullet to the face, but, I am hoping for a MINIMUM of 16kHz, that's my borderline, my minimum expectant goal. I've chosen this rate as in my opinion, this is the lowest rate before things get notice-ably irritating. A character's speech sounds awful with "S" based sounds, sharp sizzling effects, hi-hats, etc. 16000 seems to just about bear it.

    I have written a program that will convert .wav files from any frequency, stereo/mono, 8-bit/16-bit to the appropriate format for the driver, so, none of you will need to worry about converting the sample itself, it'll make a copy, and modify that copy for inclusion into the ROM, leaving a copy of the original sample untempered with. It comes complete with an interpolation setting which should help on softening sharp sounds when they're down sample rated. It also performs an interpolation for up scaling the rate too, though it is a more "linear" type of interpolation, I may look into curving it out, but that's not really important right now.
     
    amphobius and AURORA☆FIELDS like this.
  5. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    EXCELLENT NEWS!!

    OK, so, I've created a prototype system, and tested, and the results are.... well needless to say, they're quite unexpected.

    A test ROM with two samples, both roughly $50000 bytes each, meaning they're larger samples than normal, and, they're both way apart from each other in the ROM, the driver is able to buffer them both together, read them ahead of time, and the playback speed is approximately around 20,000kHz! The buffering in particular should be of interest, because it means we can avoid DMA halts and keep it at the highest quality.

    Obviously the flushing mechanism isn't written yet, and there's some clean-up to do, but you get the idea, ladies and gentlemen... ...this is going to work.

    Stay tuned folks! In the coming weeks, I may have a release.
     
  6. EMK-20218

    EMK-20218 The Fuss Maker Exiled

    Joined:
    Aug 8, 2008
    Messages:
    1,067
    Location:
    Jardim Capelinha, São Paulo
    Wonderful! It's the same quality rate my hack's custom DAC driver can reach without more than a sample playing in once! I can't wait!
     
  7. LuigiXHero

    LuigiXHero Well-Known Member Member

    Joined:
    Mar 22, 2014
    Messages:
    280
    I didn't even think this was possible. Excellent work Markey, I can't wait to try this out.
     
  8. Crash

    Crash Well-Known Member Member

    Joined:
    Jul 15, 2010
    Messages:
    302
    Location:
    Australia
    haha, i tried to write a 2 channel dac driver for the sonic 3 driver a couple of years ago, but due to the fact that i was trying to learn z80 asm while doing it, and that i never really understood the maths behind mixing audio channels, and i also just bank switched after every sample meant i only got it running at something like 3000Hz. good to see somebody that's actually competent doing this :p
     
  9. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    After careful clean up and readjustments, the final rate is about 19,250hz.

    However, if sample rate is an issue, we can always modify the driver to read SEGA's standard DPCM data at a later point, since you get two samples for each byte, you load twice as much into the buffer, this should allow the Z80 more time/opportunity to flush the sample, thus, a higher sample rate. It comes at the expense of a lossy compressed bit rate, but it's the final result that matters, if it sounds better this way, then why not.
     
  10. breakthetargets

    breakthetargets Well-Known Member Member

    Joined:
    Aug 6, 2009
    Messages:
    180
    After hearing that ROM you gave out on the discord, people should definitely not have 19.25kHz as a problem imo. It really sounds great and the noise you'd hear from the sample being 7-bit (IIRC) would not really be a problem with a low-pass filter on real hardware and especially when the sample is playing over FM. I appreciate your work Markey.
     
  11. EMK-20218

    EMK-20218 The Fuss Maker Exiled

    Joined:
    Aug 8, 2008
    Messages:
    1,067
    Location:
    Jardim Capelinha, São Paulo
    Man... This is such a good quality, especially in comparison to my custom DAC driver. My modified driver can handle up to 19,000hz maximum quality. And it happens even after the removal of some "known" stops which fucks up a lot of the sound quality. You made me very surprised with this. 19,250hz is very good, especially if we take in account that we're talking about two PCM samples being played in once!

    I didn't take this as a problem. At exactly the opposite, this is very good and it's surprising me because this is higher than the quality my driver can handle without the multiple PCM playback. And I think my driver's playback quality was already good (at least for the purposes I focus in my game).

    In general, I'm really loving the destiny this thing is taking.
     
  12. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    Dual DAC Test Recording

    This is a recording from my model 1 Mega Drive 50hz. This is Sonic 1, along with its normal 68k sound driver running in the background, as well as the multiple DMA transfers going on. There are no DAC drums, instead for this test, there are two large samples being played.

    The first sample is a harmonic electronic kind of sound, playing on the first channel. Later on, I play the second sample, which is a series of kicks, hi-hats and some sort of electronic sound, this runs alongside that harmonic sound. Further on from that, the harmonic sound stops leaving the kicks playing on their own, following this, I spam the two channels randomly mashing the buttons.

    This is to demonstrate; the quality of the samples, the samples playing individually as well as together, and that the driver is solid enough to be pestered new sample requests (without breaking of course...).

    The quality does seem to drop a bit when two samples are playing (not sure why, I'm starting to wonder if the manual lied about "ld (hl),b" and "ld (hl),c" being the same speed (there have been a few mistakes in the manual I'm using...)), but, even with that quality loss you may or may not be able to hear, it still sounds better than most drivers.

    The quality is satisfying enough for me, I'm interested in your thoughts.
     
  13. Devon

    Devon Down you're going... down you're going... Member

    Joined:
    Aug 26, 2013
    Messages:
    1,372
    Location:
    your mom
    The quality seems fine to me, even with both samples playing simultaneously. Very nice work!
     
  14. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    While performing some bug-fixes and some clean up, I had a go at advancing Sonic 1's original soundtrack using the now extra DAC channel, just for curiosity:

    Rom Download

    I took a recording of some piano chords and guitar sounds from my Yamaha keyboard:
    • Gave Green Hill Zone a set of DAC piano chords during the chorus.
    • Changed Spring Yard Zone's base to be on DAC using guitar samples (used the now free FM channel as an echo).
    • Gave Labyrinth Zone a set of DAC "soft" piano chords during the chorus.
    • Seperated the timpani drums in Scrap Brain Zone into the second channel (now the timpanis don't interrupt the kicks and snares).
    • And I gave the invincible theme a set of DAC base guitar (used the now free FM channel to enhance the main melody a bit).
    Like I said before, I'm not real musician, and this may be nothing by comparison to what some of the more passionate musicians would have done I would imagine, but it's there to demonstrate some of the main possibilities available when given an extra DAC channel.

    I haven't tested this ROM on hardware, but it should be OK.

    (Please ignore some of the irritating clicking sounds, that's the PSG messing up, Sonic 1's sound driver is full of bugs, the PSG isn't muted correctly upon playing a new track, after putting in a delay for the FM/PSG channels, it became notice-able).
     
  15. TheStoneBanana

    TheStoneBanana banana Member

    Joined:
    Nov 27, 2013
    Messages:
    602
    Location:
    The Milky Way Galaxy
    That is so cool! (Out of all of the things in that ROM, Spring Yard Zone is my favorite.)

    I can't wait to see how others use this and what is potentially going to come out of it.
     
  16. amphobius

    amphobius spreader of the pink text Member

    Joined:
    Feb 24, 2008
    Messages:
    970
    Location:
    United Kingdom
    I'm very interested in how Spring Yard's bass is being played back. Is that just one long sample, or every note sampled, or is it one sample pitched chromatically? If it's pitched chromatically I'm really interested now.
     
  17. EMK-20218

    EMK-20218 The Fuss Maker Exiled

    Joined:
    Aug 8, 2008
    Messages:
    1,067
    Location:
    Jardim Capelinha, São Paulo
    Yeah, this is making me really anxious. I feel that my dreams of making electronic music on Sega Genesis with more than just the electronic kick and the electronic snare are starting to become reality!

    I noticed it. Most of this is noticeable during the music transitions between levels and/or events. A constant PSG sound could be heard in the beginning of GHZ2 and I had to pause the game to make the sound to stop, but this happened only one time during my tests. Though this doesn't seems to be a big problem after all.

    Tell me more about this. Because I'm not understanding too much how you freed up a FM channel after adding a extra DAC playback channel to to the song. I'm curious about how this was made, or maybe I didn't read something in this thread.


    In general, a very good work is being made by you until now. The sound quality is really better than I expected when you first suggested you'd work on this thing. I'm really surprised with how the samples sounds good with this. But I have a little question. If a VGM is recorded (using the known methods), they can be normally reproduced in a VGM file as Ristar and some other Genesis games does with this feature or the VGM files may be buggy in consequence of this feature?

    As a suggestion: If this driver gets released, it could be good if you work with valleybell to create a modified (a new) version of MID2SMPS which could output SMPS files directed to this kind of DAC samples output.

    I'm liking this work so far!
     
  18. ProjectFM

    ProjectFM Optimistic and self-dependent Member

    Joined:
    Oct 4, 2014
    Messages:
    912
    Location:
    Orono, Maine
    The FM channel was freed up because the the FM bass was removed and the second DAC channel was used for it instead.
     
    EMK-20218 likes this.
  19. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    It is a series of samples, one for each note. Like I said before; pitch/volume control is not on the agenda yet, getting it to work first is the main goal and is what's important right now. I do have a prototype I made 3 years ago for Flygon, but he insisted on the samples being preloaded into Z80 RAM when a song is loaded, we need one that takes buffering into account, which I suspect will cost some sample rate time. Whether this'll be too impractical or not is better left for later.
    Sorry, I wasn't clear on this.

    FM2 for Spring Yard Zone was used for a bass. I recorded different guitar notes and played the bass on DAC2 via samples, so now, FM2 doesn't need to play the bass, now it is free to use for something else.
    If there is a bug in relation to that, then it's a bug with the VGM player/recorder.

    I will not sacrifice good quality playback for a recording asset that's nothing to do with the Megs Drive itself, if there is a fault, it's external, and they need to fix it. It would be like expecting TV manufacturers to change the way their TV reads data through a HDMI cable, so that it works on broken cables. The issue should be directed to the cable manufacturer, so they can improve the quality of the wire so that it works at the pre-established specification standards.
    That's up to him, but the format is rarely different from normal SMPS, it just has a second DAC pointer, and the FM/DAC counter is increased by 1. I have written a tool that'll make your current tracks compatible, it just points DAC2 to an F2 stop flag for now.
     
    amphobius likes this.
  20. nineko

    nineko I am the Holy Cat Member

    Joined:
    Mar 24, 2008
    Messages:
    1,902
    Location:
    italy
    There is a point I can address since I have a certain expertise about VGM files: there is technically no reason for 1.10 and 1.50 VGM files (hell, even GYM files if you are that oldschool) not to support the dual DAC, as only the final downmixed result is stored in the VGM file -- from its perspective, the VGM file doesn't care how you obtain the specific volume levels replayed on the DAC channel, which is still single from a hardware point of view. 1.60 VGM files would have a slightly harder time because of their approach to samples which would require a preemptive preparation of a "library" with all the used combinations of the various samples, but it's definitely feasible there as well. I can't think of any reason for this to break the VGM format, so you shouldn't worry about that.

    Also, even though it's highly obsoleted by now, I would be willing to implement support for this in my xm3smps converter if there's enough demand for it, as it doesn't seem it would be hard from what you're saying. However, I can't speak about mid2smps, obviously.
     
    MarkeyJester and amphobius like this.