Jump to content

desertfish

Members
  • Posts

    650
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by desertfish

  1. I guess I'm the odd one out I'm using 64tass. It's the cross assembler version of what used to be turbo assembler/ turbo macro pro on the C64 natively in the past. It has a few nice features that I make use of in the code generation backend of the Prog8 compiler. Like automatically rewriting branch statements into a jmp when the branch offset gets too large, or vice versa, and automatically eliminating unused code blocks. It does lack a "linker" step so can't be easily integrated with code coming from elsewhere.
  2. yeah I can reproduce this , this somehow doesn't work as advertised. The obvious fix is to just use the LOCATE x,y command . But should the above not work as well?
  3. I agree. I hang out in the discord too I find it a nice place to be. As a commander x16 head or just a retro computing enthusiast in general. Quite a few things going on there, likewise here on the forum
  4. Wow amazing!! I have yet to beat the game, but I play mostly with keyboard on the emulator, which isn't ideal for this. Also, is that a D&D character sheet on the table?
  5. so many data statements, by now you can just as well just store all precalculated pixels and plot those
  6. Yeah that looks pretty good, I should probably change my text-elite trader program to use this screen mode as well. Square fonts just doesn't read nearly as well as tall fonts....
  7. @Stefan New version uploaded with the above suggestions and fixes implemented. The version in github just gained a self test option as well, that checks if all possible instructions are assembled correctly. But that's only useful when tinkering with the assembler itself.
  8. you can tell the emulator to write all text output of the screen also to the standard output, but that's about it I guess
  9. - the last line not assembled is if it doesn't end with a newline. I'll fix this. - what about checking if the chosen output file already exists on disk and asking for overwrite confirmation instead?
  10. Thank you for the feedback! Yeah I'm glad the x16edit integration works as smoothly as it does, really kudos to you making it rom-able in the first place! The 'smart' a sounds like a good feature and easy to add. Likewise a + r should be easy to add as well, however, what should it use as a filename to save the program to? Label scopes is pretty hard right now because the file inclusion mechanism is based on just inserting (unparsed) lines verbatim into the parser. I haven't given it much thought to make it smarter. I don't know what ca65 does regarding to scopes. About your suggestion: that would quickly hit the max length of the symbol names right now. So that has to be increased quite substantially (say twice) but that would also limit the number of symbols that can be stored. I have no idea what to expect about the number of symbols in large assembly files though, so this may not be an issue at all (or already is).
  11. You should probably write a paragraph talking about the X16EDIT signature in the rom guide of x16edit? In any case, I just uploaded the a new version of the assembler incorporating this improvement (and the LDA $00ff,Y fix).
  12. I assume that most of the run time is spent in doing the floating point math operations, which aren't any faster in assembly (unless you somehow manage to write a faster FP library than the one that's in the kernal). So my rough estimate is that an assembly version is about twice as fast at most.
  13. Thanks for the hint, I haven't updated the editor integration, I shall do this soon to make it fully compatible again with R41 + x16edit. Load-swapping the applications is tiresome That would be a good opportunity to release the LDA $00ff,Y bugfix as well.
  14. The discussion above prompted me to check the behavior of my File based Assembler and yup, it failed to assemble LDA $0024,Y as well thinking it is LDA $24,Y which is an unexisting addressing mode. This has now been fixed, but was an interesting case!
  15. That should be opcode $B9 instead.
  16. I was able to build the web emulator successfully myself, however it didn't run because it stopped with a audio subsystem not initialized SDL error. I'm on Manjaro Linux and only had to install emscripten as additional package, then type make wasm After that it downloaded and built the dependencies automatically, generated a couple of web files including a big wasm file at the end. I also tried building the official r38 release that's on the forum and it had the same issue when actually launching the emulator. So it's an issue on my end, but the actual compilation is done without errors. I know too little about emscripten to see where the problem lies.
  17. desertfish

    BitMagic

    yay copper plasma!
  18. My goodness that Dutch layout.. is that official? I can't for the life of me think of anyone here in the Netherlands actually using that layout. I think everyone here is just using the default US layout (and usually on a keyboard with a small horizontal enter key, so the ANSI variant)
  19. (Discord also works in your web browser, if you don't want to install a separate application.)
  20. Hm, the copyright is about vbcc itself, isn't it? It doesn't say about the generated code?
  21. Nope, TI$ and DA$ work fine already. Launch the emulator with -rtc option.
  22. In all seriousness, the Linux build simply uses the system-installed SDL2 library while the Windows build has to include that dll.
  23. the SCREEN color reset behavior bit me too....
×
×
  • Create New...

Important Information

Please review our Terms of Use