OPLx wrote on 2024-03-18, 20:21:

Here's an update to TNDYCHK. When you have a chance, could you send the output of it?

Here you go.

Thank you. I'll probably DM you for additional tests. The Tandy 3100 seems to be quite a unique platform. 😀

OPLx wrote on 2024-03-19, 11:22:

Thank you. I'll probably DM you for additional tests. The Tandy 3100 seems to be quite a unique platform. 😀

This is awkward. I can't respond to you DM's. It says: We are sorry, but you are not authorized to use this feature. You may have just registered here and may need to participate more in discussions to be able to use this feature.
(Not sure if you're comfortable DM'ing me your email address or something...) In the meantime, here is a screenshot of my BOOT screen and "BIOS"

Mr.Tibb wrote on 2024-03-20, 04:56:

OPLx wrote on 2024-03-19, 11:22:

Thank you. I'll probably DM you for additional tests. The Tandy 3100 seems to be quite a unique platform. 😀

This is awkward. I can't respond to you DM's. It says: We are sorry, but you are not authorized to use this feature. You may have just registered here and may need to participate more in discussions to be able to use this feature.
(Not sure if you're comfortable DM'ing me your email address or something...) In the meantime, here is a screenshot of my BOOT screen and "BIOS"

I guess DMs only work if one has posted enough on here. I've attached another version of the check program. Hopefully this will reveal more information. Do you mind running it twice; run it once, then wait about 2 minutes then run it again. I think it should produce the exact same output, but just want to be sure.

OPLx wrote on 2024-03-20, 13:58:

Do you mind running it twice; run it once, then wait about 2 minutes then run it again. I think it should produce the exact same output, but just want to be sure.

Here it is, twice, with a few minutes in between.

Thank you again for the screenshot! I think I have an idea of how to fix it. I’ll make one more version of TNDYCHK to make sure it reports the right information.

Here's hopefully the last test to try out. Thank you for all the help!

OPLx wrote on 2024-03-22, 19:18:

Here's hopefully the last test to try out. Thank you for all the help!

Here you go. No problem - my pleasure helping out!

Mr.Tibb wrote on 2024-03-23, 18:15:

OPLx wrote on 2024-03-22, 19:18:

Here's hopefully the last test to try out. Thank you for all the help!

Here you go. No problem - my pleasure helping out!

Wonderful! It looks like it works now! I'll have an update out hopefully before this week is over.

SBVGM v1.45 is available from http://www.oplx.com/code/

This update includes:

• Fixed bug that caused a Tandy 3100 to be detected as a PC-98.

Thanks to @Mr.Tibb for pointing this out!

OPLx wrote on 2024-03-25, 23:30:

Thanks to @Mr.Tibb for pointing this out!

Thank you! It works great, now.

OPLx wrote on 2016-03-01, 14:37:

...[*]YMF262 (OPL3)

OPL3 and OPL4 also can play RP2A03 VGMs.

It does so incredibly well, better than most emulated sounds i've heard.
Allow me to describe my setup and my plea!
Windows 11 system, running DosBox-X, with a Sudomaker Retrowave Express
(an OPL3 chip addressed thru the USB as a serial device. It was 55$ USD and took only minutes to set up in DosBox X, scummvm support for it seems dropped. For all the dos games i've tried, and impressively having SBVGM convert nes music to OPL3 , it is flawless.)
And by the sound of it, SBVGM has really nailed the RP2A03>YMF262 conversion. Enough to feel like i'm playing on original nes if i'm not comparing them side by side thru a CRT TV.

HERE'S the bit i can't resolve, without learning way more than I'd like... here's my retro-gamer cry for help -
Can this technique be incorporated into a DOS based emulator such as Nesticle (sadly not open source) or FWNES? Otherwise hoping there;s help in the PCem community but it seems so close, right here, between a nes emulator and this magic program you've made!
Thanks for everything so far!

mattinitus wrote on 2024-05-23, 07:03:

It does so incredibly well, better than most emulated sounds i've heard. Allow me to describe my setup and my plea! Windows 11 […]
Show full quote

OPLx wrote on 2016-03-01, 14:37:

...[*]YMF262 (OPL3)

OPL3 and OPL4 also can play RP2A03 VGMs.

It does so incredibly well, better than most emulated sounds i've heard.
Allow me to describe my setup and my plea!
Windows 11 system, running DosBox-X, with a Sudomaker Retrowave Express
(an OPL3 chip addressed thru the USB as a serial device. It was 55$ USD and took only minutes to set up in DosBox X, scummvm support for it seems dropped. For all the dos games i've tried, and impressively having SBVGM convert nes music to OPL3 , it is flawless.)
And by the sound of it, SBVGM has really nailed the RP2A03>YMF262 conversion. Enough to feel like i'm playing on original nes if i'm not comparing them side by side thru a CRT TV.

Thank you for your kind complements! There are still some features missing such as "Noise Buzzing" and DPCM support. The OPL3 also can't quite accurately reproduce the noise channel, but it's pretty close.

mattinitus wrote on 2024-05-23, 07:03:

HERE'S the bit i can't resolve, without learning way more than I'd like... here's my retro-gamer cry for help -
Can this technique be incorporated into a DOS based emulator such as Nesticle (sadly not open source) or FWNES? Otherwise hoping there;s help in the PCem community but it seems so close, right here, between a nes emulator and this magic program you've made!
Thanks for everything so far!

If there's already a DOS based emulator, I think the techniques could be easily incorporated. My guess is that it would only reduce the CPU requirement since there's no longer the need to generate and mix the APU audio.

Since the emulator already handles all the important APU timings basically all that is required is:

• A 2-Operator FM instruments for the square channel duty types
• One 2-Operator FM instrument for the triangle channel
• One 4-operator FM instrument for the noise channel (and the appropriate approximate F-NUM frequencies)
• DPCM - this could be directly routed out to the DAC of the sound card.

A Windows-based emulator could also be updated to do this and route the output to the Retrowave Express. For actual MS-DOS hardware the OPL3 could be used of course and PicoGUS (should it one day have an RPA203 core added).

Without wanting to give too much away, would SBVGM require significant rework to write PSG bytes to a fixed memory address, rather than an IO port? 👀

SquallStrife wrote on 2024-06-04, 12:38:

Without wanting to give too much away, would SBVGM require significant rework to write PSG bytes to a fixed memory address, rather than an IO port? 👀

If it's for hardware that's already supported, it's relatively straightforward.

Apologies in advance for the dumb question, but I still don't fully understand how SBVGM works with the different FM chips ...

... is playback only possible on the right hardware or is SBVGM doing some conversions, so that a VGM rip for a SN76489 can be played back on a YM3812 ? Or how is the playback of YM2413 realized? In that case - would it be possible to capture a OPL2 DRO Raw file even for non OPL2 chips?

Thanks!

TheMechanist wrote on 2024-06-20, 06:59:

Apologies in advance for the dumb question, but I still don't fully understand how SBVGM works with the different FM chips ...

... is playback only possible on the right hardware or is SBVGM doing some conversions, so that a VGM rip for a SN76489 can be played back on a YM3812 ? Or how is the playback of YM2413 realized? In that case - would it be possible to capture a OPL2 DRO Raw file even for non OPL2 chips?

Thanks!

It's not a dumb question at all. For the most part, SBVGM plays VGMs for the natively supported hardware. In the case of say playing back SN76489 VGMs on YM3812, I would have to write a translation layer to do that. The YM3812 can't generate noise in the same way the SN76489 does so it wouldn't sound the same.

Some chips are easy to do, others require a bit more effort. The features of the YM3812 are similar enough to that of the YM2413 that it's relatively straightforward. Having said that, there are subtle differences between the two chips that might not translate well to the YM3812.

If SBVGM is able to play the non-native VGM, then capturing the DRO shouldn't be a problem. That capture may need to be optimized as there could be duplicate data in the capture.

Thanks! Maybe you could answer another question 😀

I have an interrupt driven VGM player routine for YM3812, that's polled every 1 ms (1000 Hz) (like DRO, seems a reliable polling speed, that doesn't overstrain an 286).

Since there are no PCM data it's just necessary to adjust the different VGM delays (0x61, 0x62, 0x63; 0x7n are discarded, since they are below 1 ms). The standard delay is about 0.022 ms up to 1.489 sec. (1 .. 65535 ticks - called "samples" - over 44100 Hz VGM sampling speed), I adjusted it by dividing the delay time by 44 to get delays in ms, which works as expected. But the short, special delays are way too long: I had to shorten - 0x62 - which is 1/60s, 17 ms - and 0x63 - which is 1/50s, 20 ms - about 3 - 4 ms, and I'm still not convinced ...

Do you have any idea, maybe my approach is wrong?

TheMechanist wrote on 2024-06-22, 10:36:

Thanks! Maybe you could answer another question :) […]
Show full quote

Thanks! Maybe you could answer another question 😀

I have an interrupt driven VGM player routine for YM3812, that's polled every 1 ms (1000 Hz) (like DRO, seems a reliable polling speed, that doesn't overstrain an 286).

Since there are no PCM data it's just necessary to adjust the different VGM delays (0x61, 0x62, 0x63; 0x7n are discarded, since they are below 1 ms). The standard delay is about 0.022 ms up to 1.489 sec. (1 .. 65535 ticks - called "samples" - over 44100 Hz VGM sampling speed), I adjusted it by dividing the delay time by 44 to get delays in ms, which works as expected. But the short, special delays are way too long: I had to shorten - 0x62 - which is 1/60s, 17 ms - and 0x63 - which is 1/50s, 20 ms - about 3 - 4 ms, and I'm still not convinced ...

Do you have any idea, maybe my approach is wrong?

The approach I'm using (it may not be the best) is to process the delays according to the VGM "samples". So if the interrupt is driven at 1ms, then 44,100/1,000 = 44 which means that it will be necessary to process up to 44 "samples" for each interrupt received. I do this in a loop keeping track of how many "samples" (delays) that have been counted. So for 0x62 it would end up taking about 16 (735/44) 1ms interrupt calls. This should capture the 0x7n delays too since certain VGMs can have a series of these that add up to something meaningful for playback. As a result, I don't alter any of the delay values received. There is obviously some error introduced handling things this way (maybe a fixed-point approach would be better?) Maybe an approach like this would work better for your use-case?

Something I also realized about the VGM format is that it's not necessarily a format for actual hardware, but rather for playback via emulation. If the platform the playback happens on does have sufficient CPU/processing resources, then it will work, but for platforms that don't have this, it can be tricky since there is overhead from just processing the VGM data which aren't actually accounted for. The commands that write to the hardware assume a certain amount of (short) time. So if say writing data to the hardware takes longer then that will affect the overall playback speed. For example, the typical address and data write delays for the OPL2 (and other chips) aren't part of the VGM data and it's just assumed that it is possible to write very quickly to the hardware and then just wait for the delay duration then send another series of data writes to the audio chip.

This has caused me to wonder if using an interrupt is the only way. There's another approach to not have the VGM updates occur in an interrupt, but to just have a variable that gets updated on each interrupt and track that outside the interrupt. This should work, but if the platform isn't fast enough the playback is a bit unstable.

I hope some of this has been useful for you. If you're still having trouble, please let me know.

My player doesn't use interrupts at all. It does count the 44KHz samples for each VGM wait. After a certain number of samples have passed (IIRC I had it set to 1/180 of a second) then it watches the PIT counter until the required time has passed. When the CPU is too slow, the PIT counter will have already passed the target so there is no waiting, and ultimately the music just plays more slowly. (There is also a remote possibility that we are SO slow that the PIT counter has overflowed more than once since the last time it was polled, making it uncertain whether we are 'early' or 'late', but this would only lead to an unnecessary additional delay, and shouldn't happen in practice.)