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.
I approve of all of these reasons!
Toss in a connection to the Internet with a forum reader and I'd be in pig heaven.
Actually, I was going to suggest the typical solution of IMPLEMENTING your whatever-you-decide system using FORTH, and then you can get it working quickly, and solid, but nobody has to be the wiser. This is how the big boys do it.
Really, it all comes down to specifying the interfaces, then it doesn't matter what is used to implement; its all a matter of degree of conformance to requirements.
..the typical solution of IMPLEMENTING your whatever-you-decide system using FORTH
Except that implies building Spin/PASM compiler in Forth, and the editor and so on. Even worse for those of us who want C. No one is going to create a C compiler in Forth. Or are they?
K2;1010371
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.
1) I'm not threatened by spyware on my Macs (But, spamming is another issue)
2) I haven't seen any pop-ups ads while running my IDE (do see them when web browsing)
3) My Macs are all quite power-conscious
4) I have yet to have 'any' of my computers permanently compromised
5) Don't boot-up, just let it sleep :-)
6) You have already been assimilated by the system (you're using a browser on the Internet to get here!)... I hope your not wearing an aluminum foil hat while your reading this :-)
No one said you had to run Windows or even Mac OS X. Eclipse and other productive IDEs run on Linux, as well, if your'e squeamish about non open source solutions.
And Heater,
"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."
Horsepower and memory are only a part of the problem. You need to be able to type (over long periods of time and quickly) in order to write code. No phone that I've seen has that capability (Yes, I've seen the YouTube videos of someone typing 80 words per minute on their phone, but really?). Even tablets make coding less than efficient with single windowing and on-screen keyboards. I use an iPad, love it, would love to be able to code in Spin on it, but it wouldn't be my "go to" for a big project.
Like I said, I'm not against the idea of any of this, just wanted to make a point about efficiency of self-hosting versus PC-based IDEs.
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.
I do feel your pain in that regard... And just because we can is good enough for me as well!
Advantages of a self-hosted Propeller over another portable device for me are: (for me)
1) The ability to change the output display at whim. If I'm in my comfy chair, the TV, on the road an LCD display, at my office, VGA
2) The same ability to change the input at whim for all of the same reasons.
3) Low voltage requirements. Can function on Batteries, solar, etc.
4) Programmable in Spin (what's not to like about that?!)
A dual propeller configuration with Spinx is probably ideal. It sounds like it's been done with Ramblade already.
Another potential piece of the puzzle. Has someone done a Propeller memory object for two propellers which allows the first Propeller to use the 32k memory space of an additional?
Biggest issue is the costs associated with the PC. In the field, I can't always get the PC or even a laptop to the target.
Sometimes its just getting power or a table to the target that is the killer.
In cases where the target has display and a keyboard, self hosted can't be beat.
Except that implies building Spin/PASM compiler in Forth, and the editor and so on. Even worse for those of us who want C. No one is going to create a C compiler in Forth. Or are they?
There is the spinmaker word, which creates spin code for all the forth kernel words. And there is an assembler for the prop, this is used for optimizing. The editor is not finished. So PARTS are there, but its not the PropTool by any stretch of my imagination.
Probably the closest we will come is to wait until somebody writes a C-Compiler.spin object, and just call that. Once the binaries are saved, it could boot to forth, load a binary to RAM, and run. (Which was the Sun and Apple, etc model).
But this just for conversation, there is no plan to do anything C using forth. But IF the forth self hosting package moves a little further forward, it MIGHT be an option that could be leveraged toward another environment. A determination of "suitable" or "unsuitable" could be made as early as August, if a better solution is not found by then.
I believe the self-hosted prop would be best at a 2 prop solution, one being a fast RamBlade for the crunching stuff (512KB latchless SRAM & microSD) and the second prop for the other video, keyboard, etc. Don't forget we can use a full PS2 style keyboard - we all have them (most USB keyboards work in PS2 mode still), or a roll-up one for ~$15. Then TV/VGA or even LCD.
For doing TV or VGA utilising the same pins, and links, it is easy enough for the software to determine whether TV or VGA was being utilised and change the driver on bootup accordingly.
Just for an OT concept. For a commercial product that uses 3 props, we have an option to add GPS. It actually works out better to just add the new GPS board from Parallax and that has its own inbuilt prop. So now we will be using 4 props with the GPS option
OK, I often get lost in my code but I'm not sure why I want a GPS on my self-hosting Prop development systems.....seems to me a second SD for tunes would be more important!!
@Dr_A: You make it sound like we simply need some "packaging" on this, and perhaps you are right.
BTW, do you have the most current link for KyeDOS handy? I'm not sure where my copy is.
See attached. I can feel some changes coming on - eg this code has I/O to keyboard, VGA, serial port and 20x4 LCD display. For $15 I can get a 20x4 display, but for $20 I can get a TV in the same size with full color. I'm tempted to put a "LCD font" on the TV. Then you can change the color in software.
When I get a moment I need to check out Sphinx. Then I need to rewrite Kyedos for a TV. I think that ought to get us close to a self hosting portable system.
I haven't quite managed to get Sphinx working yet on the TV - there is something wrong with the video mode as it is rolling and tearing a lot, but two things that have struck me as very interesting:
First, I think it ought to be possible to build a self hosting propeller with just one propeller chip and an SD card. Sphinx has several options for I/O, including the traditional serial port, and also TV and local keyboard. So no need for a separate propeller to handle displays, Sphinx can do all that.
Second, I think Sphinx could be the key to getting Big Spin working. Unzip sphinx and take a look in the folder "sphinx2". This contains a number of .spn files which can be viewed with any text editor. All the clever tokenising of spin is in there, decoding methods, resolving nested equations, string manipulation. The code is very clever, and it appears to get around the memory limitation of the propeller by moving things in and out of the SD card.
In the past I think the stumbling block for Big Spin has been access to the entire source code of a compiler. But it all seems to be there in Sphinx.
Given this thread, and given the availability of source code for spin compilers, it would be ironic if the first way of compiling a Big Spin program was self compiled on a propeller rather than done on a PC.
I'm off to search for any 32k memory limitations in the Sphinx code.
What I'm picturing is a two propeller setup with a serial link between the two. I'm hoping the SD connections can be shared between the two as well. (I'll know soon.) With a Sphinx running on the serial link on the rear prop, it can do all of heavy lifting of compile while the Kye dos sits on the front prop with connections to LCD, TV, VGA, keyboard, controllers, etc.
I'm also thinking that it should be a simple trick with the code that Beau gave me recently to store variable space on the rear 32k when Sphinx isn't required.
@OBC - when I get home I'm going to see if I can compile a program with sphinx.
I am hoping this only needs one prop. Put Kyedos on the eeprom. Compile the main sphinx program (and any others) into .binary files and then rename them to .exe and put them on the sd card.
I'm hoping I can then run them from Kyedos. When you 'run' a .exe program, the first thing kyedos does is load the program into memory which then overwrites kyedos. It then reboots into the new program, so that will overwrite the kyedos video etc with the sphinx ones. When sphinx finishes compiling, it does a reboot and that reloads kyedos from the eeprom.
The secret is the very rapid loading of a program from the sd card thanks to Kye's new sd driver.
I am very much hoping this means you only need one prop, and you load and reload cogs etc as needed.
hm sounds cool. Developing with just one prop. I haven't played at all with sphinx and kyedos. The keywords "load", "unload" and "reboot"
gives me an uncomfortable feeling because it reminds me of windows and it's most loved hobby of rebooting. It depends on how fast the actions are. If it takes half a second then everything is good.
If it takes 0.51 seconds or more and a two propeller-solution does is it much faster I would always prefer the two-prop-solution.
If a three-prop-solution is remarkable faster over two I would use the three-props. One for the editor, one for VGA-graphics, one for IO-handling.
Hey ! Any propeller-board is so tiny. Adding a keyboard and a screen you can watch without a magnifying glass
has a size that it doesn't matter if the housing gets one inch higher because of two propeller-PCBs behind the screen or under the keyboard.
Anyway if it just needs a micro-sd-card with sphinx on it to make software-changes in emergency-cases this would be pretty cool.
@OBC - when I get home I'm going to see if I can compile a program with sphinx.
I am hoping this only needs one prop. Put Kyedos on the eeprom. Compile the main sphinx program (and any others) into .binary files and then rename them to .exe and put them on the sd card.
I'm hoping I can then run them from Kyedos. When you 'run' a .exe program, the first thing kyedos does is load the program into memory which then overwrites kyedos. It then reboots into the new program, so that will overwrite the kyedos video etc with the sphinx ones. When sphinx finishes compiling, it does a reboot and that reloads kyedos from the eeprom.
The secret is the very rapid loading of a program from the sd card thanks to Kye's new sd driver.
I am very much hoping this means you only need one prop, and you load and reload cogs etc as needed.
I was looking at the conversion of KyeDOS to TV this weekend.. No issues there..
You know the one thing we don't have yet.. An ICON based system. Not necessarily a GUI, but maybe something along the lines of Windows 1.0 could be done with the Propeller.
I was looking at the conversion of KyeDOS to TV this weekend.. No issues there..
You know the one thing we don't have yet.. An ICON based system. Not necessarily a GUI, but maybe something along the lines of Windows 1.0 could be done with the Propeller.
OBC
Wouldn't it be great to have all those ICONs in a fast booting and fast performing 10 pin flash solution? ;-)
Comments
Nice! Don't know how I missed that!
Some simple transfer code (maybe get/put will work) between two propellers and all the pieces are here.
OBC
I approve of all of these reasons!
Toss in a connection to the Internet with a forum reader and I'd be in pig heaven.
OBC
HEY! I HEARD THAT!
Actually, I was going to suggest the typical solution of IMPLEMENTING your whatever-you-decide system using FORTH, and then you can get it working quickly, and solid, but nobody has to be the wiser. This is how the big boys do it.
Really, it all comes down to specifying the interfaces, then it doesn't matter what is used to implement; its all a matter of degree of conformance to requirements.
No offense intended, just being playful.
Except that implies building Spin/PASM compiler in Forth, and the editor and so on. Even worse for those of us who want C. No one is going to create a C compiler in Forth. Or are they?
1) I'm not threatened by spyware on my Macs (But, spamming is another issue)
2) I haven't seen any pop-ups ads while running my IDE (do see them when web browsing)
3) My Macs are all quite power-conscious
4) I have yet to have 'any' of my computers permanently compromised
5) Don't boot-up, just let it sleep :-)
6) You have already been assimilated by the system (you're using a browser on the Internet to get here!)... I hope your not wearing an aluminum foil hat while your reading this :-)
No one said you had to run Windows or even Mac OS X. Eclipse and other productive IDEs run on Linux, as well, if your'e squeamish about non open source solutions.
And Heater, Horsepower and memory are only a part of the problem. You need to be able to type (over long periods of time and quickly) in order to write code. No phone that I've seen has that capability (Yes, I've seen the YouTube videos of someone typing 80 words per minute on their phone, but really?). Even tablets make coding less than efficient with single windowing and on-screen keyboards. I use an iPad, love it, would love to be able to code in Spin on it, but it wouldn't be my "go to" for a big project.
Like I said, I'm not against the idea of any of this, just wanted to make a point about efficiency of self-hosting versus PC-based IDEs.
I do feel your pain in that regard... And just because we can is good enough for me as well!
1) The ability to change the output display at whim. If I'm in my comfy chair, the TV, on the road an LCD display, at my office, VGA
2) The same ability to change the input at whim for all of the same reasons.
3) Low voltage requirements. Can function on Batteries, solar, etc.
4) Programmable in Spin (what's not to like about that?!)
OBC
Are you implying it's like herding cats?
A dual propeller configuration with Spinx is probably ideal. It sounds like it's been done with Ramblade already.
Another potential piece of the puzzle. Has someone done a Propeller memory object for two propellers which allows the first Propeller to use the 32k memory space of an additional?
OBC
Biggest issue is the costs associated with the PC. In the field, I can't always get the PC or even a laptop to the target.
Sometimes its just getting power or a table to the target that is the killer.
In cases where the target has display and a keyboard, self hosted can't be beat.
There is the spinmaker word, which creates spin code for all the forth kernel words. And there is an assembler for the prop, this is used for optimizing. The editor is not finished. So PARTS are there, but its not the PropTool by any stretch of my imagination.
Probably the closest we will come is to wait until somebody writes a C-Compiler.spin object, and just call that. Once the binaries are saved, it could boot to forth, load a binary to RAM, and run. (Which was the Sun and Apple, etc model).
But this just for conversation, there is no plan to do anything C using forth. But IF the forth self hosting package moves a little further forward, it MIGHT be an option that could be leveraged toward another environment. A determination of "suitable" or "unsuitable" could be made as early as August, if a better solution is not found by then.
For doing TV or VGA utilising the same pins, and links, it is easy enough for the software to determine whether TV or VGA was being utilised and change the driver on bootup accordingly.
Just for an OT concept. For a commercial product that uses 3 props, we have an option to add GPS. It actually works out better to just add the new GPS board from Parallax and that has its own inbuilt prop. So now we will be using 4 props with the GPS option
Rick
Not to be used at the same time, are the two physical connections possible without issue?
OBC
OBC
See attached. I can feel some changes coming on - eg this code has I/O to keyboard, VGA, serial port and 20x4 LCD display. For $15 I can get a 20x4 display, but for $20 I can get a TV in the same size with full color. I'm tempted to put a "LCD font" on the TV. Then you can change the color in software.
When I get a moment I need to check out Sphinx. Then I need to rewrite Kyedos for a TV. I think that ought to get us close to a self hosting portable system.
First, I think it ought to be possible to build a self hosting propeller with just one propeller chip and an SD card. Sphinx has several options for I/O, including the traditional serial port, and also TV and local keyboard. So no need for a separate propeller to handle displays, Sphinx can do all that.
Second, I think Sphinx could be the key to getting Big Spin working. Unzip sphinx and take a look in the folder "sphinx2". This contains a number of .spn files which can be viewed with any text editor. All the clever tokenising of spin is in there, decoding methods, resolving nested equations, string manipulation. The code is very clever, and it appears to get around the memory limitation of the propeller by moving things in and out of the SD card.
In the past I think the stumbling block for Big Spin has been access to the entire source code of a compiler. But it all seems to be there in Sphinx.
Given this thread, and given the availability of source code for spin compilers, it would be ironic if the first way of compiling a Big Spin program was self compiled on a propeller rather than done on a PC.
I'm off to search for any 32k memory limitations in the Sphinx code.
What I'm picturing is a two propeller setup with a serial link between the two. I'm hoping the SD connections can be shared between the two as well. (I'll know soon.) With a Sphinx running on the serial link on the rear prop, it can do all of heavy lifting of compile while the Kye dos sits on the front prop with connections to LCD, TV, VGA, keyboard, controllers, etc.
I'm also thinking that it should be a simple trick with the code that Beau gave me recently to store variable space on the rear 32k when Sphinx isn't required.
OBC
I am hoping this only needs one prop. Put Kyedos on the eeprom. Compile the main sphinx program (and any others) into .binary files and then rename them to .exe and put them on the sd card.
I'm hoping I can then run them from Kyedos. When you 'run' a .exe program, the first thing kyedos does is load the program into memory which then overwrites kyedos. It then reboots into the new program, so that will overwrite the kyedos video etc with the sphinx ones. When sphinx finishes compiling, it does a reboot and that reloads kyedos from the eeprom.
The secret is the very rapid loading of a program from the sd card thanks to Kye's new sd driver.
I am very much hoping this means you only need one prop, and you load and reload cogs etc as needed.
gives me an uncomfortable feeling because it reminds me of windows and it's most loved hobby of rebooting. It depends on how fast the actions are. If it takes half a second then everything is good.
If it takes 0.51 seconds or more and a two propeller-solution does is it much faster I would always prefer the two-prop-solution.
If a three-prop-solution is remarkable faster over two I would use the three-props. One for the editor, one for VGA-graphics, one for IO-handling.
Hey ! Any propeller-board is so tiny. Adding a keyboard and a screen you can watch without a magnifying glass
has a size that it doesn't matter if the housing gets one inch higher because of two propeller-PCBs behind the screen or under the keyboard.
Anyway if it just needs a micro-sd-card with sphinx on it to make software-changes in emergency-cases this would be pretty cool.
keep the questions coming
best regards
Stefan
Programs load pretty much instantly. The "cl" command takes longer just because compiling and linking require more work!
I did have a CD/DVD printer assembly that was stepper driven, it didn't survive one of the "GET RID OF ALL THAT JUNK!" moments.
Hey-Ho.
I absolutely agree. It is only when a full environment is required (with fast external memory) when two props becomes an advantage.
You know the one thing we don't have yet.. An ICON based system. Not necessarily a GUI, but maybe something along the lines of Windows 1.0 could be done with the Propeller.
OBC