Text editing on the Propeller
Dr_Acula
Posts: 5,484
I've been working over the last few weeks on a text editor for the Propeller. It is one of those difficult problems - is it easier to write a new one from scratch, with all the features, or emulate an old one, with all the complexities of getting old code to run?
Initially I thought the former, but I now think the latter is the answer. Anyway, this is an early version of Vedit (now in the public domain) and still supported by a company producing software for modern computers on many platforms http://www.vedit.com/
The main problem was to take old software written for keyboards that didn't have as many keys, and update this for modern keyboards. This has the practical benefit that you hardly have to learn any special commands (just one in fact, hit escape twice to save). So all these keys are working; Insert/Home/PageUp/PageDown/Delete/End/PageDown/LeftArrow/RightArrow/UpArrow/DownArrow, and editing text is very intuitive.
I've got a new board being made that has a printer port, so this could conceivably print out the document as well. But the main use for this is for editing .INI files. I've got complex software that takes a while to compile and download, and for out in the field it is sometimes easier to change a program's settings rather than recompile the program.
Code is over at the qZ80 thread and the hardware is a Propeller plus a $4 memory chip and four 50c support chips, plus an SD card.
Am I addicted to the propeller? No, not at all!
Initially I thought the former, but I now think the latter is the answer. Anyway, this is an early version of Vedit (now in the public domain) and still supported by a company producing software for modern computers on many platforms http://www.vedit.com/
The main problem was to take old software written for keyboards that didn't have as many keys, and update this for modern keyboards. This has the practical benefit that you hardly have to learn any special commands (just one in fact, hit escape twice to save). So all these keys are working; Insert/Home/PageUp/PageDown/Delete/End/PageDown/LeftArrow/RightArrow/UpArrow/DownArrow, and editing text is very intuitive.
I've got a new board being made that has a printer port, so this could conceivably print out the document as well. But the main use for this is for editing .INI files. I've got complex software that takes a while to compile and download, and for out in the field it is sometimes easier to change a program's settings rather than recompile the program.
Code is over at the qZ80 thread and the hardware is a Propeller plus a $4 memory chip and four 50c support chips, plus an SD card.
Am I addicted to the propeller? No, not at all!
1365 x 1065 - 221K
Comments
This is very intriguing. Is there a smallish PCB available that would provide a home for the parts you mention?
$10 for one or $20 for three, price includes the boards and worldwide postage. Or you can make your own - there are two people on this forum who have done this. Or download the Eagle files and get your own made.
I found a nifty thing in the instructions (see attached). ^O and ^P change the indent settings. Hit ^P and the cursor moves to column 5, and then every time you hit return, it goes to column 5 instead of column 1. Hit ^P again and it now indents to column 10. ^O returns back to column 5. I just tested it now and it works really well.
Very useful for Pascal, C, Sbasic, and even Spin!
On the same Prop, you are apparently running a TV Text object, a keyboard interface, and an SD card interface.
I guess that the EEPROM contains the code to create some of this, and that the rest (such as CP/M and Vedit) is read from the SD card and loaded afterwards. If so, that is another crazy feat!
To accomplish this, all that is needed is a Prop, a 3.3V SRAM, a crystal, a voltage regulator, an SD card, and four 74HCxxx chips?
How difficult is this to set-up, that is, bring together all the various softwares and stick them in the appropriate places? Is the video output essentially monochromatic composite video? Is there some sort of RS-232 port or other similar I/O? Is this the right place to ask all this stuff?
Can the board can be brought to life in stages? Is there some hardware on the board that never needs to be populated unless additional functionality is required?
Old posts mention different revisions. What sort of revisions have been made to the board? What rev are you on now?
This is all very interesting! However, I ought to make sure I can get there from here without too much head-banging on software issues or too much hassle finding expensive or obscure parts.
Yep, us crazy people have been running CP/M on the Prop for a few years now. Starting with my PropAltair Intel 8080 emulator, then the ZiCogZ80 emulator and recently the qZ80 emulator from PullMoll so the hardware and software is quite well worked our by now.
So if you want to have a go have no fear. Dr_A's board is very easy to put together once you have the bits.
Edit: You are right, basically the emulators are just a normal Spin project living in EEPROM. That picks up everything from files on the SD card containing CP/M disk images. Only trick there is to write the disk image files to a freshly formatted SD card so that they are not going to be fragmented.
The SD card formatting and CP/M loading is done on your PC?
I would imagine there is not much to choose between.
PullMoll's qZ80 is notable for passing all the Z80 instruction set tests we have. That's probably good if you want a Sinclair Spectrum emulation. ZiCog has a handful of Z80 instructions missing. This does not matter when running CP/M as most CP/M software does not use Z80 ops anyway. One day I'll get around to fixing the missing ops.
No idea about speed, all much the same I bet.
Dr_A has switched over to yZ80 as he wanted to run MP/M and PullMoll did a great job getting that running.
As I say, most CP/M code is written to run on 8080. Everything I have thrown at ZiCog just worked.
Yes, just format a card and copy the CP/M disk image files to it.
Edit: OMG! I just looked through the 30 files that make up the CPM_MPM archive of 19.SEP.10, and took a glance at an even greater number of files in the PropArchive of 30.NOV.09. This is clearly not a project for the faint-hearted newcomer. It would appear that some assembly is required. Where does one even start?
How difficult is this to set-up, that is, bring together all the various softwares and stick them in the appropriate places? Is the video output essentially monochromatic composite video? Is there some sort of RS-232 port or other similar I/O? Is this the right place to ask all this stuff?
Can the board can be brought to life in stages? Is there some hardware on the board that never needs to be populated unless additional functionality is required?
Old posts mention different revisions. What sort of revisions have been made to the board? What rev are you on now?
This is all very interesting! However, I ought to make sure I can get there from here without too much head-banging on software issues or too much hassle finding expensive or obscure parts.
Re the parts - yes, and a number of those parts are essential for even a bare bones propeller setup. (regulator/eeprom/crystal/download circuit).
Bringing the board to life in stages; yes, I think that is a good way to do things. Start with the standard demo schematic. http://www.parallax.com/dl/docs/prod/prop/PropDemoDschem.pdf. The download circuit can be that one or a max232 or a transistor version. Get the keyboard and display working (there are many objects that can test this). Choose TV or VGA (you can use either but not both at the same time). Two pins can double up as mouse or as a second serial port. Then when that is working, add the external memory.
The number of spin files is a bit misleading - some of those are old files and could be purged. I put them all in a single directory along with BST and then start by clicking BST. It means I have lots of copies of BST. So treat that as a single package.
Then there are the disk images. There are 4 files - 3 disk images and a boot.dsk. Latest versions of code use FAT32 so you simply copy all four to an sd card.
When I build a board, I start with the basics - power supply first and check the volts. Then add the propeller and max232 and eeprom and check the proptool can find the propeller. Then add keyboard and VGA bits and test with some demo programs (KyeDOS is a good place to start). Then add sd card. Then add the external memory and test with programs that use that. You can leave out about 3/4 of the components for a 'bare bones' propeller.
Revisions to the board have added more things but the basic design is the same. Eg one version had a RS485 and another has some analog D to A and A to D chips. I have a number of boards all populated in different ways. Sockets make it easy to recycle chips.
Re video - it is dual color and you can pick any two colors of text and have different colors per line but it can only change per line, not per character. It is a limitation of the high res vga object. I tend to use white on blue or green on black, but others prefer yellow on blue. There are other software configurations where you can't do text but instead can do full color graphics.
The obscure parts would be the ram chip (future electronics or jameco), the inductor for the switching regs (you can always use linear regs), the VGA socket (future electronics) and the sd card socket (sparkfun plus or minus ebay). Others components have multiple sources.
As for the complexity of the software, sometimes I completely wipe the eeprom to test standard propeller code from the obex. Because so many pins are similar to the demo board, a lot of test software works without any modification. To then take a modified board (or a brand new one) up to a working one involves two steps;
1) Copy the 4 .dsk images to an sd card (only need to do once, and the sd card can have other files/programs as well). Time = maybe a minute.
2) Run BST, open the main spin file cpm.spin and program with F11. Total time = less than a minute.
Even if you didn't use a board for this application, you could use it for many other things. eg KyeDOS where you boot up into a menu that gives you a choice of eeprom files. These are then loaded from the sd card into memory. So you can have a menu of Femtobasic and Catalina and any spin programs you have written and choose which one you want from the menu.
I remember that you said to run BST, but I forgot that little tidbit when I started prowling through the archives. I'm so relieved to realize how simple it is to program the EEPROM.
BTW, the switching supplies sound excellent! You gotta love switchers. I have a slug (:smhair:) of power inductors and a great LM311 inductance meter. The meter makes it simple to customize a power inductor if you don't happen to have quite the right one.
Just out of idle curiosity, with the Prop doing everything it's doing, is there still an unused cog?
Ther *might* be just one issue with a global setting with BST - when you run it the first time, click on Tools/Compiler preferences, and then the Optimisations tab. Makes sure the boxes are checked - 1) eliminate unused spin methods and 2) non parallax compatible extensions.
I tend to use BST for this program, and the parallax tool for all other spin programs. Makes it easy swapping back and forth.
I might just make a mention here of KyeDOS. See attahed photo. Once you have a program stable, you can ask the compiler to save it as a binary file rather than downloading it. Then copy that binary file to the sd card. Then if you program the board with KyeDOS, it boots to this memory, and you can use commands like LS to list all the binary images on the sd card. The run them with SPIN MYFILE.BIN One of those files could be the CPM emulation, but you could have a Catalina program and a Femtobasic program and anything you like. KyeDOS does not need external ram.
I'm not sure of the status of other text editors for the propeller. You could add those to KyeDOS as well if you wanted. Hmm - maybe there is source code out there for editors in C and you could write one in Catalina C?
No sorry, there are no unused cogs. Everything about this project is compromise - compromise on speed vs pins, code in cogs, and code in pasm vs code in Z80. It makes sense to try to use as much of the propeller hub ram for screen buffer storage, so the hub is almost totally full, and the cogs are pretty much all full of code as well. But if you want more code space, there is over 300k of code space available in the ram chip from within CP/M. And you can run multiple programs in parallel using MPM.
What sort of things would you want to put in an extra cog? Maybe there is another way?
No worries! I was mostly just curious. It kind of boggles the mind to think of all the Prop is doing, and I was trying to get a clearer picture of just how tapped out it is.
There is something I'd like to hang on the serial port if the port is usable.
You mention KyeDOS a lot. Is there something about CP/M or its use of the SD card that doesn't work so well? Should I be thinking more in terms of using KyeDOS than CP/M?
The project sounds a lot more daunting than it actually is. Believe me, if I can get several versions of it working, some as Dr_A circuit intended, some with restricted chip count, some on single sided PCB and some on double sided (all PCBs home made) then anybody should be able to (all pics on the main Dracblade thread)
I even made one on a bread board, with long jumper wires, and even that one worked !!!
CPM vs KyeDOS - you can use either, they are both very useful for what they do. KyeDOS could be a useful step along the way when you have a propeller working but no ram.
The serial port is pretty easy to use - an OUT command and an IN command to write and read. What are you thinking of doing with the serial port?
Computers don't seem terribly secure to me. Maybe others have had the same experience I have: Someone give you an old computer, or you buy an old computer, and you find on the hard drive all sorts of things that the previous owner probably had no idea anyone else would ever read, and wouldn't be too happy knowing you were.
Or what about spyware and snoopware? Who knows what an interested party might be able to pry into while a computer sits connected to the internet for many hours every day? Who knows what sort of private dealings Microsoft and other companies have with government agencies to provide OS hooks for surveillance purposes?
Since I don't know the answers to those and many other questions, I've been looking into alternative platforms on which to write and store private records. The idea of a Propeller platform running CP/M and Vedit sounds promising in this regard, partly because there is no hard drive at all, no network connection, and the SD cards are tiny, capacious, and easy to store.
Anyway, I figured that an added measure of privacy would come from using xtea (or something similar) to encrypt files before writing them to the SD card. I envisioned a dongle of some sort hanging on the serial port. In it would be an SX processor functioning as a full-duplex UART and encryption engine. A batch file or script file of some sort could be invoked that would take care of the details each time you used the editor.
Re KyeDOS vs CPM, I think they complement each other. Say you wrote a program, purely in Spin, that changed its behaviour based on a small text file. You boot into KyeDOS and select that program and run it (you could even add an autoexec within the spin code of KyeDOS). This is where KyeDOS shines. But say you want to edit the text file. Boot into CPM, run Vedit, then reboot the propeller. Quick and easy, and the beauty of this is you can do it all without booting up a PC. Given the boot time of a PC, I'll bet it would be quicker too.
(My laptop 2.4Ghz running XP is 4 minutes to boot!)
I'd need to take a look at the fat 32 driver code to see if you can have two files open at the same time.
I haven't had a great need to move things in and out of CP/M when a board is disconnected from a PC, but I might need to be doing that soon if I port some code from CP/M into Catalina (see another thread for more on this).
1. From CPM, transfer a file to another cog(s) running FAT16/32.
2. From PropDos/KyeDos/Sphinx/etc, read/write a FAT16/32 file to/from a CPM Disk file. This time, the cog driver(s) need to know the structure of a CPM disk.
3. Have a CPM disk which contains only 1 contiguous file. If we know where it starts and where the length is stored, we could write/read the file directly. So PropDos/KyeDos/Sphinx/etc would just read/write directly to these sectors and if writing, update the sector storing the length. This could be the simplest.
It has a I/O port defined for the Z80 for file transfer operations. The SIMH port.
To transfer a file between CP/M and the host file system a program in CP/M sends a READ/WRITE command and a file name out through that port, it then reads or writes the file data through the port.
Meanwhile on the host end, the simulator, the port is handled much like the console port but data is read/written to the specified file instead of a UART. FAT in our case.
SIMH AltairZ80 has the CP/M commands R.COM and W.COM to do this so one could just implement the same protocol in the simulator end of the SIMH port. Or perhaps define a simpler protocol and create a new R and W.
A micro sd to standard SD card adaptor is a great idea - indeed that is what I use myself. My USB programmer programs micro SD cards, and then put the micro sd in the standard one and use on the dracblade.
The source code of W.COM and R.COM is one of the disk images from SIMH AltairZ80. Alternatively you can work out the protocol from the source code of the SIMH simulator.
Anyway one could always invent ones own little protocol to this and make a new W and R.
Why do there need to be two files open?
When the emulation is accessing the a CP/M file it is using direct block reads and writes to the SD card. The CP/M disk image file does not need to be open to do that. The FAT code only needs one file open for R/W to work on.
The board with the printer port ought to be arriving in the next week or so - then I'll test it and see how it works. There are a lot of peripheral 'real world' circuits/boards out there that use a parallel port so I think it could be a useful addition.
That's all I have ever used for micro SD cards with the Prop.
Anyway, it would be interesting these many years later to plug the Olivetti into a CP/M machine and print Vedit documents. How retro would that be?
Perhaps I'll use an SX to convert RS-232 to Parallel Printer port.
BTW, thanks for the seal of approval on using a micro-SD adapter as a socket. That appreciably simplifies matters.