08 July 2020, 10:26 | #41 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,454
|
Yes, definitely. I tested this extensively because originally I couldn't believe it didn't work. It's not a stack problem, it's an RNC problem. Note that it only happened to me on one specific file. All others I've ever used worked without a hitch.
|
08 July 2020, 10:48 | #42 | |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 909
|
Quote:
Can you send me the file that fails? |
|
08 July 2020, 11:30 | #43 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,454
|
Quote:
Anyway, sorry, I don't have that file any more - it's long been overwritten by a newer version |
|
08 July 2020, 11:31 | #44 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,508
|
Could it be only bad unpacker code and not the data intself? (see message on the different decompressor in Heimdall).
Could it be that only one of the two versions of RNC is affected? However, I seem to remember that in the past I also had a file that failed, but that happened too long ago, so I can't provide any precise information or test file. In any case, I haven't used RNC for a long time. Depending on my needs, I use doynamite, nrv2x or arjm7. |
08 July 2020, 14:12 | #45 |
Registered User
Join Date: Nov 2017
Location: france
Posts: 110
|
And you don't have again the source of your nrv2x cruncher ?
a 68000 version of your cruncher will be... great I don't need 'source' of cruncher, et's say i would prefer to crunch my file directly on amiga. So juste 'need' a nrv2x 68000 binary. I like the pc but if I can do all the steps on amiga, it's better. (for me) |
08 July 2020, 15:14 | #46 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,508
|
No, sorry.
Only available for Win platform |
10 September 2021, 07:59 | #47 | |
Registered User
Join Date: Sep 2019
Location: Sydney
Posts: 357
|
Quote:
Hey Ross, is this the latest version of nrv2r? I've been trying it for in-place decompression and it generally works great but I've come across a file that the decompressor fails on. Problem file here. I'm compressing it using: nrv2x.exe -es -k -f -o compressed.dat problem.dat It gives the output: load encoded file at buffer offset 0x0000355A In my code, I allocate 26040 bytes (original file size). I load the compressed file into this buffer + 0x355A. Then I call nrv2x_decoder with the buffer pointer and an offset of 0x355A. Comparing the output, it is trashing just the last 5 bytes. The end of file is changes from: 38 3E 00 00 00 10 to: 38 38 01 e1 b2 00 Using the .exe to decompress works fine, so it seems to be just the Amiga decompressor. Could I be doing something wrong, or is this a possible bug? |
|
10 September 2021, 10:05 | #48 |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,213
|
Are you sure that the compressed file size + 0x355A, is not exceeding the 26040 bytes you allocated ?
|
10 September 2021, 10:34 | #49 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,508
|
Quote:
Code:
nrv2x.exe -es -k -f -o compressed.dat problem.dat nrv2x v2.3, by ross (68k raw data target) compressing file "problem.dat"... upx raw data start at 516, 11381 tokens found 11370 tokens used for the new encoding, 99008 raw bits refactoring for in-place decoding... successful 11369 in-place tokens, 1 from stack, 99047 raw bits input size: 26040 bytes output size: 12381 bytes (padded to 12382 bytes) load encoded file at buffer offset 0x0000355A Code:
buffer ds.b 26040-12382 ds.b 1 incbin compressed.dat Code:
lea buffer,a0 move.l #$355a+1,d0 This: (padded to 12382 bytes)and this: 99047 raw bits== (12381*8-1...) makes me think that I have miscalculated the padding by 1 bit somewhere and therefore it would be enough to simply shift the stream.. Please try the attached compressed.dat, load it at 0x355a (in the same buffer you have) but pass 0x355b to unpacker. If it works I will fix it in the next version Thanks! PS: nrv2x behaves really well with this file. Your raw data zipped in problem.zip is 14226 bytes, output from nrv2x is 12381 bytes! |
|
10 September 2021, 13:24 | #50 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,508
|
Quote:
Code:
nrv2x.exe -es -k -f -t -o compressed.dat problem.dat ... decoding overflow, please report Luckily I left the test code inside And it's just a very rare in-place refactoring bitcode problem, nothing about the general encoding or the decompression code. |
|
11 September 2021, 05:16 | #51 |
Registered User
Join Date: Sep 2019
Location: Sydney
Posts: 357
|
Thanks Ross, I can confirm that with your new file and passing in 0x355B to the unpacker, it works for me.
|
11 September 2021, 09:36 | #52 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,076
|
This brings back memories. It looks like you have figured out to replace the original 32-bit (or even longer, it's been awhile) match offset terminator with a 16-bit one :P. I remember my converter creating a few bytes shorter files than reported here http://eab.abime.net/showthread.php?t=89467 because of that.
UPX compressor likes to create quite some junk at the end, like a literal(!) that's too long, unneeded match, and then finally a match offset terminator. WTH, why not just using a shorter literal, completely skipping the bogus match, and go straight for the terminator?!? Lots of small things to check for no apparent reason . |
11 September 2021, 11:08 | #53 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,508
|
Quote:
But Muzza trashed bytes regard a damn bit that collides and is overwritten by the in-place decompression (due to an unfortunate combination of events, bitcoding is fully right). So I used, in the bugfix release, 1 more token from the stack (i.e. it is no longer directly in the main stream but pre-cached). At the end the file size is (bit) identical, the decompression offset is identical but the bits/byte are shuffled differently. |
|
06 January 2022, 12:31 | #54 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
A bit of thread necromancy, but for a reason!
When working on my Wrath of the Demon release I encountered a problem which was caused by the Rob Norten decruncher. I am referring to the "Mode 2" decruncher which supports decrunching to overlapping source/destination areas. Sometimes, there was graphics trash on screen and I always suspected that it had to do with the ProPack decruncher and after a lot of debugging I finally tracked it down and it indeed was entirely the fault of the decruncher. When the source and destination memory areas overlap, the decruncher temporarily trashes a few bytes (2-4 I think) at the end of the destination area. Once decrunching is done, these trashed bytes will be restored. So far, so (not) good! Because this behaviour can lead to hard to find problems as in the case of WOTD. Directly after the decrunched data, a copperlist followed. Now, if this copperlist was active during decrunching (game uses more than one copperlist in this level and switches them each frame), the first 2 bytes in the copperlist were trashed which in turn caused the screen corruption. If the other copperlist was active, everything was fine. Very annoying problem which took me quite some hours to track down due to the "random" nature. Another case was the game Blastar, here the behaviour of the decruncher caused writes outside the 512k chip memory boundary which isn't exactly nice either. Long story short: If you use the ProPack decruncher with overlapping memory areas, make sure you have a few bytes safety space directly after the end of the decunched data or prepare for trouble! My final conclusion is: "Thank you" Rob Northen... Last edited by StingRay; 06 January 2022 at 12:36. |
06 January 2022, 14:29 | #55 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,508
|
Quote:
I solved it in the most drastic way in my version of WotD: completely removed RNC from it (nrv2x instead) This has brought several advantages, which sooner or later I will make public. |
|
06 January 2022, 15:19 | #56 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
|
26 May 2024, 21:15 | #57 | |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 49
Posts: 203
|
Quote:
I've only had a quick look so far and haven't tested it in depth yet. But what I miss would also be a folder with the different packers as *.asm. (eg Framework/Pack) I had thought about testing something like this: 1.) pack any raw data as input 2.) then unpack back 3.) and compare In ConvertedAssets.cmd it says ‘rnc_pack_x86.exe p %1 %1.rnc1 -m=1’ Is there a Windows64 version of RNC that gives 100% exactly the same result as PPAMI? In my test I had different results when compressing with PPAMI and rnc. But I had the same results with PPIBM under the Dosbox emulator. Edit: I compiled a 64 Bit version from: https://github.com/lab313ru/rnc_propack_source rnc_propack_x64.exe -v -= RNC ProPackED v1.8 [by Lab 313] (01/26/2021) =- Last edited by Rock'n Roll; 28 May 2024 at 14:05. Reason: ProPack 64Bit version |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
"Voices8" 8 Channel Soundtracker "DemoSongI" song - "This is the Amiga with 8 Voices" | DemosongIHunter | request.Music | 45 | 23 May 2022 20:07 |
Is there a place for traditional "Computer Shops" in modern retail? | 005AGIMA | Nostalgia & memories | 34 | 25 March 2022 18:08 |
cannot RNC/propack a given file | jotd | support.Apps | 3 | 27 December 2019 23:25 |
Decrunching protected RNC ProPack | chip | support.Other | 28 | 23 May 2019 15:47 |
RNC ProPack source code? | Dr. MefistO | support.Apps | 4 | 07 June 2018 16:29 |
|
|