Commander X16

3 hours ago, Stefan said:

You got it! And was able to describe it more clearly than me I think.



Actually the 1541 disk format was my initial inspiration.

That is SO COOL.  So do you have a BAM?   Or maybe just a “free list”?

This is awesome. If you want you can use the code I published here to implement a syntax highlighter in your editor ?

I don't mean to just copy paste everything as is but at least take a look at the parser and even copy whatever you need. ^^

29 minutes ago, rje said:

That is SO COOL.  So do you have a BAM?   Or maybe just a “free list”?

There's a BAM of sorts. In the code it's called mem_map. It's situated in normal RAM at the end of the code.

Banked RAM has 32 x 256 = 8,192 pages. The map has one bit per page, making it 1,024 bytes. 

32 minutes ago, VincentF said:

This is awesome. If you want you can use the code I published here to implement a syntax highlighter in your editor ?



I don't mean to just copy paste everything as is but at least take a look at the parser and even copy whatever you need. ^^

Syntax highlighting would be nice.

I'm worried about performance though.

Multi-line highlighting would be especially hard to implement efficiently. For example multi-line comments in C. Highlighting not dependent on what's happening in the text above or below the current line would be simpler.

However, it's a good idea, and I will have it in mind.

A question: If the program should support highlighting, is there any reasonable way to make "plugins" for different file formats?

I guess the program could load the selected highlighting code into RAM from the filesystem after startup. There could be a standardized jump table at the beginning of the code that exposes vectors to the needed subroutines.

Or is there better way?

Pretty sure I've seen syntax highlighting here before, although it worked for the inline editor. I can imagine that could work.

According to PRG, screen dimensions are the SCREEN call, $FFED from the C64 KERNAL. X has the number of volume, Y the number of rows.

I've published my second pre-release (v 0.0.2) of X16 Edit in the downloads section of this web page.

Courtesy of emulator r38 (nice work!), I've implemented basic file handling.

It is now possible to load and save text files to an attached sdcard. Use the -sdcard switch when launching the emulator.

File handling will not work without an attached sdcard. This is a limitation of the emulator, as far as I can tell.

A small video of the v. 0.0.2.

Opening one of the editor's source files (file.inc).

On 8/23/2020 at 10:21 PM, Stefan said:

 



.. Every memory page used by the program contains the following fields:



Offset   Content



00 01          Previous memory page / AddressH



02          Next memory page / Bank number



03          Next memory page / AddressH



04          Length of text stored in this memory page (0-251)



05-ff      Text data (max 251 bytes)

For a computer with an 80 column text mode, it might not be necessary to use a whole page. Since the high bit of every page in the High RAM window is always set, with a single byte you can get an address of every half page. Instead of (made up routine name)  ..with the page address in A:

LINEREF: STA LINE+1 : STZ LINE ..

You can:

LINEREF: STZ LINE : SEC : ROR : STA LINE+1 : ROR LINE ...

... so the top seven bits carry the bottom seven hits of the actual address, the top bit is always set to one, and the bottom bit decides if the bottom byte is $00 or $80. You still have text max of 123 chars/line.

And since bits #6 and #7 (of 0-7) as stored are always zero, you can use them to carry special information, like %7=1 is previous line when there is no previous line, next line when there is no next line (easily handles with BMI) and #6=1 means a formatting string instead of text to be printed / displayed:

NEXTLINE: LDY #2 : LDA (LINE),Y : TAX : INY : LDA (LINE),Y : BIT #%11000000 :  BMI ++ : STZ FORMAT : BEQ + : DEC FORMAT

+ STX RAMBANK : STZ LINE : AND #3F : SEC : ROR : STA LINE +1 : ROR LINE : RTS ; Note, carry clear

++ SEC : RTS ; carry set if stalled because already at extreme end

PRIORLINE: LDY #0 : BRA NEXTLINE+2

 

NOTE: The "special" line doesn't have to be a format line, it could be a tag line, so a tag search can zip through and only search for matches to test strings in the tag lines. That also makes it easy to go through and make an topic index by section by zipping through and making a linked list of pointers and line numbers for each tag and then processing that list.

That's an interesting subject.

The editor might not work as you think. It is essentially a model-view design.

The memory module (=model) has no concept of screen or line. It is just text data. So there is no limit to the length of a line. If you like, the text can be one line, 2MB long. And there are no links to previous or next line or to the previous or next screen page (or any other element of the view module).

When designing this, I calculated the memory usage. 16 bits are needed to represent the bank of the previous and the next memory page. 10 bits are needed to represent the previous and the next memory page high byte (range a0-bf is 1f wide = 5 bits). That is a total of 26 bits, not quite fitting in three bytes. I can't do any better, I think.

The memory not used is 6 bits per memory page. 8,192 memory pages x 6 bits = 6,144 bytes lost of the total 2 MB.

In the future I might come up with a use for those unused bits...