PropellerForth Help
rpraver
Posts: 19
I recently downloaded the PropellerForth from Parallax and can't seem
to get it to execute on my Hydra. I then tried to get access to the source
code and that can't be located either at Parallax or the developers home page.
Has anyone gotten it to execute on the Hydra and if so can I get a copy
of your? Also if anyone has the source I would appreciate that also.
Thanx
Post Edited (rpraver) : 7/22/2007 4:33:49 AM GMT
to get it to execute on my Hydra. I then tried to get access to the source
code and that can't be located either at Parallax or the developers home page.
Has anyone gotten it to execute on the Hydra and if so can I get a copy
of your? Also if anyone has the source I would appreciate that also.
Thanx
Post Edited (rpraver) : 7/22/2007 4:33:49 AM GMT
Comments
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
http://www.cliff.biffle.org/software/propeller/forth/sources.php
and follow the prompts
It looks like Cliffe's given-up on it; he says this in his tech blog "PropellerForth has stalled due to profound lack of interest from the Propeller community".
That's a real shame. I was following his thread with interest, but as he was having issues with his comm's implementation I was waiting for his next release.
COME BACK CLIFFE - PropellerForth IS being followed
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
I am now completeing a version for Briel Replica Apple that works.
If someone can convince Cliff to release the code I would be happy
to take a crack at completeing it.
BTW, I would be targeting the Hydra.
See that I am new to the Propeller, it would be a big help.
I also just about completed a tcc version to Briel Apple also.
Cliff did do a 'demo' Forth but it was not compiled using the Propeller IDE tool so therefore it could not benefit from being able to use contributed objects.
RP, trying to work from somebody else's custom tools and source can be a lot harder than starting from scratch so don't think getting source will make it easier. Writing a Forth for the Propeller is very different to writing a Forth for conventional processors so it does require some work.
Anyway, besides myself it seems like deSilva&Co are coming out with a Forth implementation too so no need to beat a dead horse when there are two live ones in the starting gate.
*Peter*
yet pertaining to forth on the Propeller and that only 2 maybes exist,
then possibly more might help creating a succesful release of atleast one
instead of multiple still borns.
Off hand just for the PC, Apple etc I beleive there were multiple flavours
out there, MVP, Fig, Miller, Atlast .... etc
BTW, in regards to the Apple Forth I've written "industrial strength" Forths for a variety of 6502ish architectures including the 65C816 and the Mitsubishi M37702 amongst many other architectures.
*Peter*
have been in the business since 1978, both hardware and software might be able
to cobble out a functional thingy that may work. It has been my experience that
if there is enough people interested and motivated that some things may come to
fruition .
I appreciate your experience concerning both interest and motivation and it is also your interest as well as others which is motivating me to put more time into the Forth that will, not may work.
*Peter*
an implementation so I could use that as jumping off platform. I want to try a small single cog
version first to play with the stack issues and base it on a minimal cross of Loeliger, MVP and Fig
ie. 79 standard. Then see where that may land me.
A nice puzzle. My fig forth source has 41 primitives of which a subset might fit into a cog. My thinking these days is to have the name fields separate from the code fields, a 16 bit implementation, and the TIB in hub memory. The io words KEY, EMIT, BLOCK, all are complicated by the variety of input/output devices or lack thereof -- making provisions for someone else's hardware (2x40 lcd here, what's your flavor?) will be problematic. The assembler looks simpler than making a 68000 version.
Deciding on how much the inner interpreter looks like another FORTH is a big choice. Yes, it could be made familiar but the propeller suggests almost from the first bit of work that it will be unlike any other. Self-modifying code! worries the hell out of me. And it might be inescapable.
Ah well. I reread some notes on FORTH tonight that I wrote 21 years ago. Who could imagine that a propeller would provoke such archaeology? What fun!
The cog memory is sufficient for the core words, a bit MISCish but not overly. However, other than pointers all buffers need to be in hub memory and even the stacks in my current model. 16bit implementation? That usually refers to the word size that is handled natively by the Forth VM and on 32-bit machines it will always be 32-bits at least. But I think you mean 16-bit indirect-threaded address model which is limited to 64K normally. My ARM Forth OS uses byte tokens very successfully and efficiently and I have seen no reason not to do so in Propeller Forth.
As to I/O there should be no problem as objects can be wrapped to accept in/out data from Forth and Forth I/O vectors are just that, vectors that can be changed. In Forth I could easily say:
BLOCK is a real throwback although I have something similar for virtual memory control but I try and keep that transparent.
I just had a forum member on the phone saying quote "who uses Forth?". Of course I had to laugh as us Forthers just "use the Forth" and I myself have it embedded in a plethora of products over the years. But once again if you prefer strict syntax and prefix rather than stack based postfix you will always compare Forth with your compiler when in fact there can be no such comparison. The Forth resides on the target whereas a language only exists in the development environment. Interestingly Spin generates byte tokens and runs a VM (Virtual Machine) from what I can see so at least at the runtime level it is more akin to Forth than normal compiled code.
I never really liked Forth on PCs as it really makes a lot more sense on embedded systems so I don't take part in all those boring discussions on language refinements etc. Forth gets my job done pronto and it's fun to work with otherwise I would go to sleep working with a "compile/syntax errors/keep the compiler happy/repeat/download/run and then figure out what just didn't happen" environment. The Propeller itself is fun and teamed up with Forth it's even more fun. Notice I keep using the word "fun" because I don't treat this as work and when it's fun it also stimulates the brain into coming up with better ways of doing things.
*Peter*
If people wonder "Who uses Forth?" then tell them that Forth programmers do. Simple as that.
"And, who migt that be?" is the possible next question. "Lots of people" I would say. People that write code for embedded systems. People that want an efficient environment instead of anxiously trying to keep syntax correct (which seems to be a main goal in academia) and people that like to have fun at work.
I would very much welcome a stable Forth for the Prop. It doesn't need to be a full Forth. But full enough to do bit banging, 16 bit arithmetic and some text/number I/O. That would go a long way. Any bonus material is welcome. And I think there are quite a few of us that are willing to pay enough to make it worth while.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cough..... In the spirit of the Propeller community CogForth (PropForth was taken I think) will be compilable by anyone and free. I benefit because I have a Forth to use with my now favorite chip and I also benefit from all the work from contributed objects and forum expertise. What beta testers can do is to help test and document all the little bits and pieces though and extend the kernel with application code when a beta is released. Gee, I really have to get a move on with this Forth, the pressure's on.
*Peter*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Throwback, eh? I'll sic my '79 dog on you! We are not old, merely been down the road a bit.
Seriously, thanks for the advice. (Relaxing about stuff that I don't know enough about). Is that MISCellaneous?
Fred
That's MISC, as in Minimal Instruction Set Computer. en.wikipedia.org/wiki/Minimal_instruction_set_computer
BLOCK was a great word when floppies were around as it was tied in with Forth screens which were simply 1K blocks of virtual memory running off the disk drive. With my SD memory I do something similar in that I treat the SD memory as flat virtual memory and build the file system on top of that again. So virtual memory is handled just like normal memory and uses similar words such as XC@ in place of C@ to fetch a byte and so on. The filesystem is normally setup as FAT16 not that this is a good thing, especially for SD cards but because it is readable by PCs. So if I was looking up a filename in the root directory it would use the virtual memory access words as in this simple example. Notice XADR which actually translates a virtual memory address into a hub memory address by reading in the sector if necessary and returning with the corresponding address.
With Forth you can define words and actions such as PLAY to accept a name and find and play that if it is a WAV audio file.
Having defined PLAY it can now be compiled into another definition or simply interpreted from the command line thus:
PLAY PACABEL
So words don't have to be letters and numbers as the word |> is the symbol for PLAY vs || as the symbol for PAUSE/STOP.
But enough of this for now as I need to get the kernel up and running.
*Peter*
$+2 ' current address + 2 bytes
in the assembler instruction set.
Any help?
*Peter*
IMO there are four reasons for needing that kind of expression:
(a) aligning to some address:
ORG ($+3)/4*4
This will rarely be needed within COG code, but is sometimes useful in SPIN (i.e. 64 byte alignment for video tiles)
In fact there is no org except ORG 0 (which indeed is needed for multi COGs code within one object!
(b) reducing the size of the load object
As the COG loader just copies 2k of the HUB RAM, there is no way of utilizing gaps inbetween; you can only avoid HUB space allocation AT THE END of the COG code (RES-directive)
(c) saving labels, i.e.
JMP $ ' endless loop
Never a good practice...
(d) checking address overflows
IF ($>$100) ABORT
The last application will need more features of a macroassembler to be useful
---
But maybe this it OT in this thread...
Post Edited (deSilva) : 7/25/2007 5:31:29 AM GMT
As can be seen I am trying to implement the inner interpreter and I am
new to the Propeler environment. I am having a real problem in finding
the equivilent op code to accomplish the above.
Any info?
Post Edited (rpraver) : 7/25/2007 5:43:42 AM GMT
here long #here+2
*Peter*