That sounds interesting. Kyedos can spawn other .bin programs. It can also pass a command line to the next program via a single line text file the previous program writes on the sd card. I wonder if embedded basic could check if that file exists, then run it?
Hmm, we really need batch files here. Then you could send commands like "load a file" then "run a file".
That sounds interesting. Kyedos can spawn other .bin programs. It can also pass a command line to the next program via a single line text file the previous program writes on the sd card. I wonder if embedded basic could check if that file exists, then run it?
Hmm, we really need batch files here. Then you could send commands like "load a file" then "run a file".
Exactly what I am trying to do. Thank you for giving me a good path to follow. Once I ran KyeDOS it really hit me... This is it! Now we need batch files!
I am still trying to learn the command.txt passing of the next file. I can get it to load first file (obviously, as this is built in to KyeDOS), but how to exit first Basic program and load it with a fresh file... that is where I am at. Now, even if command.txt holds a valid file, when I exit basic I go back to prompt (doing reboot from basic). It does not reload file in command.txt. So even if I can (read: learn how to) rewrite file on SD from basic, it exits gracefully to prompt. By design I am sure. But I like corrupting good designs.
I wonder if we could borrow the concept of batch files from CP/M and DOS
Ok, you create a batch file. This is a text file and you could let it end in .BAT. eg MYFILE.BAT
Next you need a batch file processor. CP/M had a program called SUBMIT. We could call it "BATCH"
You type BATCH MYFILE
That then goes and creates a temporary file on the sd card. CP/M creates MYFILE.$$$
Then each time Kyedos either starts, or returns to the command prompt, you add a little bit of code to see if a $$$ file exists. If it does, then read in the file, store the first line, write back the file with the first line removed, then run that first line. If on the last line, then delete the $$$ file.
And as an added plus.... make the next file conditional. Files load in order by default... but can jump to file 7 from file 3 if needed. Of course then the original batch file would have to remain complete, in case you wanted to go back to file 5 next. Maybe a second file... load.txt that contains the number (name) of next file to load. Who knows, might even want to reload same file again (now or later) in some cases, so we would not want to alter the original batch.
Ok, so two parts:
1) BATCH.BIN. If you have the kyedos source you will have the source for TYPE which is a generic prototype for a new program with all the building blocks ready to go, eg disk access, display driver. This would be a very simple program. All it actually does is copies MYFILE.BAT to MYFILE.$$$. So at the kyedos prompt you type
BATCH MYFILE
which saves the entire line "BATCH MYFILE" in COMMAND.TXT, and then runs BATCH.EXE, which can then read back COMMAND.TXT and hence get the string "MYFILE"
2) Modifications to Kyedos. I guess it would be a new PUB just before the command prompt?
BTW you know we have CP/M running on the propeller? And MP/M too.
Ok, so two parts:
1) BATCH.BIN. If you have the kyedos source you will have the source for TYPE which is a generic prototype for a new program with all the building blocks ready to go, eg disk access, display driver. This would be a very simple program. All it actually does is copies MYFILE.BAT to MYFILE.$$$. So at the kyedos prompt you type
BATCH MYFILE
which saves the entire line "BATCH MYFILE" in COMMAND.TXT, and then runs BATCH.EXE, which can then read back COMMAND.TXT and hence get the string "MYFILE"
2) Modifications to Kyedos. I guess it would be a new PUB just before the command prompt?
BTW you know we have CP/M running on the propeller? And MP/M too.
Okay... now I need to look closer at 'Type'. I wasn't sure what it could do (and why I downloaded it), I was too wrapped up in the excitement of SD access and a DOS prompt to play with it yet.
And just an odd thought I can't seem to shake... is it better to wrap KyeDOS around Basic's needs (or any language for that matter)... or Basic around a KyeDOS shell? I know, that sounds obtuse. But it makes sense to me. Of course one of them means a lot more work for Bean.
And I thought by your Avatar CP/M was an Aussie term for Propellor. I stand corrected. (Sorry, couldn't resist)
Okay... I admit, I knew it was there (I read a lot here). But I haven't played with it yet. I guess the time is coming soon. It would be a good way of sorting out needs over just interesting questions. It is amazing what can be done with such a simple, but powerful processor. I have been hung up on the memory model... once that is solved, we will have it running Windows CE.... then with the Prop 2 we can move up to XP and Windows 7. (Skip Vista... please)
"TYPE" is just an example program of how you can take a simple operating system and add more commands by adding new binary programs on an sd card (rather than by adding more code to the OS). Kyedos fills most of the propeller memory anyway so you have to think about other solutions.
Probably easiest to modify kyedos rather than asking Bean to code more. Unless something is impossible.
My avatar is a photo of CP/M running on the propeller, with some ASCII art created from a screen grab of the propeller picture, which originally came from a photo of a propeller chip. There was a bit of image enhancement and scaling done along the way. It was displayed by typing "TYPE PROPART.TXT" from within the CP/M emulation on the propeller.
We have better graphics now. Even movies in color!
If you want to write a batch file processor, I think all the building blocks are in Kyedos. eg, open a file, read lines of text, process them, close the file.
I need to check out Embedded Basic.
I see you are already thinking of conditional lines in batch files. That starts to become a programming language in its own right. It could get quite powerful, because each of the things you run can be entire self contained spin programs, that can do things like modify text files that following spin programs can also read and write.
I guess that leads to some generic Batch instructions. Print a message. Get a keypress, or line of text. Compare with other lines of text. Run one program if a match. That could be half the Basic keywords if you wanted.
It's very interesting to see this ran the 1 to 10,000 loop in ~0.3 Seconds. I used to do this same test on older computers and my Atari 800XL did it in ~ 20 seconds. That machine had a 1.79 MHz processor and was only 8 bits.
My current laptop does it in ~52 micro seconds using VB .Net 2010. Then again its a 3.6GHz 6 core i7 980x with 12 GB of ram. lol
I tried to bring all cores into play and it actually slows down the code. There is an overhead price you pay. It's doesn't payoff until you have a lot of caculations to do. It is very cool when you bring all six cores into play and see the processor really work. :-)
Humanoido,
Sorry I haven't kept this thread up to date.
I have just now updated the program in the first post.
bcolor and fcolor are just "BCOLOR value" and "FCOLOR value". value can be 0 to 15 for the different colors.
Humanoido, Sorry I haven't kept this thread up to date. I have just now updated the program in the first post.
bcolor and fcolor are just "BCOLOR value" and "FCOLOR value". value can be 0 to 15 for the different colors. Bean
Thanks Bean, the colors are working perfect! But... please do not replace the other post version! The color version font is too small, it is impossible to read on small monitors because the tiny font blurs together. It also has a good case of the shakes and shivers. It looks like I must give up the color version.
Humanoido,
Actually there is a version 0.13, but I can't test it until I get home, so I don't want to post untested code.
Version 0.13 can be compiled for 32 columns (still 25 rows) if that will help you.
Here are the other changes in version 0.13 (for the help file)...
' Version 0.13
' Changed POKEB and PEEKB to POKE and PEEK
' Added FREE function (free memory)
' Added SCREEN function (screen address NTSC ONLY)
' Fixed autostart keyboard
' Fixed REM and ' tokenizing text
I have attached the binary for 32 columns if you want to try it (untested).
Humanoido, Actually there is a version 0.13, but I can't test it until I get home, so I don't want to post untested code. Version 0.13 can be compiled for 32 columns (still 25 rows) if that will help you. Here are the other changes in version 0.13 (for the help file)...
' Version 0.13
' Changed POKEB and PEEKB to POKE and PEEK
' Added FREE function (free memory)
' Added SCREEN function (screen address NTSC ONLY)
' Fixed autostart keyboard
' Fixed REM and ' tokenizing text
I have attached the binary for 32 columns if you want to try it (untested). Bean
Bean, I like the binary. Binaries load ok with the Propeller Tool Software, right? Thanks very much. The fonts are a tiny amount bigger and it's enough to just see most characters. A zero and eight look the same but for the most part, it's workable. Let hope the font can be increased to a larger size in a future version. You're right, it's very beta (mentioned commands do not work like FREE etc.) and needs testing but thanks for this excellent preview. I'm really stoked about the way this remarkable little language is unfolding.
I made a version of EmbeddedBasic for SpinSim. The source, binary and a copy of SpinSim.exe are included in the attached ZIP file. This allows EmbeddedBasic to run in a DOS window under Windows. The LOAD and SAVE commands don't work since there is no EEPROM.
BTW, it looks like there is a problem with xPos, yPos and color not being defined if NTSC is not defined.
I used LMM for the SpinSimKeyboard task to slow it down. SpinSim uses a lock to make the system I/O functions cog-safe. I was concerned that a pure PASM keyboard task would lock out the character transmit routine. I should just add a delay loop or waitcnt instead. I copied the code from the SerialKeyboard task, where I had commented out the SERIN command. I uncommented all of the lines without realizing that the case translation was intentially commented out. That can be removed from the SpinSimKeyboard task.
I've never noticed that about the caps-lock before. I use the kbhit() routine, and it must be returning true when the caps-lock is pressed. I'll have to look into that further.
SpinSim's speed depends on the speed of the host computer. It actually runs Spin programs faster than PASM programs, but it works fine for both as long as speed is not an issue.
Dave,
I have merged your additions to the working version of Embedded Basic. All future version will have support for SpinSim.
It was easy to remove the code that converts chars to uppercase.
Is there anyway to do the "LOCATE x,y" function ? How about text colors FCOLOR, BCOLOR, COLOR ?
I would really like to do X,Y addressing and colors in a DOS window, but it seems like this is yet another function that Microsoft has removed. Earlier versions of Windows allowed using an ANSI.SYS file to support the use of the ANSI terminal escape sequence. However, I have been unable to get this to work unders Windows XP, Vista or 7. If anybody knows how to do this please let me know.
Linux command windows do support the ANSI terminal commands, so it would be possible to do this under linux.
BTW, I tried to add file I/O support to the SpinSim version of EmbeddedBasic so that programs could be saved and loaded from progn.bas files. I encountered an error that said that __ELSE_243 was unresolved. Is there a limit on the number of labels that can be generated? It looks like the PropBasic compiler did not generate the __ELSE_243 label.
Dave,
Yes, there is a limit. I have sent new files to BradC for him to compile, but I haven't heard anything back for quite a while.
I'll try to contact him again.
I ran into the issue when doing a bunch of ELSEIFs that were strung together.
Wow, Bean, the PST version is unbelievably fast at 115,200 Baud! I ran my usual benchmark program, the screen flashed, and I was shocked to see numbers in the 100,000 + range in a few seconds. It appears to give a full screen of numbers every second. It just pops on the screen. The PST is big and clear. Is there a way to send this serial information to the TV in giant characters or have a PST in the TV?
10 n=0
20 n=n+1
40 PRINT n;" ";
50 GOTO 20
Also what is the syntax on the peek command? I tried peek x but that didn't work.
I have been doing quite a bit of work on PE-Basic and I have uploaded the latest version.
Be sure to check out the pdf document.
I've included several binary files for different configurations: NTSC, Serial (PST), etc. So you don't need to worry about compiling the PropBasic source if you don't want to.
Comments
Hmm, we really need batch files here. Then you could send commands like "load a file" then "run a file".
Exactly what I am trying to do. Thank you for giving me a good path to follow.
I am still trying to learn the command.txt passing of the next file. I can get it to load first file (obviously, as this is built in to KyeDOS), but how to exit first Basic program and load it with a fresh file... that is where I am at. Now, even if command.txt holds a valid file, when I exit basic I go back to prompt (doing reboot from basic). It does not reload file in command.txt. So even if I can (read: learn how to) rewrite file on SD from basic, it exits gracefully to prompt. By design I am sure. But I like corrupting good designs.
I wonder if we could borrow the concept of batch files from CP/M and DOS
Ok, you create a batch file. This is a text file and you could let it end in .BAT. eg MYFILE.BAT
Next you need a batch file processor. CP/M had a program called SUBMIT. We could call it "BATCH"
You type BATCH MYFILE
That then goes and creates a temporary file on the sd card. CP/M creates MYFILE.$$$
Then each time Kyedos either starts, or returns to the command prompt, you add a little bit of code to see if a $$$ file exists. If it does, then read in the file, store the first line, write back the file with the first line removed, then run that first line. If on the last line, then delete the $$$ file.
How does that sound?
I still have an Apple II+ with a MS CP/M card... and it works!
1) BATCH.BIN. If you have the kyedos source you will have the source for TYPE which is a generic prototype for a new program with all the building blocks ready to go, eg disk access, display driver. This would be a very simple program. All it actually does is copies MYFILE.BAT to MYFILE.$$$. So at the kyedos prompt you type
BATCH MYFILE
which saves the entire line "BATCH MYFILE" in COMMAND.TXT, and then runs BATCH.EXE, which can then read back COMMAND.TXT and hence get the string "MYFILE"
2) Modifications to Kyedos. I guess it would be a new PUB just before the command prompt?
BTW you know we have CP/M running on the propeller? And MP/M too.
Okay... now I need to look closer at 'Type'. I wasn't sure what it could do (and why I downloaded it), I was too wrapped up in the excitement of SD access and a DOS prompt to play with it yet.
And just an odd thought I can't seem to shake... is it better to wrap KyeDOS around Basic's needs (or any language for that matter)... or Basic around a KyeDOS shell? I know, that sounds obtuse. But it makes sense to me. Of course one of them means a lot more work for Bean.
And I thought by your Avatar CP/M was an Aussie term for Propellor. I stand corrected. (Sorry, couldn't resist)
Okay... I admit, I knew it was there (I read a lot here). But I haven't played with it yet. I guess the time is coming soon. It would be a good way of sorting out needs over just interesting questions. It is amazing what can be done with such a simple, but powerful processor. I have been hung up on the memory model... once that is solved, we will have it running Windows CE.... then with the Prop 2 we can move up to XP and Windows 7.
Probably easiest to modify kyedos rather than asking Bean to code more. Unless something is impossible.
My avatar is a photo of CP/M running on the propeller, with some ASCII art created from a screen grab of the propeller picture, which originally came from a photo of a propeller chip. There was a bit of image enhancement and scaling done along the way. It was displayed by typing "TYPE PROPART.TXT" from within the CP/M emulation on the propeller.
We have better graphics now. Even movies in color!
If you want to write a batch file processor, I think all the building blocks are in Kyedos. eg, open a file, read lines of text, process them, close the file.
I need to check out Embedded Basic.
I see you are already thinking of conditional lines in batch files. That starts to become a programming language in its own right. It could get quite powerful, because each of the things you run can be entire self contained spin programs, that can do things like modify text files that following spin programs can also read and write.
I guess that leads to some generic Batch instructions. Print a message. Get a keypress, or line of text. Compare with other lines of text. Run one program if a match. That could be half the Basic keywords if you wanted.
All quite intriguing.
My current laptop does it in ~52 micro seconds using VB .Net 2010. Then again its a 3.6GHz 6 core i7 980x with 12 GB of ram. lol
I tried to bring all cores into play and it actually slows down the code. There is an overhead price you pay. It's doesn't payoff until you have a lot of caculations to do. It is very cool when you bring all six cores into play and see the processor really work. :-)
Can someone give a small program example to set bcolor and fcolor?
I'm running the version from page 1 post 1 but no color.
I'm updating the manual. Example code is needed.
A list of colors and their values would be helpful.
Thank you sincerely.
Sorry I haven't kept this thread up to date.
I have just now updated the program in the first post.
bcolor and fcolor are just "BCOLOR value" and "FCOLOR value". value can be 0 to 15 for the different colors.
Bean
*** COMPILED WITH PropBasic VERSION 00.01.02 Jul 20, 2010 ***
Actually there is a version 0.13, but I can't test it until I get home, so I don't want to post untested code.
Version 0.13 can be compiled for 32 columns (still 25 rows) if that will help you.
Here are the other changes in version 0.13 (for the help file)...
' Version 0.13
' Changed POKEB and PEEKB to POKE and PEEK
' Added FREE function (free memory)
' Added SCREEN function (screen address NTSC ONLY)
' Fixed autostart keyboard
' Fixed REM and ' tokenizing text
I have attached the binary for 32 columns if you want to try it (untested).
Bean
BTW, it looks like there is a problem with xPos, yPos and color not being defined if NTSC is not defined.
Dave
Oh, that is cool. I'll keep that option in future versions.
I can't wait to try it out.
P.S. Any reason why you made the SpinSimKeyboard task LMM ?
Bean
It worked right off.
As for timing: 10,000 FOR...NEXT loops took 2,886 milliseconds on my computer. I assume the speed is computer dependent ?
Also it only shows uppercase. Is that by design ? When I press caps-lock, I get a colon ":".
Bean
I've never noticed that about the caps-lock before. I use the kbhit() routine, and it must be returning true when the caps-lock is pressed. I'll have to look into that further.
SpinSim's speed depends on the speed of the host computer. It actually runs Spin programs faster than PASM programs, but it works fine for both as long as speed is not an issue.
I have merged your additions to the working version of Embedded Basic. All future version will have support for SpinSim.
It was easy to remove the code that converts chars to uppercase.
Is there anyway to do the "LOCATE x,y" function ? How about text colors FCOLOR, BCOLOR, COLOR ?
Bean
I would really like to do X,Y addressing and colors in a DOS window, but it seems like this is yet another function that Microsoft has removed. Earlier versions of Windows allowed using an ANSI.SYS file to support the use of the ANSI terminal escape sequence. However, I have been unable to get this to work unders Windows XP, Vista or 7. If anybody knows how to do this please let me know.
Linux command windows do support the ANSI terminal commands, so it would be possible to do this under linux.
BTW, I tried to add file I/O support to the SpinSim version of EmbeddedBasic so that programs could be saved and loaded from progn.bas files. I encountered an error that said that __ELSE_243 was unresolved. Is there a limit on the number of labels that can be generated? It looks like the PropBasic compiler did not generate the __ELSE_243 label.
Dave
Yes, there is a limit. I have sent new files to BradC for him to compile, but I haven't heard anything back for quite a while.
I'll try to contact him again.
I ran into the issue when doing a bunch of ELSEIFs that were strung together.
Bean
I have uploaded version 0.14 to the first post.
The zip file contains the source code, documentation, and binary files for NTSC (demo board), Spinneret, SpinSim and PST.
Here is a program to try out:
Hmm, it's starting to look like "real" BASIC...
Bean
They are in there now.
Sorry about that.
Bean
10 n=0
20 n=n+1
40 PRINT n;" ";
50 GOTO 20
Also what is the syntax on the peek command? I tried peek x but that didn't work.
Peek is a function, so it has to be peek(x)
Be sure to check out the pdf document.
I've included several binary files for different configurations: NTSC, Serial (PST), etc. So you don't need to worry about compiling the PropBasic source if you don't want to.
Any questions or comments are welcomed.
Thanks, Bean