Jump to content

desertfish

Members
  • Posts

    594
  • Joined

  • Last visited

  • Days Won

    15

Posts posted by desertfish

  1. On 5/14/2021 at 10:09 PM, Stefan said:

    All assemblers discussed so far in this thread have different issues: source code can no longer be found, may be widely spread and used but without clear legal basis and/or are so closely tied to a develop environment that porting to X16 would as hard as writing the whole thing from scratch

    Um... the file based assembler has none of those problems. iIt has a few other issues so far, like no macros, no expressions, no includes, but with help, I think those can be fixed?

    • Like 1
  2. Yeah I expected a new emulator release for quite a while already...

    That said, I suspect most of the programs compiled by the new beta version of prog8 can work on the V38 emulator just fine.   The V39 changes were mainly in the ram/rom banking and some register changes.  If your program doesn't use these it will likely still work on V38 of the emulator. 

    (oh and I think the floating point rom routines were relocated so you can't use floats if you want to do this)

    • Like 1
  3. Defining a label at block scope (outside a subroutine) is only possible since the 7.0-beta release of Prog8.

    Either upgrade your compiler or stick to labels inside of subroutines for now  (you can still refer to those perfectly fine by prefixing them with the subroutine name)

  4. 9 hours ago, borgar said:

    generally I find Prog8 to be a nice and simple language to work in. Since we are working closer to "the metal" than I normally do I think the simple types and limited syntax makes perfect sense. I especially like how easy it's to integrate in assembly functions with the Prog8 code.

    Thanks, I am glad it is proving to be useful for others too in the way I intended it.

    9 hours ago, borgar said:

    I've already mentioned the issue with variables only used in assembly being optimized away. I'd prefer to have these in the Prog8 part of the code for a few reasons.

    As long as you're not using zeropage locations you should be just fine by "inlining"  .byte or .word  statements in your asm blocks to reserve some variables space:

    %asm {{
        lda  variable
        rts
    variable  .byte 99
    }}
     

    I'm still considering a feature of some sort to mark variables to not optimize them away as unused, though.

    9 hours ago, borgar said:

    constants being removed in assembly output

    This hasn't been the case anymore since the 6.5-beta version at least, so you may want to upgrade to that (or even better the recently published 7.0-beta version)

    9 hours ago, borgar said:

    debugging a bit more of a hassle

    Yeah I'm not sure if prog8 compiler can be of any help for this for the Cx16 emulator.   It does output symbol and breakpoint lists for the Vice C64 emulator, but these are useless for the cx16 emulator.

    Thanks for the feedback!

  5. I've just released a new 7.0-beta version of the compiler  https://github.com/irmen/prog8/releases/tag/v7.0-beta 

    Most important changes are in the CommanderX16 target: we now target the upcoming "V39" of the cx16 emulator and roms.
    Programs targeting the cx16 compiled with this new Prog8 version may no longer work on the previous version of the emulator.

    Also the ``struct`` language feature has been removed.  (hence the new 7.0 major version because this breaks old programs that use this. Rewrite structs as separate variables).

    Also the random number generator (used for rnd() etc) has been replaced by a slower but much better one.

    Detailed change list will be added when this 7.0 version is finalized, which will probably be shortly after the "V39" of the commanderx16 is officially released as well.

  6. oh-- that's a somewhat simpler issue you're referring to now. What about tagging the actual variable declaration instead in prog8?

    Something like:

    volatile ubyte testvar

    or

    shared ubyte testvar

    to indicate to the compiler that testvar is used elsewhere that it doesn't know about?

    However, the question is: why would you even declare the variable in prog8 if your only use of it is inside an assembly block and not in any prog8 code (in this case, why not just define the variable inside the assembly block...)?

  7. that is actually a problem I haven't thought about yet!   

    It would be very hard to let the compiler check your assembly code for invalid usages of the ZP addresses it allocated.....    are you suggesting a dump of some sort of the zp locations it allocated? So that you can act on that manually?

  8.     "Is there a way to indicate that a variable is in use in a asmsub? "

    There is currently no one great way to do that. There are a few work arounds though:

    You can force the compiler to output the variable by adding a 'dummy' assignment to it so that it is flagged as used:

    ubyte tmpvar
    tmpvar = 0

    This will generate some code for that assignment obviously but it's just 2 instructions.

    You could use "%option force_output" in the block, but this prevents optimization for all other unused variables and subroutines in that block as well.

    Finally if it's just a variable you use in the assembly code (and it needs no interfacing with prog8 code) you can use any standard assembly mechanism you like in the asm block for defining variables:  use free zero page locations, use cx16.r0 .... cx16.r15,  use " tmpvar  .byte 0",  etc.   Those handful of ZP_SCRATCH variables you discovered can be used too if you know what you're doing -- they often are destroyed if you call prog8 assembly library routines.

  9. By all means look at the generated assembly code: Some things that prog8 generates are *ahem* very inefficient when compared to had written asm.   I suggest finding a few very frequently called short routines in your code and only try tor replace those with %asm  {{..}}

    I'm fairly certain you only have to do this on a few places to make it run fine on the C64 as well, it already ran pretty good as it is!

    It can also help to split up long one-line expressions into several steps, sometimes even using temporary variables or one of the 'virtual registers' cx16.r0..r15 ,  this sometimes avoids prog8 generating slow stack-based evaluation code

    • Like 1
  10. I like your palette and gradients. While it would be nice to have such a “better” palette by default (especially for basic programs) , you can always set the colors manually in your own code. (I was already setting the pepto palette for my c64 koala image viewer)

    • Like 2
  11. @Stefan great job on that rom version of x16 edit, it was surprisingly easy to incorporate it:

    sub edit_file(uword filename) {
        cx16.rombank(7)     ; activate x16edit, assumed to be in rom bank 7
        if filename {
            cx16.r0 = filename
            cx16.r1L = string.length(filename)
            %asm {{
                phx
                ldx  #1
                ldy  #255
                jsr  $c003
                plx
            }}
        } else {
            %asm {{
                phx
                ldx  #1
                ldy  #255
                jsr  $c000
                plx
            }}
        }
        cx16.rombank(4)
    }

     

    Does also save/restore the zero page that it uses?

     

  12. 7 hours ago, Stefan said:

    a routine in your assembler that starts up the ROM based editor.

    I don't think the assembler would work in ROM and I don't quite understand all the steps required to make it work like that. So this suggestion should be the easiest to implement.

    Yup I'm from the Netherlands, but I don't come to the southern parts much (where TIlburg is located).  I've worked in Tiburg for a couple of months though, once.  I don't remember very much from it to be honest 🙂  

×
×
  • Create New...

Important Information

Please review our Terms of Use