Jump to content

desertfish

Members
  • Posts

    593
  • Joined

  • Last visited

  • Days Won

    15

Everything posted by desertfish

  1. I really have to add a star to my initial review by now....
    Watched Ozyphanto's original version some time ago and was already amazed by that. This is one step beyond even ! Beating an Amiga , who would have thought Doesn't matter that it's only simulating the 3d effect --- it's the end result that counts, and drawing 2d lines / polygons animated this fast, is a feat in itself
  2. When not streaming audio, is the streaming of the polygon draw data realistic to run this fast on actual hardware? Amazing results btw.
  3. I was afraid the website got hacked.... thankfully only a cert expiry.
  4. 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?
  5. 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)
  6. Also you can now mark a variable as 'shared' with assembly code elsewhere, to not have it optimized away if even if you're not using it in prog8 code: ubyte @shared asmvar
  7. 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)
  8. %asminclude is a bit broken at the moment, I now realize. you could try %asmbinary? if you prefix it with a label in the source code you should be able to refer to it from prog8
  9. Thanks, I am glad it is proving to be useful for others too in the way I intended it. 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. 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) 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!
  10. just FAR is too confusing IMO , it's a SYS call you're doing after all, just to another Rom bank. Perhaps FSYS? (in the spirit of VPOKE/VLOAD)
  11. 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.
  12. @borgar The game is rapidly improving, I'm very impressed !!
  13. 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...)?
  14. 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?
  15. "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.
  16. Just uploaded a new version of the assembler that can now assemble large programs to any memory location in system ram. (because it now uses banked ram to store the output)
  17. 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
  18. desertfish

    Petaxian

    Amazing job, I really appreciate the complexity of your game so far: programming these movement patterns and petscii graphics routines using prog8 I love galaga and this could be a very fun game to play if it is fleshed out a little bit more, and adding some sound effects to it to top it all off Hence 4 out of 5 stars, still a bit room for growth edit: updated to 5/5 stars because the recent versions improved many things and sound effects have also been present for a while now!!
  19. ^-- which is pretty mind boggling actually...
  20. Amd EPYC around 8.3 billion transistors on a die 6502 around 3500 transistors that makes 2.37 million 6502's on one die.
  21. @Scott Robison thanks! I was totally unaware of that!
  22. The 65(c)02 cpu zero page and stack are hardwired to the first two memory pages. I don't think you can work around that using some sort of external logic either.
  23. 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)
×
×
  • Create New...

Important Information

Please review our Terms of Use