Ray,
I will get text working on VGA...Maybe this weekend if I get some free time.
I also uploaded an updated version of the compiler today. Please get the latest version when you get a chance.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
Here is the VGA demo with fonts and palette blocks.
NOTE: You MUST use PropBASIC version 00.00.77 or later to compile this. I fixed a bug that I found while writing this.
The resolution is 320x240 with 4 colors.
Text is 40x30 with a 8x8 font.
Each palette entry controls 16 pixels x 8 pixels (or two consecutive characters).
I have attached the .spin file too.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
I thought that I would give it a bump, this is to make sure that Bean does not forget about this project LOL. Any guess as to when this will be
coming out of BETA?
Nobody's forgetting anything. Unlike whining and complaining, testing is hard work and Bean and I are doing a lot of it. You don't have to pay a dime for PropBASIC so its "beta" versus "production" status is irrelevant (note that the documentation states there is no warranty of any kind... period). If you're serious about PropBASIC, how about posting some of you own code so that Bean and I can see what you're doing and how we might make the compiler and the documentation better.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
Check out the photo. Latest version of vga driver running on a Dracblade (but would work on any Prop with a VGA plug).
Letters of the alphabet, and a random palatte generator, so take your pick for a favourite color combo. This is amazing!
This brings up a technical question. I see in the demo there is a keyboard object, and the code for this sits in a TASK. I presume this goes in its own cog?
The minimum things I seem to always need are:
1) keyboard
2) Display
3) One or two serial ports
4) sd card for storing little files and data
5) some general purpose spare propeller pins. Digital in/out, and analog in/out.
Propbasic is getting jolly close to that.
I wonder, for things like the 4 serial port driver that are pretty much all PASM and only a tiny bit of spin glue code, is it possible to drop that sort of PASM code into a PROPBasic program? Call it a Task, fill a cog with the same PASM code, interface with it in the same way?
Well, ok, the serial port is already done, and you could just use two cogs for two ports. This is racing ahead so fast. So exciting. Is SD card on the list?
@Dr_A, I think that some SD code, for propBASIC, would be a major project. I was following the Kye thread with his undertaking of some SD
code, and he ran into some snags, he is a very good programmer. So, it's going to take somebody with a lot of skill to do the conversion.
Since I also end up using more than one serial port, I wonder if there really is a simple way of combining it so you only use one cog. The
other question I would have is, for instance, can the keyboard, vga, and something else be placed, in one TASK (cog), and be run successfully?
Have to start thinking about consolidation of code to reduce the number cogs that will be used.
Keep up the good work Bean, everybody knows this is a freebie, and we are very grateful for the work that you have done.
To Jon's point:
It is disheartening that while making demos and such, I seem to be the only one finding bugs.
I know that some people tend to assume that the tool (PropBASIC) wouldn't do anything wrong and that it MUST be their code. PLEASE don't do that.
This is beta testing, assume the compiler screwed up. And if you know a little PASM look at the generated code.
If something isn't working right, please make a post in this thread.
@Dr_Acula, Yeah SD will be quite an undertaking. But you should be able to use the .spin version if you use something like the dispatch demo program.
I have make yet another VGA demo (during which I found another bug) so you need to download version 00.00.78 for this demo.
I have added a line drawing routine and some other useful subroutines. Drawing now updates the palette for the points that are drawn.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
I thought I might have a shot at writing a bit of Propbasic code. Learning a lot as I go. The 'structure' reflects the prop architecture rather than Basic in some ways, but that is to be expected. Eg
DIM myarray(10) = 0
is replaced with
myarray HUB BYTE(10) = 0
But obviously that saves memory putting things in hub (as an aside, already thinking about putting arrays in external memory too).
Next thing I found is that subroutines need to be declared before use, with the number of parameters to be passed.
' Define Subroutines
Plot SUB 3 ' X, Y, Color(0-3)
Text SUB 3 ' X, Y, "String" (foreground is color 3, background is color 0)
I thought I would look at strings. Strings are not native to the propeller, at least not in the simple BASIC way of
A$="Hello"
PRINT LEFT$(a$,3)
But I've coded up strings in assembly so this is a similar task.
First, define a string array and fill with zeros (0 is the end marker)
string1 HUB BYTE(32) = 0
Then, fill it with some bytes. I'm still doing this one byte at a time, but there probably is a simpler way to do this aka string1 = "ABC", but anyway:
SUB printf ' X, Y prints STRING1
textX VAR LONG
textY VAR LONG
txtPtr VAR LONG
txtX VAR LONG
txtY VAR LONG
pixels VAR LONG
txtTemp VAR LONG
counter VAR LONG
textX = __param1
textY = __param2
counter = 0
DO
RDBYTE txtPtr, txtTemp
INC txtPtr
RDBYTE string1(counter),txtTemp
IF txtTemp = 0 THEN EXIT
INC counter
txtTemp = txtTemp - " "
txtTemp = txtTemp * 8
GETADDR font, pixels
txtTemp = txtTemp + pixels
FOR txtY = 0 TO 7
RDBYTE txtTemp, pixels
INC txtTemp
FOR txtX = 0 TO 7
IF pixels > 127 THEN
Plot textX, textY, 3
ELSE
Plot textX, textY, 0
ENDIF
pixels = pixels AND 127
pixels = pixels << 1
INC textX
NEXT
DEC textX, 8
INC textY
NEXT
DEC textY, 8
INC textX, 8
LOOP
ENDSUB
This is crude string handling at the moment. Things I'm pondering;
Put an entire string into an array with one line. Maybe pass a string pointer to a dedicated SUB to do this?
Point to arrays by name. eg pass string3 to printf
Move bytes from one string array to another by pointing to the string array start location, the @ symbol in spin?
I think with those fundamentals I can copy over LEFT, MID, RIGHT, ASC, CHR, HEX, STR from existing z80 routines. Turn these into SUBs where you pass the name of a string, and the name of the destination string.
Bean,
Thanks for VGA Demo#4.
Just for clarification, are we supposed to be seeing psychadelic camels' feet at the beginning?
The reason for asking: you may remember that the very strange audio demo that I presumed was
a matter of unusual musical taste was in fact a bug ...
Regards,
T o n y
Tony, · Are you using PropBASIC version 00.00.78 that I just posted ? · There was a bug in the SGN function (it was returning ABS) that is used in the line drawing routines. · · Those should be moire patterns.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
I'm having a weird problem with running a program in a separate cog using v78. Since I'm new to PropBasic I tried to toggle two leds. So here is the code:
led1 pin 16 low
led2 pin 17 high
START:
do
toggle led1
toggle led2
pause 500
loop
end
I ran this and SUCCESS! The leds toggle back and forth. I am a programming demigod.
Next I want to see if I can run this in a separate cog. so...
Result led1 stays on and led2 blinks at about 1/2 second. If I reverse the initial states, led2 stays on and led1 blinks. My interpretation is that the cog runs one iteration of the loop and then crashes or resets. When I've run into these situations in SPIN usually increasing stack space for the cog fixes it, but that is not an option here. I've tried changing "cogstart" to "coginit" with a specified cog#, but with the same results.
I can't think of a more basic program than this, so I'm stumped.
Never mind. I just finished reading the rest of the thread and I found:
"IN and OUT again
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"
Don't I feel like a schmuck .... (in my defense, It IS a long thread...)
I just tried your code, on my demo board, and I get the same results. I put in a 'pause 500' between led1 and led2, in the task code, just to see what happens, I have led1 blink with a short pause, but led2 stays on all the time.
Once you take the time to learn the Propeller, Ray, the problem will be obvious: all cogs outputs are OR'd together. In the PIN definitions LED2 is defined as HIGH on reset -- what's happening is that the main cog is making LED turn on and masking the activity of the TASK. Set both pins to LOW or OUTPUT and the problem will go away.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
Jon has asked us to post examples of what we are doing.
Here is a two axis step and direction controller using the standard technique of adding a velocity value at fixed intervals to an accumulator .
At halfway point the step output goes high and low again when the accumulator goes low.
A spare cog acts as a pulse generator .This could serve as a master speed control for a multi-axis machine.
Speeds have been tested accurate to 20 kHz
This code took less than a day to port across from code written in Proton for a (single axis ) Microchip controller.
Bean has kindly allowed me to create native Mac / Linux binaries of his compiler. I have posted them here www.fnarfbargle.com/PropBasic
The major changes are :
- The INVALID.TXT file is built in (no need to have it in the same directory as the binary - or anywhere at all for that matter)
- The compiler accepts relative paths in addition to absolute paths for the source file
I have appended a "-bst" to the compiler name so there is no way the binaries can be confused with the originals. Please don't bug Bean about any non-code generator related issues, but feedback directly to me would be appreciated if anyone finds this stuff useful.
Unlike most *nix programs, the file to compile *MUST* be first on the command line. Subsequent command line switches are specified with / characters after the file name. Filenames with spaces must be properly escaped or quoted. (Quoted on Windows).
As I don't do basic, my test harness is limited to the programs included in the compiler demo directory. I have ensured they all compile properly, but I've not tried any programs that include anything other than binary files, so that behaviour is currently unknown.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
@BradC - Thanks a lot. I unzipped it, removed the "-bst.osx" from the result (for less typing), and moved it to my /Applications folder. It works running it from the Terminal program. It's a beginning.
Mike Green said...
@BradC - Thanks a lot. I unzipped it, removed the "-bst.osx" from the result (for less typing), and moved it to my /Applications folder. It works running it from the Terminal program. It's a beginning.
Cheers for the feedback Mike, we have to crawl before we can walk/run/fly/teleport [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Mike Green said...
@BradC - Thanks a lot. I unzipped it, removed the "-bst.osx" from the result (for less typing), and moved it to my /Applications folder. It works running it from the Terminal program. It's a beginning.
.... I went Mike Green one farther, renamed it 'pb' ... a LOT less typing!
My Mac is a 2.66 GHZ Core 2 Duo with 4 GB RAM (Mar '09 vintage) running OSX 10.6.2 all up to date .... The PropBasic 0.79 binary is BLAZING fast! Way to go Bean and Brad
I made an editor path in BST to my 'pb' directory then loaded and compiled the resultant spin files just fine. It's not that big of a deal, flipping over to a terminal window for a few seconds and coming back to BST. I could live with that, if that's all it was, BUTTTTTTTTT, integrated into the BST GUI-IDE will be awesome!
cheers ... BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden www.wulfden.org/TheShoppe/
Comments
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
Ray
I will get text working on VGA...Maybe this weekend if I get some free time.
I also uploaded an updated version of the compiler today. Please get the latest version when you get a chance.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
NOTE: You MUST use PropBASIC version 00.00.77 or later to compile this. I fixed a bug that I found while writing this.
The resolution is 320x240 with 4 colors.
Text is 40x30 with a 8x8 font.
Each palette entry controls 16 pixels x 8 pixels (or two consecutive characters).
I have attached the .spin file too.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
Mind you, it is nice to see the full range of colors there! This bodes well for games etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
You need to download version 00.00.77 of the compiler.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Just put a message up after about 30 secs saying " No errors found, test complete" .
It would impress a lot of the clients we get
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Thank you for VGA#3: we now have a native PropBASIC way of getting a text onto VGA!
T o n y
coming out of BETA?
Ray
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
Post Edited (JonnyMac) : 2/3/2010 4:55:06 AM GMT
Check out the photo. Latest version of vga driver running on a Dracblade (but would work on any Prop with a VGA plug).
Letters of the alphabet, and a random palatte generator, so take your pick for a favourite color combo. This is amazing!
This brings up a technical question. I see in the demo there is a keyboard object, and the code for this sits in a TASK. I presume this goes in its own cog?
The minimum things I seem to always need are:
1) keyboard
2) Display
3) One or two serial ports
4) sd card for storing little files and data
5) some general purpose spare propeller pins. Digital in/out, and analog in/out.
Propbasic is getting jolly close to that.
I wonder, for things like the 4 serial port driver that are pretty much all PASM and only a tiny bit of spin glue code, is it possible to drop that sort of PASM code into a PROPBasic program? Call it a Task, fill a cog with the same PASM code, interface with it in the same way?
Well, ok, the serial port is already done, and you could just use two cogs for two ports. This is racing ahead so fast. So exciting. Is SD card on the list?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 2/3/2010 11:18:08 AM GMT
code, and he ran into some snags, he is a very good programmer. So, it's going to take somebody with a lot of skill to do the conversion.
Since I also end up using more than one serial port, I wonder if there really is a simple way of combining it so you only use one cog. The
other question I would have is, for instance, can the keyboard, vga, and something else be placed, in one TASK (cog), and be run successfully?
Have to start thinking about consolidation of code to reduce the number cogs that will be used.
Keep up the good work Bean, everybody knows this is a freebie, and we are very grateful for the work that you have done.
Ray
It is disheartening that while making demos and such, I seem to be the only one finding bugs.
I know that some people tend to assume that the tool (PropBASIC) wouldn't do anything wrong and that it MUST be their code. PLEASE don't do that.
This is beta testing, assume the compiler screwed up. And if you know a little PASM look at the generated code.
If something isn't working right, please make a post in this thread.
@Dr_Acula, Yeah SD will be quite an undertaking. But you should be able to use the .spin version if you use something like the dispatch demo program.
I have make yet another VGA demo (during which I found another bug) so you need to download version 00.00.78 for this demo.
I have added a line drawing routine and some other useful subroutines. Drawing now updates the palette for the points that are drawn.
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) : 2/3/2010 12:50:11 PM GMT
is replaced with
But obviously that saves memory putting things in hub (as an aside, already thinking about putting arrays in external memory too).
Next thing I found is that subroutines need to be declared before use, with the number of parameters to be passed.
I thought I would look at strings. Strings are not native to the propeller, at least not in the simple BASIC way of
But I've coded up strings in assembly so this is a similar task.
First, define a string array and fill with zeros (0 is the end marker)
Then, fill it with some bytes. I'm still doing this one byte at a time, but there probably is a simpler way to do this aka string1 = "ABC", but anyway:
WRBYTE string1(0),"H" WRBYTE string1(1),"e" WRBYTE string1(2),"l" WRBYTE string1(3),"l" WRBYTE string1(4),"o"And then define a little print routine
and call it
printf 0,0 ' prints string1 at position X,Yand this is the print routine
SUB printf ' X, Y prints STRING1 textX VAR LONG textY VAR LONG txtPtr VAR LONG txtX VAR LONG txtY VAR LONG pixels VAR LONG txtTemp VAR LONG counter VAR LONG textX = __param1 textY = __param2 counter = 0 DO RDBYTE txtPtr, txtTemp INC txtPtr RDBYTE string1(counter),txtTemp IF txtTemp = 0 THEN EXIT INC counter txtTemp = txtTemp - " " txtTemp = txtTemp * 8 GETADDR font, pixels txtTemp = txtTemp + pixels FOR txtY = 0 TO 7 RDBYTE txtTemp, pixels INC txtTemp FOR txtX = 0 TO 7 IF pixels > 127 THEN Plot textX, textY, 3 ELSE Plot textX, textY, 0 ENDIF pixels = pixels AND 127 pixels = pixels << 1 INC textX NEXT DEC textX, 8 INC textY NEXT DEC textY, 8 INC textX, 8 LOOP ENDSUBThis is crude string handling at the moment. Things I'm pondering;
Put an entire string into an array with one line. Maybe pass a string pointer to a dedicated SUB to do this?
Point to arrays by name. eg pass string3 to printf
Move bytes from one string array to another by pointing to the string array start location, the @ symbol in spin?
I think with those fundamentals I can copy over LEFT, MID, RIGHT, ASC, CHR, HEX, STR from existing z80 routines. Turn these into SUBs where you pass the name of a string, and the name of the destination string.
All good fun!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 2/3/2010 12:54:17 PM GMT
Thanks for VGA Demo#4.
Just for clarification, are we supposed to be seeing psychadelic camels' feet at the beginning?
The reason for asking: you may remember that the very strange audio demo that I presumed was
a matter of unusual musical taste was in fact a bug ...
Regards,
T o n y
· Are you using PropBASIC version 00.00.78 that I just posted ?
· There was a bug in the SGN function (it was returning ABS) that is used in the line drawing routines.
·
· Those should be moire patterns.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
Yes I'm using PropBASIC#78.
Mystery solved: one man's camels' feet is another man's Moir
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
led1 pin 16 low
led2 pin 17 high
START:
do
toggle led1
toggle led2
pause 500
loop
end
I ran this and SUCCESS! The leds toggle back and forth. I am a programming demigod.
Next I want to see if I can run this in a separate cog. so...
led1 pin 16 low
led2 pin 17 high
blink TASK
START:
cogstart blink
do
loop
END
TASK blink
do
toggle led1
toggle led2
pause 500
loop
ENDTASK
Result led1 stays on and led2 blinks at about 1/2 second. If I reverse the initial states, led2 stays on and led1 blinks. My interpretation is that the cog runs one iteration of the loop and then crashes or resets. When I've run into these situations in SPIN usually increasing stack space for the cog fixes it, but that is not an option here. I've tried changing "cogstart" to "coginit" with a specified cog#, but with the same results.
I can't think of a more basic program than this, so I'm stumped.
"IN and OUT again
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"
Don't I feel like a schmuck
Ray
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
Here is a two axis step and direction controller using the standard technique of adding a velocity value at fixed intervals to an accumulator .
At halfway point the step output goes high and low again when the accumulator goes low.
A spare cog acts as a pulse generator .This could serve as a master speed control for a multi-axis machine.
Speeds have been tested accurate to 20 kHz
This code took less than a day to port across from code written in Proton for a (single axis ) Microchip controller.
www.fnarfbargle.com/PropBasic
The major changes are :
- The INVALID.TXT file is built in (no need to have it in the same directory as the binary - or anywhere at all for that matter)
- The compiler accepts relative paths in addition to absolute paths for the source file
I have appended a "-bst" to the compiler name so there is no way the binaries can be confused with the originals. Please don't bug Bean about any non-code generator related issues, but feedback directly to me would be appreciated if anyone finds this stuff useful.
Unlike most *nix programs, the file to compile *MUST* be first on the command line. Subsequent command line switches are specified with / characters after the file name. Filenames with spaces must be properly escaped or quoted. (Quoted on Windows).
As I don't do basic, my test harness is limited to the programs included in the compiler demo directory. I have ensured they all compile properly, but I've not tried any programs that include anything other than binary files, so that behaviour is currently unknown.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
I very cleverly uploaded completely broken binaries this morning. They have been fixed / re-tested & re-uploaded.
Sorry about that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Cheers for the feedback Mike, we have to crawl before we can walk/run/fly/teleport [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
.... I went Mike Green one farther, renamed it 'pb' ... a LOT less typing!
My Mac is a 2.66 GHZ Core 2 Duo with 4 GB RAM (Mar '09 vintage) running OSX 10.6.2 all up to date .... The PropBasic 0.79 binary is BLAZING fast! Way to go Bean and Brad
I made an editor path in BST to my 'pb' directory then loaded and compiled the resultant spin files just fine. It's not that big of a deal, flipping over to a terminal window for a few seconds and coming back to BST. I could live with that, if that's all it was, BUTTTTTTTTT, integrated into the BST GUI-IDE will be awesome!
cheers ... BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden
www.wulfden.org/TheShoppe/
I will have to try this under Debian later on!
Thanks Bean / Brad!