+karri Posted November 16, 2016 Share Posted November 16, 2016 (edited) Hi, I tried to compile my old BLL stuff and to my big surprise it did not work at all. A brief check of lyxass sources revealed that it was written at a time when "long" was 32 bits. So I went through the code and replaced every "long" with a more appropriate "int32_t" to keep it as it used to be. It did produce a binary that looks the same as before. In case some of you have difficulties (like me) to compile this stuff I had to go through two things: Add the line below to /etc/environment BLL_ROOT="/usr/local/lib/bll" Change all file names to lower case at subdirectories of BLL_ROOT (macros, vardefs and includes). The old Windows stuff did not see any difference between DRAW.SPR and draw.spr. The stuff is at https://bitbucket.org/atarilynx/lynx/src as usual. Under tools/lyxass Edited November 16, 2016 by karri 1 Quote Link to comment Share on other sites More sharing options...
sage Posted November 16, 2016 Share Posted November 16, 2016 (edited) did you include the updates and bugfixes from my website as well? Edited November 16, 2016 by sage Quote Link to comment Share on other sites More sharing options...
+karri Posted November 16, 2016 Author Share Posted November 16, 2016 (edited) Well, I did not know about these... Edit: seems to be support for DEA and INA plus increased buffer space. My version is still 46 while yours is 48. PS. I was wondering if it would be ok to output the code as cc65 assembly source with some switch. This would be quite useful when making compilation carts. You could then build BLL games into separate segments and use cc65 linker to create the cart. Edited November 16, 2016 by karri Quote Link to comment Share on other sites More sharing options...
ThomH Posted August 14, 2018 Share Posted August 14, 2018 Massively late revival, but presumably the assumption of long being 32-bit was broken because you compiled for a 64-bit target? If so then there still seems to be a bug in your use of the LABEL struct for defining macros — you're stuffing a runtime address into a 32-bit field. Specifically you're storing it at line 53 of macro.c, and using it at line 150. That's undefined behaviour for the obvious reason. Do you really need to reuse that field? Would an extra char * in that struct not be acceptable? Quote Link to comment Share on other sites More sharing options...
sage Posted August 14, 2018 Share Posted August 14, 2018 The "hashing" for fast compare of strings was from the 8MHz era of the compiler. It has been replaced already by strcmp. Please check the _newest_ sources. Quote Link to comment Share on other sites More sharing options...
ThomH Posted August 14, 2018 Share Posted August 14, 2018 The "hashing" for fast compare of strings was from the 8MHz era of the compiler. It has been replaced already by strcmp. Please check the _newest_ sources. Line 53 of macro.c stores a 32-bit portion of the pointer to the location in the source code where a macro was defined. Line 150 treats that 32-bit portion as though it were the whole thing, and then attempts to parse from there. Nothing about the code shows any connection to hashing. Are you sure you're talking about the same thing? Quote Link to comment Share on other sites More sharing options...
sage Posted August 14, 2018 Share Posted August 14, 2018 Now I got it. yes,,,,,, this looks suspicious. I overlooked that one. I fix that. NO idea why is was working for me, maybe long size was 64 bit. Quote Link to comment Share on other sites More sharing options...
ThomH Posted August 14, 2018 Share Posted August 14, 2018 Now I got it. yes,,,,,, this looks suspicious. I overlooked that one. I fix that. NO idea why is was working for me, maybe long size was 64 bit. Cool! I considered trying to fix it myself, but I've no familiarity with the code whatsoever so the startup cost would have been high. I can't immediately find any evidence that you're maintaining a repository so I shall await what I assume will be Lyxass v50? Thanks for keeping this alive! Quote Link to comment Share on other sites More sharing options...
sage Posted August 14, 2018 Share Posted August 14, 2018 I am doing patches for my own purpose. and publish the changed sources on my website. As I am the only one, I see no much use in using a repo Quote Link to comment Share on other sites More sharing options...
sage Posted August 14, 2018 Share Posted August 14, 2018 lyxass.zip Please check if this solves problems for you. I omly make a rough check and compiled one complex project with old against new, and output was same. Quote Link to comment Share on other sites More sharing options...
ThomH Posted August 14, 2018 Share Posted August 14, 2018 lyxass.zip Please check if this solves problems for you. I omly make a rough check and compiled one complex project with old against new, and output was same. Will do as soon as I get to my own computer! I'm surreptitiously misusing workplace resources to post this message. That said, I don't actually have anything immediately to assemble, so appropriate feedback may be delayed. I was a heavy Lyxass user a decade or more ago but all my work is lost to time, at least in its original form. Thanks again! But does this mean we're the last people left alive using this assembler? Quote Link to comment Share on other sites More sharing options...
sage Posted August 16, 2018 Share Posted August 16, 2018 Will do as soon as I get to my own computer! I'm surreptitiously misusing workplace resources to post this message. That said, I don't actually have anything immediately to assemble, so appropriate feedback may be delayed. I was a heavy Lyxass user a decade or more ago but all my work is lost to time, at least in its original form. Thanks again! But does this mean we're the last people left alive using this assembler? No. But most people use some already compiled binary. Meanwhile Bastian completely rewriting his assmbler from scratch. Quote Link to comment Share on other sites More sharing options...
sage Posted August 16, 2018 Share Posted August 16, 2018 PS. I was wondering if it would be ok to output the code as cc65 assembly source with some switch. This would be quite useful when making compilation carts. You could then build BLL games into separate segments and use cc65 linker to create the cart. I am not sure if this is so easy. Because you would have to handle only some of the macros, but keep the labels. Quote Link to comment Share on other sites More sharing options...
+karri Posted August 16, 2018 Author Share Posted August 16, 2018 (edited) I am not sure if this is so easy. Because you would have to handle only some of the macros, but keep the labels. The much easier way is to compile it with lyxass and store the binary on the cart as a file. Then you just load the binary to the correct address and jump there. MegaPak I was created that way and there is even a command lynx_exec(filenumber) that does the trick. If I remember correctly about half of the games on MegaPak were BLL games. I agreed with the guys to leave an address range $0200-$03FF untouched as I put there a miniloader that was able to get back to the main menu screens. Here is the little magic to turn a compiled binary to a cc65 asm source file. tail --bytes=`ls -l lynx_sketch.o | cut -b 37-41 | bc calc` lynx_sketch.o | od -i -v -w2 | gawk -f lsketch.awk > lsketch.s lsketch.awk: BEGIN { FS=" " printf(" .global _vsketch_start\n"); printf(" .global _vsketch_end\n"); printf(" .segment \"VSKETCH_RODATA\"\n"); printf("_vsketch_start: \n"); } ($2 != "") { printf(" .word %d\n",$2); } END { printf("_vsketch_end: \n"); } In the BLL game you could then return to MegaPak I main screen by: zgorestart ;JUMP TO MAIN MULTIPAK TITLE SCREEN LDA buttonrepeat BNE zwaitforkey22 sei RESIRQ 0 RESIRQ 2 lda #0 jmp $200 Edited August 16, 2018 by karri Quote Link to comment Share on other sites More sharing options...
42bs Posted August 21, 2018 Share Posted August 21, 2018 No. But most people use some already compiled binary. Meanwhile Bastian completely rewriting his assmbler from scratch. :-) Check out: https://github.com/42Bastian/lyxass Quote Link to comment Share on other sites More sharing options...
42bs Posted August 21, 2018 Share Posted August 21, 2018 Now I got it. yes,,,,,, this looks suspicious. I overlooked that one. I fix that. NO idea why is was working for me, maybe long size was 64 bit. Oh, old 32 bit code. :-) I bit me from 16 to 32 now from 32 to 64 bit ... It is working fine for me as well. But label_t{value} should be int64_t (or better have an additional element). Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.