Jump to content

desertfish

Members
  • Content Count

    478
  • Joined

  • Last visited

  • Days Won

    14

desertfish last won the day on April 29

desertfish had the most liked content!

Community Reputation

349 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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...)?
  2. 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?
  3. "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.
  4. 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)
  5. 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
  6. 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
  7. ^-- which is pretty mind boggling actually...
  8. Amd EPYC around 8.3 billion transistors on a die 6502 around 3500 transistors that makes 2.37 million 6502's on one die.
  9. @Scott Robison thanks! I was totally unaware of that!
  10. 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.
  11. 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)
  12. Fantastic then it's correct that the only thing I had to worry about is keeping the X register safe (prog8 uses it internally as a stack pointer of sorts). It's so much more convenient now to not have to reload both applications all the time
  13. @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?
  14. This is good stuff, however there is a fundamental issue: I'm using prog8 to develop the assembler and the prog8 compiler assumes the program ends up in RAM. It generates code around that principle (embedded variables, sometimes even modifying code).
  15. 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