I've posted a new version of fastspin (see link in the fastspin for P2 thread, although of course it still works on P1). Since this is the BASIC thread, I'll just highlight some of the changes to the BASIC language support:
(1) Support for DATA/READ/RESTORE and INPUT
(2) Support for old-school BASIC programs with line numbers and GOSUB. I was able to easily port some games from classicbasicgames.org by adding:
defsng a-z ' default to floating point
option implicit ' allow implicit variable declarations
and tweaking some PRINT statements
(3) At the other extreme, better support for functional programming, in the form of a much more compact lambda function notation. For example:
sub myrepeat(n as integer, proc as sub(x as integer))
for i = 1 to n
proc(i)
next
end sub
myrepeat 4, [x: print "the number is: "; x]
Prints:
the number is: 1
the number is: 2
the number is: 3
the number is: 4
Similarly, a function to produce a function to add n to x can be written as:
type intfunc as function(x as integer) as integer
function incn(n) as intfunc
return [x:=>x+n]
end function
var f = incn(3)
print f(2) ' prints 2+3, i.e. 5
The general syntax is an opening "[", followed by optional parameters, then ":", then the statements to execute, and finally a "=>" and the expression to return; this latter may also have an "as type" clause to explicitly specify the return type.
Here's an example that can produce a counting function. It illustrates that this BASIC has proper closures (the local variables that are captured have persistent values):
type countfunc as function(x as integer) as integer
function make_counter(curval) as countfunc
return [n:var t=curval: curval = curval+n: =>t]
end function
var c = make_counter(0) ' initial counter value is 0
print c(1) ' prints 0, new value is 1
print c(5) ' prints 1, new value is 6
print c(4) ' prints 6, new value is 10
DEC in simpleserial.spin doesn't seem to work on P2...
Getting nothing out...
Actually, it's probably a tab issue. I think I can fix it...
It was a tab issue. Might have to revisit this in SpinEdit…
Had to adjust spaces on these two lines:
I'm trying to add in my spin only FSRW to the above.
With "go" commented out, it compiles.
But, uncomment "go" and it won't compile (appears to crash with no error messages).
PUB main
clkset(_SETFREQ, _CLOCKFREQ)
params[0]:=@bitmap
cognew(@entry,@params)
'go
I'm not understanding something with this attempted adaptation of the VGA demo from pure ASM to ASM+Spin using Fastspin.
The bitmap seems to wind up at the wrong place in memory. I'm telling it to be at $1000-$436, but it winds up at $10AA instead...
Is this a bug, or am I doing something wrong?
It's a bug. Basically ORGH does not work in Spin programs, only pure PASM programs. I'll try to fix that, but for now I would suggest leaving out the ORGH and using @ @ @ buffer to get the address of the buffer where the FILE is.
Not sure what's going on with your "go" crash; I can't reproduce it here, although I'm using my fsrw.spin2 because you only posted your main program, so maybe there's a difference there? It seems unlikely though. It's possible that it's a stack overflow in Windows, similar to what you ran into in the other VGA thread. Do you know how to increase the stack size allocated to a .exe in Windows? I think there's a tool that can change an existing .exe to give it a bigger stack, but I can't remember what it is.
@Rayman: Could you try the fastspin.exe in this .zip? It won't fix your ORGH problem, but it might fix the crash -- it's been recompiled with a bigger stack for Windows (8MB instead of the default 1MB).
thanks, I'll try it. Here's another thing I just noticed...
garryj's USB code uses conditions like this:
if_10 that generate an error..
if_00 seems to be OK, but not the others...
Ah, I missed those. We already have if_nc_and_nz and if_nz_and_nc (and all the similar variants). I didn't realize Chip had added so many aliases for the if conditions. I'll add them, although personally I think it's just adding more ways for newbies to be confused.
thanks, I'll try it. Here's another thing I just noticed...
garryj's USB code uses conditions like this:
if_10 that generate an error..
if_00 seems to be OK, but not the others...
Ah, I missed those. We already have if_nc_and_nz and if_nz_and_nc (and all the similar variants). I didn't realize Chip had added so many aliases for the if conditions. I'll add them, although personally I think it's just adding more ways for newbies to be confused.
Used properly, they make sense to me. With the ability to rotate a pair of bits into C,Z, the matching conditionals of
if_00
if_01
if_10
if_11
are easier to follow than the unrelated C,Z - allows for simpler 4-choice case statements.
On the topic of BASIC for P1: is anyone using the fastspin BASIC interpreter? I've recently updated fastspin and spin2gui to support some additional BASIC features like ON x GOTO and 2 dimensional arrays. I've also been thinking of adding something like a DAT section to hold large blocks of assembly and data together. The syntax would be something like:
ASM SHARED
org 0
entry
mov DIRA, mask
...
mask
long $010
END ASM
Unlike regular inline assembly this would not allow access to any BASIC variables, but it would make it easy to define code to load into COGs (just like DAT in Spin).
But I'm not sure if anyone is actually using BASIC in P1 or P2 (both would be supported), so not sure if this would be of interest?
On the topic of BASIC for P1: is anyone using the fastspin BASIC interpreter? I've recently updated fastspin and spin2gui to support some additional BASIC features like ON x GOTO and 2 dimensional arrays. I've also been thinking of adding something like a DAT section to hold large blocks of assembly and data together. The syntax would be something like:
ASM SHARED
org 0
entry
mov DIRA, mask
...
mask
long $010
END ASM
Unlike regular inline assembly this would not allow access to any BASIC variables, but it would make it easy to define code to load into COGs (just like DAT in Spin).
I'm unclear here, does that mean the more usual inline assembler, cannot define code to load into COGs ?
I'm unclear here, does that mean the more usual inline assembler, cannot define code to load into COGs ?
Yes. The usual inline assembler is, well, inline, i.e. it defines code as part of a function. So you can write snippets of ASM code that get executed inline or called directly, but not a whole program to take over another COG. (You could write inline ASM in a function and run it in another COG, but that would still drag the usual BASIC runtime along with it, so it wouldn't really take over the entire COG.)
But I'm not sure if anyone is actually using BASIC in P1 or P2 (both would be supported), so not sure if this would be of interest?
PropBASIC is certainly used, and I'm not sure how different your version is ?
Very different. Mine is more like FreeBASIC, remember? And I think we already ported the reciprocal frequency counter earlier in this thread (back on page 3, in fact).
... So you can write snippets of ASM code that get executed inline or called directly, but not a whole program to take over another COG. (You could write inline ASM in a function and run it in another COG, but that would still drag the usual BASIC runtime along with it, so it wouldn't really take over the entire COG.)
What stops there being 'full elasticity', so you can have any mix of BASIC (or any HLL) and in-line ASM, including 100% of ASM in another COG ? (so making an external assembler less required)
If nothing in 'usual BASIC runtime' is called, is that then discarded entirely ?
Very different. Mine is more like FreeBASIC, remember? And I think we already ported the reciprocal frequency counter earlier in this thread (back on page 3, in fact).
Ah, great, thanks.. Dunno if I missed that, or forgot, but I do not see any comment by me, so maybe that slipped past.
Glad to know someone is finding it useful . Are there any glitches or missing features that you'd like to see added to the BASIC?
Thanks,
Eric
Nothing jumps out at me. One thing I want to try is running some classic Basic programs.
Some of my old Basic programs output graphics based on poking ascii values into a memory mapped video. I've never thought about doing that on a VGA terminal. Would there be any (library) functions that would be able to do that?
Some of my old Basic programs output graphics based on poking ascii values into a memory mapped video. I've never thought about doing that on a VGA terminal. Would there be any (library) functions that would be able to do that?
If you use a textmode "VGA driver", writing ASCII values into the related buffer will display characters. Maybe an example for this would be nice too...
I am starting to believe that Parallax wants to stop supporting SimpleIDE , in favor of BlocklyProp. So, now I have to really start thinking about some other way of programming the Propeller x.
From the last time I did use fastspin Basic, I ran into some problems, for my projects at least, because fastspin Basic is LMM. The other problem that I need to overcome is when using the AB WiFi, I use the C function for interacting with the WiFi to work with an .html file that shows up in a WEB page. Also The other thing that I do like about SimpleIDE C, is that it has an extensive library, which I do use for different things like the ADC, CM2302, …, etc.
The last thing I want to mention is the SimpleIDE UI, it is very user friendly and easy to use. I think I got spoiled by using SimpleIDE. But, since Parallax is dumping support for SimpleIDE, I really have to start moving in another direction.
So, I guess I have to start fresh with fastspin Basic again to see how some of the things I just mentioned could be overcome.
Just an idea Eric, for dealing with the SimpleIDE C libs, to be used with fastspin Basic.
Since this is based on FreeBasic, for FreeBasic, somebody created a program called "leapfrog". What that program does is it takes a C library or some C code and turns it into a '.bi' file. The created '.bi' can then be included within the FreeBasic program to make use of the C functions that are now within the '.bi' file.
I remember a few years back I wanted to use some C code within a FreeBasic program, so I used the "leapfrog" program to do the "conversion" and then used the created '.bi' file within my program, it worked as expected. Not sure who created the "leapfrog" program, or even if there is existing code that could be looked at.
I think maybe something like a "leapfrog" program for fastspin Basic could be a helpful solution for Fastspin Basic to reuse the existing SimpleIDE C library. Just my 2 cents.
Thanks for the suggestion, Ray, it sounds interesting.
Roy Eltham is porting the Simple Libraries to fastspin's C compiler. That will allow us to access those libraries from BASIC and Spin as well, since fastspin supports all 3 languages. There's also all the OBEX Spin code too, of course, which is easy to call from BASIC.
I am trying to figure out how run a Linux version of spin2gui. In the src dir I used the gui.tcl, made it executable, but no luck in getting it to run. I am using a Debian version of Linux. Any suggestions as to what I can do to make it work.
I am trying to figure out how run a Linux version of spin2gui. In the src dir I used the gui.tcl, made it executable, but no luck in getting it to run. I am using a Debian version of Linux. Any suggestions as to what I can do to make it work.
You'll need to run spin2gui.tcl. "wish spin2gui.tcl" will usually do it. You can get spin2gui.tcl from the source repository, or use this:
#!/usr/bin/wish
#
# Simple GUI for Spin
# Copyright 2018 Total Spectrum Software
# Distributed under the terms of the MIT license;
# see License.txt for details.
#
# Top level program
package require Tk
package require autoscroll
#package require ctext
source src/ctext/ctext.tcl
source src/checkserial.tcl
source src/gui.tcl
Comments
(1) Support for DATA/READ/RESTORE and INPUT
(2) Support for old-school BASIC programs with line numbers and GOSUB. I was able to easily port some games from classicbasicgames.org by adding: and tweaking some PRINT statements
(3) At the other extreme, better support for functional programming, in the form of a much more compact lambda function notation. For example:
sub myrepeat(n as integer, proc as sub(x as integer)) for i = 1 to n proc(i) next end sub myrepeat 4, [x: print "the number is: "; x]Prints:Similarly, a function to produce a function to add n to x can be written as:
The general syntax is an opening "[", followed by optional parameters, then ":", then the statements to execute, and finally a "=>" and the expression to return; this latter may also have an "as type" clause to explicitly specify the return type.
Getting nothing out...
Actually, it's probably a tab issue. I think I can fix it...
It was a tab issue. Might have to revisit this in SpinEdit…
Had to adjust spaces on these two lines:
The bitmap seems to wind up at the wrong place in memory. I'm telling it to be at $1000-$436, but it winds up at $10AA instead...
Is this a bug, or am I doing something wrong?
I'm trying to add in my spin only FSRW to the above.
With "go" commented out, it compiles.
But, uncomment "go" and it won't compile (appears to crash with no error messages).
PUB main clkset(_SETFREQ, _CLOCKFREQ) params[0]:=@bitmap cognew(@entry,@params) 'goIt's a bug. Basically ORGH does not work in Spin programs, only pure PASM programs. I'll try to fix that, but for now I would suggest leaving out the ORGH and using @ @ @ buffer to get the address of the buffer where the FILE is.
garryj's USB code uses conditions like this:
if_10 that generate an error..
if_00 seems to be OK, but not the others...
and
DAT' Bitmap org 'orgh $1000 - $436 'justify pixels at $1000, pallete at $1000-$400 bitmap file "bitmap2.bmp"'combined1.bmp" 'bitmap2.bmp '640 x 480, 8pbb-lutAh, I missed those. We already have if_nc_and_nz and if_nz_and_nc (and all the similar variants). I didn't realize Chip had added so many aliases for the if conditions. I'll add them, although personally I think it's just adding more ways for newbies to be confused.
Used properly, they make sense to me. With the ability to rotate a pair of bits into C,Z, the matching conditionals of
if_00
if_01
if_10
if_11
are easier to follow than the unrelated C,Z - allows for simpler 4-choice case statements.
But I'm not sure if anyone is actually using BASIC in P1 or P2 (both would be supported), so not sure if this would be of interest?
PropBASIC is certainly used, and I'm not sure how different your version is ?
An excellent example of PropBASIC is this code - does that compile in fastspin BASIC ? (with minimal edits maybe ?)
http://forums.parallax.com/discussion/123170/propbasic-reciprocal-frequency-counter-0-5hz-to-40mhz-40mhz-now
Tom
Very different. Mine is more like FreeBASIC, remember? And I think we already ported the reciprocal frequency counter earlier in this thread (back on page 3, in fact).
Glad to know someone is finding it useful
Thanks,
Eric
If nothing in 'usual BASIC runtime' is called, is that then discarded entirely ?
Ah, great, thanks.. Dunno if I missed that, or forgot, but I do not see any comment by me, so maybe that slipped past.
Some of my old Basic programs output graphics based on poking ascii values into a memory mapped video. I've never thought about doing that on a VGA terminal. Would there be any (library) functions that would be able to do that?
Thanks
Tom
If you use a textmode "VGA driver", writing ASCII values into the related buffer will display characters. Maybe an example for this would be nice too...
From the last time I did use fastspin Basic, I ran into some problems, for my projects at least, because fastspin Basic is LMM. The other problem that I need to overcome is when using the AB WiFi, I use the C function for interacting with the WiFi to work with an .html file that shows up in a WEB page. Also The other thing that I do like about SimpleIDE C, is that it has an extensive library, which I do use for different things like the ADC, CM2302, …, etc.
The last thing I want to mention is the SimpleIDE UI, it is very user friendly and easy to use. I think I got spoiled by using SimpleIDE. But, since Parallax is dumping support for SimpleIDE, I really have to start moving in another direction.
So, I guess I have to start fresh with fastspin Basic again to see how some of the things I just mentioned could be overcome.
Ray
https://www.parallax.com/downloads/simpleide-software-windows-propeller-c
Since this is based on FreeBasic, for FreeBasic, somebody created a program called "leapfrog". What that program does is it takes a C library or some C code and turns it into a '.bi' file. The created '.bi' can then be included within the FreeBasic program to make use of the C functions that are now within the '.bi' file.
I remember a few years back I wanted to use some C code within a FreeBasic program, so I used the "leapfrog" program to do the "conversion" and then used the created '.bi' file within my program, it worked as expected. Not sure who created the "leapfrog" program, or even if there is existing code that could be looked at.
I think maybe something like a "leapfrog" program for fastspin Basic could be a helpful solution for Fastspin Basic to reuse the existing SimpleIDE C library. Just my 2 cents.
Ray
Roy Eltham is porting the Simple Libraries to fastspin's C compiler. That will allow us to access those libraries from BASIC and Spin as well, since fastspin supports all 3 languages. There's also all the OBEX Spin code too, of course, which is easy to call from BASIC.
Ray
You'll need to run spin2gui.tcl. "wish spin2gui.tcl" will usually do it. You can get spin2gui.tcl from the source repository, or use this: