KTH
Newbie
Posts: 13
|
Post by KTH on Oct 4, 2008 13:05:14 GMT -5
I managed to get Maniac Mansion running on the DTV. I gave Maniac Mansion the same treatment as Zak McKracken: - Disk routines replaced to read disk images from high memory - Swapped joysticks - Keyboard control replaced by routine that scans DTV buttons - Compressed with dtvDexomizer The patched game can be found here: ik2.dk/dtv/dtvDexomizer/ManiacMansion_dtv.zipIt takes a long time to decompress the disk images used by the game. I am considering implementing a lazy decompression scheme, so that the disk track data is first decompressed when accessed for the first time. Spiff, would you be willing to share your custom exomizer code used in Last Ninja 2 for this purpose? For now I made a version with uncompressed disk images, it can be found here: ik2.dk/dtv/uncompressed/ManiacMansion_dtv.zip
|
|
|
Post by spiff on Oct 7, 2008 2:55:21 GMT -5
I managed to get Maniac Mansion running on the DTV. Cool. I need to get up to speed with DTV-related stuff. And updating the repository. So little is missing to have the search capabilities and RSS feed running. Then I will redirect to use the new interface, and I don't have to maintain two parallel databases. I have a few patched games that need to go into the repository, but I have been putting it off for far too long. I have been in the process of moving to a new place, so I have only had my laptop for the past two months. But now I have my normal computer up and running again, so I should be able to fool around with DTV stuff again. Spiff, would you be willing to share your custom exomizer code used in Last Ninja 2 for this purpose? Sure. I will try to dig it out. Be aware that this is not in any DTV optimized (for speed). I have never played with skip+burst etc. What is does is swap the decompression code into one bank, and the decompression source into another, then decompressing 256B at a time and copying this back to the destination. It is really not the most elegant solution, but I wanted a decompressor that can decompress from high memory, but still be used as a level decompressor.
|
|
KTH
Newbie
Posts: 13
|
Post by KTH on Oct 7, 2008 15:11:17 GMT -5
Cool. I need to get up to speed with DTV-related stuff. And updating the repository. So little is missing to have the search capabilities and RSS feed running. Then I will redirect to use the new interface, and I don't have to maintain two parallel databases. Please keep up the good work! Spiff, would you be willing to share your custom exomizer code used in Last Ninja 2 for this purpose? Sure. I will try to dig it out. Cool. This would really be helpful. Be aware that this is not in any DTV optimized (for speed). I have never played with skip+burst etc. Oh, it really speeds the decompression up a lot. Maybe I'm better off using segdecrunch included in dtvDexomizer, but I'm not sure how this works so I'll need some help. From the dtvDexomizer.php script I know that the decompressor that is placed in the $1D4000 range decompresses the data placed from $07F0 and up. I hope that you 1570, can help me with the following questions: Is there anything special with the address $07F0? Is it possible to freely relocate the compressed data? Does the decompressor process the data backwards (does it start from the end?) How is it prevented that the decompressor overrides the data it is about to decompress?
|
|
|
Post by 1570 on Oct 7, 2008 16:53:57 GMT -5
Is there anything special with the address $07F0? No. It's just a bit below $0801, the typical decompressing end address. Yes. Yes - the last compressed byte is fetched from $07F0, the last decompressed byte is written to $0801. No precautions are taken. It's just that when decompressing backwards with a small safety offset at the end ($0801-$07F0) problems are not likely to occur in practice (hack alert ). Adjusting the dtvDexomizer code should be fairly straightforward. Actually the only thing to set up is the position of the first compressed byte to be read - this is indicated in the source code. Everything else is just a matter of getting the correct compressed data. Just look at the PHP script and the C helper and how these call Exomizer. Probably you can just do it exactly the same way. The Exomizer decompressor in the TRSI demo kernal [1] is said to be much faster. Perhaps have a look at that, too. [1] noname.c64.org/csdb/release/?id=63115
|
|
|
Post by spiff on Oct 8, 2008 3:16:34 GMT -5
Oh, it really speeds the decompression up a lot. Maybe I'm better off using segdecrunch included in dtvDexomizer, but I'm not sure how this works so I'll need some help. I still have the exomizer decompressor in a separate source file, and there have not been many modifications to this. So it should be possible to plug in a different version. Basically my code is a wrapper, which when called (replacing the level load routine in Last Ninja 2) will use a table for looking up the starting address of the data, and then decompress the whole thing to low memory. This is done by setting up the segment mapper (which also maps in the exomizer decompression code), then decompressing 256 bytes at a time, and moving this to the needed destination. It is likely possible to make this more flexible, and include the optimizations for the DTV. Previously I have avoided DTV specific code, even if some speed could be gained, but since I use the segment mapper anyways, I might as well use other DTV specific stuff. Oh, and I also use DMA to move the source into high mem. This is done to work around the two holes (DTV color-mem and the kernel flash load filename buffer), so the get_crunched_byte function does not need to do special handling of that. The Exomizer decompressor in the TRSI demo kernal is said to be much faster. Perhaps have a look at that, too. Hmm. I wonder if I could use that also. When I started patching Last Ninja 2, I had to learn some DTV specific stuff, which was of course a nice side effect. But basically what I wanted was to use the code I had already disassembled, and have the pieces compressed. However, my priority was on decompressing the individual levels when they were needed, which also meant that decompression speed was not that critical. After I already spent a lot of time extracting the data needed, I did not want to put this into Vice and make a snapshot. The web-interface for DTV exomizer is nifty if you have a snapshot (i.e. if you do the patching in the Vice monitor), but I don't really like it when decompiling and changing the source. What I needed for this was a Makefile, which would assemble and compress all the parts. I would love to see a more customizable decompressor for the purpose of building applications like this. So far my overall view of DTV patching is that it is difficult to make something that works for all purposes, because the areas where you can stuff in your own code (in the C64 memory space) can be quite different. I would love to collaborate on this, but as you probably all know, I have some other DTV related tasks that I have already put off for too long, and I'm not good at taking time for it But even though I don't have time, I hope others keep going, patching games and sharing code. Thanks for your efforts so far.
|
|
|
Post by 1570 on Oct 8, 2008 7:19:03 GMT -5
After I already spent a lot of time extracting the data needed, I did not want to put this into Vice and make a snapshot. The web-interface for DTV exomizer is nifty if you have a snapshot (i.e. if you do the patching in the Vice monitor), but I don't really like it when decompiling and changing the source. What I needed for this was a Makefile, which would assemble and compress all the parts. I think some things get mixed up here. VICE snapshots are used with vsfReanimator which generates a (runnable) PRG for the DTV. dtvDexomizer is an Exomizer wrapper that behaves more or less like "exomizer sfx" but also works with (large) DTV PRGs - such as the PRGs generated by vsfReanimator. Both vsfReanimator and dtvDexomizer can be called from Makefiles as they support a command line mode, too. dtvDexomizer is not suitable directly for special applications like level decompression really ("exomizer sfx" isn't either). As explained, you can use parts of the dtvDexomizer 6510 code for this purpose though, and if you just rip the 6510 parts from dtvDexomizer and put exomizer calls in your Makefiles everything is fine. This is the way it's done in more or less all projects that use exomizer, too. Nothing special about dtvDexomizer apart from the helper application used to break up data when compressing and the decompression routines that are optimized for the DTV.
|
|
|
Post by spiff on Oct 8, 2008 8:07:54 GMT -5
I think some things get mixed up here. VICE snapshots are used with vsfReanimator which generates a (runnable) PRG for the DTV. dtvDexomizer is an Exomizer wrapper that behaves more or less like "exomizer sfx" but also works with (large) DTV PRGs - such as the PRGs generated by vsfReanimator. Both vsfReanimator and dtvDexomizer can be called from Makefiles as they support a command line mode, too. Sorry, obviously I was the one who messed up here. I guess, what would be useful for me is to replace just the 6510 exomizer decompressor with the optimized code. But perhaps this is not straight forward, because I used the stream decompressor as a basis. Thanks for clearing up the confusion.
|
|
KTH
Newbie
Posts: 13
|
Post by KTH on Oct 9, 2008 13:55:08 GMT -5
Is there anything special with the address $07F0? No. It's just a bit below $0801, the typical decompressing end address. Yes. Yes - the last compressed byte is fetched from $07F0, the last decompressed byte is written to $0801. No precautions are taken. It's just that when decompressing backwards with a small safety offset at the end ($0801-$07F0) problems are not likely to occur in practice (hack alert ). Adjusting the dtvDexomizer code should be fairly straightforward. Actually the only thing to set up is the position of the first compressed byte to be read - this is indicated in the source code. Everything else is just a matter of getting the correct compressed data. Just look at the PHP script and the C helper and how these call Exomizer. Probably you can just do it exactly the same way. Thank you for clarifying this for me. It seems pretty simple to make use of the decompressor. I had a look at this before [1] but couldn't figure out how to make it work. Maybe I should take another look. [1] jledger.proboards19.com/index.cgi?board=dtvhacking&action=display&thread=2573
|
|
|
Post by spiff on Oct 17, 2008 6:22:51 GMT -5
I finally remembered to add Maniac Mansion to the repository: symlink.dk/nostalgia/dtv/fixed/?action=info&id=150I also added some other games that 1570 sent me. Keep up the good work. I have decided to get the repository interface done before I do more patching. Will try to work on that this weekend.
|
|
KTH
Newbie
Posts: 13
|
Post by KTH on Nov 4, 2008 14:50:41 GMT -5
I finally got the TRSI decompressor working. I'm using the Boulder Dash version with the EXO_SPEED_VERSION = 1 option set, see noname.c64.org/csdb/release/?id=66914. I had some problems with the decompressor because it is using the segment mapper (bank 1 and 2) and it apparently can't run from the memory locations $4000-$BFFF nor decompress to these. Maybe Peiselulli can confirm this. The TRSI decompressor is almost twice as fast as the segdecrunch included in dtvDexomizer, so I don't think it is worth the hassle implementing a lazy decompression scheme. The faster and slightly smaller version of Maniac Mansion can be found here: ik2.dk/dtv/TRSI/ManiacMansion_dtv.zipI also made a faster version of Zak McKracken: ik2.dk/dtv/TRSI/ZakMcKracken_dtv.zip
|
|
|
Post by spiff on Nov 8, 2008 20:19:34 GMT -5
The two new versions have been added to the repository.
|
|
|
Post by peiselulli on Nov 12, 2008 8:06:26 GMT -5
The decompressor cannot be run at 0x4000 to 0xbfff, thats true. But it should work decompressing from/to this area, because the reading is done via the blitter and the writing is done via the dma. These uses physical adresses only that aren't influenced by the segment mapper. The Registers $e and $d are not used for the segment mapping feature, they are only used because of using extra registers (like the register $a, too).
|
|