Casslan, ( and all )
I've finally had 5 mins to myself, and done a quick mod to TV_Text demo.
Here's the result.
you can now have 40x30 in NTSC using the ROM Font on TV [noparse]:)[/noparse]
I've attached a pic and the source [noparse];)[/noparse] enjoy.
PS, it's set up for Hybrid at the moment, so clock is 6Mhz, not 5Mhz, can someone test it on a 5Mhz system for me, and let me know if it's fast enough still [noparse]:)[/noparse]
Baggers.
I'm having trouble posting attaching the files, so I've asked Coley to post them for me [noparse]:)[/noparse] ( Cheers Coley )
I'm writing the editing code and WOW, there is so much I generally take for granted in a text editor.
I've been running Edit.Com in DOS in a VM, as well as Notepad in windows to emulate the behaviors I'm going for.
And I'm going to stray from one of Edit.Com/Qbasic's editing behaviors because I don't think its helpful...Example:
If your cursor is on a line(lets say close to the end), and the line above is shorter, when you press the up arrow, I think the cursor should go to the end of the line above you...not into some area of the document that doesn't really exist. Notepad behaves like this, the PropTool does not.
@Baggers- I agree, I could see how for writing code this might be usefull, if your lineing things up that may be separated by a shorter line in between.
@jazzed- ; )
Btw, I started using the PST today..very helpfull. Usually I'll just have a variable print directly on screen for the program I'm working on while figuring things out, and thats usually a byte, word or long..maybe 2 or 3. Working on this project however has given me byte arrays in the thousands...not gonna get too far printing that on the TV on top of the program I'm working on. So instead I've just been creating a hotkey to dump my buffers onto the Serial Terminal, several thousand bytes without even having to scroll ; ), And there is so much formatting utility already built into FullDuplexSerialPlus that I didn't really have to make the tools..just use em.
I'm sure many of you have been using this or something like this forever, but just incase someone hasn't used this technique yet, do yourself a favor and try it. And thanks Parallax for continuing to update/build tools/objects for the prop for free.
The movement of the cursor into the same column above is a carry over from mini and mainframe computers which basically used 80 column cards and later screens to hold the text (source, data or whatever).
When the editors came out (mainly on micros) that held the data in memory, fixed length was not wanted as it wasted space.
Hence, the differences in how editors worked depended on the authors former experience.
These days, my preference is if the cursor is at eol then mioving up/down should go to eol. However, if it is not eol it should go to the same column up or down. Does that make sense?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Just wanted to give an update:
I started putting in the mouse functions since I found a 2nd PS/2 port from an old project, that I threw on the Bread Board, but after a days worth of work on it, I think I need to forget about the mouse and just flesh-out the rest of the keyboard functions, or rather the rest of the functions based on keyboard only for now. This way I can have it done and working, and layer the mouse on top.
Whats left to implement:
Saving with the file dialog box (giving the option to save with a different name)
Block Selection (Shift + Arrow Keys = Highlight)
Cut, Copy, Paste (this will be cake the way I have it set up thus far)
Options Dialog Box (LF CR options for saving + Tab Spaces, Colors and wordwrap options)
I look forward to having some downloadable spin code soon,
7/1/09
No its not finished yet, however there have been some changes in the approach:
I ran into some issues as far as filesize...I do want to be able to edit programs·with this and 3k~5k just isn't enough.
And now we have no less than TWO on-chip compilable languages (Femto & OMG Sphinx)
In addition, the more features added...the·smaller the editable file could be.
SO what could be done to make this work? After some talking with Chip, Potatohead and Steve Moracco (sp?) at UPEW, the approach has totally been altered:
Instead of reading a file into memory..making changes to said buffer via user editing, and then writing the file back to SD when the user saves, the new approach is more of a Journaling system.
A chunk of the file is read into memory..enough to display a full page(give or take a little more), and when the user makes edits..these edits are logged into a small changelog buffer(1kb).
When refreshing the display, first the small file buffer is consulted..then the changelog is consulted...then the information is displayed.
After a certain amount of time of inactivity or when the changelog buffer gets close to full (Thinking of having a progress bar for this) the changes will be applied to the file in question on the SD.
I'm confident this will be fast enough to be transparent to the end user..and this will also leave room for future growth of PrEditor.
This approach has many advantages to the former:
*Filesize limitations pretty much gone.
*Possibly a recover on power loss option (The changelog buffer would have to be recorded on SD for this to be feasible)
I've also decided to make a real flow-chart type plan before I jump in, this wont completely alleviate any changes to things written as I go, but I'm sure it will help to have all of the functional dependencies plotted out, and yeild a better end result.
I'd love to hear what folks think about this approach, I'm very motivated after mparks demonstration as this is a very real use for this right now.
Read enough text into memory to fill the display. Anything that rolls off the top of the screen gets written to a work file. The text is edited in the display buffer and there's some auxiliary information on the length of each line. If the display buffer has to be refilled, it's from the text file. If text rolls off the bottom of the display because some is added, it goes into an overflow buffer. If the overflow buffer becomes full or the user attempts to move backwards in the file, the display buffer and overflow buffer are written to the work file, then the rest of the input file is copied to the work file. When done, the work file becomes the input file and the input file becomes the work file and the editor repositions to the requested line.
This scheme is very slow for very large files, but should be pretty snappy for most medium sized files.
Are you using fsrw? If so, would file seek make things any easier? How about multiple files?
Can you share the code at all? In particular, what's the internal organization of the editor? Is
it line-based (that is, a list of lines) or byte-based (a big chunk of bytes) or character-based
(with UTF-16 characters), or what?
rokicki, I think everyone is using fsrw [noparse]:)[/noparse] I'd guess file-seek would be of great benefit, not just to this project, but many others too. [noparse]:D[/noparse]
@Mike - That sounds interesting..is that how yours is going to work?
@Baggers - Hmmm..I'm not sure about that, I don't have a hydra [noparse]:([/noparse]
@rokicki - It's byte-based system, file seek?
I'm working on reading the file in chunks and displaying..Its in a non-working state at the moment, but no matter what I will put what I have·done up·by friday, hopefully it will be at least a·scrolling file viewer by then. I really thought I would be all done by now.
Do you guys know anything about wear-leveling? I know this isn't a commercial app, but I was just wondering if making so many writes to the SD will damage it.
One of the beauties of using an SD card is that it takes care of wear-leveling for you. Keep in mind that SD cards are now sold and used as hard disk replacements.
I have a partially finished VGA editor that uses 64Kbytes of SPI SRAM for its editing buffer, but I may switch schemes to something like what I described.
Okay, if you're doing a byte-based system, I'd use a hole-based editing system, with seek, and with a buffer on disk.
To do this, you use a temp file that is larger than the file. The temp file has a "hole" in it, that is where the editing is
taking place. Similarly, your in-memory "buffer" also has a hole in it, and that is where the cursor is (for insert or
delete). So the current file consists precisely of these portions:
FilePrefix: Lives at the beginning of the temp file.
MemoryPrefix: Not in the file, just in memory.
Current cursor position
MemorySuffix: Not in the file, just in memory.
FileSuffix: Lives at the end of the temp file.
The "current document" is always precisely "FilePrefix + MemoryPrefix + MemorySuffix + FileSuffix".
In the on-memory buffer, MemoryPrefix is at the beginning of the buffer, then you have a hole,
then you have MemorySuffix. As the cursor moves around on the in-memory chunk, the hole is
moved; as inserts or deletes are done, the hole shrinks or grows.
Exactly the same thing happens in the file, but the hole in this case omits the MemoryPrefix/MemorySuffix
data as well.
Moving the cursor moves the hole. Moving the displayed portion of the file moves the MemoryHole.
(You can do these independently, but the cursor always remains on the displayed portion.)
When you need to move data from the FilePrefix into the MemoryPrefix, you seek and load it.
If it won't fit (because the resulting MemoryPrefix + MemorySuffix would be too long), you
first drop some data from the MemorySuffix (perhaps in block increments). Ditto for down.
If insertions cause the memory hole to get too small, you flush from whichever of MemoryPrefix
or MemorySuffix is larger.
If insertions cause the file hole to get too small, you create a new temp file that is larger and
make its hole larger that way. (Another alternative is to put FilePrefix and FileSuffix in two
different temp files, and write the FileSuffix blocks in reverse order. Indeed, I sort of like this
better.)
If you get a bit clever you can track what parts of the FilePrefix/FileSuffix are still valid against
the changes made in the Memory copy, to minimize how much file I/O you need to do (no need
to write a block if it's still valid).
This sounds a tiny bit complicated, but it's really not too bad, and I think it's particularly elegant.
Comments
I've finally had 5 mins to myself, and done a quick mod to TV_Text demo.
Here's the result.
you can now have 40x30 in NTSC using the ROM Font on TV [noparse]:)[/noparse]
I've attached a pic and the source [noparse];)[/noparse] enjoy.
PS, it's set up for Hybrid at the moment, so clock is 6Mhz, not 5Mhz, can someone test it on a 5Mhz system for me, and let me know if it's fast enough still [noparse]:)[/noparse]
Baggers.
I'm having trouble posting attaching the files, so I've asked Coley to post them for me [noparse]:)[/noparse] ( Cheers Coley )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
(You'll have to rename the file extension to .zip to get it to work though
Nice work Baggers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX - The home of the Hybrid Development System and PropGFX Lite
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I can't wait to play with this!!
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
>> you can now have 40x30 in NTSC using the ROM Font on TV [noparse]:)[/noparse]
Very nice ! I hope you have time to post this in OBEX.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
This works very well on Demo Board - NTSC with·Timothy's 3" LCD display. Even with 55+ year old eyes [noparse]:)[/noparse]
Jim
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I'm writing the editing code and WOW, there is so much I generally take for granted in a text editor.
I've been running Edit.Com in DOS in a VM, as well as Notepad in windows to emulate the behaviors I'm going for.
And I'm going to stray from one of Edit.Com/Qbasic's editing behaviors because I don't think its helpful...Example:
If your cursor is on a line(lets say close to the end), and the line above is shorter, when you press the up arrow, I think the cursor should go to the end of the line above you...not into some area of the document that doesn't really exist. Notepad behaves like this, the PropTool does not.
What's the Forum's Opinion on this?
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
@jazzed- ; )
Btw, I started using the PST today..very helpfull. Usually I'll just have a variable print directly on screen for the program I'm working on while figuring things out, and thats usually a byte, word or long..maybe 2 or 3. Working on this project however has given me byte arrays in the thousands...not gonna get too far printing that on the TV on top of the program I'm working on. So instead I've just been creating a hotkey to dump my buffers onto the Serial Terminal, several thousand bytes without even having to scroll ; ), And there is so much formatting utility already built into FullDuplexSerialPlus that I didn't really have to make the tools..just use em.
I'm sure many of you have been using this or something like this forever, but just incase someone hasn't used this technique yet, do yourself a favor and try it. And thanks Parallax for continuing to update/build tools/objects for the prop for free.
Rick
When the editors came out (mainly on micros) that held the data in memory, fixed length was not wanted as it wasted space.
Hence, the differences in how editors worked depended on the authors former experience.
These days, my preference is if the cursor is at eol then mioving up/down should go to eol. However, if it is not eol it should go to the same column up or down. Does that make sense?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Just wanted to give an update:
I started putting in the mouse functions since I found a 2nd PS/2 port from an old project, that I threw on the Bread Board, but after a days worth of work on it, I think I need to forget about the mouse and just flesh-out the rest of the keyboard functions, or rather the rest of the functions based on keyboard only for now. This way I can have it done and working, and layer the mouse on top.
Whats left to implement:
Saving with the file dialog box (giving the option to save with a different name)
Block Selection (Shift + Arrow Keys = Highlight)
Cut, Copy, Paste (this will be cake the way I have it set up thus far)
Options Dialog Box (LF CR options for saving + Tab Spaces, Colors and wordwrap options)
I look forward to having some downloadable spin code soon,
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
No its not finished yet, however there have been some changes in the approach:
I ran into some issues as far as filesize...I do want to be able to edit programs·with this and 3k~5k just isn't enough.
And now we have no less than TWO on-chip compilable languages (Femto & OMG Sphinx)
In addition, the more features added...the·smaller the editable file could be.
SO what could be done to make this work?
Instead of reading a file into memory..making changes to said buffer via user editing, and then writing the file back to SD when the user saves, the new approach is more of a Journaling system.
A chunk of the file is read into memory..enough to display a full page(give or take a little more), and when the user makes edits..these edits are logged into a small changelog buffer(1kb).
When refreshing the display, first the small file buffer is consulted..then the changelog is consulted...then the information is displayed.
After a certain amount of time of inactivity or when the changelog buffer gets close to full (Thinking of having a progress bar for this) the changes will be applied to the file in question on the SD.
I'm confident this will be fast enough to be transparent to the end user..and this will also leave room for future growth of PrEditor.
This approach has many advantages to the former:
*Filesize limitations pretty much gone.
*Possibly a recover on power loss option (The changelog buffer would have to be recorded on SD for this to be feasible)
I've also decided to make a real flow-chart type plan before I jump in, this wont completely alleviate any changes to things written as I go, but I'm sure it will help to have all of the functional dependencies plotted out, and yeild a better end result.
I'd love to hear what folks think about this approach, I'm very motivated after mparks demonstration as this is a very real use for this right now.
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Forum Search (Via Google)
Yeah, that's a great approach, and as you say this will eliminate file size issues [noparse]:D[/noparse] always a bonus lol
Also, what about HX512 version? but that's really only good for Hybrid users, as we can have SD + HX512 at the same time [noparse]:)[/noparse]
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Read enough text into memory to fill the display. Anything that rolls off the top of the screen gets written to a work file. The text is edited in the display buffer and there's some auxiliary information on the length of each line. If the display buffer has to be refilled, it's from the text file. If text rolls off the bottom of the display because some is added, it goes into an overflow buffer. If the overflow buffer becomes full or the user attempts to move backwards in the file, the display buffer and overflow buffer are written to the work file, then the rest of the input file is copied to the work file. When done, the work file becomes the input file and the input file becomes the work file and the editor repositions to the requested line.
This scheme is very slow for very large files, but should be pretty snappy for most medium sized files.
Can you share the code at all? In particular, what's the internal organization of the editor? Is
it line-based (that is, a list of lines) or byte-based (a big chunk of bytes) or character-based
(with UTF-16 characters), or what?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
We do not have a target date for a release, but may well have several intermediate releases as things progress.
If anyone else wants to join or contribute to our sourceforge project, just chime on in.
I'd join in, but I'm a tad busy again with work, and another project I'm working on [noparse]:D[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
@Baggers - Hmmm..I'm not sure about that, I don't have a hydra [noparse]:([/noparse]
@rokicki - It's byte-based system, file seek?
I'm working on reading the file in chunks and displaying..Its in a non-working state at the moment, but no matter what I will put what I have·done up·by friday, hopefully it will be at least a·scrolling file viewer by then. I really thought I would be all done by now.
Do you guys know anything about wear-leveling? I know this isn't a commercial app, but I was just wondering if making so many writes to the SD will damage it.
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Forum Search (Via Google)
I have a partially finished VGA editor that uses 64Kbytes of SPI SRAM for its editing buffer, but I may switch schemes to something like what I described.
To do this, you use a temp file that is larger than the file. The temp file has a "hole" in it, that is where the editing is
taking place. Similarly, your in-memory "buffer" also has a hole in it, and that is where the cursor is (for insert or
delete). So the current file consists precisely of these portions:
FilePrefix: Lives at the beginning of the temp file.
MemoryPrefix: Not in the file, just in memory.
Current cursor position
MemorySuffix: Not in the file, just in memory.
FileSuffix: Lives at the end of the temp file.
The "current document" is always precisely "FilePrefix + MemoryPrefix + MemorySuffix + FileSuffix".
In the on-memory buffer, MemoryPrefix is at the beginning of the buffer, then you have a hole,
then you have MemorySuffix. As the cursor moves around on the in-memory chunk, the hole is
moved; as inserts or deletes are done, the hole shrinks or grows.
Exactly the same thing happens in the file, but the hole in this case omits the MemoryPrefix/MemorySuffix
data as well.
Moving the cursor moves the hole. Moving the displayed portion of the file moves the MemoryHole.
(You can do these independently, but the cursor always remains on the displayed portion.)
When you need to move data from the FilePrefix into the MemoryPrefix, you seek and load it.
If it won't fit (because the resulting MemoryPrefix + MemorySuffix would be too long), you
first drop some data from the MemorySuffix (perhaps in block increments). Ditto for down.
If insertions cause the memory hole to get too small, you flush from whichever of MemoryPrefix
or MemorySuffix is larger.
If insertions cause the file hole to get too small, you create a new temp file that is larger and
make its hole larger that way. (Another alternative is to put FilePrefix and FileSuffix in two
different temp files, and write the FileSuffix blocks in reverse order. Indeed, I sort of like this
better.)
If you get a bit clever you can track what parts of the FilePrefix/FileSuffix are still valid against
the changes made in the Memory copy, to minimize how much file I/O you need to do (no need
to write a block if it's still valid).
This sounds a tiny bit complicated, but it's really not too bad, and I think it's particularly elegant.