|
Post by Espen Skog on Jun 20, 2008 12:12:12 GMT -5
Is there a tool which can open the flashfile made by dtvmkfs. Kinda like an explorer-tool which enables the user to:
1. Add/Remove files from a already existing flashfile.bin 2. Set up partitions in the flashfile (e.g. have one partition for games and another for demos and a third for programs and so on) 3. A button that creates the flashfile.bin file from all files selected :-)
It would be nice when one has a flashfile.bin with alot of games, and you just want to rearrange some, delete some or add some new games/demos.
If someone has this, or wants to make such a tool, I would be very happy.
//Espen
|
|
|
Post by 1570 on Jun 22, 2008 11:05:12 GMT -5
Yes, such a tool would be nice - it doesn't exist though. There is dtvmkfs that, together with its companion dirdump, provides more or less the functionality needed. Unfortunately, it does not provide a GUI, does not support fixed portions of the flash (alternate kernal...), does not allow adding PRG files (easily), and cannot minimize the wear imposed on the flash chip when reflashing since it has no "update" functionality but creates flash images from scratch always. I planned to write a new tool for some time now... don't know how motivated I am for all this though. Just for the fun of it, I just ported tlr's dtvpack.c to Java (I think a Java app meets portability and GUI requirements best here - I'd hate to have such an application as Windows only or coming with a ton of dependencies). See viceplus.svn.sourceforge.net/viewvc/viceplus/trunk/tools/dtvfsedit/. It's a long way to a proper GUI though of course...
|
|
|
Post by 1570 on Jun 28, 2008 6:28:26 GMT -5
Current status of dtvfsedit: - Opens existing flash images and Spiff ZIPs
- Imports/exports PRG files (transparently handling DTV flash compression)
Error handling and UI is very basic so far. Concerning removing files: Not possible easily due to the flash image format. Proper removing needs erase and reflash (bad for flash lifetime). I'll add the option to change/shorten file names and setting start address to zero though. This hides the corresponding files from starting menus and can be done without flash block erase. I probably will not implement flash partitions - no need for that when being able to "incrementally" change the flash without the need to erase flash blocks unless for petty "keeping things in order" purposes .
|
|
|
Post by spiff on Jul 2, 2008 7:54:03 GMT -5
Concerning removing files: Not possible easily due to the flash image format. Proper removing needs erase and reflash (bad for flash lifetime). I'll add the option to change/shorten file names and setting start address to zero though. This hides the corresponding files from starting menus and can be done without flash block erase. It is not easy to reclaim the space (which requires flash erase), but as you know (judging from your statement about shortening filenames), setting bytes to $00 can be done without erase. With TLR's patched kernel, Roland's menu and mine and LarsP's lsmenu, any entries in the $10000 directory starting with $00 are skipped, and reading stops when first seeing an entry starting with $FF (in the filename). So writing $00 as the first character of the filename will effectively "remove" the file from the list, both in the menus, and in TLR's patched kernel. Unfortunately, if this is done with an unmodified kernal, scanning stops when the first $00 entry is reached, which is probably not too good. When I first made dtvmkfs I had the problem that I did not terminate the directory list with $FF, but just one entry of $00 (unless extra space was reserved). This meant that Roland's menu would skip the $00 entry and continue scanning the data area for filename entries, resulting in a lot of garbled filenames at the end of the list. I added a $FF entry, which fixed the problem, and when LarsP and I made lsmenu, we implemented the directory parsing in the same way.
|
|
|
Post by 1570 on Jul 2, 2008 12:04:45 GMT -5
This essentially does not provide any tangible benefit for the user though. The "$" file is still outdated and space not reclaimed; also it's a hack really and certainly not worth the hassle of reflashing the kernal. Still, if you already patched your kernal, then you are of course free to change the names of deleted files to an empty string in DTVFSEdit (which won't work on a stock kernal then though - not so great if you give that image to someone else). I also just changed DTVFSEdit to handle 00 entries. Any takers for implementing the 6502 side of a proper flash-friendly file system as explained on picobay.com/dtv_wiki/index.php?title=DTV_Flash_File_System#DTVFS2? - implementing support for this in DTVFSEdit is simple.
|
|
|
Post by Espen Skog on Jul 2, 2008 14:37:44 GMT -5
Current status of dtvfsedit: - Opens existing flash images and Spiff ZIPs
- Imports/exports PRG files (transparently handling DTV flash compression)
Error handling and UI is very basic so far. Concerning removing files: Not possible easily due to the flash image format. Proper removing needs erase and reflash (bad for flash lifetime). I'll add the option to change/shorten file names and setting start address to zero though. This hides the corresponding files from starting menus and can be done without flash block erase. I probably will not implement flash partitions - no need for that when being able to "incrementally" change the flash without the need to erase flash blocks unless for petty "keeping things in order" purposes . Hey, nice of you to start working on such a tool. I would LOVE that the DTV game repository had a option where one cook roms online too. Is it possible to test your tool ? Espen
|
|
|
Post by spiff on Jul 2, 2008 15:23:20 GMT -5
This essentially does not provide any tangible benefit for the user though. The "$" file is still outdated and space not reclaimed; also it's a hack really and certainly not worth the hassle of reflashing the kernal. Still, if you already patched your kernal, then you are of course free to change the names of deleted files to an empty string in DTVFSEdit (which won't work on a stock kernal then though - not so great if you give that image to someone else). I also just changed DTVFSEdit to handle 00 entries. Well, it should be possible to parse the $-file and create a new one. While this cannot be appended to the existing file, you can just create a new $-file, skipping the old one by setting its name to $00. So I don't agree that it is not possible to alter the filesystem without erase (if the kernel is patched). I originally planned on doing this with dtvmkfs (which is why the -i option exists separate from the -k). But I never got around to it. As for the patched kernel, I use a (slightly modified) version of TLR's kernel loader to load the patched kernel. This is called INTRO, and is thus loaded on startup. The patched kernel loads some other program. This way I don't have to reflash $0000-$FFFF but I still get a patched kernel with some bugs fixed and an optimized palette.
|
|
|
Post by 1570 on Jul 2, 2008 16:13:40 GMT -5
Well, it should be possible to parse the $-file and create a new one. If you are okay with patched kernals anyway, you can simply get rid of the "$" file altogether and implement a proper routine that builds "$" by looking at flash entries. Peiselulli's kernal already does this as far as I can remember. I *think* you can also set the name to something with less "1" bits so renaming "$" to (space) might also be an option that's compatible with stock kernals. Hey, I never said otherwise . The point of DTVFSEdit is to do this - even with stock kernals. Cool. Can you share this? Would also be handy for Jiffy softkernals etc.
|
|
|
Post by spiff on Jul 3, 2008 3:31:57 GMT -5
Cool. Can you share this? Would also be handy for Jiffy softkernals etc. Sure. My patches are: 1) I modified kernelstarter.prg to have a SYS address compatible with the original kernal (I think it must be 2059). 2) Before calling the reset function, I call the screen setup, so the modified palette is loaded. For this to work, a kernel is appended to the prg, and this kernel must be patched to NOT load INTRO, since the combined prg will be called INTRO, which would result in a loop. I used TLR's patched kernal, modified the palette and the string INTRO (changed to DTVB*) with a hex editor. Then my filesystem contains the INTRO (kernel loader) and DTVBOOT (bootstrap based on the original EGGS.PRG, which loads LSMENU). I sent the patched version to TLR, a long time ago, when I first made it. But I can put it up on my page. Don't know if I have time tonight, but otherwise I will try to do it on Friday.
|
|
|
Post by spiff on Jul 3, 2008 4:02:43 GMT -5
I *think* you can also set the name to something with less "1" bits so renaming "$" to (space) might also be an option that's compatible with stock kernals. This is a good idea. The entries can easily be hidden in the menus, since the menus use the sys address for this, which can also be set to 0. But this will only work for the $-file. Other filenames cannot generally be changed into anything other than $00, so without a patched kernal you cannot replace a file (i.e. put in a new file with an existing name) in a general way.
|
|
|
Post by 1570 on Jul 3, 2008 5:06:59 GMT -5
Other filenames cannot generally be changed into anything other than $00 Sure. Just shorten the filename (i.e., replace one or more chars at the end of the filename by zeros). This is possible without flash erase. It's described on picobay.com/dtv_wiki/index.php?title=DTVFSEdit#Changing_an_existing_image see also the second post in this thread . Of course this gives artefacts in the filesystem but this doesn't really matter in practice since nothing of this is visible in the menu (due to the start address being set to 0).
|
|
|
Post by spiff on Jul 3, 2008 5:54:31 GMT -5
Sure. Just shorten the filename (i.e., replace one or more chars at the end of the filename by zeros). This is possible without flash erase. It's described on picobay.com/dtv_wiki/index.php?title=DTVFSEdit#Changing_an_existing_image see also the second post in this thread . Of course this gives artefacts in the filesystem but this doesn't really matter in practice since nothing of this is visible in the menu (due to the start address being set to 0). OK, I understand what you are saying, but when I was saying "generally", I was thinking about a solution that works for ANY file name. Your suggestion will not work for file names that have only 1 character (since shortening it will make it into $00, and therefore not work with unpatched kernals). And if programs use multi-part loading with pattern matching, they may only work with the first n characters, and so not notice the truncated file. For instance my patched kernel loads DTVB* because there were only 5 characters reserved for the filename string in the DTV kernel. The actual program I use is called DTVBOOT, but this will require shortening more than the last character in order to work. As far as I can see, you can NORMALLY delete files by shortening their names, as you describe, but there are special cases that do not work unless the kernel is patched. Therefore it is not easy to make this process automatic. If the kernel is patched you can ALWAYS wipe the entire filename to $00. Of course some programs may use their own routine to parse the $10000 directory, in which case it will not work correctly if it stops upon $00 instead of skipping and stopping at $FF.
|
|
|
Post by 1570 on Jul 3, 2008 7:12:08 GMT -5
I think we can go on with this forever . I just checked: There's not a single file in the whole repository that has a one-char name. Even if this was the case this would need to be fixed as this is broken in the first place (what happens if one game uses the file "1" as level 1, and so does another game I want to put in the flash?). Ah, and for all multifile games in the repository the filenames' last part is significant. There's no "1LEVEL", "2LEVEL", there's only "$FLIMBO.0", "$FLIMBO.1" and so on.
|
|
|
Post by spiff on Jul 3, 2008 7:54:17 GMT -5
I think we can go on with this forever Yes. Let's go on forever I just checked: There's not a single file in the whole repository that has a one-char name. Even if this was the case this would need to be fixed as this is broken in the first place (what happens if one game uses the file "1" as level 1, and so does another game I want to put in the flash?). Ah, and for all multifile games in the repository the filenames' last part is significant. There's no "1LEVEL", "2LEVEL", there's only "$FLIMBO.0", "$FLIMBO.1" and so on. I totally agree, both that there there is no such game in the repository, and that it seems broken if there was. Working on Last Ninja 2 I can say that the filenames are like: 1A.---------- 1B.CENTRAL PARK 2A.---------- 2B.THE STREET etc., and the loader routines load only based on the two first characters and *, e.g load "1A*". Of course I'm changing this, because - as you say - this is broken. But theoretically there is nothing forcing people to only use games from the repository. Someone could make a demo that he wants to load easily with the on-screen keyboard, and therefore call it "1" or something. I know this is quite theoretic, and you can surely just detect this case in the tool, and warn that it is not possible to shorten this filename. Anyways, I have no need to continually update the flash filesystem of the DTV. I'm already soldering on the needed wires for bootstrapping without keyboard, flashing the filesystem, and removing the wires again. Since this discussion is getting sidetracked, and it appears we both know that it is almost possible - I can think of a case that it will not work - and you say that case will never occur (and you are probably right), I think I will stop commenting anymore. The fact is that the original kernel looks for 0 for termination, and it is therefore not possible to remove the termination without re-flashing. And once you have put $00 somewhere in the list, the stock kernel will not read past it. In my opinion this means the kernal does not properly handle updating the $10000 directory without flash erase. If I want to append files to the original DTV filesystem, how could this be done without doing a page erase on the $10000 directory?
|
|
|
Post by 1570 on Jul 3, 2008 11:14:45 GMT -5
Concerning Last Ninja, I hope you consider patching it so that is loads from high memory. Completely forgot about that. Yes, one erase is necessary of course.
|
|