long filename support possible?
- Thread starter DReffects
- Start date
frolik
Bass Invader
you can copy over files with LFNs using a card reader but most gp32 progs will truncate the filename with a ~1. Strangely some progs like frodo, do recognise the entire filename.
frolik
Bass Invader
stupid? <_<
And lazy.
Last edited by a moderator:
H
Hazuki2K4
Guest
u..h...o...k
frolik
Bass Invader
I believe yoyo and crew intend to implement a rom database (goodsnes?) like ljgp has, this sort it out.
for now you'll have to just rename your roms to fit 8.3 names
Squidge
Certified Guru
Progs like Frodo probably pull the filename from the file itself, rather than the filename.
However, it IS possible to support long filenames, but it would have to be implemented by each developer in there own projects - even if we hacked it into the bios in someway (as no doubt all the current projects out there are assuming 8.3 by now)
However, it IS possible to support long filenames, but it would have to be implemented by each developer in there own projects - even if we hacked it into the bios in someway (as no doubt all the current projects out there are assuming 8.3 by now)
What's the point of implementing the GoodTools database, when some of the other emulators already offer long filename support!? LFN support is do-able now. Renaming roms to 8.3 is not practical for anyone that regularly rotates the ROMs they play. Also, GoodTools databases gets outdated when new ROMs are found.
So, implementing LFN support is the only correct solution.
Last edited by a moderator:
frolik
Bass Invader
Really? How outdated can it get? Didn't know that it was incomplete....
works well in rlyeh's emulators and ljgp, doesn't seem a problem to me
Squidge
Certified Guru
Which emulators support LFNs? Considering the GP32 bios doesn't support LFN's, then the emulator itself must be reading from the SMC directly via the hardware registers.
Unless of course your getting confused, and the emulators seem to be supporting LFN's simply because they are retrieving the full name from inside the rom itself, which is most likely what is happening.
Last edited by a moderator:
Hmmm, you might be right. I haven't played with my GP32 in the last couple of months (I'm on a ROM D/Ling marathon right now, almost done.) I thought at least one of them has true LFN support.
Ahhh, maybe I am thinking of LFN support via ZIPped ROMs? I.e., the emulator uses the LFN of the ROM file(s) inside a 8.3 Zip file. That would solve both the LFN support problems, as well as give us Zipped ROMs support at the same time. Is there not an emu that already does this?
To me, that would be the ultimate solution to all the ROM problems. Zipped to save space, and also allowing LFN support, without all the aggravation of "scanning" the ROMs, outdated GoodTools databases, or other hacks.
I would be willing to bet, Zip support is also easier to implement, than many of these other ideas, a the libs are already out there, ready to be plugged into a emulator. No emu author should release his work, without such support, IMHO.
Sure. The most recent Good2600 GoodTools added over 1000 new entities!
Using the GoodTools DB works, but I'd much rather see LFN support through the use of ZIP files, as I mentioned in the previous reply. Cleaner, and works better.
Last edited by a moderator:
coolgpguy
Member
use the hacked pc link :huh:
Axeman
Axemeister
It's something I would have thought was obvious from the beginning! Ah well.. could be worse!
frolik
Bass Invader
he's talking about viewing lfn's within emulators which doesn't work - copying em over ain't a prob
Bingo. Something I thought would be obvious.he's talking about viewing lfn's within emulators which doesn't work - copying em over ain't a prob
Try searching through a few thousand Atari 2600 ROMs, using the current Atari 2600 emus.
Last edited by a moderator:
Squidge
Certified Guru
Well, there are two solutions here:
We could either use a filename database, which resolves shortnames to the full length names. Would mean including support for the database in every gp32 program (not supporting programs would simply just use the original shortened name), as well as writing specific pc software to update the file when new files were copies over using it. Would also mean you couldn't copy files over using an SMC Reader/Writer - they would all have to be copied over using the proper pc software that supports the database.
Or, we could go Microsoft's way - and that is to use additional entries in the directory structures for the extended parts of the names. Old programs not supporting the long filenames would show the shortened versions, whilst the supported software would show the full filename. This would would allow SMC readers/writers full use of the smc, and even show the long filenames on the PC when connected in such a way. However, it would require new software for the gp32 pc-link tool as well as a new pc pc-link tool, although you could ignore this and just use an smc reader/writer if you wished.
Both methods would allow filenames upto 255 character and both upper and lower case characters, along with other normally forbidden characters.
Personally, I prefer the second option, as it's more universal, and your not going to naff up the database as easily. The ability to read the entire card (including long names) to your pc for backup purposes is great.
To implement this would require simply calling different routines for listing the files in a directory and opening/creating files etc. May even be able to replace the old routines thereby meaning a simple modification and recompile could enable long filename support (I say modification as no doub't most programs now assume 8+3, and thus only allocate buffers big enough to hold filenames that size).
We could either use a filename database, which resolves shortnames to the full length names. Would mean including support for the database in every gp32 program (not supporting programs would simply just use the original shortened name), as well as writing specific pc software to update the file when new files were copies over using it. Would also mean you couldn't copy files over using an SMC Reader/Writer - they would all have to be copied over using the proper pc software that supports the database.
Or, we could go Microsoft's way - and that is to use additional entries in the directory structures for the extended parts of the names. Old programs not supporting the long filenames would show the shortened versions, whilst the supported software would show the full filename. This would would allow SMC readers/writers full use of the smc, and even show the long filenames on the PC when connected in such a way. However, it would require new software for the gp32 pc-link tool as well as a new pc pc-link tool, although you could ignore this and just use an smc reader/writer if you wished.
Both methods would allow filenames upto 255 character and both upper and lower case characters, along with other normally forbidden characters.
Personally, I prefer the second option, as it's more universal, and your not going to naff up the database as easily. The ability to read the entire card (including long names) to your pc for backup purposes is great.
To implement this would require simply calling different routines for listing the files in a directory and opening/creating files etc. May even be able to replace the old routines thereby meaning a simple modification and recompile could enable long filename support (I say modification as no doub't most programs now assume 8+3, and thus only allocate buffers big enough to hold filenames that size).
