Sorry about the 128k - my mistake I guess it is because I coded that into my IDE and I've looked at it so many times I thought that was the number.
Lots of flexibility with all the models you support. The SPI ought to be similar to other SPI boards. I'm looking forward to some Catalina programming time this weekend. I've been trying out Kye's new SD card driver and it is a *lot* faster. Run a binary from the Kyedos prompt and it takes about 1.5 seconds to load and run. I don't know how he is getting data off the sd card into the propeller so fast. So I guess that is now another nifty bit of spin/pasm code that needs porting into C...
I read the manual on Catalina and Catalyst and was confused on a point. In order to run an XMM application on a multi-prop platform, does it require User intervention to start it up, or can the whole thing start
itself up from SD on Powerup?
What I want to do is write a C program ( which will require XMM due to its feature set ), and when the user turns the device on, it loads itself and intializes itself from the SD card, at which point, the user now
see a opening menu on a LCD screen.
I think the answer is yes, but I wasn't sure.
Related to your last answer on running C and spin, I understand that I can't run C and spin if the C is using XMM. I assume that applies to all cogs? Ie, I can't have a cog running a XMM C App
and a cog running spin?
I know there are cog commands in the latest releases, so while I can't run C and Spin, I can run different C "programs" on the different cogs. Anotherwards, I have the same functionality in an XMM C program of using multiple cogs for parallel
processing that I do under spin.
Do I have this correct?
Last question - in the documentation, you talk about possible purchasing of cog safe C functions such as Malloc. Is that possible, or a future possibility?
I read the manual on Catalina and Catalyst and was confused on a point. In order to run an XMM application on a multi-prop platform, does it require User intervention to start it up, or can the whole thing start
itself up from SD on Powerup?
Catalyst is specifically intended for user interaction, but there is also a "Generic SD Card Loader" in the utilities folder with an auto-start capability.
What I want to do is write a C program ( which will require XMM due to its feature set ), and when the user turns the device on, it loads itself and intializes itself from the SD card, at which point, the user now
see a opening menu on a LCD screen.
I think the answer is yes, but I wasn't sure.
Yes, the "Generic SD Card Loader" is designed to be able to do what you need. You just configure it with the file name to be loaded on boot and then program the loader into the EEPROM. I haven't used this code in a while, so I'll check that it is still working and let you know. Also, I suppose I could add similar code to Catalyst so it will auto boot a specific file name (e.g. "AUTOEXEC.BIN") if it finds it on the SD Card. I'll add that function to the forthcoming release.
Related to your last answer on running C and spin, I understand that I can't run C and spin if the C is using XMM. I assume that applies to all cogs? Ie, I can't have a cog running a XMM C App
and a cog running spin?
I know there are cog commands in the latest releases, so while I can't run C and Spin, I can run different C "programs" on the different cogs. Anotherwards, I have the same functionality in an XMM C program of using multiple cogs for parallel
processing that I do under spin.
Do I have this correct?
Not quite - this is currently true for the LMM kernel, but I haven't added multithreading to the XMM kernel yet. And just a word of warning - when I do, it may be that for XMM programs I can only support multithreading on a single XMM cog, not multiple XMM cogs (it depends on how much space I can manage to find in the XMM Kernel, which is already fairly tight!)
Last question - in the documentation, you talk about possible purchasing of cog safe C functions such as Malloc. Is that possible, or a future possibility?
That's a future possibility - at present, you will need to protect any memory management operations via a thread lock (the same way I do for the HMI calls in the demos).
I think it might already be answered above. I have a very similar request now that Kyedos is working. I'd like a binary file on the sd card that can run xmm catalina programs.
eg - in Spin the procedure is to hit F8, then "save as binary", then I rename "myfile.binary" to "myfile.exe" or "myfile.com" or myfile.bin", then put that on the sd card. This can then be run from Kyedos.
For XMM programs, I would imagine that the equivalent program contains a part that runs and then loads a larger part into external memory and then runs that. Catalyst can then run that program.
What I'm wondering is whether it is possible to create a program that contains catalyst within it? A bit like an autoextracting zip file.
Or maybe a way of passing the filename to catalyst as a command line (now that we have command line parameters working on Kyedos)? Or even pass parameters through as well? (The kyedos protocol is pretty simple - it just saves the command line as a single line text file "COMMAND.TXT" on the SD card, so all you would have to do is check if that exists and read it in and chop it up into the parameters).
I think it might already be answered above. I have a very similar request now that Kyedos is working. I'd like a binary file on the sd card that can run xmm catalina programs.
eg - in Spin the procedure is to hit F8, then "save as binary", then I rename "myfile.binary" to "myfile.exe" or "myfile.com" or myfile.bin", then put that on the sd card. This can then be run from Kyedos.
For XMM programs, I would imagine that the equivalent program contains a part that runs and then loads a larger part into external memory and then runs that. Catalyst can then run that program.
What I'm wondering is whether it is possible to create a program that contains catalyst within it? A bit like an autoextracting zip file.
Or maybe a way of passing the filename to catalyst as a command line (now that we have command line parameters working on Kyedos)? Or even pass parameters through as well? (The kyedos protocol is pretty simple - it just saves the command line as a single line text file "COMMAND.TXT" on the SD card, so all you would have to do is check if that exists and read it in and chop it up into the parameters).
Your thoughts would be most appreciated.
I think the best thing is to just use KyDos to autoload an instance of the Generic SD Card Loader program (or Catalyst, when I add this facility to that program), which would then autoload whatever file that program was configured to load on startup. While it seems a bit round-about, in reality this is probably the best and simplest option. Adding an SD card loader to the program itself wouldn't help much, since that program would then become larger than 32kb and would therefore itself require a special loader to be written.
Note that I have not yet added the ability to autoload programs that require command line parameters (I added command line parameters after I wrote the Generic SD Card Loader). I'll look at adding that facility in.
I have just sent a $250 donation via your sourceforge paypal link to say thanks for all the support. Cheers, Drac.
Goodness Gracious, Dr_Acula! You didn't need to do that - but thanks very much. Most of it will probably go straight back to Parallax for the purchase of a C3 - but I heard you say in another thread that you are thinking of using SPI RAM on your next board - so you will ultimately benefit from your investment.
I'll also send you a copy of the Catalina Optimizer (actually, for a donation that size you can have 10 copies!) and I'll also polish up the various program loaders for you (and Bruce as well).
Attached is a version of Catalyst which supports auto-execution. On boot, it will auto-execute the file AUTOEXEC.BIN if it exists it in the root directory of the SD Card. Otherwise it goes to the normal command line prompt. The file to be auto-executed can be a normal SPIN binary, or an LMM or an XMM C program. If you want to instead auto-execute a file with a different name, or pass parameters to it, just modify the AUTOFILE and AUTOARGS variables to whatever you need.
This version will be included in the next release. For the moment, simply overwrite your existing version (which is in the Catalina\catalyst\core subdirectory) and rebuild Catalyst.
Let me know if you have any problems.
Ross.
EDIT: Attachment removed. It is no use without the latest version of Catalina, which is yet to be released.
Thanks Ross. This will go very well with the xmodem transfer I got working tonight. Runs xmodem on Kyedos and on the catalina IDE. So now it is possible to transfer any files directly to the SD card. Had to tweak multiple timing delays when changing from 38400 to 115200 baud, but it works well now and can both send and receive files.
Compile to ram, or compile and download to the card with one keypress.
I've got variants of catalyst already on the card. Now I need to have a little think about how to "run" an XMM program from kyedos. Maybe it is as simple as kyedos creating the autoexec file and then running catalyst?
I've got variants of catalyst already on the card. Now I need to have a little think about how to "run" an XMM program from kyedos. Maybe it is as simple as kyedos creating the autoexec file and then running catalyst?
That was what I intended. Another option is to modify KyDos to execute Catalyst with command line parameters telling it what program to start. The reason I didn't do this was that it requires Catalyst and KyeDos to agree on the method of passing parameters. You could either adopt Catalyst's method (see Catalina\catalyst\demo\Demo.spin) or build a custom version of Catalyst that uses KyDos's method (I don't know what that method is).
If you decide to choose the former (i.e. adopt Catalyst's method), then I will modify Catalyst to execute the program specified in the command line arguments instead of always executing the same auto-exec file. This would only require a few minutes work, so let me know if you want this solution.
As an aside, I've re-coded xmodem to run at 115200 baud. Using a demo C program in XMM, Payload compiles and downloads in 20 seconds. Xmodem compiles and downloads and saves to the sd card in 45 seconds.
So you have the best of both worlds - faster compilation to ram for quick and simple testing. And slower but permanent transfer of the same program to sd card but taking a bit longer.
In re-coding this I have been looking at the vb.net code for some time so I need to post this before I forget what is going on!
ResetPropeller() ' boot back into kyedos
Sleep(3000) ' compile is faster than kyedos rebooting
Compile_C() ' compile the program
Download_C() ' download the file
The Download_C does the following:
1) rename myfile.binary to myfile.bin
2) run xmodem - sends XMODEM R MYFILE.BIN<cr>
3) wait for 3 secs for Kyedos to restart
4) run CATLYST2.EXE which is the serial version of catalyst at 38400 baud (I must get around to recompiling a 115200 baud one). sends CATLYST2<cr>
5) wait 2 seconds for catalyst to start
6) sets baud rate to 38400
7) sends MYFILE<cr>
All this is possible because we are talking via the serial port. How would you do the same thing from within Kyedos?
The problem I have is finding something static when you run a new program. I thought some memory locations would stay static but they seemed to change. So I just save a command line on the sd card. The syntax seems almost identical to your syntax for catalyst.
Actually, I don't even have a syntax. If the user types "XMODEM R MYFILE.TXT<cr> then the file COMMAND.TXT contains a zero terminated string "XMODEM R MYFILE". It is up to the xmodem program to work out what that means, print out error messages etc.
So we could just use your syntax?
I guess the simplest command is to type:
CATLYST MYFILE
and catalyst would then run the XMM program MYFILE.BIN
But down the track one might want to pass a command line as well.
At the moment, if I type
CATLYST MYFILE PAR1 PAR2 PAR3
then there will be a file COMMAND.TXT on the sd card with the text
CATLYST MYFILE PAR1 PAR2 PAR3
Could Catalyst check if this exists and if so, process this in some way?
for example, this is the code in xmodem. And yes, it may do odd things if you don't type the command right, so maybe a better command line parser is needed, ie one that formally looks for spaces or something?
result := \fat.openfile(string("COMMAND.TXT"),"R")
result := \fat.readstring(@commandline,80) ' read in the command line
result := \fat.closefile
i := str.len(@commandline) ' length of the string "XMODEM R MYFILE.TXT"
str.mid(@commandline,@lineoftext1,8,1) ' get R or S
rw := str.stringcompareci(@lineoftext1,string("R")) ' is it R or r then returns zero? if not then S or s
str.mid(@commandline,@filename,10,i-9) ' get the filename
The problem I have is finding something static when you run a new program. I thought some memory locations would stay static but they seemed to change. So I just save a command line on the sd card. The syntax seems almost identical to your syntax for catalyst.
Actually, I don't even have a syntax. If the user types "XMODEM R MYFILE.TXT<cr> then the file COMMAND.TXT contains a zero terminated string "XMODEM R MYFILE". It is up to the xmodem program to work out what that means, print out error messages etc.
Ok - that makes sense. The only thing guaranteed to be common between Catalyst and KyeDos (or any other OS for that matter) is the SD card itself, so let's use that.
Tonight I will modify Catalyst so that if it finds a file called COMMAND.TXT (or AUTOEXEC.TXT - I'll make it configurable so you can use whatever file name you want) on the SD card when it starts, it will read a line from the file and execute it as a Catalyst command line. Easy!
Now that would be nifty! Then we could pass all sorts of parameters. Indeed, Catalyst will just be reading that file, so COMMAND.TXT will still be there when the C program runs. So you could also use it to pass parameters to the C program as well. Maybe if Space is the delimiter, and Catalina can use the first n parameters, and the C program starts reading its parameters from n+1. Most programs might not have parameters but it certainly gives a lot of flexibility to be able to pass them. Many other ways to do this as well. Little text files are a great way of passing data between programs.
C programs could run other C programs and pass parameters in the same way.
Just going off on a tangent I'm thinking of cool things to add to the Kyedos library. Do you know of any Basic interpreteters written in C89? Or Compilers? Or other languages for that matter? (There seems to be Python interpreters around written in C89. Would they work?) I've got all the ones in CP/M but they are inside CP/M and it would be a great to have some ones that run natively on the propeller rather than within CP/M.
And another thought. What is the extension for compiled C programs? I think you have used .BIN
I'm using .EXE for compiled Spin files. I could program KyeDOS so that if you type the name of a program that ends in .BIN, it runs Catalyst. So you don't have to type the catalyst bit.
Then big XMM C programs could seamlessly be integrated into the operating system as commands.
How cool would it be to have a file BASIC.BIN and you type BASIC<cr> and up comes a basic interpreter prompt?
Now that would be nifty! Then we could pass all sorts of parameters. Indeed, Catalyst will just be reading that file, so COMMAND.TXT will still be there when the C program runs. So you could also use it to pass parameters to the C program as well. Maybe if Space is the delimiter, and Catalina can use the first n parameters, and the C program starts reading its parameters from n+1. Most programs might not have parameters but it certainly gives a lot of flexibility to be able to pass them. Many other ways to do this as well. Little text files are a great way of passing data between programs.
C programs could run other C programs and pass parameters in the same way.
They could - but it's an inefficient way to do it, since it means all programs must include file system access code - which is quite large. Internally, Catalyst & Catalina have a much more efficient ways to pass parameters to C (and SPIN) programs which does not rely on having an SD card, and also consumes almost zero hub RAM (it uses cog RAM instead). The file-based on one is useful mainly for passing parameters between programs in different operating environments (i.e. Catalyst and KyeDos).
Just going off on a tangent I'm thinking of cool things to add to the Kyedos library. Do you know of any Basic interpreteters written in C89? Or Compilers? Or other languages for that matter? (There seems to be Python interpreters around written in C89. Would they work?) I've got all the ones in CP/M but they are inside CP/M and it would be a great to have some ones that run natively on the propeller rather than within CP/M.
There's quite a few. Just google for "ANSI C BASIC INTERPRETER". Some are good, some are useless. A python interpreter would probably compile, but may be too large to run on some platforms (Python is a larger language than Basic). Catalyst does run Lua (another scripting language), but Python is larger still.
And another thought. What is the extension for compiled C programs? I think you have used .BIN
I'm using .EXE for compiled Spin files. I could program KyeDOS so that if you type the name of a program that ends in .BIN, it runs Catalyst. So you don't have to type the catalyst bit.
The latest version of Catalyst also accepts .LMM, .SMM and .XMM and will use the appropriate loader for each. Why not reserve those in KyeDos to mean "launch this program with Catalyst?"
Then big XMM C programs could seamlessly be integrated into the operating system as commands.
How cool would it be to have a file BASIC.BIN and you type BASIC<cr> and up comes a basic interpreter prompt?
Catalyst can already do this. I had "ByWater Basic" included as a demo program for a while, but as a Basic interpreter it is very slow, so I dropped it.
Ah, passing parameters in cog ram? Now *that* is a cunning plan!
That ought to be faster than passing via a text file.
So, how does that work? I presume you write to a specific cog?You are right about leaving out the file access code and saving space. So, if it is via cog ram, it could just be 80 bytes somewhere. How do you get it back out again?
The latest version of Catalyst also accepts .LMM, .SMM and .XMM and will use the appropriate loader for each. Why not reserve those in KyeDos to mean "launch this program with Catalyst?"
That sounds a perfect solution. I'll just change one line of code in vb.net so it copies to .xmm instead of .bin. And only a few lines of code in KyeDOS.
Ah, passing parameters in cog ram? Now *that* is a cunning plan!
The actual implementation is in Catalina\target\Catalina_CogStore.spin. The Hub RAM overhead is one long (at a predefined location in upper RAM).
From a C program launched from Catalyst, the implementation is built into the C runtime - the command line parameters appear in the normal C argc and argv arguments to your main function - i.e:
main(int argc, char *argv[]) {
// argc = parameter count,
// argv[i] = pointer to parameter i
...
}
You can also use it from a SPIN program launched from Catalyst. There is an example of doing so in Catalina\Catalyst\demos\Demo.spin.
I've just realized the Catalyst file I posted most recently (i.e. a few posts back in this thread) will not work without the other updated files in Catalina 2.8 - so while I'll implement the "text file" method of specifying a a command for auto-execution, you'll have to wait - probably till the weekend - for me to release a whole new updated version of Catalina 2.8 before you can use it.
So there is one location in hub ram? Maybe I got unlucky with the locations I picked at random? I don't know much about how hub ram is preserved during a reboot command.
So there is one location in hub ram? Maybe I got unlucky with the locations I picked at random? I don't know much about how hub ram is preserved during a reboot command.
Not sure what you mean. The location is specified by the constant COGSTORE in Catalina_Common.spin. See the file Catalina_CogStore.spin.
Sorry, its a bit complicated to explain what I mean. I guess in simple terms, how do you preserve variables between reboots? In other words, sure, the location might be specified by the constant COGSTORE, and sure, another program can have the same constant defined as well, but if hub ram gets corrupted between reboots it won't help. Even if you are preserving cog code, you have that one hub variable. How, for instance, would you preserve that if you loaded a hypothetical 32k program? Use the @@@ operator to fix a location in hub?
Anyway, I could not think of an answer to that so I used the SD card. This does have the advantage of making debugging easier, as you can take out the card and read it with a PC and see what the file actually is.
I'm deep inside the code translating an object into C. As a C expert, could you take a quick look at this code for me please?
unsigned long i; // most propeller code is unsigned longs
unsigned long j;
unsigned long dira_; // these are in a VAR section in the Spin code.
unsigned long dirb_;
unsigned long vcfg_;
unsigned long cnt_;
i = 0xff << (base_pin & 0x18); // i := $FF << (base_pin & %011000)
// not sure what this translates to, is %100000 == always 0 false // j := base_pin & %100000 == 0
dira_ = i & j; // dira_ := i & j
// is ! toggle, and what is the equivalent in c? is it xor // dirb_ := i & !j
vcfg_ = 0x300000ff + (base_pin & 0x38) << 6; // vcfg_ := $300000FF + (base_pin & %111000) << 6
// Ready cnt value to sync cogs by
cnt_ = cnt_ + 0x100000; // cnt_ := cnt + $100000
I have put the Spin code in the comment section. The original Spin code is largely uncommented and I've left in the ones that are there.
Binary values need to be changed to hex, as C can't do binary values, right?
The == in one line has me stumped. It is an equality test and in this particular form (ie with no IF or While), it is discussed on page 275 of my manual. But if you test for equality with two constants that are not equal, won't that always return False ?
Also I'm not sure about the ! operator. Is XOR the equivalent to this?
Sorry, its a bit complicated to explain what I mean. I guess in simple terms, how do you preserve variables between reboots?
Easy - don't reboot!
Catalyst doesn't reboot when it loads a program. It just loads the program in and then starts the SPIN interpreter, the same way a reboot would do (plus some messing about with the clock). The program being started never knows the difference. That's why Catalyst can pass information to the program via a cog - provided the program knows how to interrogate the CogStore (which is done via the single fixed hub location).
If the program you run does not know about the CogStore, it simply has no access to the command line. However, I decided that when a program being run exits, it should do a real reboot. This means it can't pass any information back to Catalyst. I could change this, but Catalyst is really only intended to function as a program loader, not an operating system. I'm happy to leave that particular project to others .
As for your code:
unsigned long i; // most propeller code is unsigned longs
unsigned long j;
unsigned long dira_; // these are in a VAR section in the Spin code.
unsigned long dirb_;
unsigned long vcfg_;
unsigned long cnt_;
i = 0xff << (base_pin & 0x18); // i := $FF << (base_pin & %011000)
j = (((base_pin & 0x20) == 0)?-1:0) // j := base_pin & %100000 == 0
dira_ = i & j; // dira_ := i & j
dirb_ = i & !j // dirb_ := i & !j
vcfg_ = 0x300000ff + (base_pin & 0x38) << 6; // vcfg_ := $300000FF + (base_pin & %111000) << 6
// Ready cnt value to sync cogs by
cnt_ = cnt_ + 0x100000; // cnt_ := cnt + $100000
Yes, C can't do binary constants - they have to be hex. Other than that, C and SPIN are reasonably compatible on expression evaluation. The expression x = a == b will set x to true if a equals b, or false othersiwse. If a and b are constants, then the result is also a constant - most C compilers will automatically replace the expression with a suitable constant (SPIN does not). And ! is the bitwise NOT operator.
EDIT: It looks to me like the line that sets "j" assumes TRUE = -1, which is true in SPIN but not in C (where TRUE = 1). So I have replaced my original with the ternary operator "?:"
Ross.
Thanks Ross. So catalyst would just check for that text file, if it exists, run it, if not then go to the command prompt? Hmm - if it did find a command.txt file, should it then delete that file? Otherwise you might never get to the command prompt >
Thanks for the C advice. Porting Spin to C is slow for the first object, but hopefully will be quicker each time, now that the building blocks are in place. I have a new admiration for all the code you already have done!
Thanks Ross. So catalyst would just check for that text file, if it exists, run it, if not then go to the command prompt? Hmm - if it did find a command.txt file, should it then delete that file? Otherwise you might never get to the command prompt >
Hi Dr_Acula,
If you want that behaviour, its a simple one-line change. I'll make it a compile-time option in Catalyst.
Comments
Sorry about the 128k - my mistake I guess it is because I coded that into my IDE and I've looked at it so many times I thought that was the number.
Lots of flexibility with all the models you support. The SPI ought to be similar to other SPI boards. I'm looking forward to some Catalina programming time this weekend. I've been trying out Kye's new SD card driver and it is a *lot* faster. Run a binary from the Kyedos prompt and it takes about 1.5 seconds to load and run. I don't know how he is getting data off the sd card into the propeller so fast. So I guess that is now another nifty bit of spin/pasm code that needs porting into C...
itself up from SD on Powerup?
What I want to do is write a C program ( which will require XMM due to its feature set ), and when the user turns the device on, it loads itself and intializes itself from the SD card, at which point, the user now
see a opening menu on a LCD screen.
I think the answer is yes, but I wasn't sure.
Related to your last answer on running C and spin, I understand that I can't run C and spin if the C is using XMM. I assume that applies to all cogs? Ie, I can't have a cog running a XMM C App
and a cog running spin?
I know there are cog commands in the latest releases, so while I can't run C and Spin, I can run different C "programs" on the different cogs. Anotherwards, I have the same functionality in an XMM C program of using multiple cogs for parallel
processing that I do under spin.
Do I have this correct?
Last question - in the documentation, you talk about possible purchasing of cog safe C functions such as Malloc. Is that possible, or a future possibility?
Thank you for your assistance and for catalina.
Bruce
I think it might already be answered above. I have a very similar request now that Kyedos is working. I'd like a binary file on the sd card that can run xmm catalina programs.
eg - in Spin the procedure is to hit F8, then "save as binary", then I rename "myfile.binary" to "myfile.exe" or "myfile.com" or myfile.bin", then put that on the sd card. This can then be run from Kyedos.
For XMM programs, I would imagine that the equivalent program contains a part that runs and then loads a larger part into external memory and then runs that. Catalyst can then run that program.
What I'm wondering is whether it is possible to create a program that contains catalyst within it? A bit like an autoextracting zip file.
Or maybe a way of passing the filename to catalyst as a command line (now that we have command line parameters working on Kyedos)? Or even pass parameters through as well? (The kyedos protocol is pretty simple - it just saves the command line as a single line text file "COMMAND.TXT" on the SD card, so all you would have to do is check if that exists and read it in and chop it up into the parameters).
Your thoughts would be most appreciated.
I think the best thing is to just use KyDos to autoload an instance of the Generic SD Card Loader program (or Catalyst, when I add this facility to that program), which would then autoload whatever file that program was configured to load on startup. While it seems a bit round-about, in reality this is probably the best and simplest option. Adding an SD card loader to the program itself wouldn't help much, since that program would then become larger than 32kb and would therefore itself require a special loader to be written.
Note that I have not yet added the ability to autoload programs that require command line parameters (I added command line parameters after I wrote the Generic SD Card Loader). I'll look at adding that facility in.
Ross.
Goodness Gracious, Dr_Acula! You didn't need to do that - but thanks very much. Most of it will probably go straight back to Parallax for the purchase of a C3 - but I heard you say in another thread that you are thinking of using SPI RAM on your next board - so you will ultimately benefit from your investment.
I'll also send you a copy of the Catalina Optimizer (actually, for a donation that size you can have 10 copies!) and I'll also polish up the various program loaders for you (and Bruce as well).
Ross.
Attached is a version of Catalyst which supports auto-execution. On boot, it will auto-execute the file AUTOEXEC.BIN if it exists it in the root directory of the SD Card. Otherwise it goes to the normal command line prompt. The file to be auto-executed can be a normal SPIN binary, or an LMM or an XMM C program. If you want to instead auto-execute a file with a different name, or pass parameters to it, just modify the AUTOFILE and AUTOARGS variables to whatever you need.
This version will be included in the next release. For the moment, simply overwrite your existing version (which is in the Catalina\catalyst\core subdirectory) and rebuild Catalyst.
Let me know if you have any problems.
Ross.
EDIT: Attachment removed. It is no use without the latest version of Catalina, which is yet to be released.
Compile to ram, or compile and download to the card with one keypress.
I've got variants of catalyst already on the card. Now I need to have a little think about how to "run" an XMM program from kyedos. Maybe it is as simple as kyedos creating the autoexec file and then running catalyst?
That was what I intended. Another option is to modify KyDos to execute Catalyst with command line parameters telling it what program to start. The reason I didn't do this was that it requires Catalyst and KyeDos to agree on the method of passing parameters. You could either adopt Catalyst's method (see Catalina\catalyst\demo\Demo.spin) or build a custom version of Catalyst that uses KyDos's method (I don't know what that method is).
If you decide to choose the former (i.e. adopt Catalyst's method), then I will modify Catalyst to execute the program specified in the command line arguments instead of always executing the same auto-exec file. This would only require a few minutes work, so let me know if you want this solution.
Ross.
As an aside, I've re-coded xmodem to run at 115200 baud. Using a demo C program in XMM, Payload compiles and downloads in 20 seconds. Xmodem compiles and downloads and saves to the sd card in 45 seconds.
So you have the best of both worlds - faster compilation to ram for quick and simple testing. And slower but permanent transfer of the same program to sd card but taking a bit longer.
In re-coding this I have been looking at the vb.net code for some time so I need to post this before I forget what is going on!
ResetPropeller() ' boot back into kyedos Sleep(3000) ' compile is faster than kyedos rebooting Compile_C() ' compile the program Download_C() ' download the fileThe Download_C does the following:
1) rename myfile.binary to myfile.bin
2) run xmodem - sends XMODEM R MYFILE.BIN<cr>
3) wait for 3 secs for Kyedos to restart
4) run CATLYST2.EXE which is the serial version of catalyst at 38400 baud (I must get around to recompiling a 115200 baud one). sends CATLYST2<cr>
5) wait 2 seconds for catalyst to start
6) sets baud rate to 38400
7) sends MYFILE<cr>
All this is possible because we are talking via the serial port. How would you do the same thing from within Kyedos?
The problem I have is finding something static when you run a new program. I thought some memory locations would stay static but they seemed to change. So I just save a command line on the sd card. The syntax seems almost identical to your syntax for catalyst.
Actually, I don't even have a syntax. If the user types "XMODEM R MYFILE.TXT<cr> then the file COMMAND.TXT contains a zero terminated string "XMODEM R MYFILE". It is up to the xmodem program to work out what that means, print out error messages etc.
So we could just use your syntax?
I guess the simplest command is to type:
CATLYST MYFILE
and catalyst would then run the XMM program MYFILE.BIN
But down the track one might want to pass a command line as well.
At the moment, if I type
CATLYST MYFILE PAR1 PAR2 PAR3
then there will be a file COMMAND.TXT on the sd card with the text
CATLYST MYFILE PAR1 PAR2 PAR3
Could Catalyst check if this exists and if so, process this in some way?
for example, this is the code in xmodem. And yes, it may do odd things if you don't type the command right, so maybe a better command line parser is needed, ie one that formally looks for spaces or something?
result := \fat.openfile(string("COMMAND.TXT"),"R") result := \fat.readstring(@commandline,80) ' read in the command line result := \fat.closefile i := str.len(@commandline) ' length of the string "XMODEM R MYFILE.TXT" str.mid(@commandline,@lineoftext1,8,1) ' get R or S rw := str.stringcompareci(@lineoftext1,string("R")) ' is it R or r then returns zero? if not then S or s str.mid(@commandline,@filename,10,i-9) ' get the filenameOk - that makes sense. The only thing guaranteed to be common between Catalyst and KyeDos (or any other OS for that matter) is the SD card itself, so let's use that.
Tonight I will modify Catalyst so that if it finds a file called COMMAND.TXT (or AUTOEXEC.TXT - I'll make it configurable so you can use whatever file name you want) on the SD card when it starts, it will read a line from the file and execute it as a Catalyst command line. Easy!
Ross.
C programs could run other C programs and pass parameters in the same way.
Just going off on a tangent I'm thinking of cool things to add to the Kyedos library. Do you know of any Basic interpreteters written in C89? Or Compilers? Or other languages for that matter? (There seems to be Python interpreters around written in C89. Would they work?) I've got all the ones in CP/M but they are inside CP/M and it would be a great to have some ones that run natively on the propeller rather than within CP/M.
And another thought. What is the extension for compiled C programs? I think you have used .BIN
I'm using .EXE for compiled Spin files. I could program KyeDOS so that if you type the name of a program that ends in .BIN, it runs Catalyst. So you don't have to type the catalyst bit.
Then big XMM C programs could seamlessly be integrated into the operating system as commands.
How cool would it be to have a file BASIC.BIN and you type BASIC<cr> and up comes a basic interpreter prompt?
Catalyst can already do this. I had "ByWater Basic" included as a demo program for a while, but as a Basic interpreter it is very slow, so I dropped it.
Ross.
That ought to be faster than passing via a text file.
So, how does that work? I presume you write to a specific cog?You are right about leaving out the file access code and saving space. So, if it is via cog ram, it could just be 80 bytes somewhere. How do you get it back out again?
That sounds a perfect solution. I'll just change one line of code in vb.net so it copies to .xmm instead of .bin. And only a few lines of code in KyeDOS.
I love this "brainstorming" coding!
The actual implementation is in Catalina\target\Catalina_CogStore.spin. The Hub RAM overhead is one long (at a predefined location in upper RAM).
From a C program launched from Catalyst, the implementation is built into the C runtime - the command line parameters appear in the normal C argc and argv arguments to your main function - i.e:
main(int argc, char *argv[]) { // argc = parameter count, // argv[i] = pointer to parameter i ... }You can also use it from a SPIN program launched from Catalyst. There is an example of doing so in Catalina\Catalyst\demos\Demo.spin.Ross.
I've just realized the Catalyst file I posted most recently (i.e. a few posts back in this thread) will not work without the other updated files in Catalina 2.8 - so while I'll implement the "text file" method of specifying a a command for auto-execution, you'll have to wait - probably till the weekend - for me to release a whole new updated version of Catalina 2.8 before you can use it.
Ross.
So there is one location in hub ram? Maybe I got unlucky with the locations I picked at random? I don't know much about how hub ram is preserved during a reboot command.
Not sure what you mean. The location is specified by the constant COGSTORE in Catalina_Common.spin. See the file Catalina_CogStore.spin.
Ross.
Anyway, I could not think of an answer to that so I used the SD card. This does have the advantage of making debugging easier, as you can take out the card and read it with a PC and see what the file actually is.
I'm deep inside the code translating an object into C. As a C expert, could you take a quick look at this code for me please?
I have put the Spin code in the comment section. The original Spin code is largely uncommented and I've left in the ones that are there.
Binary values need to be changed to hex, as C can't do binary values, right?
The == in one line has me stumped. It is an equality test and in this particular form (ie with no IF or While), it is discussed on page 275 of my manual. But if you test for equality with two constants that are not equal, won't that always return False ?
Also I'm not sure about the ! operator. Is XOR the equivalent to this?
Easy - don't reboot!
Catalyst doesn't reboot when it loads a program. It just loads the program in and then starts the SPIN interpreter, the same way a reboot would do (plus some messing about with the clock). The program being started never knows the difference. That's why Catalyst can pass information to the program via a cog - provided the program knows how to interrogate the CogStore (which is done via the single fixed hub location).
If the program you run does not know about the CogStore, it simply has no access to the command line. However, I decided that when a program being run exits, it should do a real reboot. This means it can't pass any information back to Catalyst. I could change this, but Catalyst is really only intended to function as a program loader, not an operating system. I'm happy to leave that particular project to others
As for your code:
unsigned long i; // most propeller code is unsigned longs unsigned long j; unsigned long dira_; // these are in a VAR section in the Spin code. unsigned long dirb_; unsigned long vcfg_; unsigned long cnt_; i = 0xff << (base_pin & 0x18); // i := $FF << (base_pin & %011000) j = (((base_pin & 0x20) == 0)?-1:0) // j := base_pin & %100000 == 0 dira_ = i & j; // dira_ := i & j dirb_ = i & !j // dirb_ := i & !j vcfg_ = 0x300000ff + (base_pin & 0x38) << 6; // vcfg_ := $300000FF + (base_pin & %111000) << 6 // Ready cnt value to sync cogs by cnt_ = cnt_ + 0x100000; // cnt_ := cnt + $100000Yes, C can't do binary constants - they have to be hex. Other than that, C and SPIN are reasonably compatible on expression evaluation. The expression x = a == b will set x to true if a equals b, or false othersiwse. If a and b are constants, then the result is also a constant - most C compilers will automatically replace the expression with a suitable constant (SPIN does not). And ! is the bitwise NOT operator.EDIT: It looks to me like the line that sets "j" assumes TRUE = -1, which is true in SPIN but not in C (where TRUE = 1). So I have replaced my original with the ternary operator "?:"
Ross.
Thanks for the C advice. Porting Spin to C is slow for the first object, but hopefully will be quicker each time, now that the building blocks are in place. I have a new admiration for all the code you already have done!
Hi Dr_Acula,
If you want that behaviour, its a simple one-line change. I'll make it a compile-time option in Catalyst.
Ross.