Sorry to ask this...But im wiring up my screen and im using your code(just because i know that it works and I can test the hardware) and i can't seem to firgure out what DB0 through DB15 are needed for and where are they referenced in your code. And just one more thing(hopefully) what pin on the touchscreen module does the "Tv Pin" reference. I have searched around for answers for a couple hours and I can't find an answer.
Sorry, my bad. There is a schematic around somewhere and I thought it was on this thread but I think it is on another thread. I'll post when I get home. There are some HC374 latches and a 512k memory chip because there simply are not enough pins on the propeller chip. The TV is for debugging but it almost is at the point you don't need that and this frees up some pins.
I haven't published the schematic widely because it is not a very good design. It is far too slow and takes around 60 pasm instructions to get a pixel from the ram chip out to the display. I have a new (untested) design that I believe can send a pixel in 4 bytes. It is optimised for RAM to display speed (at the expense of slightly slower Prop to Ram speed). The thinking behind that is that with 170k for a full screen picture, there really is no point trying to output that from a propeller with only 32k. Better to buffer things like fonts and icons in external ram.
The new design is sitting on the computer at the moment but I keep thinking of improvements. So it may be another month before any board is ready.
However, if you want to test things out, keep things very simple. 16 prop pins to D0-D15 on the display. 5 control lines. 4 for an SD card. No TV for debugging. No touchscreen for the moment. So that is 25 propeller pins.
There are a couple of lines in the spin code to change so it outputs 16 instead of 8 bits. If you can tell me which prop pin numbers you are connecting to what I can give you some new spin code to try that will at least get something on the screen.
Thanks for the reply! I'm using pin 38-22 for the DO-D15 then 21-16 for control then 15-11 for SD card. That code would be helpful im new to graphics with the propeller and there is sure a learning curve.
instead of latching out VL and then VH, put everything on P0-P15 and then toggle the write pin.
I haven't tested this but something like
PRI LCD_Writ_Bus(VH,VL) | Vout
Vout := VL | (VH <<8)
OUTA := Vout
WriteLow
WriteHigh
and check all the pins like RSlow and RShigh.
I can't debug this as I don't have the circuit you have. Sorry again. You will probably need to do this one line at a time with leds on various pins. And then there is the pasm part. But at least with the spin part you might be able to get a pixel to display.
This is still *way* off something ready to publish as a working circuit or board that you can buy.
I've also attached the new circuit I am working on which has been designed from the point of view of a fast transfer of ram to the display, and then later the propeller was added. Not tested but some notes on what the code is likely to be are on the schematic. Not a simple circuit either, but the aim is to refresh the whole screen many times a second.
There are several (relatively) small html browsers. lynx being the most popular, but there's dos navigator (part of the freedos distribution iirc) and I'm pretty sure I've seen others, just don't remember where/when, so yes, definitely possible to build a web browser into the propeller, especially if you use one of those tetra boards (I so want one of those) so you have plenty of extra cogs to handle things. heh. I can help with the web browser code, but not advanced enough (yet) with spin or pasm to help there. I was thinking of using this touch screen for some sort of logo stand-alone programming for teaching programming at our local elementary school, might be kind of cool (if the school would let me do it) (not likely though, they don't seem to want after school activities.) My son would love it though.
This is fantastic!!! I'll definitely be looking at this in a few months when I'm getting ready to create my own touchscreen GUI for an engine management system!
Start simple, text only, headers, paragraphs, bold, italic. Load in fonts as required. Needs a html parser in Spin. Searching for "<" and ">" would be the start, then branch depending on the characters.
<html>
<body>
<p><b>This text is bold</b></p>
<p><strong>This text is strong</strong></p>
<p><big>This text is big</big></p>
<p><i>This text is italic</i></p>
<p><em>This text is emphasized</em></p>
<p><code>This is computer output</code></p>
<p>This is<sub> subscript</sub> and <sup>superscript</sup></p>
</body>
</html>
HTML is actually very simple. For a quick reference, I have always used the Bare Bone Guide To HTML, which can be found here: http://werbach.com/barebones/barebones.html. A little outdated, but still very good for a quick reference.
Just a note to myself, the commonest picture format on the net seems to be .jpg and these need to be decoded. Basic and C code here http://63.236.73.220/showthread.php?t=667395
For full color photos you would want to use JPEG or PNG. However, for images with 256 colors or less, than the GIF format would speed things up. It all depends on the resolution required.
Something else worth noting, you can also achieve some very nice background effects with a very small image and background parameter. If you have any questions, please don't hesitate to ask, I may be able to help you.
Good point. The format I'm using at the moment is .raw which is simply RGBRGB etc. Any graphics program can convert from any format to .raw, but for browsing I guess the browser needs to be able to decode whatever it is given. Interesting looking at the source code for this forum. .png seems to be the picture format. .png would be nice - all the icons on the GUI start off life as .png files (that are converted to .raw) but it would be great to leave them in their original form.
The javascript in the forum looks daunting though. I suspect this may need to start with baby steps and old-skool early 1990's text only pages.
but for browsing I guess the browser needs to be able to decode whatever it is given.
Yes I would assume that is the case, but first it is given the html document that includes formatting tags and image tags.
The javascript in the forum looks daunting though.
Yes, JavaScript is daunting.
Perhaps you might want to look at it from a different standpoint. In the Windows OS there are several types of controls which control the view, eg., TreeView, ListView, ScrollView, etc..., but they are all based upon the view. The view is a blank canvas which can be painted, structured, repainted, restructured, etc... You could always decode html documents, format the screen according to the document (paint text accordingly) and then when you come to an IMAGE tag, decode the image and paint it to the proper location.
Attached is the latest code. There isn't any breakthrough with this one - just tidying up the flip between landscape and portrait mode. I found a lot of code on the internet that was not correct and ended up with mirror images or worse. This code does the flip correctly now and the practical upshot is that pictures don't need to be rotated, and also there is not need to store two fonts - landscape and portrait - now it is just one font.
(I got into the html code and realised it was getting too complicated storing two fonts for every tag).
Also sending off the board today so hopefully soon others can join in the fun!
Here we go. A little html browser. Just need to attach it to the spinneret and serve up some simple web pages.
<html>
<body>
Simple html browser with text and pictures<br>
<b>This text is bold</b><br>
<big>This text is big</big><br>
<i>This text is italic</i><br>
<code>This is computer output</code><br><br>
<img src="aust128.raw" alt="Austria"/>
This is a picture of Austria
</body>
</html>
Propeller code can easily handle more <tags>. Pictures still have to be .raw files for the moment. Screenshot at the bottom.
PUB HTML | filesize,pointer,c,ramaddress,blocks
SetOrientation(false) ' landscape
Clearscreen(255) ' white background
ILISetcursor(0,0) ' local cursor
filesize := Loadfile(string("html.txt")) ' load into ram
pointer := ramtext ' pointer to ram
ILILoadfont(string("Times16.ifn")) ' default font
repeat until c == 254
if c <> "<"
c := ILI9325.readrambyte(pointer++) ' don't read in if already got a "<"
if c == "<" ' <
c := ILI9325.readrambyte(pointer++) ' get next character
if c == "p" ' p for paragraph
c := ILI9325.readrambyte(pointer++) ' read in ">" and discard
ILIcrlf ' new paragraph
c := 255 ' to exit
if c == "b" ' could be big or just b for bold
c := ILI9325.readrambyte(pointer++) ' get next character
if c == ">" ' it was b for bold
ILILoadfont(string("Times16b.ifn"))
c := 255 ' exit
if c == "i" ' must be big
ILILoadfont(string("Times20.ifn"))
repeat 2 ' read in rest of tag
ILI9325.readrambyte(pointer++)
c :=255
if c == "o" ' body so discard
repeat 3
ILI9325.readrambyte(pointer++)
c:= 255
if c == "r" ' must be <br>
ILI9325.readrambyte(pointer++) ' new line
ilicrlf
c := 255
if c == "h" ' html so discard
repeat 4
ILI9325.readrambyte(pointer++)
c := 255
if c == "c" ' code
repeat 4
ILI9325.readrambyte(pointer++) ' discard the ode>
ILILoadfont(string("Cour16.ifn"))
c:= 255
if c == "i" ' italic
c := ILI9325.readrambyte(pointer++) ' get next character
if c == ">" ' it was i for italic
ILILoadfont(string("Times16i.ifn"))
c := 255
if c == "m" ' img so load a picture
repeat until c == 34 ' read in until the quote
c := ILI9325.readrambyte(pointer++)
str.builtstring(true) ' clear the string
repeat
c:=ILI9325.readrambyte(pointer++)
if c <> 34
str.buildstring(c) ' get the name of the file and build a string
while c <> 34
' file is 128x98
fat.openfile(str.builtstring(false),"R") ' open the picture 128x98
filesize := fat.filesize ' divide by 3 for the number of pixels
blocks := (filesize / 3) /128 ' number of 128 byte pixel blocks
ramaddress := 0
repeat blocks
fat.readdata(@sdbuffer,384) ' 128 pixels, 3 bytes per pixel
ILI9325.docmd("E",@sdbuffer,@buffer2,128) ' convert to 2 byte .ili format, len is number of pixels
ILI9325.docmd("A",@buffer2,ramaddress,256) ' A must start on 0,256,512,768 etc move 256 bytes to external ram (must be 256)
ramaddress += 256 ' add 256
fat.closefile
ILI9325.draw(0+10,cury,127+10,cury+blocks-1) ' set up the area of the screen to draw in
ILI9325.docmd("C",0,0,blocks << 8) ' move bytes from ram out to the display
curx :=0
cury += blocks ' need to edit this for other file sizes - only works for 128 wide at the moment
repeat
c:=ILI9325.readrambyte(pointer++)
until c == ">"
c :=255
if c == "/" ' cancel character
c := ILI9325.readrambyte(pointer++) ' read in next character after /
if c == "b" ' could be cancel big or cancel b bold
c := ILI9325.readrambyte(pointer++) ' get next character
if c == ">"
ILILoadfont(string("Times16.ifn")) ' must be cancel bold so reload normal font
c := 255
if c == "o" ' cancel body
repeat 3
ILI9325.readrambyte(pointer++) ' read and discard dy>
c :=255
if c == "i" ' cancel big
repeat 2
ILI9325.readrambyte(pointer++)
ILILoadfont(string("Times16.ifn")) ' normal font
c := 255
if c == "p" ' cancel a paragraph
ILI9325.readrambyte(pointer++) ' read in ">" and discard
ILIcrlf ' new paragraph
c := 255
if c == "i" ' cancel italic
ILI9325.readrambyte(pointer++) ' get next character
ILILoadfont(string("Times16.ifn")) ' must be cancel bold so reload normal font
c := 255
if c == "c" ' cancel code
repeat 4
ILI9325.readrambyte(pointer++)
ILILoadfont(string("Times16.ifn")) ' must be cancel code so reload normal font
c := 255
if c =="h"
c := 254 ' /html so finish displaying and end the routine
if c == 255 ' exit character so read the next one
c := ILI9325.readrambyte(pointer++) ' read in next character ready to display
if (c=>32) and (c=< 126) and (c <> "<")
curx := ILIChar(c,curx,cury) ' only print if a valid ascii character
Yes I had a free day today. Amazing what you can do with a whole day of coding!
cluso, how can they lose your boards??
Got a little header for the browser - a back button, home button and a space to enter a URL.
Working on hyperlinks now - blue text and need to create a 'hot' area on the touchscreen based on the blue text. Then load up a new html file. There is also an html tag for making a picture a link as well.
html is a fantastic language. I spent a little time looking at vb scripts (which only work on internet explorer). If you can have simple vb scripts, why not simple spin scripts that can do things like change the state of a propeller pin? Then the html can start to be able to interact with the real world.
Working with local files on the SD card at the moment but with the spinneret, hopefully this can move to remote files as well.
Yes I had a free day today. Amazing what you can do with a whole day of coding!
Amazing work Doc! I'm really impressed with what you've got done. I just finished my hardware, like 10 minutes ago. Not quite a whole day's worth of work, but it still took some time. It's not pretty, that's for sure. It *SHOULD* work. The worst part was figuring out pinouts. Right now I'm using mostly pin for pin. Stacked the SD and Touch clk and i/o lines. I'm using a total of 24 prop pins for the display all in. 2 pins for SigmaAdc. I think i will need to make a few adjustments later, but this should get me going. I still have a lot of questions ...crying baby. must go for now.
So if I understand correctly Dr. I can't just connect DB and Control lines straight to the propeller. I need to run the through the IC's as in your schematic...Disappointing I was hoping i could run the wires straight to the propeller. Correct me if i'm wrong please.
The LCD will directly interface with the prop, as I am doing. From my understanding, the limitation is propeller ram. The ic's are SRAM that hold font data from my understanding. This offloads the memory intensive job of loading and storing fonts.
The LCD will directly interface with the prop, as I am doing. From my understanding, the limitation is propeller ram. The ic's are SRAM that hold font data from my understanding. This offloads the memory intensive job of loading and storing fonts.
Correct. You *can* connect propeller pins directly to the display. I think there might even be an "8 bit" mode for the display so you use less pins.
The external ram is mainly for fonts, and for when you might want to draw a window on the screen and then restore the background. You can get a lot working however without external ram - for instance pictures are usually moved straight from the SD card onto the screen.
There are many different ways to wire up these displays and I don't think we have explored them all yet.
I think html is going solve all sorts of problems for a GUI front end. There are simple commands, like changing the background. There are more complex things like forms, buttons, radio buttons etc.
Earlier in this thread I posted a calculator. I wonder if such a thing can be done in html?
I recently got the cart before the horse. I was at a microcontroller sig where a friend happened to have a spare LCD module mentioned here so I bought it off of him at a fair price. I then wondered what to do with it when I stumbled over this thread. Dr. Acula you are amazing, first CPM, now a touchscreen GUI. What's next, a KDE desktop ? I am looking forward to seeing what plays out and I definitely will be in line to buy one of your boards when its ready. In the meantime I have one of Ray's obsolete Propeller System Modules which uses a non-touch screen LCD with the ILI9325 to play with. It doesn't use extrenal ram, uses the font in the Propeller's Rom and is a bit slow on refreshing.
I've hit a bit of a wall and I'd appreciate some help here.
Let's start with the simple question. html tells you to draw a button on the screen, and the programs knows where the button is, so it can create a hotspot on the touchscreen. What happens when someone touches the screen?
Well, the simple answer would be to run some spin code. But the code will be different for every application, and it is not practical to code for many things because this will use up all the spin code memory very quickly.
The clever way would be to run a script. See post #87 above, scroll down about halfway into the calculator code to see the actual javascript that makes the calculator work. if '+' then add the numbers etc.
There is javascript, vbscript, and a language I had not heard of until today, TCL which appears to be a bit like "Cscript"
So that has got me thinking about script parsers. Which script parsers might already exist, and what language are they written in?
There might be one out there in C, in which case maybe this whole project is better off being ported to C.
Or maybe if the language is kept simple, it could be worth creating Spinscript?
I'll come back to this in a sec. While I was writing the html parser (and this will come up in a script parser as well), it seems there are multiple choices to make based on characters. You start off with "if" statements, then "case"/"switch" statements and eventually as you realise most of the letters of the alphabet are coming up, you start considering the merits of branch tables http://en.wikipedia.org/wiki/Branch_table
Branch tables are much faster. If you are searching for a match for letter "z", instead of searching first through every letter of the alphabet, why not take the ascii value for "z", add to a branch table and jump to the appropriate subroutine?
Can Spin do this?
Pasm can. heater and cluso99 used this in the Zicog with a vector jump for interpreting Z80 opcodes
dispatch_2 shl data_8, #2 'Mul by 4 to get a LONG offset into the table
add data_8, dispatch_tab_addr 'Index into table
rdlong vector, data_8 'Get vector from table
vect_1 jmp vector 'Jump(indirect) to the instruction handler
Original dialects of Basic used this:
ON A GOTO 100,200,500,700
But it contains the evil GOTO. Yet this does seem to be the fastest way to do branching because you can jump directly to the function without having to do any tests.
Interesting in that link above that C does allow this sort of thing
#include <stdio.h>
#include <stdlib.h>
typedef void (*Handler)(void); /* A pointer to a handler function */
/* The functions */
void func3 (void) { printf( "3\n" ); }
void func2 (void) { printf( "2\n" ); }
void func1 (void) { printf( "1\n" ); }
void func0 (void) { printf( "0\n" ); }
Handler jump_table[4] = {func0, func1, func2, func3};
int main (int argc, char **argv) {
int value;
/* Convert first argument to 0-3 integer (Hash) */
value = atoi(argv[1]) % 4;
if (value < 0) {
value *= -1;
}
/* Call appropriate function (func0 thru func3) */
jump_table[value]();
}
And so maybe that does sway the argument towards porting this project into C.
There is another very practical reason for porting this into C, and that is that C allows much larger programs, and an html parser is going to take a fair bit of code if you want to add all the features.
Back to SpinScript, if such a language existed, it would also allow Spin to break out of the 32k limit. And at the same time, create a Spin interpreter which would allow one to test Spin fragments of code and even whole Spin programs on a propeller itself.
So you could have spin programs that you can run immediately from within html. html would provide the framework such as the textbox for the text, the buttons for "run" and the like.
Of course, it would be slower to run, but it may be quicker to use because you would not need to wait for a download each time.
If the touchscreen is too small, you could always have a text VGA or TV display for writing the code, then switch displays when it is run. That is another nice thing about the propeller!
So back to SpinScript. It takes me back to the very first language I used which was Micro-Soft Basic, and this had the amazing and almost unique feature of being available with an interpreter and a compiler. Scripting languages recreates the advantage of this, which is that with slower processors and slow compilation/download, sometimes you just want to quickly test a single subroutine by itself without recompiling the entire program.
So - what language to write this in?
Spin could work, if the instruction set is kept simple. Not too much bracket nesting and the like. That calculator is a good example - you need enough smarts to build a string of characters, convert to a number, do some maths, print a result. Maybe some other stuff that is not so relevant on a PC but very useful on a micro, like change the state of a pin, read or output an analog voltage, send a byte out a serial port.
So there need to be some inbuilt libraries in the html browser that you can call.
So this is a question to ponder. If you want html to actually be able to do things, like turn on a led when you push a button on the screen, it needs some sort of interaction between html and the browser and hence the chip.
Scripting seems an answer. Define objects within the script that the propbrowser knows how to handle eg "serialport." or "dira."
Then parse the text and run it.
What script language to choose? Java, VB, C, Spin
What language to write the parser in? Spin, LMM Pasm, C?
Comments
Thanks for your patience,
Tyler
I haven't published the schematic widely because it is not a very good design. It is far too slow and takes around 60 pasm instructions to get a pixel from the ram chip out to the display. I have a new (untested) design that I believe can send a pixel in 4 bytes. It is optimised for RAM to display speed (at the expense of slightly slower Prop to Ram speed). The thinking behind that is that with 170k for a full screen picture, there really is no point trying to output that from a propeller with only 32k. Better to buffer things like fonts and icons in external ram.
The new design is sitting on the computer at the moment but I keep thinking of improvements. So it may be another month before any board is ready.
However, if you want to test things out, keep things very simple. 16 prop pins to D0-D15 on the display. 5 control lines. 4 for an SD card. No TV for debugging. No touchscreen for the moment. So that is 25 propeller pins.
There are a couple of lines in the spin code to change so it outputs 16 instead of 8 bits. If you can tell me which prop pin numbers you are connecting to what I can give you some new spin code to try that will at least get something on the screen.
Thanks,
Tyler
Schematic below of the circuits I am using.
The 16 bit output part to change in spin is
instead of latching out VL and then VH, put everything on P0-P15 and then toggle the write pin.
I haven't tested this but something like
PRI LCD_Writ_Bus(VH,VL) | Vout
Vout := VL | (VH <<8)
OUTA := Vout
WriteLow
WriteHigh
and check all the pins like RSlow and RShigh.
I can't debug this as I don't have the circuit you have. Sorry again. You will probably need to do this one line at a time with leds on various pins. And then there is the pasm part. But at least with the spin part you might be able to get a pixel to display.
This is still *way* off something ready to publish as a working circuit or board that you can buy.
I've also attached the new circuit I am working on which has been designed from the point of view of a fast transfer of ram to the display, and then later the propeller was added. Not tested but some notes on what the code is likely to be are on the schematic. Not a simple circuit either, but the aim is to refresh the whole screen many times a second.
Start simple, text only, headers, paragraphs, bold, italic. Load in fonts as required. Needs a html parser in Spin. Searching for "<" and ">" would be the start, then branch depending on the characters.
HTML is actually very simple. For a quick reference, I have always used the Bare Bone Guide To HTML, which can be found here: http://werbach.com/barebones/barebones.html. A little outdated, but still very good for a quick reference.
Bruce
And then for advanced internet programming and questions, go to: http://www.irt.org.
Bruce
EDIT: Oooopppsss, they are either under reconstruction or have hone off web.
Not that I have been checking image formats of all pics across the internet, but for:
For full color photos you would want to use JPEG or PNG. However, for images with 256 colors or less, than the GIF format would speed things up. It all depends on the resolution required.
Bruce
Something else worth noting, you can also achieve some very nice background effects with a very small image and background parameter. If you have any questions, please don't hesitate to ask, I may be able to help you.
Bruce
The javascript in the forum looks daunting though. I suspect this may need to start with baby steps and old-skool early 1990's text only pages.
Yes I would assume that is the case, but first it is given the html document that includes formatting tags and image tags.
Yes, JavaScript is daunting.
Perhaps you might want to look at it from a different standpoint. In the Windows OS there are several types of controls which control the view, eg., TreeView, ListView, ScrollView, etc..., but they are all based upon the view. The view is a blank canvas which can be painted, structured, repainted, restructured, etc... You could always decode html documents, format the screen according to the document (paint text accordingly) and then when you come to an IMAGE tag, decode the image and paint it to the proper location.
Bruce
I did not look it over to much, but maybe you could find some good guidance here: HTML5 in mobile devices, http://en.wikipedia.org/wiki/HTML5_in_mobile_devices
Bruce
(I got into the html code and realised it was getting too complicated storing two fonts for every tag).
Also sending off the board today so hopefully soon others can join in the fun!
Back to html coding...
Propeller code can easily handle more <tags>. Pictures still have to be .raw files for the moment. Screenshot at the bottom.
You obviously have too much time on your hands. Care to lend out some? heyhey
Looking good. Hope you have better luck with your pcbs. Just discovered mine have been lost since mid December so I have to get them done again
cluso, how can they lose your boards??
Got a little header for the browser - a back button, home button and a space to enter a URL.
Working on hyperlinks now - blue text and need to create a 'hot' area on the touchscreen based on the blue text. Then load up a new html file. There is also an html tag for making a picture a link as well.
html is a fantastic language. I spent a little time looking at vb scripts (which only work on internet explorer). If you can have simple vb scripts, why not simple spin scripts that can do things like change the state of a propeller pin? Then the html can start to be able to interact with the real world.
Working with local files on the SD card at the moment but with the spinneret, hopefully this can move to remote files as well.
Thanks,
Tyler
Correct. You *can* connect propeller pins directly to the display. I think there might even be an "8 bit" mode for the display so you use less pins.
The external ram is mainly for fonts, and for when you might want to draw a window on the screen and then restore the background. You can get a lot working however without external ram - for instance pictures are usually moved straight from the SD card onto the screen.
There are many different ways to wire up these displays and I don't think we have explored them all yet.
I think html is going solve all sorts of problems for a GUI front end. There are simple commands, like changing the background. There are more complex things like forms, buttons, radio buttons etc.
Earlier in this thread I posted a calculator. I wonder if such a thing can be done in html?
Here is a html calculator http://www.htmlfreecodes.com/Calculator_in_your_page.htm. Copy and paste it into any window in the w3schools site eg http://www.w3schools.com/html/tryit.asp?filename=tryhtml_font
and it does actually work!. So - time to code all those tags for tables and buttons etc. Maybe femtobasic for the inline functions?
By the way, The PSM is directly wired to the screen and uses 8 bit mode so it may be a good reference for this LCD module. The link is http://www.rayslogic.com/Propeller/Products/Psm/psm.htm.
I've hit a bit of a wall and I'd appreciate some help here.
Let's start with the simple question. html tells you to draw a button on the screen, and the programs knows where the button is, so it can create a hotspot on the touchscreen. What happens when someone touches the screen?
Well, the simple answer would be to run some spin code. But the code will be different for every application, and it is not practical to code for many things because this will use up all the spin code memory very quickly.
The clever way would be to run a script. See post #87 above, scroll down about halfway into the calculator code to see the actual javascript that makes the calculator work. if '+' then add the numbers etc.
What languages could we use for a script? http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.2.2
There is javascript, vbscript, and a language I had not heard of until today, TCL which appears to be a bit like "Cscript"
So that has got me thinking about script parsers. Which script parsers might already exist, and what language are they written in?
There might be one out there in C, in which case maybe this whole project is better off being ported to C.
Or maybe if the language is kept simple, it could be worth creating Spinscript?
I'll come back to this in a sec. While I was writing the html parser (and this will come up in a script parser as well), it seems there are multiple choices to make based on characters. You start off with "if" statements, then "case"/"switch" statements and eventually as you realise most of the letters of the alphabet are coming up, you start considering the merits of branch tables http://en.wikipedia.org/wiki/Branch_table
Branch tables are much faster. If you are searching for a match for letter "z", instead of searching first through every letter of the alphabet, why not take the ascii value for "z", add to a branch table and jump to the appropriate subroutine?
Can Spin do this?
Pasm can. heater and cluso99 used this in the Zicog with a vector jump for interpreting Z80 opcodes
Original dialects of Basic used this:
But it contains the evil GOTO. Yet this does seem to be the fastest way to do branching because you can jump directly to the function without having to do any tests.
Interesting in that link above that C does allow this sort of thing
And so maybe that does sway the argument towards porting this project into C.
There is another very practical reason for porting this into C, and that is that C allows much larger programs, and an html parser is going to take a fair bit of code if you want to add all the features.
Back to SpinScript, if such a language existed, it would also allow Spin to break out of the 32k limit. And at the same time, create a Spin interpreter which would allow one to test Spin fragments of code and even whole Spin programs on a propeller itself.
So you could have spin programs that you can run immediately from within html. html would provide the framework such as the textbox for the text, the buttons for "run" and the like.
Of course, it would be slower to run, but it may be quicker to use because you would not need to wait for a download each time.
If the touchscreen is too small, you could always have a text VGA or TV display for writing the code, then switch displays when it is run. That is another nice thing about the propeller!
So back to SpinScript. It takes me back to the very first language I used which was Micro-Soft Basic, and this had the amazing and almost unique feature of being available with an interpreter and a compiler. Scripting languages recreates the advantage of this, which is that with slower processors and slow compilation/download, sometimes you just want to quickly test a single subroutine by itself without recompiling the entire program.
So - what language to write this in?
Spin could work, if the instruction set is kept simple. Not too much bracket nesting and the like. That calculator is a good example - you need enough smarts to build a string of characters, convert to a number, do some maths, print a result. Maybe some other stuff that is not so relevant on a PC but very useful on a micro, like change the state of a pin, read or output an analog voltage, send a byte out a serial port.
So there need to be some inbuilt libraries in the html browser that you can call.
So this is a question to ponder. If you want html to actually be able to do things, like turn on a led when you push a button on the screen, it needs some sort of interaction between html and the browser and hence the chip.
Scripting seems an answer. Define objects within the script that the propbrowser knows how to handle eg "serialport." or "dira."
Then parse the text and run it.
What script language to choose? Java, VB, C, Spin
What language to write the parser in? Spin, LMM Pasm, C?
Thoughts would be most appreciated!