Commander X16

In my opinion, the "natural" text line break character of the C64 is defined by what the KERNAL does on print, and the KERNAL breaks lines on $0d.

Also, the text editors that came with the assembler ASSI/M and with Kyan Pascal use CR as line terminator.

So  think, to keep C64 compatibility, which I guess is a clear goal for the X16, there is no way around supporting CR as line terminator as an option.

I also think this fiddling with different dharsets and encodings is quite annoying, but if CBM is part of the game, that's how it is.

 

As for the KERNAL API that X16 Edit uses, since that is all in the standard list of API calls, you could look at how X16 BASIC handles those. IIUC you can call those standard APIs with the BASIC ROM switched in, and they magically end up calling the KERNAL, so BASIC must have a nifty bank bridge that I would expect you could re-use.

 

In the nano editor for Linux you can choose to save as old Mac format (CR=$0D), but default is Unix format (LF=$0A).

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
    
  
  
  
  

Is it possible to write stand alone Forth programs using this VolksForth? I.e. they should be possible to autostart using the emulator without having to type anything in Forth. Preferably it should be one file with VolksForth baked in, but if that is not possible some program that loads VolksForth and the Forth program automatically.

On 11/17/2020 at 6:38 PM, mobluse said:

Is it possible to write stand alone Forth programs using this VolksForth? I.e. they should be possible to autostart using the emulator without having to type anything in Forth. Preferably it should be one file with VolksForth baked in, but if that is not possible some program that loads VolksForth and the Forth program automatically.

Yes, that is possible. The usual way to compile an application with VolksForth is to compile the application code on top of the base Forth system, and then use SAVESYSTEM to store the compiled code together with the underlying Forth system into one file.

There are a few hooks aka deferred words, pre-populated with noop, e.g. 'cold, that are called during system startup. They can be used to start an application on Forth startup.

As for how BASIC in ROM bank 4 jumps into the KERNAL in ROM bank 0: This is implemented in https://github.com/commanderx16/x16-rom/tree/master/kernsup. I haven't fully grokked (yet) how the code works in detail, but it seems pretty clear that the essence is that the kernsup_*.s files assemble a jump list at the end of the BASIC or the MONITOR rom that mirrors the KERNAL jump list and implements it via cross-bank long jumps. I could imagine that replicating this mechanism at the end of an X16 Edit ROM could work. I wasn't suggesting to use the BASIC ROM; I may have caused a misunderstanding there.

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

@Stefan That is great news! Kudos for getting this to run.

How would one start the editor from, say, BASIC, or, for that matter, Forth?

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

 

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.

Hi Stefan,

in case you want to do inline assembly, you would indeed want to add 6502asm.fth and possibly trns6502asm.fth from https://github.com/forth-ev/VolksForth/tree/master/6502/C64/src to the sdcard, but to start and learn the language I would actually advise to leave out assembly at first. Of course, to call your editor, you need assembler, that's true. I may also take a stab at that integration over the Christmas break. I'm currently working on porting my C compiler cc64 (written in VolksForth) to the x16 - there your editor would of course also come in extremely handy.

But basically I would say you don't need any other files to do something interesting. You may want to add tracer.fth from the same location above, if you want to do single-step debugging. But that should be it. cc64 is really based on just core v4th and the 6502asm.fth files from the VolksForth sources.

One thing we should figure out to make the two tools easy to integrate with each other is zero page usage: Maybe we could make it so that we keep away from under each others' feet, so to speak, that we use different zero page areas. What is X16Edit using? VolksForth currently starts to use ZP from $30, and I would have to look closer how long exactly the used zero page segment is, but it seems to be ~50 bytes; among others the inner interpreter lives there, much like charget in C64 BASIC.

Cheers

/Philip