Anyone write a text editor for the Propeller ?

Bean · 2012-07-18 10:54

I need a simple text editor for PEBasic and I didn't see one in the OBEX.
So I thought I would whip one up in spin, but it's not as easy as I thought it would be.

Has anyone written one ?

Bean

David Betz · 2012-07-18 12:10

Bean wrote: »

I need a simple text editor for PEBasic and I didn't see one in the OBEX.
So I thought I would whip one up in spin, but it's not as easy as I thought it would be.

Has anyone written one ?

Bean

Isn't there one that is part of Sphinx that you can steal, I mean borrow?

Publison · 2012-07-18 12:40

Didn't Rick (Casslan) start writing one:

http://forums.parallax.com/showthread.php?112344-Coming-soon-to-a-Prop-near-you-PrEditor&highlight=Editor

Where has he been lately?

Dave Hein · 2012-07-18 12:45

You could use the vi editor attached below. If you build it with BSTC using the script in the zipfile it's about 22K in size. If you don't need the file I/O you could remove about 5 or 6K from that. Most users aren't familiar with vi, so you would probably need to modify it with a more user-friendly interface.

Rayman · 2012-07-18 12:53

Dave, vi looks nice. Is this a direct port from C source code using cspin?

(comments say so, just want to make sure.)

Another question... This is for editing over serial connection to a terminal program on a PC, right?
It can't use connected VGA and keyboard (?)

mindrobots · 2012-07-18 13:00

Bean,

This showed up in your "similar threads" - it might give you a skeleton to incorporate into PEBasic.

Dave Hein · 2012-07-18 14:31

Rayman wrote: »

Dave, vi looks nice. Is this a direct port from C source code using cspin?

Another question... This is for editing over serial connection to a terminal program on a PC, right?
It can't use connected VGA and keyboard (?)

I wrote the original version in C and then used cspin to convert it to Spin. However, the Spin version has diverged from the C version, and I need to port those changes back to C at some point.

This version only works with a serial port. I was working on an 80x24 character VGA driver a few months ago, but I put it aside for a while. I hope to get it working with VGA and a keyboard in the future.

jazzed · 2012-07-18 14:58

Hi Dave.

Any pointers on changes to use vi without SD card?
Thanks.

Dave Hein · 2012-07-18 15:46

Here's a version without file I/O. I kept the ReadFile and WriteFile routines, but commented out the file I/O code. This way other file storage code could be added to store to something like EEPROM. I also include clib.spin, which is used instead of clibsd.spin. Just copy these to files to the same directory as the other vi files and build vi1.spin.

msrobots · 2012-07-18 15:58

Spinx has a nice Editor called ED.

I think Phil already adapted it for VGA-basic? look there too...

Enjoy!

Mike

Phil Pilgrim (PhiPi) · 2012-07-18 17:26

I didn't write Sphinx or ED, or adapt either one. That was all done by Michael Park.

-Phil

Bean · 2012-07-19 04:01

Thanks for all the suggestions guys.
I need something really small though. Maybe I'll try that "Split-buffer" method that was mentioned.

I'm using the vga_hires_text because I need to support 640x480. This gives me an 80x40 character display.

I'll post whatever I get working.

Bean

Bean · 2012-07-19 07:30

Here is what I have so far. No scrolling yet, but everything else pretty much.

Uses Propeller Demo board, VGA and Keyboard

Comments welcome...

Bean

LoopyByteloose · 2012-07-19 09:49

I wonder if Nedit C code in Linux could easily be ported over to the Propeller? I have been using it quite a bit as a simple editor and it already supports a lot of programming languages as an added feature.

Traditional Linux/Unix editors such as Vi and Nano may be a bit annoying to the uninitiated, but Nedit will do a generic ASCII file in a simple and direct manner. I imagine the C-code could be a useful place to start even if you don't use the whole thing.

http://www.nedit.org/

OR take a look at Nano, it is not an X-Windows editor - just generates ASCII for a Terminal window in Linux.

http://www.nano-editor.org/dist/v2.2/faq.html#1.3
http://mintaka.sdsu.edu/reu/nano.html

pik33 · 2012-07-19 10:05

What kbd driver it uses?

Edit: I managed to run it with keyboard driver from femtobasic. It works

Rayman · 2012-07-19 10:15

I like the split buffer idea that rockiki mentioned in the other thread. Is that what you are doing Bean?

Still, it seems that if you have an SD card in the system, you could just use HUB ram as a change buffer with the original file on SD card. Then, every once in a while, write the updated file to SD and clear the change buffer... Then, you could edit arbitrarily large files (right?)

pik33 · 2012-07-19 10:28

Right; having SD you can edit near unlimited (up to 2GB) files... and this is a good idea...

jmg · 2012-07-19 20:22

Bean wrote: »

Thanks for all the suggestions guys.
I need something really small though.

I'm intrigued - why do you need a Text editor in a Prop ?

Is this as a Source Code editor for a Basic (or similar) ?
So you are targeting something like the first Turbo Pascal, which I think included Editor/Debug/Compiler in ~39K ?
Might be a tad tight on a Prop 1, but certainly doable on a Prop 2.

Phil Pilgrim (PhiPi) · 2012-07-19 20:30

It's totally doable on the Prop I. Remember, TRS-80 Level II BASIC for the Z80 fit in 12K of ROM and included floating point, dynamic strings, and garbage collection. But, it's 2012 now; that was in 1983, which begs the question: why?

-Phil

potatohead · 2012-07-19 21:19

...or why not?

Bean · 2012-07-20 04:34

jmg wrote: »

I'm intrigued - why do you need a Text editor in a Prop ?
Is this as a Source Code editor for a Basic (or similar) ?
So you are targeting something like the first Turbo Pascal, which I think included Editor/Debug/Compiler in ~39K ?
Might be a tad tight on a Prop 1, but certainly doable on a Prop 2.

Yes for an embedded BASIC for the Prop1.
Needs to run on the Propeller Demo board, so only 32K EEPROM and no SD or SRAM. This is why it must be a very small editor (small in code space terms).
Something like femtoBasic, only (hopefully) much faster and more modern. Closer to PBASIC 2.5.

Bean

pik33 · 2012-07-20 04:45

There is no problem to add a micro sd to a demoboard (I have one connected). All you need is sd/µsd, adapter, 6 pins, 6 wires and a 100 µf capacitor

Then 5 minutes of soldering all of these together.

Rayman · 2013-01-23 09:29

I've been thinking some more about how to implement a text editor myself...
Specifically, I'd like to be able to edit all of the Prop Tool Library files on the Propeller...

I see two problem:
1. Some of these files are >100 kB (much greater than HUB RAM) and
2. Some of these are in Unicode and I'd also like to use Sphinx

I like the split-buffer approach, but I think that is only viable for small text files or with external RAM.
So, the approach I have in mind is to use a list of pointers to lines.
The pointers will either be to the original file data on SD card, or to modified lines in HUB RAM.
So, there will be some limit to the amount of edits possible. The the limit is reached, the file will have to be
saved to SD card and then editing can start again. I'd need some temporary file at this point so as not to overwrite the original.

Problem #2 may not be so bad because I think the Prop tool only allows certain unicode characters. I can easily make a map to
translate these characters into ascii codes. I think I have a font that can show these special characters using a Parallax code page.
If this is true, then I can either save to ascii before calling Sphinx or save back as unicode.

MagIO2 · 2013-01-23 11:18

Have a look at preditor, it uses a gap-buffer to allow editing huge files. That makes it much easier, because using a small buffer means trouble when editing long files at the beginning - remove characters and you have to move the whole end forward, inserting characters and you have to move the whole rest of the file backwards.

Dave Hein · 2013-01-23 11:31

Rayman, I've though of extending my VI editor the way you are suggesting. It makes sense to me. I also use a linked-list to keep track of lines in the buffer. This makes it easy to delete and insert lines.

MagIO2 · 2013-01-23 12:06

Here is a link to a gap-buffer discussion: http://forums.parallax.com/showthread.php/118071-Gap-Buffer-Success!!!?highlight=gap-buffer
And here .. contains some nice ASCII arts that describe the gap-buffer: http://forums.parallax.com/showthread.php/118487-GAP-Buffer-Needed-functions-...and-Display-Portability-Thoughts?highlight=gap-buffer

File editing in Preditor works like that:
There is a SWAP-file which contains the gap-buffer
Load the file into the gap-buffer
Do the editing
When done, save the text from gap-buffer back to the file
Also with gap-buffer a list of linestarts helps a lot. The list can also be created in SWAP-file in gap-buffer style, so that you don't run out of HUB-RAM when editing huge files.

Rayman · 2013-01-23 13:17

I think what I'm thinking of is a doubly-linked list of pointers to either SD data or HUB line buffers.
Maybe implementing the HUB line buffers each as a split buffer.

MagIO2, that gap buffer looks like a refinement of the split buffer. It would still require a lot of RAM to edit a large file, right?
Looks like you were going to do it by writing back to SD every time the cursor moved to a new line, is that right?

It just occurred to me that when my HUB line buffers get full, maybe I can append them to the end of the SD file that I'm editing. Need to see if I can then simply resize the file, if I don't want to save the edits... Or, maybe I'll create a new file just for the temporary edits. I think fsrw will let me open two files for reading at the same time. So, my doubly-linked list could point to original file on SD, scratch file on SD, or HUB...

MagIO2 · 2013-01-23 14:46

No RAM, the gap-buffer that is used by casslan used my vMem extensions for FSRW, so, yes it's using SD. But it only writes back if the sector is exceeded AND if something has been changed in the sector.
This means scrolling forward, insert a character, scrolling backward, inserting a character, scrolling forward, insert ..... is the worst case scenario which would write each sector after you scrolled through it.

But the same vMem functions could also be used with a SPI RAM-Driver, which still would make the Editor code easier, as the whole SWAP-stuff is separated in the vMem-code. The editor would simply work on a linear huge address-space.

Rayman · 2013-01-23 15:00

MagIO2, Did you get an editor working already with this approach? It sounds in a way like what I want to do...

Rayman · 2013-01-23 18:06

Just had another thought (beer helps)...
I was thinking that one thing that would be hard to do is select a large block of text with the mouse and then cut and paste somewhere else...

But, maybe the copy or cut operation could just create a file on SD called "clipboard.dat" that held the data...
If it were used, it would then be appended to the scratch file first...

MagIO2 · 2013-01-23 21:39

Preditor is using this approach.

For cut and paste, just reserve another section in the swap-file.