Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Stefan

  1. Great input! Let's think about what you could do with a common program signature. It could be used for instance to: list ROM content, and/or make a command in Basic to start ROM based programs: START("<APPNAME>"). If there would be a START command, it would also be great if you could specify start parameters, for instance like this: START("<APPNAME">, "<PARAMS>"). What is required to make this kind of functionality possible? Maybe: A way to read the program name from each ROM bank A fixed entry point, or at least a way to get the entry point A way for the program to read start params One solution: A fixed length header containing Program name Program version A fixed address for the main entry point The start params could be a null terminated string referenced by one of the zero page registers R0-R15. The string format could be inspired by how you write command line parameters In the end each program would be responsible for the interpretation of the param string But maybe I'm getting ahead of things now
  2. Hi, Elsewhere on this site, there was some discussion on the need for a common way to uniquely identify user-added programs stored in ROM. A program could be identified by a "magic" string, similar to how many file formats work. In the ROM version of X16 Edit I have for instance stored this string at address $fff0: "X16EDIT" followed by three more bytes representing the program version (major-minor-patch). @pzembrod commented on this, and said that the place near end of ROM might not be best suited, should you want to replicate the calling addresses of the Kernal routines. Another possibility would then be the start of ROM, i.e. $c000. RFC: Is there any need for a standard way of marking and identifying ROM based programs like this? Should we use a magic string based solution as described above? If so, where in ROM should we place the magic word? Can we agree on a magic string format? For instance: <PROGRAM NAME><NULL><VERSION> where <PROGRAM NAME><NULL> is a null terminated string containing the program name where <VERSION> is the program version represented by three bytes (major, minor, patch) with a total length of not more than 256 bytes Example: "X16EDIT",0,0,3,3 => X16EDIT version 0.3.3
  3. 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).
  4. 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.
  5. 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.
  6. I'm really looking forward to try this out! Very nice achievement.
  7. 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!
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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
  15. 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
  16. The weird thing is that doing SEI + CLI outside the interrupt handler doesn't save much time. It's still a mystery to me.
  17. I have done some more tests, and written a completely new test program. These are my findings. My test program is as fast or slow as your test code, i.e. loading the source file in about 8 seconds. That is if the test program is run as a "normal program", and not within an interrupt. If I setup the IRQ vector in $0314-15 and makes it point to the start of my program, so that it is run as part of the interrupt (the same as X16 Edit) the file read is done in about 4 seconds without changing the code that's responsible for reading the file. Can this be the true behavior of the machine? Or is it some kind of bug in the emulator? test.asm
  18. The editor is essentially a custom IRQ handler. Everything, including the file read function, is run within the interrupt handler. So a file read blocks further interrupts from happening. However, if interrupts are disabled in your code, that doesn't help (much). The timer doesn't work then, but I manually clocked it to be 7,8 s. I don't know which vectors you are thinking about. But I would say the program does nothing special before starting the file load.
  19. Hi, I cannot see anything obvious. It seems that X16 Edit loads the complete file in about half the time. That's 8,208 lines of code. Blocks free in the editor before load=1,983 and after=1,692, diff=291 blocks x 251 bytes => the file is about 73,041 bytes. Seems to match the reported file size if the sdcard image is mounted in the host file system. The secondary address is different in your code compared to the editor, but that doesn't seem to affect load time. Another difference is that the editor appends ",s,r" to the file name for sequential file read. But this doesn't either seem to affect load time. We have to keep looking...
  20. After programming a while for the emulator I'm generally very pleased with how things are working. There are a lot of free ZP addresses, at least when you program in assembly. Typically even a large program really requires only a few ZP words, mostly for indirect addressing. The bank switching works well as is, and it will work even better when moved to ZP. But I have the advantage of not having done bank switching 6502 programs before, so I have no fixed view on how this could or should work. The interface to VERA is logical and easy to work with. I'm especially fond of the auto increment/decrement feature, making it possible to do really fast writes to the memory in VERA. And there's a lot of RAM and ROM, making it possible to do things never imagined on 8 bit computers. I think it really is a dream to program.
  21. Hi, Yes the editor reads the whole file, and then refreshes the screen. EDIT: I think it's sufficient if the assembler has one common read_line function, so that it's easy to expand it in the future to receive code from other sources (e.g. memory). It would also be nice to have one common write_byte function, so that it's easy to let the assembler write program code to different destinations, if need be (file, memory or whatever). These are just my thoughts.
  22. Really impressing work. Maybe you can improve the speed of the file read function. I tried to load a 433 kB file into X16 Edit. That took 26 seconds, i.e. 16 kB/s. Another thing. At the heart of the assembler I/O could be a read_line function. There's nothing wrong letting the assembler using different sources where the line is read from (file, memory). But again. Impressing work in such a short time.
  23. I uploaded v 0.3.3 of the X16 Editor today. New in this version: I have implemented a directory listing view, that you can use to select files for opening or saving. The default option is still to enter the file name manually at the prompt, similar to how GNU Nano works. At the open and save file prompts you may press Ctrl+T. "To files" in GNU Nano jargon. I hope that X16 Edit will be usable for native programming on the computer. The ability to easily open different files should be valuable. I have also made an alternative entry point that loads a specified text file immediately on startup. I have discussed this option with @pzembrod who also came with valuable input on the function. The idea with this function is that it may be useful when integrating X16 Edit with other programs, for instance Volksforth and the C compiler Philip is working on. If this is hard to understand, the functions are described in more depth in the manual and the special notes on using the ROM version that is available on the download page. Or you may watch this video. X16 Edit 0.3.3.mp4
  24. True. Also answered by I=U/R => During a short R is close to 0 Ohm and I is close to infinity Amps (but in reality the amount of amps provided by the PSU). Almost everything I know about electricity is contained within those three letters
  • Create New...

Important Information

Please review our Terms of Use