Jump to content

desertfish

Members
  • Posts

    554
  • Joined

  • Last visited

  • Days Won

    14

Everything posted by desertfish

  1. 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?
  2. "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.
  3. 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)
  4. 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
  5. 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!!
  6. ^-- which is pretty mind boggling actually...
  7. Amd EPYC around 8.3 billion transistors on a die 6502 around 3500 transistors that makes 2.37 million 6502's on one die.
  8. @Scott Robison thanks! I was totally unaware of that!
  9. 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.
  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)
  11. 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
  12. @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?
  13. 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).
  14. 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
  15. Here's my reply that I wrote under Matt's video: Because “gif” is just a regular word in Dutch (meaning: poison), I cannot pronounce it any other than that word /χɪf/. Definitely not “Jiff”
  16. Hey stefan thanks for checking it out again, yeah it's coming along nicely so far. Although there are some things in the TODO list now that I don't have any idea how to implement them yet or how much time it will cost. It can be a long time befire it is an actual useful assembler tool ... One thing that could help to make it more practical to work with is when used together with your text editor, that there is a way to switch between them without having to load the other tool from disk again and again to edit-assemble-edit-assemble. Can you think of a possible way to have both in memory at the same time somehow? and easily swap between them?
  17. Seems like you will have to use the methods to read SEQuential files... open them with ,s,r and unfortunately you’ll have to read them character by character and reconstruct the fields yourself https://www.lemon64.com/forum/viewtopic.php?p=181963&sid=b81070e1421529e6e7b2a28a55222530#181963
  18. Exiting results. The use of the hash table provides a massive speedup. It now assembles around 32 kilobyte of source code with 700 symbols in it (basically a giant sequence of labels and JMPs to those labels) in just over 5 seconds. I've updated the file in the downloads section to this new version. cx16mf-2021-04-22_22.40.19.mp4
  19. Yeah I don't know exactly, I just assume undefined behavior when an underflow or overflow occurs. And perhaps it's cheap to clip just the X-position, and is that implemented? Who knows -- use the source, Luke
  20. I would think that it is just an optimization issue. Clipping things all the time to stay within screen boundaries is an expensive operation. I guess some addressing simply wraps around now when stuff is drawn outside screen borders.
  21. Yeah it was a stupid trial and error process to come up with that function above. Using a dictionary + statistical plot in a separate tool was a great idea (i used python) I was going for 256 buckets first but the distribution was extremely skewed to one half of that so I now simply and with 127 to get rid of that It is what it is, I'm now going with the very simple function of just adding all letters and xoring the length -- that seems to behave fairly well and is very fast to calculate In any case the hash function is trivial to replace with a better one later.
  22. the buckets can contain 1 or more labels. (collison) so yeah if you have collision, you still have to scan in the bucket list, but it will be a LOT shorter
  23. tweaked the function a bit, I now have this (c0 + clast + c1*4) ^ (length*4) & 127 resulting in this distribution over 128 hash buckets for random labels generated from dictionary words: This assumes we know the length of the symbol beforehand. Otherwise you can just as well simply add up all the letters making up the symbol while scanning it to determine the length: (this also seems to yield better results when I feed it with shorter label names):
  24. the function i was experimenting with is: ((c0 + clast + length) ^ (c1*4)) & 127 where c0 = first char, c1 = second char, clast= last char, length=length of name. it doesn't use modulo at all
  25. @Dejital I think I found a simple but still fairly good "hash" function based on the first two and last letter and the length. I've been experimenting with it a little, but it's not yet integrated in the assembler because the actual hash table isn't programmed yet. The function results in 128 buckets so a lot less collisions than when just looking at the first letter.
×
×
  • Create New...

Important Information

Please review our Terms of Use