Jump to content

desertfish

Members
  • Posts

    594
  • Joined

  • Last visited

  • Days Won

    15

Posts posted by desertfish

  1. I can't get it to work, no matter what I try the cursor always jumps to the first column when I press enter.  Tried ^A to turn auto indent on /off, no difference.  I'm quite confused and feel stupid 😛  There's no visible indicator to tell me if autoindent should be enabled or not so I just assume it should be. This is what I configured in the config registers as well when jumping into the editor from the assembler.   I type: <TAB>test<ENTER> and expect the cursor to be put under the t of test, but it stays in column 1 instead.

  2. @yock1960 Yes this r39 limbo is really annoying, I'm sorry about that. When I made the decision to make prog8 r39 only I didn't think it would take this long for it to finalize.

    Maybe this can be a solution for you though:

    - use BOX16 the alternative emulator, it is built for r39 and includes a precompiled windows binary https://github.com/indigodarkwolf/box16/releases

    - download ZeroByte's patched v39 kernal bin image from this topic https://www.commanderx16.com/forum/index.php?/topic/2064-r39-patched-kernal-to-fix-load-into-hiram-functionality  and install that as the rom.bin

    Prog8 can launch box16 as the alternative emulator with -emu2 command line option.

  3. So it seems that Windows needs fiddling with the PATH and/or JAVA_HOME environment variables? I would have guessed (hoped?) that the JDK installation would take care of that.  Anyway, as long as java.exe can be found in your path you can just type "java -jar prog8compiler-7.5-all.jar <options>" on the command line.

    Borgar's script is handy if you frequently use the same command line arguments. Personally I'd use an alias for that (which is done with doskey on windows I believe?), but there's always more than one way to skin a cat!

    Happy programming

     

  4. Version 7.5 has been released  https://github.com/irmen/prog8/releases/tag/v7.5

    Documentation as always here:   https://prog8.readthedocs.io/

    Some new features and more optimizations have been added.

    • added diskio.load_raw() to load headerless files
    • added cx16diskio with load() and load_raw() that are HIRAM bank-aware
    • added cx16.getrambank() / getrombank()
    • fix grammar problem: \x and \u escape sequences now work properly in character literals
    • fix grammar problem: scoped variables such as cx16.r0-r15 are now allowed as loop variable in for loops
    • cx16.r0-r15 are now properly considered to be already in zeropage on X16 if you use them as pointers
    • allow using ubyte[] as subroutine parameter type
    • some other bugfixes and optimizations
    • Like 3
  5. I haven't really thought about that to be honest. The only thing that occurred to me is that you could make a version that uses ZeroByte's fixed v39 kernal rom to use LOAD instead of a CHRIN based file read loop to load large files much faster, like I did in the assembler.

    Saving will still be slow because SAVE doesn't yet work with banked ram. Also that version, like my assembler now, would only work with the patched ROM...

    If the patch won't get merged we'll be stuck with non working software 😞

  6. Thank you Stefan.

    As long as you don't load the resulting output program, or loading it into a unoccupied piece of RAM as to not overwrite the assembler itself (so outside $0801-$5000 ish, look at the load addresses of the assembler program) you can indeed simply restart the assembler to continue editing or assembling code.

    (prog8 programs generally are restartable after exit).

  7. Update again with new file load routines. Note that a patched V39 ROM is required to run this correctly because it depends on the kernal's LOAD routine to work correctly across ram banks.

    The framework for loading multiple files is now in place and we have ample RAM to store them into - we're now using hiram banks so we can store hundreds of kb of source files.

    So the next thing to do in the next version is to implement some sort of .INCLUDE "file.asm" directive to be able to read from multiple source files.

    • Like 1
  8. From the (limited) time I spent with this patched kernal it seems to work fine for me!  So yeah go ahead with the pull-request on github.  This is quite an important one, as it will probably fix a whole lot of data-load issues when running from sd-card 😐 

    (also I want to integrate it with my custom v39 rom build, because a few other patches are in there as well)

    edit: found an issue when loading to banked addresses when LSB=$02 , thinks work ok if LSB=$00

    • Like 1
  9. Version 7.4.1 has been released  https://github.com/irmen/prog8/releases/tag/v7.4.1

    Documentation as always here  https://prog8.readthedocs.io

     

    Even more improvements in generated code efficiency, resulting in smaller code that runs faster.

    • improved code generation.
    • optimizer is now smarter about accesses to memory mapped IO that shouldn't be optimized away
    • performance improvements in the compiler itself, updated to Kotlin 1.6
    • fixed some illegal instructions in the conv module on c64 target
    • other bugfixes
    • documentation improvements
    • Like 3
  10. Here's a 24 bit division routine from codebase64 that is an extended version of their 16 bit division routine (which I use in prog8), so I expect you can extend it once again to 32 bits.

    It looks smaller than your code, but I didn't measure.

    https://codebase64.org/doku.php?id=base:24bit_division_24-bit_result

    Also here's another person with a different looking 32 bits division routine but arguing that it is useful for small code sizes   https://atariage.com/forums/topic/237463-looking-for-32-bit-division-routines/?tab=comments#comment-3240032

    I haven't tried both of them but perhaps they're of some use to you

     

    but if it's always division by 60, perhaps you can cheat a bit?   Start with division by 64 (which is a simple shift) and maybe this is precise enough already? otherwise perhaps there's a way to adjust the result somewhat to make it more precise, I don't know

×
×
  • Create New...

Important Information

Please review our Terms of Use