Jump to content

Stefan

Members
  • Posts

    313
  • Joined

  • Last visited

  • Days Won

    9

Posts posted by Stefan

  1. On 5/15/2022 at 2:57 AM, desertfish said:

    - what about checking if the chosen output file already exists on disk and asking for overwrite confirmation instead?

    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.

  2. 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.
  3. On 5/12/2022 at 9:36 PM, desertfish said:

    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).

     

    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.

  4. @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.
    • Like 1
  5. On 5/11/2022 at 1:02 PM, desertfish said:

    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).

    OK. Will try it out.

    The ROM notes file is now updated with info on the application signature stored at $fff0.

  6. On 5/10/2022 at 9:55 PM, desertfish said:

    Load-swapping the applications is tiresome 🙂  

    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.

  7. 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.

    • Thanks 1
  8. On 4/30/2022 at 9:42 AM, Ed Minchau said:

    There's a new behavior for the Kernel LOAD and SAVE subroutines; they now display the names of every file being loaded or saved on the screen, along with SEARCHING FOR etc as it's loading.  That might be great for a diagnostic, but not for a game or a video.  I can't have it displaying all those messages; is there any way I can turn that behavior off?  We haven't needed it so far.

    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.

  9. 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 🙂

  10. 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.

  11. 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.

    • Like 2
  12. 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.

  13. 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.
    • Like 3
  14. 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.

  15. 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.

    • Like 1
  16. I did not have a lot of success with Ed's word method.

    All words occurring more than once were included in the test, even one-letter words. These words were replaced by a byte code. The blank space preceding a byte code was stripped. The list of words was added to the end of the text block, as this list is needed for decompression. The resulting file was actually somewhat increased in size from 1,818 to 1,895 bytes.

    Ignoring one-letter words was a bit better, resulting in a file of 1,650 bytes. But compressing this with lzsa resulted in 1,298 bytes, still not better than just using lzsa.

    The effectiveness might rely on the characteristics of the text, especially how often the same words are repeated. Or maybe I'm doing something wrong...

    • Like 1
×
×
  • Create New...

Important Information

Please review our Terms of Use