What excellent work you have done on your PropBasic Compiler project. I hope that this will enable a few of the people that currently use the SX range and Basic Stamp to move over to the Propeller Micro and feel more at ease until they jump in to Spin & Pasm. Is a good learning tool already being able to see generated code. The next object that I would love to see is any VGA driver, as being English find the video output (PAL) from the Propeller to be - well awfull and in my personal opinion holds this device back from some actual commercial applications.
I certainly do not under estimate the hard work you and also Jonny Mac (with the documentation) have done to get this up and running so quickly. Believe 2010 will see this project as another language option for the Propeller, and this has to be very good indeed for everyone.
Thanks for doing that -- I've been using EditPlus for all my PropBASIC stuff but hadn't taken the time to create a syntax file; you just saved me a bit of time.
Note the quotes around the arguement -- this is required if the path contains spaces.
2) Download to RAM
-- command: C:\Documents and Settings\Administrator\My Documents\Programming\Propeller\Propellent.exe
-- arguement: "$(FileDir)\$(FileNameNoExt).spin"
3) Download to EEPROM
-- command: C:\Documents and Settings\Administrator\My Documents\Programming\Propeller\Propellent.exe
-- arguement: /EEPROM "$(FileDir)\$(FileNameNoExt).spin"
mcstar said...
Since others are using editplus as well, I thought I'd post my syntax file for PropBasic. Just create a new file type under Tools->Preferences-> files and syta and point it at the syntax file attached. Set the file extension to pbas.
Since Editplus has the ability to run external programs, you can even set it to to build the pbas file using the Propbasic.exe and deploy the resultant file to a connected propeller using Propellent.exe!
To set it up, make sure the user toolbar is showing (View-> Toolbars -> User Toolbars) and add two new custom buttons to the tool bar. Point the first one at the propbasic.exe with this argument. "$(FilePath)"
Point the second button to the Propellent.exe with this argument $(FileDir)\$(FileNameNoExt).spin
Now build and compile is just two clicks and integrated into an ide with syntax highlighting!
I've been sitting on the sidelines watching your PropBASIC efforts. I know what the two of you can achieve as a team from watching the SX/B progression over recent years. JonnyMac is most excellent with documentation, coding and projects; Bean is an experienced compiler developer who sticks with the project and manages the many requests he shall receive (often from JonnyMac himself) without discounting them as too difficult or not necessary. This project needs the two of you and shows what happens when two guys with unique skills put their efforts into one project. The fact that you're doing this for the Propeller is really humbling for Parallax and Propeller users everywhere, causing me to hang quietly in the background until I actually give PropBASIC a try.
We couldn't be more lucky and appreciative to have the two of you as part of the team! The early documentation looks very good and is certainly part of the key to PropBASIC long-term success.
mcstart: nice work.
Bean & JonnyMac: Fantastic - I can see a great future for this in 2010
Bean, you asked about starting a spin cog from pasm. It is fairly simple. Sorry, I don't have the time to check just at the moment. You can look at the Spin Interpreter code. You require 2 parameters. The start address which is in hub ROM for the interpreter (cannot recall the address) and the address of the spin code. If Hippy has the time he could help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Errata notice :
While trying to get the video demos to work with a TV out, I had a bit of trouble. It didn't take too long to find cause, but here is the fix in case others are hitting the same snag. BTW, working through this did help me learn a few things about the video processor in the propeller that I didn't know, so if you want to solve the challenge yourself, please stop reading now
First off, let me say, I'm blown away by how little code is needed to get the video driver to work! Before compiling in PBasic, MoneVid is only ~50 lines of code. After compiling MonoVid.spin is only 167 lines of Assembly code and that's with lots of extra space and comments. Wow! Just think, that's the entire video driver.
For my setup I'm using a PRC board with the PRC TVIO card from wulfden.org which has the TV output on pins 20-23. The same problem will occur with the demo board if using TV output, but you shouldn't have to change the pins, only the VideoMode.
Originally, I tried just setting my TV output pins using the Basic variables defined near the top of the page like this.
SyncPin PIN 20 OUTPUT ' Sync signal on pin 12 (Demo board)
VideoPin PIN 22 OUTPUT ' Video (black / white) signal on pin 14 (Demo board)
But this result in no output at all. An Oscope confirmed that although I was a getting a pulse on pin 20, there was definitely no video. So, I dove deeper into the video driver (monovid). This led me to line 161, the video config. Here's what it was set to.
A couple things here, first the pin group and pin mask are hard coded, thus changing the sync and video pin were not having any affect on the output for the video PLL. Also, the 01 indicates the video processor would be generating VGA not composite. Here's my corrected VCFG setting for showing composite video on the PRC TVIO board...
I played with your syntax file, adjusting it to my nutty liking (different name so you can try it without losing the other). I've also attached a screen shot of my color selections and my template file.
[noparse][[/noparse]Update] 12-31-2009 : Found INC and THEN missing from propbasic.stx -- update attached.
Post Edited (JonnyMac) : 12/31/2009 7:48:47 PM GMT
Bean, you asked about starting a spin cog from pasm. It is fairly simple. Sorry, I don't have the time to check just at the moment. You can look at the Spin Interpreter code. You require 2 parameters. The start address which is in hub ROM for the interpreter (cannot recall the address) and the address of the spin code. If Hippy has the time he could help.
How about it? Do I need to motivate my lumbering carcass to take up the sub-project?
Because of the cog startup time, I think the best way to handle spin code would be to leave the spin interpreter running and use it was a dispatcher with hub variables.
Basically the spin code would wait for a "spinID" variable to get set to a value that indicates what spin routine you want to call.
The spin code would run that routine and return any values in some kind of "spinData" variables.
I'll try to mock up something in the next couple days to demonstrate what I mean.
I check this forum several times daily with the hope of seeing exactly a reponse such as yours!
I've been researching all the variations of 'calling Spin from PASM' within the Forum to run with Cluso's advice; and am convinced that even to _understand_ the problem takes further thought.
This sounds promising. Phil Pilgrim has posted code previously on calling Spin from PASM - using a 'dispatch' methodology and example; but it is beyond my comprehension unfortunately.
I hadn't considered startup time for this process. So, obviously, a monitor process already running would neatly solve several problems.
Now, to consider the nature of that dispatcher task: Spin or Pasm or PropBasic?
PropBasic would work for educational purposes and can be optionally included as the first thing to be processed in all 7 possible tasks.
I will need to reread the documents and do some testing before going too far along this path.
Optimization can come later. Time to do some 'spermentin'...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Post Edited (Mike Huselton) : 12/28/2009 11:35:19 PM GMT
Here is a demo program showing how to interface spin objects into PropBASIC using a spin dispatcher.
If you try this demo, make sure it's NOT in the same directory as the keyboard demo PropBASIC code. The PropBASIC keyboard demo creates a "keyboard.spin" file that is NOT the one we want to this demo.
You can see that I used an ASM...ENDASM block to insert the object and dispatcher code. Even though it's not PASM code, the ASM...ENDASM commands don't care they just put whatever is between them into the output file.
' Put in code to run spin dispatcher
ASM
OBJ
Key: "Keyboard"
PUB SpinStart
CogInit(1, @__Init, @__DATASTART) ' Start PropBASIC program
Repeat
case spinCmd
spinKeyStart:
Key.Start(spinP1, spinP2)
spinCmd := 0
spinKeyGetKey:
spinP1 := Key.GetKey
spinCmd := 0
ENDASM
If you have any questions about how this works, please let me know.
Hi all,
Just to report SUCCESS using Bean's method to call a Spin object from PropBASIC!
I spent an hour trying to use the example given, before giving up and writing some _really_ simple code.
The joy finally on hearing a 400Hz tone generated by Spin called from the Obex by PropBASIC!
Many thanks,
Here's the code that I used. It may be crude, but it works!
Regards, T o n y
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
ASM
OBJ
soundmachine: "Profbrd_tonegen" 'this is one of Rayman's sound drivers, renamed "Profbrd_tonegen" in my files
PUB SpinStart
CogInit(1, @__Init, @__DATASTART)
soundmachine.tonegen(400,500,3) 'sends frequency/duration/attenuation to the tonegen subroutine
ENDASM
PROGRAM Start
Start:
END
Being new to the propeller, I'm hoping you guys with much greater knowledge can help.
I can't get "GOSUB" to work, but I can't find anything about declared SUB / FUNC which the documentation says replaces it.
If I use goto to get to the subroutine, and another goto (instead of return) at the end of the subroutine with a label at the place it should have "returned to" it works.
The error is "Undefined ?_RET symbol".
The other issue I can't seem to work around is "Origin Exceeds" errors.
If some one could explain what they mean, it might get me on the right track.
I keep getting the Origin Exceeds errors·once I have reached a fairly small number of code lines (about 200). If I rem (comment)·some out, I can use others, so it seems to be based on the amount of code, not some particular code.
Interestingly, the errors show up onscreen a minute or two after compiling (which shows no errors) and attempting to download to RAM, which just sort of·flashes for a second·the "downloading window", but doesn't download anything.
The Origin exceeds fit limit means that you have too much code. The PASM code that PropBASIC generates must fit within the COG. So only 496 instructions are allowed.
Some PropBASIC commands generate alot of PASM code so you need to put them into a subroutine.
If you look at the template.pbas you will see that near the top of the program you declare the subroutines along with how many parameters they need.
Plot SUB 2
Means you will have a subroutine named "Plot" that takes 2 parameters.
Near the bottom of the template you will see where you put the actual subroutine code.
SUB Plot
' Parameters are in __PARAM1 and __PARAM2
ENDSUB
If you could post your code we could help you much more.
Another more complecated thing to do is to break the program into multiple TASKs. Each TASK runs in it's own COG, so each TASK can have 496 PASM instructions.
@Geekgirl: If you post your .pbas source Bean and/or I can fix it up for you -- that should help get you going as we continue to work on the docs.
One of the code space killers we frequently run into is PAUSE -- it's used a lot and generates several lines of code; one way to save space in your program is to create a subroutine that serves as shell for PAUSE. Start by defining the subroutine -- here's how I do it:
DELAY_MS SUB 1, 1 ' shell for PAUSE
Now you have to write the code for the definition; this one is easy:
' Use: DELAY_MS duration
' -- shell for PAUSE
SUB DELAY_MS
PAUSE __param1
ENDSUB
As you learn about PropBASIC you'll find that parameters are passed in the __paramX (1 - 5) variables. With 32-bit numbers we only need one value, and this can be dropped right into PAUSE as I've done in the DELAY_MS subroutine.
In your program you'll now substitute DELAY_MS for PAUSE (except in the body of the subroutine -- we need that one for the compiler). I had a look and PAUSE generates six lines of code. Using DELAY_MS uses only two lines -- that's a nice savings every time we need a delay, which can be frequent in many programs.
Of course, this is a very simple example but is shows the code-savings power of SUBs and FUNCs. I've attached a little working demo that uses DELAY_MS so you can see exactly how it works.
Post Edited (JonnyMac) : 12/31/2009 6:15:10 PM GMT
Bean (Hitt Consulting) said...
The Origin exceeds fit limit means that you have too much code. The PASM code that PropBASIC generates must fit within the COG. So only 496 instructions are allowed.
Some PropBASIC commands generate alot of PASM code so you need to put them into a subroutine.
If you look at the template.pbas you will see that near the top of the program you declare the subroutines along with how many parameters they need.
Plot SUB 2
Means you will have a subroutine named "Plot" that takes 2 parameters.
Near the bottom of the template you will see where you put the actual subroutine code.
SUB Plot
' Parameters are in __PARAM1 and __PARAM2
ENDSUB
If you could post your code we could help you much more.
Another more complecated thing to do is to break the program into multiple TASKs. Each TASK runs in it's own COG, so each TASK can have 496 PASM instructions.
Bean.
I am working from the template, and saw the place to declare subs, but have no idea how it's done or what a parameter is or how you know how many the sub would have.
I put the sub code in the lower area specified for that.
Here's the program code that works. Apparently that's all the instructions cog0 can hold.
As I expected, lots of PAUSE usage (see my post above). Another way to save code is to declare pins as outputs and then write a value (0 for off, 1 for on) to the pin. I'll touch up you code and repost.
As I expected, lots of PAUSE usage (see my post above). Another way to save code is to declare pins as outputs and then write a value (0 for off, 1 for on) to the pin. I'll touch up you code and repost.
I changed all the PAUSEs to DELAY_MS, and set some times (T1, T2 ... ) as constants to use with it, and it works OK. It saved enough space that I didn't have to comment out anything.
I see what you mean about the pins thing, it's not as easy to visualize that yet as it is to think in·the way I've been doing it with the stamp, which is what the first code I posted based from.
Sometimes this stuff makes me feel like such a moron for a a while, and then the light bulb starts to flicker.
Darlene-
DONT fell stupid or foolish! PropBasic is almost exactly like SX/B, and I've been studying JonnyMac's and others code for a YEAR now and still learn new things everyday! Take your time, keep your mind open and play! It'll get easier!
Bean (Hitt Consulting) said...
Here is one way to make it smaller.
I make the LEDs pin groups, this makes it easier to assign colors to them.
I didn't convert all of your code, but you should be able to get the idea.
Bean. ·
P.S. I screwed up the color names. I have posted the correct version.
WOW, Thanks....·
It took me a while to see how the colors worked, but then I saw how you broke the pins into groups of three and the color constants when seen as 3bit·binary, my light bulb is starting to flicker.
Here's a version of Terry's program that lets you store the lighting sequences in a DATA table (does not use program space as tables are stored in the Hub) -- this will let you define sequences using Terry's color scheme, which is FAR EASIER than the high-low mash-up strategy you started with. You simply call the PLAY subroutine with the sequence you want to use and the step timing.
JonnyMac said...
Here's a version of Terry's program that lets you store the lighting sequences in a DATA table (does not use program space as tables are stored in the Hub) -- this will let you define sequences using Terry's color scheme, which is FAR EASIER than the high-low mash-up strategy you started with. You simply call the PLAY subroutine with the sequence you want to use and the step timing.
Thanks again!
This is wayyyy cool, at least to me.
I'm still working to understand exactly·how it all does what it does on this version, this is a lot of new ground for me, but it's coming.
Comments
What excellent work you have done on your PropBasic Compiler project. I hope that this will enable a few of the people that currently use the SX range and Basic Stamp to move over to the Propeller Micro and feel more at ease until they jump in to Spin & Pasm. Is a good learning tool already being able to see generated code. The next object that I would love to see is any VGA driver, as being English find the video output (PAL) from the Propeller to be - well awfull and in my personal opinion holds this device back from some actual commercial applications.
I certainly do not under estimate the hard work you and also Jonny Mac (with the documentation) have done to get this up and running so quickly. Believe 2010 will see this project as another language option for the Propeller, and this has to be very good indeed for everyone.
With regards
Mike.
I setup three tools:
1) Compile PropBASIC
-- command: C:\Documents and Settings\Administrator\My Documents\Programming\Propeller\PropBASIC\PropBasic.exe
-- arguement: "$(FilePath)"
Note the quotes around the arguement -- this is required if the path contains spaces.
2) Download to RAM
-- command: C:\Documents and Settings\Administrator\My Documents\Programming\Propeller\Propellent.exe
-- arguement: "$(FileDir)\$(FileNameNoExt).spin"
3) Download to EEPROM
-- command: C:\Documents and Settings\Administrator\My Documents\Programming\Propeller\Propellent.exe
-- arguement: /EEPROM "$(FileDir)\$(FileNameNoExt).spin"
I've been sitting on the sidelines watching your PropBASIC efforts. I know what the two of you can achieve as a team from watching the SX/B progression over recent years. JonnyMac is most excellent with documentation, coding and projects; Bean is an experienced compiler developer who sticks with the project and manages the many requests he shall receive (often from JonnyMac himself) without discounting them as too difficult or not necessary. This project needs the two of you and shows what happens when two guys with unique skills put their efforts into one project. The fact that you're doing this for the Propeller is really humbling for Parallax and Propeller users everywhere, causing me to hang quietly in the background until I actually give PropBASIC a try.
We couldn't be more lucky and appreciative to have the two of you as part of the team! The early documentation looks very good and is certainly part of the key to PropBASIC long-term success.
Sincerely,
Ken Gracey
Parallax Inc.
Bean & JonnyMac: Fantastic - I can see a great future for this in 2010
Bean, you asked about starting a spin cog from pasm. It is fairly simple. Sorry, I don't have the time to check just at the moment. You can look at the Spin Interpreter code. You require 2 parameters. The start address which is in hub ROM for the interpreter (cannot recall the address) and the address of the spin code. If Hippy has the time he could help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
While trying to get the video demos to work with a TV out, I had a bit of trouble. It didn't take too long to find cause, but here is the fix in case others are hitting the same snag. BTW, working through this did help me learn a few things about the video processor in the propeller that I didn't know, so if you want to solve the challenge yourself, please stop reading now
First off, let me say, I'm blown away by how little code is needed to get the video driver to work! Before compiling in PBasic, MoneVid is only ~50 lines of code. After compiling MonoVid.spin is only 167 lines of Assembly code and that's with lots of extra space and comments. Wow! Just think, that's the entire video driver.
For my setup I'm using a PRC board with the PRC TVIO card from wulfden.org which has the TV output on pins 20-23. The same problem will occur with the demo board if using TV output, but you shouldn't have to change the pins, only the VideoMode.
Originally, I tried just setting my TV output pins using the Basic variables defined near the top of the page like this.
SyncPin PIN 20 OUTPUT ' Sync signal on pin 12 (Demo board)
VideoPin PIN 22 OUTPUT ' Video (black / white) signal on pin 14 (Demo board)
But this result in no output at all. An Oscope confirmed that although I was a getting a pulse on pin 20, there was definitely no video. So, I dove deeper into the video driver (monovid). This led me to line 161, the video config. Here's what it was set to.
VCFG = %0_01_0_0_0_000_00000000000_001_0_0100_0000
A couple things here, first the pin group and pin mask are hard coded, thus changing the sync and video pin were not having any affect on the output for the video PLL. Also, the 01 indicates the video processor would be generating VGA not composite. Here's my corrected VCFG setting for showing composite video on the PRC TVIO board...
VCFG = %0_10_0_0_0_000_00000000000_010_0_1111_0000 'PRICO
And Ca-Ching~! I'm reward with a zillion little dots flying around on the screen.
I just added that to my toolbar as well. Very Nice.
[noparse][[/noparse]Update] 12-31-2009 : Found INC and THEN missing from propbasic.stx -- update attached.
Post Edited (JonnyMac) : 12/31/2009 7:48:47 PM GMT
I've always used the non-standard VGA setting.
I'm not sure why it wouldn't work, but if you got it working that's great.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PropBASIC home page www.propbasic.com
·
How about it? Do I need to motivate my lumbering carcass to take up the sub-project?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Basically the spin code would wait for a "spinID" variable to get set to a value that indicates what spin routine you want to call.
The spin code would run that routine and return any values in some kind of "spinData" variables.
I'll try to mock up something in the next couple days to demonstrate what I mean.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PropBASIC home page www.propbasic.com
·
Hi Mike,
I check this forum several times daily with the hope of seeing exactly a reponse such as yours!
I've been researching all the variations of 'calling Spin from PASM' within the Forum to run with Cluso's advice; and am convinced that even to _understand_ the problem takes further thought.
Regards and encouragement,
T o n y
This sounds promising. Phil Pilgrim has posted code previously on calling Spin from PASM - using a 'dispatch' methodology and example; but it is beyond my comprehension unfortunately.
Regards,
T o n y
Post Edited (skynugget) : 12/29/2009 10:06:34 PM GMT
I hadn't considered startup time for this process. So, obviously, a monitor process already running would neatly solve several problems.
Now, to consider the nature of that dispatcher task: Spin or Pasm or PropBasic?
PropBasic would work for educational purposes and can be optionally included as the first thing to be processed in all 7 possible tasks.
I will need to reread the documents and do some testing before going too far along this path.
Optimization can come later. Time to do some 'spermentin'...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Post Edited (Mike Huselton) : 12/28/2009 11:35:19 PM GMT
Mike, The dispatcher will almost certainly have to be written in spin.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PropBASIC home page www.propbasic.com
·
If you try this demo, make sure it's NOT in the same directory as the keyboard demo PropBASIC code. The PropBASIC keyboard demo creates a "keyboard.spin" file that is NOT the one we want to this demo.
You can see that I used an ASM...ENDASM block to insert the object and dispatcher code. Even though it's not PASM code, the ASM...ENDASM commands don't care they just put whatever is between them into the output file.
' Put in code to run spin dispatcher ASM OBJ Key: "Keyboard" PUB SpinStart CogInit(1, @__Init, @__DATASTART) ' Start PropBASIC program Repeat case spinCmd spinKeyStart: Key.Start(spinP1, spinP2) spinCmd := 0 spinKeyGetKey: spinP1 := Key.GetKey spinCmd := 0 ENDASMIf you have any questions about how this works, please let me know.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PropBASIC home page www.propbasic.com
Post Edited (Bean (Hitt Consulting)) : 12/30/2009 6:41:25 PM GMT
Just to report SUCCESS using Bean's method to call a Spin object from PropBASIC!
I spent an hour trying to use the example given, before giving up and writing some _really_ simple code.
The joy finally on hearing a 400Hz tone generated by Spin called from the Obex by PropBASIC!
Many thanks,
T o n y
Regards, T o n y
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
ASM
OBJ
soundmachine: "Profbrd_tonegen" 'this is one of Rayman's sound drivers, renamed "Profbrd_tonegen" in my files
PUB SpinStart
CogInit(1, @__Init, @__DATASTART)
soundmachine.tonegen(400,500,3) 'sends frequency/duration/attenuation to the tonegen subroutine
ENDASM
PROGRAM Start
Start:
END
I can't get "GOSUB" to work, but I can't find anything about declared SUB / FUNC which the documentation says replaces it.
If I use goto to get to the subroutine, and another goto (instead of return) at the end of the subroutine with a label at the place it should have "returned to" it works.
The error is "Undefined ?_RET symbol".
The other issue I can't seem to work around is "Origin Exceeds" errors.
If some one could explain what they mean, it might get me on the right track.
I keep getting the Origin Exceeds errors·once I have reached a fairly small number of code lines (about 200). If I rem (comment)·some out, I can use others, so it seems to be based on the amount of code, not some particular code.
Interestingly, the errors show up onscreen a minute or two after compiling (which shows no errors) and attempting to download to RAM, which just sort of·flashes for a second·the "downloading window", but doesn't download anything.
Some PropBASIC commands generate alot of PASM code so you need to put them into a subroutine.
If you look at the template.pbas you will see that near the top of the program you declare the subroutines along with how many parameters they need.
Means you will have a subroutine named "Plot" that takes 2 parameters.
Near the bottom of the template you will see where you put the actual subroutine code.
If you could post your code we could help you much more.
Another more complecated thing to do is to break the program into multiple TASKs. Each TASK runs in it's own COG, so each TASK can have 496 PASM instructions.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Try BASIC on the Propeller.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
Post Edited (Bean (Hitt Consulting)) : 12/31/2009 5:17:57 PM GMT
One of the code space killers we frequently run into is PAUSE -- it's used a lot and generates several lines of code; one way to save space in your program is to create a subroutine that serves as shell for PAUSE. Start by defining the subroutine -- here's how I do it:
Now you have to write the code for the definition; this one is easy:
As you learn about PropBASIC you'll find that parameters are passed in the __paramX (1 - 5) variables. With 32-bit numbers we only need one value, and this can be dropped right into PAUSE as I've done in the DELAY_MS subroutine.
In your program you'll now substitute DELAY_MS for PAUSE (except in the body of the subroutine -- we need that one for the compiler). I had a look and PAUSE generates six lines of code. Using DELAY_MS uses only two lines -- that's a nice savings every time we need a delay, which can be frequent in many programs.
Of course, this is a very simple example but is shows the code-savings power of SUBs and FUNCs. I've attached a little working demo that uses DELAY_MS so you can see exactly how it works.
Post Edited (JonnyMac) : 12/31/2009 6:15:10 PM GMT
I put the sub code in the lower area specified for that.
Here's the program code that works. Apparently that's all the instructions cog0 can hold.
Thanks in advance,
Darlene
As I expected, lots of PAUSE usage (see my post above). Another way to save code is to declare pins as outputs and then write a value (0 for off, 1 for on) to the pin. I'll touch up you code and repost.
I make the LEDs pin groups, this makes it easier to assign colors to them.
I didn't convert all of your code, but you should be able to get the idea.
Bean.
P.S. I screwed up the color names. I have posted the correct version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Try BASIC on the Propeller.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
Post Edited (Bean (Hitt Consulting)) : 12/31/2009 7:03:57 PM GMT
I see what you mean about the pins thing, it's not as easy to visualize that yet as it is to think in·the way I've been doing it with the stamp, which is what the first code I posted based from.
Sometimes this stuff makes me feel like such a moron for a a while, and then the light bulb starts to flicker.
Thanks for all the help.
Darlene·
DONT fell stupid or foolish! PropBasic is almost exactly like SX/B, and I've been studying JonnyMac's and others code for a YEAR now and still learn new things everyday! Take your time, keep your mind open and play! It'll get easier!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Shawn Lowe
When all else fails.....procrastinate!
It took me a while to see how the colors worked, but then I saw how you broke the pins into groups of three and the color constants when seen as 3bit·binary, my light bulb is starting to flicker.
Darlene
Thanks again!
This is wayyyy cool, at least to me.
I'm still working to understand exactly·how it all does what it does on this version, this is a lot of new ground for me, but it's coming.
Darlene