_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Regarding storage for lines that are not currently being edited - and this is probably taking things too far! - it strikes me that you could even compress the data for these lines. Then I wondered whether contemporary tools like View actually did that...

Attached is a simple demo (animated) GIF of what my text editor is looking like right now.

Pretty much all of the normal keys do what they should do. Return, Backspace, Tab, Delete, Arrow Keys, etc. I have not yet implemented Home, End, Page Up, or Page Down. The Pages will have to wait until I can get my screen scrolling vertically. I'm thinking of using Insert for the "Defrag" process.

You can see the delay between hitting Return and Backspace. Those two keys in particular refresh the entire screen. So, what's taking so long is not the moving of data, it's just retyping each character on the screen, including blank characters. I'm thinking of ways to optimize this, but I also need to consider the vertical scrolling I will need to implement as well.

Note that this is all in my Simulator, not on real hardware at the moment. Oh, and you don't want to see my code because there's zero comments and it's designed for my homemade '816 Assembler.

Thanks for all of the help everyone! Looking good!

Chad

So far so good... but now is the right time to consider how it might deal with larger texts!

Neil

Looks good to me, for general editing - plenty responsive enough! Of course, more responsiveness is always better, but there are diminishing returns beyond where you are now I think.

For the insert/delete line cases, you can probably make them quite a bit faster, at the extreme by using unrolled loops with absolute indexed addressing. And at least these won't get worse for longer documents, if most of the cost is moving data on the screen.

I think, at this point, I'd suggest splitting the editor and framebuffer support out and treating them as 2 separate entites:

• An operating system (or monitor if you like that sort of thing) function that does the screen/frambeuffer handling.
• Many applications all using the same OS/Monitor calls to do their screen handling for them.

And this is nothing new - early 6502 systems I used - the Apple II and the BBC Micro both did this - the Beeb in a much more "thorough" way, but that's the advantage of 4 years later, faster clock and more ROM...

And think of all those systems with terminals, printing, "glass ttys", vt100s, and whatnot...

My own Ruby does this too - although it has to by virtue of using a serial line to the framebuffer - the question might be how do you control the FB - do you have OS calls (Like the apple II to clear screen, position cursor, etc.) or do you output control codes (Like the Beeb).

The control code method has the advantage that you can then hook up a serial terminal if so desired...

The question then is what codes? Go all-out and go for ANSI/vt100 or something else?

Some time back I ported my RubyOS to the Cerberus 2080 system - it has an on-board framebuffer. I opted to keep the same control codes for applications and write a separate framebuffer handler. This hooks into the "putchar" mechanism and interprets the codes. The Acorn/BBC Micro ones are fairly simple (at the text level). The important ones are clear screen (12), move home (30) and move to XY (31, X, Y) The other usual ones - move cursor to start of line (CR, 13). Move cursor down a line (LF, 10 - causes a scroll if moving down from the bottom line) move cursor up a line (11, VT, scrolls the screen down a line if on the top line), left and right (8, 9). There are a few others (colour, graphics), but that's enough to make a working screen.

So even though it could, an application (e.g. BBC Basic) could poke pixels/characters at the screen, it doesn't - it just prints it and lets the operating system do the hard work. This may seem a bit odd when the code and framebuffer are all in the same memory space, same CPU but the Beeb was designed to have a 2nd processor, leaving the original one - the host - to handle screen, keyboard, filing, network, etc. with your code running on the 2nd processor. (And people are still using this today with more and more new 2nd processors coming on-board inlcuding the '816, RISC-V, PDP11, etc.)


What's missing in the Acorn/Beeb codes that's handy for an editor: clear from cursor to end of line and clear from cursor to end of page. Those can help an editor or other application manipulate text on the screen. I added them into my system - BBC Basic doesn't use them, but C (on the 6502) and BCPL (on the '816) applications can.

The up-shot of my Cerberus port was that BBC Basic "just worked" and all it's built-in commands like CLS, etc. worked as intended. (as they do on my Ruby system). the Ruby system has the advantage of having the framebuffer run on my Linux desktop and is written in C, but there is still that 115K baud line going into it.

And it's not that hard to translate Acorn/BBC code into ANSI codes - my ATmega "host processor" does that transparently, so I can hook up a terminal to it and the BCPL editor works as normal - as does BBC Basic...

So - separating the video/framebuffer code and you're starting to build on the monitor/OS - and you can make that code as optimal as possible. Scrolling an 80x32 text window can be blindingly fast when you keep a list of screen line start addresses and unroll the loop. applications can be smaller as the OS the offloading the IO functions more efficiently and life is fun...

And as part of something I'm working on, I have a 20x4 LCD hooked up to the Ruby board and I adapted my framebuffer code for that (and make it fairly generic), so I have in RAM a 20x4 byte framebuffer and I can write into that which then gets copied over to the LCD - it's not slow either and it means I can scroll the LCD up and down, move the cursor, make my editor work on it and run BBC Basic on it. The applications stay the same.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I am personally biased against ANSI/VT100/VT52 control sequences. They come from the days when serial communications use 7-bit quantities.

As anyone who has dealt with them know, it is expensive converting binary numbers to ASCII decimal and back.

There are many other popular terminal control sequence sets such as ADM3A, Televideo 950, IBM 3101.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Indeed.

I do think the Acorn/BBC Micro one is very simple though - the only complex one is move cursor - 3 bytes and X and Y are binary. This does mean that you need an interface that's fully 8-bit clean and that characters won't be mis-interpreted mid-stream.

Full list here:

https://beebwiki.mdfs.net/VDU

the other way is faster which is to have a callable API style interface (faster on the native system that is) - which is how I do it from BCPL - I have a 'vdu' library which BCP programs call and that library then does what's needed - on the Ruby platform it outputs the Acorn/Beeb VDU commands - obviously it's actually slower but it gives the BCPL programs a common interface library no matter what platform they are running on.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Well, I have a word of advice: Make sure you have a system monitor available to use before attempting any big software projects!

So I made a function to clear up all the unwanted, old, and obsolete lines in memory. It works... mostly. When it doesn't work, I don't know why.

If I could SEE the memory being moved around and all that, then it would much easier to diagnose problems! I can add a feature into my simulator for that, or make one in assembly code, but either way that will take time away from doing this project. I wish I would have made one before starting this

Well, there's my word of advice for the day. Yay!

Chad

Whenever I start creating an emulator, I always begin with a debugger. Fundamental commands to load a program, unassemble code, view and modify memory and register contents, single stepping and breakpoints. Only then do I begin implementing simulators for machine instructions.


I have decided that DOS is the most universal platform for my tools. I had thought that 32-bit Windows was universal with things like Wine, but there appears to be many problems with that approach.

Meanwhile, DOSBox is available on most modern platforms, including, I recently discovered, ChromeOS.

A recent feature in DOSBox-X caught my attention - the ability to create a second window for a Monochrome Display Adapter (MDA)

The main window shows the debugger and output written to the primary virtual serial port. Output to a second virtual serial port goes to the MDA window - I can include special code in my programs to write debugging information to that second port. I have a DOS TSR from way back called SNAPSHOT which copies the contents of the main screen to the MDA in response to a hotkey combination. I have also implemented commands in my debugger to route output to the MDA window.

As an aside, I was contracting to a company once and had to help interview to find my replacement (full-time rather than contract). There was a programming task and I was explicitly instructed to show anyone the door if they opened a debugger first. They wanted people who could think and problem solve rather than rely on a debugger..

My own methods work like this (probably why I got that gig in the first place) I don't have a (machine code) monitor in any of my systems and have not fond it a hindrance when developing RubyOS - about 10KB of 6502 (with a few '816 nods now) nor the 16K of BCPL CintcodeVM in '816 assembler, nor the 4K of TinyBasic..

Which is not to say that I write perfect code - far from it, but just that I use different methods and maybe tools (never underestimate the power of a blinky LED!) One thing I have found handy though is a memory dump facility. That's the only thing in RubyOS remotely close to any monitor command. There is no memory modify commands, no way to set a breakpoint (and anyway, BRK is used to print error messages) nor disassemble. (I have the source code, so no need).

There are arguments for moving to high level codes too - I'm not sure I'd have had the enthusiasm to write my editors in 6502 assembler - the BCPL one runs fast enough and I'm often pondering over issues like this and wondering if we're being somewhat artificially held-back by those who want these things because they need and/or use them (which is fine) or because aye been.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Getting an emulator running properly is majority reverse engineering the software I am trying to run in it, so the debugger is essential.

I also must strongly disagree on the grounds that stepping through code in a debugger and verifying that values in variables and registers are what I expect is very valuable for testing.

Do you feel the same way about a programmer whose first response is to sprinkle "print" statements in the code instead of carefully reading it first?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The sneakiest bug I had to trace was in the program editor of VTL02, and it was a copy loop that moved one extra byte but did it in a way that corrupted the text very gradually, and only in certain cases. I think the C=64 had a very subtle screen editor bug too, that could be activated by a very specific sequence of events and cause a crash. I used Apple Writer II for many years, and I think I was able to trigger a word-wrap bug once by accident, but it was so accidental that I was never able to repeat it, accidentally or otherwise.

I squashed my VTL02 editor bug with the Apple ][+ monitor, my old trusty friend. Thanks for CALL -151, Woz! Or, in the case of VTL02:

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)