On Tuesday, November 10, 2015 at 5:49:02 PM UTC-5, Pekka Takala wrote:
> I suggest that you do like this:
> 
> -first load a program you are crunching testing.
> -Modify the program so that it actually does not run the program - just
> change it to make poke1,55 and then execute setnam, setlfs and load
> routine with verify flag (c-flag) set. After all, you do _not_ need to
> execute the actual program, just verifying it is enough.
> -Save the name in the program as original.prg and then save the
> _uncrunched_ program with EXACTLY that name.
> -Crunch the program
> -Execute the sfx
> 
So just add a ML VERIFY test code in the SFX after decompressing.  I can do
that!  However, before creating an SFX, I want to use a raw method and compare
the final output to the initial test file.  I can use a batch file to extract
the former from a 
disk image and use VBINDIFF to compare it to the initial input file as one
already in the Windows file system.  I just want a better way.  :)

> If everything goes right, the system, when starting, actually does
> verify to check. If something is wrong, it wont start the verify or the
> verify fails. After all, when your sfx routine starts the program, the
> sfx routine has /no idea/ about that the code does not run a game,
> instead a short verify routine.
> 
> On basic, you accomplish this easily by just setting verify"name",
> on first line and then end. If verify says, that the code is same, then
> it is.
> 
> This requires assembly language knowledge, but the routine is VERY
> short. It takes about 50 bytes including the name. If your sfx routine
> disables roms, you can enable them in your code and test. After all, you
> can use 38 or 50 kilobytes test routines.
> 
I have assembler knowledge.  :)  Once the conmpression works, I plan to convert
the compress/decompress code in DASS assembler.

> I would do things like that. It is _not_ needed to execute the test
> data, your sfx should not know shit about your verify routine. just put
> a simple compare routine there and let it do the thing. If you need more
> exact, then you can write a open - getchr-compare routine and just load
> the file byte by byte and you get the exact place of error.
> 
I'll add the routine during debugging and remove it after.  :)

> If you cannot write a verify routine in a program file that your sfx can
> execute directly after decrunching, then I cannot help. I would use a
> machine language monitor program for thaṭ purpose, after all the code is
> not long.
> 
I can!  :)

--- SoupGate-Win32 v1.05