| |
Slammer
Registered: Feb 2004
Posts: 416 |
Kick Assembler Thread 2
The previous thread took a little long to load, so this is a new fresh one.. |
|
... 590 posts hidden. Click here to view all posts....
|
| |
Conrad
Registered: Nov 2006
Posts: 833 |
Found another possible bug(?)...
I'm using KickAss (version V3.25) on a linux system (SlackoPuppy)... via the commandline:
"java -jar /mnt/sda3/CBM/TOOLS/KickAssembler/KickAss.jar -maxaddr -1 -aom -binfile -o /mnt/sda3/OC_SERVER/CBM/test.crt %f"
("OC_SERVER" is a mounted directory to a shared network drive of my Windwos PC, where WinVice is installed.)
The source I compile should output a large crt (EasyFlash format) which is roughly 129K... but when compiling the output binary through this shared network drive, it outputs around 69K (i.e. loss of file data).
Compiling the binary locally and then copying that file across to the network drive works fine.
I don't know if this is a Linux-Windows issue or not. When mounting the network drive, I use "nounix" and "noserverino" as parameters. |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
>The source I compile should output a large crt (EasyFlash format) which is roughly 129K... but when compiling the output binary through this shared network drive, it outputs around 69K (i.e. loss of file data).
I assume you get no error messages. Since it outputs 69k it seams like you have set the maxAddr correctly.
1. Is the output cut when you compile it normally (no network drive, no binary)?
2. Is the output cut when you compile it as a binary?
3. Is the output cut when you compile it as a binary on the networkdrive?
(Also check if the code reallly should be 69k)
If 1 or 2 fails, i'll need some failing code to see whats wrong.
|
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
Network paths can operate slightly differently to local devices.
This problem can be caused by an unflushed fseek.
Before each fseek do a fflush. A flush before a fclose can also help. |
| |
Conrad
Registered: Nov 2006
Posts: 833 |
@Slammer
Quote:1. Is the output cut when you compile it normally (no network drive, no binary)?
2. Is the output cut when you compile it as a binary?
No, in both of these cases it outputs the full size fine. No errors etc.
Quote:3. Is the output cut when you compile it as a binary on the networkdrive? Yes, I'm executing KickAss from my laptop (linux OS), but the output path is via a network, where this problem occurs. The source code can be stored on either the network side or local side, but there is no difference. There's nothing wrong with my source code on its own.
@Martin: Yes I agree. I remember having this problem with network drives at where I work... having to using some flushing C functions as you mentioned. Maybe the java functions have the same issue? The JRE libraries on Linux might have issues too, but I don't know. |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Try this one, http://www.theweb.dk/KickAssConrad.jar |
| |
Conrad
Registered: Nov 2006
Posts: 833 |
Quote: Try this one, http://www.theweb.dk/KickAssConrad.jar
Thanks Slammer, that one works perfect! :) |
| |
Claus_2015
Registered: Oct 2012
Posts: 53 |
Is there a reason why nested .pseudopc blocks are not allowed in KickAssembler? I stumbled over the problem when trying to relocate a loader (i.e. loading it to $0801 and moving it to $0300 for later use), that contains drive code, which is again in a .pseudopc block.
I would imagine that handling nested pseudopc blocks would be straightforward, as the outer block does not influence the inner block at all, or do I miss something here? |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
I wasn't aware that anybody would do that. It takes some extra management to keep track of all the simultaneous memory positions, so thats why it want implemented in the first place.
|
| |
Claus_2015
Registered: Oct 2012
Posts: 53 |
I would love to see this in an upcoming release. I think only with this feature you can reasonably have pseudopc's in a library, as relocating library code is something that at least I tend to do frequently. And pseudopc's are needed at least for all drive code.
When trying to circumvent this, I created the probably most ugly mess of {}-blocks that mankind has ever been exposed to :-). |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
This old idea I posted would allow for that and more: http://noname.c64.org/csdb/forums/?roomid=11&topicid=26156#44932
Perhaps it won't free you of all braces though. ;) |
| Previous - 1 | ... | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | ... | 61 - Next |
