Programming directly on the Propeller
David Betz
Posts: 14,516
There seems to be a recurring discussion that moves all over the various forum threads having to do with writing programs directly on the Propeller without the aid of a PC. There are certainly already options for doing this available. The ones I know about include FemtoBasic and its variants, Sphinx, PE Basic, and Forth. I'm sure there are others as well. And, there are ongoing discussions about adding new languages to this mix including a C compiler.
What I'd like to know is:
Who is actually interested in doing development directly on the Propeller.
What language and features do you require.
What sorts of programs do you expect to write on the Propeller?
Would you be likely to use an onboard Propeller language as your primary development environment?
Why would you prefer to program directly on the Propeller over using cross development tools like the Propeller Tool, BST, Catalina C, etc?
What other peripherals do you want to use in your Propeller-based environment? TV or VGA? PS2 keyboard? SD card? Flash memory? External RAM?
What I'd like to know is:
Who is actually interested in doing development directly on the Propeller.
What language and features do you require.
What sorts of programs do you expect to write on the Propeller?
Would you be likely to use an onboard Propeller language as your primary development environment?
Why would you prefer to program directly on the Propeller over using cross development tools like the Propeller Tool, BST, Catalina C, etc?
What other peripherals do you want to use in your Propeller-based environment? TV or VGA? PS2 keyboard? SD card? Flash memory? External RAM?
Comments
I think it is an excellent idea, and I've played with both FemoBasic and Sphinx
Sphinx (also covers PASM)
C
Educational, quick control programs, modifying code in the field.
No, but as a good portable / in the field system.
Mostly for education, and some in-field testing/upgrades.
All of the above.
We definitely need some more standardization on simple user I/O - last couple of Spin programs I've been playing with having an instance of an stdio object, which wraps around the actual I/O... example below:
OBJ stdio: "Serial_console" ' stdio: "TV_KB" ' starts a TV driver and keyboard driver, provides methods wrapping access ' stdio: "VGA_KB" ' starts a VGA driver and keyboard driver, provides methods wrapping access pub main stdio.start stdio.str(string("Hello World!",13))This way all the I/O specific initialization can be hidden in the wrapper object, and the main program does not have to care about console specifics.
-Phil
Pascal, K&R C, structured BASIC, Spin, Prop Assembly. For BASIC, C, and Pascal the ability to compile as cog only, LMM, or XMM.
Everything from drivers, graphics editors, demos, compilers to everything else.
Yes, most definitely.
I have always preferred native development environments to cross compilers, even on MCUs. this is why I first started pushing the limits of VGA on the AVR quite some time ago, and part of what brought me to the Prop. Not to mention that I would probably get more done, as on my PC, Amiga, Apple IIgs, or Atari TT (clone) I spend to much time researching what I am doing (because of the convenience of the Web Browser right there).
VGA, PS/2, a standardized interface for mass storage (so we can use what ever each prefers) SRAM (serial and parallel), SPI (I know 'duh').
There are times when I might appreciate being able to change a program on a Propeller platform without the help of a PC. I could see a case where it would be easier to be a "Propeller Evangelist" if everything was "in my hand" rather than having to drag along a bunch of stuff. What would be my requirements in that case?
Having enough memory to actually demonstrate what is possible with Propeller as a self-hosted dev environment is a key to me. Self-hosted dev is not a micro-controller application, so typical micro-controller applications are not the point of the discussion. However hard some tries, I will never be convinced that 32KB of global RAM is enough to do really useful non micro-controller stuff.
What languages would be useful? I would like any language that is "natural" to most people - most people don't use old HP RPN calculators for example. Practically speaking, BASIC is a good option because it can be small enough to be embedded. Spin is good for lots of things and an easy language to use, but it is really too limited in todays form with regard to program size. I lean toward C because I like it, know it well, and it allows creating large, complex, and maintainable programs.
What would be a nice general goal for self-hosted dev? Being able to walk up to the front of the room at UPEW to demonstrate something without having to carry a dump-truck of junk would be a good start.
It's a wild stretch to try and finish in a month, but I think your XBASIC running on a PropTouch Propeller Platform Handheld would be a very nice demo.
Lets face it, The PC/Mac with Windows/Linux/OS10 is to the computer age what the multimeter and scope was (and still is) to the electronics age.
I don't have much experience with Javascript, but that sounds like a better tool than using Objective-C. It's the only "cross-platform" programming tool for the iPad and development should be able to be done with any web browser. It could be served from a website or packaged as a stand-alone application.
If I'm going to have to carry a screen and keyboard around, why not use the iPad as the screen and its Bluetooth or even on-screen keyboard with a link via WiFi to the Prop?
This may be crazy, but I hope to spend some time in a couple of months experimenting with it.
Coupla things I think make self-hosting worth it:
1. If a Propeller can program a Propeller, then all one needs are Propellers. Many things can be factored out, like hardware changes, operating systems, etc... It's not always practical, but something I believe is important to have be possible, if anything, just to insure that one could choose to map skills onto things that are constant, or that one has control over.
Never did like the shifting sands problem. Sometimes it takes a lot to get skill, and then when it's changed to improve the overall state of things, it's often worth doing the work to stay relevant. But what happens when it changes just to make money?
Exactly. So there is that, a clear ideological argument.
2. I keep both a old Atari and a Color Computer 3 handy. Have for years. Usually, I don't have them both up and at the ready, but I almost always have one. Or... that model 100 that I scored recently. It's actually at the office, and I actually do use it, from time to time. For what? Terminal, and sometimes just to write a little tiny bit of code to get the answer to something like I always have since I knew what a computer was.
So a Propeller could easily fill that role. I've toyed with getting a Apple ][ series computer, putting the prop on a card, so that it could render video, or the computer could be used as a nice dev station, etc... Would kill two birds with one stone! One box for both the odd little bit of computing, and a nice dev, test station all in one. That really appeals to me, even though the Apple is kinda big. I can see it with cables, my scope, breadboard, headers, the prop on a card, maybe props on cards, some glue code to make it all make sense on the Apple. Could walk up to it, write a bit of SPIN, fire a Prop off, do stuff, use the display, or the scope, or both, and just have it turn on, be ready, and I can work, flick the switch to turn it off, and it's just simple.
That said, a portable Prop, connected via USB to a laptop rocks hard. No worries there. It's great, but sometimes not just established, and by that I mean there are always the connections to make, and the OS and such is fickle, or maybe I want to leave it on for a few days, but can't because...
3. Games.
Truth is, I really want to run some text adventure type games on a prop. I love those, and either the Apple kind of idea would be simply golden, or some portable thing, like that model 100, where I could turn it on, play, then turn it off, is just kind of appealing, like some little hand held thing would be.
4. One variation on doing simple things is stuff like aligning a old television, or radio. That's one of the tasks the old retro computers did for years. Nothing beats turning one of those on, writing a little program, or fetching one, depending on what goodies are attached, to draw those basic things needed to sort a old TV out. And I like stuff like that, because I will use stuff like that, and the older devices, because I have always enjoyed older, simpler, robust things.
Just did the SONY WEGA on the Prop this time. Excellent!! Wrote the stuff, loaded up the EEPROM, and then carried the little board and battery to the TV, just like I would have the retro-computer, and drew all the patterns I wanted. I like to draw the safe area, dot grids, lines, color gradients, and some other specialized things in the overscan to get the TV just as perfect as it can be. Good for a year or two, then it happens again. Done it since I was a kid, and did it then because one had to, or watch a rather crappy TV, and that paid for a lot of dates!!
None of those are really all that viable commercially I would think, but they could be a lot of fun, and mostly I'm into this for the fun right now, hoping that might change for the better, but not really all that worried as to whether or not that comes to pass.
Nice idea but let's forget the iPad. It's closed nature is the antithisis of everything going on on this forum.
But an Android tablet could do it. For example BSTC is written in Pascal an it is possible to run Psscal native code on an Android.http://www.asus.com/Eee/Eee_Pad/Eee_Pad_Transformer_TF101/
A nice little project for BradC:)
Sounds like fun! When can I get a PropTouch? :-)
There are other solutions besides a PC/Mac/Linux such as the mini unix versions and android on small tablets/phones, etc.
Requirements (for me)
VGA &/or TV, Kbd (PS2 on USB connector), Stereo out, microSD, SRAM (128KB min) using dual props. Why? Because I also want to be able to run emulations such as CPM because I can switch almost on the fly and use a lot of tools already done, such as editors, etc under CPM until they are available under prop.
In what way are the existing programming-on-the-Propeller solutions inadequate for what you want to do. By existing I mean FemtoBasic, PE Basic, and Sphinx primarily and maybe Forth as well. Secondarily, I guess I should include everything that runs under CP/M and will run on the Propeller under Z80 emulation. What features do those existing platforms lack that you view as essential?
Once I've sorted things out, i'll "re-spin" the motherboard.
New PCBs will be available before UPEW.
John Abshier
An ideal scenario here would be a fully equipped version of BASIC with access to:
* text and hires graphics modes
* easy access to SIDcog functions
* access to SD
* access to MIGS type game controllers
* 20+K left over to do something interesting
* access to most of the I/O
I've seen femto mods connected with PropGFX so I know this can be done.
OBC
Braino, and my minions from the local elementary school robotic club.
Forth, assembler, and any other languages deemed appropriate. Must be cheap, must use no other resources, as most of these kids have a zero budget.
Monitoring sensors and controling actuators.
Almost certainly.
No PC, or PC is busy doing other things. Also, I find learning a forth adapted for a new chip a LOT easier than learning assembler right off the bat for a new chip. No other tools are necessary or any more useful (in my limited experience)..
TV or VGA as needed, keboard as needed; terminal interface if available, ethernet terminal interface is most likely; SD card will likely be intergral to development environment, but optional on final; FLASH and other external memory as needed, but SD memory will propbably be sufficient for most applications
The baseline development environment for Propforh 5.0 will likely be a Spineret providing the development GUI over ethernet via a web browser, and providing the programming interface to the target embedded prop (a separate target prop is not required, the spineret can b programmed directly over ethernet). Thus development can be achived using any netbook or smart phone over the internet, and my windows PC can be dedicated to it only real useful function, which is playing games.
This in probably not a desirable environment for some folks. If one is used an environment that takes up the full resources of a PC, than one would probably not be comfortable in an environment that does not. I find the PC gets in the way more than it helps. But that's just me.
Sal is working on the wireless access to the prop, but has not found he likes.
I think it is a great idea, but at the same time I do not believe it is a practical proposition. And I say that from the perspective of someone who has written and compiled both C and Basic programs on the propeller itself.
I want something that at the minimum looks like Windows Notepad A text editor, ability to save, load, a mouse, keyboard, and then add on the ability to click a button to "compile and download". I have this working in an IDE written in VB.NET and having used this for nearly a year, I can say that I am not really keen on going back to more text based compilers.
C and Basic are probably the two practical languages. I do not believe Spin and Pasm are going to work without a *lot* of extra coding!
You name the language, and we can shoot holes in why it is not practical *grin*. I believe C and Basic can work because there are some compilers where you can get right inside the code and pull it to bits and rewrite it. Until there is a totally open source Spin and Pasm compiler, I do not believe these two languages are possible, so even though I would like to use them, I don't think the speculation is going to lead anywhere. Plus having used Catalina with an almost infinite program space, I now have no great desire to go back to trying to write code to fit within the 32k of the propeller memory. Pascal might be a useful stepping stone to Spin. C and Basic are the practical languages though.
For me, this might come down to speed. There is the speed of compiling a program vs the speed of downloading a program. For some small BDSC programs in CP/M, the slow compilation speed is more than offset by the lack of a delay downloading. Fine for a 10k demo program But for a real program, download speed is not insignificant - the 150k Catalina program I am writing that emulates Windows takes nearly a minute to download, and it is probably heading to a 300-400k program. So if you can compile this onboard faster than that speed, then this would be great, but I don't believe it would be possible.
For me, the bare minimum is a display (VGA/TV or 20x4 LCD), keyboard, SD card, probably mouse, one or two serial ports, real world interface (digital/analog) and external ram.
I have to agree with Dr_Acula, I do not think it is a very practical endeavor. In another thread, I am working on my PropOS program, and I am already starting to see that I will be running out of resources very quickly, plus I have not even considered a programming perspective from the Propeller. Besides that who wants to go back to a text based environment?
What I would find interesting is a portable Prop box that would have maybe a touch LCD screen, plus some other stuff. That way all you need is a laptop, a usb cable for the Prop box, and you are ready to show off, or "evangelize" the Propeller. Just my thoughts on this subject
Ray
That would be me:)
Just so happens I have been fighting with the Eclipse IDE used for developing with the "chip that shall remain nameless". I swear that using the command line tools is a lot easier.
Although it might sound crazy at first to use something as slow as EEPROM for code I've built some powerful features into the byte code system to reduce code size and both temporarily and permanently cache critical code in Hub RAM. A Prop Windmill system will be faster than many early practical computers such as the TRS-80 and Apple ][ and even the early IBM PC's were, and the Windmill engine will only use two of the eight cogs. It will also be capable of reclaiming the RAM used to launch a PASM cog image.
Windmill is a serious project; I'm getting paid to do it and will be using it for serious in-house development. Right now it's going in fits and starts though since I have to fit Windmill work between other immediately paying projects.
And I'm doing this for two reasons. First, it should be understood that the Propeller really is far more powerful than computers that were used for much practical work for many years, and there's no reason it shouldn't be self supporting. And second, I refuse to have another VB6 or Windows XP experience. It doesn't matter how nice a tool is if it is stolen from you after you've worked to learn how to use it.
On edit: Seconding Heater, I would love to return to a text based environment, especially with one of the higher character count drivers such as Chip's hig high density VGA or my LCD hacks. Back in the DOS 3.3 days I got a copy of the Heath/Zenith DOS Developer's kit which included an editor called BSE or Basic Screen Editor. It was written entirely in assembly language, and could simultaneously open 99 windows either into different positions within the same file or different files. I was far more productive with that thing than I am in graphical IDE's which run slower even on modern hardware than BSE did on a 12 MHz 80286, and I constantly have to use the mouse to do things I could do on the keyboard in BSE. It had very powerful search and macro functions which simply aren't available in any of the modern IDE's I've seen.
The 50&64 column ones only need a 5Mhz crystal, the 80 column driver needs a 6.25Mhz crystal to be very close to VESA.
They are part of my new "Save A Cog Foundation" :-)
The drivers come with my 8x8, 8x10, 8x12, 8x15 and 8x16 pixel fonts, which can be scaled vertically...
Chip Gracey.
I think there are good reasons to want to be able to program the Propeller on the Propeller. We've all had hardware that has become obsolete because we could no longer get legacy software to run on current computers or could no longer hook up to an outdated or proprietary connector.
But personally I'm with Phil. I have no interest in using a primitive, text-based development environment. I think it has merit in the hobbyist sector and the people on this forum who are doing development in that area have certainly advanced the state-of-the-art on the Propeller. I don't want to discourage that development. But when I do my work, I want an IDE that takes advantage of the power of my computer and includes the latest advances in programming editors.
Editors, IDE's and languages are always fertile ground for a debate:)
I'd just like to say that there is nothing "primitive" about text based or command line tools. Well, perhaps there is if your command line is only a DOS box. Indeed most development is text based whatever editor you use to create it. There will always be things you can do on the command line that you can't easily do in any IDE. Except possibly if you use an editor like emacs that let's you script almost anything.
I'm surprised that you say "I think it has merit in the hobbyist sector". I would have though exactly the opposite. A hobbyist or casual programmer or beginner can be well served by an IDE where you open a window, type the program and hit the "run" button. i.e. making things as simple a possible. In my professional life command line tools rule. God forbid that a beginning programmer has to deal with the nightmare that is Eclipse for example. I'm told that is one of the prime examples of the "latest advances in programming editors".
We have a similar set up, except we have a big fast propeller. If more pins or cogs are needed, more props are added, and accessing remote cogs is identical to the user as local cogs; the user only has to group functionality to account for the grouping of eight cogs/32 pins in time critical functions. The option exists for using the EEPROM as a file system, but we found that using SD more cost effective and this will be the direction.
The new kernel design has hooks to access the SD, load "scripts" into to the prop, run them, store results, and forget the script when no longer needed. Most of the main memory is available to the user, we guessimate about 28K. Throughput is limited by the transfer speed of the SD card, but application tthoughput is very close to that of the SD card since there is very low overhead.
"I think it is a great idea, but at the same time I do not believe it is a practical proposition."
You guys are funny. Reminds me of "Interesting, Orville; but it will never fly"
Ray