Also Eric, I ran int a problem with use of "res" too in FASTSPIN. For the code snippet below P2ASM worked okay and allowed me to pad out to 64 instructions, but it was no go in FASTSPIN. I'd like this to work otherwise I need to compute a hard coded pad value which changes as I change the code, unless there is another common way that works.
Sorry, that was an oversight -- I didn't add the special code to handle $ to the RES directive, although it was supported for ORG. It's fixed in github now and will be in the next release.
In the meantime you could probably work around it by doing something like "ORG font + 64" instead of "RES 64 - ($ - font)".
When using FlexGUI 4.0.4-beta, under Win10 and coding in BASIC for a P2-EVAL rev B board:
@ersmith It appears the FlexBASIC clkfreq() function is misbehaving. The code snipped shown in the manual won't compile. This doesn't work:
current_freq = clkfreq
print current_freq
The code above throws an "error: incompatible types in assignment". The code below returns a really (really) big integer that clearly isn't the clock freq:
But if you call CLKFREQ as if it were a function, the error is avoided but the return value is always zero:
current_freq = clkfreq()
print current_freq
On a different subject, someone (I don't remember who, or in what thread) recently suggested adding stand-alone code snippets to the FlexBASIC docs. If I generated and tested a bunch of "cut-n-copy" snippets, would this be something you'd consider putting in the manual? Or maybe I need to generate a separate document to be included in the distro? Your thoughts would be appreciated.
When using FlexGUI 4.0.4-beta, under Win10 and coding in BASIC for a P2-EVAL rev B board:
@ersmith It appears the FlexBASIC clkfreq() function is misbehaving. The code snipped shown in the manual won't compile.
Oops, yes, it certainly is misbehaving. I've changed it to go back to the old behavior. Long term it would be nice to get away from having a built-in variable for clkfreq, since it should only be changed via the clkset() function, but for now it's a variable again. Thanks for the bug report!
On a different subject, someone (I don't remember who, or in what thread) recently suggested adding stand-alone code snippets to the FlexBASIC docs. If I generated and tested a bunch of "cut-n-copy" snippets, would this be something you'd consider putting in the manual? Or maybe I need to generate a separate document to be included in the distro? Your thoughts would be appreciated.
I'm always happy to get contributions for the FlexGUI code and docs. If there are appropriate places to put the code snippets in the manual, we can certainly do that, or perhaps we could put them in an appendix or stand-alone document.
When using FlexGUI 4.0.4 under Win10 and coding in BASIC for a P2-EVAL rev B board:
@ersmith Okay... FlexGUI is looking better and better!
With reference to the earlier bug, I have some interesting results to report. This code now compiles fine, but returns "0" all the time:
print clkfreq
But if you go chase it a bit, it turns-out that CLKFREQ is actually working... its just that FlexBASIC didnt set the CLKFREQ variable to a proper default clock value. So it just returns "0". By manually setting the clock frequency we can prove this, as this code shows:
clkset(0x015166F4, 350_000_000) ' 350 MHz PLL
_setbaud(230400) ' keep our USB connection happy after the clock speed change
print clkfreq
This code prints "350000000", just as it should.
So it appears that FlexBASIC needs to initialize CLKFREQ to the actual clock value it is using. (BTW: What is the default clock speed set by Flex? 80 mhz? 160 mhz?)
ersmith,
After exec'ing "git pull" in a spin2cpp repository directory, running make and then launching (in the build directory) fastspin, it returns:
% fastspin
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
Version 4.0.5-beta-cac4de16 Compiled on: Dec 1 2019
usage: fastspin [options] filename.spin | filename.bas
After exec'ing "git pull" & "git submodule update" in a flexgui repository directory, running make and then launching the built fastspin, it returns:
~/source/flexgui/spin2cpp/build% ./fastspin
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
Version 4.0.4-beta-5bec2198 Compiled on: Dec 1 2019
usage: ./fastspin [options] filename.spin | filename.bas
I assumed that "git submodule update" would grab the latest spin2cpp & fastspin sources, no? Note: I always exec "make clean" before building any projects after git updates to make sure they build with the current sources... Is there another git command that will ensure the latest sources get inside flexgui?
After exec'ing "git pull" & "git submodule update" in a flexgui repository directory, running make and then launching the built fastspin, it returns:
~/source/flexgui/spin2cpp/build% ./fastspin
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
Version 4.0.4-beta-5bec2198 Compiled on: Dec 1 2019
usage: ./fastspin [options] filename.spin | filename.bas
I assumed that "git submodule update" would grab the latest spin2cpp & fastspin sources, no? Note: I always exec "make clean" before building any projects after git updates to make sure they build with the current sources... Is there another git command that will ensure the latest sources get inside flexgui?
No, that's an interesting feature of git -- the submodules refer to a specific version, so "git pull" and/or "git submodule update" at the top level will pull that particular version. Which is sometimes what you want (it guarantees that all the pieces work together) but is sometimes surprising.
To get the latest fastspin/spin2gui from inside the flexgui tree, cd to the spin2cpp subdirectory and do "git pull" there. That should pull the latest version, if I remember correctly. If not, you can do "git checkout master" inside the spin2cpp subdirectory.
To get the latest fastspin/spin2gui from inside the flexgui tree, cd to the spin2cpp subdirectory and do "git pull" there. That should pull the latest version, if I remember correctly. If not, you can do "git checkout master" inside the spin2cpp subdirectory.
Running only "git pull" in those directories almost works...
~/source/flexgui/loadp2% git pull
remote: Enumerating objects: 19, done.
remote: Counting objects: 100% (19/19), done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 17 (delta 10), reused 17 (delta 10), pack-reused 0
Unpacking objects: 100% (17/17), done.
From https://github.com/totalspectrum/loadp2
b94d6c9..e66f467 master -> origin/master
You are not currently on a branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull <remote> <branch>
But, running "git checkout master" first, gets you closer:
~/source/flexgui/loadp2% git checkout master
Previous HEAD position was b94d6c9 Checked in MainLoader*.h to make bootstrapping easier
Switched to branch 'master'
Your branch is behind 'origin/master' by 7 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
I am having an issue with the port definition when trying to program a Prop1 on a Windows 10 machine using Flexgui_4.0.3. See attached file for screen shot. The Prop1 is on comport 15. The PropTool is able to access it on COM15. What am I doing wrong?
@TrapperBob : is it possible some other program is using the serial port and preventing PropLoader from accessing it? Otherwise I'm not sure what could be going on; I have a pretty similar setup, although it is COM7 instead of COM15.
Another thing you could try is to launch proploader from a command line and see if it accepts "-p COM15" instead of "-p \\.\COM15, that is try:
I checked and no other device is using the port. I was able to launch proploader directly using the -p COM15 syntax from cmdline without the backslash escapes as when it is called by the gui ?
I checked and no other device is using the port. I was able to launch proploader directly using the -p COM15 syntax from cmdline without the backslash escapes as when it is called by the gui ?
Huh, that's very strange. I have tried several combinations of backslashes on the command line and they all seem to work for COM7, including the original one that the GUI sends. If you manually type in the command with -p \\.\COM15 or -p \\\\.\\COM15 do either of those work?
I changed to com2 and tried from the gui. It fails using the syntax that the gui specifies \\.\COM2.
I can successfully from the cmdline use either -p COM2 , -p \\\\.\\COM2 or -p \\.\com2 . The same holds true for the original COM15.
I tried on a different Windows 10 machine and the gui worked just fine.
I also truied running flexgui as admin without any difference in operation. I am not sure what is going on on this particular PC. It is my PC at work. I will continue to "fiddle" with it. More ideas are welcome.
I changed to com2 and tried from the gui. It fails using the syntax that the gui specifies \\.\COM2.
I can successfully from the cmdline use either -p COM2 , -p \\\\.\\COM2 or -p \\.\com2 . The same holds true for the original COM15.
Wait, so the lower case version of the GUI syntax worked, but the upper case one failed? That's just weird.
I tried on a different Windows 10 machine and the gui worked just fine.
I don't know what to suggest, it also works fine on my Windows 10 machine here.
You can always use Commands > Configure Commands... to change the command line that the GUI will use, so you could hard code the port there. To do that, replace the %P string in the run command with "-p COM2" or whatever is appropriate.
I have harcoded it as suggested for now. I did not mean to imply that case had anything to do with it. It does NOT seem to. (com2 vs COM2).
What I have found is that the syntax that the %P in the config file resolves to when execute by flexgui is -p\\.\COM2 and this form does not seem to work when it is the command presented by flexgui. I need to verify on my computer at home if this resolves to //./COMx or ////.//COMx, I do not remeber now.
Thanks for your help!
I got an interesting error while converting this Spin1 driver to Spin2...
Says a bunch of labels are "not on lonword boundary".
I think this is due to my use of a byte jump table.
This kind of jump table is used a lot with P1 ASM to save instructions....
I'm sure there is something better for P2.
However, I think the compiler could be made to accommodate this...
BTW: I sometimes use a word jump table instead.
Just mentioning it in case it's something you want to fix (or not).
Something else...
This commented out section of code should be ignored, but gives a "unexpected end of line, expecting indentation" error...
I've put it into the attached.
The problem is that on P2 instructions and the "long" pseudo-instruction do not automatically align to a longword boundary. So in:
and t2,#$FF
jmp t2 'jump to command
jumps byte 0 '0
byte CaptureFrame_ '1
DummyOp_
NotUsed_ jmp #loop
Everything after "DummyOp_" is no longer long aligned on P2 (it is on P1 because of the automatic alignment). So the compiler error is legit in this case. You can fix it by inserting "alignl" after your jump table to resume long alignment.
BTW there's also a warning from the new fastspin:
FLIR_Driver3a.spin2:254: warning: Second operand is a constant used without #; is this correct? If so, you may suppress this warning by putting +0 after the operand
In this case it's OK because the instruction is "mov t2, 0" and the source is actually set by a "sets" earlier. Still, you might want to write "mov t2, 0-0" to get rid of the warning and also to make it clearer to the reader that the source is programmed by an earlier sets.
Yes, I understand the alignment.
Was merely commenting that Spin1 allowed this and Chip's Spin2 probably will too (?)...
I wouldn't be so sure. Have you tried it in PNut? I think @cgracey intended that P2 instructions do not have to be long aligned in HUB memory, so mixing byte directives and instructions may be problematic if you're intending to load them into COG memory. On P1 it was never an issue because instructions automatically became long aligned.
Under ORG mode (but not ORGH mode), any PASM instruction automatically bumps to the next long-aligned cog address (not hub address). When I wrote that code yesterday, I realized that we need maybe a special directive or BYTE/WORD version (BYTECOG/WORDCOG?) to pad to the next long-aligned cog address after its data. Or, what if BYYE/WORD under ORG mode just padded to the next long automatically?
Under ORG mode (but not ORGH mode), any PASM instruction automatically bumps to the next long-aligned cog address (not hub address).
Ah, OK. I had it never bumping the address (so acting like ORGH mode all the time). I'll fix that in the next version of fastspin.
When I wrote that code yesterday, I realized that we need maybe a special directive or BYTE/WORD version (BYTECOG/WORDCOG?) to pad to the next long-aligned cog address after its data. Or, what if BYYE/WORD under ORG mode just padded to the next long automatically?
I don't think we'd want BYTE/WORD padding automatically in ORG mode, because there might be cases where you really want to put bytes in COG memory (for use by getbyte, for example) without any padding. I think this is one of those situations where people are going to have to be careful and/or use explicit "alignl" if they want padding.
It might make sense for LONG to automatically align itself in ORG mode though, if it doesn't already (does it?)
for data in Hub we already have alignl/w if needed so that is fine.
for Cog images in Hub we already have them aligned at long and in the COG code instructions need to get automatically padded to long boundaries, everything else could not run.
for Data in a Cog I see not really a need to have a directive like wordcog, labels in COG/LUT are always long aligned, so what should it do?
Something else...
This commented out section of code should be ignored, but gives a "unexpected end of line, expecting indentation" error...
I've put it into the attached.
That's an interesting bug, nice catch. The bug would happen if a REPEAT (or similar instruction needing indentation after it to indicate a block) was the last instruction in the last function in the file, and everything after it was either blank or {} comments. I'll fix that in the next version, but for now you can work around it by putting a RETURN after the REPEAT. The RETURN will be optimized away (since it can never be reached) and is harmless as the last instruction in a function.
P.S. Could someone explain the use of a dot before some of the labels ? ".wait", ".loop", ".done"
It's to indicate a temporary label that only lasts until the next regular label. In P1 PASM that was indicated with a colon (":wait", ":loop", ":done" etc.) but in P2 PASM it's a dot.
@ersmith , Does fastspin allow the @.endloop type of addressing with REP? I vaguely recall I had trouble with this when porting over to use fastspin instead from P2ASM and I think I needed to change my labels to get rid of the period for my rep loop addressing to work.
eg. try this...
REP @.endloop, #4
ADD A, #1 ' some loop
.endloop
Seems to work for me.
Well this code compiles okay...
p4 if_nz rep @endnormal, #COLS '2760 clocks for 80 normal wide
skipf a 'skip 2 of the next 5 instructions
xor a, #%11110 'flip skip sequence for next time
rdlut d, pb 'read pair of characters/colours
getword c, d, #1 'select first word in long (skipf)
getword c, d, #0 'select second word in long (skipf)
sub pb, #1 'decrement LUT read index (skipf)
getbyte b, c, #0 'extract font offset for char
altgb b, #font 'determine font lookup address
getbyte pixels, 0-0, #0 'get font for character's scanline
testflash bitl c, #15 wcz 'test (and clear) flashing bit
flash if_c and pixels, #$ff 'make it all background if flashing
movbyts c, #%01010101 'colours becomes BF_BF_BF_BF
mov b, c 'grab a copy for muxing step next
rol b, #4 'b becomes FB_FB_FB_FB
setq ##$F0FF000F 'mux mask adjusts fg and bg colours
muxq c, b 'c becomes FF_FB_BF_BB
testb modedata, #10 wz 'repeat columns test, z was trashed
endnormal 'end rep 2 instructions early (skipf)
if_nz movbyts c, pixels 'select pixel colours for char
But this code below with the dot in front of the label gives this error on the rep line, seems to ignore the dot in front of the symbol.
Version 4.0.4-beta- Compiled on: Nov 16 2019
/Users/roger/Downloads/flexgui-4.0.3/samples/p2videodrv.spin2:1035: error: Unknown symbol p4:endnormal
/Users/roger/Downloads/flexgui-4.0.3/samples/p2videodrv.spin2:1035: error: Destination operand too big for rep
p2videodrv.spin2
p4 if_nz rep @.endnormal, #COLS '2760 clocks for 80 normal wide
skipf a 'skip 2 of the next 5 instructions
xor a, #%11110 'flip skip sequence for next time
rdlut d, pb 'read pair of characters/colours
getword c, d, #1 'select first word in long (skipf)
getword c, d, #0 'select second word in long (skipf)
sub pb, #1 'decrement LUT read index (skipf)
getbyte b, c, #0 'extract font offset for char
altgb b, #font 'determine font lookup address
getbyte pixels, 0-0, #0 'get font for character's scanline
testflash bitl c, #15 wcz 'test (and clear) flashing bit
flash if_c and pixels, #$ff 'make it all background if flashing
movbyts c, #%01010101 'colours becomes BF_BF_BF_BF
mov b, c 'grab a copy for muxing step next
rol b, #4 'b becomes FB_FB_FB_FB
setq ##$F0FF000F 'mux mask adjusts fg and bg colours
muxq c, b 'c becomes FF_FB_BF_BB
testb modedata, #10 wz 'repeat columns test, z was trashed
.endnormal 'end rep 2 instructions early (skipf)
if_nz movbyts c, pixels 'select pixel colours for char
Comments
Sorry, that was an oversight -- I didn't add the special code to handle $ to the RES directive, although it was supported for ORG. It's fixed in github now and will be in the next release.
In the meantime you could probably work around it by doing something like "ORG font + 64" instead of "RES 64 - ($ - font)".
@ersmith It appears the FlexBASIC clkfreq() function is misbehaving. The code snipped shown in the manual won't compile. This doesn't work: The code above throws an "error: incompatible types in assignment". The code below returns a really (really) big integer that clearly isn't the clock freq: But if you call CLKFREQ as if it were a function, the error is avoided but the return value is always zero:
On a different subject, someone (I don't remember who, or in what thread) recently suggested adding stand-alone code snippets to the FlexBASIC docs. If I generated and tested a bunch of "cut-n-copy" snippets, would this be something you'd consider putting in the manual? Or maybe I need to generate a separate document to be included in the distro? Your thoughts would be appreciated.
I'm always happy to get contributions for the FlexGUI code and docs. If there are appropriate places to put the code snippets in the manual, we can certainly do that, or perhaps we could put them in an appendix or stand-alone document.
Thanks!
Eric
@ersmith Okay... FlexGUI is looking better and better!
With reference to the earlier bug, I have some interesting results to report. This code now compiles fine, but returns "0" all the time: But if you go chase it a bit, it turns-out that CLKFREQ is actually working... its just that FlexBASIC didnt set the CLKFREQ variable to a proper default clock value. So it just returns "0". By manually setting the clock frequency we can prove this, as this code shows: This code prints "350000000", just as it should.
So it appears that FlexBASIC needs to initialize CLKFREQ to the actual clock value it is using. (BTW: What is the default clock speed set by Flex? 80 mhz? 160 mhz?)
If you only do "print clkfreq" then yes, it will print 0 (it evaluates clkfreq before any I/O, so the clock has not been set yet). If however you do: then it should print 160000000.
After exec'ing "git pull" in a spin2cpp repository directory, running make and then launching (in the build directory) fastspin, it returns:
After exec'ing "git pull" & "git submodule update" in a flexgui repository directory, running make and then launching the built fastspin, it returns:
I assumed that "git submodule update" would grab the latest spin2cpp & fastspin sources, no? Note: I always exec "make clean" before building any projects after git updates to make sure they build with the current sources... Is there another git command that will ensure the latest sources get inside flexgui?
dgately
No, that's an interesting feature of git -- the submodules refer to a specific version, so "git pull" and/or "git submodule update" at the top level will pull that particular version. Which is sometimes what you want (it guarantees that all the pieces work together) but is sometimes surprising.
To get the latest fastspin/spin2gui from inside the flexgui tree, cd to the spin2cpp subdirectory and do "git pull" there. That should pull the latest version, if I remember correctly. If not, you can do "git checkout master" inside the spin2cpp subdirectory.
~/source/flexgui/loadp2% git pull remote: Enumerating objects: 19, done. remote: Counting objects: 100% (19/19), done. remote: Compressing objects: 100% (7/7), done. remote: Total 17 (delta 10), reused 17 (delta 10), pack-reused 0 Unpacking objects: 100% (17/17), done. From https://github.com/totalspectrum/loadp2 b94d6c9..e66f467 master -> origin/master You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull <remote> <branch>But, running "git checkout master" first, gets you closer: Then "git pull" responds with success!Thank you!
dgately
Another thing you could try is to launch proploader from a command line and see if it accepts "-p COM15" instead of "-p \\.\COM15, that is try:
I checked and no other device is using the port. I was able to launch proploader directly using the -p COM15 syntax from cmdline without the backslash escapes as when it is called by the gui ?
Huh, that's very strange. I have tried several combinations of backslashes on the command line and they all seem to work for COM7, including the original one that the GUI sends. If you manually type in the command with -p \\.\COM15 or -p \\\\.\\COM15 do either of those work?
The first time, it tried the wrong serial port...
Maybe look in device manager to see which com port it is actually on?
Thanks for suggestions!
I changed to com2 and tried from the gui. It fails using the syntax that the gui specifies \\.\COM2.
I can successfully from the cmdline use either -p COM2 , -p \\\\.\\COM2 or -p \\.\com2 . The same holds true for the original COM15.
I tried on a different Windows 10 machine and the gui worked just fine.
I also truied running flexgui as admin without any difference in operation. I am not sure what is going on on this particular PC. It is my PC at work. I will continue to "fiddle" with it. More ideas are welcome.
I don't know what to suggest, it also works fine on my Windows 10 machine here.
You can always use Commands > Configure Commands... to change the command line that the GUI will use, so you could hard code the port there. To do that, replace the %P string in the run command with "-p COM2" or whatever is appropriate.
FlexGui must be using some external dll or something that is different on that pc...
I have harcoded it as suggested for now. I did not mean to imply that case had anything to do with it. It does NOT seem to. (com2 vs COM2).
What I have found is that the syntax that the %P in the config file resolves to when execute by flexgui is -p\\.\COM2 and this form does not seem to work when it is the command presented by flexgui. I need to verify on my computer at home if this resolves to //./COMx or ////.//COMx, I do not remeber now.
Thanks for your help!
Says a bunch of labels are "not on lonword boundary".
I think this is due to my use of a byte jump table.
This kind of jump table is used a lot with P1 ASM to save instructions....
I'm sure there is something better for P2.
However, I think the compiler could be made to accommodate this...
BTW: I sometimes use a word jump table instead.
Just mentioning it in case it's something you want to fix (or not).
This commented out section of code should be ignored, but gives a "unexpected end of line, expecting indentation" error...
I've put it into the attached.
and t2,#$FF jmp t2 'jump to command jumps byte 0 '0 byte CaptureFrame_ '1 DummyOp_ NotUsed_ jmp #loopEverything after "DummyOp_" is no longer long aligned on P2 (it is on P1 because of the automatic alignment). So the compiler error is legit in this case. You can fix it by inserting "alignl" after your jump table to resume long alignment.
BTW there's also a warning from the new fastspin: In this case it's OK because the instruction is "mov t2, 0" and the source is actually set by a "sets" earlier. Still, you might want to write "mov t2, 0-0" to get rid of the warning and also to make it clearer to the reader that the source is programmed by an earlier sets.
Was merely commenting that Spin1 allowed this and Chip's Spin2 probably will too (?)...
I wouldn't be so sure. Have you tried it in PNut? I think @cgracey intended that P2 instructions do not have to be long aligned in HUB memory, so mixing byte directives and instructions may be problematic if you're intending to load them into COG memory. On P1 it was never an issue because instructions automatically became long aligned.
Chip, am I wrong about this?
I don't think we'd want BYTE/WORD padding automatically in ORG mode, because there might be cases where you really want to put bytes in COG memory (for use by getbyte, for example) without any padding. I think this is one of those situations where people are going to have to be careful and/or use explicit "alignl" if they want padding.
It might make sense for LONG to automatically align itself in ORG mode though, if it doesn't already (does it?)
for Cog images in Hub we already have them aligned at long and in the COG code instructions need to get automatically padded to long boundaries, everything else could not run.
for Data in a Cog I see not really a need to have a directive like wordcog, labels in COG/LUT are always long aligned, so what should it do?
curious,
Mike
That's an interesting bug, nice catch. The bug would happen if a REPEAT (or similar instruction needing indentation after it to indicate a block) was the last instruction in the last function in the file, and everything after it was either blank or {} comments. I'll fix that in the next version, but for now you can work around it by putting a RETURN after the REPEAT. The RETURN will be optimized away (since it can never be reached) and is harmless as the last instruction in a function.
Thanks for the bug report!
Well this code compiles okay...
p4 if_nz rep @endnormal, #COLS '2760 clocks for 80 normal wide skipf a 'skip 2 of the next 5 instructions xor a, #%11110 'flip skip sequence for next time rdlut d, pb 'read pair of characters/colours getword c, d, #1 'select first word in long (skipf) getword c, d, #0 'select second word in long (skipf) sub pb, #1 'decrement LUT read index (skipf) getbyte b, c, #0 'extract font offset for char altgb b, #font 'determine font lookup address getbyte pixels, 0-0, #0 'get font for character's scanline testflash bitl c, #15 wcz 'test (and clear) flashing bit flash if_c and pixels, #$ff 'make it all background if flashing movbyts c, #%01010101 'colours becomes BF_BF_BF_BF mov b, c 'grab a copy for muxing step next rol b, #4 'b becomes FB_FB_FB_FB setq ##$F0FF000F 'mux mask adjusts fg and bg colours muxq c, b 'c becomes FF_FB_BF_BB testb modedata, #10 wz 'repeat columns test, z was trashed endnormal 'end rep 2 instructions early (skipf) if_nz movbyts c, pixels 'select pixel colours for charBut this code below with the dot in front of the label gives this error on the rep line, seems to ignore the dot in front of the symbol.
Version 4.0.4-beta- Compiled on: Nov 16 2019
/Users/roger/Downloads/flexgui-4.0.3/samples/p2videodrv.spin2:1035: error: Unknown symbol p4:endnormal
/Users/roger/Downloads/flexgui-4.0.3/samples/p2videodrv.spin2:1035: error: Destination operand too big for rep
p2videodrv.spin2
p4 if_nz rep @.endnormal, #COLS '2760 clocks for 80 normal wide skipf a 'skip 2 of the next 5 instructions xor a, #%11110 'flip skip sequence for next time rdlut d, pb 'read pair of characters/colours getword c, d, #1 'select first word in long (skipf) getword c, d, #0 'select second word in long (skipf) sub pb, #1 'decrement LUT read index (skipf) getbyte b, c, #0 'extract font offset for char altgb b, #font 'determine font lookup address getbyte pixels, 0-0, #0 'get font for character's scanline testflash bitl c, #15 wcz 'test (and clear) flashing bit flash if_c and pixels, #$ff 'make it all background if flashing movbyts c, #%01010101 'colours becomes BF_BF_BF_BF mov b, c 'grab a copy for muxing step next rol b, #4 'b becomes FB_FB_FB_FB setq ##$F0FF000F 'mux mask adjusts fg and bg colours muxq c, b 'c becomes FF_FB_BF_BB testb modedata, #10 wz 'repeat columns test, z was trashed .endnormal 'end rep 2 instructions early (skipf) if_nz movbyts c, pixels 'select pixel colours for char