 Previous Messages |
Posted By
IstvanV
on 2008-02-20
12:15:44
|  Re: Doesn't work with Yape...
The colors are initialized by the routine at $F3B5. In fact, some compressors actually call this, but I do not know why they overwrite the colors in the first place, when there is enough stack space to move the decompressor code after $0123.
|
|
Posted By
SVS
on 2008-02-19
03:01:56
 | Re: Doesn't work with Yape...
I've did the test with KNM Cruncher. Indeed it uses the area $0123... so that the color values result wrong when finished decompression. For this reason it sets read-from-Rom. I've coded my program to reset reading colors from Ram when start. After this only the re-programmed colors work, the other ones have wrong values. To solve this it should need to reprogram all the 16 color-values, or  to find the routine that set them at O.S. initialization.
|
|
Posted By
IstvanV
on 2008-02-16
15:31:36
| Re: Doesn't work with Yape...
The use of ROM or RAM for color codes is controlled by bit 7 of $07F9: if it is 0, then RAM is used.
|
|
Posted By
SVS
on 2008-02-16
14:59:23
| Re: Doesn't work with Yape...
many thanx Istvan for the tips.
The odd thing in KNM compressor is that the colors are not "personalizable" after its decompressing operation. This could be obtained only by setting the O.S. to read color from Rom. This setting is existing somewhere, I remember I've inserted it into my Ultimate-Map.
I'll try to insert a line of code in my prg that make back OS aims the Ram. This in order to verify if what I suppose is true.
|
|
Posted By
IstvanV
on 2008-02-16
05:22:28
| Re: Doesn't work with Yape...
Do you mean the color codes stored at $0113-$0122 should not be overwritten ? Indeed, most compressors do overwrite that area with code. Perhaps the KNM compressor could be modified not to start the code at $0100, but rather from $0123 or above; since it is fairly small, there is probably still enough space left before the end of the stack. Alternatively, if you do not mind using a cross-compressor, you could try the compress.exe program included with plus4emu; for large files, it should have very good compression ratio if used with the -9 flag, although the decompressor is somewhat slow. Memory areas used are $2D-$32 and $9D-$9E (for storing the end address), $0124-$01FF, $0335-$0407, and $0800-$0BFF. I would also have suggested exomizer or pucrunch, but those apparently also overwrite the beginning of the stack, unless there is some way to prevent that that I did not notice.
|
|
Posted By
SVS
on 2008-02-16
04:03:57
| Re: Doesn't work with Yape...
The main probem is to find a compresser able to automatically start the Basic execution just after the decompress operation. Only KNM seems to do it, but it produces codes with wrong colors...
The file I have to compress is from $1001 to $FCFF then either the compresser is residing on low Ram or it should work on disk.
Past years I solved this problem, but I forgot how I did !-/
|
|
Posted By
IstvanV
on 2008-02-15
15:11:24
| Re: Doesn't work with Yape...
What is the reason that prevents other compressors from working ? Does the program to be compressed use a very large memory area, or it needs zeropage variables to be set correctly or not overwritten ?
|
|
Posted By
SVS
on 2008-02-15
14:06:41
| Re: Doesn't work with Yape...
Indeed Istvan the double pass' is the way I use to do.
But there is a problem: it seems that only KNM CRUNCHER is able to run code produced by Austrospeed, after expanded the compressed code, then it has to be the first pass of compressing.
Unfortunately the expanded code of KNM CRUNCHER has false colours, I suspect that it modify the codecolors in Ram (in my program I've reprogrammed them).
For these reasons I tried to compress the executable only with HCS packer...
|
|
Posted By
IstvanV
on 2008-02-15
10:17:13
| Re: Doesn't work with Yape...
You may also try compressing the file with a simple RLE compressor first, and then it is hopefully small enough for the HCS packer. Old Plus/4 programs were usually compressed using similar "two pass" methods.
|
|
Posted By
IstvanV
on 2008-02-15
10:06:42
| Re: Doesn't work with Yape...
It is probably the file length that causes the problem, as I tried this utility (with plus4emu) and it seems to work without any obvious problem. Using cross platform PC to Plus/4 compressors may be preferred anyway for large files, since the compression ratio can be much better.
|
|
Posted By
SVS
on 2008-02-15
07:31:54
| Re: Doesn't work with Yape...
The same is with Plus4emu...
Maybe too long files...I start to think I've achieved the border of this loved black machine.
|
|
Posted By
SVS
on 2008-02-15
07:18:32
| Doesn't work with Yape...
Sorry Gaia, I know you're busy with the baby... 
I've just discovered that "HCS PACKER V9.0", an old compress prg, wants not work under Yape 0.79
I've even set the emulator at Very-High-Compatibility but it seems to enter into a endless loop into 1541 execution (CPU mode). Be informed that HCS PACKER only works with 1541.
By pressing F11 emulator goes into RAM jam.
|
|
