Propeller Browser (HTML Terminal) ?
jazzed
Posts: 11,803
Did I see someone post something before about this subject? Was I dreaming?
A "Propeller Browser" is a Propeller that interprets HTML and displays it on an LCD, TV, or VGA display. HTML would come in from a serial port and mouse/keyboard events would be transmitted on the serial port.
This question is motivated primarily by microcontrolled's Graphics Slave post, Peter Jakacki's GUI Terminal Client, and my own need for GUI based terminal.
Why is this interesting? A "Propeller Browser" would offer a standard* way of presenting a GUI for user interaction. A dedicated and separate Propeller Browser that interprets most HTML markup would off-load the video buffer and primitive processing from a device that runs a user application. The application device can of course be a PC or any micro-controller that can generate HTML and does not have to be internet enabled.
There are existing alternatives to a "Web Browser" that may be optimized for micros, but the interfaces are cryptic (written for micros) and require a steep learning curve for users that are otherwise already familiar with HTML. An HTML based interface would be easier to understand for many interested users to create interfaces because of the wide-spread use of the HTML mark-up language.
*Obviously Propeller doesn't have enough on board program memory to interpret all HTML elements, but my bet is that key components can be rendered and that is sufficient.
Thanks in advance for your input,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
A "Propeller Browser" is a Propeller that interprets HTML and displays it on an LCD, TV, or VGA display. HTML would come in from a serial port and mouse/keyboard events would be transmitted on the serial port.
This question is motivated primarily by microcontrolled's Graphics Slave post, Peter Jakacki's GUI Terminal Client, and my own need for GUI based terminal.
Why is this interesting? A "Propeller Browser" would offer a standard* way of presenting a GUI for user interaction. A dedicated and separate Propeller Browser that interprets most HTML markup would off-load the video buffer and primitive processing from a device that runs a user application. The application device can of course be a PC or any micro-controller that can generate HTML and does not have to be internet enabled.
There are existing alternatives to a "Web Browser" that may be optimized for micros, but the interfaces are cryptic (written for micros) and require a steep learning curve for users that are otherwise already familiar with HTML. An HTML based interface would be easier to understand for many interested users to create interfaces because of the wide-spread use of the HTML mark-up language.
*Obviously Propeller doesn't have enough on board program memory to interpret all HTML elements, but my bet is that key components can be rendered and that is sufficient.
Thanks in advance for your input,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Actually Morpheus + Catalina + one of my high-resolution 4 color bitmap drivers could even render buttons etc. (mind you, probably slowly)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
As far as LCD etc...
I will not announce any more products before they are ready... I will not announce any more products before they are ready... I will not announce any more products before they are ready... I will not announce any more products before they are ready... I will not announce any more products before they are ready... I will not announce any more products before they are ready... I will not announce any more products before they are ready... I will not announce any more products before they are ready... I will not announce any more products before they are ready... I will not announce any more products before they are ready... I will not announce any more products before they are ready... I will not announce any more products before they are ready... I will not announce any more products before they are ready... I will not announce any more products before they are ready... I will not announce any more products before they are ready...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I wrote the serial port program for this, I've attached it below, allong with the Propeller Demo Code. You could make a nice HTML editor with this and my Graphics slave. It's nice to see that it is being used!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my new website!!
Use the Propeller icon!!
Follow me on Twitter! Search "Microcontrolled"
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my new website!!
Use the Propeller icon!!
Follow me on Twitter! Search "Microcontrolled"
The Contiki project has a 'lightweight' implementation of a web browser (text-based, like Lynx).
http://en.wikipedia.org/wiki/Contiki
http://www.sics.se/contiki/
Maybe something could be taken from their code?
--trodoss
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the Propeller Powered SIG·fourm kindly hosted at Savage Circuits
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
But then I couldn't find the code. Maybe you can point me to a precise link?
Thanks,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I found it.
http://www.sics.se/contiki/download.html
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
the SF page for the latest source is the following:
http://sourceforge.net/projects/contiki/files/Contiki/Contiki 2.4/ (12.4 MB) download
If you look in the /apps/webbrowser you should be able to see the source.
--trodoss
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the Propeller Powered SIG·fourm kindly hosted at Savage Circuits
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
Thanks,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
If it is just "one way" communication (and the Propeller is just consuming the HTML) then it should work fine.
The major challenge I would see of communicating serially with another MCU is that it must be capable of understanding/processing the 'post/get' requests, which would likely mean a TCP/IP implementation like SLIP would need to be in place [noparse][[/noparse]Edit:], or at least a bare-bones processing of the post/get would need to be in place.·
Since the primary 'mode' of communication is a serial connection, have you thought about using VT100/ANSI? That would give you a 'lighter weight' protocol for user interaction, and would still allow for some UI to be specified.
[noparse][[/noparse]Edit:]· pullmoll has created VT100 emulation for VGA that could be used.
VGA color and VT100 objects - (pullmoll)
http://forums.parallax.com/showthread.php?p=905162
Just a thought
--trodoss
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the Propeller Powered SIG·fourm kindly hosted at Savage Circuits
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
Post Edited (trodoss) : 6/21/2010 9:20:01 PM GMT
I'm interested in a method of exchanging page content and an event model that is familiar to many users and advanced beyond VT100. VT100 is nice for text and I use it all the time when developing applications with VI, but it is not a rich and immersive experience like a web page can be. Still, the Propeller and the output device will constrain the types of elements that can be used. Even with the constraints, Propeller is capable of more than of what VT100 (and CP/M) has to offer.
I do also intend for Propeller to be able to send HTML from one or more files to the Propeller Browser client and receive event notifications. In some ways that would be is a server, but without all the HTTP protocol and TCP/IP overhead.
Thanks for your help.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
But, compared with games, we have an advantage - the screen does not change most of the time. So you might take some time to build up a screen from html, but once it is created, it just sits there until the user clicks something.
My understanding is that the propeller is not fast enough to render graphics from external ram. So - the 32k internal ram is precious and so using it for graphics is a very good use for that ram. We could allocate half the ram to graphics? No, why not all the ram? 320x240 is 76800 pixels. 32768 bytes is 262144 pixels. Allocate 3 bits per pixel and there should be enough ram.
Now, in a cog, have some LMM code running that uses external ram to store the program. Pull in each instruction from external ram. Slow, but speed is not an issue here. Talk to other cogs via external ram postboxes. With LMM and external ram the code can be as big as you like.
Ok, what does 320x240 look like? See attached - this is a grab from the propeller site. You can only see a bit of the site, so lots of scrolling would be needed! And this is 4 bit color. Paintshop can't do 3 bit. Hmm - if you went 4 bit and made the screen just a tiny bit smaller then you could fit into 32k.
Not a trivial task. But maybe not impossible though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The proposal is for a Propeller based Browser client that provides enough functionality for an HTML Terminal GUI to be rendered by a Propeller to an LCD, TV, or VGA monitor with user generated events sent back to the "application host" micro-controller.
That being said, most of your observations are relevant.
Now I'm experimenting with the 1280x1024 VGA tile driver. Images are TBD and I may be totally off in my thinking. I like your ideas regarding graphics memory. Buttons, etc... can be rendered using the Propeller built-in font and they look pretty darn good so far.
I know I'll eventually hit the big Propeller memory wall ... it happens over and over again. That's part of the plea for a workable Spin interpreter that uses external memory ... and ideas that I've seen today can help that become a reality. To me LMM is just too big for a reasonable, simple, and cost effective external memory solution. Still, I don't think a user would want to interact with something that's slower than New England molasses, so the LMM option remains open.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
(I may gnaw my way through the internet cable connecting my Propeller if I ever see this.)
That being said, there is zero reason why text based materials couldn't be displayed very easily given what we already have.
Even some basic html tags like <CENTER></CENTER> or <H1><H2><H3> could be translated into various colors.
(ie: the Linux lynx browser)
An idea I've toyed with for a while is supporting some special ?HML commands hidden within the remark of a normal
webpage. Something like:
<-- <SPECIAL CODES> --!>
The micro would be programmed to see these special codes while the rest of the world remained blissfully ignorant
of what was going on. A kind of web-inside-a-web so to speak. You know, the kind of thing that imaginative sci-fi thriller
movies might have. (Only without all the secret society stuff.)
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Feature Projects: PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
Post Edited (Oldbitcollector) : 6/22/2010 4:28:08 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
No you haven't. There is no mention of licensing in any of the ZOG files.
In the unlikely event that someone is worried by such things I would probably put the LGPL or MIT license on it. Is there a "Do what you want with this file if you don't bother me license."?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, I agree. Start with small steps and build it gradually. HTML has become a very useful standard. When I do a visit at my local nursing home, their patient notes are on a 'web browser' program. It looks like the internet - buttons, pictures, graphics etc. But it isn't - the page is being served up by a local server and the computer is deliberately not connected to the 'net. The clever thing is that no training is required - everyone knows how to use a web browser.
HTML is *better* than VT100. Now we have done VT100, it is time to look at the next challenge. I think what you are proposing is a great idea.
I'm pulling together some ideas from your other thread on Big Spin. When Cluso designed the triblade and heater did the Z80 emulation, the key with external ram was speed. Hence the parallel ram. But speed is not the issue here. What you want is familiarity - a screen that you intuitively know what to do with. Buttons, text, graphics, text boxes etc. So I'm thinking about a hardware model that has one or a few of Bill Henning's serial ram chips. That only uses a couple of pins so the propeller stil has lots of spare pins for I/O.
Next = put Big Spin as an emulation in a cog, with serial ram containing the program. Maybe load it from an sd card - we have all that working now anyway so the eeprom doesn't need to do much.
But don't try to be fancy yet with caching. Just mindlessly load each spin instruction off an sd ram chip, execute it, then get the next one. Drop out square root and a couple of string instructions or whatever it takes to free up enough memory to add a serial ram driver. Later on, caching can be added. But right now it might make the whole thing too daunting.
Aim to free up all of the hub ram for graphics, or a hybrid of graphics and the VGA/TV text driver.
Then you can start getting really clever. Want a really fancy looking button? Just load a bitmap off the sd card and put it at a certain location on the screen.
So I suppose one question (for myself, and others), how much code does the bare minimum serial ram drive code take?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Several other guys had the SPI RAM's working with the Prop before me... what I came up with was VMCOG, which is virtual memory for the prop, and makes a decent hardware abstraction layer so apps can use external memory with a common interface. In the case of slow SPI memory, VMCOG is also a way of making them run MUCH faster [noparse]:)[/noparse]
It is actually much easier to build VMCOG support into bigspin that building direct SPI ram handling in, and using VMCOG, bigspin would be MUCH faster than running SPI ram's directly (which would also take up more room in the bigspin cog)
Another good approach is Jazzed's caching eeprom driver - that should also make for decent speed bigspin, however it does not expand the variable space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
ZOG allows for using the GNU tool chain which at some point will compile 99%
of all C programs just like the all the other GNU tool chains can.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
No idea how big Lynx is, I'd be surprised if we could get it to fit in our XMM solutions.
On a related topic I would like to get the uIP stack working under Zog using SLIP as a network connection to a PC or router.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
www.w3.org/TR/xhtml-basic/
A Prop-centric browser may need to set its sights lower still, however.
-Phil
So, lower sights are required (as Phil rightly said).
Of course, with expanded hardware, there are other ways to achieve this. However, look at the processing requirements for rendering the image. I think the prop may well be too slow for a decent display. Although I hate to say it, but I think this is a job for another processor(s) or FPGA's. IMHO it is just not a good Prop solution.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Clearly using the full HTML specification is not possible, but I've said that several times now.
As for the rest, we'll see what happens.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
www.w3.org/TR/1998/NOTE-compactHTML-19980209/#www3
This is designed to fit on a small screen without scrolling. This might make it possible to render the screen on the fly so the page would not have to be stored in its entirety in a separate buffer.
-Phil
Now that's a fair target. Supporting an existing standard would be best. We'll see if it's doable.
Thanks for finding that.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Talbot
New Market, MD, USA
Coincidently, I've been staring at the APPLET and SCRIPT tags and wondering how they would be used. Short SPIN byte-code programs might be loaded with the APPLET tag. I don't know how useful that would be except maybe in handling some events.
I don't know if there would be room for a separate interpreter for SCRIPT unless it could be loaded on demand into a COG and may be a small subset of BASIC. As it is onload, onclick and other events would be pre-defined to interact with the server side, but with a small scripting engine (or SPIN APPLET) some things could be done exclusively on the client.
All of this is subject to constraints of course.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM