Forums

@sverx 1 question: With devkit is possible create a vgmplayer with a gui visual and playlist feature?

[Admin: split topic from https://www.smspower.org/forums/15228-DevkitSMSDevelopYourHomebrewInC ]

segarule wrote

@sverx 1 question: With devkit is possible create a vgmplayer with a gui visual and playlist feature?

Sure, provided you:
- convert each VGM to PSG to be used with PSGlib
- put them all in the ROM with the player
it can be done (but of course I have no idea which GUI visuals you need...)

sverx wrote

segarule wrote

@sverx 1 question: With devkit is possible create a vgmplayer with a gui visual and playlist feature?

Sure, provided you:
- convert each VGM to PSG to be used with PSGlib
- put them all in the ROM with the player
it can be done (but of course I have no idea which GUI visuals you need...)

This dont was exactly in my mind. With gui visuals i mean with windows and menu like as Sonicplayer.
https://www.paulsprojects.net/sonicplayer/sonicplayer.png

Quote

- convert each VGM to PSG to be used with PSGlib

My idea was keep the vgm files in folder and the smsapp acess it and play it in native form and with no necessity of rom output.

segarule wrote

My idea was keep the vgm files in folder and the smsapp acess it and play it in native form.

You would probably need an EverDrive and a library to access the SD card in it, then read (cache) a chunk of the file, play that with some VGM replay library while caching the next chunk. It's possible, but not easy.

I don’t think anyone has an example of accessing the SD card on Everdrive. Decompressing compressed VGMs is beyond the system capabilities.

sverx wrote

segarule wrote

My idea was keep the vgm files in folder and the smsapp acess it and play it in native form.

You would probably need an EverDrive and a library to access the SD card in it, then read (cache) a chunk of the file, play that with some VGM replay library while caching the next chunk. It's possible, but not easy.

This was in my mind!

Quote

I don’t think anyone has an example of accessing the SD card on Everdrive. Decompressing compressed VGMs is beyond the system capabilities.

For play it must be decompressed? I was thinking only in some homebrew that recognized the format.

Maxim wrote

Decompressing compressed VGMs is beyond the system capabilities.

Yeah, I didn't even consider that. But 'regular' (not compressed) VGMs could be played if one can actually access the filesystem on the SD card, which of course is a big IF.

Maxim wrote

Decompressing compressed VGMs is beyond the system capabilities.

Out of interest, what's the critical limiting factor here - processing speed or RAM availability?

A bit of both. Deflate has a 32KB window size, plus it needs to build Huffman trees as it works, so doing all that would require rather more than 8KB of RAM. Unzippers exist for CP/M on Z80, for example. I suspect they’d be pretty slow, though.

Regular VGMs can also be played by including them in the ROM, but it’s not very space efficient and makes it hard to have a long playlist. Having them in the file system can seem easier to manage for a typical user.

Hum. So basically we have 2 problems:
1 - Amount of RAM resident in system;
2 - Necessity of decompress vgm faster?

I think that iten 2 could have a solution?

please split this topic from post 126964 if possible :)

Done :)

Maxim wrote

I don’t think anyone has an example of accessing the SD card on Everdrive.

There are probably magic sequences that lock and unlock access to the SD cart, Emulicious emulate that, because you can run the game gear games using everdrive firmware as bios. So that is not much of a secret. The point is, that once locked, it might not be possible to unlock access to the SD cart, but probably not. So you either have to replace the everdrive firmware with your own, or you are lucky and you can load the program from SD and then access that SD. Anyway, reading SD sectors is not enough, you need to implement FAT filesystem as well, at least the read only mode.

ps: on the Game Boy, there is EZFlash Jr. cart, where you can arbitrary lock or unlock access to SD. But no one seem to take advantage of it due to the lack of interest, i guess.

https://github.com/untoxa/vgm_player/

6a703145-6a31-4a07-856c-fad5fdfd6311.jpg (124.63 KB)

screenshot

toxa wrote

https://github.com/untoxa/vgm_player/

absolutely interesting!

toxa wrote

https://github.com/untoxa/vgm_player/

Do it for SMS!

segarule wrote

Do it for SMS!

There is an SMS version: https://github.com/untoxa/VGM_player/releases/latest

Checked on the real hardware - working fine.

To be clear: this is the SD access demo project for the different SD carts in the first place. Not the VGM player, i put the player in just for the demonstration to make example do something useful. I am not going to add features to the player myself, my only interest is adding the support for the newest Everdrive carts. Likely state-of-the-art Everdrives are not compatible with the old ones, but i don't have one to test that yet, if someone has it and eager to help - will be much obliged.

Though, if someone want to contribute something to the player functionality or the player look - you are very welcome to pull request your features, or fork the repo and do it on your own..

IMG_1600.jpg (57.73 KB)

VGM Player running on the SMS2 + Everdrive SMS

FM chip support: https://github.com/untoxa/VGM_player/releases/tag/v1.3

ps: the rom may be run in Emulicious with the required mounted filesystem, if you make the zip archive with the ROM and the other necessary files (say, *.VGM files), and then pass that ZIP file instead of the ROM file. "Run games via Everdrive" option in Emulicious must be switched on. For example:

Emulicious.exe -set MasterEverdriveEnabled=true vgm_player-everdrive.zip

What is the best way to compensate the difference between the real console speed (which is PAL or NTSC) and the VGM file, which is supposed to be played on PAL or NTSC (according to the "Rate" field)?

VGM playback in my case is interrupt-driven, and it is important to keep this feature, because of the asynchronous readahead process running in main. Is there is some recommended solution for using hblank interrupts instead?

What should be the correct settings/algo for these cases:
1. GG + 50 Hz VGM
2. PAL SMS + 60 Hz VGM
3. NTSC SMS + 50 Hz VGM

Something like set interrupt fire each 38 line and run the driver each 5 events in one case and set interrupt fire each 44 and run the driver each 6 events in the other? Probably, my math is not correct. Scanline counter behaving sort of weirdly, taking into account this: https://www.smspower.org/Development/ScanlineCounter probably that complicate things as well?

Since the VGM file has delays in units of 1/44100 s, you should be able to traverse the file at a rate of 735 samples per frame at 60Hz and 882 samples per frame at 50Hz. The result of this is that a file with data every 735 samples (“recorded at 60Hz”) will play two frames’ data in one interrupt every 5 frames of played at 50Hz, and conversely a 50Hz file will have a frame with no updates every 6th frame at 60Hz. I found the result to be pleasant to listen to despite the coarseness of the playback aliasing in time. Maybe it’s worse for people with more refined musical senses, or for certain types of music (I guess per-frame arps might be more noticeably affected).

a-m-m-m... is not that too crude?

i want to try hblank approach first. how interrupts behave while inactive display (vblank period)? do they fire? if they do, do "jumps" of the scanline counter affect the hblank interrupt calls in the NTSC 256x192 and PAL 256x192 modes?

The interrupts are only in the active display, so you would need to count lines to time things inside the blanking area.

Hm, looks like my HBlank approach works reasonably well: https://github.com/untoxa/VGM_player/releases/tag/v1.4

On some complex FM tunes it does miss interrupts sometimes, but it is not audible and relatively rare, only visible if make the player display the current time slot.

PAL and NTSC timeslot distribution. On NTSC it is close to ideal, on PAL it is less equal, but very robust.

NTSC timeslots.jpg (23 KB)

NTSC timeslots

PAL timeslots.jpg (22.64 KB)

PAL timeslots

Author	Message
segarule Joined: 23 Jan 2010 Posts: 460	DevKitSMS VGM player/accessing the Everdrive filesystem Posted: Thu Jul 20, 2023 12:30 am
segarule Joined: 23 Jan 2010 Posts: 460	@sverx 1 question: With devkit is possible create a vgmplayer with a gui visual and playlist feature? [Admin: split topic from https://www.smspower.org/forums/15228-DevkitSMSDevelopYourHomebrewInC ]

sverx Joined: 05 Sep 2013 Posts: 3956 Location: Stockholm, Sweden	Posted: Thu Jul 20, 2023 9:08 am
	segarule wrote @sverx 1 question: With devkit is possible create a vgmplayer with a gui visual and playlist feature? Sure, provided you: - convert each VGM to PSG to be used with PSGlib - put them all in the ROM with the player it can be done (but of course I have no idea which GUI visuals you need...)

segarule Joined: 23 Jan 2010 Posts: 460	Posted: Thu Jul 20, 2023 2:30 pm
segarule Joined: 23 Jan 2010 Posts: 460	sverx wrote segarule wrote @sverx 1 question: With devkit is possible create a vgmplayer with a gui visual and playlist feature? Sure, provided you: - convert each VGM to PSG to be used with PSGlib - put them all in the ROM with the player it can be done (but of course I have no idea which GUI visuals you need...) This dont was exactly in my mind. With gui visuals i mean with windows and menu like as Sonicplayer. https://www.paulsprojects.net/sonicplayer/sonicplayer.png Quote - convert each VGM to PSG to be used with PSGlib My idea was keep the vgm files in folder and the smsapp acess it and play it in native form and with no necessity of rom output.

sverx Joined: 05 Sep 2013 Posts: 3956 Location: Stockholm, Sweden	Posted: Thu Jul 20, 2023 2:42 pm
	segarule wrote My idea was keep the vgm files in folder and the smsapp acess it and play it in native form. You would probably need an EverDrive and a library to access the SD card in it, then read (cache) a chunk of the file, play that with some VGM replay library while caching the next chunk. It's possible, but not easy.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14990 Location: London	Posted: Thu Jul 20, 2023 5:07 pm
	I don’t think anyone has an example of accessing the SD card on Everdrive. Decompressing compressed VGMs is beyond the system capabilities.

segarule Joined: 23 Jan 2010 Posts: 460	Posted: Thu Jul 20, 2023 6:03 pm
segarule Joined: 23 Jan 2010 Posts: 460	sverx wrote segarule wrote My idea was keep the vgm files in folder and the smsapp acess it and play it in native form. You would probably need an EverDrive and a library to access the SD card in it, then read (cache) a chunk of the file, play that with some VGM replay library while caching the next chunk. It's possible, but not easy. This was in my mind! Quote I don’t think anyone has an example of accessing the SD card on Everdrive. Decompressing compressed VGMs is beyond the system capabilities. For play it must be decompressed? I was thinking only in some homebrew that recognized the format.

sverx Joined: 05 Sep 2013 Posts: 3956 Location: Stockholm, Sweden	Posted: Fri Jul 21, 2023 9:31 am
	Maxim wrote Decompressing compressed VGMs is beyond the system capabilities. Yeah, I didn't even consider that. But 'regular' (not compressed) VGMs could be played if one can actually access the filesystem on the SD card, which of course is a big IF.

willbritton Joined: 06 Mar 2022 Posts: 697 Location: London, UK	Posted: Fri Jul 21, 2023 10:05 am
	Maxim wrote Decompressing compressed VGMs is beyond the system capabilities. Out of interest, what's the critical limiting factor here - processing speed or RAM availability?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14990 Location: London	Posted: Fri Jul 21, 2023 10:14 am
	A bit of both. Deflate has a 32KB window size, plus it needs to build Huffman trees as it works, so doing all that would require rather more than 8KB of RAM. Unzippers exist for CP/M on Z80, for example. I suspect they’d be pretty slow, though. Regular VGMs can also be played by including them in the ROM, but it’s not very space efficient and makes it hard to have a long playlist. Having them in the file system can seem easier to manage for a typical user.

segarule Joined: 23 Jan 2010 Posts: 460	Posted: Sat Jul 22, 2023 9:02 am
segarule Joined: 23 Jan 2010 Posts: 460	Hum. So basically we have 2 problems: 1 - Amount of RAM resident in system; 2 - Necessity of decompress vgm faster? I think that iten 2 could have a solution?

sverx Joined: 05 Sep 2013 Posts: 3956 Location: Stockholm, Sweden	Posted: Mon Aug 21, 2023 2:23 pm
	please split this topic from post 126964 if possible :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14990 Location: London	Posted: Mon Aug 21, 2023 6:59 pm
	Done :)

toxa Joined: 09 Aug 2021 Posts: 152	Posted: Mon Aug 28, 2023 10:43 am
toxa Joined: 09 Aug 2021 Posts: 152	Maxim wrote I don’t think anyone has an example of accessing the SD card on Everdrive. There are probably magic sequences that lock and unlock access to the SD cart, Emulicious emulate that, because you can run the game gear games using everdrive firmware as bios. So that is not much of a secret. The point is, that once locked, it might not be possible to unlock access to the SD cart, but probably not. So you either have to replace the everdrive firmware with your own, or you are lucky and you can load the program from SD and then access that SD. Anyway, reading SD sectors is not enough, you need to implement FAT filesystem as well, at least the read only mode. ps: on the Game Boy, there is EZFlash Jr. cart, where you can arbitrary lock or unlock access to SD. But no one seem to take advantage of it due to the lack of interest, i guess.

toxa Joined: 09 Aug 2021 Posts: 152	Posted: Thu May 23, 2024 11:02 pm
toxa Joined: 09 Aug 2021 Posts: 152	https://github.com/untoxa/vgm_player/ 6a703145-6a31-4a07-856c-fad5fdfd6311.jpg (124.63 KB) screenshot

sverx Joined: 05 Sep 2013 Posts: 3956 Location: Stockholm, Sweden	Posted: Fri May 24, 2024 10:03 am
	toxa wrote https://github.com/untoxa/vgm_player/ absolutely interesting!

segarule Joined: 23 Jan 2010 Posts: 460	Posted: Fri May 24, 2024 10:57 am
segarule Joined: 23 Jan 2010 Posts: 460	toxa wrote https://github.com/untoxa/vgm_player/ Do it for SMS!

toxa Joined: 09 Aug 2021 Posts: 152	Posted: Wed May 29, 2024 2:03 pm
toxa Joined: 09 Aug 2021 Posts: 152	segarule wrote Do it for SMS! There is an SMS version: https://github.com/untoxa/VGM_player/releases/latest Checked on the real hardware - working fine. To be clear: this is the SD access demo project for the different SD carts in the first place. Not the VGM player, i put the player in just for the demonstration to make example do something useful. I am not going to add features to the player myself, my only interest is adding the support for the newest Everdrive carts. Likely state-of-the-art Everdrives are not compatible with the old ones, but i don't have one to test that yet, if someone has it and eager to help - will be much obliged. Though, if someone want to contribute something to the player functionality or the player look - you are very welcome to pull request your features, or fork the repo and do it on your own.. IMG_1600.jpg (57.73 KB) VGM Player running on the SMS2 + Everdrive SMS

toxa Joined: 09 Aug 2021 Posts: 152	Posted: Tue Sep 17, 2024 7:43 pm
toxa Joined: 09 Aug 2021 Posts: 152	FM chip support: https://github.com/untoxa/VGM_player/releases/tag/v1.3

toxa Joined: 09 Aug 2021 Posts: 152	Posted: Thu Sep 19, 2024 12:37 pm
toxa Joined: 09 Aug 2021 Posts: 152	ps: the rom may be run in Emulicious with the required mounted filesystem, if you make the zip archive with the ROM and the other necessary files (say, *.VGM files), and then pass that ZIP file instead of the ROM file. "Run games via Everdrive" option in Emulicious must be switched on. For example: Emulicious.exe -set MasterEverdriveEnabled=true vgm_player-everdrive.zip

toxa Joined: 09 Aug 2021 Posts: 152	Posted: Fri Sep 27, 2024 10:52 pm
toxa Joined: 09 Aug 2021 Posts: 152	What is the best way to compensate the difference between the real console speed (which is PAL or NTSC) and the VGM file, which is supposed to be played on PAL or NTSC (according to the "Rate" field)? VGM playback in my case is interrupt-driven, and it is important to keep this feature, because of the asynchronous readahead process running in main. Is there is some recommended solution for using hblank interrupts instead? What should be the correct settings/algo for these cases: 1. GG + 50 Hz VGM 2. PAL SMS + 60 Hz VGM 3. NTSC SMS + 50 Hz VGM Something like set interrupt fire each 38 line and run the driver each 5 events in one case and set interrupt fire each 44 and run the driver each 6 events in the other? Probably, my math is not correct. Scanline counter behaving sort of weirdly, taking into account this: https://www.smspower.org/Development/ScanlineCounter probably that complicate things as well?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14990 Location: London	Posted: Sat Sep 28, 2024 9:04 am
	Since the VGM file has delays in units of 1/44100 s, you should be able to traverse the file at a rate of 735 samples per frame at 60Hz and 882 samples per frame at 50Hz. The result of this is that a file with data every 735 samples (“recorded at 60Hz”) will play two frames’ data in one interrupt every 5 frames of played at 50Hz, and conversely a 50Hz file will have a frame with no updates every 6th frame at 60Hz. I found the result to be pleasant to listen to despite the coarseness of the playback aliasing in time. Maybe it’s worse for people with more refined musical senses, or for certain types of music (I guess per-frame arps might be more noticeably affected).

toxa Joined: 09 Aug 2021 Posts: 152	Posted: Sat Sep 28, 2024 12:09 pm
toxa Joined: 09 Aug 2021 Posts: 152	a-m-m-m... is not that too crude? i want to try hblank approach first. how interrupts behave while inactive display (vblank period)? do they fire? if they do, do "jumps" of the scanline counter affect the hblank interrupt calls in the NTSC 256x192 and PAL 256x192 modes?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14990 Location: London	Posted: Sat Sep 28, 2024 12:17 pm
	The interrupts are only in the active display, so you would need to count lines to time things inside the blanking area.

toxa Joined: 09 Aug 2021 Posts: 152	Posted: Sat Sep 28, 2024 3:33 pm
toxa Joined: 09 Aug 2021 Posts: 152	Hm, looks like my HBlank approach works reasonably well: https://github.com/untoxa/VGM_player/releases/tag/v1.4 On some complex FM tunes it does miss interrupts sometimes, but it is not audible and relatively rare, only visible if make the player display the current time slot.

toxa Joined: 09 Aug 2021 Posts: 152	Posted: Sun Sep 29, 2024 9:12 am
toxa Joined: 09 Aug 2021 Posts: 152	PAL and NTSC timeslot distribution. On NTSC it is close to ideal, on PAL it is less equal, but very robust. NTSC timeslots.jpg (23 KB) NTSC timeslots PAL timeslots.jpg (22.64 KB) PAL timeslots

Forums

View topic - DevKitSMS VGM player/accessing the Everdrive filesystem