ElBrunzy wrote:I'm in the search of interesting idea for the video, please give me tough I would be most happy to realise them. I will re-read the whole thread, but I have no idea about that crash, i'll see what I can see.
Now that I have fm1312 and saa1099 on that sb1.5, let's talk about the real stuff:
first thing first : if I do "sbvgm -h music.vgm" it display help, but if I do "sbvgm music.vgm -h" it does not. BUT ! if I do "sbvgm -c music.vgm" it complains -c is not a file, but if I do "sbvgm music.vgm -c" it does play with the saa1099, can you see the problem I'm getting at ? that's simple command prompt parsing, my guess is you can fix that in a jeffey, but it's quite confusing for the end user.
also : I'm quite amazed how good your player work with hardware sega rip dump. Can I ask you about how you did you timing ? I'm using a p1-233 and it's all perfect
Ideas for a video? What did you have in mind?
Thank you also for the suggestions. I will look into implementing them soon; that does make a lot more sense. Currently the program expects the filename to be the first parameter, but I'll look into making it a bit more flexible.
About the timing...VGM data is set for playback at 44,100Hz. Since this rate is too high with the PC interrupt 8 timer, it is set to 180Hz playback. 44100Hz divided by 180Hz yields 245, so on each tick (from the 180Hz clock) the VGM playback routine is called 245 times. The approach works for most
cases (even on a slow 4.77MHz PC) as many VGMs were recorded from games with 60Hz update rates, but there are some cases where this approach does not work well such as some of the OPL3 VGMs at the OPL Archive
. Some of the Adlib Tracker songs playback at a rate of 300Hz (sometimes higher) and naturally the approach the program uses above will inadvertently drop frames from the VGM playback.
It is possible to set the interrupt timer to playback at about 1,000Hz, but there are other issues that show up in terms of how often the interrupt gets called and of course playback on actual hardware. One of the nice things about the SAA1099 chips are that there are no waits between register writes, but the OPL2 and OPL3 require waiting a certain amount of time (in microseconds) between address and data writes. I think
the timings in the VGM data takes this into account, but I am not 100% sure. At a 44,100Hz capture those waits would only show up as a wait time of zero or at worst one VGM frame.
A while back I tried an experiment where the VGM was updated as fast at the CPU could go, but would wait with the VGM command specified a delay running the interrupt timer at 1,000Hz with a counter to act as a reference for when the VGM commands should be processed. It kind of worked, but the timing was a bit off at 4.77MHz. Again the time waiting between the OPL2 address and data writes seemed to throw things a bit off. I don't have an actual 4.77MHz PC to test on (I used DOSBox 0.74 for development), so sometimes the results are different from actual hardware (at least on my Pentium 3/450MHz machine) and that's when I have to go back and make it work for actual hardware.
Overall though, that's how the program handles the timing. One caveat about VGM format is that a program that plays back such files seems to have to handle all
the commands since certain commands advance the data at different sizes; there's no way to know in advance how many bytes to skip. The whole program is written in C (I don't have enough free time to write and debug in assembler), so I am sure there are places that could be optimized.
The original goal of the program was simply to test out some things with the SAA1099 chips. The NES VGMs really show off some of the SAA1099 abilities ... though (at present) the program does not handle the NES APU's DPCM channel nor simulate duty cycles for the two square wave channels.