Commander X16

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.

Hi Stefan,

Great stuff! ?

Regarding learning Forth: Yes, that is quite a step. It doesn't actually really have to be hard, but it's very different in a number of respects from many other programming languages, so quite some concepts to wrap your mind around, esp. the distinction of compile time and run time which, as opposed to most other languages, in Forth you have explicit control of - and want to use, at times.

There are 2 books by Leo Brodie I would recommend, btw. The generally agreed best book for learning Forth is "Starting Forth" which is e.g. available online at Forth, Inc. The other book is even more remarkable, imho, and it is "Thinking Forth" which even has its own web site now, and it contains a lot of really insightful design advice and principles when using Forth; at least some of it should be relevant beyond Forth, too; I at least consider it one of the top influential books on my own programming and design style.

 

Really good that you have leeway wrt zero page usage. But I also just saw that I could likely let VolksForth use the area $00A9-$00FF; in the Commander X16 Programmer's Reference Guide it says "In a machine language application that only uses KERNAL (no BASIC or floating point), the following zero page locations are also available:" - that should apply easily to VolksForth; when exiting it I'm invoking a BASIC cold start so overwriting BASIC's zero page addresses should not be a problem.

Anyway, clearly something we can get figured out and synced on going forward.

As for the $0400-$07FF area - VolksForth doesn't use any of that (methinks, at least); it is based on and follows the C64 VolksForth very much. ?

VolksForth also doesn't use any banked RAM right now; when a time comes where that might be desirable, e.g. to back the Forth virtual memory manager for reading disk blocks (which the x16 implementation doesn't do at all yet), I'm sure we could also arrange some (possibly configurable) split of the RAM banks between the different usages.

Cheers

/Philip

 

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. 
  

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

Hi Stefan,

congratulations, awesome progress on your side. Just a quick update from here as I recently found some time again for my X16 coding.

I feel I am in the late stages of porting my cc64 Small C compiler to the X16. It is building now (I figured out a way around the smaller contiguous RAM compared to C64 and C16), I am currently cleaning up the code, and then I'll have to adapt the runtime library, and see if the tests pass. The next step to make it usable would then be adding a call stub to X16 Edit. The same call stub would obviously also work for plain VolksForth, as cc64 is written in VolksForth.

On 12/10/2020 at 9:54 PM, Stefan said:

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

This is pretty great! I am currently using one RAM bank for VolksForth; with your X/Y solution I can adapt X16 Edit easily; I love it.

On 12/10/2020 at 9:54 PM, Stefan said:

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 ?

Happy to help there if things haven't cleared up already; we can sync one of these days if you like.

Hi,

Exciting news that you are close to get the C compiler working.

Haven't had time to play with VolksForth the last couple of weeks. If you could give me some pointers on how to use 6502asm.fth, that would be nice.

Also, if you come up with anything else that would make X16 Edit better for Forth or C programming, please let me know.

On 1/1/2021 at 7:47 AM, Stefan said:

Haven't had time to play with VolksForth the last couple of weeks. If you could give me some pointers on how to use 6502asm.fth, that would be nice.

How about we sync via chat or video? I'll send you a PM.

On 1/1/2021 at 7:47 AM, Stefan said:

Also, if you come up with anything else that would make X16 Edit better for Forth or C programming, please let me know.

I haven't tried anything out yet, but one thing I could imagine useful would be the ability to invoke X16 Edit with a filename to open. Then, on the Forth command line or C compiler shell, you could type

  xed filename.c

and directly land in the editor with filename.c opened for editing.