@Mike, Meta2 looks interesting. I'll have to look at it in more detail.
@William, I do plan to allow Spinix to use other devices for stdio, such as VGA for stdout. I've spent a small amount of time looking into an 80 column text display. I think I can do that with 2 cogs and 2 or 3 Kbytes of hub RAM.
@Mike, Meta2 looks interesting. I'll have to look at it in more detail.
@William, I do plan to allow Spinix to use other devices for stdio, such as VGA for stdout. I've spent a small amount of time looking into an 80 column text display. I think I can do that with 2 cogs and 2 or 3 Kbytes of hub RAM.
This is really great work!
The 2 big things I see missing is:
1: A Virtual Memory facility using xmm
2: multiprop capability for more memory and processes
A virtual memory feature would be nice. I do plan on adding the capability to run XMM C programs in the near future. These would be run in a stand-alone mode, similar to how I run large Spin and LMM C programs. It would get complicated to support XMM in the OS itself, but it's certainly possible.
I haven't really thougt about multi-prop configurations. It could be done by making one of them the master, and the other ones would respond to commands from the master.
I'm not familiar with "bc", and I had to google it to learn about it. It might be nice to have a simple version of it as part of the tool set.
A virtual memory feature would be nice. I do plan on adding the capability to run XMM C programs in the near future. These would be run in a stand-alone mode, similar to how I run large Spin and LMM C programs.
I've attached spinix097 below. This contains the beginnings of a VGA driver that I did about a year ago, but never posted. It's only a 32x15 text display, so it's not that useful, but it's a start. The driver is loaded by running loadvga. Once the driver is loaded you can run a test program call vgatdemo. Hit the escape key to exit the program. The standard out can be switched to the display by typing "stdout display". It can be switched back to the serial port by typing "stdout serial".
This version also contains faster versions of the sb and rb apps that are used to send and receive files over the serial port. The faster versions are called sb1 and rb1. They compute the CRC using a table instead of doing it a bit at a time.
This version of spinix fixes a problem with running C LMM apps and programs. CMM and XMM programs are still not supported. I've also included the source for the filetest program that shows how to mount the SD card and change to the current working directory.
Well I downloaded an tried it, and it works on my C3 board. Did you write the bootsd.binary file to your EEPROM and copy the files from the spinix098/root directory to the SD card? The first time you boot up it will print "Press any key to start SD pin setup" once per second. After you enter the SD pins the shell will print "spinix 0.98 July 31, 2013". Do you get any of that? The baud rate is 115,200.
Well I downloaded an tried it, and it works on my C3 board. Did you write the bootsd.binary file to your EEPROM and copy the files from the spinix098/root directory to the SD card? The first time you boot up it will print "Press any key to start SD pin setup" once per second. After you enter the SD pins the shell will print "spinix 0.98 July 31, 2013". Do you get any of that? The baud rate is 115,200.
Yes, I did all of that. I get the SD pin setup, and enter the pins, then it hangs. Nothing happens after the SD pin setup even with a reset. It never prints "spinix 0.98 ..." On the board I'm using for Spinix, the SD card is attached directly to P16, 17, 18, 19. Spinix090 and 097 work fine.
I'm not using C3 for this. I'm using that for something else at the moment.
I did a "diff -r pfth097 pfth098" and the only changes I see are in _cloader.spin, ls.spin, runc_sd.spin, shell.spin and the C program binaries. bootsd.binary is identical between 097 and 098, so it doesn't really need to be reloaded. The changes in shell.spin were to change the date and version number and the two long values that are used to detect a C binary file. This shouldn't affect bootup.
Steve, can you reload pfth097 and verify that that's working, and then reprogram the same SD card with the pfth098 files without reprogramming the EEPROM? It seems that has to work OK. If that doesn't work maybe another SD card would work.
Steve, can you reload pfth097 and verify that that's working, and then reprogram the same SD card with the pfth098 files without reprogramming the EEPROM? It seems that has to work OK. If that doesn't work maybe another SD card would work.
Hi Dave,
Copied all the spinix098 files to the sdcard without reprogramming the EEPROM, and I get the "spinix 0.98 July 31, 2013" banner.
Spinix 1.02 is attached below. The main change in version 1.02 is the addition of the pfth Forth interpreter. The executable for pfth is in the /bin directory, and the source and text files are in the /forth directory. An ANS Forth source file can be executed by typing "pfth file.fth" from the Spinix command line. The user can exit pfth, and return back to the Spinix shell by typing "bye". pfth supports simplified version of the ls, cat, rm, cp and cd command.
Another major change is the way that Spin and C programs are detected. I now use an explicit "SPRO" or "CPRO" tag stored in the first four bytes of the file, where the clock frequency is normally stored. Programs that are not Spinix-aware can be run as stand-alone programs. This allows for running CMM C programs and other programs that should not be modified by the OS.
This version of spinix contains some major changes. I've decided to get rid of the kernel, which simplifies things quite a bit. Now each program contains the entire file system rather than relying on the kernel to provide the file system. This improves performance of each application, and reduces the total amount of memory that was required by the application plus the kernel.
The shell now support variables and the ability for scripts to execute other scripts. The shell also supports $#, $? and parameter variables $1, $2, etc. The shell now supports the following conditional-execution commands within a script file:
if then else fi while do done exit
Only one level of "if" or "while" blocks can be used at a time, but an "if" block can be embedded in a "while" block, or vice-versa.
I added unix time support, where the date and time is maintained using the Prop counter. The following utilities have been added to support shell variables and unix time:
alias date unset declare export let printenv set test timezone touch unalias
The Spin compiler has been enhanced by adding a Spin linker call splink. splink will link a top object with another file that contains one or more objects. I created a script call spc, which stands for Spin Compiler collection. It can compile and build a Spin program by running spinit followed by spasm, and then uses splink to link the program to the clibsd object. Sample programs are located in the devel directory.
I forgot to include the timezone utility in the latest build. It's needed if you want to change the timezone from -6 to something else. I've attached the timezone executable below. Alternatively, you can change the long stored at location $7fba using the diag utility, and the pokem command. You would then need to do a reboot for the value to be written to the /_sysparm file.
Or you could edit the /_sysparm file, and change the first number on the second line from -6 to something else. You would then need to do a hardware reset for the _sysparm file to be read on bootup.
The easiest thing to do is to just copy the timezone.bin file to the /bin directory, and rename it to timezone. Then you can set the time zone using the utility.
I got Spinix133 up and running on a Propeller Activity Board in less than 10 minutes.
Started pfth. (Dumb) question: How do I save my newly defined Forth words? Or are they automatically saved to the SD card or EEPROM?
I have dabbled with spinix/pfth and Tachyon, I like having choices! My ADD has gotten in the way of getting a good depth of knowledge of either, but with pfth being ANSI, that gives me a goal to master that Starting with "Starting Forth". The ability to run C and other code is compelling also.
@ Peter Jakacki. Not dissing Tachyon, but bear in mind both you guys are light years ahead of me and pfth suits my goal of learning the basics for now.
I've been working on an sdsave command the past couple of days, and I've attached the file below as sdsave.txt. Download this file and copy it to the forth directory on your SD card. You may want to change the extension from txt to fth. Then start up pfth and type "include sdsave.fth". You can then save the current state of your pfth session by typing "sdsave filename". This creates an executable file with the specified name, so you can restart from where you left off by running the saved executable file.
Here's an example of creating a "Hello World" word, saving it, exiting to spinix, and then running the saved image.
shell>
shell> pfth
pfth 1.03
ok
include sdsave.fth
ok
: hello ." Hello World!" cr ;
ok
hello
Hello World!
ok
sdsave mywork
ok
bye
shell> mywork
pfth 1.03
ok
hello
Hello World!
ok
bye
shell>
One advantage to running a saved image is that pfth doesn't have to compile itself since the image contains the compiled code. This allows pfth to come up instantly instead of taking 2 or 3 seconds to compile on startup. In the next release of Spinix I'll include a pre-compiled version of pfth that already includes the sdsave command.
Of course, the alternative to saving your work this way is to create words in a text file using one of the spinix editors or the ted editor under pfth. This way you will be able to modify the source and load it using the include command or loading it when you invoke pfth by specifying it on the command line, such as "pfth test.fth".
Had never looked at spinix before... Interesting in light of the thread from Ken about programming a prop-based bot from an iPad or other tablet device. I'm looking into using the rb (receive binary) command to receive an executable wirelessly from a device or CPU. In my testing, I've run into an issue with rb as well as a few other problems that are hindering my tests.
Config: Most-recent spinix from Post #1 of this thread. QuickStart board with PropellerPowered Quick Proto Lite. The Proto Lite has an SD slot wired to P0-P3. Running SimpleIDE (0.9.45 - Thanks to Jazzed!) on Mac OS X10.9 as well as the cutecom terminal app (for ymodem access to file transfers)...
Initial steps: installed the boot.binary (using Brads Prop Tool app) into the QS's EEPROM and inserted the SD with all of the files from the spinix root directory copied to it. On startup, receive the "press any key" message and went through the entry process for the SD card pins. At that point I can use spinix commands, compile the spin code examples, etc. I exec these commands from SimpleIDE's console or from cutecom (terminal app that allows ymodem transfers)...
Issues:
1. After booting and going through the SD pin config process, I reboot spinix expecting that it will save the SD pinout info in EEPROM, but after reboot I still get the "press any key" message and have to re-enter the SD pins.
2. Exec'ing the "rb" command gives me the 15 second warning message to send a file using ymodem. I start the Send file option (with ymodem) on cutecom. The QS responds with "1 0x00" (or something similar) then seems to reboot, giving me the "press any key" message again. I was trying to send a binary of the "kill" command. cutecom appears to send the file, lighting up the transmit & receive LEDs on the QS board as an indicator that data is being sent. After cutecom is done sending, checking for the file with "ls" shows that it was not transferred.
3. I noticed that the "ps" and "kill" commands are not included in the spinix binaries. The .spin sources are in the devel directory and can be compiled and resulting binaries copied to the SD card. Not sure if this is just something that was missed from recent downloads?
BTW: I am expecting to use one of PropellerPowered's USR WiFi devices, which provides TTL serial access from the Prop. With spinix, I hope to download a binary file, wirelessly from the iPad to spinix, where it can be executed. As a proof of concept for a possible iPad/tablet-based compiler, this could help to flesh-out the transport methodology (I hope)...
Sorry about the boot issue. It saves the pin values back to EEPROM, but will ask again on the next boot if the first pin is 0. I've attached a fixed version of boot.spin and boot.binary below.
I did some testing of rb after I made my changes to the spinix architecture, but I need to test it some more. I'll let you know if I have a fix for the problem.
I removed ps and kill from the bin directory since I no longer allow multiple processes. However, it still might be useful to control the driver cogs. I'll add them back in the next update.
Now booting without the need to reapply SD pin numbers...
I tried to rebuild both ps.spin and kill.spin. but kill.spin wants a definition for sys#cogtable, which seems missing from sysdefs.spin from the spinix133 build.
ps.spin compiled and is back in my /bin directory and works! Good to know what drivers are exec'ing, since I'll be testing a few.
I've been working on an sdsave command the past couple of days, and I've attached the file below as sdsave.txt. Download this file and copy it to the forth directory on your SD card. You may want to change the extension from txt to fth. Then start up pfth and type "include sdsave.fth". You can then save the current state of your pfth session by typing "sdsave filename". This creates an executable file with the specified name, so you can restart from where you left off by running the saved executable file.
Here's an example of creating a "Hello World" word, saving it, exiting to spinix, and then running the saved image.
shell>
shell> pfth
pfth 1.03
ok
include sdsave.fth
ok
: hello ." Hello World!" cr ;
ok
hello
Hello World!
ok
sdsave mywork
ok
bye
shell> mywork
pfth 1.03
ok
hello
Hello World!
ok
bye
shell>
One advantage to running a saved image is that pfth doesn't have to compile itself since the image contains the compiled code. This allows pfth to come up instantly instead of taking 2 or 3 seconds to compile on startup. In the next release of Spinix I'll include a pre-compiled version of pfth that already includes the sdsave command.
Of course, the alternative to saving your work this way is to create words in a text file using one of the spinix editors or the ted editor under pfth. This way you will be able to modify the source and load it using the include command or loading it when you invoke pfth by specifying it on the command line, such as "pfth test.fth".
Hello Dave,
Great work.
On my breadboard module (10MHz crystal, pll8x) with usb connection via a FT232RL chip, spinix133 starts without problems. But it does not run on a module that is based on ramblade design (12MHz crystal, pll8x), and has different pins for RX / TX. In which files can I change the pin numbers, if it is at all possible. If I change it only in clibsd.spin, boot.binary starts from the EEPROM and ask for the SD pins. After that, the shell does not start. Do I still make changes in other files, such for example in cserial.spin?
With kind regards
G
You should just have to change the serial pins in the start method in clibsd.spin and the clock settings in boot.spin. It sounds like you rebuilt boot.binary since it works, but you must rebuild everything using build_spinix. The programs inherent the clock settings from the boot program, but the serial driver is restarted every time a program is run. I plan on making the serial driver resident again, which would eliminate the requirement of having to rebuild everything to change the pin settings.
There are some stand-alone programs that would need to be changed also if you want to run those. I think the lerner program is the only stand-alone Spin program, so you would have to change it's clock setting and it's copy of clib.spin if you want to run it. You would also need to change the C programs, but I'm not sure how to set the serial pins.
Hello Dave
Thanks for the answer.
I found RX and TX pin numbers at two places in the clibsd.spin. First in the method "start" and secondly, in the method "enter1". I changed both. Even at the first try I had changed the clock settings in boot.spin and eeprom.spin. After that, I started build-spinix again. Now the shell prompt appears on the terminal screen. My problem was in the method "enter1". The terminal is connected to pin 23 (RX) and pin 22 (TX). Now I can use my SD-CP/M-modul (based on RamBlade) for spinix.
The c-programs still use the pin numbers 30 and 31.In the next time I'm still trying to change the RX and TX pins in c programs.
Thanks for finding that. I had forgotten that spinix apps call c.enter instead of c.start. start calls start1, and enter calls enter1, which calls start1. enter does all of the initialization for the app, and I was going to allow for specifying the stack size. However, it currently uses the same stack size of 200 bytes that start uses, so I could have just call start instead.
In some future update the console driver will remain resident, and this confusion shouldn't happen. I think for C programs the serial pin numbers can be specified when building the binary image. I'll look into when I get a chance.
spinix145 is attached below. This version incorporates the patches that I've posted since the last update. It also adds a Basic interpreter and Michael Park's Sphinx Spin compiler. The Basic interpreter is called bas, and you can do a "man bas" to get more information about it.
The Sphinx Spin compiler is contained in the sphinx directory. It is executed by running the lex utility, which parses the Spin source file, and then invokes codegen to build an object file. If the "-l" option is specified, codegen will run link to produce an executable file. I added the tokdump and sobdump utilities to dump the contents of token and object files.
This version of spinix also includes the Linux cal, sort and sed utilities.
I forgot to mention that this release contains the original C source files for some of the utilities in the csrc directory. The C files are converted to Spin using cspin, and copied to the src directory. These utilities include bas, cal, diff, ed, lerner, sed, sobdump, sort, spasm, spinit, splink, tar, ted and vi.
Comments
@William, I do plan to allow Spinix to use other devices for stdio, such as VGA for stdout. I've spent a small amount of time looking into an 80 column text display. I think I can do that with 2 cogs and 2 or 3 Kbytes of hub RAM.
Did you check out my single-cog VGA text drivers?
80 column (requires 6.25MHz crystal)
http://forums.parallax.com/showthread.php?129781-80-column-VGA-text-driver-in-one-cog-60-48-40-32-30-24-20...rows!-%28beta-test%29
64 column (requires 5.00Mhz crystal)
http://forums.parallax.com/showthread.php?129739-64-column-VGA-text-driver-in-one-cog-48-40-32-30-24-20...rows!-%28RELEASED%29
50 column (requires 5.00Mhz crystal)
http://forums.parallax.com/showthread.php?129769-50-column-VGA-text-driver-in-one-cog-60-50-40-30-25-20...rows!-%28RELEASED%29
The drivers come with a large set of fonts (8/10/12/15/16 dots high) so you can configure a ton of different text resolutions.
If you use a small font (ie 8x10) vertically scaled by 2, you get a 80x24 display with decent descenders. The memory footprint is not too bad...
Regards,
Bill
The 2 big things I see missing is:
1: A Virtual Memory facility using xmm
2: multiprop capability for more memory and processes
and a little thing..bc.
Keep up the good work.
Doug
I haven't really thougt about multi-prop configurations. It could be done by making one of them the master, and the other ones would respond to commands from the master.
I'm not familiar with "bc", and I had to google it to learn about it. It might be nice to have a simple version of it as part of the tool set.
This version also contains faster versions of the sb and rb apps that are used to send and receive files over the serial port. The faster versions are called sb1 and rb1. They compute the CRC using a table instead of doing it a bit at a time.
Yes, I did all of that. I get the SD pin setup, and enter the pins, then it hangs. Nothing happens after the SD pin setup even with a reset. It never prints "spinix 0.98 ..." On the board I'm using for Spinix, the SD card is attached directly to P16, 17, 18, 19. Spinix090 and 097 work fine.
I'm not using C3 for this. I'm using that for something else at the moment.
Steve, can you reload pfth097 and verify that that's working, and then reprogram the same SD card with the pfth098 files without reprogramming the EEPROM? It seems that has to work OK. If that doesn't work maybe another SD card would work.
Hi Dave,
Copied all the spinix098 files to the sdcard without reprogramming the EEPROM, and I get the "spinix 0.98 July 31, 2013" banner.
Another major change is the way that Spin and C programs are detected. I now use an explicit "SPRO" or "CPRO" tag stored in the first four bytes of the file, where the clock frequency is normally stored. Programs that are not Spinix-aware can be run as stand-alone programs. This allows for running CMM C programs and other programs that should not be modified by the OS.
I also added the Linux word count program, wc.
The shell now support variables and the ability for scripts to execute other scripts. The shell also supports $#, $? and parameter variables $1, $2, etc. The shell now supports the following conditional-execution commands within a script file:
if then else fi while do done exit
Only one level of "if" or "while" blocks can be used at a time, but an "if" block can be embedded in a "while" block, or vice-versa.
I added unix time support, where the date and time is maintained using the Prop counter. The following utilities have been added to support shell variables and unix time:
alias date unset declare export let printenv set test timezone touch unalias
The Spin compiler has been enhanced by adding a Spin linker call splink. splink will link a top object with another file that contains one or more objects. I created a script call spc, which stands for Spin Compiler collection. It can compile and build a Spin program by running spinit followed by spasm, and then uses splink to link the program to the clibsd object. Sample programs are located in the devel directory.
Or you could edit the /_sysparm file, and change the first number on the second line from -6 to something else. You would then need to do a hardware reset for the _sysparm file to be read on bootup.
The easiest thing to do is to just copy the timezone.bin file to the /bin directory, and rename it to timezone. Then you can set the time zone using the utility.
First, thanks for your continued work on this.
I got Spinix133 up and running on a Propeller Activity Board in less than 10 minutes.
Started pfth. (Dumb) question: How do I save my newly defined Forth words? Or are they automatically saved to the SD card or EEPROM?
I have dabbled with spinix/pfth and Tachyon, I like having choices! My ADD has gotten in the way of getting a good depth of knowledge of either, but with pfth being ANSI, that gives me a goal to master that Starting with "Starting Forth". The ability to run C and other code is compelling also.
@ Peter Jakacki. Not dissing Tachyon, but bear in mind both you guys are light years ahead of me and pfth suits my goal of learning the basics for now.
Rick.
I've been working on an sdsave command the past couple of days, and I've attached the file below as sdsave.txt. Download this file and copy it to the forth directory on your SD card. You may want to change the extension from txt to fth. Then start up pfth and type "include sdsave.fth". You can then save the current state of your pfth session by typing "sdsave filename". This creates an executable file with the specified name, so you can restart from where you left off by running the saved executable file.
Here's an example of creating a "Hello World" word, saving it, exiting to spinix, and then running the saved image.
One advantage to running a saved image is that pfth doesn't have to compile itself since the image contains the compiled code. This allows pfth to come up instantly instead of taking 2 or 3 seconds to compile on startup. In the next release of Spinix I'll include a pre-compiled version of pfth that already includes the sdsave command.
Of course, the alternative to saving your work this way is to create words in a text file using one of the spinix editors or the ted editor under pfth. This way you will be able to modify the source and load it using the include command or loading it when you invoke pfth by specifying it on the command line, such as "pfth test.fth".
Dave
Config: Most-recent spinix from Post #1 of this thread. QuickStart board with PropellerPowered Quick Proto Lite. The Proto Lite has an SD slot wired to P0-P3. Running SimpleIDE (0.9.45 - Thanks to Jazzed!) on Mac OS X10.9 as well as the cutecom terminal app (for ymodem access to file transfers)...
Initial steps: installed the boot.binary (using Brads Prop Tool app) into the QS's EEPROM and inserted the SD with all of the files from the spinix root directory copied to it. On startup, receive the "press any key" message and went through the entry process for the SD card pins. At that point I can use spinix commands, compile the spin code examples, etc. I exec these commands from SimpleIDE's console or from cutecom (terminal app that allows ymodem transfers)...
Issues:
1. After booting and going through the SD pin config process, I reboot spinix expecting that it will save the SD pinout info in EEPROM, but after reboot I still get the "press any key" message and have to re-enter the SD pins.
2. Exec'ing the "rb" command gives me the 15 second warning message to send a file using ymodem. I start the Send file option (with ymodem) on cutecom. The QS responds with "1 0x00" (or something similar) then seems to reboot, giving me the "press any key" message again. I was trying to send a binary of the "kill" command. cutecom appears to send the file, lighting up the transmit & receive LEDs on the QS board as an indicator that data is being sent. After cutecom is done sending, checking for the file with "ls" shows that it was not transferred.
3. I noticed that the "ps" and "kill" commands are not included in the spinix binaries. The .spin sources are in the devel directory and can be compiled and resulting binaries copied to the SD card. Not sure if this is just something that was missed from recent downloads?
BTW: I am expecting to use one of PropellerPowered's USR WiFi devices, which provides TTL serial access from the Prop. With spinix, I hope to download a binary file, wirelessly from the iPad to spinix, where it can be executed. As a proof of concept for a possible iPad/tablet-based compiler, this could help to flesh-out the transport methodology (I hope)...
Thanks for your development work on spinix!
dgately
I did some testing of rb after I made my changes to the spinix architecture, but I need to test it some more. I'll let you know if I have a fix for the problem.
I removed ps and kill from the bin directory since I no longer allow multiple processes. However, it still might be useful to control the driver cogs. I'll add them back in the next update.
Now booting without the need to reapply SD pin numbers...
I tried to rebuild both ps.spin and kill.spin. but kill.spin wants a definition for sys#cogtable, which seems missing from sysdefs.spin from the spinix133 build.
ps.spin compiled and is back in my /bin directory and works! Good to know what drivers are exec'ing, since I'll be testing a few.
Thanks again,
dgately
Works beautifully, thanks Dave.
Great work.
On my breadboard module (10MHz crystal, pll8x) with usb connection via a FT232RL chip, spinix133 starts without problems. But it does not run on a module that is based on ramblade design (12MHz crystal, pll8x), and has different pins for RX / TX. In which files can I change the pin numbers, if it is at all possible. If I change it only in clibsd.spin, boot.binary starts from the EEPROM and ask for the SD pins. After that, the shell does not start. Do I still make changes in other files, such for example in cserial.spin?
With kind regards
G
There are some stand-alone programs that would need to be changed also if you want to run those. I think the lerner program is the only stand-alone Spin program, so you would have to change it's clock setting and it's copy of clib.spin if you want to run it. You would also need to change the C programs, but I'm not sure how to set the serial pins.
Thanks for the answer.
I found RX and TX pin numbers at two places in the clibsd.spin. First in the method "start" and secondly, in the method "enter1". I changed both. Even at the first try I had changed the clock settings in boot.spin and eeprom.spin. After that, I started build-spinix again. Now the shell prompt appears on the terminal screen. My problem was in the method "enter1". The terminal is connected to pin 23 (RX) and pin 22 (TX). Now I can use my SD-CP/M-modul (based on RamBlade) for spinix.
The c-programs still use the pin numbers 30 and 31.In the next time I'm still trying to change the RX and TX pins in c programs.
In some future update the console driver will remain resident, and this confusion shouldn't happen. I think for C programs the serial pin numbers can be specified when building the binary image. I'll look into when I get a chance.
The Sphinx Spin compiler is contained in the sphinx directory. It is executed by running the lex utility, which parses the Spin source file, and then invokes codegen to build an object file. If the "-l" option is specified, codegen will run link to produce an executable file. I added the tokdump and sobdump utilities to dump the contents of token and object files.
This version of spinix also includes the Linux cal, sort and sed utilities.