I have been experimenting with PropBasic a little more. This really speeds me up! I can write the code more quickly and it will execute really fast. No assembler needed. I am astonished, how much code fits into the cog ram.
One suggestion: If you store a variable to a byte or word hub variable and read it again, then the sign causes trouble. What do you think of a parameter like that:
rdword buffer, variable[noparse][[/noparse], signed]······ 'to extend the sign to 32 bits
I have posted version 00.00.72 of the PropBASIC compiler.
The MAJOR change is in the way pin groups are handled.
In previous versions you had to declare pin groups as "name PIN LSBpin..MSBpin" with LSBpin always having to be a lower value than MSBpin. This was not consistent with the way spin uses groups of pins. So PropBASIC was changed.
Pin groups are now declared as "name PIN MSBpin..LSBpin" and compiler will reverse the bits if MSBpin is lower than LSBpin. This works very much like spin, so users of both languages won't get confused.
@Christof: It would probably require new commands like: WRSWORD, RDSWORD, WRSBYTE, RDSBYTE. I'll put it in the "think about it" pile.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
' Define variables (LONGs only)
temp···· VAR LONG
ascii··· VAR LONG(13) ' Conversion to ASCII
i······· VAR long
' Define Subroutines
SerNumber SUB 1
'###############################################################################################
' Start of main code
PROGRAM Start
Start: · pause 2000 · for i = 0 to 100 step 10 ··· SerNumber i · next i
end
SUB SerNumber ··· STR ascii, __param1, 10,3 ··· ascii(10) = 13 ··· FOR temp = 0 TO 10 ····· SEROUT TX, Baud, ascii(temp) ··· NEXT
ENDSUB
Christof,
Yeah 32-bit values can only handle 10 digit values up to 4_294_967_296. That's why if chokes if the leading digit is > 4.
There is no problem if you use 9 digits.
I'll have to see if I can implement a 33-bit value somehow.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
the sign eats one of the 9 digits in mode 3... Perhaps there are possibilities without having 33 bits?
Do not misunderstand me, please. I started a project right away with your compiler and your IDE this week. Working with·them is real fun! I have 4 Tasks running well, the code is about 10 screens long and gives about 800longs of cog code. So I am very happy with this betabeta Version!
Christof,
I have posted version 00.00.73 with fixes for the problems you have found.
If you use mode 2 or 3 (signed) the first character is either "-" or " " (it cannot be a digit as before). So mode 2 or 3 allows 11 places to be used.
Basically if you specify mode 0 or 1(default) with 10 places or mode 2 or 3 with 11 places, the highest digit is handled before the main loop. The generates more code, but at least the result is correct.
I do not take offence...In fact I'm very glad that you are finding these bugs for me. I wish more members would be a though as you.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
Hi Jon and Bean, congrats on a superb compiler! As a user of picbasic, I supposed we are spoilt to some extent with having some LCD character display commands. Do you envisage including the equivalent or similar in propbasic or should we just rely on LCD macros being posted by other users?
@Spreader: I, for one, am of the opinion that LCDs and things should not be built into the compiler. We try to focus on timing sensitive things -- LCDs really are not that sensitive at all. Do you need LCD code right away? I've got a couple other things on my plate, but I might be able to port my Spin code over in the next day or so.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
Hi Jon, I don't need anything right now, but will be experimenting with some 20x4's and possibly the odd GLCD (driver not known at present) in the near future. I get the gist of what you are saying re timing, but as I said, I find that being able to use a few basic commands to get a display up and running quickly quite useful. Thanks for the kind offer.
Just for fun I fired up PropBasic on the Dracblade. I'll document the steps since it was so easy.
1) Download propbasic from the first page of this thread into a new folder
2) Run PropBasicIDE
3) Open the file Keyboard t PC.BAS
4) Minor tweak to the code - dropped the baud rate to 19200 as my terminal program is set up for that rate
5) Compile it
6) Run a terminal program (lots of choices - they all work)
7) Type characters on the keyboard and they come up on the screen.
This is fun!!!
Of course, I immediately want to do more. I had a quick look in the demos - is there a VGA driver?
If not, given there is lots of generic code around, is this hard to add?
I'm now trying to get my head around what propbasic is doing. The keyboard driver seems to be a complete rewrite in Propbasic (which is
very impressive, as it comes to a tiny amount of code. Less even that a Z80 assembly keyboard driver I have.) So rather than drop in pre-written
spin/pasm modules, are each of these functions being rewritten for propbasic? If so, given the small code listings, and the direct to assembly translation and the extremely rapid compilation, I can see the attraction there.
Thinking aloud, is there a way to automate the translation? Or is it just a tedious matter of going through each line?
I'm thinking of other useful building blocks - eg VGA, but especially the SD card code. Both of those would be beyond me to write, but I think I could contribute code for the 20x4 LCD display.
G'day guys. I don't want to hijack Bean's thread, but I figure this is probably the best place to post this.
I'm not much of a BASIC programmer (in fact I've not used it since about 1983), but I want to set up some automated testing of the PropBasic compiler.
With spin, it's easy. I just downloaded the entire obex and built a test suite around that. I now test against ~1800 spin files.
Is anyone interested in E-mailing me zip files of their PropBasic source code that I could use in a private test suite? I could really use some programs that create multiple files, use tasks, use include files and anything else that hits the disk. Having said that, even simple examples will help greatly. No code will be examined, judged, commented on or released outside of my home network, but I could _really_ use some help here from those that are actually using PropBasic on a regular basis. <pretty please with a cherry on top>.
If you could e-mail code to proptools <at> fnarfbargle.com, I'd _really_ appreciate it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Can you release the info on how to compile a .pbas program from am command line? I have looked through this thread and in the docs included with the latest v .75 and can't seem to find any info. I tried to use the Notepad++ editor (Which I like), but was not successful.
I used PropBASIC for the first larger program and was able to write a driver for an MCP23S17 I/O Expander chip pretty quickly. I used the SHIFTOUT command and then tweaked the PASM to remove the WAITCNT, because the MCP23S17 only needs 45ns between CLKs. I then reinserted the modified PASM back into the PropBASIC code using the ASM...ENDASM statements and this works so slick.
I can really see how useful this is to people that are not 100% proficient in PASM. It a great learning tool!!!!
Jim,
You call PropBASIC.exe with the first parameter as the FULL path to the .pbas file (in quotes). If you add a /p switch, the compiler will pause at errors.
Bean (Hitt Consulting) said...
Okay, well here is my translation.
DEVICE P8X32A, XTAL1, PLL16X ' {$STAMP BS2} ' {$PBASIC 2.5}
FREQ 80_000_000
Blank CON %00000000 ' all segments off
Baud CON "T115200" ' Baud rate to PC
Segs PIN 0..7 OUTPUT ' Segs VAR OUTL ' Segments on P0 - P7
' SegsDirs VAR DIRL ' DIRS for segments
Digs PIN 8..11 OUTPUT ' Digs VAR OUTC ' Digit control pins
TX PIN 30 HIGH ' Serial pin to PC
vss VAR LONG ' vss VAR Word
mph VAR LONG ' Mph VAR Word
theDig VAR LONG ' theDig VAR Nib ' current display digit
wait VAR LONG ' Used to accumulated count for 1 second
ascii VAR LONG(12) ' Used to hold string to send to PC
temp VAR LONG ' Temporary variable
digits HUB BYTE(4) = "0" ' Digits to show on multiplex display
' .GFEDCBA
Digit0 DATA %00111111 ' digit patterns
Digit1 DATA %00000110
Digit2 DATA %01011011
Digit3 DATA %01001111
Digit4 DATA %01100110
Digit5 DATA %01101101
Digit6 DATA %01111101
Digit7 DATA %00000111
Digit8 DATA %01111111
Digit9 DATA %01100111
DigSel DATA %1110 ' digit 0 active
DATA %1101 ' digit 1 active
DATA %1011 ' digit 2 active
DATA %0111 ' digit 2 active
Multiplex TASK
PROGRAM Start
Start:
Digs = %1111 ' all off
' DIRS = $0FFF ' make segs & digs outputs
COUNTERA 80, 15, 0, 1, 0 ' Setup counter to accumulate count from pin P15
ascii(0) = " "
ascii(1) = "M"
ascii(2) = "P"
ascii(3) = "H"
ascii(4) = " "
ascii(5) = "="
ascii(6) = " "
ascii(11) = 13 ' Carrage return
COGSTART Multiplex ' Start task that handles the multiplexed display
wait = cnt + _Freq
DO
WAITCNT wait, _Freq ' COUNT 15, 1000, vss 'Get vehical speed signal
vss = phsa ' Get accumulated count from counter
phsa = 0 ' Zero accumulated count
vss=67 ' ***** temporary line
mph = vss * 9 'Turn vss signal into speed reading
' DEBUG HOME, " MPH = ", DEC Mph DIG 3,DEC Mph DIG 2, DEC Mph DIG 1, DEC Mph DIG 0,CR 'temporary line Mph to pc terminal
STR ascii(7), mph, 4 ' Convert mph to ascii characters
WRBYTE Digits(0), ascii(7) ' Update digits to show on multiplex display
WRBYTE Digits(1), ascii(8)
WRBYTE Digits(2), ascii(9)
WRBYTE Digits(3), ascii(10)
FOR temp = 0 TO 11 ' Send string to PC
IF temp = 10 THEN
SEROUT TX, Baud, "."
ENDIF
SEROUT TX, Baud, ascii(temp)
NEXT
LOOP
END
TASK Multiplex
theDig VAR LONG = 0
temp VAR LONG
DO
Segs = Blank ' clear display
RDBYTE DigSel(theDig), temp ' READ (DigSel + theDig), Digs ' select digit
Digs = temp
RDBYTE Digits(theDig), temp
temp = temp - "0"
RDBYTE Digit0(temp), temp
Segs = temp
INC theDig ' theDig = theDig + 1 // 4 ' update digit pointer
theDig = theDig AND 3
PAUSE 5 ' Time to display digit
LOOP
ENDTASK
Note that you DON'T need a seperate task to do the COUNT. The hardware counters will handle that. But you do need one for the multiplex display.
I havne't tested it fully because I don't have the hardware, but it should be really close.
Bean.
I tried the code with PropBasic & the information including the speed went to the Serial Terminal, however, I got no display on my LED display. I'll look at it & attempt to locate errors.
Joe
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I'm going insaine. It's SOOOOOO much fun. lol
Excellent! Excellent! Excellent! I am pretty new to the forums, but I think this was a great idea for those of us new to SPIN. It should lead
to a whole new array of easy to learn educational materials for beginners. I can't even begin to imagine the amount of work that this must
have been and still probably is, I just know it's a heck of a lot. Way to go Bean & Johnny and anyone else that contributed!
Many, many accolades!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ It's not the size of the dog in the fight, but the size of the fight in the dog.
Is it possible to control the same pin from two or more tasks?, if so how can this be done?
Regards
Gerry
RE #2: It's actually quite easy in PropBASIC because IO pin definitions are global (i.e., shared across all cogs in a project) -- all you have to do is set an output or read an input in your tasks as you would the main program.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
DEVICE P8X32A, XTAL1, PLL16X
FREQ 96_000_000
' Define pins
LED PIN 27 OUTPUT
'LED = 0 Turns LED ON
' Define TASKs
ToggleLED TASK
' Main program
PROGRAM Start
Start:
COGSTART ToggleLED
LED = 0 'if = 1 does not work
DO
LOOP
END
TASK ToggleLED
PAUSE 2000
DO
Pause 100
TOGGLE LED
LOOP
ENDTASK
but if LED is set to 1 in program Start·LED doesn't flash·-can anybody shed some light on this !
Also DO without a LOOP statement is not trapped as an error
I say, that looks like fun. VGA display for the masses. Starts with some vertical lines then a diagonal line then random pixels with red,white,blue,black. See photo.
This works straight out of the box on the dracblade. How can we take this further?
Well, I see an awful lot of pixels on the screen. Probably far more than are needed for some simple games. Is it possible, say, to halve the vertical and horizontal number which will decrease the number of bytes to 1/4, then have 4 times the number of colors, ie 4x4=16 colors?
The 512k of ram on the dracblade is not fast enough for direct drawing on the screen but it ought to be fast enough for moving sprites into screen memory, especially if the sprite is much smaller than the display - eg a little rocket ship moving across the display. I'll defer to the game experts (who I think hang out over at the hydra forum) but I think it ought to be possible in theory.
Back to the real world, I guess some fonts are the next possibility? And the 512k of ram would be a perfect spot to store some fonts, though hopefully there is some spare memory on the demo board to store some fonts too?
To answer my own question I believe reason is that as outa registers are ORed together,when LED =0 ,ToggleLED task will work
but with LED =1,ToggleLED will only generate a 1 as outa in Program start is permanently set to 1(· 1 OR x = 1).
To answer my own question I believe reason is that as outa registers are ORed together,when LED =0 ,ToggleLED task will work
but with LED =1,ToggleLED will only generate a 1 as outa in Program start is permanently set to 1(· 1 OR x = 1).
Regards
Gerry
Gerry, · You are right. The output from all the cogs is OR'd together. So if ANY cog makes it high, it is high.
· Also, the PIN modifiers are only for the cog running the main code, for the same reason. If you defined a pin as HIGH, and started another cog, that pin would always be held high by the other cog.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
Comments
I have been experimenting with PropBasic a little more. This really speeds me up! I can write the code more quickly and it will execute really fast. No assembler needed. I am astonished, how much code fits into the cog ram.
One suggestion: If you store a variable to a byte or word hub variable and read it again, then the sign causes trouble. What do you think of a parameter like that:
rdword buffer, variable[noparse][[/noparse], signed]······ 'to extend the sign to 32 bits
Christof
If you want to convert a signed word to a signed long you can do it with a bit of inline assembly:
The first line moves the original MSB (bit15) to bit31, the second moves it back, filling the new bits (31..16) with the original MSB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
The MAJOR change is in the way pin groups are handled.
In previous versions you had to declare pin groups as "name PIN LSBpin..MSBpin" with LSBpin always having to be a lower value than MSBpin. This was not consistent with the way spin uses groups of pins. So PropBASIC was changed.
Pin groups are now declared as "name PIN MSBpin..LSBpin" and compiler will reverse the bits if MSBpin is lower than LSBpin. This works very much like spin, so users of both languages won't get confused.
@Christof: It would probably require new commands like: WRSWORD, RDSWORD, WRSBYTE, RDSBYTE. I'll put it in the "think about it" pile.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
Christof
I have another question regarding negative numbers. The intention is that everything should work with signed numbers?
··············· mov········ __remainder,temp················ '····· sample1 = temp / 2
··············· and········ __remainder,#1·················
··············· mov········ sample1,temp···················
··············· shr········ sample1,#1·
So the sign gets lost.
Best Regards Christof
· Thanks for catching that.
· I will be fixed in release 00.00.73.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
Post Edited (Bean (Hitt Consulting)) : 1/21/2010 12:47:05 PM GMT
some other thing, ther seems to be a bug in str.
' Define variables (LONGs only)
temp···· VAR LONG
ascii··· VAR LONG(13) ' Conversion to ASCII
i······· VAR long
' Define Subroutines
SerNumber SUB 1
'###############################################################################################
' Start of main code
PROGRAM Start
Start:
· pause 2000
· for i = 0 to 100 step 10
··· SerNumber i
· next i
end
SUB SerNumber
··· STR ascii, __param1, 10,3
··· ascii(10) = 13
··· FOR temp = 0 TO 10
····· SEROUT TX, Baud, ascii(temp)
··· NEXT
ENDSUB
gives:
········ 0
······· 10
······· 20
······· 30
······· 40
········ 2
······· 12
······· 22
······· 32
········ 4
······ 100
As this is a key feature to debug, it would be nice to fix this soon.....
Best regards Christof
Yeah 32-bit values can only handle 10 digit values up to 4_294_967_296. That's why if chokes if the leading digit is > 4.
There is no problem if you use 9 digits.
I'll have to see if I can implement a 33-bit value somehow.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
Post Edited (Bean (Hitt Consulting)) : 1/22/2010 10:18:27 PM GMT
the sign eats one of the 9 digits in mode 3... Perhaps there are possibilities without having 33 bits?
Do not misunderstand me, please. I started a project right away with your compiler and your IDE this week. Working with·them is real fun! I have 4 Tasks running well, the code is about 10 screens long and gives about 800longs of cog code. So I am very happy with this betabeta Version!
Christof
I have posted version 00.00.73 with fixes for the problems you have found.
If you use mode 2 or 3 (signed) the first character is either "-" or " " (it cannot be a digit as before). So mode 2 or 3 allows 11 places to be used.
Basically if you specify mode 0 or 1(default) with 10 places or mode 2 or 3 with 11 places, the highest digit is handled before the main loop. The generates more code, but at least the result is correct.
I do not take offence...In fact I'm very glad that you are finding these bugs for me. I wish more members would be a though as you.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
Announcement: To cut costs in the current economic climate, we have switched-off the light at the end of the tunnel.
1) Download propbasic from the first page of this thread into a new folder
2) Run PropBasicIDE
3) Open the file Keyboard t PC.BAS
4) Minor tweak to the code - dropped the baud rate to 19200 as my terminal program is set up for that rate
5) Compile it
6) Run a terminal program (lots of choices - they all work)
7) Type characters on the keyboard and they come up on the screen.
This is fun!!!
Of course, I immediately want to do more. I had a quick look in the demos - is there a VGA driver?
If not, given there is lots of generic code around, is this hard to add?
I'm now trying to get my head around what propbasic is doing. The keyboard driver seems to be a complete rewrite in Propbasic (which is
very impressive, as it comes to a tiny amount of code. Less even that a Z80 assembly keyboard driver I have.) So rather than drop in pre-written
spin/pasm modules, are each of these functions being rewritten for propbasic? If so, given the small code listings, and the direct to assembly translation and the extremely rapid compilation, I can see the attraction there.
Thinking aloud, is there a way to automate the translation? Or is it just a tedious matter of going through each line?
I'm thinking of other useful building blocks - eg VGA, but especially the SD card code. Both of those would be beyond me to write, but I think I could contribute code for the 20x4 LCD display.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I'm not much of a BASIC programmer (in fact I've not used it since about 1983), but I want to set up some automated testing of the PropBasic compiler.
With spin, it's easy. I just downloaded the entire obex and built a test suite around that. I now test against ~1800 spin files.
Is anyone interested in E-mailing me zip files of their PropBasic source code that I could use in a private test suite? I could really use some programs that create multiple files, use tasks, use include files and anything else that hits the disk. Having said that, even simple examples will help greatly. No code will be examined, judged, commented on or released outside of my home network, but I could _really_ use some help here from those that are actually using PropBasic on a regular basis. <pretty please with a cherry on top>.
If you could e-mail code to proptools <at> fnarfbargle.com, I'd _really_ appreciate it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Have you looked at the Demos in the PropBasic Package. There are some interesting Video Files and other stuff there.
Ron
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
Announcement: To cut costs in the current economic climate, we have switched-off the light at the end of the tunnel.
Can you release the info on how to compile a .pbas program from am command line? I have looked through this thread and in the docs included with the latest v .75 and can't seem to find any info. I tried to use the Notepad++ editor (Which I like), but was not successful.
I used PropBASIC for the first larger program and was able to write a driver for an MCP23S17 I/O Expander chip pretty quickly. I used the SHIFTOUT command and then tweaked the PASM to remove the WAITCNT, because the MCP23S17 only needs 45ns between CLKs. I then reinserted the modified PASM back into the PropBASIC code using the ASM...ENDASM statements and this works so slick.
I can really see how useful this is to people that are not 100% proficient in PASM. It a great learning tool!!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jim Fouch
FOUCH SOFTWARE
You call PropBASIC.exe with the first parameter as the FULL path to the .pbas file (in quotes). If you add a /p switch, the compiler will pause at errors.
Example:
PropBASIC.exe "c:\full_path\myfile.pbas" /p
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
1. IF-ENDIF Statement
Compiler doesn't complain if "ENDIF" is missing.
2 IN & OUT PINS
Is it possible to control the same pin from two or more tasks?, if so how can this be done?
Regards
Gerry
I tried the code with PropBasic & the information including the speed went to the Serial Terminal, however, I got no display on my LED display. I'll look at it & attempt to locate errors.
Joe
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I'm going insaine. It's SOOOOOO much fun. lol
to a whole new array of easy to learn educational materials for beginners. I can't even begin to imagine the amount of work that this must
have been and still probably is, I just know it's a heck of a lot. Way to go Bean & Johnny and anyone else that contributed!
Many, many accolades!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not the size of the dog in the fight, but the size of the fight in the dog.
RE #2: It's actually quite easy in PropBASIC because IO pin definitions are global (i.e., shared across all cogs in a project) -- all you have to do is set an output or read an input in your tasks as you would the main program.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
Post Edited (JonnyMac) : 1/27/2010 4:27:37 PM GMT
Here is a really simple one. It creates a 320x240 pixel 4 color VGA bitmapped display.
Enjoy,
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
When I try attached it· works
but if LED is set to 1 in program Start·LED doesn't flash·-can anybody shed some light on this !
Also DO without a LOOP statement is not trapped as an error
Regards
Gerry
This works straight out of the box on the dracblade. How can we take this further?
Well, I see an awful lot of pixels on the screen. Probably far more than are needed for some simple games. Is it possible, say, to halve the vertical and horizontal number which will decrease the number of bytes to 1/4, then have 4 times the number of colors, ie 4x4=16 colors?
The 512k of ram on the dracblade is not fast enough for direct drawing on the screen but it ought to be fast enough for moving sprites into screen memory, especially if the sprite is much smaller than the display - eg a little rocket ship moving across the display. I'll defer to the game experts (who I think hang out over at the hydra forum) but I think it ought to be possible in theory.
Back to the real world, I guess some fonts are the next possibility? And the 512k of ram would be a perfect spot to store some fonts, though hopefully there is some spare memory on the demo board to store some fonts too?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
To answer my own question I believe reason is that as outa registers are ORed together,when LED =0 ,ToggleLED task will work
but with LED =1,ToggleLED will only generate a 1 as outa in Program start is permanently set to 1(· 1 OR x = 1).
Regards
Gerry
· You are right. The output from all the cogs is OR'd together. So if ANY cog makes it high, it is high.
· Also, the PIN modifiers are only for the cog running the main code, for the same reason. If you defined a pin as HIGH, and started another cog, that pin would always be held high by the other cog.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·