Jump to content

SerErris

Members
  • Content Count

    172
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by SerErris

  1. Make sure you read that ... the best explanation I have seen so far.
  2. My statement was more based around expectations to say what to expect. @desertfish is pretty much right on it and the reasons why C is pretty much inefficient on the 6502. BASIC has its own inefficiencies and is even compiled not considered fast. What I wanted to say is - If you need speed, Assembler is the only performance efficient way to do it. If it comes to complex calculations Basic can get you started, C can get you also the fragments going, but if you want to optimize on performance you need to write some assembly code. It would be great if we would have a debugger in the emulator that also can do profiling (how many cycles in which part of the program). If that would exist, you could then optimize the code where it makes the biggest impact and ignore the code you are just calling once or where you spend in total very few amount of time (in percent). The typical consideration is: 90% of execution time is spend in 10% of the code. That is what you want to optimize. So C with hand crafted Assembly routines optimized for speed might be a good and efficient procedure. However without a profiler you will never know.
  3. good catch - you are right .. corrected... New Version attached ... ca65.cson
  4. The whole procedureal generation is the real secret sauce in Elite ... besides the unparalleled graphics of that time. Also need to correct - the Seed is 6 bytes = 3 words. Start reading here: Sub TT20 and Sub TT54 gives you more or less the whole picture. TT24 is then calculating the real system data. Everything comes together than with the tokenized text routines (which is a masterpiece in itself). That will put out the information based on the system data. None of the strings you see on screen can be found anywhere in the code. They are also generated. That code and description can be found in QQ18. https://raw.githubusercontent.com/markmoxon/elite-beebasm/master/sources/elite-source.asm But now enough on that here... it is confusing the original post with non relevant data.
  5. I do not see any reason why I should need to build for X16 on Linux if I am Using. The whole Toolchain exists on Windows. If you want to use Linux - that is great and everything works there. But if you want to use Windows then WSL is just something to enable you to run Linux - which was not the idea in the first place. I now have done a setup with Atom as VSCode does not have any proper syntax highlighting I can easily change. I still need to do the build and run integration. I have not done that as I currently working on the source. After I have something to compile I will try to build the integration (which should be really nothing than a caller script to make and CC65).
  6. Just not related to prog8 but to Elite. You may want to lookup how the 256 planets worked in Elite. (check the source code I linked) It has a very good writeup how that works. In short: You have a pseudo random generator that is seeded by the galaxy seed (4 bytes). This seed is then taken through iterative random numbers to allways generate the same parameters for a specific planet. So if you feed in 240 into this generator (System Number), it will allways get the same result back to you, which is then feeded into the the System generator and gets you the name and the description. All of that is also generated and not stored anywhere. The marked prices are as well generated but also only varried with a random difference. /Edit: ah forgot the galaxies ... So if you jump the galaxy. the 4 bytes above will be all rotated left by 1 bit. That results into a different seed for each galaxy and will also return back to 1 for if you jump through 8 galaxies back to the first one.
  7. That is a good approach. Just wanted to make you aware of the fact of limitations of the Architecture in regards of high languages. Where the Amiga was optimal to use for C the C64 never was and the X16 compensates a bit by processor speed with factor of 8 but has the same limitations. The compiled BASIC was just a reference for comparison. It was not meant as a recommendation to go that way. Compiled Basic is for my point of view the way to go, if you really do not want to dive into Assembler. But it is still very slow. For serious game development IMO Assembler is still required. Maybe the main game loop can be written in C, but the intensive math and graphics routines should then be done directly in Assembler to avoid C functioncalls.
  8. So this is it ... I solved it by searching for the whole regex ( Line Start;any # of whitespaces;one of the allowed Mnemonics;any # of whitespaces; and then the letter 'A');followed by a word boundary). Setting both the Mnemonic and the Register in a group and then highlighten both individually works. The problem is that you need to highlight both parts otherwise the Mnemonic would be unhighlighted. I am not sure why the "X and Y" part does not highlight anything in the comments, but I do not care - it works. Attached you find the new ca65.cson file. ca65.cson
  9. Be aware that C is not a good language for the C64/X16/6502 in general. It is very heavy on all the calls and context switches, where the 6502 is not very good at. The stack is also only 8 bit and only 256 bytes in total and cannot get extended. So you need to create a software stack (which is exactly what cc65 is doing) and that is really slow to use. Yes you can program in high languages - and it will be faster than interpreted basic. However I assume (not tested) that compiled basic would be faster than any C code.
  10. That sounds like a good approach ... You are right A is very uncommon ... I can specifically look for certain mnemonics and X Y have a leading comma .. however still my problem with the comment apply. LDA (ADDR),X ; This is a ,X comment would still hightlight both X. I cannot find any statement that is highlighting anything only if it NOT part of a comment. @Greg King Why should I ignore spaces? The syntax will be still interpreted by the Assembler if there is a space between the comma and the Register. So if it is valid Syntax it should also be highlighted correctly. Haveing whitespaces between comma and the Register is not a big issue. ... However having a comment (;) anywhere in front of such a structure is a problem.
  11. There is actually only one valid Register ... if the first part is a mnemonic. This statment you have given will also show stuff in the comments .. LDA #50 ; This load A Register. would highlight the A in front of "A Register". However it is part of the comment and should not be highlighted anyway different, but highlighted as a comment. I cannot thing of any way really other the excluding stuff. Cause you need to exclude a match if a ; is in Front of the [AXY] ... Or in other words: try to match it, but if you meet a ";" ignore the rest of the string completely (never match). Not sure if something like that exists.
  12. Okay after reading the Regex Tutorial again .. it turns out that it should be this - which works in the JavaScript on regex101: \b[AXY](?<!^\s*[AXY]|^\s*;.*)\b Hower converting it to this # Registers { match: '\\b[AXY](?<!^\\s*[AXY]|^\\s*;.*)\\b' name: 'keyword.parameter.register.ca65' } Leads to nothing parsed anymore (all characters white now). I tried a lot of stuff but I cannot get my head around to something working in Atom.. This is my test text for regex101: Only the second and the last entry shall be matched. This does the trick as well (?<!^\s*|;.*)\b[AXY]\b ... it reads: Match [AXY] if it as single letter and if infront of it there is neither a ";" sign nor only whitespaces. Works again with JavaScript in regex101 - but not in atom.
  13. I still have some minor issue with it. 1. My register statement does not work as I would like it to be. I addressed this question in another thread put like to pull it out there, as it is not related to the original topic. So here we go. If I hit a Register as a parameter to a Assembly call I like to highlight it For instance I like to highlight the X in LDA ADDR,X where LDA should be highlighted as Mnemonic, ADDR should be highlighted as symbol/label , as operator and X as register. That works great with the current file. However if I just put X anywhere on the line (without anything else) it is getting highlighted to. I got a recommendation from @Ender to try that: { match: '^\\s*\\S+.*\\b([AXY])\\b' captures: 1: name: 'keyword.parameter.register.ca65' } The result is not as I expected it to be. Now every X or A will be highlighted and the rest of the line will be not highlighted at all. I also tried to change the match to this - but same result: match: '^\\s*\\w+.*\\b([AXY])\\b' .. Same result. So obviously I am overwriting the comment rule and this rule has somehow precendence. I would love to write it this way: If the line does not start with A or X or Y with any number of Whitespaces in front, then tread a word which consists only of the letter A or X or Y as a register. So the normal way would be like that: match :'(?!^\\s*[AXY])\\b[AXY])\\b' This part is the if not start+any number of whitespaces+[A or X or Y]. If that hits, the rest will be ignored. If that does not hit, the rest will get matched. However it does not work. It works if I put X in the first column. But as soon as I put it in second column with a space in front, the not part does not seem to work and it is getting matched as a register. This is what regex101 has to say about it: I cannot see what is wrong with it - but it is even there doing the highlighting for the " X" string
  14. Awesome ... not sure why that is not part of the official flight manual
  15. Hmm the regex is supposed to match the second part \b[AXY]\b but not if the first part is matched before (which is ^\s*[AXY] or beginning of line with any number of whitespaces followed by one character AXY ... that should actually work. what is this captures Statement doing? I could not find the right documentation to explain how the grammar file is setup.
  16. Hi I looked at the language-65asm package, but missed some things.. So I created my own grammar file based on that. This grammar file now highlights labels and symbols as well as registers and separates the # sign from the following constant/label. I attached the ca64.cson file, that you need to put into your language-65asm/grammars folder. Then restart Atom and the new grammar file can be selected. You can also define it for your filetypes as default in your config.json file. To enable all colours, you need to change the base.less file in your syntax-theme to refer to the new values, as not all of them are honored in all syntax-themes. I will create a specific Syntax-theme, that does include only the required variants and makes it specific to cc65. Attached find a example how it could look like: ca65.cson
  17. I worked a little in Atom now and added to the language-65asm as I did not like some things: 1. the cc65 variant does highlight #$FE0A in on thing (so the # is the same color as the following constant). I like to have it separated as # is an operator and $FE0A is a constant. Also as # is such an important thing not to overlook ... Better it sticks out. 2. I like that the cc65 labels/constants/symbols are highlighted everywhere I find them, to clearly identify them in the source code. In the cc65 grammar labels or symbols do not exist at all ... 3. I like to highlight illegal statements ... e.g a label that is a register (A: or X: would not work as the assembler will interpret that as X register). The output looks like that so far (colors need work There is one thing in my grammar file, that I do not understand. I cannot get the highlighting of the X in line 39 off. This is the regex that is activating it. # Registers { match: '(?!^\\s*[AXY])\\b[AXY]\\b' name: 'keyword.parameter.register.ca65' } It is supposed to highlight a single letter AXY but NOT if it is at the beginning of the line with only whitespaces in between. It is actually working for directly at the beginning of the line. But not if there is one space in it. I am puzzled ... and do not understand how to instrcut the regex to math it but not if there is nothing else before than whitespaces. Maybe anyone of you have ideas... However I attached my ca65.cson file - which you can simply copy into the language-65asm grammars folder and you can work with it. The colors of cause are coming from your scheme and require adoption as well. I will create a color scheme later on, purely for the cc65 usecase. Other todos: I have no idea how to get the folding right. It currently folds only on indention and not on .scope/.endscope or anything alike. Anyone ever got that to work? ca65.cson
  18. Is this generic support for D64 which is just not documented? Confused now.
  19. But but ... wasnt the VIC Chips already capable of hardware scrolling ? BTW: Hardware scrolling on VERA is smooth (one pixel at a time if you want), vs Sofwarescrolling can only do a whole character and looks stuttering. With a proper alignment to the vsync you should have a butter smooth scrolling. One of the games in development here demonstrates it (kind of a jump and run).
  20. Nice effect, One question : Would that not be possible to do as well with (H-, V-)Scroll registers of Vera? That should be even massively or better, without CPU overhead. You would need to insert just one line or one column to the hidden part, and VERA will do the rest for you. That should be much faster than copying data. (very specific to scrolling btw.). You can also put that into an interrupt routine, reakting only on vscync and therefore avoiding the tearing.
  21. No that will not work .. (at least not if this is not an undocumented feature). -sdcard does accept a fat32 .img file ... not a D64 image file. AFAIK you cannot mount D64 images at all. Workaround: Take all the files and put it directly in a directory (inside the x64emu). You can extract all the files with DirMaster
  22. The good thing is, that the assembler put out a warning about it. But I was puzzled at first as it looked goot - then finding out great: again a missing # ...
  23. That is very C like (header files describing the external interface). Now I need to see if I use include with constants (that avoids all the exporting/importing) or if I use the header file approach. Thanks for all your input @Greg King I will integrate it into my thoughts about the proper layout. What I like about cc65 tool chain is, that you simply let the linker do its job an put everything in place. So you actually only need to ensure it fits into the memory (or think of ways of splitting it). All the rest will be done by the linker. However it requires a little bit more of preparation around the individual files. One last question regarding scopes. Is the scope inside a .s/.asm file automatically local? So any variable will be only local to the file until I export them or import others from outside?
×
×
  • Create New...

Important Information

Please review our Terms of Use