| |
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.. |
|
... 592 posts hidden. Click here to view all posts....
|
| |
Martin Piper
Registered: Nov 2007
Posts: 646 |
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: 838 |
@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: 838 |
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: 1727 |
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. ;) |
| |
Claus_2015
Registered: Oct 2012
Posts: 53 |
Hi tlr,
I am not sure if I correctly understand your idea with the segments (I guess you are refering to his? The link only jumps to the beginning of the thread). It is more or less splitting memory areas into several parts, with the content being defined (or reserved) at arbitrary places in the source code, correct? How would that help the problem with the nested pseudopcs?
|
| |
tlr
Registered: Sep 2003
Posts: 1727 |
Nested segments can contain different .pc which could be made to allow generating what you want.
Segments aren't strictly necessary but a concept of nestable scopes with different .pc settings will do the trick.
A way of dereferencing a particular label in any of the available scopes would be very useful too. I.e getting the non-virtual address of any virtual label an vice versa. I've suggested that elsewhere.
This of course gets a bit trickier to express with nested virtual .pc. |
| Previous - 1 | ... | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | ... | 61 - Next |
