Oh, I forgot to mention that Jeff Martin is plugging the new compiler into the PropellerTool. That has scroll bars and context highlighting.
What happened to PropellerIDE? I thought that was going to be the cross platform replacement for the PropellerTool. Will PropellerIDE be updated to work with Spin2?
I don't know. It's easy for us to get PropellerTool running, though.
I just tried it on my 1080p FastSpin tile driver.
I expected about 0% chance of it working...
But, I'm giving it a go...
So far:
1. Had to fix "integer not allowed in floating-point expressions" issue
2. Appears to want () after Pub method names, even if no parameters
3. Got error on "add #read_1,#1". FastSpin allowed that first #, even though it is wrong...
4. Methods with no arguments need () after name to call
5. It doesn't like the @ in this return (gives error: expected end of line):
PUB GetTiles() 'return address to tile pointer array
return @Tiles
I just tried it on my 1080p FastSpin tile driver.
I expected about 0% chance of it working...
But, I'm giving it a go...
So far:
1. Had to fix "integer not allowed in floating-point expressions" issue
2. Appears to want () after Pub method names, even if no parameters
3. Got error on "add #read_1,#1". FastSpin allowed that first #, even though it is wrong...
4. Methods with no arguments need () after name to call
5. It doesn't like the @ in this return (gives error: expected end of line):
PUB GetTiles() 'return address to tile pointer array
return @Tiles
Rayman, I just looked into this. If you want a method to return some value(s), you need to put ': resultname{, result2name,...}' after the parameters declaration. So, there can only be return values if they are specified in the method declaration.
PUB CreateP1Colors():i,j,k,l,m,r,g,b 'Create P2 version of the P1 colors from the P1 VGA demo
'Need to create 24-bit colors from the 6-bit color P1 code
'When stored at proper place in palette array, will be compatible with P1 text printing style
repeat j from 0 to 15 step 2
I guess this is defining several return variables that aren't actually being used to return anything...
FastSpin let me get away with this. We'll see what Spin2 does soon...
@cgracey said:
> Rayman wrote: »
>
> Ok, I got past that with this: PUB GetTiles():pTiles28934|i23432 'return address to tile pointer array i23432:=@Tiles return i23432
>
>
> But, it seems that local variables have to be globally unique?
> it won't work with just plain "i" or "pTiles"
>
>
>
>
> Local variables need to be distinguishable from globals.
>
> It sounds like you've already used 'i' and 'pTiles' globally. Is that the case?
Yeah that's not a practical restriction, Chip.
Maybe prefix or suffix the variables internally, or have an additional scope byte that affects the hash?
I prefer to not allow local variables with the same names as global, as long as that doesn't apply across external objects you use (OBJ section).
As in, if I use an OBEX object, will my global vars "collide" with it's locals causing it (the OBEX object) to fail to compile in the context of my program?
> @"Roy Eltham" said:
> I prefer to not allow local variables with the same names as global, as long as that doesn't apply across external objects you use (OBJ section).
> As in, if I use an OBEX object, will my global vars "collide" with it's locals causing it (the OBEX object) to fail to compile in the context of my program?
Object boundaries keep problems like that from happening.
Chip,
I thought that was the case. Just wasn't sure if it had changed with Spin2, due to some other change.
If it's working the same as Spin1, then I say don't change it.
If you do allow locals to have the same names as globals, then it should at the very least issue a warning, because it's likely to be a bug (or at the very least bad design).
I could resolve this conflict by moving this dat section assembly code to a seperate file.
But then, I face the challenge of passing all the constants it needs as variables... very tedious
Rayman,
The reason for the "more work" is to make your code less likely to have bugs and easier to read by others.
You can still use i,j,k,x,y everywhere except as globals.
I think having the same names everywhere makes your code harder to read. Like if you have a variable "i" in global space AND in several local spaces, then how do you know what's what? A functions that has a local named "i" won't be able to access the global named "i" unless Chip adds yet another feature to allow you to prefix variable accesses with a "global scope" indicator. It's all just making it more of a mess.
Being same as spin1 is fine
Just seems like extra work for no reason
I like to use i,j,k,x,y everywhere
Those single-letter variables are going to be used only within methods, I'd think. Why give global VARs such non-descriptive names when they won't meaningfully communicate ideas among methods?
I found a bug in the interpreter, where the skip patterns for the multiply/divide assignment operations had a consistent '1' where they needed a '0'. Here is the latest:
I made a decimal printing routine that prints commas, too, in the VGA demo. There are two drivers now, one for 640x480 and another for 1280x1024, which provides 160x85 characters.
Here is the VGA demo source code. You can see how SEND() can be used just like a PRINT in BASIC:
CON _clkfreq = 250_000_000
OBJ
vga : "VGA_640x480_text_80x40_driver" '_clkfreq >= 50MHz
' vga : "VGA_1280x1024_text_160x85_driver" '_clkfreq >= 216MHz
PUB go() | i, t
vga.start(8) 'start vga
send := @vga.print 'set send pointer
send(4, $004040, 5, $00FFFF) 'cyan on dark cyan
t := getct 'capture time
i := @text 'print file
repeat @textend-i
send(byte[i++])
i := getct 'capture time
t := muldiv64(i - t, 1_000_000, clkfreq) 'get delta in microseconds
send(12, "Elapsed time during printing was ", dec(t), " microseconds.")
PRI dec(value) | flag, place, digit
flag~
place := 1_000_000_000
repeat
if flag ||= (digit := value / place // 10) or place == 1
send("0" + digit)
if lookdown(place : 1_000_000_000, 1_000_000, 1_000)
send(",")
while place /= 10
DAT
text file "VGA_640x480_text_80x40_driver.txt"
textend
Where is the clock being set in these 1080p examples? I'm not seeing it...
Never mind, I see now that I'm supposed to use "vga_text_demo.spin2" as the top file.
The 1080p examples don't work for me.
I think it's because, despite being called from a file that starts with "VGA", it is not actually VGA.
Looks like its actually component video...
The first example, "VGA_640x480...", does work though.
Comments
I don't know. It's easy for us to get PropellerTool running, though.
I expected about 0% chance of it working...
But, I'm giving it a go...
So far:
1. Had to fix "integer not allowed in floating-point expressions" issue
2. Appears to want () after Pub method names, even if no parameters
3. Got error on "add #read_1,#1". FastSpin allowed that first #, even though it is wrong...
4. Methods with no arguments need () after name to call
5. It doesn't like the @ in this return (gives error: expected end of line):
PUB GetTiles() 'return address to tile pointer array return @TilesRayman, I just looked into this. If you want a method to return some value(s), you need to put ': resultname{, result2name,...}' after the parameters declaration. So, there can only be return values if they are specified in the method declaration.
PUB GetTiles() : ptr 'return address to tile pointer array return @TilesMethods can return 0 to 15 values.
PUB GetTiles():pTiles28934|i23432 'return address to tile pointer array i23432:=@Tiles return i23432But, it seems that local variables have to be globally unique?
it won't work with just plain "i" or "pTiles"
Local variables need to be distinguishable from globals.
It sounds like you've already used 'i' and 'pTiles' globally. Is that the case?
The problem I have is that there is an "i" defined in an assembly DAT block.
FastSpin doesn't seem to mind this, but Spin1 and Spin2 won't have it.
PUB CreateP1Colors():i,j,k,l,m,r,g,b 'Create P2 version of the P1 colors from the P1 VGA demo 'Need to create 24-bit colors from the 6-bit color P1 code 'When stored at proper place in palette array, will be compatible with P1 text printing style repeat j from 0 to 15 step 2I guess this is defining several return variables that aren't actually being used to return anything...
FastSpin let me get away with this. We'll see what Spin2 does soon...
> Rayman wrote: »
>
> Ok, I got past that with this: PUB GetTiles():pTiles28934|i23432 'return address to tile pointer array i23432:=@Tiles return i23432
>
>
> But, it seems that local variables have to be globally unique?
> it won't work with just plain "i" or "pTiles"
>
>
>
>
> Local variables need to be distinguishable from globals.
>
> It sounds like you've already used 'i' and 'pTiles' globally. Is that the case?
Yeah that's not a practical restriction, Chip.
Maybe prefix or suffix the variables internally, or have an additional scope byte that affects the hash?
But in dat should/might be ok?
It’s fine when code is small...
But with big code it is nice to have local variables be independent .
Especially when combining code from separate files into one...
Be more like Spin1 or C++
As in, if I use an OBEX object, will my global vars "collide" with it's locals causing it (the OBEX object) to fail to compile in the context of my program?
You'd at least want to be sure that permanent symbols weren't being redefined, like REPEAT, or something.
> I prefer to not allow local variables with the same names as global, as long as that doesn't apply across external objects you use (OBJ section).
> As in, if I use an OBEX object, will my global vars "collide" with it's locals causing it (the OBEX object) to fail to compile in the context of my program?
Object boundaries keep problems like that from happening.
Or maybe if constants in main file scoped to objects too
I thought that was the case. Just wasn't sure if it had changed with Spin2, due to some other change.
If it's working the same as Spin1, then I say don't change it.
If you do allow locals to have the same names as globals, then it should at the very least issue a warning, because it's likely to be a bug (or at the very least bad design).
I could resolve this conflict by moving this dat section assembly code to a seperate file.
But then, I face the challenge of passing all the constants it needs as variables... very tedious
Just seems like extra work for no reason
I like to use i,j,k,x,y everywhere
The reason for the "more work" is to make your code less likely to have bugs and easier to read by others.
You can still use i,j,k,x,y everywhere except as globals.
I think having the same names everywhere makes your code harder to read. Like if you have a variable "i" in global space AND in several local spaces, then how do you know what's what? A functions that has a local named "i" won't be able to access the global named "i" unless Chip adds yet another feature to allow you to prefix variable accesses with a "global scope" indicator. It's all just making it more of a mess.
How did you deal with this in Spin1?
Those single-letter variables are going to be used only within methods, I'd think. Why give global VARs such non-descriptive names when they won't meaningfully communicate ideas among methods?
https://drive.google.com/file/d/1HWnhswX2fd3W9H1gYSFqNeWToBMO7N7T/view?usp=sharing
I made a decimal printing routine that prints commas, too, in the VGA demo. There are two drivers now, one for 640x480 and another for 1280x1024, which provides 160x85 characters.
Here is the VGA demo source code. You can see how SEND() can be used just like a PRINT in BASIC:
CON _clkfreq = 250_000_000 OBJ vga : "VGA_640x480_text_80x40_driver" '_clkfreq >= 50MHz ' vga : "VGA_1280x1024_text_160x85_driver" '_clkfreq >= 216MHz PUB go() | i, t vga.start(8) 'start vga send := @vga.print 'set send pointer send(4, $004040, 5, $00FFFF) 'cyan on dark cyan t := getct 'capture time i := @text 'print file repeat @textend-i send(byte[i++]) i := getct 'capture time t := muldiv64(i - t, 1_000_000, clkfreq) 'get delta in microseconds send(12, "Elapsed time during printing was ", dec(t), " microseconds.") PRI dec(value) | flag, place, digit flag~ place := 1_000_000_000 repeat if flag ||= (digit := value / place // 10) or place == 1 send("0" + digit) if lookdown(place : 1_000_000_000, 1_000_000, 1_000) send(",") while place /= 10 DAT text file "VGA_640x480_text_80x40_driver.txt" textendHere is 1080p HDTV in portrait mode - 135 columns by 160 rows of 8x12 font using 3-pin component signalling:
The photo doesn't do it justice. The color is dingy and its blurry. On my desk here, it looks really nice.
Never mind, I see now that I'm supposed to use "vga_text_demo.spin2" as the top file.
The 1080p examples don't work for me.
I think it's because, despite being called from a file that starts with "VGA", it is not actually VGA.
Looks like its actually component video...
The first example, "VGA_640x480...", does work though.
Looks like it assumes "Long" if nothing is specified?
Wouldn't that be better with commas?