Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Stefan last won the day on March 12

Stefan had the most liked content!

1 Follower

About Stefan

  • Birthday 01/03/1973

Recent Profile Visitors

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

Stefan's Achievements

    The assembler is already fully functional. Using it, you may get an effective workflow doing native assembly development on the X16. It lacks some advanced functions found in some other assemblers, such as calculated expressions, macros, and scopes. Those functions are convenient, but you can get by pretty well without them.
  1. You're a star @desertfish, making such a nicely working assembler!
  2. If you're doing multiple rounds of editing + assembling, you expect to overwrite the output file. I'm afraid that a confirmation prompt will not add any real protection. Another option is that the assembler does not allow the output file name to be the same as the input source file name.
  3. This is the test program I created with @desertfish's assembler. After using it for a couple of hours, it felt quite productive. The test program is the basis for an app switching utility living at $9000. If you press F1 it loads and starts one program (here X16 Edit), and if you press F2 it loads and starts another program (here the assembler). App switcher.mov
  4. After some further testing: I think the assembler skips assembling the last line of the source file, and you now need to add a blank line at the end It would be great if something could be done about entering the files names during assembly; from my short experience , it's easy to overwrite your source file by entering that file name as the name of the executable by mistake. Maybe the assembler should add ".PRG" after the name of the executable unless it already has that file ending.
  5. Yes. I suspected that supporting scopes would not be that easy. If only the symbol length is a problem, you could give each source file an index number, and internally prefix labels with the index instead of the whole file name. But I guess the solution requires some thought. I think the solution could work even if the assembler just inserts the text of included source files, verbatim as you say. Anyway, the assembler is already very impressive. In combination with the ROM based editor it's far more convenient than what I used in the good old days - the Commodore Macro Assembler for the C64.
  6. @desertfish I did download the latest version of you assembler and made a small program with it just to try how well it worked. It is very usable as it is, I would say. Some reflections: I tend (nowadays) to program by writing a small piece of code, compiling, and testing it, and then writing a new small piece of code, and so on. The assembler environment stores the name of the last executable that was run so that you need not type it again. Could it also store the name of the last assembled source file so that you could enter the "a" command without parameters. Could there be a command that both assembles and then runs the program, a combination of the "a" and "r" commands Have you given any thought to label scopes? Doing scopes like ca65 might be too hard. But maybe something could be done. For instance, the assembler could internally prefix all labels with the name of the source file, for example "kb.init" could reference the label "init" in the source file "kb.asm". I don't know if exactly that is a good idea, but maybe you could come up with something clever. The integration with ROM based X16 Edit worked fine after the update.
  7. OK. Will try it out. The ROM notes file is now updated with info on the application signature stored at $fff0.
  8. That is so true. It's not the load time, but all the extra typing of LOAD and RUN. A context switching application could be an alternative solution. I mean a program that lives somewhere in RAM or ROM, and lets you switch between programs that are loaded and run from the SD Card at the click of a shortcut key. The SD Card interface is plenty fast for that to work nicely.
  9. Hi @desertfish! Great work on your file based assembler. I tested it today in the R41 Kernal, and it seems to work fine even after all Kernal updates. The Kernal ROM bank layout has changed. Banks 0 to 8 are now used by the Kernal. X16 Edit will be in bank 9 or above. In reality, you cannot be sure where the program is stored. This has made the assembler's function to open the editor not work any more. There is an application signature (="X16EDIT") stored at $fff0 in the X16 ROM bank. You may use that signature to find in what ROM bank X16 Edit is.
  10. 0000041D Swedish It's very similar to 0000040B Finnish, I'm not even sure that there are any differences. Downloaded the XML specifications for each layout and run it through diff. As far as I can tell, only the local names of the various keys in the specification are different, which is not visible on an actual keyboard.
  11. The only way I know of to get finer control is to implement your own serial read/write function. Then LOAD would be replaced by calling these functions: SETNAM SETLFS OPEN CHKIN MACPTR (faster block read) or CHRIN (slower byte read) CLOSE CLRCHN It is, evidently, more code, but it's not that bad.
  12. That version runs on my Mac. Great work with the Kernal, by the way!
  13. It returned: zsh: bad CPU type in executable: ./x16emu Never seen that error, and don't really know what it means. Bad CPU type => Build target something else than the Intel Core i5 processor I have. Yes I know it's old
  14. As with R39, I get this error when launching R40 on my Mac (Catalina 10.15): dyld: Symbol not found: _GCHapticDurationInfinite However, works fine if I clone and build myself. Did not break X16 Edit from R39 in any way that in any way I can see quickly.
  • Create New...

Important Information

Please review our Terms of Use