3 hours ago, pzembrod said:

One thing that would of course be great is if one could call your editor directly from Forth. Do you think there would be a way to place X16 Edit into a ROM bank and make it callable from other programs, e.g. Forth?

18 minutes ago, cstrotm said:

I have another thing that would be great: if the X16 edit keeps the data of the text file in memory, it would useful, after returning back to VolksForth, to be able to get the pointers to the start and the end of the text from inside VolksForth (or any other application). That way VolksForth could parse and compile the source code from memory without the need of (slow) disk I/O.

2 hours ago, Stefan said:

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

2 hours ago, Stefan said:

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.

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

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