Disabling the built-in E: editor

[XL Freak]

Hello all. I'm going to try my hand at a little cheesy full screen, single line editor in assembly, and don't want the E: editor (which is painfully slow and doesn't conform to single line mode) in the way. Can I simply close it using a CLOSE #0? Or is it more involved than that?

Edited October 19, 2023 by XL Freak

[TGB1718]

If you're not using it, you can just close it and use your new code.

Although if you plan to use your new editor in something like BASIC I think BASIC will open

channel 0 by default and don't think it will allow you to close it.

It may be that other languages/utilities will do the same.

[Rybags]

Close is the easy bit.

Various things can open it agan - warmstart of course, and if you're in Basic or many other language processors, an error condition or program ending.

Returning to Dos from an application also.

 

Are you replacing E: or just employing code that does the IO processing all by itself?
In theory you could still use K: to get the keystrokes then just deal with them as you like.

[XL Freak]

I would just leave it alone and coexist peacefully in parallel beside it, bit I can't have it processing keystrokes and replicating what I'm doing. perhaps I need to find a way to trap the keystroke vector, grab the key value and exit out of the vector routine without giving the rest of the os, ie. E:, a chance to have them

[Rybags]

E: only gets to do such processing if it's asked to.

In a user program situation that involves calling CIO with the appropriate channel opened already.

 

All that's needed here is to close IOCB #0.  In fact you could get away without doing that so long as you can guarantee that CIO won't be called to do E: output.

A quick and dirty way to mark an IOCB as closed is to just put value $FF into ICHID ($340 in this case) - this serves as index into the handler table to tell CIO which device is open on the IOCB, value $FF flags that the IOCB is closed.

[TGB1718]

Maybe just change the vector to your code in HATABS at $31A, so close channel 0, then

change the vector and re-open using your code.

 

Just had a quick look and it does look like SDX does already do that, the E: handler is pointing to

a low RAM address, not the system ROM and it's using that address even in BASIC.

Edited October 19, 2023 by TGB1718

[XL Freak]

8 hours ago, Rybags said:

E: only gets to do such processing if it's asked to.

Hmmm... I'll look into that. It may be I just need to ignore it lol

 

8 hours ago, Rybags said:

All that's needed here is to close IOCB #0.  In fact you could get away without doing that so long as you can guarantee that CIO won't be called to do E: output.

It's not the E: output I'm concerned with. It's the input. after 38 characters, the cursor drops to the next line and continues the first line on it. And the third line as well, all making one logical line of input text. My "editor" will be single line, and I don't want my own input, hijacked by E:, thinking it's ok to continue a line by inserting a blank line below it. Once a  character in my editor reaches the 40th position (mine will use all 40 chars; no 2 char left margin) it will just stop accepting input on that line. I hope this makes sense.

 

8 hours ago, TGB1718 said:

Maybe just change the vector to your code in HATABS at $31A,

I don't want to use the E: device in any way. My code will have it's own way of dealing with situations.

 

I appreciate the input from everyone. If you're curious what I'm doing, I'll be attempting to make a full screen editor for an assembler, that I'll write later, that doesn't use line numbers. I detest line numbers. I've spent the past several years developing some Android apps, using a derivative of basic for the modern world that doesn't use line numbers. That's where I will eventually be going. But first, the assembler. All this for the new Antonia 4Mb upgrade that's in the mail headed my way. When the assembler is finished, I plan to use it to write a new modern hyper-fast RISC styled Basic that has an inline assembler that can be used to extend the language via libraries that can be shared amongst the community. For example: Don't like the included Player Missile functions contained in the included Graphics library, you are free to write your own, 😃 and even share them. And the full screen editor for the Basic will be 80 columns per line displayed in a 40x24 window, scrolling sideways as it needs to. Since there will be only a single command allowed per line, 80 columns will be most sufficient. I suppose it could even be extended to 120 columns quite easily, if needed. That's where all this is headed lol

Edited October 19, 2023 by XL Freak

[dmsc]

Hi!

2 hours ago, XL Freak said:

Hmmm... I'll look into that. It may be I just need to ignore it lol

 

It's not the E: output I'm concerned with. It's the input. after 38 characters, the cursor drops to the next line and continues the first line on it. And the third line as well, all making one logical line of input text. My "editor" will be single line, and I don't want my own input, hijacked by E:, thinking it's ok to continue a line by inserting a blank line below it. Once a  character in my editor reaches the 40th position (mine will use all 40 chars; no 2 char left margin) it will just stop accepting input on that line. I hope this makes sense.

You don't need to "use the E: editor" to read from keyboard and write to the screen. But using the E: device to write to the screen has the advantage of supporting existing 80 column devices; and using the K: device to read from keyboard has the advantage of automatically processing all the keys.

 

The full-screen editor in FastBasic - that also does not use line numbers and support up to 255 characters per line (scrolling the line if necessary) works that way, it reads from K: on input and writes the E: on output, handling all the screen details. A full screen editor - with char/line insert/delete, copy-paste, loading, saving, page-up/down, at less than 1000 basic lines: https://github.com/dmsc/fastbasic/blob/master/src/editor.bas

 

But, as you say, the main limitation of the built-in E: device is the speed, it is very slow. This can be alleviated with a "screen accelerator", but doing all the output directly to the screen from assembly would be faster. In the case of the FastBasic editor, it was written to be as small as posible, and IMHO it is fast enough for typing small to medium size BASIC programs, and as you can compile and run from the editor it is nice that uses very little RAM.

 

Have Fun!

[reifsnyderb]

Yes, please use the E: device.  The 80 column 1090 boards support E:.  Thank you!

[Rybags]

You might get away with using K: and S:

 

The problem with S: though with Gr. 0 is that it will still do line insertions when your output exceeds column 39.

A potential fix but then your program will be XL only - set the screen mode to 12 which is the same architecture but doesn't do the unwanted line inserts.

 

Quick example:

10 CLOSE #16
20 OPEN #6,12,0,"S"
25 POKE 87,12
30 POSITION 8,1:? #6;"ABCD";
40 POSITION 38,0:? #6;"12345";
999 GOTO 999

 

Try changing line 25 - value 12 or 0.  With 0 it will do line insertion, with 12 it won't.

You have to press Reset once the program finishes.

 

Edited October 20, 2023 by Rybags

[XL Freak]

50 minutes ago, dmsc said:

But, as you say, the main limitation of the built-in E: device is the speed, it is very slow.

Yes.... The purpose of this "first run" editor isn't to display tokenized data, such as Basic, which adds to its slowness. Rather, when a text file is loaded into memory, the editor, using a Gr.0 screen, will be a slidable window through the file. The only real processing will be adding blanks to the end of each line after the EOL has been found. Character by character, line by line. Moving the cursor on the screen causes no processing at all until a line is changed and the cursor moved off that line, then the old line in the file is replaced with the new lines text. So far so good, ML can do this while taking a nap lol. But, move the cursor to the top line, then tap the Control-UP arrow, and now you have to fast-move the top line through the next to the bottom line to replace the lines: top line plus one through the bottom line, then redraw the top line, update some indexes and your done. Same with moving down through the text file. But... when Shift-Control-UP and Shift-Control-DOWN arrows are used, simulating Page Up and Page Down, I'm sorry, but I don't think the E: or S: devices are up to the task. I truly believe it'll have to be handled through raw ML working with the data and memory directly. But we'll see. I'm on pins and needles waiting for my Antonia. My 130XE is ready at the shop after having the CPU socketed, and I can't go get it till tomorrow afternoon. -- But... as the author of a wickedly fast and well established Basic programming language, I really appreciate your input.

 

32 minutes ago, reifsnyderb said:

Yes, please use the E: device.

Perhaps later... My experiments will be mainly geared to computers sporting the 6502's big 16-bit brother the 65816 with 4mb or more of linear ram.

 

13 minutes ago, Rybags said:

The problem with S: though with Gr. 0 is that it will still do line insertions when your output exceeds column 39.

A potential fix but then your program will be XL only - set the screen mode to 12 which is the same architecture but doesn't do the unwanted line inserts.

XL only? I have an XE. And you described the exact condition I'm trying to avoid: Inserting blank lines because that's what it's programmed to do. I think loading and storing directly from memory in a file to screen memory is my best bet, as described above, I'm hoping to get instantaneous Pg Up and Down. It's going to get interesting when I need to escape from the editor to say the load/save file browser. I guess I'll have to re-open the editor lol

[dmsc]

Hi!

5 minutes ago, XL Freak said:

Yes.... The purpose of this "first run" editor isn't to display tokenized data, such as Basic, which adds to its slowness. Rather, when a text file is loaded into memory, the editor, using a Gr.0 screen, will be a slidable window through the file. The only real processing will be adding blanks to the end of each line after the EOL has been found. Character by character, line by line. Moving the cursor on the screen causes no processing at all until a line is changed and the cursor moved off that line, then the old line in the file is replaced with the new lines text. So far so good, ML can do this while taking a nap lol. But, move the cursor to the top line, then tap the Control-UP arrow, and now you have to fast-move the top line through the next to the bottom line to replace the lines: top line plus one through the bottom line, then redraw the top line, update some indexes and your done.

In the FastBasic editor, the scroll-up and scroll-down are very easy, as they use the E: operations (insert/delete line, printing an $9C or $9D character at top of the screen), the only "slow" part is searching for the start of the previous line, but as most of the lines are short, this is fast enough, see https://github.com/dmsc/fastbasic/blob/master/src/editor.bas#L421 for the code. Also, FastBasic maintains an array with the pointer to the beginning of each line in the screen - this makes the up/down movement inside the the screen a little faster and avoids searching the end of the screen when you delete a line at the middle.

 

5 minutes ago, XL Freak said:

Same with moving down through the text file. But... when Shift-Control-UP and Shift-Control-DOWN arrows are used, simulating Page Up and Page Down, I'm sorry, but I don't think the E: or S: devices are up to the task. I truly believe it'll have to be handled through raw ML working with the data and memory directly.

FastBasic implementes page-up and page-down as pressing 20 times cursor-up or cursor-down respectively, an depends on those operations being fast enough. Using the EFAST accelerator, I think is confortable for an editing session, here is a little demo of the speed using original hardware (it is faster with Altirra OS replacement ROM):

 

 

Have Fun!

[XL Freak]

1 hour ago, reifsnyderb said:

Since the first run code will run in a normal Atari computer, if the speed is up to my expectations, I see no reason an 80 column patch couldn't be applied. So keep the faith, if it runs as expected, I'll share the source with you.  

[XL Freak]

29 minutes ago, dmsc said:

the only "slow" part is searching for the start of the previous line, but as most of the lines are short, this is fast enough ... Also, FastBasic maintains an array with the pointer to the beginning of each line in the screen - this makes the up/down movement inside the the screen a little faster and avoids searching the end of the screen when you delete a line at the middle.

I liked the demo you provided. The Pg Up/Down isn't really that bad, but man that's a lot of work and overhead. Were you to just redraw each new page instead of shifting it 20 times, it'd be real close to instantaneous. But you'd lose that little 'jiggle' 🤣. As a serious coder, it wouldn't be fast enough for me. But it might if you just did a total redraw.

 

Another concern, the array you're using has a space overhead of 1k per 500 lines. Have you seen any issues there? I will put it in mine because, 1) it's a fantastic idea, and 2) the target audience will have more than enough memory to support it.

Edited October 20, 2023 by XL Freak

[dmsc]

Hi!

1 minute ago, XL Freak said:

I liked the demo you provided. The Pg Up/Down isn't really that bad, but man that's a lot of work and overhead. Were you to just redraw each new page instead of shifting it 20 times, it'd be real close to instantaneous. But you'd lose that little 'jiggle' 🤣. As a serious coder, it wouldn't be fast enough for me. But it might if you just did a total redraw.

Yes, but FastBasic is not fast enough - so a full redraw is slower than the scrolling, you can see in the video a redraw when i do a go-to-line 100. Old versions did redraw on page-up and page-down, but I simplified the code by doing the multiple cursor-up and cursor-down instead.

 

1 minute ago, XL Freak said:

Another concern, the array you're using has a space overhead of 1k per 500 lines. Have you seen any issues there?

No, I don't store a pointer to each line, only to the lines that are visible in the screen, exactly to avoid the space overhead. When you do a go-to-line, the code searchs the line from the start of the complete buffer. And I'm thinking of also eliminating the array of lines on screen, and simply search backwards and forwards for the next EOL on each cursor-up and cursor-down, to make the code smaller - I have to see if the editor feels slower that way.

 

1 minute ago, XL Freak said:

I will put it in mine because, 1) it's a fantastic idea, and 2) the target audience will have more than enough memory to support it.

The slowest part of the editor is adding or removing lines at the start of a big buffer - as you have to move the full buffer memory. This is mitigated in the FastBasic editor as each line is edited in a temporary 256 byte buffer, and it is only inserted in the text when you change the line. This also allows implementing the "UNDO" as simply dropping the modified line buffer - so you can only undo the editing on the last line.

 

Have Fun!

[XL Freak]

5 minutes ago, dmsc said:

I don't store a pointer to each line, only to the lines that are visible in the screen

I see. That actually makes more sense from an 8-bit, 64k point of view.

 

7 minutes ago, dmsc said:

a full redraw is slower than the scrolling

But doesn't FB use raw text, rather than a binary tokenized file like Basic? It's all in my head right now, but it seems like a redraw would be much faster than 20 full-screen scrolls.

 

11 minutes ago, dmsc said:

The slowest part of the editor is adding or removing lines at the start of a big buffer

Yes, I agree. But in ML, you can move a page of memory wicked fast. And Basic's EXPAND and CONTRACT ML routines simply do multiple page moves.  In my head I'm thinking that in Basic if you have a very large Basic program, and it is getting close to running out of memory, and you type in a new variable on a new line, it has to do 3 memory moves: 1) to expand the VariableNameTable, 2) to expand the VariableValueTable, and 3) to expand the StatementTable. And it does all 3 memory moves in excess of 20-30k EACH before you can blink an eye.

 

I keep forgetting your editor is programmed in FB, which is a marvelous achievement on its own, no doubt.

 

2 hours ago, dmsc said:

The full-screen editor in FastBasic - that also does not use line numbers and support up to 255 characters per line (scrolling the line if necessary) works that way, it reads from K: on input and writes the E: on output

How do you cause a very long line to scroll using the E: device instead of dropping down, inserting a blank line and continuing? This is confusing lol. Unless it has something to do with EFAST.

[dmsc]

Hi!

On 10/19/2023 at 11:28 PM, XL Freak said:

But doesn't FB use raw text, rather than a binary tokenized file like Basic? It's all in my head right now, but it seems like a redraw would be much faster than 20 full-screen scrolls.

Yes, the editor uses raw text. Redraw is slow because for each line, the editor does:

- Calculate the line length (by searching for the next EOL),

- Setup DSPFLG and CRSINH to print control characters and hide the cursor

- Move cursor to the line position

- Print the portion of the line that fits in the screen width

- If the line length is more than the screen width, print the portion of the line that fits and a right arrow.

- Else, print spaces until the right margin (to erase old characters in the screen)

- Restore DSPFLG and CRSINH.

 

Some of the functionality is not needed when you are redrawing the full screen, but the editor uses the same procedure to draw one line, so it must do the full drawing. And yes, in ML and writing directly to the screen it would be faster.

 

On 10/19/2023 at 11:28 PM, XL Freak said:

Yes, I agree. But in ML, you can move a page of memory wicked fast. And Basic's EXPAND and CONTRACT ML routines simply do multiple page moves.  In my head I'm thinking that in Basic if you have a very large Basic program, and it is getting close to running out of memory, and you type in a new variable on a new line, it has to do 3 memory moves: 1) to expand the VariableNameTable, 2) to expand the VariableValueTable, and 3) to expand the StatementTable. And it does all 3 memory moves in excess of 20-30k EACH before you can blink an eye.

Not really 🙂

 

Copying a byte in 6502 assembly is basically about 16 cycles (using indirect addressing and one byte per iteration).

 

Suppose that you are at the start of a 10K buffer. Then, to insert one byte, you need at least 160000 cycles. As the CPU in graphics 0 runs at about 1.16M cycles per second, this means you can only insert characters at 7 char/second in the best case. This will feel slow. And with a 30k buffer, you are at 2.5 chars/second, very slow.

 

So, by only modifying the current line, the editor feels a lot faster.

 

On 10/19/2023 at 11:28 PM, XL Freak said:

I keep forgetting your editor is programmed in FB, which is a marvelous achievement on its own, no doubt.

Thank you! But it is not that difficult, the only tricky part is making it small and memory efficient.

 

On 10/19/2023 at 11:28 PM, XL Freak said:

How do you cause a very long line to scroll using the E: device instead of dropping down, inserting a blank line and continuing? This is confusing lol. Unless it has something to do with EFAST.

As I explained above, the editor processes the keys on input and redraws the whole line on each change. Basically, when you press a key, the editor reads the key, inserts it into the line buffer, and then redraws the line - this ensures that the line is always drawn correctly. The E: device is only used for screen output, not for input.

 

Have Fun!

[XL Freak]

I'm starting to wonder if we're talking about different things. I wasn't talking about EXPANDing a 30k buffer one character at a time to replace altered text, agreeably that'd be awfully inefficient. I was just making a point that Atari Basic moves massive amounts of memory around all the time, both in editing and execution, and it's not even noticeable. I agree with you that altered text should be replaced as an entire line, not char by char. So in my head, I see the user typing away and the update doesn't happen until something causes the cursor to leave the current line, then it is saved to the buffer. Just like Atari Basic, this ONE TIME event goes by unnoticed.

 

Paging through the text is another ordeal altogether. For each PgUp/Dn, you'd have a maximum of 960 bytes to transfer from the buffer to the Gr.0 screen memory, plus all the conditions you mentioned, no matter the language used. I thought you might be exaggerating when you said 16 cycles for a byte move. Nope, I did the math and 16 cycles is dead on. If you're just moving 960 bytes of data once, not moving a 10k buffer, you'd need 15,360 cycles, just say 16k cycles to add a little to setup the move. Plus you'd need to add in for the line setup you mentioned, and I have no idea how much, but even if it were a 1000 cycles per line, that'd be 20k plus 16k = 36k, divided by 1.6m is 0.0225+/- seconds for a PgUp/Dn redraw in assembly. Unless the math is extremely flawed, that's over 44 redraws a second. That's freeking fast!

 

Here's some food for thought for you: each line of FB code maxes out at 255 chars. Not a bad number. So each line is 6.375 40-column chunks wide, per se'. A Gr.0 screen data area consumes 960 bytes, so 6.375 side by side screens would consume about 6k of memory. You could have that 6k screen, each line with it's own dli pointer to it's own 255 byte space in the 6k screen ram, and sideways scrolling would be nothing more than updating 24 2-byte dli addresses, and the entire screen would scroll effortlessly side to side, with much less overhead processing. Add smooth scrolling, and dang-it boy, you got a nice upgrade  

 

Bad news on my 130XE. I don't know what happened, but when I got my motherboard back from the cell phone repair shop for having the CPU socketed, all I get is a dark red screen. I swear my poor little machine spends more time broken or waiting for upgrades than it does working on my desk. This is kinda starting to suck lol...

 

anyway, thanks for letting my mind run loose. I've got to get up early, so I'm out for the night. Thanks for chatting...