RJDMC 1.53
Moderator: Moderators
RJDMC v0.6
-Added a pop-up box when processing is being done
-Added a reverse function
-Data is read in almost 2x as fast
-Quality of "rate" changes is much higher
-Added extra error handling for non-pcm and non-wav files
-Fixed several bugs
-Added "play selection" feature
-DPCM output is always (mod16 + 1) bytes, so looping is more accurate
-Fixed a few of the keypresses not being read properly
-Various improvements to code efficiency
-Fixed all bugs with the trackbars (all scroll 1-per-tick)
-Added a pop-up box when processing is being done
-Added a reverse function
-Data is read in almost 2x as fast
-Quality of "rate" changes is much higher
-Added extra error handling for non-pcm and non-wav files
-Fixed several bugs
-Added "play selection" feature
-DPCM output is always (mod16 + 1) bytes, so looping is more accurate
-Fixed a few of the keypresses not being read properly
-Various improvements to code efficiency
-Fixed all bugs with the trackbars (all scroll 1-per-tick)
RJDMC v0.9
-Zoom into any area is done
-Operations on zoomed selections are possible
-Modify volume for selection
-Fade volume to x%
-Fixed several bugs, made tons of optimizations (mostly to new functions)
-Zooming on large files is faster
-Fixed some bugs with opening files with additional info in their headers and files that were sampled at odd rates.
-Zoom into any area is done
-Operations on zoomed selections are possible
-Modify volume for selection
-Fade volume to x%
-Fixed several bugs, made tons of optimizations (mostly to new functions)
-Zooming on large files is faster
-Fixed some bugs with opening files with additional info in their headers and files that were sampled at odd rates.
Great tool! I'm thikning how to add the dmc seamlessly into the rom.
Let's see if I've got it right.
Starting in $C000, you can address samples at 64 bytes increments via $4012.
Samples size is set via $4013 and the number written is multiplied by 32 then added 1 to get the sample size.
So, if you have to align samples to 64bytes, there is a trailing waste of 31 bytes after each sample.
The first byte could be used to store the $4012 value of the sample,
(ADDR - $C000)/64, I think the assembler could do that but not sure.
Then the remaining 30 bytes, and this is where RJDMC comes into play, could be data from the sample, pitch, freq, etc (if there's more) in nes format, so you can directly store the value or OR it, padded to 30 bytes (with anything you want, program signature, name, version, etc).
RJDMC could write this file along with the dmc file, so in the code you only have to include the dmc, autocalculate the $4012 address, include the trailer and you have always your samples aligned and it's easy to call them
Any toughts about this? :p
Let's see if I've got it right.
Starting in $C000, you can address samples at 64 bytes increments via $4012.
Samples size is set via $4013 and the number written is multiplied by 32 then added 1 to get the sample size.
So, if you have to align samples to 64bytes, there is a trailing waste of 31 bytes after each sample.
The first byte could be used to store the $4012 value of the sample,
(ADDR - $C000)/64, I think the assembler could do that but not sure.
Then the remaining 30 bytes, and this is where RJDMC comes into play, could be data from the sample, pitch, freq, etc (if there's more) in nes format, so you can directly store the value or OR it, padded to 30 bytes (with anything you want, program signature, name, version, etc).
RJDMC could write this file along with the dmc file, so in the code you only have to include the dmc, autocalculate the $4012 address, include the trailer and you have always your samples aligned and it's easy to call them
Any toughts about this? :p
What OS are you using? Is the .net framework fully updated on your machine? That'd be my first guess, as I'm pretty sure the open/save dialogs use 3.5 code while the main form uses more backward compatible stuff.Dwedit wrote:Why doesn't saving work on my PC? This is very frustrating. I can't even save a file without the program throwing an exception.
Try http://4x86.com/RJDMCv0.9a.zip as it has a couple fixes and uses a subset of the .NET framework instead of the whole thing now (apparently this can help with framework-related errors).
Actually multiplied by 16, but you get the idea.Wave wrote:Great tool! I'm thikning how to add the dmc seamlessly into the rom.
Let's see if I've got it right.
Starting in $C000, you can address samples at 64 bytes increments via $4012.
Samples size is set via $4013 and the number written is multiplied by 32 then added 1 to get the sample size.
If you're storing the $4012 value after the end of a compressed wave, then given a wave's ID number, how would you find the end of this wave to be able to find its $4012 value? Most games that I've seen use a table to translate wave ID numbers into $4010/$4012 values. You could call this the "inode table" if you wish. In fact, it can be done with 2 bytes per wave because it's possible to approximate the $4013 value from this wave's $4012 value and that of the next, with the other byte holding the default $4010 value.The first byte could be used to store the $4012 value of the sample,
(ADDR - $C000)/64, I think the assembler could do that but not sure.
Oh, right.tepples wrote: Actually multiplied by 16, but you get the idea.
Sooo, there's a space of 63-15bytes "free" aren't they?
Assuming the trailer can be automaticaly created...
$4012 is the starting address, calculated by the assembler
$4010 is frecuency, given by the program in a trailer in this case
$4013 is size, given by the program in a trailer in this case
Am I wrong?
EDIT: I understand what you were trying to say now.
Given that scenario you could create a table pointer to the trailers easily.
Last edited by Wave on Wed Dec 15, 2010 9:29 am, edited 1 time in total.
The idea is to have everything calculated and not to modify by hand any value. If you changed a dmc, it would work without code changes (if it fits on rom)tepples wrote:Which would take the same space as a table of $4010 and $4012 values. Do you want me to explain how $4013 values could be calculated from $4012 values for any sample that doesn't loop?Wave wrote:Given that scenario you could create a table pointer to the trailers easily.
Also, how do you align dmcs to 64 bytes?
I'll get that to you within 1-2 days, whenever I turn in my code for the project here at school.Dwedit wrote:I get a lot of "Could not find file, or no file specified" after opening, saving, or even playing a temporary generated file. Source code please? Then I can find out what's making those errors.
The solution I have calculates the $4012 value from the starting address of the wave in ROM, and then it calculates the $4013 value by subtracting this sample's $4012 value from that of the next and then doing some shifts.Wave wrote:The idea is to have everything calculated and not to modify by hand any value. If you changed a dmc, it would work without code changes (if it fits on rom)
.align statements in ca65 do this.Also, how do you align dmcs to 64 bytes?
For an illustration, have a look at how I handle samples in the source code to LJ65.
Unless you have more than about a dozen of samples, you'd actually waste bytes with this instead of saving them.The solution I have calculates the $4012 value from the starting address of the wave in ROM, and then it calculates the $4013 value by subtracting this sample's $4012 value from that of the next and then doing some shifts.
Useless, lumbering half-wits don't scare us.
So you have to do it manually for each sample?tepples wrote:The solution I have calculates the $4012 value from the starting address of the wave in ROM, and then it calculates the $4013 value by subtracting this sample's $4012 value from that of the next and then doing some shifts.Wave wrote:The idea is to have everything calculated and not to modify by hand any value. If you changed a dmc, it would work without code changes (if it fits on rom)
.align statements in ca65 do this.Also, how do you align dmcs to 64 bytes?
For an illustration, have a look at how I handle samples in the source code to LJ65.
Wouldn't it be better to have samples padded to 64 bytes and use the trail as I suggested?