Jump to content

desertfish

Members
  • Posts

    554
  • Joined

  • Last visited

  • Days Won

    14

Everything posted by desertfish

  1. update regarding V39 of the emulator/roms: I'm updating and fixing some things in Prog8 and its libraries, to accommodate the changes made in the emulator and rom V39 that will be out soon. Starting from the next version of Prog8 that will come out, 6.5, the compiler will produce programs meant to run on V39 of the commanderx16 emulator/rom (and hopefully on the actual hardware) The compiler changes are sometimes incompatible with V38. Stick to prog8 6.4 if you absolutely have to create programs meant to run on V38. Programs compiled by the next prog8 version can sometimes still run on V38, but that is only if you're lucky. I'm not adding backward compatibility to the compiler because I'm expecting everyone that compiles code for it, will hop to V39 anyway, as soon as it is released.
  2. Yup, this is the cause of the problem. I'll try to fix it in the parser. EDIT: fixed , the source file loader now normalizes all line endings to just '\n' and I've simplified the parser grammar to just deal with Unix line endings.
  3. can you please attach the exact tmp.p8 file that fails to compile? I can't reproduce your problem...
  4. That first fragment compiles fine as well.... what error are you observing? sub start() { ubyte[6] array = [ 1,2,3, ; Comment here 4,5,6 ] txt.print_ub(len(array)) } correctly prints 6
  5. @borgar i'm curious about your experiences with Prog8 so far. I'm not really aware of anyone else beside myself using it, so I wonder what you think of it and if you have any comments maybe?
  6. You should add that explanation on the album page, it really adds to the whole production!
  7. WOW, listening to it now! ... is the album cover inspired by the Alan Wake game logo screen by any chance?
  8. True about the performance, but the kernal call would not require changes when the rom is rebuilt . Choice depends on what you value more in your use case of course !
  9. Wow that is amazing @Greg King now i remember more, I used Simons basic and Logo as well. But both weren’t compilers.
  10. Yeah I think it’s pretty much impossible to have the same full featured prog8 compiler optimizer and code generator natively. Then again there is a (limited) native C compiler that I also thought not being possible at all. I was using a macro assembler on the Commodore 64 back in the days
  11. Hm, wondering why it is reading the internal variable directly and depending on its location, rather than using RDTIM kernal call?
  12. Ah man, here I was thinking it would come out on the PS3 and the Vita....
  13. @Michael Steil thanks for the work on the roms and the emulator, looking good. Actual bug fixes obviously have priority, but there is one Quality of Life patch on the emulator that currently is quite annoying for me, and probably for other Linux users as well. As it stands, starting and stopping the emulator results in a nasty display flicker and actually causes other applications to freeze or stop updating (most notably, Firefox in my case, it goes totally blank). That patch adds a tiny SDL hint to no longer bypass the display compositor and totally fixes the issue (at least, on my system). It's easy enough (for me) to build a custom emulator with this patch applied, but I think it would be great if the official emulator that is due to be released soon comes with it out of the box.
  14. yeah it was intentional (unfortunately) I'm struggling with the code generator for complex array index expressions. The reason you now see this error is because I reduced the number of automatically generated internal temporary variables to hold expression results. Suggestion for now: add 2 variables yourself for the x and y arguments to setcc(). I think the resulting assembly code will be more optimized that way as well. Maybe this limitation will be lifted again in a future version of the compiler.
  15. Found only 1 issue so far, which turned out to be a bug in my own code (in the file based assembler - fixed now): it was reading $0000 sometimes by mistake, which happened to work before because that used to contain zero. But in v39 it is no longer zero.
  16. Sin and cos overlap after .5 pi you can save a few hundred bytes with that
  17. Prog8 6.4 was just released. As always the documentation is here and the git repository is here. It contains fixes for the bugs mentioned above, further optimizations, and the code generator is now finally fully completed. There's also a cx16.vload() function now that is similar to basic's VLOAD. Have a look at the release notes on Github if you want all the details
  18. won't this break when you add non-wall elements such as monsters, projectiles
  19. prog8's textio module is a mess in this regard, some routines use kernal others write directly to Vera. Mostly, the operations that can reasonably be done by a kernal routine are not writing to Vera though. (On the C-64, it is the same, but instead of vera it directly writes into the screen buffer ram locations). In the end, does it matter? It should be a secret for the user of the library how it does its work, as long as you get the desired result The only thing that may be problematic is if you have banked out the kernal rom in your program and try to use the library routines that depend on a kernal routine. A note in the documentation about this should fix that I think (something I haven't yet taken care of for prog8...)
  20. About zero termination, I'm a bit confused then, because I see this : my input buffer at $0920 was fully filled with 20 question marks $3f, I typed my name (and some garbage that I backspaced), and those zeros really did appear
  21. Hm, In the meantime, I've discovered a few bugs in the comparison operators (such as <, >, <= etc). This means I will probably add one more release soon with optimized and fixed code for this. Also with a few other nice things such as a vload() routine that does the same as the VLOAD basic command.
  22. Playing some more with input_str.... : entered string in buffer seems to be terminated by a zero byte (I like this!) ... this probably means you want to allocate 1 byte more in your input buffer to have room for this. Maybe good to document this too after pressing enter, the cursor remains visible. I expected it to disappear i cannot enter petscii symbols (or capitals when in lowercase character mode) ?
  23. the input_str() routine, does it return the input string in petscii or in screencodes?
  24. i love that invaders one
×
×
  • Create New...

Important Information

Please review our Terms of Use