|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
DevKitSMS VGM player/accessing the Everdrive filesystem
Posted: Thu Jul 20, 2023 12:30 am
|
@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 ] |
|
|
Posted: Thu Jul 20, 2023 9:08 am |
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...) |
|
|
Posted: Thu Jul 20, 2023 2:30 pm |
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
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. |
|
|
Posted: Thu Jul 20, 2023 2:42 pm |
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. |
|
|
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. | |
|
Posted: Thu Jul 20, 2023 6:03 pm |
This was in my mind!
For play it must be decompressed? I was thinking only in some homebrew that recognized the format. |
|
|
Posted: Fri Jul 21, 2023 9:31 am |
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. |
|
|
Posted: Fri Jul 21, 2023 10:05 am |
Out of interest, what's the critical limiting factor here - processing speed or RAM availability? |
|
|
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. |
|
|
Posted: Sat Jul 22, 2023 9:02 am |
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? |
|
|
Posted: Mon Aug 21, 2023 2:23 pm |
please split this topic from post 126964 if possible :) | |
|
Posted: Mon Aug 21, 2023 6:59 pm |
Done :) | |
|
Posted: Mon Aug 28, 2023 10:43 am |
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. |
|
|
Posted: Thu May 23, 2024 11:02 pm |
https://github.com/untoxa/vgm_player/
|
|
|
Posted: Fri May 24, 2024 10:03 am |
absolutely interesting! |
|
|
Posted: Fri May 24, 2024 10:57 am |
Do it for SMS! |
|
|
Posted: Wed May 29, 2024 2:03 pm |
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.. |
|
|
Posted: Tue Sep 17, 2024 7:43 pm |
FM chip support: https://github.com/untoxa/VGM_player/releases/tag/v1.3 | |
|
Posted: Thu Sep 19, 2024 12:37 pm |
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
|
|
|
Posted: Fri Sep 27, 2024 10:52 pm |
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? |
|
|
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). | |
|
Posted: Sat Sep 28, 2024 12:09 pm |
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? |
|
|
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. | |
|
Posted: Sat Sep 28, 2024 3:33 pm |
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. |
|
|
Posted: Sun Sep 29, 2024 9:12 am |
PAL and NTSC timeslot distribution. On NTSC it is close to ideal, on PAL it is less equal, but very robust.
|
|