New community dev tool uploaded: BASIC PREPROCESSOR

[Scott Robison]

13 minutes ago, rje said:

I think..... just off the top of my head..... there are characters that are non-printable codes in one but printable in the other.... if the file is on the X16 then, surely there's a character that renders "wrong" (for some value of "wrong") if it's ASCII..... and therefore would never have a right to exist in a text file... hrmmmmmm.....



Establish guardrails, such as "this must be a text file", and then you'll be able to detect whether or not it's PETSCII by whether or not that first character is actually PETSCII printable.  If it ain't, then assume that's a flag indicating the rest of the file is ASCII...? 



 



For example, ASCII 15, 16, 21, 22, 23, 25, 26 appear to be printable, but not in PETSCII.

There might be some terminals or systems that render ASCII or 8859-15 control codes, but technically by the standard they have no visible representation. $00-$1F and $7F-$BF in ASCII are not printable in that context. Even though many of them aren't valid C source characters, for example, people will often include them anyway because compilers will not complain (it is either undefined or implementation defined behavior, I can't remember which off the top of my head.

That's not to be confused with the screen codes, which are distinct from the XSCII encoding.

[Scott Robison]

37 minutes ago, rje said:

I actually started a vi-like editor, in BASIC, in February.  I dinked with it for two days then put it on the shelf.



It uses the left-arrow as the escape to command mode.  Which I had forgotten, and therefore is probably a bad idea.



On the cutesy side, I apparently named it "xvi", which is therefore a pun both on vi and on the x16.

You and I are kindred spirits, because I was thinking of a pseudo vi-inspired editor. I'm not a fan of vi, really, so I'm not sure, but it was my thought. I was thinking to use back arrow or british pound for the esc character if I went that route.

And I do enjoy the punny name. It's not so punny that I have to groan, and it is cutesy.

[rje]

Yeah, that's how I approached it, as well.  I liked the tidy separation of "colon-command" mode from edit mode, but I wasn't trying to be slavishly recreating a vi thing.

My code doesn't let the user cursor around the screen, so for instance I can't go back and erase part of a line or insert a new line, etc.  I'd have to add that in...

I'm not sure, but I think the X16 can't currently write and read SEQ files in BASIC.  So I didn't get to the point of reading and writing.  Unless that's been fixed.

I see I have a 256-element string array as a buffer.  One string per line.  Not sure if that's the best way to do it.  Would an array of words be better?  

Alternately, I think using RAM banks as a buffer would be stupendous.  I love those RAM banks.  Memory management would be a pain, though.

 

[Scott Robison]

1 hour ago, rje said:

Yeah, that's how I approached it, as well.  I liked the tidy separation of "colon-command" mode from edit mode, but I wasn't trying to be slavishly recreating a vi thing.



My code doesn't let the user cursor around the screen, so for instance I can't go back and erase part of a line or insert a new line, etc.  I'd have to add that in...



I'm not sure, but I think the X16 can't currently write and read SEQ files in BASIC.  So I didn't get to the point of reading and writing.  Unless that's been fixed.



I see I have a 256-element string array as a buffer.  One string per line.  Not sure if that's the best way to do it.  Would an array of words be better?  



Alternately, I think using RAM banks as a buffer would be stupendous.  I love those RAM banks.  Memory management would be a pain, though.

My limited experience with it so far agrees with you that SEQ doesn't seem to be a thing yet, and that's using the bleeding edge github source.

My thought had been to use the RAM banks for text. For simplicity, probably to divide them into maximum line lengths that I would support and avoid strings. I fear garbage collection in this version of BASIC if most characters wind up destroying and creating multiple strings in the heap. If I was going to use actual BASIC strings though, I think I would use one array element per line, not per word.

[rje]

You're right about the RAM bank thing: the data just represents 80 characters per line, all lines accounted for.  The editor itself can track "actual" line lengths for when the thing is written to disk.

Then you allocate one bank at a time, with each bank representing appx 100 lines or so.

 

 

[Scott Robison]

1 minute ago, rje said:

You're right about the RAM bank thing: the data just represents 80 characters per line, all lines accounted for.  The editor itself can track "actual" line lengths for when the thing is written to disk.



Then you allocate one bank at a time, with each bank representing appx 100 lines or so

Exactly. 80 is a good limit for this type of editor especially. Create them as pascal-style of strings where each line has a length byte followed by a fixed maximum length then it is "easy" to "draw" the string without actually having to use an actual BASIC string type.

[rje]

Ah, yes, that would work, especially since you want to minimize the binary.

It would go sort of like... well let me do it in C, but you understand what the BASIC would look like:

clrscr(); // forgot the actual name...

for (row=row_offset; row<row_offset+58; ++row) // save two rows for command and status and stuff
{
   poke 0, FIRST_BANK + int(row / 100); // overkill
   actual_row = row modulo 100 or something;
   row_length  = 0xa00 + actual_row * 81;
   row_data    = row_length + 1;
   display_row = row + 1 - row_offset; // or something
   for (col=0; col<PEEK(row_length); ++col)
   {
      putcxy( display_row, col,  PEEK(row_data + col) );
   }
}

 

[rje]

Actually, 81 bytes per line, with byte 0 specifying the used length, fits VERY nicely into 8192 bytes.  Use the last 92 bytes for metadata, and you've got 100 lines plus some useful info to boot.

I reserve the last row as a status + command row, but maybe there's value in reserving the first row as well, which would leave the middle 58 lines for scrolling file contents.

[Scott Robison]

I think I've done all I'm going to do with BASIC PREPROCESSOR with the update just posted. It's not the prettiest or more friendly tool ever, but it works.  I uploaded another sample that generates Armstrong numbers just as an illustration of labels and "long" variable names.

If you're curious: An Armstrong number is a number such that the sum of the digits raised to the power of the number of digits is the original number. For example:

123 is not an Armstrong number because 1^3 + 2^3 + 3^3 = 36, and 36 is not equal to 123, the original number.

153 is an Armstrong number because 1^3 + 5^3 + 3^3 = 153, and 153 is equal to 153, the original number.

They are not useful, just interesting and a bit of a "hobby" of mine since I was first introduced to them in college. Finding efficient ways to test all possible numbers for Armstrongness is an interesting exercise in algorithmic analysis, especially when you consider that Armstrong numbers can be up to about 60 digits long (theoretically, in base 10).

[Scott Robison]

Okay, now I've done all I'm going to do with BASIC PREPROCESSOR. It's not the most elegant thing in the world, but it's a stepping stone. ?