| |
Dosoo
Account closed
Registered: Apr 2002
Posts: 32 |
crunched dreams
This is SuperCPU related, so those unfamiliar with that may not want to read this.
Ever since I purchased my SCPU128 I have often used sta $d07a as first instruction in my code if I code normal 6510 stuff. That turns SCPU to slow mode and indeed, that what it does.
However, if I for some reason use cruncher to pack that ready code I have figured, that the computer usually jams. After some debugging I isolated the problem to the first instruction. E.G. in byte boiler SCPU version if I put $5000 as start address the packed version didn't start. Then I tried $5003 and everything worked ok, but SCPU was in high speed.
Have you encountered such thing. I have used Byte Boiler and Cruncher AB with same result. For that reason I had to leave my Christmas demo back in 2002 unpacked as it wouldn't start after I packed. Spooky... |
|
| |
iopop
Registered: Dec 2001
Posts: 317 |
Would the scpu go into slow mode if you do LSR $D07A / INC $D07A ? ie. only a read/write of that adress puts the scpu into slow mode?
Does byteboiler scpu version use the scpu during decrunch? Maybe you need a little delay between the slowmode changes.
I dont have any scpu and Im just bored.. :/ |
| |
6R6
Registered: Feb 2002
Posts: 244 |
SCPU doesnt like illegal opcodes or crunchers / packers that do wrap-around stuff. i.e. sta $ffc0,x which will be written to $00xx on a standard c64, but scpu wraps it to $100xx.
(I dont have a scpu, i'm just telling stories.) |
| |
Ninja
Registered: Jan 2002
Posts: 407 |
Hmm,strange. ByteBoiler worked fine so far for me. At least V1.1 and V1.3. Did you use one of those versions? |
| |
Dosoo
Account closed
Registered: Apr 2002
Posts: 32 |
Some corrections must be made.
There is nothing wrong with the crunching itself. The cruncher works fine (I've used Byte Boiler 1.3). There are no problems with illegal opcodes, as everything works fine when I remove the first opcode. And as far as I'm concerned, SCPU registers are "write sensitive" as the manual says. So only writing to the registers matter, not the value.
I think ByteBoiler uses SCPU when depacking, but since it doesn't start the code until everything is depacked, I don't understand how a delay would do any difference when entering slomo.
I know there are only few SCPU users, but am I only one with these kind of problems? |
| |
Ninja
Registered: Jan 2002
Posts: 407 |
So, what happens when your code starts with three NOPs at $5000 before the STA-command? (Just to make sure: $01 and I-Flag are set properly?) |
| |
Ninja
Registered: Jan 2002
Posts: 407 |
BTW ByteBoiler does not need/use the SCPU when depacking. I just added SCPU-support to the cruncher... |
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
illegal opcodes are the main reason for me reworking Abuze Crunch 3.2/Abyss Connection. It also had some old remnants left in. I have since learned that some other crunchers may offer better returns but I sometimes still use it because I can change elements of it (never like ones that forward decrunched as they normally overwrite after program).
How about adding 3 NOPs to the start code and then sta $d07a? (write triggered, not data triggered) then jmp $5003 to start it? Or NOP first 3 where the sta $d07a happened. Maybe decrunch bugs? Or crunch bugs?
Another trick I sometimes used was load in crunched programs, change the jmp addy in decruncher to $0334 and at $0334 have something like sei, lda #$37, sta $01, inc $d020, jmp the inc. then I would jump to the AR which is a bit hard with SCPU. Any monitors that can run from different bank? (hope you have extra RAM) then maybe have a check for space and jump to monitor.
To be honest, I have no idea what is causing your problems :( |
| |
iopop
Registered: Dec 2001
Posts: 317 |
You should try to crunch with TimeCruncher v5.0 or some similiar low complexity cruncher. If you get the same problem then its your code otherwise its the cruncher in combination with your file. Both AB and ByteBoiler can crash at some form of data. What kind of data is a rather uninvestigated area.
|
| |
HCL
Registered: Feb 2003
Posts: 717 |
I don't see why AB or ByteBoiler would crash your scpu, but neither i'm god, nor i have a scpu. I would naturally look at the problem from another aspect: What is wrong with the scpu since it crashes?!? Does this mean it's a non-compatible hardware to the c64? Then it should be burned and noone should ever be allowed to use it again!! Waste it!
Solution #2: Use ByteBoozer instead! What do you think iopop? ;) |
| |
Ninja
Registered: Jan 2002
Posts: 407 |
HCL: So, should we all burn and never use again our Action-Replays, just because they crash when you try reading from $DE00? ;) |
... 9 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
