I currently utilize a COTS motion-controller that has a proprietary interpreted programming language. The beauty of this is that I can remotely tweak the code.
This past summer, for example, I was sitting at a beach-bar at Lido Di Jesolo (near Venice, Italy), sipping Campari & Soda, watching ladies (topless :cool:) volleyball (this is absolutely true).
I received an alert on my cell phone (I use Zello, 2-way radio) from my customer in North Carolina. These are the guys that make the ugly yellow school buses.
We had recently retrofitted one of our control systems to one of their tube forming machines and they had discovered an "undocumented feature" (bug).
Using TeamViewer on my Galaxy S5, I accessed the interpreted code, located the problem and made a modification. For my machine's HMI, I use a heavily protected tablet and my customer used the integrated camera to demonstrate the problem of the machine's behavior.
The customer was delighted with the instant fix that didn't require a factory visit.
I am currently attempting to replicate the features of this motion controller using the Prop and it's really coming along. The problem, up until recently, was what do I use for an interpreted command processor. Well, I was recently made aware of the Micromite product and then realised that I already had something similar, the ByPic. So, my plan is to use the Prop for what it really excels at and use one of these other products for command processing as they feature FP math and have more than enough memory for my needs.
PropBASIC has made it very easy for me to achieve very high performance on the Prop and test all kinds of "what-if" features/scenarios that MUST run at PASM speeds, without me having to code in the relatively tedious PASM.
JS the language has been very stable since ES2 or whatever. Even MS faithfully copied all the broken language features of the original Netscape version into IE and then insisted they get baked into the ECMA standard.
That makes JS the language more stable than C, C++ and many others.
The browser is another story. Mostly a mess. Especially the dog's breakfast MS made out of IE
The Edge browser is playing nicely with the web standards and following along with the other guys too.
OK, I'm persuaded. Although I was never really opposed to to the idea I just saw it as not being needed when we already have PC's.
What you are describing reminds me of the early days with the 8080 and Z80, and how much could be accomplished with the simple tools a small eprom based monitor/debugging tool provided. The hardware available today makes so much more possible.
Heater, it's enterprise stuff mostly, and it's Java combined with a browser. Downright toxic.
The various JS based things I have used online work a lot of the time, but I really can't just keep a stable browser with the updates happening all the time.
If people were serious about compliant JS, that has merit. For sure, I'm not opposed, just don't want to be forced into using a browser. I'll take ASCII, thanks.
Serial and ASCII, maybe even optional ANSI or VT-x will work on anything that has serial and some CPU or other, VT 100, Apple 2, PDP era on up to modern day. Who knows? People keep wanting to give me an IRIX box. A nice O2 or Indy with video capture would make a great dev terminal, as well as full on station, using C OpenSpin, etc...
All that should be possible, or we aren't doing it right. Does not mean people have to go that way, just that they can. Also means props programming props too.
A browser option would be a good, optional load or switch, for the poor souls running a closed tablet or something similar.
I swear, we need to make a simple program it via serial link using dots on the display for some of these devices... something. I like things like an iPad as readers. Useless otherwise.
I have kept an Apple 2 for that reason. It's old, and 1mhz means using assembly for anything meaningful. But it is easy 6502 assembly, so there is that. But, it and an Atari were the bench computers. I got a ton of learning and cool stuff done with those and books back then.
When I got an old Tek scope, it was a potent setup.
My favorite P1 way is terminal and or video output, both displayed on my computer. A P2 will allow this, have room to do more meaningful things, and won't necessarily need much else. Could use my Apple with it. (And I might, for a fun curio)
Anyhoo, the bench computer use case is a primary target for P2, as far as I am concerned. I believe it will get used, particularly given the fancy pins and all those DAC options. The thing will be a playground. Setup one as bunch computer, maybe enclose it and provide some buffered, raw I/O on headers and other nice plug it in and go type connectors and cables. I may model up and print something like that, when we get to the "real chips are gonna happen for sure" stage.
A few COGS provide the computer, display, data capture and data out parts. User does stuff with the remaining ones, no OS really needed. This is seriously powerful and easy once we get those very basics in the can.
Making one could be a killer kit set too. 200 in one, and the first thing you do is make the computer that works for all the other fun stuff it does.
Somebody finds one in a bin 20 years from now, and it works as well as the ones we find in the bin today do.
On a pro note, an similar arrangement doing say, industrial automation, requires only documentation to be useful and serviceable for a good long time too.
...enterprise stuff mostly, and it's Java combined with a browser. Downright toxic
As I suspected. Java is a whole other can of worms. Java, FLASH, Silverlight, ActiveX/VB, etc in the browser are not the WEB platform. They are not muti-vendor solutions backed by web standards.
I'm surprised at your comment about "updates happening all the time" In the Windows world IE has only moved to new versions with new OS versions. MS has gone to huge efforts to make newer IE versions backwards compatible with older versions. Especially for those enterprise installations that are dependent on MS specific extensions.
Out here we don't worry about browser upgrades. Chrome and Firefox keep evolving but there has been no urgent need to keep up to date and normally I'm too lazy to bother.
There has been a constant nag of "upgrade Java" or "upgrade FLASH", another story as I say, and one I have not bothered with for ages. Don't think I even have a FLASH or Java installed anymore.
Then there is the problem of web sites insisting on using whatever new web standard features come along, rounded corners on divs or websockets. Hardly a concern if you need the latest and greatest for a WEB IDE or whatever.
I just wish they would arrange to allow users to grant permission to web pages to access a serial port like they do with web cams and microphones now in HTML5. Then we could make in browser terminals and other tools.
So whats a use case for self hosted X on the prop?
If the target application is bit banging, then the prop is a good choice.
If the target needs modification in the field, and one needs and arbitrary or generic tool chain, for example a smart phone or laptop serving as terminal, WITHOUT specific libraries and etra hardware (debugger, incircuit emulator etc); then and interactive kernel environment is a good choice.
In practice, hot programming in the field on the flly isa pain in the neck, simply because its different then working on the PC workstation one my desk. I'm used to my PC, its already set up; a tiny keyboard and a tiny screen away from my coffee cup is just not convenient.
We had the Jupiter ACE version of forth ages ago, they provide a standalone interactive work environment. But we didn't use these, as the PC is a better way to get actual work done.
Need a browser or ability to view PDF? You have a laptop and smart phone that does this. Why waste the time and effort to build it into your prop app? You COULD, I didn't; too many other fish to fry, and existing tools do it better anyway.
Doing all this (again) in C (etc) MIGHT get a dfferent result this time. But the forth experiments did not uncover a way in which "standalone" had advantages over "PC".
On the other hand, in forth, we can re-program a live system over the internet while it running. Save time and travel expenses etc. If a standalone system allows that, then it can have obvious advantaqes. But one might have to design this from the start to get it to work. I don't know if this is possible with existing basic systems, or if could be possible with a compiled system for example using C or SPIN.
Heater, it it not all java related, and like I said, if I see it work for a while without tinkering with browsers, I'm not opposed.
Personally, I think all that stuff is way too much overhead to be considered for the core on chip tools, but may well work out great as a pack one could use. If the minimums are well done, it should be easy to build on them.
Or, just ignore those, and load up something targeted right at browsers.
When a person is working with others, using Internet, etc... those updates matter. If that is not the case, then yeah. Things like an encryption sunset, or a tool that uses some new thing may well for updates as well.
Let's just say, should good things appear, and work over some period of time, I'm inclined to check it out.
The browser is another story. Mostly a mess. Especially the dog's breakfast MS made out of IE
Saying "except for the browser" is like asking "Other than that, how was the play, Mrs. Lincoln?" Don't even get me started on exception handling in callback functions.
I think all that stuff is way too much overhead to be considered
Somewhere deep in my soul I agree with that sentiment. Things have gotten very complicated.
Back in the day we had a minicomputer or microprocessor or MPU connected to a serial line connected to a teletype or green screen terminal. Basically the human interface was simple enough to be mechanical hardware or simple electronics.
Soon all the teletypes and green screens were gone. The teletypes were terribly expensive mechanical devices. The green screens were replaced with a PC running Procom or whatever terminal emulator.
Then comes the world of proprietary operating systems and development environments and the lock-in that has cause so much trouble for three decades or more.
Today we find that processing power and net connectivity has almost zero cost. The WIFI is that serial line at a fraction of the cost of the cable never mind the connectors and hardware at each end, a browser is the terminal software. All at thousands of times less expense than thirty years ago.
We also have the bounty of open source everything.
So, if you want to build a long lived system independent of any particular OS or vendor the net and the browser are the way to do it.
I do want all that to be independent of any "cloud" services or other servers out there though. Which sadly is not the plan among the "Internet of Things" players today.
Well the tone of this thread seems very upbeat for self-hosting systems even if it is mostly for the P2. I've never bothered to fully complete the self-hosting for the P1 itself but it would be a bit of fun to make a stand-alone computer.
This makes the most sense on P2, as the P1 is going to be too small and way too slow for anything other than 'a bit of fun'.
However, there is always P1V, and the board I linked above has VGA, PS/2 and 256k x 32 Fast SRAM, designed for the ProjectOberon self-hosted design.
The FPGA used has 13248 CELLS.
I just wish they would arrange to allow users to grant permission to web pages to access a serial port like they do with web cams and microphones now in HTML5. Then we could make in browser terminals and other tools.
Nice proof it is still not-quite-ready for prime-time (but fine for niche use)
Get back to us when this is implemented in multiple stable browsers, with decent speed support.
Heater, I also think if you want to build something with no OS, etc... dependencies, serial and some on chip baseline tools will do the trick and do so in less storage than the browser interaction code will consume itself!
Funny, someone just gave me an old TTL green screen. I may go ahead and make a driver for it. Maybe some tricks are possible!
Yes, those and the high resolution composite are gone, but we emulate terminals and capture video easily.
All those old, simple things still work just fine, and you can pick your OS and or hardware to operate with them too. This is the way the on chip stuff should work too. So far, it is all the closest to works no matter what that we have.
A serial connection to your PC cannot be had without a USB/serial adapter, a hugely complex OS and USB drivers to talk to it and some terminal software.
Nothing simple about any of that.
The screen you are using to display anything at all has more processing power than the Prop II can dream of.
Nothing simple about any of that.
Actually assembling a "simple" system with RS232 + teletype/green terminal is not economically viable.
Peter, you have rekindled my interest in FORTH. I am a plodding programmer, but I get things done. 25 years ago I learned FORTH as part of an employment opportunity, and used that experience 23 years ago to produce an embedded controller system that is still in production! While I still struggle with the philosophy of the propeller, I am gradually getting it. I actually have three propeller based projects in commercial use with no issues.
I am now considering porting that 1993 system to the propeller with your FORTH. Thanks for all your work!
Dave
Attached is a picture of my Brodie book, a required purchase by my employer...so grateful.
Hi Dave, sorry to hear you had to use Forth! So like you, the project is still plodding on decades later! Better than a flash in the pan I say!
I lent out (lost) all my Starting Forth books a long time ago but it still held fond memories of when I first read it and at the time I could use Micromotion Forth on the Apple. The fun and experience I got from that led me to use Forth professionally in POS terminals with great success. In those days I could use a modem to dial across the country and talk to individual multi-dropped terminals and diagnose problems or make code changes (in battery-backed SRAM) while the terminal was in use.
About a year ago I decided to look for a replacement for that book and found one online that was in very good condition, so now it sits in my bookshelf for me to flip through whenever and it is never ever going to be "lent out"
@Prof: I don't think you can look at the Forth you had back then and say "well the standalone system doesn't have any advantages". Tachyon is way more advanced in its speed and compact memory usage plus O/S style support with its FAT32 filesystem, WIZnet server and built-in VGA that I can say that I can see an advantage in some circumstances. Mind you though, I don't really see the need for an actual keyboard and monitor most of the time but I do have systems that use that so it becomes an advantage to have the source on file and a simple editor. The advantage of the standalone system is illustrated and evident as in the case of the Apple II computers for instance. In other systems I use my phone/tablet as a Bluetooth or Telnet ANSI terminal.
I don't really miss the green screen days Heater. We have a lot more now.
As for serial, I see it a lot, and it isn't hard to deal with, unless we are talking about appliance type devices. No serial fault there, more like a hostile device.
Basics like serial, composite, analog audio, and such, are everywhere and see a lot of use. Thete are always pushes to get rid of them, but their replacements come with more resources, dependencies, licenses...
Given how much serial is being used, I have no real worries about it. Far fewer than I do a browser or some custom comms.
For the on chip stuff, serial, or native keyboard mouse require the least and enjoy decades of broad support. Self hosting systems should employ the lean, well proven stuff. All else can be added, maintained...
Hi Dave, sorry to hear you had to use Forth! So like you, the project is still plodding on decades later! Better than a flash in the pan I say!
I lent out (lost) all my Starting Forth books a long time ago but it still held fond memories of when I first read it and at the time I could use Micromotion Forth on the Apple. The fun and experience I got from that led me to use Forth professionally in POS terminals with great success. In those days I could use a modem to dial across the country and talk to individual multi-dropped terminals and diagnose problems or make code changes (in battery-backed SRAM) while the terminal was in use.
About a year ago I decided to look for a replacement for that book and found one online that was in very good condition, so now it sits in my bookshelf for me to flip through whenever and it is never ever going to be "lent out"
I gave my copy away too but I just ordered another. Seems like a classic that should be on the bookshelf of any programming language junkie like me. :-)
I just wish they would arrange to allow users to grant permission to web pages to access a serial port like they do with web cams and microphones now in HTML5. Then we could make in browser terminals and other tools.
How can we get this done? With the OSS Mozilla, maybe it's as simple as submitting a patch?
We've got three rough self-hosted use cases under discussion here: (P2 assumptions in play, with the assumption of programming for P1 too at some point)
First, I am mentioning the Apple 2 here, not out of nostalgia, but as an excellent model for how this kind of thing can go and how useful it turned out to be. Those computers, though lacking in the fancy graphics and custom chip department, were designed to be development workstations and they ended up being exactly that. Lots of cross development happened on them, test, measure, control did too. The ideas in them are still quite relevant and useful today.
1. Minimum on chip tools: Assembler, Monitor, Editor, Crypt, Loader, maybe some shared things, like SPI block read / write routines*, serial routines, etc... Turn it on and talk to it straight away.
*I have that mentioned, because it proved very useful on the Apple 2 to have some basics in the ROM, and in particular, one of those was enough to read track 0 on the floppy disks without requiring a DOS. A DOS would be loaded with that routine, which could then ignore it from there and do whatever it wanted.
So, if you want to on the Apple 2, you can write a program on the default tools, and write it to a disk and get it back, low level, track and sector (block today) style. Doing that made all sorts of well integrated, bootable media possible. (Which is why I really want partition support, and or Peter's parameter block scheme to be in the SD boot methods, if we have SD boot methods. If we don't, then this kind of thing ends up in whatever block storage the chip can boot from.
As stated above, to me that means native keyboard, mouse, display, or serial I/O with the cool autobaud trick developed for "hot"
This is self-hosted, and on-chip. Available no matter what, but easily ignored / overwritten. It's also the minimum for bootstrapping, because it's baked in, not going to change, unless a new ROM somehow gets done at some later, "after success" date. It's also somewhat in line with how the P1 offered up some useful things in the ROM. So, on the P2 chip, if you want to, you can write whatever you want, write it to disk and get it back low level style, just using modern ideas and storage capabilities. This will lead to all sorts of well integrated things being made, just as it did with the same ideas in the past.
**I keep thinking about RAM and how it can get trashed. Wondering if it's worth pestering chip for a HUB RAM write disable for the first 16K block... It's not needed though, just super nice to have, so I've mentioned it, but that's it.
2. Bench Computer "Sweet Spot, loadable on-chip environment. FORTH (already got it, just need to sort out booting on the P2), Browser capability, SPIN, C, BASIC, whatever. Debugger, and perhaps some handy utilities. Anyone wanting to do this and have it self-host on boot, just needs to look at the minimums, whatever hooks are provided, and then do what makes sense from there. This is what you do with case #1, if you want / need to.
Turn it on, it sees this environment, loads it, then you talk to it from there.
Potentially, a lot of the chip resources are used. This is like the bench computer, intended for interactive use, prototyping, poor man's basic test / measure equipment set, etc...
It's here that the, "use a browser" option may make sense, given there is a network (or serial?) connection available. Given Contiki works on something like 64K or less, having a basic network may make sense, given the 512K HUB available.
It's also here that maybe building code for a P1 chip can be a loadable option.
This one is fluid, as it's a loadable thing. Improves as tools do and as use cases may demand. On P1, we've got FORTH, BASIC, Sphinx...
Tachyon is the best example, at this time, of this case as well.
3. Custom load. User takes control of it all, grabs what they want, if anything, from the Bench Computer use case, and builds out a device environment that targets what they really want to or need to target. Peter's system(s) seem like the best example, at present, of this case too. It's targeted to get specific things done, every unit running some set of the native tools, and a reference, or admin type environment could be managing all the other ones.
You turn it on, it sees this, and does whatever it's told. You might not talk to it much.
This is still self-hosted, but loaded onto the chip, not just present by default, and not necessarily, likely frequently, not standard at all. It's whatever the user / developer needs to "get it done" whatever "it" happens to be.
This is the propellers programming propellers use case, taken to it's logical conclusion.
4. Hybrid. Primary dev on another machine, likely a PC, but not necessarily. Of course, none of this has much to do at all with the non-self-hosted use cases, which basically ignore all of the on-chip stuff, unless a user program specifically requests it be present, such as the case of calling a COG in the use program to make the monitor available, like we did on the "hot" design iteration.
You turn it on, send it something, and then go from there, just like we do today, the difference being the environment / application / program makes use of something supplied on chip.
A loadable debugger, perhaps completed as part of the "bench computer" case, would be another great example of this happening. Program written to comply with whatever the on chip memory use is, which allows for using any bits that make sense.
When Forth was developed, self hosting was important. A decent PC (generic) was still a few years away, and time rented on time share systems was expensive.
Today you can buy an incredible PC for little more than $100, and it has a screen 4 times bigger (more pixels) than a P2 and maybe 500x the performance.
So if you are going to live off grid, and not communicate with anyone on the internet, what is the point of self-hosting other than being cute, maybe educational, or mildly amusing for a while. You will still turn on that PC, smart phone, or tablet to surf the web, write emails or post here on the forum.
There are billions of embedded ARM processors (cortex class) and tens of billions of older CPUs out there and few if anyone who develops code for them on that CPU.
@Brucee: Self-hosting is not an important feature, but it can be practical for various reasons and so the question is, is it do'able? But much like landing man on the moon, in itself it wasn't all that important, but the technologies that were developed had great spin-offs. Once you get a system self-hosting you then have a lot of great components that you can mix'n'match to suit the application, and in some applications that might mean self-hosting.
There is a timelessness with this approach as long after the source and the tools have disappeared along with the readme/howto that would otherwise be hosted on PCs etc you can come along to the target self-hosted system, edit the source code on the unit itself, and update as necessary. Mark Watney had to edit hex with a lot of help from Earth to make a patch, having the source on-board would make the job a lot easier. This is just my take, but maybe the P1 and P2 can benefit from a mission into self-hosted space too.
Hi Dave, sorry to hear you had to use Forth! So like you, the project is still plodding on decades later! Better than a flash in the pan I say!
Arrgh!
I've been captured by the FORTH again!
Seriously, I've used your most excellent Tachyon Forth lately to check some hardware I/O with great ease. I always liked the interactive nature of Forth. I am looking forward to learning more and implementing Tachyon in some future projects.
Thanks you for producing Tachyon and making it available.
Comments
This past summer, for example, I was sitting at a beach-bar at Lido Di Jesolo (near Venice, Italy), sipping Campari & Soda, watching ladies (topless :cool:) volleyball (this is absolutely true).
I received an alert on my cell phone (I use Zello, 2-way radio) from my customer in North Carolina. These are the guys that make the ugly yellow school buses.
We had recently retrofitted one of our control systems to one of their tube forming machines and they had discovered an "undocumented feature" (bug).
Using TeamViewer on my Galaxy S5, I accessed the interpreted code, located the problem and made a modification. For my machine's HMI, I use a heavily protected tablet and my customer used the integrated camera to demonstrate the problem of the machine's behavior.
The customer was delighted with the instant fix that didn't require a factory visit.
I am currently attempting to replicate the features of this motion controller using the Prop and it's really coming along. The problem, up until recently, was what do I use for an interpreted command processor. Well, I was recently made aware of the Micromite product and then realised that I already had something similar, the ByPic. So, my plan is to use the Prop for what it really excels at and use one of these other products for command processing as they feature FP math and have more than enough memory for my needs.
PropBASIC has made it very easy for me to achieve very high performance on the Prop and test all kinds of "what-if" features/scenarios that MUST run at PASM speeds, without me having to code in the relatively tedious PASM.
JS the language has been very stable since ES2 or whatever. Even MS faithfully copied all the broken language features of the original Netscape version into IE and then insisted they get baked into the ECMA standard.
That makes JS the language more stable than C, C++ and many others.
The browser is another story. Mostly a mess. Especially the dog's breakfast MS made out of IE
The Edge browser is playing nicely with the web standards and following along with the other guys too.
OK, I'm persuaded. Although I was never really opposed to to the idea I just saw it as not being needed when we already have PC's.
What you are describing reminds me of the early days with the 8080 and Z80, and how much could be accomplished with the simple tools a small eprom based monitor/debugging tool provided. The hardware available today makes so much more possible.
The various JS based things I have used online work a lot of the time, but I really can't just keep a stable browser with the updates happening all the time.
If people were serious about compliant JS, that has merit. For sure, I'm not opposed, just don't want to be forced into using a browser. I'll take ASCII, thanks.
Serial and ASCII, maybe even optional ANSI or VT-x will work on anything that has serial and some CPU or other, VT 100, Apple 2, PDP era on up to modern day. Who knows? People keep wanting to give me an IRIX box. A nice O2 or Indy with video capture would make a great dev terminal, as well as full on station, using C OpenSpin, etc...
All that should be possible, or we aren't doing it right. Does not mean people have to go that way, just that they can. Also means props programming props too.
A browser option would be a good, optional load or switch, for the poor souls running a closed tablet or something similar.
I swear, we need to make a simple program it via serial link using dots on the display for some of these devices... something. I like things like an iPad as readers. Useless otherwise.
I have kept an Apple 2 for that reason. It's old, and 1mhz means using assembly for anything meaningful. But it is easy 6502 assembly, so there is that. But, it and an Atari were the bench computers. I got a ton of learning and cool stuff done with those and books back then.
When I got an old Tek scope, it was a potent setup.
My favorite P1 way is terminal and or video output, both displayed on my computer. A P2 will allow this, have room to do more meaningful things, and won't necessarily need much else. Could use my Apple with it. (And I might, for a fun curio)
Anyhoo, the bench computer use case is a primary target for P2, as far as I am concerned. I believe it will get used, particularly given the fancy pins and all those DAC options. The thing will be a playground. Setup one as bunch computer, maybe enclose it and provide some buffered, raw I/O on headers and other nice plug it in and go type connectors and cables. I may model up and print something like that, when we get to the "real chips are gonna happen for sure" stage.
A few COGS provide the computer, display, data capture and data out parts. User does stuff with the remaining ones, no OS really needed. This is seriously powerful and easy once we get those very basics in the can.
Making one could be a killer kit set too. 200 in one, and the first thing you do is make the computer that works for all the other fun stuff it does.
Somebody finds one in a bin 20 years from now, and it works as well as the ones we find in the bin today do.
On a pro note, an similar arrangement doing say, industrial automation, requires only documentation to be useful and serviceable for a good long time too.
I'm surprised at your comment about "updates happening all the time" In the Windows world IE has only moved to new versions with new OS versions. MS has gone to huge efforts to make newer IE versions backwards compatible with older versions. Especially for those enterprise installations that are dependent on MS specific extensions.
Out here we don't worry about browser upgrades. Chrome and Firefox keep evolving but there has been no urgent need to keep up to date and normally I'm too lazy to bother.
There has been a constant nag of "upgrade Java" or "upgrade FLASH", another story as I say, and one I have not bothered with for ages. Don't think I even have a FLASH or Java installed anymore.
Then there is the problem of web sites insisting on using whatever new web standard features come along, rounded corners on divs or websockets. Hardly a concern if you need the latest and greatest for a WEB IDE or whatever.
I just wish they would arrange to allow users to grant permission to web pages to access a serial port like they do with web cams and microphones now in HTML5. Then we could make in browser terminals and other tools.
If the target application is bit banging, then the prop is a good choice.
If the target needs modification in the field, and one needs and arbitrary or generic tool chain, for example a smart phone or laptop serving as terminal, WITHOUT specific libraries and etra hardware (debugger, incircuit emulator etc); then and interactive kernel environment is a good choice.
In practice, hot programming in the field on the flly isa pain in the neck, simply because its different then working on the PC workstation one my desk. I'm used to my PC, its already set up; a tiny keyboard and a tiny screen away from my coffee cup is just not convenient.
We had the Jupiter ACE version of forth ages ago, they provide a standalone interactive work environment. But we didn't use these, as the PC is a better way to get actual work done.
Need a browser or ability to view PDF? You have a laptop and smart phone that does this. Why waste the time and effort to build it into your prop app? You COULD, I didn't; too many other fish to fry, and existing tools do it better anyway.
Doing all this (again) in C (etc) MIGHT get a dfferent result this time. But the forth experiments did not uncover a way in which "standalone" had advantages over "PC".
On the other hand, in forth, we can re-program a live system over the internet while it running. Save time and travel expenses etc. If a standalone system allows that, then it can have obvious advantaqes. But one might have to design this from the start to get it to work. I don't know if this is possible with existing basic systems, or if could be possible with a compiled system for example using C or SPIN.
Personally, I think all that stuff is way too much overhead to be considered for the core on chip tools, but may well work out great as a pack one could use. If the minimums are well done, it should be easy to build on them.
Or, just ignore those, and load up something targeted right at browsers.
When a person is working with others, using Internet, etc... those updates matter. If that is not the case, then yeah. Things like an encryption sunset, or a tool that uses some new thing may well for updates as well.
Let's just say, should good things appear, and work over some period of time, I'm inclined to check it out.
Saying "except for the browser" is like asking "Other than that, how was the play, Mrs. Lincoln?" Don't even get me started on exception handling in callback functions.
Back in the day we had a minicomputer or microprocessor or MPU connected to a serial line connected to a teletype or green screen terminal. Basically the human interface was simple enough to be mechanical hardware or simple electronics.
Soon all the teletypes and green screens were gone. The teletypes were terribly expensive mechanical devices. The green screens were replaced with a PC running Procom or whatever terminal emulator.
Then comes the world of proprietary operating systems and development environments and the lock-in that has cause so much trouble for three decades or more.
Today we find that processing power and net connectivity has almost zero cost. The WIFI is that serial line at a fraction of the cost of the cable never mind the connectors and hardware at each end, a browser is the terminal software. All at thousands of times less expense than thirty years ago.
We also have the bounty of open source everything.
So, if you want to build a long lived system independent of any particular OS or vendor the net and the browser are the way to do it.
I do want all that to be independent of any "cloud" services or other servers out there though. Which sadly is not the plan among the "Internet of Things" players today.
However, there is always P1V, and the board I linked above has VGA, PS/2 and 256k x 32 Fast SRAM, designed for the ProjectOberon self-hosted design.
The FPGA used has 13248 CELLS.
Get back to us when this is implemented in multiple stable browsers, with decent speed support.
Funny, someone just gave me an old TTL green screen. I may go ahead and make a driver for it. Maybe some tricks are possible!
Yes, those and the high resolution composite are gone, but we emulate terminals and capture video easily.
All those old, simple things still work just fine, and you can pick your OS and or hardware to operate with them too. This is the way the on chip stuff should work too. So far, it is all the closest to works no matter what that we have.
A serial connection to your PC cannot be had without a USB/serial adapter, a hugely complex OS and USB drivers to talk to it and some terminal software.
Nothing simple about any of that.
The screen you are using to display anything at all has more processing power than the Prop II can dream of.
Nothing simple about any of that.
Actually assembling a "simple" system with RS232 + teletype/green terminal is not economically viable.
I miss those days too....
I am now considering porting that 1993 system to the propeller with your FORTH. Thanks for all your work!
Dave
Attached is a picture of my Brodie book, a required purchase by my employer...so grateful.
I lent out (lost) all my Starting Forth books a long time ago but it still held fond memories of when I first read it and at the time I could use Micromotion Forth on the Apple. The fun and experience I got from that led me to use Forth professionally in POS terminals with great success. In those days I could use a modem to dial across the country and talk to individual multi-dropped terminals and diagnose problems or make code changes (in battery-backed SRAM) while the terminal was in use.
About a year ago I decided to look for a replacement for that book and found one online that was in very good condition, so now it sits in my bookshelf for me to flip through whenever and it is never ever going to be "lent out"
@Prof: I don't think you can look at the Forth you had back then and say "well the standalone system doesn't have any advantages". Tachyon is way more advanced in its speed and compact memory usage plus O/S style support with its FAT32 filesystem, WIZnet server and built-in VGA that I can say that I can see an advantage in some circumstances. Mind you though, I don't really see the need for an actual keyboard and monitor most of the time but I do have systems that use that so it becomes an advantage to have the source on file and a simple editor. The advantage of the standalone system is illustrated and evident as in the case of the Apple II computers for instance. In other systems I use my phone/tablet as a Bluetooth or Telnet ANSI terminal.
As for serial, I see it a lot, and it isn't hard to deal with, unless we are talking about appliance type devices. No serial fault there, more like a hostile device.
Basics like serial, composite, analog audio, and such, are everywhere and see a lot of use. Thete are always pushes to get rid of them, but their replacements come with more resources, dependencies, licenses...
Given how much serial is being used, I have no real worries about it. Far fewer than I do a browser or some custom comms.
For the on chip stuff, serial, or native keyboard mouse require the least and enjoy decades of broad support. Self hosting systems should employ the lean, well proven stuff. All else can be added, maintained...
How can we get this done? With the OSS Mozilla, maybe it's as simple as submitting a patch?
We've got three rough self-hosted use cases under discussion here: (P2 assumptions in play, with the assumption of programming for P1 too at some point)
First, I am mentioning the Apple 2 here, not out of nostalgia, but as an excellent model for how this kind of thing can go and how useful it turned out to be. Those computers, though lacking in the fancy graphics and custom chip department, were designed to be development workstations and they ended up being exactly that. Lots of cross development happened on them, test, measure, control did too. The ideas in them are still quite relevant and useful today.
1. Minimum on chip tools: Assembler, Monitor, Editor, Crypt, Loader, maybe some shared things, like SPI block read / write routines*, serial routines, etc... Turn it on and talk to it straight away.
*I have that mentioned, because it proved very useful on the Apple 2 to have some basics in the ROM, and in particular, one of those was enough to read track 0 on the floppy disks without requiring a DOS. A DOS would be loaded with that routine, which could then ignore it from there and do whatever it wanted.
So, if you want to on the Apple 2, you can write a program on the default tools, and write it to a disk and get it back, low level, track and sector (block today) style. Doing that made all sorts of well integrated, bootable media possible. (Which is why I really want partition support, and or Peter's parameter block scheme to be in the SD boot methods, if we have SD boot methods. If we don't, then this kind of thing ends up in whatever block storage the chip can boot from.
As stated above, to me that means native keyboard, mouse, display, or serial I/O with the cool autobaud trick developed for "hot"
This is self-hosted, and on-chip. Available no matter what, but easily ignored / overwritten. It's also the minimum for bootstrapping, because it's baked in, not going to change, unless a new ROM somehow gets done at some later, "after success" date. It's also somewhat in line with how the P1 offered up some useful things in the ROM. So, on the P2 chip, if you want to, you can write whatever you want, write it to disk and get it back low level style, just using modern ideas and storage capabilities. This will lead to all sorts of well integrated things being made, just as it did with the same ideas in the past.
**I keep thinking about RAM and how it can get trashed. Wondering if it's worth pestering chip for a HUB RAM write disable for the first 16K block... It's not needed though, just super nice to have, so I've mentioned it, but that's it.
2. Bench Computer "Sweet Spot, loadable on-chip environment. FORTH (already got it, just need to sort out booting on the P2), Browser capability, SPIN, C, BASIC, whatever. Debugger, and perhaps some handy utilities. Anyone wanting to do this and have it self-host on boot, just needs to look at the minimums, whatever hooks are provided, and then do what makes sense from there. This is what you do with case #1, if you want / need to.
Turn it on, it sees this environment, loads it, then you talk to it from there.
Potentially, a lot of the chip resources are used. This is like the bench computer, intended for interactive use, prototyping, poor man's basic test / measure equipment set, etc...
It's here that the, "use a browser" option may make sense, given there is a network (or serial?) connection available. Given Contiki works on something like 64K or less, having a basic network may make sense, given the 512K HUB available.
It's also here that maybe building code for a P1 chip can be a loadable option.
This one is fluid, as it's a loadable thing. Improves as tools do and as use cases may demand. On P1, we've got FORTH, BASIC, Sphinx...
Tachyon is the best example, at this time, of this case as well.
3. Custom load. User takes control of it all, grabs what they want, if anything, from the Bench Computer use case, and builds out a device environment that targets what they really want to or need to target. Peter's system(s) seem like the best example, at present, of this case too. It's targeted to get specific things done, every unit running some set of the native tools, and a reference, or admin type environment could be managing all the other ones.
You turn it on, it sees this, and does whatever it's told. You might not talk to it much.
This is still self-hosted, but loaded onto the chip, not just present by default, and not necessarily, likely frequently, not standard at all. It's whatever the user / developer needs to "get it done" whatever "it" happens to be.
This is the propellers programming propellers use case, taken to it's logical conclusion.
4. Hybrid. Primary dev on another machine, likely a PC, but not necessarily. Of course, none of this has much to do at all with the non-self-hosted use cases, which basically ignore all of the on-chip stuff, unless a user program specifically requests it be present, such as the case of calling a COG in the use program to make the monitor available, like we did on the "hot" design iteration.
You turn it on, send it something, and then go from there, just like we do today, the difference being the environment / application / program makes use of something supplied on chip.
A loadable debugger, perhaps completed as part of the "bench computer" case, would be another great example of this happening. Program written to comply with whatever the on chip memory use is, which allows for using any bits that make sense.
Today you can buy an incredible PC for little more than $100, and it has a screen 4 times bigger (more pixels) than a P2 and maybe 500x the performance.
So if you are going to live off grid, and not communicate with anyone on the internet, what is the point of self-hosting other than being cute, maybe educational, or mildly amusing for a while. You will still turn on that PC, smart phone, or tablet to surf the web, write emails or post here on the forum.
There are billions of embedded ARM processors (cortex class) and tens of billions of older CPUs out there and few if anyone who develops code for them on that CPU.
So I don't get why this is an important feature.
There is a timelessness with this approach as long after the source and the tools have disappeared along with the readme/howto that would otherwise be hosted on PCs etc you can come along to the target self-hosted system, edit the source code on the unit itself, and update as necessary. Mark Watney had to edit hex with a lot of help from Earth to make a patch, having the source on-board would make the job a lot easier. This is just my take, but maybe the P1 and P2 can benefit from a mission into self-hosted space too.