Text Editor Shifting Mechanics

[IamRob]

I agree. The monitor listing is an indespensible tool. Nowadays though, 99% of my errors are because I forgot some syntax in the way my Assembler works, or my typing can't keep up to my brain and I drop an important instruction. Damn serial connection from my brain to my hands isn't fast enough.

[GlennSmith]

Hi all,
The earlier comments about VT100 and so-on reminded me of the most amazing editor that was distributed with the HP1000 minicomputers. It depended upon the proprietary HP terminal escape codes, but the low-down was that you used the TERMINAL as the editor, in screen mode (some of the more expensive HP terminals had over 4 80-line pages) and you could type anywhere on the screen, insert, delete, scroll, copy & paste to you hearts content. When you wanted, you typed a simple control sequence (this was back in the very early 1980s - I can't recall what the sequence actually was) and the terminal read the entire screen (all n pages) and transmitted it back as normal ASCII text.

It was amazingly fast, and 'my' HP1000 5I was system mgr.) had over 20 users connected plus all of the number-crunching going-on in the background. I wrote 1000's of lines of assembler and Pascal with that editor.

I haven't really studied VT100, but I seem to recall that there are commands for reading back a line of text from the current cursor position. That basically all you need above the normal cursor positioning commands...

I was thinking of going down that road once I've got the WBC V1 up and running, and chosen a suitable VGA interface for it.

Well, that's my 1€'s worth. Happy new year to all.

(Edit. thinking about it, it is more probable that the terminal only transmitted line-by-line and the HP1000 editor linked the text correctly into the textfile, and sent the relevant escape codes)

[gfoot]

I used to pride myself on being able to debug without a debugger, and spotting bugs without compiling the code, and it's a valuable skill. And there are things you can find using old fashioned tools like printf or other logging statements that are harder to find with a debugger - having a log of the system activity over time is very valuable. But there are also times when knowing how to make best use of more modern tools will lead you to a solution much more quickly - I think all of these tools are valuable in practice.

[sburrow]

gfoot wrote:

I think all of these tools are valuable in practice.

Indeed. I might place personal constraints on myself in hardware (and sometimes software), but ultimately it works or doesn't work, and I'd rather it work

Using my mini-monitor-thing for my simulator has helped a lot already. What I was seeing on the screen was fine, but behind the scenes it was chaos! Most of the bugs are fixed, and I'm reworking the 'defrag' next. After that is vertical scrolling, and then I should be done. At least done with the basics, I can go back and do copy/paste commands later if I *really* want it.

Thank you all!

Chad

[barnacle]

sburrow wrote:

but ultimately it works or doesn't work, and I'd rather it work

Tsk, some people want everything!

Neil

[sburrow]

barnacle wrote:

Tsk, some people want everything!

Haha, yep Selfish and stubborn.

But it works now! Attached is my uncommented code, a GIF showing some features off, and then a PNG of what I'd love to eventually be doing with this.

Defrag seems to be working and vertical scrolling is VERY nice. The reason why it's slow to draw on the screen after Return and Backspace, yet fast after Page Up/Down is because it's not redrawing the entire screen each time... it's hardware scrolling! At least that's the plan going forward with my next SBC.

I have a couple more functions I want to implement, but 99% done now. Now, what am I going to use this for? A programming environment! I'm not sure if it will be version of BASIC, C, or something else, but I am planning on not using line numbers.

Well, thank you again, everyone, for the conceptual help. This was really neat Now onto the next thing.

Chad

[plasmo]

Oh, excellent works! I'm happy to see all these solutions toward standalone 6502/65816. The diversity of solution is quite amazing.
Bill

[barnacle]

Also, kudos for using proper Allman braces and proper separation in your fake C

Neil

[sburrow]

barnacle wrote:

Also, kudos for using proper Allman braces and proper separation in your fake C

Neil

But I just realized I needed:

Code: Select all

while (bytes > 0) 

Oops! Good thing it was fake!

Chad

[BigDumbDinosaur]

IamRob wrote:

...99% of my errors are because I forgot some syntax in the way my Assembler works, or my typing can't keep up to my brain and I drop an important instruction.

...and the other one percent of the errors are the ones that have you lying wide awake in bed at 3 AM wondering what the heck is wrong with your code.   Been there many times...and, as Garth has noted when you finally do figure out the problem, you slap yourself in the forehead for having made such a boneheaded mistake.

For the record, about 99.9 percent of my errors are really stupid ones, such as typing TXA when I meant TAX.  With the 65C816, a really insidious one is inadvertently loading a 16-bit register with an eight-bit value, or vice versa, due to faulty instruction syntax.  When that happens, it throws the program counter off by one during program execution and produces some really crazy results that can defy debugging...especially inside of an interrupt handler.    In the Kowalski assembler, and in Supermon 816, all it takes to do that is to forget to use the ! operand modifier to tell the assembler to coerce an eight-bit, immediate-mode operand to 16 bits, or to mistakenly use ! on a operand that is to be loaded into a register set to eight bits.  Been there, done that...innumerable times. 

[sburrow]

I made it SO much faster just now! I added a 4K character 'buffer' in RAM that captures any printed character to the screen. So then in my 'print character' subroutine, I just look at the character in the buffer, compare it with what I want to draw, and if they are the same I just don't draw it.

Further optimizations include eliminating the 'copy' of the text character bitmap on blank characters, just paste $00. I also took my compressed text character bitmap and expanded it to speed up the copy/paste portion, though that did little in comparison to the buffer.

Ok, NOW I'm happy with it

Thanks everyone.

Chad

[BigDumbDinosaur]

!!!BUMP!!!

Wondering if more progress was made on this editor.

[commodorejohn]

I need to have a go at this myself sometime. The solution I've considered for storing in a way that makes insertion and block operations less expensive is to use a linked list of fixed-size chunks that can hold from zero to N characters - you lose some of your available text space to overhead, but insertion never has to move more than N bytes (if you move off the end of one chunk, just insert a new node for the overflow text) and cut-and-paste is just a matter of re-linking and possibly splitting the boundary nodes.

(Copy-and-paste would still be more involved; one might add a flag and extra pointers to the chunk header so that one could alias pasted text to the original chunks and treat it as copy-on-write, but this may be overly complicated.)

Fragmentation would get to be an issue eventually, too; you'd definitely want a defrag function in the memory manager.

[Yuri]

gfoot wrote:

I used to pride myself on being able to debug without a debugger, and spotting bugs without compiling the code, and it's a valuable skill. And there are things you can find using old fashioned tools like printf or other logging statements that are harder to find with a debugger - having a log of the system activity over time is very valuable. But there are also times when knowing how to make best use of more modern tools will lead you to a solution much more quickly - I think all of these tools are valuable in practice.

As I often say, want to use the best tool for the job. The code I work on in my day job still boils down to having good logs when I invariably have to tell a customer why something did (or did not) work the way they expected it to. I tend to shake my fist at the other developers when I run into something they did not add sufficient logging to and it the servers wander off into areas I can't track what's going on. x_X

[stefan1]

Hi,

I know this thread is kind of old, but there’s some recent activity and I find the subject very interesting.

I had thought about this exact problem for years before attempting to write a 6502 based text editor.

It is based on the following model:

- The text buffer is divided into 256 byte blocks.
- Each block starts with a link to the previous and the next block. The lenght of the text in a block is also stored in the block.
- If the link to the previous block is NULL you are at the first block. The link to next block is NULL you are in the last block.
- A block allocation table keeps track of which blocks are in use and which are free.
- When inserting a char, the subsequent text within the block is shifted forward. This is pretty fast, as a block is 256 bytes. If the block is full, the char is pushed into the next block. If that is also full, a new empty block is linked in after the current block. This is also fast as no copying is necessary.
- When deleting a char, the trailing chars in the block are shifted to the left and the block length is decremented. If the block becomes empty it is marked as free.
- A defragmentation routine runs when the editor is idle.

This memory layout works pretty well. There is no noticeable performance hit even when handling large files. The drawback is of course code complexity.