Jump to content

Stefan

Members
  • Posts

    320
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by Stefan

  1. Hello. Starting the weekend with some thoughts on the keyboard shortcuts. I would like to follow GNU Nano as closely as possible, but some differences are unavoidable. This is my first try:
  2. I now have a solution for the shortcut overlaps, as you may read about above in this thread. The next problem is to decide on the shortcuts to use: Some shortcuts may be used as is Some shortcuts must be changed as the control character does not exist in PETSCII (for instance underscore) Some X16 Edit commands have no direct match in Nano I attach a file listing the shortcuts. Considering that you have been using Nano and Pico for such a long time, I would appreciate your input on the shortcut layout. Also, if there are other commands that in your opinion are crucial for using Nano effectively, please list those too. kbdshortcuts.txt
  3. Seems @Michael Steil was way ahead of us. After further studying of the Kernal sources I noticed the function "kbdbuf_get_modifiers" in kernal/kbdbuf.s. In R38 the call address is $ca64. I've just tested it briefly, and I think it is working properly. The function returns value of shflag in A register, where each modifier key is represented by one bit. This also makes it possible to detect combinations of several modifier keys.
  4. @Greg King Hello Greg. You're right, those 16 bit values are pointers to keyboard layout tables, and the values might change as you switch keyboard layout. You could still compare $84-85 to each entry in the $a017 table. From the position in the table where there is a match you can conclude the modifier key. But it's a hack. The solution is depending on the internal workings of the Kernal keyboard scan routine, leaving $84-85 in this state when done. Do you have a better solution? Or should we kindly ask @Michael Steil to modify the Kernal to store a copy of shflag for us?
  5. I have looked at little at the Kernal keyboard driver code: x16-rom/kernal/drivers/x16/ps2kbd.s I first tried to read the value of shflag ($a00c), but it seems that the value is cleared before the Kernal scan routine returns. However, if I understand correctly (far from certain), the _kbd_scan routine stores a 16 bit key pressed value in "ckbtab" ($84-85). I did try that. Results: First byte ($84) seems to indicate modifier key Value if no modifier key = $c5 Value if Shift pressed = $38 Value if Control pressed = $93 Value if Alt pressed = $c1 The other byte ($85) seems to indicate non-modifier key When trying this, I first called the Kernal GETIN as normal. Then I read the content of $84-85. There is a table of what I believe is modifier key values, ten bytes from $a017. Content: $38, $c1, $ee, $c1, $93, $c1, $ee, $c1, $c5, $c0 It looks promising. Have to keep digging, though. If I get this working reliably, I will make the keyboard shortcuts the same as in GNU Nano, as far that's possible to do.
  6. I totally agree that the editor should use the same shortcuts as Nano, if possible. I think the solution is to get Ctrl and Alt key status separately. That probably requires low level reading of the VIAs. Maybe such a function could be "bolted on" in parallel to using the Kernal keyboard scan routine. Otherwise, you need to write custom keyboard scan code from scratch, which I wouldn't like to do if there are other options. The X16 joystick_scan and joystick_get Kernal functions read Ctrl and Alt key status for you separately, according to the PRG. But it is said to work only if no joystick is attached. I wouldn't like to create a text editor that requires you to unplug the joystick every time... I will look more closely on this, as it's an important part of the user interface. If anyone else has a solution, please tell me.
  7. Thanks! It would certainly be nice to follow Nano's shortcuts more closely. As you said, some Ctrl+key sequences are wired to other keys at least as the Kernal keyboard scan routine works. Ctrl+c=Esc and Ctrl+M=Enter are two examples. I will look at the files you attached. In the meantime, all commands should be available if you press and release Esc and then the command key (without Ctrl). I put in that option as a fallback.
  8. @pzembrod I've now given it some thought how to best let other programs limit what parts of banked RAM is used by the editor. I have got a test solution that seems to work: Before starting the ROM version of the editor you specify the first bank used by the editor in the X register and the last bank in the Y register. Then you call the editor entry point in $c000. Another thing: I have not yet succeeded in including 6502asm.fth. I get compiler errors that seem to be linked to the character encoding. I first made a Python script to convert ascii to petscii. I then saw that you in the Makefile called a utility for this conversion. I also found the source code of that utility, but I still didn't get it working properly. I need to continue another day... But I really like the idea of Forth from a conceptual standpoint. And I'm still using my old HP12c calculator at work, so I'm kind of used to reversed Polish notation
  9. I've done some initial work reducing X16 Edit memory usage. It's now only using ZP addresses $22-$37 = 22 bytes. This was done by moving variables from ZP to $0400 page. I have also removed some variables that were stored in $0400 page (mainly temp data backups). These values are now temporarily stored on the stack instead. The range $0400-$04c6=199 bytes is used for variables. As before the editor uses all of $0500-$07ff. As to the banked RAM: I need one bank for house keeping and buffers. This is bank 1 at the moment I would like to have a fixed head of the text buffer not to overcomplicate the program. This is bank 2/$A000 for now. In bank 1 I already have a memory map or BAM, if you like. It would not be hard to make a function that lets you reserve parts of banked RAM that is not touched by the editor.
  10. Hi, Thanks, I'll try including those files. Learning Forth is a struggle, and I don't feel like the smartest of people when reading tutorials about it... Good idea to coordinate memory usage. At this stage, the program uses 57 bytes of zero page ($22-$5B). Of these, 10 bytes must be in zero page, as they are used for indirect addressing. The program uses $0400-04DA for variables and temorary storage. $0500-05FF is the buffer used when prompting the user for input to commands. $0600-06FF is the current file name buffer. $0700-077F is a buffer holding the result of last disk status read. $0780-07FF is bridge code needed to handle ROM banking. All of banks 1-255 in the banked RAM are also used. Bank 1 for the program's memory map (1 kB) and clipboard buffer (3 kB) and banks 2-255 for the actual text buffer. I could easily use less zero page addresses. I could probably also use a lot less space in the $0400 page. There are a lot of temporary backups of values that could be moved to the stack instead. And it is of coarse possible to backup the zero page on starting X16 Edit, and to restore it on exit. I have got 4 kB of unused space in banked RAM, bank 1, that could be used for this purpose.
  11. I'm trying to setup V4TH to start learning the language. Is it true that the download published on this site is just a base system, and that you need additional files to actually do something interesting? For instance inline assembly. Could you tell a total FORTH beginner what files you need to put on the sdcard besides v4th-x16.prg.
  12. You need to start the ROM version of the program in machine code. In Basic you may load the code from a DATA statement. I attach an example. I don't know how to do the same in Forth. I'm very interested in knowing how well the editor works with your Forth compiler. Let me know if there are issues. STARTER.BAS EDIT: Isn't there an inline assembler in Forth? If so you could enter the following assembly code to start the editor: LDA $9F60 PHA LDA #$07 STA $9F60 JSR $C000 PLA STA $9F60 RTS
  13. @pzembrod and @mobluse Inspired by you, I have made a romable version of X16 Edit. It's published in the downloads section. Sources on Github. It's a bit fiddly to set up for testing, but a proof of concept that the editor ROM version works as expected. I had three main issues to solve Bridging Kernal calls. I seems that I could have used the built in JSRFAR, but in the end it was very easy to implement my own specialized bridge. This was the easy part. There was quite a few variables embedded in the code section that I had to move to RAM. This was not hard, but took some time to do. The hardest part was to get interrupts working. Very frustrating before I found a solution. I looked mostly on how the built-in monitor had solved this, but it's always hard to get to know code you are not familiar with. I have also changed the way line breaks are encoded. If the editor is in PETSCII mode, it uses CR as line break If in ISO mode it uses LF as line break Internally it still uses LF as line break in all cases. When reading a file into the buffer it converts all CRs to LFs. If in PETSCII mode, all LFs are converted back to CRs when you save the file. I guess you're right that this is the most likely setup to be play nicely with other programs from the C64 era. After all Commodore 8 bit computers didn't have the LF control character. If you would like to save an ISO file with CR line breaks or a PETSCII file with LF line breaks, it's still possible. Edit the file in the preferred mode. If you want LF line breaks, change to ISO mode before saving or to PETSCII mode before saving if you want CR line breaks.
  14. Version 0.3.0 of X16 Edit released. Major rework to make the program romable. I have included a pre-built ROM image. There are, however, some steps, if you want to test the ROM version. The steps are described in more detail on the download page, and on my Github page. Change of line break encoding. If in PETSCII mode line breaks are now marked with a single CR. In ISO mode line breaks are marked with a single LF.
  15. I got the ROM version of my program and interrupts working now, finally. I learned some new things in the process. I write it down, should you have any use for it. I use the CA65 assembler. A minimal config file could contain the following: MEMORY { ROM: start = $c000, size = $3ffa, fill=yes, fillval=$aa; IRQ_VECTORS: start = $fffa, size = $06, fill=yes, fillval=$aa; } SEGMENTS { CODE: load = ROM, type = ro; IRQ: load = IRQ_VECTORS, type = ro; } On a maskable interrupt request, the 65C02 processor jumps to the address in $FFFE/$FFFF. Your ROM needs to hold a reference to a valid interrupt handler. Otherwise it's likely that the computer just locks up. That interrupt handler needs to switch to Kernal ROM bank, and call the Kernal interrupt handler in Bank 0/$FFFE-$FFFF. When done it needs to switch back to the ROM bank that was active before, i.e. the ROM bank you are using. The interrupt handler must be stored in RAM. If in your ROM bank, the program execution would continue at the following address in the Kernal ROM as soon as you switch bank, and probably cause unexpected results. There is already such an interrupt handler in RAM location $038B ("banked_irq") when the computer is booted. To use this enter the following somewhere in your code to be stored in the IRQ segment, i.e. in memory addresses $FFFA-$FFFF. .segment "IRQ" .byt $ff, $ff, $ff, $ff, $8b, $03 .CODE In your code you may then change the interrupt vectors in $0314-$0315 as usual. sei lda #<($0780) sta $0314 lda #>($0780) sta $0315 cli Here my custom interrupt handler is stored in RAM address $0780. Normally you would store the handler in ROM, and copy it to RAM on starting your program. My custom interrupt handler looks like this: bridge_irq: lda ROM_SEL pha lda #7 ;assuming your code is in bank 7 sta ROM_SEL jsr irq_handler pla sta ROM_SEL jmp (irq_default_handler) irq_handler is code in your ROM bank that is run during the interrupt. The bridge code is only what's needed to switch between Kernal bank and your bank. Assemble your rom image with the following command: cl65 -v -t cx16 -C yourconfig.cfg -o yourrom.bin <source files> You may attach your ROM image to the standard ROM file with the cat command (on Linux or MacOS at least). This is also what the X16 Kernal project does in it's makefile. For this to work your ROM image must be exactly 16,384 bytes. cat rom.bin yourrom.bin > customrom.bin When starting the emulator, select the custom rom with the -rom option. I don't think it's possible to run code in another ROM bank from BASIC. Instead you may type in the following short startup program in the built-in monitor. .A1000 LDA#$07 ;assuming your code is in ROM bank 7 .A1002 STA$9F60 .A1005 JSR$C000 ;assuming this is the entry point of your code .A1008 RTS
  16. @Ender Thank you. I understand a bit more of what the monitor does now. Vector in ROM bank 5/FFFE = 038b The routine in 038b is called banked_irq, which basically does the following, I think (it's easy to get sidetracked): Saves active ROM bank number on stack Switches to ROM bank 0 (Kernal) Jumps to Kernal FFFE vector. Before that pushes return address and processor status (?) on stack Switches back to the ROM bank we started with Restores registers Exits with RTI My next try will be based on a FFFE vector pointing to the same 038b routine and a custom irq handler stored in RAM pointed to by 0314-0315. The custom irq handler will switch ROM bank and call my code, and when done switch the ROM bank back. Exit with jump to Kernal irq routine.
  17. Hi, I see that @StephenHorn has written an article on interrupts. I have a question on how to setup interrupts if your code is placed in a ROM bank (not the same as the Kernal). I just can't get it to work. Any pointers on how to do this are welcome. The alternatives I tried: Placing bridge code in RAM that is pointed to by $0314-0315. The bridge code change ROM bank, and executes my code therein. When done it restores X,Y,A and exits with RTI (without changing the ROM bank). Storing pointers to my interrupt handler directly in the $FFFE-FFFF in my ROM bank. Either nothing happens, or the emulator crashes. EDIT: I've looked a lot at the monitor code, but I do not fully understand it. One thing is that its interrupt handler seems to exit with a rts. How is that possible? Looking at the compiler config file for the monitor, it's apparent that it includes some vectors, amongst other things, from the Kernal. These two memory ranges are defined: KSUP_CODE2: start = $FB00, size = $03C0, fill=yes, fillval=$AA; KSUP_VEC2: start = $FEC0, size = $0140, fill=yes, fillval=$AA; => Range $fec0-ffff: May include entry points of Kernal routines, and all interrupt vectors It all comes down to what happens on an interrupt: Is the interrupt vector read from FFFE/FFFF in the active ROM bank (and not always ROM bank 0)? I guess that there's no possibility that the processor on interrupt could change the ROM bank before code execution starts. If so, what parts of the Kernal ROM need to be copied to your own ROM to make this work?
  18. OK. I will look into supporting CR line breaks and maybe even CRLF line breaks as alternatives. The user interface could work about the same way as Nano, i.e. you select format after issuing the save command. As to being romable: There's the JSRFAR Kernal function, but I guess that's not available if your code resides in another ROM bank. The JSRFAR is general and there seems to be some overhead for each call that you could avoid by using a specialized bridge, at least for Kernal calls made a lot of times in a loop. I've looked at the BASIC source, but as I'm not familiar with it, it's very hard to exactly understand what's going on. And the BASIC ROM code is also not available if your code resides in another ROM bank. A bridge function in RAM need not be more complicated than this, I think, using a call to CHRIN as an example: bridge_chrin: stz $9f60 ;ROM bank 0 jsr CHRIN ldx #6 ;Return to editor ROM bank, here assumed to be no 6 stx $9f60 rts
  19. Was there ever a standard text file format for the C64? I don't really remember. But I was not doing a lot of text editing on the C64 in the 80s. My feeling is that everyone invented their own solution on the C64. BASIC uses NULL (0) as end of line marker. At least some of the word processors/text editors of the time used screen codes instead of PETSCII. One such example is SpeedScript, that I've tested in VICE. Speedscript furthermore used screen code 31 as end of line marker, i.e. the left arrow character. The text: "HELLO WORLD!<ENTER>" is stored as hex values 00 25 08 05 0C 0C 0F 20 17 0F 12 0C 04 21 1F, where the first three bytes are not part of the text, and 1F is the line break marker. By not using LF as line break marker, we loose compatibility with all modern OS:es. Do we really gain anything by using $OC?
  20. It's not a problem supporting CR line breaks. But is it a good idea to have different standards? I haven't done much thinking on what's needed to make the editor "romable". The editor would fit in a 16 K ROM bank without any further size optimization The editor uses the following Kernal routines: GETIN to read the keyboard SETNAM, SETLFS, OPEN, CHKIN, CHKOUT, CHRIN, CHROUT, READST, CLRCHN and CLOSE for reading and writing files MEMTOP to get banked RAM size I think you would need a bridge in RAM for each of those Kernal functions. A bridge would need to Switch to the Kernal ROM bank Call the Kernal function Switch back to editor ROM bank And return without affecting the communication registers of the Kernal function Looking at the memory map, it seems that the bridge functions could be placed in 0400-07ff. The bridge functions could be stored in the editor ROM bank and moved to 0400-07ff on each startup. Disclaimer: I haven't tested any of this.
  21. The head of the text is always bank 1, address $a000. The memory model is not a simple stream of bytes. The memory pages are organized as doubly linked lists, and every memory page has some metadata to make this possible.
  22. @pzembrod OK. Let me know if there are issues. One thing: As far as I know there is no real text file format standard for the X16, especially how line breaks are to be coded. I have chosen to use Unix style line breaks, that is LF=character code 10 (decimal). That could be a problem for VolksForth if it assumes another form of line break. I would not like to use CR as line break, as that is not recognized by other OS. And don't ask me about those Windows two byte line breaks... I'm not part of the group that decides what's going into the ROM. If they would like to include the editor, that's fine with me. The editor is released under GPL v 3, and may be distributed by anyone under the terms of that license. Would it otherwise help to make a high memory version of the editor, that could stay in RAM at the same time as VolksForth? The program has become a bit large (at present 15KB). I could shrink it by 2 KB by moving the built-in help screen to a file. I'm in the process of cleaning up the code, and might be able to shrink to code further, but it will not be easy to make it substantially smaller than 13 KB.
  23. Nice work! Forth is an interesting language, but I do not know almost anything about how to use it. I've been programming a text editor for the platform (X16 Edit). It would be nice to use the editor for forth coding. I managed to write the smallest hello world program and saved it as a text file on the SD card image. I could import the source file to your interpreter with the include command, and it worked as expected. Even though the interpreter seems to be running in ISO character mode, the source file I imported was interpreted as PETSCII. I don't know if that's a limitation. Comments are, for instance, marked with backslash, which is not available in PETSCII. Please let me know if there is anything I can do to make the editor play nicely with Forth.
  24. It would be great to use the editor for enhanced BASIC programming. I started to look at a solution a couple of weeks ago: Write BASIC code and save as text file (=source) Run a parser/translator on the source file which outputs a tokenized BASIC program I don't know if the parser/translator should be integrated into the editor or if it should be a separate program. The parser/translator could make it possible to write BASIC code with support for labels and long variable names, and without using line numbers. It's feasible, but a lot of work.
  25. @tibi I'm glad you want to try x16edit. If you use the command "x16emu.exe -sdcard sdcard.img -prg x16edit-0.2.3.prg -run" there is no need to copy the prg file to the sdcard image. When starting the emulator with the -prg option, the emulator loads the prg file directly from the host file system. The -run option runs the program automatically as soon as the emulator is started. The error message simply means that x16edit-0.2.3.prg wasn't found, presumably not being in the path where you started the emulator from. The easiest solution might be to stand in the folder where x16edit-0.2.3.prg is saved in the host file system when you start the emulator. Then the command should work without any changes. If you still have problems it may help to copy x16edit-0.2.3.prg to the same folder where the emulator executable is stored. Another solution would be to use an absolute path to the prg file. As I have no Windows installation, I cannot test exactly how you would specify an absolute path, but you could test "c:/downloads/x16edit-0.2.3.prg" or "c:\downloads\x16edit-0.2.3.prg" (assuming that the prg file is stored in the c:\downloads folder. The command would then be: x16edit.exe -sdcard sdcard.img -prg c:/downloads/x16edit-0.2.3.prg -run (if forward slashes work on the Windows version of the emulator) However, it's also possible to copy the prg file to the sdcard image as you did. If you do this, you need to load and run the program in a different way: Ensure that the sdcard image is not mounted in Windows. Mounting the image on two systems at the same time may corrupt the sdcard image. Start the emulator with the following command: x16emu.exe -sdcard sdcard.img In the emulator, first type: LOAD "X16EDIT-0.2.3.PRG" Then type RUN
×
×
  • Create New...

Important Information

Please review our Terms of Use