Jump to content

Stefan

Members
  • Posts

    251
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by Stefan

  1. Your tracker looks very nice by the way. Another thing. Apart from PageUp and PageDown, the user experience is also affected by the key repeat rate, i.e. the rate at which a key is repeated while held down. In a keyboard controlled program, the user-experience is often better if the repeat rate is fast. Fast repeat decreases the need for other cursor movement options, such as PageUp/PageDown/GotoNextWord and so on. I recently made a post regarding the key repeat rate. In the C64, this was apparently controlled by the Kernal. Skimming through the X16 Kernal, there seems to be no mechanism for key repeat control. I think the repeat rate will be controlled by the PS/2 keyboard controller. If you change the key repeat rate in your host system, this will also affect the key repeat rate in the emulator, suggesting that the Kernal is not handling this property. But then, how can you set the key repeat on a real X16? I have seen that you may send commands from a computer to a PS/2 keyboard to set, for instance, the key repeat rate. As for now there is no function in the Kernal to support that. It would, however, be doable to implement this yourself, if need be.
  2. Hi, PageUp and PageDown are simply not supported by the Kernal keyboard routine. As for now, you have no other feasible option than to use some other key or key sequence. There are also some issues with the GETIN routine inherited from the C64. One problem is that there are overlapping values (for instance ESC is the same value as Ctrl+C). And another is your problem that modifiers don't affect the arrow keys. In the Kernal, there is in fact a routine to read modifier key status. That routine is kbdbuf_get_modifiers (call address $ca64 in emulator R38). It returns a value in .A where bits 0 to 4 represents the modifiers as follows: KBD_MODIFIER_SHIFT = 1 ; C64: Shift KBD_MODIFIER_ALT = 2 ; C64: Commodore KBD_MODIFIER_CTRL = 4 ; C64: Ctrl KBD_MODIFIER_WIN = 8 ; C128: Alt KBD_MODIFIER_CAPS = 16; C128: Caps You could use kbdbuf_get_modifiers to catch sequences not distinguishable solely by using GETIN, including I think, Shift+Arrow keys. kbdbuf_get_modifiers have, however, not yet made it into the public Kernal API, even though there is a comment in the Kernal source saying that it should be. The calling address ($ca64) will probably change for each Kernal upgrade, so using this requires you to update your code when the Kernal changes. I did register an issue on the Kernal Github page, asking for kbdbuf_get_modifiers to be included in the API with a fixed jump vector. So far there has been no reaction to this. Link to the issue: https://github.com/commanderx16/x16-rom/issues/182 Finally, on the C64 it was still reasonable (?) to implement your own keyboard scan routines. On the X16 this is a lot more complex, especially with the support for different keyboard layouts. I have made a pull request on the Github page that would let you intercept the PS/2 scan codes before they are processed by the Kernal. It would work in a way similar to interrupts, letting you change a jump vector that calls your custom keyboard code. If this would make it into the Kernal, you could catch PageUp and PageDown scan codes (or any other scan code) and act on those keys. The beauty is that the rest of the Kernal keyboard routines would not need to be changed. But I haven't got any comments on the pull request either. Link to the pull request: https://github.com/commanderx16/x16-rom/pull/187
  3. I think you're right about that. This is said about the KOUNT variable ($028B) on https://www.pagetable.com/c64ref/c64mem/ I can't find that the KOUNT variable or any other similar variable is used by the X16 Kernal. Of coarse it could be there anyway. I have read somewhere that PS/2 keyboards managed key repeats themselves (generating multiple key down/up events I guess). Maybe the X16 Kernal is expecting that, which would make the keyboard repeat rate untweakable on the computer side. EDIT: I now realized that if you change the keyboard repeat settings in the host system, that also affects the repeat rating in the emulator. At least on MacOS. Am I right to assume that keyboard repeat rate is not handled by the Kernal? How would you set the repeat rate on the real machine? I searched a little for PS/2 keyboard hardware repeat rate, and found that there seems to be commands that you can send to the keyboard to change its default repeat rate setting. Maybe that's the answer.
  4. I'm in the process of cleaning the X16 Edit code. I still have some work to do, but I think it's very stable now. I couldn't resist implementing a new feature, as this was only about 20 lines of assembly - a prompt to execute DOS commands, for instance if you would like to rename or delete a file or create or rename a directory. This feature is not, however, not yet published. There are two issues that are a bit more complicated to solve One is the keyboard repeat rate. X16 Edit uses the Kernal keyboard routines, and it's sometimes painfully slow to wait for the cursor to move while you hold down an arrow key. The speed is the same as in the built-in BASIC editor, I would say. Is there anything you could do? If not, I might have to include more cursor movement features, maybe move one word back or forth. The other is the word-wrap feature. It is very simplified at the moment, and the feature I'm least satisfied with. Making it better is a large undertaking, though. Any thoughts on how to make it better without complicating the code base too much would be very appreciated.
  5. Very interesting. Hope you find the sources. I guess there is some tweaking to get those to work on X16. Wonder how much tweaking.
  6. This seems to work. Also puts out the blinking light. CLOSE = $ffc3 CLRCHN = $ffcc SETLFS = $ffba SETNAM = $ffbd OPEN = $ffc0 CHKIN = $ffc6 CHROUT = $ffd2 CHRIN = $ffcf READST =$ffb7 disk_status: lda #15 ldx #8 ldy #15 jsr SETLFS lda #0 jsr SETNAM jsr OPEN ldx #15 jsr CHKIN : jsr CHRIN pha jsr READST bne EOF pla jsr CHROUT bra :- EOF: pla lda #15 jsr CLOSE jsr CLRCHN rts
  7. Looks promising. You should probably use READST to check for errors/EOI instead of return value 0 from CHRIN. What happens when you run this?
  8. OK. READST just tells you that you have reached end of file or that there is some error, but not which one. By opening another file with secondary address 15 you may read the disk status text stream. The text stream is read with the same functions as a normal text file(call CHKIN, and then call CHRIN and READST in a loop until you get a non-zero status value). "00, OK, 00,00" is returned if there was no error. "62, FILE NOT FOUND,00,00" is returned on, you guessed it, file not found. There are, of coarse, many other possible disk errors. Read the complete list in the 1541 user manual page 42 found here: http://www.commodore.ca/wp-content/uploads/2018/11/commodore_vic_1541_floppy_drive_users_manual.pdf This is not entirely intuitive, being a Commodore legacy, when disk drives where almost computers of their own that you communicated with over the serial bus.
  9. Hi, The read loop in my program stops if READST returns anything else than 0. I have tested what return value you get from READST on file not found. And it is $42. That is $2 (time out read) + $40 (end of identity, sort of end of file). As your code tests for $40 that doesn't seem to explain your problem. To read the disk status, you need to open the command channel with a zero length file name. Otherwise you are effectively sending the file name to the drive which will try to interpret it as a DOS command. In most cases this will cause a syntax error, and the blinking continues. To see what I mean, try entering DOS "<anyfilename>" at the BASIC prompt. The blinking light turns on. Then read the status by entering just "DOS". You can see that the last error was syntax error. I haven't tested it, but you might actually also need to read the byte stream from the command channel before closing it in order to make the blinking light go away. Only by reading the stream, you get to know what disk error occurred, if that's of any interest to you. Finally, Greg and I discussed the order in which you should call CLOSE and CLRCHN some time ago. It's common to find C64 code examples online that first calls CLOSE and then CLRCHN. When testing this thourougly, I found that it doesn't matter in which order you call these functions. Having used X16 Edit for several months now, I have not had any file related problems with calling CLOSE first and CLRCHN second. I think you may rule out that this has anything to do with your problem.
  10. The blinking pixels at top right corner goes away after you read the disk status. In assembly, you need to open yet another file for reading with secondary address 15 (=command channel) to do this.
  11. OK. Please let us know if it solves your problem. Interesting issue after all.
  12. I haven't had that problem myself in my program X16 Edit. My program always reads the disk status after accessing a file, the equivalent of entering DOS at the BASIC prompt. Maybe reading the disk status is necessary, clearing the error state before accessing other files. It's not likely an emulator bug. More likely a "feature" of the Kernal that you stumbled upon.
  13. It looks nice, all simultaneously moving sprites. I have experienced SD card corruption if the SD card is mounted in the local file system at the same time it's used by the emulator. There's nothing stopping you from doing that, but you should avoid it.
  14. 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
  15. 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
  16. 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).
  17. 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.
  18. 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.
  19. I'm really looking forward to try this out! Very nice achievement.
  20. 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!
  21. 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.
  22. 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.
  23. 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.
  24. 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.
×
×
  • Create New...

Important Information

Please review our Terms of Use