Jump to content

Stefan

Members
  • Content Count

    111
  • Joined

  • Last visited

  • Days Won

    6

Stefan last won the day on January 12

Stefan had the most liked content!

Community Reputation

65 Excellent

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.

  1. Hi, You can change the character set while running X16 Edit (Ctrl+E). However, the special characters in cc64, such as { and }, are not mapped to the ASCII values of those characters. So it will not work to just change character mode in the editor. To make this more user friendly, either cc64 can be changed to support ISO character mode (I don't know how hard that would be). Or X16 Edit could be changed to support a special cc64 mode (I don't know how hard that would be either).
  2. Yes, I think Windows and Linux users have trouble at least with Ctrl+R, that resets the emulator instead of the intended function, reading a file. On MacOS reset is Cmd+R, which is not a problem for X16 Edit.
  3. Downloaded it now, and tried it out for the first time. It's working! A real accomplishment. I have skimmed the instructions you published. Do I understand correctly that there are no standard libraries? We may need to develop such libraries, for instance to call Kernal routines.
  4. I'm really looking forward to try this out! Very nice achievement.
  5. There are several reasons. It's a personal preference: I've used Nano a lot and come to like it. The X16 environment mostly resembles a keyboard controlled command line in a modern OS. I wanted to build upon a tried and tested solution for the such an environment. Nano is generally recognized to be very user friendly without the learning curve of other options such as Vi or Emacs. Nano comes pre-installed in MacOS and in most Linux distributions. It's also available to Windows users. It's hard to say how many active users there are, but I would guess that we still are quite a few. However, I'm not religious about it, and do certainly not intend to start an editor war. If there are usability issues, I will try to sort them out. I'm very excited to try the C compiler @pzembrod published yesterday. I have not yet had a chance to do that. I will look at integration issues and key mappings. Have a nice day!
  6. I've given this some more thought. As I said, my intension is to not change the opcodes at $c000 and $c003, as they are part of the public API of the editor. To verify with greater certainty, that a ROM bank contains X16 Edit, I have made placed the string "X16EDIT" followed by three bytes representing the application version number (major - minor - patch), a total of ten bytes, at address $fff0-$fff9. This is only available in the ROM version of the program. It's pushed to the Github repository, and will be in the next release. Unless you have some other ideas on what would be best to do.
  7. The assembler and linker in the cc65 suite are very nice. It's true that you feel overwhelmed at first, especially learning to use the linker config files that control where code ends up in memory. It's not likely that a native assembler will ever compete on par with cc65. That said, I am convinced that we may create a really good native assembly programming experience on the X16. That's worthwhile, as without native programming alternatives, the X16 could easily become nothing more than a game console with a cumbersome way of starting the games. Not one person can do all that work, creating source code editors, assemblers, and compilers or interpreters for different languages. We need to divide the tasks and work together on projects wherever that's effective. Using standards, such as plain text files, is a reasonable step in that direction. I lived a long time before ever hearing about source control software. That was a life worth living too.
  8. Yes, copying the read loop to RAM is a good option if you like to avoid bank switching and improve performance. Possibly it's sufficient to copy the inner loop that's run for every byte, and accept that other parts of the read function that's run more seldom is in the other ROM bank. I would not like to gain performance by not calling READST or reading the status byte (if that can be done directly in a safe way) for every iteration of the read loop.
  9. Thanks a lot @pzembrod It's a nuisance, that Ctrl+R resets the emulator on Windows and Linux. It doesn't in the MacOS version. I have assumed that Ctrl+R will not reset the real X16, but assumptions are dangerous I would really like to use GNU Nano's shortcuts as much as possible. But I cannot anyway follow that all the way, as Alt+key combinations may not reliably be detected. A side note is that I have made a pull request in the Github repository for the X16 ROM to get finer control of key press and key release events, making it possible, amongst other, to detect Alt+key combinations. You may read about the pull request here: https://github.com/commanderx16/x16-rom/pull/187 If you have a suggestion, I'm all ears. In the meantime you get to file open in the Windows and Linux emulators by F5, as you write, or by pressing and releasing Esc and then R. Checking for the presence of X16 ROM by the signatures of the two leading jmp instructions sounds like a good idea. I intend to do my very best to never change the op codes at $c000 and $c003. If you would like another form of verification, I would be happy to provide that as well, for instance a short text string or byte sequence. That could be placed before the vectors at $fffa, for instance. Have to dash. I'm off to do some cross country skiing, as we finally have got snow where I live.
  10. Great! Github is a great alternative for a project like this. As to the "select kernal ROM" issue. I have not done any thorough investigation, but this is what I think is happening. Basic is in ROM bank 4, and the Kernal is in ROM bank 0. You may see how the X16 ROM is put together in the makefile. You may also do PRINT PEEK($9F60) at the basic prompt, which returns a 4. When you start a program from Basic, you will continue to have ROM bank 4 selected unless you change it. In the Basic ROM bank, there are corresponding jump instructions to Kernal public functions at the same addresses as in ROM bank 0. But is is not the same content, and the actual Kernal functions are not also stored in ROM bank 4. For instance, FFD2 in bank 4 = JMP $FD53. In bank 0 this is JMP ($0326). If you follow the execution path in bank 4 from $FD53 I would say that you will eventually end up at an instruction that makes a bank switch, and then calls the function in ROM bank 0. And when it's done, it will switch back to bank 4. There's quite a lot going on preparing for the bank switch, explaining the delay. The solution seems to be an easy one. An assembly program that uses Kernal functions should switch to ROM bank 0 at start, and restore the ROM bank before program exit.
  11. From the discussion in the File I/O Performance thread I think we know how to optimize the speed of file reading: Disable interrupts Select Kernal ROM before the read loop Maybe getting the status value directly from memory instead of calling READST The assembler you're working on is very promising. I guess the next big step is supporting symbols/labels. These are the thoughts I have had on that subject: The symbol table entries could have a fixed length, making it easier to store and search them The symbol names could be long but not more than maybe 256 characters; to limit the size of the table you could opt store not the whole name, but for instance this information that is used for searching/matching symbols: A suitable number of characters from the start of the symbol name (for instance 6 characters) The total length of the symbol (Forth does this) An 8 bit checksum (for instance just adding the character ASCII values together). The symbol search could start from the end of the table. This makes it possible to redefine symbols, as the assembler will find the symbol that was defined last. This method is used in Forth. Redefined symbols could be used to support scopes, which I find very valuable in ca65. When starting a new scope the assembler needs to store the index of the last item in the symbol table. New symbols defined within the new scope are added to the symbol table at the end. When checking for not allowed duplicate symbols, the search would start from the end of the table and stop at the index where the scope started. And when leaving the scope the pointer to the last symbol would be reset to the index before the scope started, effectively forgetting all symbols created within the scope. These are not in any way my ideas, it is just a combination of Forth and David Salomon's book that I mentioned above in this thread.
  12. A side note. The ROM version of X16 Edit I'm working cannot avoid bank switching when reading files. The code is in ROM bank 7, and for each byte it reads it must go the Kernal ROM bank 0. However, I'm not using the Kernal JSRFAR function, but my own minimal bank switching code stored in low RAM ($0400-7FFF). Opening the same 73 kB file is done in about 5.3 s => 13.8 kB/s. The editor RAM version doesn't have to do the bank switching, and is a bit faster, loading the file in about 4.5 s => 16.2 kB/s. This is the bank switching code. Before calling this routine the address in jsr $ffff needs to be changed to the address you actually want to call. I use a macro to make this "self modification" safe. bridge_kernal: stz ROM_SEL ;Kernal is ROM bank 0 jsr $ffff ;$ffff is just placeholder pha lda #ROM_BNK ;Set ROM select to our bank again sta ROM_SEL pla rts ;14 bytes
  13. Interesting stuff. I have three test programs to verify this, all reading the 73 kB source code file provided by @desertfish in the native assembly thread. The original test program, interrupt disabled The same + changing ROM bank to 0 at start As no 2 + but reading the status directly from memory (status address = $0286, hope I didn't get that mixed up). I clocked these manually (average of three runs per test program): 7.8 s (7.76 s + 7.76 s + 7.75 s) => 9.3 kB/s 4.4 s (4.33 s + 4.30 s + 4.42 s) => 16.6 kB/s (78 % faster) 4.1 s (4.12 s + 4.07 s + 4.12 s) => 17.8 kB/s (91 % faster) The bank switching really seems to be the culprit. The READST function is also hitting the performance, but not nearly as much as the bank switching. test_banking_status.asm test_banking.asm test.asm
  14. The weird thing is that doing SEI + CLI outside the interrupt handler doesn't save much time. It's still a mystery to me.
×
×
  • Create New...

Important Information

Please review our Terms of Use