OPLx wrote:

Glad it's mostly working! 😀 Do you mind telling me which VGM from Miracle Warriors didn't work? It looks like I need to fix some issues with how the memory manager/pager works. 😢 Does the reveal sc400 use or emulate the SAA1099? I never heard of this card before; it looks interesting though!

Dont say it "mostly work", it sure did work and I had the music I heard yesterday in my mind all day long and it kept me on good mood, it was such a terrific experiment to listen to that, the sound was so real, it is a stunning success!

All of the music from miracle warrior did not worked, you can pick anyone from the url I gave you and try it.

I use a .batch file to do some "for %%f in" because your player dont handle wildcard so when there is a batch of unworking files it take about 2 seconds to detect the hardware, hope to see the force adlib switch soon.

I just wanted to make sure the fact about miracle warrior was allright, I re-tested and made some further investigation. Using the -ps1 switch the file is playing allright. But asking the opl2 at 388h call the "Insufficient memory to playback VGM!" error message. One of my favorite music from the pack is the "castle" music from the miracle warrior pack at http://www.smspower.org/uploads/Music/Miracle … iors-SMS-FM.zip, just grab this file "Miracle Warriors - Seal of the Dark Lord (FM) - 04 - Castle.vgm", I also did put it on my ftp at http://junkskool.net/ftp/castle.vgm

searching for a youbuve video of the castle music I went thru that, seem to be someone comparing the PSG with the FM version of the sega master system. Could not be more spot on matter https://www.youtube.com/watch?v=CRoBMXRpHKI&f … =youtu.be&t=210 it's a audio track where the castle theme start and you can also hear both version, can hear that music on loop more thant 5 time in a row 😉

OPLx wrote:

Yes, I did make oplx.com ... need to "modernize" it at some point though ... 😒

Do you really need thoses driversguide.com link on your web site ? If they dont give you money, get rid of them, they lower your ranking. Driverguide once found a windows 10 x64 driver for my isa gus classic, now that is something else !

also I think you asked long time ago about how was the guspnp configured, the adlib is at port 388h, here is for the rest :

ElBrunzy wrote:

Dont say it "mostly work", it sure did work and I had the music I heard yesterday in my mind all day long and it kept me on good […]
Show full quote

OPLx wrote:

Glad it's mostly working! 😀 Do you mind telling me which VGM from Miracle Warriors didn't work? It looks like I need to fix some issues with how the memory manager/pager works. 😢 Does the reveal sc400 use or emulate the SAA1099? I never heard of this card before; it looks interesting though!

Dont say it "mostly work", it sure did work and I had the music I heard yesterday in my mind all day long and it kept me on good mood, it was such a terrific experiment to listen to that, the sound was so real, it is a stunning success!

All of the music from miracle warrior did not worked, you can pick anyone from the url I gave you and try it.

I use a .batch file to do some "for %%f in" because your player dont handle wildcard so when there is a batch of unworking files it take about 2 seconds to detect the hardware, hope to see the force adlib switch soon.

It's strange that the Miracle Warrior files don't work as they are not compressed and are small enough to fit in memory without using EMS; I'll have to investigate more. I'll try to also add that "force adlib" switch soon.

ElBrunzy wrote:

I just wanted to make sure the fact about miracle warrior was allright, I re-tested and made some further investigation. Using the -ps1 switch the file is playing allright. But asking the opl2 at 388h call the "Insufficient memory to playback VGM!" error message. One of my favorite music from the pack is the "castle" music from the miracle warrior pack at http://www.smspower.org/uploads/Music/Miracle … iors-SMS-FM.zip, just grab this file "Miracle Warriors - Seal of the Dark Lord (FM) - 04 - Castle.vgm", I also did put it on my ftp at http://junkskool.net/ftp/castle.vgm

searching for a youbuve video of the castle music I went thru that, seem to be someone comparing the PSG with the FM version of the sega master system. Could not be more spot on matter https://www.youtube.com/watch?v=CRoBMXRpHKI&f … =youtu.be&t=210 it's a audio track where the castle theme start and you can also hear both version, can hear that music on loop more thant 5 time in a row 😉

Hmm ... that's unusual. What type of machine do you have and which sound cards are you using? The -ps1 switch is meant for IBM PS/1 machines so I'm a bit baffled as to what might be going on. It seems like it would be something that is easy fix. I'm not surprised at this problem given that I only had a limited set of hardware to test on.

ElBrunzy wrote:

Do you really need thoses driversguide.com link on your web site ? If they dont give you money, get rid of them, they lower your […]
Show full quote

OPLx wrote:

Yes, I did make oplx.com ... need to "modernize" it at some point though ... 😒

Do you really need thoses driversguide.com link on your web site ? If they dont give you money, get rid of them, they lower your ranking. Driverguide once found a windows 10 x64 driver for my isa gus classic, now that is something else !

also I think you asked long time ago about how was the guspnp configured, the adlib is at port 388h, here is for the rest :

I had put the driversguide.com link there a while back and I'm actually surprised anyone actually visits the OPLx.com site. It's there primarily for folks who are looking for Windows 95/98/ME drivers; I'm not even sure how much traffic the site gets per day or it's ranking.

By the way is the junkskool.net site down? I couldn't download the VGM or see the image you placed there.

my junkskool.net site went down, it's right into my house and we got some problem, it's not completely reliable. Now it should be up and running. But I just gave my home site as a backup, you should get all file from here : http://www.vgmusic.com/music/console/sega/master/ scroll down to the "miracle warrior FM and non FM soundtrack and see.

for now on I'm in the process of dualbooting that computer to windows 98 and give a take at vgmplay. Maybe I can understand more why this miracle warrior sountrack fail with your player ?

I just finished dualbooting win98 and freedos. Funny thing, win98 see and install the adlib (OPL2) driver allright. They are provided by Microsoft dated 4-23-1999. The guspnp is completely undetected. USB and Net too... I will fix all that and install winamp and that VGM plugin and configure it to prefer hardware playback, in my books it always sounds best.

Are you in any way interested about using your players on a win98 shell? I dont intend to do that, but if it mean anything to you I can make some tests.

ElBrunzy wrote:

I just finished dualbooting win98 and freedos. Funny thing, win98 see and install the adlib (OPL2) driver allright. They are provided by Microsoft dated 4-23-1999. The guspnp is completely undetected. USB and Net too... I will fix all that and install winamp and that VGM plugin and configure it to prefer hardware playback, in my books it always sounds best.

Are you in any way interested about using your players on a win98 shell? I dont intend to do that, but if it mean anything to you I can make some tests.

Thanks for trying it out with a different configuration! From what I remember, GUSPnP often had driver issues (out of the box with Win98); you'd probably have to install the drivers that Gravis provided for it to work. On my test machine I use WinME, DOS 6.22, and FreeDOS to test things out. It should work fine under a Win98 shell, but the primary target for the program is simply under a pure DOS boot.

I have uploaded v1.07 here. It has the -a option to force the usage of Adlib and should cut down on waiting a few seconds while the program searches for the ports which there might be sound hardware.

I still need to look into that out of memory error, but I have a suspicion that it's ZLib causing it. Whether or not the VGM is compressed, it will always get loaded through ZLib and Zlib might just be allocating too much memory (in anticipation of decompressing the file). I have support for just reading it a non-compressed file and I'll look into re-enabling that hopefully in the near future. The files you are loading are 4K or less and there shouldn't be any memory issues with them.

Thank you for taking the time out to try the program. 😀

ElBrunzy wrote:

I just wanted to make sure the fact about miracle warrior was allright, I re-tested and made some further investigation. Using the -ps1 switch the file is playing allright. But asking the opl2 at 388h call the "Insufficient memory to playback VGM!" error message. One of my favorite music from the pack is the "castle" music from the miracle warrior pack at http://www.smspower.org/uploads/Music/Miracle … iors-SMS-FM.zip, just grab this file "Miracle Warriors - Seal of the Dark Lord (FM) - 04 - Castle.vgm", I also did put it on my ftp at http://junkskool.net/ftp/castle.vgm

searching for a youbuve video of the castle music I went thru that, seem to be someone comparing the PSG with the FM version of the sega master system. Could not be more spot on matter https://www.youtube.com/watch?v=CRoBMXRpHKI&f … =youtu.be&t=210 it's a audio track where the castle theme start and you can also hear both version, can hear that music on loop more thant 5 time in a row 😉

I had some time to take a quick look and here's what I found out:

I'm successfully able to reproduce it under DOSBox it is easier to debug. Castle.vgm is actually a compressed (VGZ) file, which explains the issue I mentioned about ZLib. The file size is actually 18,874 bytes in size! The other interesting thing about this file is that it's VGM data is tagged to use both the YM2413 and the SN76489 (though there doesn't seem to be any commands for the SN76489). Without scanning through the whole VGM to detect commands, SBVGM takes the information given and (depending on the chips used) may actually allocate additional memory to create tables to help in converting the frequencies from the clock rate specified by the VGM to what the hardware under DOS can use. In this case, 2K is being allocated for SN76489 -> SAA1099 and 2K is being allocated for the YM2413 -> YM3812 ... the interesting thing is that the VGM specifies a clock rate of 3.579540 MHz for the YM2413 and of course a clock rate of 3.579545 MHz. That 0.000005 MHz difference is causing the allocation and the difference is small enough to probably not matter anyway! 🤣

The Insufficient memory to playback VGM! message occurs when SBVGM attempts to allocate memory for the SN76489 -> SAA1099 frequency table ... Either way, I need to rework the memory allocation algorithm since it shouldn't fail when specifying the option to use XMS memory ... there's also a volume bug in the YM2413 simulator that castle.vgm exposed ... I'll have to take a look at that as well ... 😵

OPLx wrote:

I had some time to take a quick look and here's what I found out:

I'm successfully able to reproduce it under DOSBox it is easier to debug. Castle.vgm is actually a compressed (VGZ) file, which explains the issue I mentioned about ZLib. The file size is actually 18,874 bytes in size! The other interesting thing about this file is that it's VGM data is tagged to use both the YM2413 and the SN76489 (though there doesn't seem to be any commands for the SN76489). Without scanning through the whole VGM to detect commands, SBVGM takes the information given and (depending on the chips used) may actually allocate additional memory to create tables to help in converting the frequencies from the clock rate specified by the VGM to what the hardware under DOS can use. In this case, 2K is being allocated for SN76489 -> SAA1099 and 2K is being allocated for the YM2413 -> YM3812 ... the interesting thing is that the VGM specifies a clock rate of 3.579540 MHz for the YM2413 and of course a clock rate of 3.579545 MHz. That 0.000005 MHz difference is causing the allocation and the difference is small enough to probably not matter anyway! 🤣

The Insufficient memory to playback VGM! message occurs when SBVGM attempts to allocate memory for the SN76489 -> SAA1099 frequency table ... Either way, I need to rework the memory allocation algorithm since it shouldn't fail when specifying the option to use XMS memory ... there's also a volume bug in the YM2413 simulator that castle.vgm exposed ... I'll have to take a look at that as well ... 😵

Hello, I myself have informations to update the issue. After many problems encountered (I had to change the mobo from a VIA to an iNTEL chipset one, can you imagine?), I have finally been able to dualboot this machine for freedos and win98 and tonight I'm listening to the winamp in_vgm.dll plugin. I havent took time to set it to use the adlib opl chip yet and I'm listening to some .vgm in software with the guspnp being used for PCM. All those music from the soundtrack Miracle Warriors sound awfull, with the exception of "castle.vgm", maybe it was spared as it's kind of a simple music? There seem to be having timing problems with every single notes, might be something related to what you investigate. But then again, most of my vgm files have badly timed notes now and then, might be a timing issue with in_vgm.dll. The issue is lot worse with the Miracle Warrior recording. I have read that I could tell in_vgm.dll to use the adlib opl with compatible .vgm, but I'm not sure it will be easy to do, I'll give you some info about that later when it will be done.

By the way, I wanted to showcase your software to a friend this week as I was working on that open computer and explained him how VGM and players where working. But having to call a dos batch file to load your player to load every file in a directory was too much to ask, so I gave up (I wasnt on my first beer). If you want an advice, add wildcard for your player, so you can do "vgmplay C:\music\vgm\gameX\*.vgm" maybe no fancy shuffle or playlist support, but that would be a great feature. Maybe I'll install norton commander and create a shortcut for players like sbvgm. What do you think?

also, while I'm at it, I did try your player under win98 as the test.exe and jukebox.exe from the adlib disk worked from the command.com. I can tell you that SBVGM v1.06 by OPLx work very well ... as long as the sbvgm.exe window have the main focus 🤣 This seem to be true for everything using the adlib under win98 tho

I'm sorry about the zlib issue, I wasnt aware of that. Fortunately it seem that it was not a waste of time, right ?

OPLx wrote:

Thanks for trying it out with a different configuration! From what I remember, GUSPnP often had driver issues (out of the box w […]
Show full quote

Thanks for trying it out with a different configuration! From what I remember, GUSPnP often had driver issues (out of the box with Win98); you'd probably have to install the drivers that Gravis provided for it to work. On my test machine I use WinME, DOS 6.22, and FreeDOS to test things out. It should work fine under a Win98 shell, but the primary target for the program is simply under a pure DOS boot.

I have uploaded v1.07 here. It has the -a option to force the usage of Adlib and should cut down on waiting a few seconds while the program searches for the ports which there might be sound hardware.

I still need to look into that out of memory error, but I have a suspicion that it's ZLib causing it. Whether or not the VGM is compressed, it will always get loaded through ZLib and Zlib might just be allocating too much memory (in anticipation of decompressing the file). I have support for just reading it a non-compressed file and I'll look into re-enabling that hopefully in the near future. The files you are loading are 4K or less and there shouldn't be any memory issues with them.

Thank you for taking the time out to try the program. 😀

I am sorry I missed this post. Your second one make more sence now.

I understand now that vgmplay only can use the adlib hardware if you use the player, and not it's winamp plugin, or so it seem. You also have to use it like yours, that is; specify each files. So I have did a test with vgmplay.exe with castle.vgm and it seem to playback very good (for my tastes at last, but really it sound neat). I did took a screenshot of the player if it's any help for you, maybe you did that already ?

I'm very grateful about that you did add I feel like the one who own you. I would be pleased to do any testing that might help you out if you ever feel like it. I rebooted in dos to give a test to the awesome -a feature of the 1.07 version. If I add the -a switch it play music playlist snappy, with no more embarassing 2 seconds delay in between files. The funny thing is that if I dont add the switch it kind of pretend to play stuff but there is nothing to be heard.

Never mind that last sentence about no sound without the -a option, it's simply not true. I cannot reproduce it, must have been something else.

ElBrunzy wrote:

Hello, I myself have informations to update the issue. After many problems encountered (I had to change the mobo from a VIA to a […]
Show full quote

OPLx wrote:

I had some time to take a quick look and here's what I found out:

I'm successfully able to reproduce it under DOSBox it is easier to debug. Castle.vgm is actually a compressed (VGZ) file, which explains the issue I mentioned about ZLib. The file size is actually 18,874 bytes in size! The other interesting thing about this file is that it's VGM data is tagged to use both the YM2413 and the SN76489 (though there doesn't seem to be any commands for the SN76489). Without scanning through the whole VGM to detect commands, SBVGM takes the information given and (depending on the chips used) may actually allocate additional memory to create tables to help in converting the frequencies from the clock rate specified by the VGM to what the hardware under DOS can use. In this case, 2K is being allocated for SN76489 -> SAA1099 and 2K is being allocated for the YM2413 -> YM3812 ... the interesting thing is that the VGM specifies a clock rate of 3.579540 MHz for the YM2413 and of course a clock rate of 3.579545 MHz. That 0.000005 MHz difference is causing the allocation and the difference is small enough to probably not matter anyway! 🤣

The Insufficient memory to playback VGM! message occurs when SBVGM attempts to allocate memory for the SN76489 -> SAA1099 frequency table ... Either way, I need to rework the memory allocation algorithm since it shouldn't fail when specifying the option to use XMS memory ... there's also a volume bug in the YM2413 simulator that castle.vgm exposed ... I'll have to take a look at that as well ... 😵

Hello, I myself have informations to update the issue. After many problems encountered (I had to change the mobo from a VIA to an iNTEL chipset one, can you imagine?), I have finally been able to dualboot this machine for freedos and win98 and tonight I'm listening to the winamp in_vgm.dll plugin. I havent took time to set it to use the adlib opl chip yet and I'm listening to some .vgm in software with the guspnp being used for PCM. All those music from the soundtrack Miracle Warriors sound awfull, with the exception of "castle.vgm", maybe it was spared as it's kind of a simple music? There seem to be having timing problems with every single notes, might be something related to what you investigate. But then again, most of my vgm files have badly timed notes now and then, might be a timing issue with in_vgm.dll. The issue is lot worse with the Miracle Warrior recording. I have read that I could tell in_vgm.dll to use the adlib opl with compatible .vgm, but I'm not sure it will be easy to do, I'll give you some info about that later when it will be done.

By the way, I wanted to showcase your software to a friend this week as I was working on that open computer and explained him how VGM and players where working. But having to call a dos batch file to load your player to load every file in a directory was too much to ask, so I gave up (I wasnt on my first beer). If you want an advice, add wildcard for your player, so you can do "vgmplay C:\music\vgm\gameX\*.vgm" maybe no fancy shuffle or playlist support, but that would be a great feature. Maybe I'll install norton commander and create a shortcut for players like sbvgm. What do you think?

also, while I'm at it, I did try your player under win98 as the test.exe and jukebox.exe from the adlib disk worked from the command.com. I can tell you that SBVGM v1.06 by OPLx work very well ... as long as the sbvgm.exe window have the main focus 🤣 This seem to be true for everything using the adlib under win98 tho

I'm sorry about the zlib issue, I wasnt aware of that. Fortunately it seem that it was not a waste of time, right ?

Hello!

If you are seeing some audio issues using in_vgm.dll it's possible that the VGM capture was bad or because it's running under Win98. I can't say for sure though since I have never ran in_vgm.dll under Win98. I do understand and appreciate what you mean about having something that can play files in a certain directory. There were thoughts of adding that feature to the player, but the .EXE size is getting much larger than I had hoped. I thought about compressing the .EXE file, but that still won't resolve issues with more memory being used. I'm generally hoping to keep the player working on a 4.77MHz machine ... though there is the possibility of having a 32-bit version (since it's written in Watcom C) removing much of the 16-bit real mode issues.

For now, I've attached the batch file (decompress the ZIP file) that I use for testing. Typing: sbvgmply C:\music\vgm\gameX should get this working for you. So to play the adlib files with the -a option you would do: sbvgmply C:\music\vgm\gameX -a

The player won't likely work well in a Win98 DosBox for the simple fact that the OS has control over various system level events (timers, etc) and will steal time away from the DosBox if it doesn't have focus. One interesting thing about Win95, Win98, and WinME is that they allow direct hardware access which technically means that it is possible to have a native Windows player ... but I'm not sure if I have that much time to invest (at the moment) to do that. I do have my old Visual C 6 compiler around, so it's not necessarily out of the question ... hmm ...

ElBrunzy wrote:

I am sorry I missed this post. Your second one make more sence now. […]
Show full quote

OPLx wrote:

Thanks for trying it out with a different configuration! From what I remember, GUSPnP often had driver issues (out of the box w […]
Show full quote

Thanks for trying it out with a different configuration! From what I remember, GUSPnP often had driver issues (out of the box with Win98); you'd probably have to install the drivers that Gravis provided for it to work. On my test machine I use WinME, DOS 6.22, and FreeDOS to test things out. It should work fine under a Win98 shell, but the primary target for the program is simply under a pure DOS boot.

I have uploaded v1.07 here. It has the -a option to force the usage of Adlib and should cut down on waiting a few seconds while the program searches for the ports which there might be sound hardware.

I still need to look into that out of memory error, but I have a suspicion that it's ZLib causing it. Whether or not the VGM is compressed, it will always get loaded through ZLib and Zlib might just be allocating too much memory (in anticipation of decompressing the file). I have support for just reading it a non-compressed file and I'll look into re-enabling that hopefully in the near future. The files you are loading are 4K or less and there shouldn't be any memory issues with them.

Thank you for taking the time out to try the program. 😀

I am sorry I missed this post. Your second one make more sence now.

I understand now that vgmplay only can use the adlib hardware if you use the player, and not it's winamp plugin, or so it seem. You also have to use it like yours, that is; specify each files. So I have did a test with vgmplay.exe with castle.vgm and it seem to playback very good (for my tastes at last, but really it sound neat). I did took a screenshot of the player if it's any help for you, maybe you did that already ?

I'm very grateful about that you did add I feel like the one who own you. I would be pleased to do any testing that might help you out if you ever feel like it. I rebooted in dos to give a test to the awesome -a feature of the 1.07 version. If I add the -a switch it play music playlist snappy, with no more embarassing 2 seconds delay in between files. The funny thing is that if I dont add the switch it kind of pretend to play stuff but there is nothing to be heard.

Thank you! I have referenced vgmplay in the past. I think its YM2413 is accurate, but my experience with emulators while developing SBVGM made me realize that (at times) the emulators aren't accurate as real hardware or there are bugs in the emulation. I really would like to get my hands on an actual YM2413 so I can do my own tests and comparisons with the YM3812 before I make any additional fixes and changes ... perhaps one of these days when I have a bit more time.

I think the silence that you hear every now and then might be an issue with running under Win98. I have a Yamaha PCI sound card that exhibits this problem and I reckon that it may be some kind of driver issue.

It's getting more clear now, I havent be able to use in_vgm with adlib opl (yet), I'm not even sure if it's possible at all. For reasons unknown I prefer your player over vgmplay, maybe it's that it's real time and there is no steal time ? I suspect also maybe the instrument handling of the adlib's opl that seem more "true to the adlib" with your player" (I'm bored of listening to this music on a real ym2413).

Thanks alot for your batch file, but the funny thing is that I already had one made for your player already that's look exactly the same 😁

In win98 the difference for your player to sound great only in foreground is maybe to use timer instead of interrups, or vice versa, someone already told you about that in the thread and you told him that you are working on it to change, is that a good idea? But you also say that what's particular with your player is that it's direct translation and not emulation, and this make a big difference. I am not sure to understand what you mean at all there.

What make your player specific, sounding so good and one of it's kind is that it play in real dos. That your player print is 5kb or 500kb make no difference to me. Of course I use msdos and freedos on p1 class machines. If you want to keep as tiny or small as possible, it's up to you, but I dont think it's a good idea to go into win32.

ElBrunzy wrote:

It's getting more clear now, I havent be able to use in_vgm with adlib opl (yet), I'm not even sure if it's possible at all. For […]
Show full quote

It's getting more clear now, I havent be able to use in_vgm with adlib opl (yet), I'm not even sure if it's possible at all. For reasons unknown I prefer your player over vgmplay, maybe it's that it's real time and there is no steal time ? I suspect also maybe the instrument handling of the adlib's opl that seem more "true to the adlib" with your player" (I'm bored of listening to this music on a real ym2413).

Thanks alot for your batch file, but the funny thing is that I already had one made for your player already that's look exactly the same 😁

In win98 the difference for your player to sound great only in foreground is maybe to use timer instead of interrups, or vice versa, someone already told you about that in the thread and you told him that you are working on it to change, is that a good idea? But you also say that what's particular with your player is that it's direct translation and not emulation, and this make a big difference. I am not sure to understand what you mean at all there.

What make your player specific, sounding so good and one of it's kind is that it play in real dos. That your player print is 5kb or 500kb make no difference to me. Of course I use msdos and freedos on p1 class machines. If you want to keep as tiny or small as possible, it's up to you, but I dont think it's a good idea to go into win32.

Thank you for the kind comments about the player! It originally was just an experiment to see if certain RP2A03 (NES APU) features would work on the SAA1099. The VGMs provided data to work with and gradually over time I realized I could just support the other chipsets that are used by sound cards from the early PC era. Since the player was written for DOS, running the player in a Win95/98/ME shell could introduce timing issues; a proper win32 version of the player would not have the .EXE size (or memory) restrictions. As I mentioned before, it is possible to access hardware registers directly under Win95/98/ME, but I'm not 100% if that is safe to do. Another option is to just a 32-bit DOS version of the .EXE. This might actually be easier to do, but I will have to find time to look into that as I ought to spend some time seeing if there's a way to improve the timing and playback so the VGMs that have very high update rates could play properly even on an old machine ... but (at the moment) I don't have too much time to investigate this.

Thank you again for your kind comments and suggestions! 😀

OPLx wrote:

Thank you for the kind comments about the player! It originally was just an experiment to see if certain RP2A03 (NES APU) features would work on the SAA1099. The VGMs provided data to work with and gradually over time I realized I could just support the other chipsets that are used by sound cards from the early PC era. Since the player was written for DOS, running the player in a Win95/98/ME shell could introduce timing issues; a proper win32 version of the player would not have the .EXE size (or memory) restrictions. As I mentioned before, it is possible to access hardware registers directly under Win95/98/ME, but I'm not 100% if that is safe to do. Another option is to just a 32-bit DOS version of the .EXE. This might actually be easier to do, but I will have to find time to look into that as I ought to spend some time seeing if there's a way to improve the timing and playback so the VGMs that have very high update rates could play properly even on an old machine ... but (at the moment) I don't have too much time to investigate this.

Thank you again for your kind comments and suggestions! 😀

The hit point of your player is that it dont need windows. I start to understand that if you want to integrate some vgmplay libs you will need to port your code to win32. I remember that shitty process. I called it the "16 bit and 32 bit libs cannot merge" era.

You might confuse me with someone else or misunderstood my propositions. I think you should keep away from windows and linux and remain on dos so for to gain full realtime access to hardware. I understand you cannot use win32 code from vgmplay on dos and will stop bug you with that.

How was the miracle warrior debug ? I really want to listen to that music on the adlib's opl. Maybe you can just recompile your code from tiny to small or something like it? I'm very eager to listen to that soundtrack from your very player!

OPLx : maybe you dont like forum ? But what I prefer with vogons is that I end up talking with guys like you. I feel so lucky to be so. Can I ask you some question ? : What went you into coding computers ? How come you are interested in music so much ? What is the relationship of coding an music in your life ? What soundcard do you prefer to use when into coding ? Is there reasons you use closed sources for your sbvgm player projet ?

feel free to answer or not, I just felt like an journalist 😁

ElBrunzy wrote:

The hit point of your player is that it dont need windows. I start to understand that if you want to integrate some vgmplay libs […]
Show full quote

OPLx wrote:

Thank you for the kind comments about the player! It originally was just an experiment to see if certain RP2A03 (NES APU) features would work on the SAA1099. The VGMs provided data to work with and gradually over time I realized I could just support the other chipsets that are used by sound cards from the early PC era. Since the player was written for DOS, running the player in a Win95/98/ME shell could introduce timing issues; a proper win32 version of the player would not have the .EXE size (or memory) restrictions. As I mentioned before, it is possible to access hardware registers directly under Win95/98/ME, but I'm not 100% if that is safe to do. Another option is to just a 32-bit DOS version of the .EXE. This might actually be easier to do, but I will have to find time to look into that as I ought to spend some time seeing if there's a way to improve the timing and playback so the VGMs that have very high update rates could play properly even on an old machine ... but (at the moment) I don't have too much time to investigate this.

Thank you again for your kind comments and suggestions! 😀

The hit point of your player is that it dont need windows. I start to understand that if you want to integrate some vgmplay libs you will need to port your code to win32. I remember that shitty process. I called it the "16 bit and 32 bit libs cannot merge" era.

You might confuse me with someone else or misunderstood my propositions. I think you should keep away from windows and linux and remain on dos so for to gain full realtime access to hardware. I understand you cannot use win32 code from vgmplay on dos and will stop bug you with that.

How was the miracle warrior debug ? I really want to listen to that music on the adlib's opl. Maybe you can just recompile your code from tiny to small or something like it? I'm very eager to listen to that soundtrack from your very player!

I understand what you mean. A Win95/Win98/WinME version sounded appealing since I wouldn't have to deal with some of the idiosyncrasies of the 16-bit memory model and still have direct access to hardware. Because of time though and not being sure whether it's actually safe to do direct hardware writes, it's highly unlikely there will be a version for Win95/98/Me. 😀

The debug on miracle warrior has been a bit slow. Things got a bit busy and I didn't have some spare time to take do any further investigation. The fix should be simple though; I just need to re-write how the memory allocator works. If I have a chance this week, I will take a look.