Closed hoit closed 4 years ago
Ok, multiple questions. I hope I don't miss any of them. :)
I don't know about what data is overwriting who, but could it be something from the VBlank as no section is mentioned in the overwrite warning?
""Unresolved reference to "__nmi_handler" but it seems to be correct in crt0_snes.asm file."
"__nmi_handler" seems to be a local label. Remove the two underscores from the beginning of it and it might just work (from label and the references).
Here's a quote from (old) WLA's documentation:
"3.3. Labels
Labels are ordinary strings (which can also end to a ':'). Labels starting with "_" are considered to be local labels and do not show outside sections where they were defined, or outside object files, if they were not defined inside a section."
Slot is an area in the CPU's memory. If you have an architecture where you can switch ROM banks in address $0000-$3fff, then define $0000-$3fff as a slot. If you have RAM in $f000-$ffff then define that area also as a slot.
Libraries are collections of code &/ data that you can directly reuse in multiple projects. Objects should be used for everything else. And nothing forbids you from compiling everything as objects. :) I could also be said that library support in WLA DX is not worth the effort as they bring very little to the table...
In this case you could write
.ORGA $8000
if that's what you'd like to do. Check out the documents for .ORGA...
Hope this helps!
Yes thanks, it is more clear but more complicated that i thought.. Replace __nmi_handler by nmi_handler works but wlalink fail after on
E:\pvsneslib\lib\crt0_snes.obj: crt0_snes.asm:251: PARSE_STACK: Unresolved reference to "__endsection.data".
It is not declared in this file but in tcc65816 (tiny c compiler) which use its own version of wla (the old 9.4 and never updated). (i think it will be the same for others xxxxx like endsection...) In old sources, i found in write.c (from wla dx folder) part which generate labels startramsection and endramsection but it seems to be different in latest version. Is it linked to [ramsections] in linkfile ?
I hope that the first step for me is not to update tcc with the latest version of wla :(
You cannot link together objects / libraries compiled with WLA v9.4 and v9.8... The file formats have changed a lot between those versions. Version 9.4 is now 11 years old. :D
If you have a label that starts with "__", then it is not visible outside the section / file where it was defined. Not any more with v9.8...
I'm sorry. I don't know all the details, but it is very, very possible that you'll need to make a version of tcc65816 that uses the latest WLA DX v9.8...
Ok, i will try to update wla dx in tcc816 to see if it solve something but i need to analyse code and understand how it works.
Great! Let us know asap if you hit any problems, and also if you succeed in making the upgrade. :)
In fact, i just build tcc816 (in snes-sdk) by replacing wla_dx folder by the new one with few adaptations in makefiles. I am on Windows and it seems to be less hard than i thought. it is not clear and a lot of folders seems no more usefull or unused in snes-sdk but i let them for now.
It strange, because in snes-sdk\trunk\libs folder, crt0_snes.asm file is provided and has been build (i have crt0_snes.obj). This is the original file (with __nmi_handler) and i didn't got errors like in my 1st message (i guess that functions will be called only to compile a game).
So i replaced tcc exe by the new one in PVSneslib folder (which should use the latest version of wladx), crt0_snes.obj by the new in lib folders and try to build hello_world :
it fails because of "__nmi_handler". I removed the 2 underscore and i finally get :
E:\pvsneslib\lib\crt0_snes.obj: crt0_snes.asm:251: PARSE_STACK: Unresolved refer ence to "__endsection.data". make: *** [/e/snes-examples/hello_world/hello_world.sfc] Error 1
This issue directly comes from crt0_snes.asm. I think that upgrade of wladx on tcc816 will be usefull later but it is not the cause of my issue here.
I don't know how to update crt0_snes.asm (i don't know asm!) to remove all "" (endramsectionram, endramsection, startramsection).
Does anybody can help me to update it ? In parallel, i am looking on forums :)
If you could zip/rar the required folders and put that on the net, or email me it ville dot helin at gmail dot com, I could try to take a look at it (latest on Saturday, I'm moving to a new home tomorrow morning)... Please also give me instructions of what to do! :)
I have Windows 10 and Cygwin installed...
I sent it yesterday by email, i hope i won't be in your junk mail :)
Thanks, I got it! I just finished moving into a new apartment, I'll start looking at this later today...
On Fri, May 10, 2019 at 6:58 PM RetroAntho notifications@github.com wrote:
I sent it yesterday by email, i hope i won't be in your junk mail :)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vhelin/wla-dx/issues/232#issuecomment-491340133, or mute the thread https://github.com/notifications/unsubscribe-auth/ABQ62USIBNEPY7KIQDPJGETPUWLUDANCNFSM4HK3YOWA .
I got the sources from https://code.google.com/archive/p/snes-sdk/source/default/source and then replaced the wla_dx directory with the latest 9.8a... The I issued "make", and it compiled WLA DX ok, but then ends as follows:
... make[1]: Entering directory '/cygdrive/v/snes-sdk/trunk/tcc-65816' make[1]: '816-tcc' is up to date. make[1]: Leaving directory '/cygdrive/v/snes-sdk/trunk/tcc-65816' cd libs && make PREFIX=/usr/local/snes-sdk make[1]: Entering directory '/cygdrive/v/snes-sdk/trunk/libs' ../tcc-65816/816-tcc -I. -I../tcc-65816/include -o libm_c.pasm -c libm_c.c make[1]: [Makefile:5: libm_c.pasm] Aborted (core dumped) make[1]: Deleting file 'libm_c.pasm' make[1]: Leaving directory '/cygdrive/v/snes-sdk/trunk/libs' make: *** [Makefile:14: libs] Error 2 ...
So in fact ../tcc-65816/816-tcc crashes.
...
ville@DESKTOP-EDMJKER /cygdrive/v/snes-sdk/trunk/libs $ gdb GNU gdb (GDB) (Cygwin 8.1.1-1) 8.1.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) file ../tcc-65816/816-tcc Reading symbols from ../tcc-65816/816-tcc...done. (gdb) run -I. -I../tcc-65816/include -o libm_c.pasm -c libm_c.c Starting program: /cygdrive/v/snes-sdk/trunk/tcc-65816/816-tcc -I. -I../tcc-65816/include -o libm_c.pasm -c libm_c.c [New Thread 12136.0x1e78] [New Thread 12136.0x4d44] [New Thread 12136.0x39d0] [New Thread 12136.0x3c98]
Thread 1 "816-tcc" received signal SIGABRT, Aborted.
0x0000000100401441 in tcc_free (ptr=
Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) l 960 static inline void tcc_free(void ptr) 961 { 962 #ifdef MEM_DEBUG 963 mem_cur_size -= malloc_usable_size(ptr); 964 #endif 965 free(ptr); 966 } 967 968 static void tcc_malloc(unsigned long size) 969 {
...
I tried to compile it with -O0 and -DMEM_DEBUG, but got no more information (in fact got less for some reason)...
You mention many .rar files in your email. Where can I download them? They are not attached to the email...
If I comment the free() away (make tcc to leak memory a lot, I guess) 816-tcc doesn't crash and I can move on... :) More later.
Ok, got a little bit further:
ville@DESKTOP-EDMURKLS /cygdrive/v/snes-sdk/trunk/libs $ make ../wla_dx/binaries/wla-65816 -i -o libm.obj libm.asm ../wla_dx/binaries/wla-65816 -i -o libtcc.obj libtcc.asm ../tcc-65816/816-tcc -I. -I../tcc-65816/include -o libc_c.pasm -c libc_c.c make: *** [Makefile:5: libc_c.pasm] Segmentation fault (core dumped)
ville@DESKTOP-EDMURKLS /cygdrive/v/snes-sdk/trunk/libs $ gdb GNU gdb (GDB) (Cygwin 8.1.1-1) 8.1.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-cygwin". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) file ../tcc-65816/816-tcc.exe Reading symbols from ../tcc-65816/816-tcc.exe...done. (gdb) run -I. -I../tcc-65816/include -o libc_c.pasm -c libc_c.c Starting program: /cygdrive/v/snes-sdk/trunk/tcc-65816/816-tcc.exe -I. -I../tcc-65816/include -o libc_c.pasm -c libc_c.c [New Thread 15612.0x2e24] [New Thread 15612.0x1460] [New Thread 15612.0x2820] [New Thread 15612.0x1f08] [New Thread 15612.0x43c8] [New Thread 15612.0x3020]
Thread 1 "816-tcc" received signal SIGSEGV, Segmentation fault. 0x000000010040bcaa in sym_push (v=2228285, type=0xffffc3a0, r=0, c=0) at tcc.c:1715 1715 ts = table_ident[(v & ~(SYM_STRUCT)) - TOK_IDENT]; (gdb) bt
...
To my eye tcc is pretty buggy. Have you tried to contact its author, Fabrice Bellard? I have no idea of tcc's code, so I'm not sure I can make this work...
I uploaded files here : trunk.rar : http://s000.tinyupload.com/?file_id=02371891205245714524 lib.rar : http://s000.tinyupload.com/?file_id=31333585284359941073 hello_world.rar : http://s000.tinyupload.com/?file_id=24688188881016047065 devkitsnes.rar : http://s000.tinyupload.com/?file_id=84318916626047766667
tcc seems to be more easy to build with msys. It is available in trunk.rar as exe but i think you don't need it. Fabrice Bellard doesn't maintain tcc anymore. The port for tcc65816 has been developed by an other person who never continue the project ! I think error comes only from crt0_snes.asm file. You can see it in hello_world.rar. But to build hello_world, dependencies are in lib.rar and devkitsnes.rar.
To try it, i think it will be more easy if you merge libs and hello_word files then you wla/wlalink them to see result. I need to clean code to create a minimal code...
ok, should be more clear now :)
Forget all previous .rar files, I merged all necessary dependencies to build the hello_world here : http://s000.tinyupload.com/?file_id=76826166167718687994
There are a lot of asm files (which often comes from .c files from PVSneslib that are converted with tcc816).
One file is crt0_snes.asm and has been written in asm directly. It worked with wla 9.4 but failed during wlalink with wla 9.8. The first error was :
crt0_snes.obj: crt0_snes.asm:205: PARSE_STACK: Unresolved refer ence to "__nmi_handler".
it has been solved by renaming __nmi_handler to nmi_handler
The second error : crt0_snes.asm:251: PARSE_STACK: Unresolved reference to "__endsection.data".
So i tried the same thing, remove "" when variable start with (endsection, startsection, endramsection and __startramsection)
but it produce
crt0_snes.obj: crt0_snes.asm:251: PARSE_STACK: Unresolved reference to "endsecti on.data".
I think there are new rules in wla 9.8 and the file need some modifications.
Initial crt0_snes.asm file is available here : https://github.com/alekmaul/pvsneslib/blob/master/pvsneslib/source/crt0_snes.asm
Works here 100%:
ville@DESKTOP-EDMTVDH /cygdrive/v/hello_world $ ../wla-dx-master-2/binaries/wla-65816.exe -v -o crt0_snes.o crt0_snes.asm Pass 1... Directive checks... Internal pass 1... Internal pass 2... Free space at $0000-$0090. Free space at $00b7-$7fb1. Free space at $7fb6-$7fbf. Free space at $7fdc-$3ffff. Bank 00 has 32698 bytes (99.79%) free. Bank 01 has 32768 bytes (100.0%) free. Bank 02 has 32768 bytes (100.0%) free. Bank 03 has 32768 bytes (100.0%) free. Bank 04 has 32768 bytes (100.0%) free. Bank 05 has 32768 bytes (100.0%) free. Bank 06 has 32768 bytes (100.0%) free. Bank 07 has 32768 bytes (100.0%) free. 262074 unused bytes of total 262144. Total 262144 additional bytes (from headers and footers). Total size 524288 bytes.
Or is your linking failing? I don't really know what you are doing, what commands you are running. "make" gives me this:
$ make Makefile:12: *** "Please create an environment variable DEVKITSNES with path to its folder and restart application. (you can do it on windows with <setx DEVKITSNES "/c/snesdev/">)". Stop.
... and I don't know how to define DEVKITSNES.
ville@DESKTOP-EDMTVDH /cygdrive/v $ li total 10304 dr-xr-x---+ 1 ville ville 0 Jan 13 2017 '$RECYCLE.BIN'/ drwxrwx---+ 1 Administrators ville 0 May 11 00:21 ./ dr-xr-xr-x 1 ville ville 0 May 11 00:40 ../ drwxrwx---+ 1 ville ville 0 May 11 00:37 hello_world/ drwxrwx---+ 1 ville ville 0 Nov 19 2017 Ideas/ drwxrwx---+ 1 ville ville 0 Mar 18 2016 snes-sdk/ drwxr-x--- 1 Unknown+User Unknown+Group 0 Jan 19 2018 'System Volume Information'/ drwxrwx---+ 1 ville ville 0 May 6 19:56 Unity/ drwxrwx---+ 1 ville ville 0 May 6 20:13 'Unity Projects'/ drwxrwx---+ 1 ville ville 0 Apr 28 20:38 wla-dx-master/ drwxrwx---+ 1 ville ville 0 May 11 00:36 wla-dx-master-2/ -rwxrwx---+ 1 ville ville 2764933 Apr 28 19:55 wla-dx-master-before-branch.rar -rwxrwx---+ 1 ville ville 2557377 Mar 10 15:49 wla-dx-master-old-1.rar -rwxrwx---+ 1 ville ville 2565660 Mar 10 19:44 wla-dx-master-old-2.rar -rwxrwx---+ 1 ville ville 2612364 Mar 10 20:11 wla-dx-master-old-3.rar
/cygdrive/v/wla-dx-master-2 has the latest WLA DX v9.8a /cygdrive/v/hello_world has your hello_world
It will be more easy if you use the rar i uploaded from my previous message ( this one : http://s000.tinyupload.com/?file_id=76826166167718687994 )
I removed makefiles and only joined COMMAND_LIST.txt which gives command i used.
yes, wla-65816.exe -v -o crt0_snes.o crt0_snes.asm works correctly, it is the linking command which failed and gave :
crt0_snes.obj: crt0_snes.asm:251: PARSE_STACK: Unresolved reference to "endsecti on.data".
because i already removed the "" for endsection, startsection, endramsection and startramsection. The previous version with the double "" failed too.
The initial version of the file is available here : https://github.com/alekmaul/pvsneslib/blob/master/pvsneslib/source/crt0_snes.asm
Ok, now I got it, how to test this thing... :)
It seems that v9.4's WLALINK generates (wlalink/write.c) labels for section start and end.
/* generate labels for section (group) start and end
(not for text sections) */
if(strncmp(s->name,".text", 5)) { //totalsections > 1) {
struct label* l = malloc(sizeof(struct label));
sprintf(l->name, "__startsection%s", s->name);
l->file_id = s->file_id;
l->file_id_source = s->file_id_source;
l->linenumber = 0;
l->rom_address = s->address;
l->section = s->id;
l->section_status = s->status;
l->bank = s->bank;
l->base = s->base;
l->slot = s->slot;
l->status = LABEL_STATUS_LABEL;
l->address = s->address;
add_label(l);
struct label* ll = malloc(sizeof(struct label));
*ll = *l;
sprintf(ll->name, "__endsection%s", s->name);
ll->rom_address = sa[p+j-1]->address;
ll->address = sa[p+j-1]->address + sa[p+j-1]->size;
add_label(ll);
}
... but only for SUPERFREE sections? It is very possible that such a feature was added by the author of tcc or someone else as the code is not ANSI C89 and doesn't look like at least what I'd do...
I could add such a feature to WLA DX, but I need to think about it first. Perhaps the best place to add those labels is the assembler, not the linker? A new flag (-X) that enables the label generation?
Ok, if you now give -x flag to the assembler, it'll create SECTIONSTART[section name] and SECTIONEND[section name] labels for each section - that should do the trick.
Let us know if there are any more problems!
I was not very clear with my explanations :) Cool, thanks a lot, you are very reactiv. I was no here today but i will try it quickly.
Bad news :( I tried to generate crt0_snes.obj with this command: wla-65816 -x -v -o crt0_snes.obj crt0_snes.asm
then link all files :
wlalink.exe linkfile test.sfc i i already have unresolved reference :
E:\snes-examples\hello_world>wlalink.exe linkfile test.sfc crt0_snes.obj: crt0_snes.asm:251: PARSE_STACK: Unresolved reference to "__endsecti on.data".
or if i remove the double "" (like for nmi_handler) :
E:\snes-examples\hello_world>wlalink.exe linkfile test.sfc crt0_snes.obj: crt0_snes.asm:251: PARSE_STACK: Unresolved reference to "endsecti on.data".
In fact, i am not really sure where i need to appli -x parameter. In crt0_snes.asm, the function which produce error is tcc__start and i saw its name only in hdr.asm ( under .SNESEMUVECTOR section).
I also tried to apply -x parameter to all files to see the result but seems to be the same with some others errors :
E:\snes-examples\hello_world>wlalink.exe linkfile test.sfc
libc.obj: libc_c.asm:436: TRY_PUT_LABEL: Label "SECTIONSTART_.text_0x0" was defi
ned more than once.
libc.obj: libc_c.asm:250: TRY_PUT_LABEL: Label "SECTIONEND_.text_0x0" was define
d more than once.
libc.obj: libc_c.asm:12433: TRY_PUT_LABEL: Label "SECTIONSTART_ram.data" was def
ined more than once.
libc.obj: libc_c.asm:12451: TRY_PUT_LABEL: Label "SECTIONEND_ram.data" was defin
ed more than once.
libc.obj: libc_c.asm:12451: TRY_PUT_LABEL: Label "SECTIONSTART_.data" was define
d more than once.
libc.obj: libc_c.asm:12451: TRY_PUT_LABEL: Label "SECTIONEND_.data" was defined
more than once.
libc.obj: libc_c.asm:12451: TRY_PUT_LABEL: Label "SECTIONSTART_.rodata" was defi
ned more than once.
libc.obj: libc_c.asm:12464: TRY_PUT_LABEL: Label "SECTIONEND_.rodata" was define
d more than once.
libc.obj: libc_c.asm:12464: TRY_PUT_LABEL: Label "SECTIONSTART_.bss" was defined
more than once.
libc.obj: libc_c.asm:12497: TRY_PUT_LABEL: Label "SECTIONEND_.bss" was defined m
ore than once.
libm.obj: libm.asm:45: TRY_PUT_LABEL: Label "SECTIONSTART_.fp" was defined more
than once.
libm.obj: libm.asm:17: TRY_PUT_LABEL: Label "SECTIONEND_.fp" was defined more th
an once.
crt0_snes.obj: crt0_snes.asm:251: PARSE_STACK: Unresolved reference to "__endsec
tion.data".
Should i use it differently ? Thanks
Ok i was not concentrated and said bullshit... i need to adapt few files and adapt names to see if it work. I’ll try soon....
I tested it correctly this time :) Sections that doesn't work in crt0_snes.asm seems to come from libc.asm, it is this one that need to be build with -x parameter. I replaced startsectionxxx and endsectionxxx by the new SECTIONSTART and SECTIONEND. Then i got a lot of errors of Unresolved reference to xxxxx which came from libcc.asm. For each, i just removed the "" or "" before the name like for nmi_handler. (i don't know what will be the final impact on the rom...)
Now, wlalink.exe linkfile test.sfc produce this error :
crt0_snes.obj: crt0_snes.asm:243: COMPUTE_PENDING_CALCULATIONS: Result (339/$153 ) of a computation is out of 8-bit range.
crt0_snes.asm line 243 is : sta.b nmi_handler + 2 and nmi_handler is declared like that : nmi_handler dsb 4
If you have any idea, i will be happy to get it otherwise, i will continue to investigate on it :)
Haha, sorry, I'm too drunk today to check it out. I'll try to look into it tomorrow. :)
Did you solve this already? I cannot check it at the moment, which it is, but either
I'm betting on the first one...
Not again solved and next days will be very busy. I will have more time sunday i hope.
It is really strange like restriction :) I'll try it, thanks !
I checked out the 65816 instructions, and
sta.b nmi_handler + 2
is "store accumulator", and "nmi_handler + 2" must fit inside a byte (0-255), it seems... It's actually a requirement by sta(.b), not by WLA DX... :) There is also a 16-bit sta, sta.w, but using that instead of sta.b here, I don't know if it would work. Probably not. I'd need to see the code and spend time understanding it, before I could say yes or no...
nmi_handler has to be closer to crt0_snes.asm line 243 (distance in memory must be less than 127-2)
=> I tried to move .ramsection ".registers" (which contain nmi_handler dsb 4) just before .section ".start" where tcc__start function has error but result is the same.
I tried your other id : use sta.w instead of sta.b and this line compile correctly now but the same error occurs few lines after. Still without understanding final impact, I changed all lines with this error to use ".w" to finally get :
libm.obj: libm.asm:319: COMPUTE_PENDING_CALCULATIONS: Result (443/$1bb) of a computation is out of 8-bit range.
on this line :
- sty tcc__E - 1,X
STY means : STore Y register "When the m flag is 0, LDA, STA, and STZ are 16-bit operations, and when the m flag is 1, LDA, STA, and STZ are 8-bit operations."
but i'm now looking what is m flag and how to set it!
Really, with all errors since the 1st message, i am not sure to be in the right way : i think that 65816 codes (and 8/16/24 bits constraints) are the same for any version of wla. So i guess that this error "out of range" should already appear in oldest version used. Is it possible that is due to an internal change in wla or the architecture used to compile the project ?
To be continued... :)
nmi_handler has to be closer to crt0_snes.asm line 243 (distance in memory must be less than 127-2)
=> I tried to move .ramsection ".registers" (which contain nmi_handler dsb 4) just before .section ".start" where tcc__start function has error but result is the same.
I tried your other id : use sta.w instead of sta.b and this line compile correctly now but the same error
I'm afraid that if you do that change without understanding the code itself you'll end up with non-working code, even if you manage to compile it without errors...
occurs few lines after. Still without understanding final impact, I changed all lines with this error to use ".w" to finally get :
libm.obj: libm.asm:319: COMPUTE_PENDING_CALCULATIONS: Result (443/$1bb) of a computation is out of 8-bit range.
on this line :
sty tcc__E - 1,X
STY means : STore Y register "When the m flag is 0, LDA, STA, and STZ are 16-bit operations, and when the m flag is 1, LDA, STA, and STZ are 8-bit operations."
but i'm now looking what is m flag and how to set it!
I don't think WLA handles that, you'll need to manage the m-flag status in your code yourself... At least 16-bit STA is 0x8D and 8-bit STA is 0x85, and if the parameter is 16-bit WLA will use 0x8D.
Really, with all errors since the 1st message, i am not sure to be in the right way : i think that 65816 codes (and 8/16/24 bits constraints) are the same for any version of wla. So i guess that this error "out of
They should be unless there has been some fixes or changes. Reading the CHANGELOG between v9.4 and the latest might bring light to this matter...
range" should already appear in oldest version used. Is it possible that is due to an internal change in wla or the architecture used to compile the project ?
It is very possible that something has changed inside WLA or WLALINK and this is the cause of the errors. New features or bug fixes might all affect this.
To be continued... :)
I hope we can solve this issue...
If you could once again let me have the sources and makefiles and etc. I could once again try to help us go past at least some issues... :)
Your help is really appreciable :) We will solve it, i am sure ! But like you said, if i change without understanding the code i will get non-working code (and i already dit it!).
I really need to learn asm and especially 65816 but it will ask me more time.
This is final sources :
http://s000.tinyupload.com/?file_id=77760737083266259446
it contains all necessaries file and i removed makefiles with dependencies. You just need to execute command available in command_list.txt (wla and wlalink).
The code break on wlalink command with this error : crt0_snes.obj: crt0_snes.asm:243: COMPUTE_PENDING_CALCULATIONS: Result (339/$153) of a computation is out of 8-bit range.
If you want to check it, i will be happy but don't loose too much time, i think i need to restart from the beginning to avoid issues.
I think I found the culprit: RAMSECTION ".fp" is the biggest RAMSECTION that goes into slot 1. And bigger RAMSECTIONs are placed into SLOTs before smaller ones. ".fp" goes in first, before RAMSECTION ".registers" where nmi_handler is thus nmi_handler's absolute address is > 0xff and the code fails...
Perhaps the section sorting came as a new feature after 9.4 and before that it worked, because the files were given in correct order (".registers" was given in linkfile before ".fp"...).
So we need a way of prioritizing RAMSECTIONs... I could introduce a new parameter for sections, like "PRIORITY", that could be used when we sort the sections. Sounds like a plan. I'll try to do that tomorrow. :)
Ok, added PRIORITY to .SECTIONs and .RAMSECTIONs, but then we get another problem:
libc.obj: sprites.asm:160: COMPUTE_PENDING_CALCULATIONS: Result (-423460860/$e6c28004) of a computation is out of 24-bit range.
I'll check what this is all about next...
Just for reference, I changed the line 3 of crt0_snes.asm to
.ramsection ".registers" bank 0 slot 1 priority 1
and we got to this new problem...
WLALINK's write.c:get_snes_pc_bank() messes up this reference, and I don't know what is going on... :P
Looking at SNES's memory architecture I think I'm starting to understand this... Depending on the BANK the SLOT mapping of SNES changes. This is kinda crazy. Unless every SLOT is $10000 in size. This will take time to understand...
ok really good news for the solved issue :) but i don't know how i can help you for now.
I'm still learning asm but it is ... not common ! I already read better tutorials but i keep motivation!
Another fix: libm.asm line 7:
.ramsection ".fp" bank 0 slot 1 priority 2
This needs high priority as well. And you'll need the modified WLALINK I just modded... I'll commit that later.
ok really good news for the solved issue :) but i don't know how i can help you for now.
I'm still learning asm but it is ... not common ! I already read better tutorials but i keep motivation!
I don't think you can help me at this point, I just need to go through this until the very end and see why it's not linking... :P Hard work is all this takes. :D More or less. I think more work...
Ok, if you now try the latest sources and make those two "priority" changes to .RAMSECTIONs, you'll get
crt0_snes.obj: crt0_snes.asm:284: FIX_REFERENCES: Reference to an unknown label "__malloc_init".
And there seems to be a lot of labels with "__" or "___" prefix... To be removed, the prefix. Can you make any progress from this?
yes, i will check it but i think i will not finish today. i keep you in touch in the next days
No hurry! Let's give this a loose hard deadline of 31.12.2029. :D Just contribute when you have time, like me. This doesn't seem to be a simple problem fixed in a day... Needs lots of work.
It is hard to get help and i enjoy your own ! I don't want to leave hanging because i know that i will not find solution myself :)
So i solved few issues on " Reference to an unknown label xxxxxx" then i get :
E:\snes-examples\hello_world>wlalink.exe linkfile test.sfc libc.obj: lzsss.asm:164: FIX_REFERENCES: Too large distance (138 bytes from $e71c to $e7a7 "_ldv_next_flag") for a 8-bit reference.
I just moved this part :
_ldv_next_flag:
dec LZSS_CNT2
bne +
jmp _ldv_loop
before _ldv_flag_clear:
and it seems to work.
Now, it is a first victory : wlalink command finish correctly but the rom paused automatically after few seconds.
Here is the link to the current version with .sfc file : http://s000.tinyupload.com/?file_id=06459745816719328138
I need to read informations on no$sns debugger to understand it. And i would like to build other samples to see if it produce others errors.
Ouch! If you moved that code block (three code lines and the label) starting from _ldv_next_flag somewhere else, I'm 100% sure the code will fail even if it compiles...
_ldv_copy_string_done: sty LZSS_TEXTBUF_OFFS plb ply plx _ldv_next_flag: dec LZSS_CNT2 bne + jmp _ldv_loop +: jmp _ldv_check_flags _ldv_done: plb ply plx plp
That's because the execution will flow from "plx" (push x register) command one line before into _ldv_next_flag and further... :)
If you look at
http://6502.org/tutorials/65c816opcodes.html
it says about "bra": "These instructions can branch -128 to 127 bytes from the address of the next instruction." - 138 bytes is clearly too much.
BUT
about "brl" it says: "BRL is like BRA, except that the branch displacement is 16 bits, instead of 8 bits, which means it can branch -32768 to 32767 bytes from the address of the next instruction (or -32765 to 32770 bytes from the address of the BRL instruction)."
===> You should be able to replace "bra" on line lzsss.asm:164 with "brl" and the code should assemble and also work. :) - No need to move anything around...
I wonder why the code originally worked as that jump should have failed with WLA DX v9.4 as well. Perhaps WLA DX was buggier at the time?
I think we are pretty close to the solution here: If you can undo that latest code block moving, and use "brl" instead of "bra" here at lzsss.asm:164, then it might work?
If not, could you start over, and do just renaming of those labels that begin with "_" or "__" and add priorities to those two sections? I can do the rest (the 65816 asm coding)? :)
I've never written a line of SNES/65816 code in my life, but I could start from here. It's just like every other ASM, but the instructions are partially different, and I have good documents here at my disposal...
I just tried test.sfc in SNES9X, but it just gave me a black screen... Something has gone wrong? What should it do? Print just "hello wolrd" on screen?
I replaced bra by brl and generated .sfc file. Result seems to be the same : the game is paused automatically after few seconds but now when i go to no$sns it crash !
Perhaps WLA DX was buggier at the time?
tcc816 was provided with its own wla dx version, maybe it has been changed in sources but i don't think.
If not, could you start over, and do just renaming of those labels that begin with "_" or "__" and add priorities to those two sections? I can do the rest (the 65816 asm coding)? :)
Not sure to understand : You mean renaming all labels in sources that contains "_" or "__" ? and priorities for .ramsection ".registers" and ".fp" ? Because last sources uploaded contains modifications to build the code without error (with lzsss wrong modification) but original file is here : https://github.com/alekmaul/pvsneslib/blob/master/pvsneslib/source/lzsss.asm
For now, test.sfc only create a black screen because i removed all dependencies to ease understanding of issues. I need to clean sources and add snes text source files too to print something. Lot of them are written in C, i have to adapt pvsneslib structure to give a correct sample
It is very possible that the author of tcc816 modified WLA DX v9.4 even more than what we know...
I was just suggesting, that if you have no underestanding of 65816 code, then go to the starting point and do the following things:
and let me have the zip of the project when it doesn't assemble and I'll try to fix the 65816 code as best as I can. Don't move 65815 code blocks around as it doesn't work. :)
...
Anyway, if you have a hunch of what to do next, feel free to do what you want. I wast just drinking beer here and suggesting something LOL. :D
Hi,
I am trying to upgrade wla to use the latest version. The first part using wla-65816 works correctly now (i began questions in a previous thread ) but i still have difficulties with linkfile :
When i try with this file, i get this ouput :
E:\snes-examples\hello_world\data.obj: MEM_INSERT: Overwrite at $7fc8 (old $48 n ew $44). ^ Writing fixed data block from "E:\pvsneslib\lib\crt0_snes.obj". E:\snes-examples\hello_world\data.obj: MEM_INSERT: Overwrite at $7fca (old $4c n ew $46). ^ Writing fixed data block from "E:\pvsneslib\lib\crt0_snes.obj". E:\snes-examples\hello_world\data.obj: MEM_INSERT: Overwrite at $7fcb (old $4c n ew $41). ^ Writing fixed data block from "E:\pvsneslib\lib\crt0_snes.obj". E:\snes-examples\hello_world\data.obj: MEM_INSERT: Overwrite at $7fcc (old $4f n ew $55). ^ Writing fixed data block from "E:\pvsneslib\lib\crt0_snes.obj". E:\snes-examples\hello_world\data.obj: MEM_INSERT: Overwrite at $7fcd (old $20 n ew $4c). ^ Writing fixed data block from "E:\pvsneslib\lib\crt0_snes.obj". E:\snes-examples\hello_world\data.obj: MEM_INSERT: Overwrite at $7fce (old $57 n ew $54). ^ Writing fixed data block from "E:\pvsneslib\lib\crt0_snes.obj". E:\snes-examples\hello_world\data.obj: MEM_INSERT: Overwrite at $7fcf (old $4f n ew $20). ^ Writing fixed data block from "E:\pvsneslib\lib\crt0_snes.obj". E:\snes-examples\hello_world\data.obj: MEM_INSERT: Overwrite at $7fd0 (old $52 n ew $43). ^ Writing fixed data block from "E:\pvsneslib\lib\crt0_snes.obj". E:\snes-examples\hello_world\data.obj: MEM_INSERT: Overwrite at $7fd1 (old $4c n ew $41). ^ Writing fixed data block from "E:\pvsneslib\lib\crt0_snes.obj". E:\snes-examples\hello_world\data.obj: MEM_INSERT: Overwrite at $7fd2 (old $44 n ew $52). ^ Writing fixed data block from "E:\pvsneslib\lib\crt0_snes.obj". E:\snes-examples\hello_world\data.obj: MEM_INSERT: Overwrite at $7fd3 (old $20 n ew $54). ^ Writing fixed data block from "E:\pvsneslib\lib\crt0_snes.obj". E:\pvsneslib\lib\crt0_snes.obj: crt0_snes.asm:205: PARSE_STACK: Unresolved refer ence to "__nmi_handler".
"Unresolved reference to "__nmi_handler" but it seems to be correct in crt0_snes.asm file.
In fact, what is a slot because i saw that crt0_snes.obj use few differents (line 3 and line 35). In this case, should i have only 1 slot by asm file ?
I also tried to use all file in [libraries] part as simple [objects] and the result is the same but seems to be more easy because i don't need to manage bank and slots :
Thanks for your help.
This is crt0_snes.asm code :