Toward a Self-Hosting Propeller
K2
Posts: 693
I know the Prop can already be self-hosting through Z-80 emulation and the CP/M OS; and also with FORTH. But why couldn't the Prop be used to edit, assemble, and then run its own native machine code? In terms of peripherals, all that would seem to be required would be a 64 KB EEPROM (with perhaps a bank switch), an SD card, a keyboard, and a TV or composite monitor of some kind.
One half of the EEPROM would contain the boot code for the development system, and the other half would be the destination for the "new" code. The SD card would contain swap-out code for the editor, assembler, other necessary functions, and possibly a compiler.
I know it would be an involved project, but is there any fundamental reason it wouldn't/couldn't work? It seems like all the necessary knowledge is in place.
One half of the EEPROM would contain the boot code for the development system, and the other half would be the destination for the "new" code. The SD card would contain swap-out code for the editor, assembler, other necessary functions, and possibly a compiler.
I know it would be an involved project, but is there any fundamental reason it wouldn't/couldn't work? It seems like all the necessary knowledge is in place.
Comments
http://www.sphinxcompiler.com/
http://mikronauts.com/products/propcade/
I've been kind of keeping my eye on Sphinx and companions for a while. I seem to remember there were still a few "all we need is" type qualifiers.
I keep hoping to have a small robot summer school sometime. It would be great if each student in the class didn't have to have a computer. If they could work at home on programs by plugging their Prop into their home TV, it would open up robotics to a lot more kids.
So could I add a SD card, keyboard and TV connection to a Prop and have kids be able to program at home?
I know all this has been talked about to death. But hey, since K2 asked, I thought I'd tag along.
OBC
I designed RoboProp specifically to allow for self-hosted development :-)
FYI, RoboProp is designed to fit the BOE-BOT chassis, and several other popular platforms.
This would allow using a PC or another propeller as terminal... whatever is at hand...
Nice.. I like where this could go... Dual prop.. Self hosted...
OBC
The hardware includes an SD card so if you already have that then do all the work on the sd card rather than eeprom.
Put Kyedos on the eeprom, then everytime you reboot you can run programs, which would either be i) a text editor or ii) sphinx compiler or iii) the program you just compiled.
Is there a text editor that could be used? (and yes I know there are text editors in CP/M but to date, I don't think anyone has been able to get the text out of the CP/M image and onto the SD card as a text file).
And there might be the issue of the style of writing code. If you have a 40 column TV display, it might be better to not write long complex lines with multiple | & >> << instructions, but perhaps to split it up into intermediate lines where you do only one instruction per line.
So is the only thing missing a text editor?
Addit; I just found this text editor http://www.sphinxcompiler.com/Home/sphinx-documentation/reference/edbin
Now we have KyeDos (seems to be the best reported so far although I have not had time to look) that could be used as the base. I also thought someone wrote a better editor that mpark provided with SphinxOS.
Anyway, the basis of SphinxOS is that any additions are just prop binaries (just as a program .COM or .EXE in older dos and windoze). No need to modify the OS for each addition.
I built a very basic SD loader based on PropDos & PropCmd. All it did was to boot a binary on the SD card. It relies on "that" binary to know what peripherals are on "this" prop, so the loader is universal (excepting the requirement to know the pin numbers of the SD card - I suspect we could actually test for this by searching for the 10K pullup on the -CS pin). This code was for RamBlade and is IIRC in the OBEX. This booter allows me to change the SD card (or edit the autoexec.bat file) in a PC, so no USB/FTDI/PropPlug is actually required. This type of loader made the most sense to me because you can even change the hardware without having to reprogram the eeprom. My RamBlade has a WP (write protect) jumper to prevent users inadvertantly reprogramming the eeprom.
There have since been a few editors, but I would suggest we have some pretty good interim tools in CPM. Now, if we built a minimum CPM that runs in the hub, we could switch any hardware into CPM to take advantage of the tools (provided they run in a smaller environment) and then back again. Why? Well the editor(s) for one! All that is required is a routine in CPM to copy a file to/from the FAT16/32 file system - this would be quite easy. Or, do it in KyeDos/PropDos/whatever and use a fixed CPM drive location for the file.
IIRC I made the 1pin TV & 1pin Keyboard object work with SphinxOS. They can exist on any 2 pins, so P30 & P31 works too.
Unfortunately I had other things to do so this project went on the backburner. Drac seems to have made great progress here though. We certainly have the basics, and instead of everyone doing their own thing, it would be better to "pool" resources to make an excellent and usable PropDos (call it whatever) so that all programs can run... pasm, spin, basic (all), forth, catalina, etc.
http://forums.parallax.com/showthread.php?112344-Coming-soon-to-a-Prop-near-you-PrEditor&highlight=Casslan+PrEditor
OBC
Now you are speaking my language! I couldn't agree more.. The trick with this group is getting everyone to agree on a direction.
OBC
Why not simply two? That's probably a reasonable setup for most people. Hey 60 I/O pins (after interconnecting them), 16 cogs, and 64k should be enough for anyone. <SMIRK>
OBC
Suddenly I am thinking that almost everything is there now.
I'm currently working on unchaining my prop from my office and letting it run free. To do that, I need to move everything from VGA over to TV, and I'm a bit stumped with the movie player color VGA display driver, but I think all the text drivers will port over.
Kyedos might need some tweaking as it was designed for an 80x40 display and so the help menu might need to be split into two screens. Fundamentally, while kyedos has many instructions, the one you use the most is to type in the name of a program that ends in .exe and then it runs. So that does not need an 80x40 display, indeed it might even look better on a little TV with a much bigger font.
The text editor(s) seem to be there and that was a stumbling block for a while.
Ok, here is a little challenge that takes things beyond 'hello world'. Say you have a source file in spin which was designed for a video display on pin 24 and you want to change it so it runs on pin 16.
Boot into Kyedos and run a text editor.
You load up the .spin file into a text editor.
You scroll to the line in question and change it and save the file
You exit the text editor and run Sphinx.
You link together the new files.
Maybe ? you change that new file extension from .bin to .exe (Kyedos can do that).
You run your new program as an .exe
This could be exceptionally useful 'out in the field'.
BTW, do you have the most current link for KyeDOS handy? I'm not sure where my copy is.
OBC
The use of a serial driver instead of video would open the door to folks using just about anything they wanted on a terminal end. Would the existing objects suit for this?
OBC
Just curious...
Other than being kind of a cool gesture to edit, build and run your code all on a single device, what value does it add to the development process? I don't want to put the idea down, as I would probably spend some time with a self-hosted prop, myself. But, I've used several good to great IDEs over the last 30 (egad, I'm dating myself!) years and I don't see an advantage over the long run in using a self-hosted micro controller as my main programming tool. There are so many added benefits in modern IDEs that I would miss:
- Graphical interfaces that assist fast access to my code (multi-windowed environments, pop-up menus, hierarchical views of my projects, etc.)
- Gigabytes of memory
- Terabytes of storage on-hand
- Access to professional source repositories (svn, cvs, etc.) on globally-available servers
- Global search capabilities (search all my sources, libraries, documentation)
- Instant access to all libraries (mine, system, openSourced)
- Copy, Cut, Paste, Drag...
- Spell checkers, source formatting, syntax coloring
- Find/replace editing
- etc...
I use Xcode on a Mac, but Visual Studio, Eclipse and other modern IDEs offer similar features. The other overriding feature of these IDEs is that they allow collaborative development. Teams of developers can use source repositories to allow tagging of source revisions. IDEs then have tools that allow quick source merging, inline with your editing process. This makes it easier for splitting up the code, allowing team project building. And, the list of benefits, goes on from there... The benefits far outweigh the "coolness" factor of self-hosted programming on a micro. iPhone, Blackberry and Android operating systems & apps are all developed with modern IDEs that provide these features. I'll bet it would be hard to convince the engineering teams that they should write their code using their devices.
Of course, I understand the fun & coolness factor of doing just about anything with the Propeller. But higher productivity in the software writing process, gives me more time to think about what I can do with the Propeller. I want all of the difficulties in the writing process to disappear and allow speed in getting my thoughts into code.
Just food for thought... I still have a habit of keeping my Terminal up & running behind the graphical UI in case I want to have fun!
dgately
someone much smarter than me once said something like this: "If all you have is a hammer, everything starts to look like a nail"
I have made a serial driver for Sphinx long time ago. See the Sphinx thread:
http://forums.parallax.com/showthread.php?114023
post #103
Andy
I decry needless complexity and bloat. In an effort to be everything for everybody, Windows has become an absolute MONSTER over which users have no real control. Thanks to the tragic inefficiency of the monster, it takes 2,000,000,000 CPU operations every second to make it work even half-assed. This is fundamentally ridiculous.
Why do I want a self-hosting Propeller?
1) It won't become loaded with spyware.
2) Pop-ups won't dog me at every turn.
3) I won't need a 350 W switching power supply to get "Hello, world!"
4) It won't become permanently compromised when a backdoor trojan installs a rootkit virus.
5) It won't take five minutes to boot up.
6) Because I refuse to become assimilated by the System.
Why not a self hosting Android phone or tablet? Theses things have as much horsepower/memory and storage as the PC's we used as develop on just a few years back.
There was an old thread (SphinxOS???) where we were all discussing the rendezvous/mailbox area. It is just a matter of loading a few drivers. We could even swap them on the fly for a TV to VGA change, or pinout. It's not rocket science any more.
dgately: Just because we can. Maybe no commercial app, but who knows, or even cares. At least I will know what it is doing. Every so often my XP dozes off - something running 100% of the time and I just have to wait. It is NOT a virus - just something in windoze! Every time I open a particular large folder in windoze explorer, I cannot scroll for at least 30 seconds. Bloatware has steals my pc many times per day and there is no longer anything I can do.
Most software would probably be fine with 60x20 or even 40x16. I say 60 because IIRC my 1pin driver will do 60x25 NTSC at 80MHz.
However, there are a couple of ways to handle the smaller width....
1. The video driver could be a window on the buffer, so 80x25 = 2,000 chars, and use special keys to move around the window. Could be messy but could also work - just modify the input routine/driver to extract a few keys to move around the window to directly interact with the screen driver.
2. Auto lf after 40 chars. Not so nice, but would work.
So I would expect a self hosting Prop system to have multiple Props and possibly external RAM. A VT100 terminal on it's own board would be nice for example.
The Inmos transputer TDS using occam actually ran on a transputer board plugged into a PC. I had it running on my hardware, with 1 Mbyte of RAM. Fortran and C compilers also ran on it OK.
With some external RAM I understand Catalina can compile itself to run on the Prop. I believe the sticking point was the lack of PASM assembler to perform the last step of building the binary. Perhaps as Roy Eltham is now building a C version of the Prop Tools Spin compiler this starts to become a reality.