Jump to content
IGNORED

lyxass updated


karri

Recommended Posts

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 by karri
  • Like 1
Link to comment
Share on other sites

Well, I did not know about these... :ponder:

 

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 by karri
Link to comment
Share on other sites

  • 1 year later...

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

attachicon.giflyxass.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?

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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 by karri
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...