This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#6122 - NSF player
Attached to Project:
Rockbox
Opened by Adam Gashlin (AdamGashlin) - Thursday, 05 October 2006, 09:17 GMT+2
Opened by Adam Gashlin (AdamGashlin) - Thursday, 05 October 2006, 09:17 GMT+2
|
DetailsHere's an NSF player, based on NotSo Fatso by Disch.
At the moment it only supports the pAPU, the expansion chip and FDS code is there but I'm working on optimizing the minimal stuff first. Not everything will play real time on my 4g ipod. Not by any stretch is this "done", but I figured I should get it out there. 
nsf2.patch
(18.1 KiB)
apps/codecs/Makefile | 15 ++++- apps/codecs/SOURCES | 1 apps/codecs/nsf.c | 140 ++++++++++++++++++++++++++++++++++++++++++++++++++ apps/metadata.c | 14 +++++ apps/tree.c | 1 firmware/export/id3.h | 1 firmware/id3.c | 2 tools/configure | 34 ++++++------ 8 files changed, 188 insertions(+), 20 deletions(-) 
nsf0.1.tar.bz2
(92.8 KiB)
|
This task depends upon
Closed by Steve Bavin (pondlife)
Thursday, 25 January 2007, 19:57 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed.
Thursday, 25 January 2007, 19:57 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed.
Now full speed for most stuff, sacrificing some accuracy. Wizardry doesn't work at the moment for reasons to be explored shortly.
Fixed DMC (was all but dead, now try out Journey to Silius!)
Added NSFe loading, track lengths and fade times are read from NSFe. No playlist support yet.
Artist, game name, and company (copyright info) are loaded and displayed as artist, track name, and album, respectively.
I noticed that the loading code is quite endian-dependent (as the files are little endian and the code is written assuming little endian loading of 32 bit integers), this will have to be remedied. Part of this is the reason why there are now warnings shown again.
Oh, and the progress bar will now correctly report the current track as play advances.
I haven't had this tested on a big endian system, though, if anyone can perform such a test and let me know how it works out I'd very much appreciate it. In fact, it hasn't been tested on anything but ipods so far. So please give it a go, it is very usable now and could use testing. If anyone is squemish about building the source I can put together a custom build for you.
Builds here: http://hcs64.com/rockbox/
To try to keep things consistent, I've named the patch nsf0.17.patch, to show that it comes after the nsf0.16.tar.bz2 (libNoSo). You'll need the latest numbered version of both the patch and the .tar.bz2 archive to build.
Unfortunately I'm not wholly sure which NSF may have caused the problem. Part of my mind is saying Ninja Gaiden 2, and another part Castlevania 1, but it could easily be neither of those.
All code is now in a single file (no libNotSo, and now there's a single patch), tidied up a bit.
Enabled processing of undocumented opcodes (Loopz now works).
Speed seems to have taken a slight hit, much work to be done along those lines.
Was I supposed to apply 21 over 20 or anything? (Tested with an H120, just to clarify)
Speaking of track numbers, is zero-based ok for everyone?
I don't know what to say about your speed issues... everything is running much faster on ARM. I'd like you to run the profiled version (uncomment #define NSF_PROFILE) so I can get an idea where the problem is, but it uses the portalplayer's USEC_TIMER, and I don't know of an equivalent mechanism on the coldfile. Could you try removing the whole #if CONFIG_CPU==etc. block at the beginning? One tester was reporting those helped with speed, but that was several versions back.
Moved a lot of stuff into IRAM, helped speed a lot for someone on an H120.
Cleaned up a bunch of code related to mixing that isn't needed now (since every channel is played at full volume).
The reason I am asking is because nsf.c breaks just about every rule we have regarding source code formatting, e.g mixed case identifiers, TAB characters and // comments.
We allow this kind of formatting if it helps us maintain the code, for example patches from the main project, but if you have rewritten large portions of it anyway, we certainly prefer having the code follow our guidelines.
It has been substantially rewritten, so I'm going to need to clean it up.
If this is in good enough shape I'd like it to be considered for CVS.