| |
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: 245 |
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: 411 |
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: 411 |
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: 411 |
BTW ByteBoiler does not need/use the SCPU when depacking. I just added SCPU-support to the cruncher... |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
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: 728 |
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: 411 |
HCL: So, should we all burn and never use again our Action-Replays, just because they crash when you try reading from $DE00? ;) |
| |
Dosoo
Account closed
Registered: Apr 2002
Posts: 32 |
SCPU seems to raise not only C64's temperature but sceners' temperature aswell... I DID WARN YOU THIS IS SCPU RELATED TOPIC
But back to business.
What comes to extra RAM and things related to that, I haven't even tried of packing 65816 code with these crunchers. I have only packed normal standard (yet amateur) 6510 code. The SCPU is in emulation mode e.g. I have done no mode swapping in my code.
I have to try that nopnopnop -thingie, but still it doesn't explain why the code crashes. Everything works fine with the original code, which I've packed. And everything works fine with the code, where I have removed the first sta $d07a instruction.
Thanks for your comments so far. Maybe I'll try this topic in a more SCPU friendly environment. |
| |
ThunderBlade
Registered: Jan 2002
Posts: 77 |
1) there was a problem in the original Byte Boiler already which caused some problems - sometimes the decrunched data would be partly mess, one particular sequence would always be wrong. I was also working on a SCPU (or previously Flash8) version of Byte Boiler, but did not release it because of this bug. I talked to Skyflash, the real author of the cruncher, about this bug and he explained it to me. It was something with a 16 bit (2 byte) combination, made of the last byte of the file to crunch, and the first byte of the memory after the file to crunch (in the moment the file is loaded by the cruncher!). I could reduce the bug occurance a lot by a random-fill of the memory before loading the file to crunch. However, I did want to fix this bug for real, but before I could, Ninja released his version and I assumed he fixed the bug, although I never tried.
2) Why don't you tell us what IS there, instead of the STA $D07A? Haven't you looked, using a monitor? (i.e. the one built into Virtual Assembler)
|
| |
Dosoo
Account closed
Registered: Apr 2002
Posts: 32 |
I've tried to postpone this reply, but I haven't checked what's there in code. It never came to my mind... I'll check when ever I have time. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
@ninjadrm: Look into your c64 hardware spec.. $de00 is something like "area reserved for future expansion...", so i guess you just have to blame yourself if you use it cause there's really no reason if you have no external hardware connected.
I'm don't know what makes the SCPU fukkup, but there's surely a reason to blame it ;) Still my solution#2 must be the best .D |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
@HCL: You missed the point, before you said: "Does this mean it's a non-compatible hardware to the c64? Then it should be burned..." That applies for the AR, too. Not only with $DE00, remember those "KILL CARTRIDGE"-statements? Don't worry, I don't want to express a "SCPU-is-a-must-have"-opinion. But your argumentation had a little weakness here. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
@Thunderblade: Sorry to disappoint you, but I did not fix this ByteBoiler-bug. Simple reason is, I didn't know it back then. It still never occured to me... |
| |
ThunderBlade
Registered: Jan 2002
Posts: 77 |
It doesn't occur often. Back then, when I exchanged long notes with my contacts, I sometimes crunched the notes to let it fit on the disk. With some crunched files, after decrunching an empty screen of spaces was filled with a different char instead, or a sequence (a written word) had a strange spelling mistake that I didn't type, and this mistake appeared everywhere when the word was used. :) This was with the original Byteboiler already. But as there are so many other compactors available, why bother.
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
@ninjadrm: I think you miss the point that there is a difference between *expansion* and *non compatible*. ARP expands the c64, while scpu obviously makes it buggy :). You can still claim the opposite and be on safe ground.. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
@HCL: I'll just leave it to this. Probably we could fill dozens of pages with this thread. I suggest we keep the discussion for a nice talk on one of the upcoming parties, okay? ;) |
