KTH
Newbie
Posts: 13
|
Post by KTH on May 7, 2008 15:41:11 GMT -5
Hi all I bought a DTV a couple of months ago, when I noticed it was running out of stock. The DTV was flashed with my favorite games from Spiff's repository, but Zak McKracken was unfortunately missing. With good help from the C64 DTV Hacking Wiki I started patching the game and here is what have been done so far: Disk routines replaced to read disk images from high memory Swapped joysticks Keyboard control replaced by routine that scans DTV buttons Added a basic stub using exomizer sfx What I would like to do is use dtvDexomizer and maybe use it to compresses the disk images as well. Does a makefile or instruction to how build and use dtvDexomizer exist? Is dtvDexomizer suitable for programs without a basic stub (Zak loads at $400)? Can it decompresses to high memory? It there a way to disable output when doing a DTV kernal LOAD? It corrupts the program by writing "LOADING" to the screen. The patched game can be found here: ik2.dk/dtv/uncompressed/ZakMcKracken_dtv.zip
|
|
|
Post by 1570 on May 8, 2008 5:05:09 GMT -5
Sounds cool! :-)
An efficient way to convert multifile games is to put everything in one large DTV PRG, replacing loading routines by routines that fetch data from high memory (remove decompression routines if there are any) and compress the resulting file with dtvDexomizer instead. This way, there's a small delay due to decompression when starting the game but after that everything will "load" more or less without delay. Also, this way compression efficiency is higher compared to other approaches.
You said you replaced disk routines with routines that fetch data from high memory; if you already did this, I don't quite understand why you have trouble with DTV kernal LOAD...? Why/for what do you still use it? AFAIR ZMK reads not files but sectors from disk...? Do you use kernal load to load one disk images to high memory at one time? I'd propose to just put all disk images into memory concurrently and change the starting pointer for "changing" disks then.
dtvDexomizer is suitable for programs loading to $0801 and starting via RUN currently. Docs are available at the beginning of its source file. The only other thing you need to do is compiling the segcrunch helper program.
In any case, if you send the file you want to compress to me, I can compress it.
|
|
|
Post by nojoopa on May 8, 2008 12:31:14 GMT -5
It there a way to disable output when doing a DTV kernal LOAD? It corrupts the program by writing "LOADING" to the screen. Have you tried LOAD&RUNing the game manually? If it fixes the problem, try replacing the sys address in "index.txt" with 256.
|
|
KTH
Newbie
Posts: 13
|
Post by KTH on May 8, 2008 14:50:40 GMT -5
Yes, that is correct. I have added three files to the flash file system:
ZAK MCKRACKEN program from the boot disk (residing form $400 to $A000 after decompression) ZAKSIDE1 disk 1 image (load address is $20000) ZAKSIDE2 disk 2 image (load address is $50000)
The disk drive initiation routine in ZAK MCKRACKEN was replaced to load the disk images instead. That is why I am having trouble with DTV kernal LOAD. Maybe I should point out that the file I linked to should work. I "solved" the issue by including a DTV kernal LOAD routine with output removed.
I have not seen a memory map for the DTV but I seem to recall that the DTV kernal uses some memory locations in the $10000 range, that is why I placed the first disk image at $20000. The second disk image was placed at $50000 to reuse the calculation of the sector location in memory. I did that and placed the exomizer 2.0 beta4 executable in the same folder. I also compiled dtvDexomizer-segdecrunch.asm and renamed the output to decompressor.prg, is this OK?
|
|
|
Post by spiff on May 9, 2008 15:34:35 GMT -5
Cool. ;D
Tell me when it is done, and I'll add it to the repository.
|
|
|
Post by 1570 on May 11, 2008 12:05:44 GMT -5
ZAK MCKRACKEN program from the boot disk (residing form $400 to $A000 after decompression) ZAKSIDE1 disk 1 image (load address is $20000) ZAKSIDE2 disk 2 image (load address is $50000) It's probably easiest to arrange it this way in VICEplus/x64dtv (zero memory before), save a .vsf snapshot, and use vsfReanimator to create a DTV .prg then (which can be compressed with dtvDexomizer). You need to use the SVN version of vsfReanimator for this though (the online version currently handles only x64 snapshots without high memory). This way you don't need to write any further code and end up with only one .prg. Con is that decompression will take a bit longer than necessary since empty areas get decompressed, too. picobay.com/dtv_wiki/index.php?title=DTV_Programming#RAM_LAYOUTNote that large programs loaded by kernal load get garbled somewhere at $01xxxx due to kernal load using that memory as temp space. vsfReanimator and dtvDexomizer take care for this though. Does it work? :-)
|
|
KTH
Newbie
Posts: 13
|
Post by KTH on May 12, 2008 14:09:52 GMT -5
It's probably easiest to arrange it this way in VICEplus/x64dtv (zero memory before), save a .vsf snapshot, and use vsfReanimator to create a DTV .prg then You are properly right. Actually I was trying to avoid freezing the game to keep it as small as possible. You need to use the SVN version of vsfReanimator for this though (the online version currently handles only x64 snapshots without high memory). I got it, when I run it the resulting output file is only about 67kb. Do I need a special version of VICE plus (got v1.0-1.22) No, I get a "?SYNTAX ERROR IN 0" when I run a dexomized program. I will try to debug it to see what is going on.
|
|
|
Post by 1570 on May 12, 2008 16:50:23 GMT -5
I got it, when I run it the resulting output file is only about 67kb. Do I need a special version of VICE plus (got v1.0-1.22) VP 1.0 is correct (I haven't checked whether vsfReanimator works with the new VP 1.1 x64dtv - it's possible that it doesn't since the snapshot format changed). Unless specified no highmem will be included in the freezed file. If you use a x64dtv VSF as input, just specify the number of bytes above $00ffff to include in the output as fourth parameter of vsfReanimator (forgot to document this).
|
|
KTH
Newbie
Posts: 13
|
Post by KTH on May 17, 2008 14:01:55 GMT -5
I got the dtvDexomizer to work. It turned out that the DASM version I was using did not compile properly. 1570, what version of DASM do you use? I also had to remove "./" from the exec("./segcrunch ... line in dtvDexomizer.php (I am running Windows).
To speed the decompression up, I will try placing the disk images at $10000 and remove the gap between the them. Next I will add some screen notes, how can these easiest be made?
|
|
|
Post by 1570 on May 17, 2008 16:17:51 GMT -5
I use DASM V2.20.09 (no special reason behind that).
For adding a decompression screen just write to the screen in VICE, save screen mem to a file from VICE monitor, and give that file as parameter 3 to dtvDexomizer.
BTW it might be possible to decrunch with gaps quickly - segcrunch seems to support this. Running segrunch manually ("segcrunch -c3 lowmem midmem highmem screenfile -o result") and changing dtvDexomizer.php to use the result file might work.
|
|
KTH
Newbie
Posts: 13
|
Post by KTH on May 19, 2008 13:55:40 GMT -5
For adding a decompression screen just write to the screen in VICE, save screen mem to a file from VICE monitor, and give that file as parameter 3 to dtvDexomizer. I saved the screen memory ($400 to $7E0) and used that with dtvDexomizer, it works, but the colors are messed up. How can I initialize the color memory? BTW it might be possible to decrunch with gaps quickly - segcrunch seems to support this. Running segrunch manually ("segcrunch -c3 lowmem midmem highmem screenfile -o result") and changing dtvDexomizer.php to use the result file might work. This works, but only made the decompression a little faster. It takes about 35 seconds now, in comparison it takes about 15 seconds to load the uncompressed disk images.
|
|
|
Post by 1570 on May 19, 2008 14:47:12 GMT -5
it works, but the colors are messed up. How can I initialize the color memory? Color memory is located at $01d800 and used for crunched data (for long files). Nothing you can do (easily) about that. I take it the weird colors occur only on LOAD/decompression, not after that? The built-in LOAD decompressor is quite fast but not very efficient space-wise. Replacing the dtvDexomizer decompressor code with the 2008 Odyssey version (see CSDb) might be worthwhile. I'm too lazy for that though ;-).
|
|
KTH
Newbie
Posts: 13
|
Post by KTH on May 20, 2008 14:02:13 GMT -5
I take it the weird colors occur only on LOAD/decompression, not after that? Yes, the colors look fine in the game. I guess I have to drop the screen notes. Replacing the dtvDexomizer decompressor code with the 2008 Odyssey version (see CSDb) might be worthwhile. I had a look at the tRSi-demo-kernal source, it looks really nice. Maybe I could use that instead of dtvDexomizer, this would require some work though.
|
|
|
Post by 1570 on May 20, 2008 15:49:15 GMT -5
It should be possible to use the trsi decompressor code with dtvDexomizer with some minor modifications. dtvdexomizer.php cares for a lot of things (patching memory areas corrupted by LOAD or colormem, rearranging memory so that the compressed data is one continuous block, copying decompression routine to high mem and mapping it into lower mem...) the trsi decompressor code (which is only the core algorithm I think?) doesn't handle at all.
|
|
|
Post by peiselulli on May 21, 2008 15:13:38 GMT -5
Yes, it is only the core and it does not support literals (important note for packing). Maybe I should write a version that support literals in future, but the space that support of literals saved was not worth the effort of coding for our demo.
BTW., don't forget to add following in your code before starting the depacker function :
sei lda #$7f ; disable standard irq because it only saves a, x and y sta $dc0d ; (the depacker uses other registers of the register bank, too) lda $dc0d lda #$01 ; disable colorram fetches sta $d03f ; (coloram fetches are for DMA equal badlines for CPU) lda #$30 sta $d03c
... call to depacker
|
|