@Rayman said:
Think the FlexProp VGA demo can also work at 720p, see attached.
Doesn't like 1080p though...
A more recent version of the VGA demo is at https://github.com/totalspectrum/p2_vga_text . I should update the one in FlexProp I guess, but the p2_vga_text one is larger and has more stuff (including timings for 1280x1024 and some tools for converting fonts).
FlexProp version 6.9.4 is available now from github and from my Patreon page. It has some significant bug fixes, particularly for Windows (where an uninitialized variable could cause mysterious and apparently random error messages).
FlexProp has been updated to 6.9.9. Since the last release there are quite a few compiler fixes. The changelog looks like:
Version 6.9.9
- Fixed `--compress` flag on Windows
- Added `--zip` flag to flexcc (previously it was just in flexspin)
- Improved handling of file names in .zip output
- Improved error message for sizeof(x) when x is undefined
Version 6.9.8
- Fix `#foo+CONST` calculation
- Fix a problem with pointer calculations in structs
Version 6.9.7
- Fixed infinite loop when CORDIC and Read/Write optimizations fight
- Fixed potential crash when compiling empty functions
- Allow `#foo+CONST` for inline assembly when `foo` is a HUB label
Version 6.9.6
- Added a peephole for some address calculations (as suggested by Evan)
- Fixed some built-in functions in spin2cpp
Version 6.9.5
- Fixed immediate ranges for load/store, and made out of range immediates an error (thanks to Ada)
- Fixed an inappropriate memory forwarding with WZ (also thanks to Ada)
- Made sure arrays of bytes are put into memory, even if inside structs or unions
The binary releases are available on GitHub and on my Patreon page; links are in my signature.
@ersmith Seem to be having an issue with the shell.c example...
When copying this python file from /host to /sd, it doesn't copy the whole file.
Any idea what might cause that?
@Rayman thanks for the bug report. I tried copying that file from host to host, and it worked, so it seems like it's some problem in the FAT file system. Most likely it's in the interface between FAT and the stdio library. Your work-around seems like a good one for now.
Ah, I think I found the bug -- because FATFS provides a flush function, we're not calling the default flush which fputc() relies on. The fix is to insert a call
__default_flush(fil);
at the beginning of the v_flush function in include/filesys/fatfs/fatfs.cc (before any of the #if or other statements)
@ersmith,
I am just getting started with FlexProp and I am getting the follwing error when compiling with FlexProp but not PNUT. What am I not understanding?
Hmm... Wonder if it's one of those new things that one has to specify the Spin2 version to use with PropTool and FlexProp?
Looks like can fix like this?
It's probably because Flexspin's return codes are passed in registers by default, and that Flexspin is not identifying the referencing for placing tc on the stack instead.
you could probably replace @tc.byte[2] with @tc+2, but you really shouldn't, since that enables locals-on-stack mode (There's -Ospin-relax-memory, but it's not perfect).
Thank you all. I rewrote code as suggested by Rayman and it now compiles in both PNUT and Flexspin. I am somewhat torn as to which tool to use long-term. I am liking each one of them for slightly different reasons. Any input from the community as to what they like/dislike about either tool would be helpful to me as well as maybe to others. I certainly do appreciate the community!
Flexspin compiles to native, so is always going to be faster. It's ability to gobble and share a mix of Spin, Basic and C all together is impressive too. Probably its biggest weakness is not supporting interrupts. Chip has been very careful to ensure the Pnut/Proptool Spin2 VM is interrupt safe.
EDIT: On that note, any "inline" assembly that isn't explicitly coded for interrupt safety will break when subjected to interrupts, on the same cog, under Pnut too. My latest SD card driver is one such case. I wrote it for FlexC and have ported it to Spin2 without consideration for interrupts. However, historically, most drivers have tended to launch their own cog for such activities. Interrupts usually are lone to the code on that cog.
FlexProp 7.0 is available now from the usual places (links in my signature). It supports most of the new Spin2 language features such as structs, pointers, and tasks. The preprocessor in Spin and BASIC is case insensitive by default (as the languages are), and there is a new model for file systems which allows for large files and for easily replacing the underlying device driver (so for example we can now mount a disk image on the host as a FAT file system). There are also some new optimizations (thanks largely to @Wuerfel_21) and many bug fixes.
Something I forgot to mention: there's an Easter egg in the new flexspin compiler; it supports a new, previously unsupported language. I haven't had time to document it, and it's a fairly obscure language that I doubt many users will want to program in. Finding it is left as an exercise for the reader but as a hint files ending in .b are treated as the new language.
(Those who've read the flexspin source code already know what it is, of course...)
bf... A classic esoteric language. Good to have it onboard although programming in it may be hard... However, there is a Game of Life programmed in it.
Edit: the forum doesn't like the code. Look at linusakesson.net and search for game of life.
It can be a very expressive language, since most characters are treated as comments. E.g. code to echo what you type:
This is a very simple program -- it just echos what you type!
[ Most of this text is comment :> other than a few magic
characters, it's all filler. You have to try to
guess which is which :-< ]
Of course without the comments it can get a bit nasty. "Hello world" looks like:
Mostly I implemented it as a toy example in case others want to try adding languages to flexspin. It is fully integrated with the module system, so for example you can do things like have a Spin program use a BF program as an object:
CON clkfreq=180_000_000
OBJ
hello: "hello.b"
ser: "jm_serial"
PUB test()
ser.start(230_400)
send := @ser.tx ' set up output for hello object
hello.program() ' run the (only) function in the bf module
send("All done now!", 13, 10)
There is a problem - standard opening and saving files in Flexprop doesn't support .b. You have to select "all files" - then I opened and compiled 'hello.b'.
If you forgot about this, the saved file will be something.b.spin2
I wonder if I can redirect the output to Basic's print without using Spin...
Edit: No. The bf object can be included and works from a Basic main program, but output goes to the serial terminal while Basic's channel 0 is redirected to the HDMI driver. So I have "test ready" printed by Basic on the monitor connected to a P2 and Hello World on the PC's serial terminal.
How, if possible at all, to simulate Spin's 'send' in Basic?
Edit 2: the main code looks like this:
const _clkfreq = 338688000
const pin=0
dim v as class using "hg010b.spin2"
dim psram as class using "psram.spin2"
dim hello as class using "hello.b"
dim pscog,videocog as ubyte
dim mbox as ulong
pscog=psram.startx(0, 1024, 11, 7)
mbox=psram.getMailbox(0)
videocog=v.start(pin,mbox)
for thecog=0 to 7:psram.setQos(thecog, 80 << 16) :next thecog
psram.setQoS(videocog, $0400f400)
open SendRecvDevice(@v.putchar, nil, nil) as #0
waitms(100)
v.cls(154,147)
print "Test ready"
hello.program
@pik33 Unfortunately the Spin2 SEND and RECV methods are independent of BASIC and C file I/O methods. That's something I'd like to address someday. In theory you should be able to assign the builtin variable __sendptr in BASIC to set the Spin2 SEND function. That may or may not work with BF programs, I haven't really tested BASIC/BF integration (nor is it a high priority ).
Similarly the .b file extension isn't supported in the GUI because I didn't really anticipate many people wanting to write programs in that language...
@ersmith Hoping you might have a suggesting for me...
Trying to send a 128 col x 48 row text screen out to ansi terminal on PC side.
Want to update screen quickly.
On one computer, works with putty and high baud.
But, on another computer, screen is all garbled... Unless a bunch of delays are added
Thinking probably doing this in a bad way:
void TransmitScreen()
{
for (;;)
{//send screen forever
Ansi4* pChar = vga.GetBuffer();
Ansi4* pLastChar = pChar;
printf("\x1B[?25l"); //hide cursor
//printf("\x1B[2J"); //clear screen
_waitms(10);
for (int y = 0; y < rows; y++)
{
char fgcolor = pChar->fgcolor;
char bgcolor = pChar->bgcolor;
printf("\x1B[38;5;%dm", fgcolor); //Set foreground color
printf("\x1B[48;5;%dm", bgcolor); //Set background color
printf("\x1B[%d;%dH", y + 1, 1); //Set to this row, first column
_waitus(100);
for (int x = 0; x < cols; x++)
{
char newchar = pChar->curchar;
char newfg = pChar->fgcolor;
char newbg = pChar->bgcolor;
if (newbg != bgcolor)
{//New background color?
bgcolor = newbg;
printf("\x1B[48;5;%dm", bgcolor); //Set background color
_waitus(100);
}
if ((newfg != fgcolor) && (newchar != ' '))
{//New foreground color and not a space?
fgcolor = newfg;
printf("\x1B[38;5;%dm", fgcolor); //Set background color
_waitus(100);
}
//putchar(newchar);
printf("%c", newchar);
_waitus(100);
//buf[x] = pChar->curchar;
pChar += 1;
}
//printf("\n");
//_waitms(10);
_waitus(100);
}
}
}
@Rayman Some computers may not be able to keep up with high baud transmission; that's probably more a function of the PC than of anything you're doing on the P2 side. You could try reducing the baud rate, or inserting periodic delays (as it looks like you've done).
@ersmith said:
@pik33 Unfortunately the Spin2 SEND and RECV methods are independent of BASIC and C file I/O methods. That's something I'd like to address someday. In theory you should be able to assign the builtin variable __sendptr in BASIC to set the Spin2 SEND function. That may or may not work with BF programs, I haven't really tested BASIC/BF integration (nor is it a high priority ).
Similarly the .b file extension isn't supported in the GUI because I didn't really anticipate many people wanting to write programs in that language...
This:
send=v.putchar
works in Basic and makes the bf code output via the video driver instead of a serial terminal so it seems 'send' function is recognized in Basic too.
Comments
A more recent version of the VGA demo is at https://github.com/totalspectrum/p2_vga_text . I should update the one in FlexProp I guess, but the p2_vga_text one is larger and has more stuff (including timings for 1280x1024 and some tools for converting fonts).
FlexProp version 6.9.4 is available now from github and from my Patreon page. It has some significant bug fixes, particularly for Windows (where an uninitialized variable could cause mysterious and apparently random error messages).
FlexProp has been updated to 6.9.9. Since the last release there are quite a few compiler fixes. The changelog looks like:
The binary releases are available on GitHub and on my Patreon page; links are in my signature.
FlexProp 6.9.10 is now available on GitHub (see my signature for links). This has several fairly significant bug fixes, so it's worth updating.
@ersmith Seem to be having an issue with the shell.c example...
When copying this python file from /host to /sd, it doesn't copy the whole file.
Any idea what might cause that?
Don't know what's up with fputc(), but works when copy is rewritten like this:
char buf[100]; for(;;) { c = fread(buf, 1, 100, inf);// fgetc(inf); if (c == 0) break; fwrite(buf, 1, c, outf); count+=c; if (c < 100) break; }@Rayman thanks for the bug report. I tried copying that file from host to host, and it worked, so it seems like it's some problem in the FAT file system. Most likely it's in the interface between FAT and the stdio library. Your work-around seems like a good one for now.
Ah, I think I found the bug -- because FATFS provides a flush function, we're not calling the default flush which fputc() relies on. The fix is to insert a call
at the beginning of the
v_flushfunction in include/filesys/fatfs/fatfs.cc (before any of the #if or other statements)I'll try to get this fix up to github soon.
Glad you found it. Was trying calling flush and it didn't help. Guess that's why...
@ersmith,
I am just getting started with FlexProp and I am getting the follwing error when compiling with FlexProp but not PNUT. What am I not understanding?
Hmm... Wonder if it's one of those new things that one has to specify the Spin2 version to use with PropTool and FlexProp?
Looks like can fix like this?
It's probably because Flexspin's return codes are passed in registers by default, and that Flexspin is not identifying the referencing for placing
tcon the stack instead.It's kind of amazing that the FlexProp version of Spin2 is compatible as it is with PNUT, when completely different under the hood...
you could probably replace
@tc.byte[2]with@tc+2, but you really shouldn't, since that enables locals-on-stack mode (There's-Ospin-relax-memory, but it's not perfect).Thank you all. I rewrote code as suggested by Rayman and it now compiles in both PNUT and Flexspin. I am somewhat torn as to which tool to use long-term. I am liking each one of them for slightly different reasons. Any input from the community as to what they like/dislike about either tool would be helpful to me as well as maybe to others. I certainly do appreciate the community!
Flexspin compiles to native, so is always going to be faster. It's ability to gobble and share a mix of Spin, Basic and C all together is impressive too. Probably its biggest weakness is not supporting interrupts. Chip has been very careful to ensure the Pnut/Proptool Spin2 VM is interrupt safe.
EDIT: On that note, any "inline" assembly that isn't explicitly coded for interrupt safety will break when subjected to interrupts, on the same cog, under Pnut too. My latest SD card driver is one such case. I wrote it for FlexC and have ported it to Spin2 without consideration for interrupts. However, historically, most drivers have tended to launch their own cog for such activities. Interrupts usually are lone to the code on that cog.
FlexProp 7.0 is available now from the usual places (links in my signature). It supports most of the new Spin2 language features such as structs, pointers, and tasks. The preprocessor in Spin and BASIC is case insensitive by default (as the languages are), and there is a new model for file systems which allows for large files and for easily replacing the underlying device driver (so for example we can now mount a disk image on the host as a FAT file system). There are also some new optimizations (thanks largely to @Wuerfel_21) and many bug fixes.
Something I forgot to mention: there's an Easter egg in the new flexspin compiler; it supports a new, previously unsupported language. I haven't had time to document it, and it's a fairly obscure language that I doubt many users will want to program in. Finding it is left as an exercise for the reader
but as a hint files ending in
.bare treated as the new language.(Those who've read the flexspin source code already know what it is, of course...)
I found the file
bflang.c... Obscure?! I figured that meant it already existed in the wild!I'll be piking out on giving it a spin I'm afraid.
bf... A classic esoteric language. Good to have it onboard although programming in it may be hard... However, there is a Game of Life programmed in it.
Edit: the forum doesn't like the code. Look at linusakesson.net and search for game of life.
It can be a very expressive language, since most characters are treated as comments. E.g. code to echo what you type:
Of course without the comments it can get a bit nasty. "Hello world" looks like:
Mostly I implemented it as a toy example in case others want to try adding languages to flexspin. It is fully integrated with the module system, so for example you can do things like have a Spin program use a BF program as an object:
CON clkfreq=180_000_000 OBJ hello: "hello.b" ser: "jm_serial" PUB test() ser.start(230_400) send := @ser.tx ' set up output for hello object hello.program() ' run the (only) function in the bf module send("All done now!", 13, 10)Bah! I only googled for, and found nothing, .b file suffix.
LOL...The next time someone asks me "So what programming language do you use?"
There is a problem - standard opening and saving files in Flexprop doesn't support .b. You have to select "all files" - then I opened and compiled 'hello.b'.
If you forgot about this, the saved file will be something.b.spin2
I wonder if I can redirect the output to Basic's print without using Spin...
Edit: No. The bf object can be included and works from a Basic main program, but output goes to the serial terminal while Basic's channel 0 is redirected to the HDMI driver. So I have "test ready" printed by Basic on the monitor connected to a P2 and Hello World on the PC's serial terminal.
How, if possible at all, to simulate Spin's 'send' in Basic?
Edit 2: the main code looks like this:
@pik33 Unfortunately the Spin2 SEND and RECV methods are independent of BASIC and C file I/O methods. That's something I'd like to address someday. In theory you should be able to assign the builtin variable
).
__sendptrin BASIC to set the Spin2 SEND function. That may or may not work with BF programs, I haven't really tested BASIC/BF integration (nor is it a high prioritySimilarly the
.bfile extension isn't supported in the GUI because I didn't really anticipate many people wanting to write programs in that language...@ersmith Hoping you might have a suggesting for me...
Trying to send a 128 col x 48 row text screen out to ansi terminal on PC side.
Want to update screen quickly.
On one computer, works with putty and high baud.
But, on another computer, screen is all garbled... Unless a bunch of delays are added
Thinking probably doing this in a bad way:
void TransmitScreen() { for (;;) {//send screen forever Ansi4* pChar = vga.GetBuffer(); Ansi4* pLastChar = pChar; printf("\x1B[?25l"); //hide cursor //printf("\x1B[2J"); //clear screen _waitms(10); for (int y = 0; y < rows; y++) { char fgcolor = pChar->fgcolor; char bgcolor = pChar->bgcolor; printf("\x1B[38;5;%dm", fgcolor); //Set foreground color printf("\x1B[48;5;%dm", bgcolor); //Set background color printf("\x1B[%d;%dH", y + 1, 1); //Set to this row, first column _waitus(100); for (int x = 0; x < cols; x++) { char newchar = pChar->curchar; char newfg = pChar->fgcolor; char newbg = pChar->bgcolor; if (newbg != bgcolor) {//New background color? bgcolor = newbg; printf("\x1B[48;5;%dm", bgcolor); //Set background color _waitus(100); } if ((newfg != fgcolor) && (newchar != ' ')) {//New foreground color and not a space? fgcolor = newfg; printf("\x1B[38;5;%dm", fgcolor); //Set background color _waitus(100); } //putchar(newchar); printf("%c", newchar); _waitus(100); //buf[x] = pChar->curchar; pChar += 1; } //printf("\n"); //_waitms(10); _waitus(100); } } }@Rayman Some computers may not be able to keep up with high baud transmission; that's probably more a function of the PC than of anything you're doing on the P2 side. You could try reducing the baud rate, or inserting periodic delays (as it looks like you've done).
You can always count on bloat to crush the hardware. Take away the large L3 cache on a modern OS and its CPU will grind to a crawl.
Ok, that makes sense. The problem PC is better, but also has a gazillion processes running...
Guess upping the baud rate isn't a real solution then.
Can make a custom viewer program for PC though that can take in the raw buffers and process them.
Have to create that option later...
On the bright side, in this slow mode, it works in the regular terminal window that Flexprop calls. That's nice, even if painfully slow...
This:
works in Basic and makes the bf code output via the video driver instead of a serial terminal so it seems 'send' function is recognized in Basic too.