Although it is possible to add extra chips to do more wonderful things with the video I'd rather concentrate on getting the most out of the Prop itself and also so that when Prop II pops up I'm ready to port and play!
With that pathway in mind, you could always develop using TWO Prop 1's ? - if your total 'equivalent' COG use is <=8, it would morph into a Prop 2 quite easily.
With that pathway in mind, you could always develop using TWO Prop 1's ? - if your total 'equivalent' COG use is <=8, it would morph into a Prop 2 quite easily.
Prop II will have hardware to support communicating between cogs and other Props so anything I do with the current Prop will be a poor man's version although capable enough for present. My main focus now is getting Tachyon fully functional and robust for industrial applications.
I downloade the latest and finally h ad a chance to play with it. I loaded the 57600 binary... Since ZTerm on th Mac goes to 230400, I tried to recompile for that using Prop Tool, which kept barfing in the serial object to a reference to rbuf pprefixed with "@@@". I know I have seen a thread on this but cannot seem to find it. Is it a BST thing? Any hope for a Prop Tool compatible?
Is it a BST thing? Any hope for a Prop Tool compatible?
Yes, it is. Try this:
result := @HSSerialRx+4 ' Use cog image for serial buffer (skip 4 for control)
cognew(@HSSerialRx, [COLOR="#FF0000"]@HSSerialRx[/COLOR])
DAT org 0
HSSerialRx [COLOR="#FF0000"]add rxwr, par[/COLOR]
[COLOR="#FF0000"]add rxbuf, par[/COLOR]
mov Y0,rxbuf
...
rxpin long 0 ' mask of rx pin
[COLOR="#FF0000"]rxwr long 3 ' byte address of rxwr in hub
rxbuf long 4 ' pointer to rxbuf in hub memory
[/COLOR]
bitticks long 0
Yes, it is. Try this:
..............<snip\>..........
Thanks friend, I've been concentrating that much on Tachyon itself that the little sidekick HS-SerialRx didn't get much attention as it was more of a quick hack. I tried out your mods and can confirm that they work just fine.
Thanks for the feedback Brian, I will have to setup some help information but possibly on another document that's linked to from the source. I have a 25ms line delay which is pretty close to what you have. I have yet to figure out why Minicom doesn't understand software handshaking even though it has a setting for it. Once I sort that out then Tachyon will simply XON/XOFF at the application level to say "hit me" when it's ready for more and certainly at 3M baud that doesn't take long at all to fill the bill. I'm working on my EEPROM routines at present (working) and making it possible to backup the current session but there are a few tweaks I still need to make.
The latest binary image and source files have been zipped and updated on the top post and here --> TACHYON.zip. The EEPROM routines include bytecode that runs the I2C bus at 125kHz so that a full 32kB of EEPROM can be saved in 5.4 seconds and loaded in 4.3 seconds while not relying on anything but the Tachyon cog. In fact except for the high-speed serial cog and of course the VGA cog I am restricting myself to the one cog at present just to maximize what I can do with it first. For SPI and SD functions I can clock data at 2.8MHz which unfortunately was a tad fast for I2C and I didn't want to bog down the PASM code with programmable delays as I may end up using the counter to clock data at much higher speeds, especially when I fully implement my SD file system.
Anyway, there are a lot of little things that have been tidied up and improved with runtime compilation etc and I have had to move the VGA pixel buffer up a couple of K just so I can develop and test. Later on the dictionary will be fully optimized to run out of the 2K Tachyon image in hub plus the rest in EEPROM.
I think a lot of people have had a look at the on-line document but except for one grumpy comment at the start I haven't had too much feedback. I noticed that if I view it on another computer that I'm not signed into then it may appear slightly different to what I'm seeing. At the very least it always seems to show a paginated view with gaps between pages. On my Android phone and tablets it may have a different font but it's still readable.
I'm at the stage where I am documenting more and tidying things up before I move onto to the next big stage leading up to a full-blown stand-alone system capable of editing and developing with a part graphics and part text display. But I like the idea of using Bluetooth and that's the other way that this can be developed too, on a tablet which is both small, portable, and cordless. However, I am not locking it into any one method, I'd rather keep it very flexible.
The latest binary and sources are in a WHAT'S NEW section near the start of the document to make that more central to access and I'd like to keep as much of the documentation together with the source as the copy&paste into the Spin tool doesn't phase it one bit.
Finally I have gotten around to implementing the session backup feature where all user code and settings are backed up to EEPROM (it only needs a standard 32K). Just download the latest binary and include the IIC.fth source file (from the intro page) which when added you can tell it to do a BACKUP. There's also an AUTORUN feature so that your code can run automatically on startup.
On top of this I have created an "Introduction to Tachyon Forth" webpage (which automatically republishes from a Google Document) which will gradually be expanded to include all kinds of stuff including tutorials and projects.
The links for the current binary and other documents etc will also be located at the end of this page.
Hi Brian, I'm removing most of the links in the actual source code document and the thread as I want to put this in a central place and preferably on a standard web page that everybody can access easily. So use the links at the bottom of the Introduction page as these will always be up-to-date. In fact the binary and source code text files are sitting on my Dropbox account and all I have to do is copy my current files to that folder. No links to change and instantly updated. Now that I have a session save and autorun up and running I can really get into expanding the kernel. Next will be SD memory access then PS/2 style keyboard after which I will look at running multiple VMs concurrently and perhaps at least one that just looks after "background" processes and timed tasks.
For those who liked the simplicity of BS2 commands I am slowly building up equivalents of them. Here's a very useful one which I happened to have an immediate need for with a serial LCD where it pays to keep it simple. The BS2 SEROUT command transmits asynchronous data from any pin at any baud rate (within limits) and so it is with Tachyon Forth. I've tested this code for use up to 220K baud. Here's the code fragment for it and some typical uses.
: SEROUT ( data baud pin -- )
MASK DUP OUTSET ROT ( baud mask data )
$100 OR 2* ( baud mask data )
ROT #10 SWAP #80,000,000 SWAP / WAITCNT ( mask data )
FOR SHROUT 0 WAITCNT NEXT
2DROP
;
\ Demo code
: >LCD ( char -- ) #9600 3 SEROUT ; \ transmit serial data to the LCD on P3
: CLD $0C >LCD ; \ clear LCD
: SETBIG 2 >LCD ; \ big digit mode
: ENDBIG 3 >LCD ;
: TYPELCD ( str -- ) BEGIN C@++ ?DUP WHILE >LCD REPEAT DROP ;
CLD SETBIG " 123" TYPELCD ENDBIG " DEMO" TYPELCD ;
WAITCNT is a little different than what it is in Spin or PASM in that if you supply a non-zero value then it will save that value as the delta and calculate the target. You can get it to synchronize easily by simply saying 0 WAITCNT which uses the saved target and delta.
EDIT: With a slight modification to the kernel where WAITCNT does not need any parameters passed to it anymore and the word DELTA is used instead to set it up I can achieve over 400K baud speeds.
I know you like GoogleDoc, but I am a man on a mission - for Phil's Spin Documenter.
Since I ponder for a while now with getting into FORTH, I read this thread with interest. Looked at your GoogleDoc, found it to complicated and agressive for my use. Finally downloaded your code of post #70 and dove into it.
I still do not know much about FORTH but I do like your PASM-Source. WELL DONE!
So to better browse your source and understand it, I decided to 'rework' the way you are commenting your source according to the rules Phil posted in this Thread.
Fairly simple. I needed to repace/change some titles. Add some curly brackets and some dots. And DONE.
Then I took the spin fie and submitted it to Phils Spin Documenter. Saved the resuting file as Tachyon1v0-VGA_Doc.html. Impressive. Did the same with the rest of the spin files and added a README_Doc.html as a header. Here the complete Tachyon1v0-VGA-Autodoc.
Funny thing is - once you adapted the way of commenting you can at any time recreate a new HTML-file out of your Tachyon1v0-VGA.spin source. Just upoad it to Phil's Spin Code Documenter and save the resulting file as Tachyon1v0-VGA_Doc.html. That easy.
I did not wrote any of that documentation shown in the link. YOU DID. I just changed the way you are commenting a bit...
So PLEASE - open a beer - look at both sources - compare the comments - smile.
You can download from that web-page or take the attachment ... both are the same.
The whole shebang is just html - So it works on any webserver and even without webserver on your local harddrive. Just download the zip-file. (in windows7 right-click after saving, select properties and select 'unblock' if there)
Then unzip in folder of the same name as the zip - and voila there you go.
Start _README_Doc.html inside the folder.
BTW. I did not found VGA_512x384_Bitmap.spin in your zip. can you post it or give me a link ?
Ahh. And is there a HS-SerialTx.spin you can point me to also? I do like the simplicity of HS-SerialRx.spin
The tiny bit of code in the kernel labeled "transmit' is all you need but if you call it from Spin which is many times slower it will slow down the throughput and also take up a whole cog. Having it built into the Tachyon kernel means it's a lot more efficient to just send data out rather than trying to buffer it and this leaves the serial cog totally free to just concentrate on receiving data.
I've updated the links at the bottom of the Introduction page if you are looking for the VGA object.
I also had a look at the formatted source code and while it's very neat and kudos to Phil there is one big drawback for me and that is it's not editable on-line. At present if I make a modification to a document then everybody else has access to the very latest without having to upload or anything. However I don't mind adding the formatting if it makes it easy to convert but besides doing all this fancy (but not complicated or aggressive) formatting on Google Docs I have been far too busy concentrating on developing Tachyon itself in-between real work etc. It's only been about a month since I first announced I was going to do it and now I have it so it's very solid that I can easily use it in real products and the speed it runs at is fantastic. I would have loved this stuff if someone else did it but now that I've done it, it seems to be a bit of a flop as I can almost hear the yawns of disinterest from the forum. Perhaps if I burnt out a Prop or came up with a transistor to use with the Prop I would have had more interest. Of course that doesn't stop me from doing what I'm doing but a little helpful "user" feedback might prove beneficial for all, after all it's not a small amount of work to do this plus publish it in this format.
The idea behind the autodoc facility is that you don't have to create and store a separate HTML file, but convert the source on demand every time you need to view it in doc form. To make things even easier, I've created a "DOC" button that resides on the Prop Tool's toolbar. When clicked with an autodoc-ready Spin file showing, the file is converted on the spot to an HTML document which opens in the user's default browser. If the Spin file that's showing is not autodoc-ready, the user is prompted to see if he wants the program to add an autodoc template, which he can then simply fill in with the needed information.
I haven't posted this version publicly yet, since I'm waiting for an official nod from Parallax. There's a good chance that the templating facility will be extended to include optional retabbing and case-conformance to the Gold Standard spec, although the latter is one feature that I probably wouldn't use myself.
Did not find the "uemit" word in any of the posted files.
_Really like the BACKUP and AUTORUN words.
And just for fun the how about this link: http://www.inventio.co.uk/forthvsc.htm I've got my flame suit on so go ahead. I really like the part about if you don't understand the problem you shouldn't be writing software.
yes I stumbled over transmit already, nice. And - yes - this is a huge amount of work you are doing there. But at least you have ONE guy interessted in this - ME.
The style of commenting differs not much from what you are doing and you can keep your source where it is. But like Phil said anybody can (re)create the html-doc out of your source easy.
Did not find the "uemit" word in any of the posted files.
_Really like the BACKUP and AUTORUN words.
And just for fun the how about this link: http://www.inventio.co.uk/forthvsc.htm I've got my flame suit on so go ahead. I really like the part about if you don't understand the problem you shouldn't be writing software.
I think the problem might be the version so just make sure you get the latest because I do update it constantly. Just look at the links at the bottom of the Introduction web page. Bear in mind that I try not to change things too much but if it needs to it needs to. Things are starting to settle down a bit more now though.
The problem with the article from the link you gave to "Forth vs C" is it is too busy defending and comparing. The target audience have already been assimilated and any further resistance is futile for they C the world via their library implants. There is only one way of doing it and that's the library way and you had better fit in with it.
Forth is Forth, not C, and a good Forth is so much better than a bad Forth and some although well written can be bad simply because they do not address the needs of the application and platform, they seem to have been written more like an assignment in a CS class or are PC centric. So I can definitely tell you that this Forth is tailored both for the Propeller and for the many applications that you and I typically use it for.
yes I stumbled over transmit already, nice. And - yes - this is a huge amount of work you are doing there. But at least you have ONE guy interessted in this - ME.
The style of commenting differs not much from what you are doing and you can keep your source where it is. But like Phil said anybody can (re)create the html-doc out of your source easy.
@Phil - I takes Parallax 2 Years to NOD?
Enjoy!
Mike
Hi MIke, I've had some sleep so I'm feeling a little better now What Phil has done looks very professional and I'm surprised that Parallax haven't nodded yet because it doesn't really change anything for them, it can only make it better. The Google Docs however allow me to paste in images and tables and drawings etc which you can't normally do in source code. If it hampered my productivity I think I would know plus it would show. But it is very streamlined to copy&paste back into the Spin tool and hit F11. If I time it I guess it might take as long as 2,000,000us which if I were the Prop that would be a long time to wait around.
How about this: If I give you the keys to the car and grant you permission to edit the main document could you insert the extra formatting required without crunching the gears? Then you should be able to do a copy&paste or whatever into Guru Phil's confabulator.
I've thought about adding an image capability to the autodocumenter. Do you think it would clutter things too much to have a bunch of base64-encoded stuff in comments at the end of the source file to accommodate such a facility? I do want it to be completely self-contained, without referencing external files or urls.
BTW, if you don't want to be dragged into this discussion, just say so, and I'll understand.
Well there seems to be a great flurry of activity lately in the area of improving the documentation in various ways. In regards to base64 "junk" even if I had a heap of stuff down the bottom of the Google document I can hide it by graying it out and/or reducing the font size. Let's get into it and try it out. What do I need to do?
yes, I would love to do that. As you can see the differences are small and it will not disturb your progress.
Still need to wrap my head around FORTH. But reading your source helps a lot Since in FORTH everything seems backwards for me understanding the Language by understanding its implementation in PASM seems to be logical to me, somehow...
PM me how to do that, and I gladly accept your offer.
I am currently building up my own (Silver?) Standard Library of those objects I really need often.(Serial,I2C,SD,TV,VGA). Documenting them and, well add some generic I/O methods. This is preatty rewarding in it self. As you said "What Phil has done looks very professional".
yes, I would love to do that. As you can see the differences are small and it will not disturb your progress.
Still need to wrap my head around FORTH. But reading your source helps a lot Since in FORTH everything seems backwards for me understanding the Language by understanding its implementation in PASM seems to be logical to me, somehow...
PM me how to do that, and I gladly accept your offer.
I am currently building up my own (Silver?) Standard Library of those objects I really need often.(Serial,I2C,SD,TV,VGA). Documenting them and, well add some generic I/O methods. This is preatty rewarding in it self. As you said "What Phil has done looks very professional".
Enjoy!
Mike
English is an example of an SVO language in that we have a subject, then the verb and then the object. However in other languages it is common to have the verb last such as in SOV languages. Isn't Forth more like an SOV language then in that you supply the information first (subject, object) then feed it into the verb. Take for example if I had a command in something like a standard CLI:
DUMP $1000,$400
Well you could see that DUMP is straining at the bit to find out what it's got to dump and that information can only be in the form that it is prepared for, it's syntax. However in the back-to-front (or is it front-to-back from a reverse perspective) you can do what you like before you tell it what to do:
0 REG $100 DUMP
Eminently far more sensible in my opinion and far more flexible even in this very simple example. Hang on, in many programming languages to get a delay you have to say something like delayms(100) which is not how we talk either yet many programmers have had it instilled into them to think that way. In Forth I just say 100 ms and that's it.
Now I've got the uemit word in: Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120804.0140 but now it seems BACKUP is not working nor is COLD sensing a hard restart as before?
Now I've got the uemit word in: Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120804.0140 but now it seems BACKUP is not working nor is COLD sensing a hard restart as before?
I've been using a PROPBOE for testing.
I'm not sure what you mean by BACKUP is not working. Are you use the I2C.fth document from the link and are you able to EDUMP? If you ever want to reset to factory values and wipe out all your downloaded extensions then you have to do a COLD but this doesn't actually change the EEPROM so you then have to download I2C.fth and perform a new BACKUP. Perhaps I could build IC2.fth into the kernel but I am trying to do more with these Forth source extensions rather then "hard-coding" it into the kernel.
Sorry about the last terse message.
Okay just a little confused. I understand and have been using IIC.fth and others. Performing a RESET maintains my "user code" if I have done a BACKUP. Power off and on removes my "user code" and I get: Cold start - no user code - setting defaults. Got it. _My problem was trying to AUTORUN a word that used EMIT and I didn't get any output so I thought (mistake) it was the kernel. PEBKAC! Can / will we be able to disable "cold start" after power failure to enable AUTORUN the "system". NOCOLD
yes I am one of those programmers trained to think the other way. The whole concept of a DataStack still confuses me. So definition of PRTHEX for example. I think I do understand how it works and why. So far so good.PRTBYTE..WORD..LONG ok also. Then I hit DUMP.
OK. Now I need a piece of paper and a pen. Writing my own stack while jumping between definitions in code. This is a interesting concept of language, and certainly a very good match for the prop. But mindbending. Somehow it is like a functional language like "F" or so. But it isn't.
Having your PASM helps me out alot. There I feel home.
Anyways I did as you said in the PM and have write-acces to your document. Will start tomorrow... still browsing around in your doc. Having pictures is very nice.
Comments
With that pathway in mind, you could always develop using TWO Prop 1's ? - if your total 'equivalent' COG use is <=8, it would morph into a Prop 2 quite easily.
I downloade the latest and finally h ad a chance to play with it. I loaded the 57600 binary... Since ZTerm on th Mac goes to 230400, I tried to recompile for that using Prop Tool, which kept barfing in the serial object to a reference to rbuf pprefixed with "@@@". I know I have seen a thread on this but cannot seem to find it. Is it a BST thing? Any hope for a Prop Tool compatible?
TNX
result := @HSSerialRx+4 ' Use cog image for serial buffer (skip 4 for control) cognew(@HSSerialRx, [COLOR="#FF0000"]@HSSerialRx[/COLOR]) DAT org 0 HSSerialRx [COLOR="#FF0000"]add rxwr, par[/COLOR] [COLOR="#FF0000"]add rxbuf, par[/COLOR] mov Y0,rxbuf ... rxpin long 0 ' mask of rx pin [COLOR="#FF0000"]rxwr long 3 ' byte address of rxwr in hub rxbuf long 4 ' pointer to rxbuf in hub memory [/COLOR] bitticks long 0Thanks friend, I've been concentrating that much on Tachyon itself that the little sidekick HS-SerialRx didn't get much attention as it was more of a quick hack. I tried out your mods and can confirm that they work just fine.
Big thanks to Peter for the great work and to Kuroneko-san for the quick and accurate fix.
To optimize copy/paste transfers, you want to setup Settings --> Text Pacing , which controls copy/paste as well as File Send
- uncheck "wait for echo"
- set "delay between characters" to zero (0) 60ths of a second
- set "delay between lines" to two (2) 60ths of a second
( I tried 0 & 1 for line delay and it wasn't enough)
- save configuration Dial --> Save Setup
Anyway, there are a lot of little things that have been tidied up and improved with runtime compilation etc and I have had to move the VGA pixel buffer up a couple of K just so I can develop and test. Later on the dictionary will be fully optimized to run out of the 2K Tachyon image in hub plus the rest in EEPROM.
I'm at the stage where I am documenting more and tidying things up before I move onto to the next big stage leading up to a full-blown stand-alone system capable of editing and developing with a part graphics and part text display. But I like the idea of using Bluetooth and that's the other way that this can be developed too, on a tablet which is both small, portable, and cordless. However, I am not locking it into any one method, I'd rather keep it very flexible.
The latest binary and sources are in a WHAT'S NEW section near the start of the document to make that more central to access and I'd like to keep as much of the documentation together with the source as the copy&paste into the Spin tool doesn't phase it one bit.
Any feedback is welcome (hopefully positive)
On top of this I have created an "Introduction to Tachyon Forth" webpage (which automatically republishes from a Google Document) which will gradually be expanded to include all kinds of stuff including tutorials and projects.
The links for the current binary and other documents etc will also be located at the end of this page.
The code in Tachyon120801.zip is 120731 not 120801.0950
: SEROUT ( data baud pin -- ) MASK DUP OUTSET ROT ( baud mask data ) $100 OR 2* ( baud mask data ) ROT #10 SWAP #80,000,000 SWAP / WAITCNT ( mask data ) FOR SHROUT 0 WAITCNT NEXT 2DROP ; \ Demo code : >LCD ( char -- ) #9600 3 SEROUT ; \ transmit serial data to the LCD on P3 : CLD $0C >LCD ; \ clear LCD : SETBIG 2 >LCD ; \ big digit mode : ENDBIG 3 >LCD ; : TYPELCD ( str -- ) BEGIN C@++ ?DUP WHILE >LCD REPEAT DROP ; CLD SETBIG " 123" TYPELCD ENDBIG " DEMO" TYPELCD ;WAITCNT is a little different than what it is in Spin or PASM in that if you supply a non-zero value then it will save that value as the delta and calculate the target. You can get it to synchronize easily by simply saying 0 WAITCNT which uses the saved target and delta.
EDIT: With a slight modification to the kernel where WAITCNT does not need any parameters passed to it anymore and the word DELTA is used instead to set it up I can achieve over 400K baud speeds.
I know you like GoogleDoc, but I am a man on a mission - for Phil's Spin Documenter.
Since I ponder for a while now with getting into FORTH, I read this thread with interest. Looked at your GoogleDoc, found it to complicated and agressive for my use. Finally downloaded your code of post #70 and dove into it.
I still do not know much about FORTH but I do like your PASM-Source. WELL DONE!
So to better browse your source and understand it, I decided to 'rework' the way you are commenting your source according to the rules Phil posted in this Thread.
Fairly simple. I needed to repace/change some titles. Add some curly brackets and some dots. And DONE.
Then I took the spin fie and submitted it to Phils Spin Documenter. Saved the resuting file as Tachyon1v0-VGA_Doc.html. Impressive. Did the same with the rest of the spin files and added a README_Doc.html as a header. Here the complete Tachyon1v0-VGA-Autodoc.
Funny thing is - once you adapted the way of commenting you can at any time recreate a new HTML-file out of your Tachyon1v0-VGA.spin source. Just upoad it to Phil's Spin Code Documenter and save the resulting file as Tachyon1v0-VGA_Doc.html. That easy.
I did not wrote any of that documentation shown in the link. YOU DID. I just changed the way you are commenting a bit...
So PLEASE - open a beer - look at both sources - compare the comments - smile.
You can download from that web-page or take the attachment ... both are the same.
The whole shebang is just html - So it works on any webserver and even without webserver on your local harddrive. Just download the zip-file. (in windows7 right-click after saving, select properties and select 'unblock' if there)
Then unzip in folder of the same name as the zip - and voila there you go.
Start _README_Doc.html inside the folder.
BTW. I did not found VGA_512x384_Bitmap.spin in your zip. can you post it or give me a link ?
Ahh. And is there a HS-SerialTx.spin you can point me to also? I do like the simplicity of HS-SerialRx.spin
Enjoy!
Mike
I've updated the links at the bottom of the Introduction page if you are looking for the VGA object.
I also had a look at the formatted source code and while it's very neat and kudos to Phil there is one big drawback for me and that is it's not editable on-line. At present if I make a modification to a document then everybody else has access to the very latest without having to upload or anything. However I don't mind adding the formatting if it makes it easy to convert but besides doing all this fancy (but not complicated or aggressive) formatting on Google Docs I have been far too busy concentrating on developing Tachyon itself in-between real work etc. It's only been about a month since I first announced I was going to do it and now I have it so it's very solid that I can easily use it in real products and the speed it runs at is fantastic. I would have loved this stuff if someone else did it but now that I've done it, it seems to be a bit of a flop as I can almost hear the yawns of disinterest from the forum. Perhaps if I burnt out a Prop or came up with a transistor to use with the Prop I would have had more interest. Of course that doesn't stop me from doing what I'm doing but a little helpful "user" feedback might prove beneficial for all, after all it's not a small amount of work to do this plus publish it in this format.
The idea behind the autodoc facility is that you don't have to create and store a separate HTML file, but convert the source on demand every time you need to view it in doc form. To make things even easier, I've created a "DOC" button that resides on the Prop Tool's toolbar. When clicked with an autodoc-ready Spin file showing, the file is converted on the spot to an HTML document which opens in the user's default browser. If the Spin file that's showing is not autodoc-ready, the user is prompted to see if he wants the program to add an autodoc template, which he can then simply fill in with the needed information.
I haven't posted this version publicly yet, since I'm waiting for an official nod from Parallax. There's a good chance that the templating facility will be extended to include optional retabbing and case-conformance to the Gold Standard spec, although the latter is one feature that I probably wouldn't use myself.
-Phil
The thread is at http://forums.parallax.com/showthread.php?141653-Getting-More-From-Your-EEPROM-Slot
: CON 0 uemit W! ;
near the end of EXTEND.FTH
running kernel: Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120803.1845
Did not find the "uemit" word in any of the posted files.
_Really like the BACKUP and AUTORUN words.
And just for fun the how about this link: http://www.inventio.co.uk/forthvsc.htm I've got my flame suit on so go ahead. I really like the part about if you don't understand the problem you shouldn't be writing software.
yes I stumbled over transmit already, nice. And - yes - this is a huge amount of work you are doing there. But at least you have ONE guy interessted in this - ME.
The style of commenting differs not much from what you are doing and you can keep your source where it is. But like Phil said anybody can (re)create the html-doc out of your source easy.
@Phil - I takes Parallax 2 Years to NOD?
Enjoy!
Mike
I think the problem might be the version so just make sure you get the latest because I do update it constantly. Just look at the links at the bottom of the Introduction web page. Bear in mind that I try not to change things too much but if it needs to it needs to. Things are starting to settle down a bit more now though.
The problem with the article from the link you gave to "Forth vs C" is it is too busy defending and comparing. The target audience have already been assimilated and any further resistance is futile for they C the world via their library implants. There is only one way of doing it and that's the library way and you had better fit in with it.
Forth is Forth, not C, and a good Forth is so much better than a bad Forth and some although well written can be bad simply because they do not address the needs of the application and platform, they seem to have been written more like an assignment in a CS class or are PC centric. So I can definitely tell you that this Forth is tailored both for the Propeller and for the many applications that you and I typically use it for.
How about this: If I give you the keys to the car and grant you permission to edit the main document could you insert the extra formatting required without crunching the gears? Then you should be able to do a copy&paste or whatever into Guru Phil's confabulator.
I've thought about adding an image capability to the autodocumenter. Do you think it would clutter things too much to have a bunch of base64-encoded stuff in comments at the end of the source file to accommodate such a facility? I do want it to be completely self-contained, without referencing external files or urls.
BTW, if you don't want to be dragged into this discussion, just say so, and I'll understand.
-Phil
yes, I would love to do that. As you can see the differences are small and it will not disturb your progress.
Still need to wrap my head around FORTH. But reading your source helps a lot Since in FORTH everything seems backwards for me understanding the Language by understanding its implementation in PASM seems to be logical to me, somehow...
PM me how to do that, and I gladly accept your offer.
I am currently building up my own (Silver?) Standard Library of those objects I really need often.(Serial,I2C,SD,TV,VGA). Documenting them and, well add some generic I/O methods. This is preatty rewarding in it self. As you said "What Phil has done looks very professional".
Enjoy!
Mike
English is an example of an SVO language in that we have a subject, then the verb and then the object. However in other languages it is common to have the verb last such as in SOV languages. Isn't Forth more like an SOV language then in that you supply the information first (subject, object) then feed it into the verb. Take for example if I had a command in something like a standard CLI:
DUMP $1000,$400
Well you could see that DUMP is straining at the bit to find out what it's got to dump and that information can only be in the form that it is prepared for, it's syntax. However in the back-to-front (or is it front-to-back from a reverse perspective) you can do what you like before you tell it what to do:
0 REG $100 DUMP
Eminently far more sensible in my opinion and far more flexible even in this very simple example. Hang on, in many programming languages to get a delay you have to say something like delayms(100) which is not how we talk either yet many programmers have had it instilled into them to think that way. In Forth I just say 100 ms and that's it.
Now I've got the uemit word in: Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120804.0140 but now it seems BACKUP is not working nor is COLD sensing a hard restart as before?
I've been using a PROPBOE for testing.
I'm not sure what you mean by BACKUP is not working. Are you use the I2C.fth document from the link and are you able to EDUMP? If you ever want to reset to factory values and wipe out all your downloaded extensions then you have to do a COLD but this doesn't actually change the EEPROM so you then have to download I2C.fth and perform a new BACKUP. Perhaps I could build IC2.fth into the kernel but I am trying to do more with these Forth source extensions rather then "hard-coding" it into the kernel.
Okay just a little confused. I understand and have been using IIC.fth and others. Performing a RESET maintains my "user code" if I have done a BACKUP. Power off and on removes my "user code" and I get: Cold start - no user code - setting defaults. Got it. _My problem was trying to AUTORUN a word that used EMIT and I didn't get any output so I thought (mistake) it was the kernel. PEBKAC! Can / will we be able to disable "cold start" after power failure to enable AUTORUN the "system". NOCOLD
yes I am one of those programmers trained to think the other way. The whole concept of a DataStack still confuses me. So definition of PRTHEX for example. I think I do understand how it works and why. So far so good.PRTBYTE..WORD..LONG ok also. Then I hit DUMP.
OK. Now I need a piece of paper and a pen. Writing my own stack while jumping between definitions in code. This is a interesting concept of language, and certainly a very good match for the prop. But mindbending. Somehow it is like a functional language like "F" or so. But it isn't.
Having your PASM helps me out alot. There I feel home.
Anyways I did as you said in the PM and have write-acces to your document. Will start tomorrow... still browsing around in your doc. Having pictures is very nice.
Enjoy!
Mike