Jump to content

Stefan

Members
  • Posts

    313
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by Stefan

    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.
  15. Tested the new fast loader Kernal function ("MACPTR") in X16Edit. Haven't done any optimization, just getting it to work. Results (manual timing) opening/reading a file of 169 kB in size: Old byte by byte reading: 10.8 seconds => 15.6 kB/s New MACPTR block reading: 2.5 seconds => 67.6 kB/s Quite significant a difference.
  16. Version 0.5.0 uploaded to the download page with support for the new official R39 Kernal. Versions 0.4.0-0.4.5 do not work in the final R39 due to change of VERA memory layout.
  17. Trying the MacOS binary causes the following error: "dyld: Symbol not found: _GCHapticDurationInfinite" Haven't had time to investigate, but it seems to be a resource made available in MacOS 11 (released November 2020), which I'm not running. I could, however, clone the emulator master branch, and successfully build and run it on my Mac.
  18. The VERA memory layout used by the Kernal was updated earlier today. https://github.com/commanderx16/x16-rom/issues/185 The update will break programs writing directly to the VERA screen buffer, such as X16 Edit. I have committed a fix for this in the X16 Edit Github master branch. It is not yet thoroughly tested, but seems to be working OK.
  19. A lot of dedication shown by @Wavicle !
  20. Who runs this project, and how could you contribute if interested?
  21. I uploaded a new version of X16 Edit today (0.4.4). It uses lzsa to compress the help text. It is decompressed during program initialization using the built-in Kernal function. Version 0.4.3 was 15,532 bytes, and the new version 0.4.4 is 14,897 bytes, a difference of 635 bytes. There are also some other savings from my ongoing code cleaning. I really want the program not to go over the 16 kB boundary, as this would cause a serious problem for the ROM version. Apart from that, the new version is mostly bug fixes: The old code that read a file into the text buffer did not work properly in all circumstances. As discussed in another thread here, the Kernal function OPEN does not return an error even if the file is not found. That error is thrown not until you try to read the first byte. If the file does not exist, bit 2 of READST (read timeout) is set. The old code did work in most cases, but would fail if the file contained just one character. In the previous version, the ROM based X16 Edit could not read the custom keyboard shortcut config file (X16EDITRC). This was caused by the name of the config file being stored within the executable. The config file name was not available after switching to the Kernal ROM bank when trying to open it. There was a similar problem in the function reading directory listings. The "file name" = "$" was stored within the executable, but was no longer available after switching to the Kernal ROM when opening it. Both these problems were solved by copying the file names to RAM before calling Kernal OPEN.
  22. Thank you for that @Greg King The C64 PRG and other books I've found online are not very clear on this matter.
  23. Hi, Yes, I got a copy of the PRG from when I was just a boy, printed in 1987. It doesn't say where error codes not reported in READST are stored, but you would assume the A register. I tried running a program three times calling OPEN on a file that doesn't exist. The return values are not consistent, example output: 1st invokation: A=$a0, X=$00, Y=$0b, carry=0, readst=0 2nd invokation: A=$e0, X=$00, Y=$0b, carry=0, readst=0 3rd invokation: A=$e0, X=$00, Y=$0b, carry=0, readst=0 Calling the same code when the file exists: 1st invokation: A=$00, X=$00, Y=$0b, carry=0, readst=0 2nd and 3rd invokation returned the same values A != 0 could indicate an error, but neither $a0 nor $e0 are listed as valid error codes. It could of coarse be a bug in the X16 Kernal. I haven't done any testing on the C64.
  24. Hi, I realized that I hadn't fully understood the status word (Kernal function READST) when reading serial files in assembly. After some experiments, this is what I think is correct. OPEN ($ffc0) will succeed whether or not the file exists To test if a file exists, you need to call CHRIN ($ffcf) trying to read the first byte If you then call READST ($ffb7) Bit 6 (EOI) is set if the file contained only one byte (value=$40) Bit 6 (EOI) and 1 (Read timeout) are set if the file is not found (value=$42) Bit 7 is set if the drive is not present. This could also be caught by checking the carry bit after calling OPEN. Conclusions: READST = $00 => CHRIN returned a valid byte, and it's not the end of the file READST = $40 => CHRIN returned a valid byte, and it's the last byte of the file READST = any other value than $00 or $40 => An error condition, the value returned by CHRIN is not valid Maybe someone in the community has more information, please share if so. I'm especially interested in whether you may trust that bit 1 in READST (Read timeout) always will be set on file not found.
×
×
  • Create New...

Important Information

Please review our Terms of Use