Why anyone would want to do so is another question.
Well, the reason that comes to my mind right away is that it takes forever to load these "large"
programs up... If I wanted to demo several programs, it would be a bit painful.
But, if I could have several of them on SD, it seems we could switch between them more quickly...
Actually, now that I think about this... There is already some way of executing a program from SD with Catalyst, right?
I think you mentioned once that is faster...
Yes, I know - my bad. I put it in the top level folder. I created a shortcut to it in the program Start menu. I made the installer display it at the conclusion of the installation process.
Well, the reason that comes to my mind right away is that it takes forever to load these "large"
programs up... If I wanted to demo several programs, it would be a bit painful.
But, if I could have several of them on SD, it seems we could switch between them more quickly...
Actually, now that I think about this... There is already some way of executing a program from SD with Catalyst, right?
I think you mentioned once that is faster...
Correct. While there will always be cases where you do need to load programs serially, anyone who has an SD Card should just load Catalyst into EEPROM permanently and the then load their programs from SD.
Loading a program any larger than a few hundred kilobytes serially will never be fast - even if I improve the speed of Payload.
If I did that, could I just have one program rename a file on the SD card to be whatever Catalyst is looking for and reboot?
Would that let me switch programs?
If I did that, could I just have one program rename a file on the SD card to be whatever Catalyst is looking for and reboot?
Would that let me switch programs?
Of course!
Catalyst will check on each boot for a file called AUTOEXEC.TXT. If this file exists, it will read one line from the file and execute that line as a Catalyst command. So just add in this file the name of the program you want to auto-execute.
Hey, this is good news! This might be a way to get programs running in Kyedos.
Let's see. I have a program called something (not sure - advice needed) but it is a large 200k binary program sitting on an sd card. Let's call it myprog.cat
I'd like to run this from Kyedos. So I type "myprog", and kyedos runs through its internal commands (not found) then all the .exe programs (not found) so it runs through the .cat programs and finds this program.
It then writes the filename to AUTOEXEC.TXT and then runs catalyst.
Catalyst then runs this program.
Next problem - where is catalyst running from?
You suggested catalyst could be in eeprom, but I have Kyedos in eeprom.
This is very exciting - how do you suggest we solve this? Is it as simple as putting Catalyst on the sd card?
And what extension do you suggest for compiled catalina programs (anything except .exe)?
Hey, this is good news! This might be a way to get programs running in Kyedos.
Let's see. I have a program called something (not sure - advice needed) but it is a large 200k binary program sitting on an sd card. Let's call it myprog.cat
I'd like to run this from Kyedos. So I type "myprog", and kyedos runs through its internal commands (not found) then all the .exe programs (not found) so it runs through the .cat programs and finds this program.
It then writes the filename to AUTOEXEC.TXT and then runs catalyst.
Catalyst then runs this program.
Next problem - where is catalyst running from?
You suggested catalyst could be in eeprom, but I have Kyedos in eeprom.
This is very exciting - how do you suggest we solve this? Is it as simple as putting Catalyst on the sd card?
And what extension do you suggest for compiled catalina programs (anything except .exe)?
Gosh, you really like making your life complicated, don't you
Catalyst can run from SD card. Just execute CATALYST.BIN.
Catalyst itself will execute any of the following extensions (note that everything except .SMM is just a convention):
.BIN Spin/PASM program (or LMM C program <= 32kb) .LMM LMM C program <= 32kb .SMM LMM C program <= 32kb, compiled to use the SDCARD loader .XMM XMM C program (LMM program > 32kb)
But this is complicated behind the scenes, simpler for the user, who only needs to type one command into Kyedos (the name of the program) not two ("Catalyst", then the name of the program). Also, don't need two versions of Catalyst (one for VGA, one for TV) because the user never sees the catalyst command line (not that I have anything against catalyst, just trying to get a two step process into a single step).
I can add a few lines of code into Kyedos so that it recognises .LMM, .SMM and .XMM and then shells catalyst.
But this is complicated behind the scenes, simpler for the user, who only needs to type one command into Kyedos (the name of the program) not two ("Catalyst", then the name of the program). Also, don't need two versions of Catalyst (one for VGA, one for TV) because the user never sees the catalyst command line (not that I have anything against catalyst, just trying to get a two step process into a single step).
I can add a few lines of code into Kyedos so that it recognises .LMM, .SMM and .XMM and then shells catalyst.
I think I'll just stick to Catalyst. It's a lot simpler. Perhaps I'm too old now to just enjoy complexity for its own sake.
I think I'll just stick to Catalyst. It's a lot simpler.
Well, I'm going to just call this one like it is. I checked out Catalyst. I even did that thing that no male is ever meant to do (I read the manual).
It is very good. In fact, it can do more than Kyedos. You have coded something very nice there. Indeed, you may perhaps be underselling this
(I have attached the instructions - in a nutshell Catalyst is an operating system for the Propeller)
Since this program can do so many things, including run compiled spin files PLUS compiled C files, I am now hooked.
I'm using TV and VGA about equally at the moment and Kyedos comes in both versions. Any chance of producing two versions of Catalyst for the dracblade - a TV version as well?
(Bog standard 40x13 TV driver, colors maybe white on blue, pins 16,17,18)
If you could, then this could be a really useful program for the dracblade. Thanks++
Also, possibly related question as I don't think we have tested TV much on the dracblade:
I'm using TV and VGA about equally at the moment and Kyedos comes in both versions. Any chance of producing two versions of Catalyst for the dracblade - a TV version as well?
(Bog standard 40x13 TV driver, colors maybe white on blue, pins 16,17,18)
If you could, then this could be a really useful program for the dracblade. Thanks++
Also, possibly related question as I don't think we have tested TV much on the dracblade:
I deliberately disable it because my DRACBLADE has no TV out. Is the TV out now stnadard? If so, I'll update my DRACBLADE config files for the next release.
In the meantime, it is easy to re-enable TV and configure the relevant files appropriately - I'll post a new set of configuration files and also a compiled version for you to try over the weekend.
Could you do me a favor and update that document to the version in release 3.3? This thread is about 3.3, but that document is from release 3.1.
Ok, fixed that.
Is the TV out now stnadard?
Yes, it changed in the last month or so. Not quite official yet as the boards are still being made and I had to design a new library object in Eagle for the RCA socket that Futurlec sell. Pin 16-18 for TV, and as before, pin 16-23 for VGA.
(There are some changes too with the ram and the SD pins and the 138 which ought to give a significant speedup, but I'll need to test some pasm code first when the boards arrive).
Just to check though, and I think I have asked this before, when the sd card is being accessed, the ram is not being accessed? In other words, the ram driver goes to sleep, the sd code starts up, reads in a block or whatever, then the ram restarts?
Hmm - come to think of it, I hope this new design will work. It does imply that if you are reading a 50k block of data from the sd card into external ram, that the sd card is going to need to be enabled, read block, disable, enable ram and copy block to ram, reenable sd card, read block, disable sd card, etc
Catalyst will check on each boot for a file called AUTOEXEC.TXT. If this file exists, it will read one line from the file and execute that line as a Catalyst command. So just add in this file the name of the program you want to auto-execute.
Ok, that sounds great. What I'd like to do is show a menu of the different programs on SD card and then have the user hit a key to launch them...
Yes, it changed in the last month or so. Not quite official yet as the boards are still being made and I had to design a new library object in Eagle for the RCA socket that Futurlec sell. Pin 16-18 for TV, and as before, pin 16-23 for VGA.
(There are some changes too with the ram and the SD pins and the 138 which ought to give a significant speedup, but I'll need to test some pasm code first when the boards arrive).
Just to check though, and I think I have asked this before, when the sd card is being accessed, the ram is not being accessed? In other words, the ram driver goes to sleep, the sd code starts up, reads in a block or whatever, then the ram restarts?
Hmm - come to think of it, I hope this new design will work. It does imply that if you are reading a 50k block of data from the sd card into external ram, that the sd card is going to need to be enabled, read block, disable, enable ram and copy block to ram, reenable sd card, read block, disable sd card, etc
Ok - easy enough to modify the TV configuration - I'll do that on the weekend. The XMM RAM code you may need to modify yourself.
Potential conflicts between accessing the SD card and XMM RAM is common on many board designs. Catalina's SD card driver and XMM kernel know about such things, so all should be well.
Ok, that sounds great. What I'd like to do is show a menu of the different programs on SD card and then have the user hit a key to launch them...
Do you see an easy way to implement that?
A couple of options ways, assuming Catalyst is in EEPROM:
1. Modify the Spin part of the Catalyst_XMM_SD_Loader.spin program (in the target directory) to present a menu of whatever it finds in the top level directory, or perhaps read a separate menu file. The advantage of this method is the menu will pop up on each reboot.
2. Write a standalone Spin or C "menu" program to present the options and allow a user to select one. Similar to the mechanism Dr_A proposed above, the program should allow the user to select the command (and perhaps enter any applicable parameters) then write the final command line to AUTOEXEC.TXT file and reboot the Prop. There is a Catalyst compile-time option (AUTODELETE) that can be set which will cause Catalyst to delete the AUTOEXEC.TXT file after each use (necessary to avoid infinite loops). The only disadvantage of this method is that you will return to the Catalyst command prompt after each menu selection - if you want to make another choice you will need to manually start the menu program again.
I'm trying to figure out if I can debug a "Large" program from within Code::Blocks...
Would it be easy to run the "sst" example in debug mode?
TINY, SMALL and LARGE are the memory modes. LMM, EMM, SMM, XMM are really more to do with the load option:
LMM: program <= 32k (i.e. TINY), one phase "Parallax" loader SMM: program <= 32k (i.e. TINY), two phase "SDCARD" loader EMM: program <= 32k (i.,e. TINY) two phase "EEPROM" loader (LMM version) EMM: program > 32k (i.e. SMALL or LARGE), two phase "EEPROM" loader (XMM version) XMM: program > 32k (could be either SMALL or LARGE), two phase "XMM" loader.
You can certainly debug the sst example - the debugger can debug any program, and supports TINY, SMALL or LARGE mode (the loader does not matter) - but unfortunately the debugger does not currently support debugging programs executing out of FLASH memory (I still have some work to do on that one). So you will need to instead debug them on a board with enough RAM to load the program. Also, be aware that debugging requires an extra cog.
@Rayman, we seem to be working on the same things.
Kyedos gives you a command prompt, and a signon prompt that says "type Help to see the instructions" and then from the help the user can see that by typing "dir *.exe" all the programs are there.
A bit old-skool though.
You can modify Kyedos if you like so that it automatically finds those programs and puts them in a list, and you could have '1 - display palette' and '2 - Run CP/M' etc, and then the user types 1 or 2 etc. Kyedos is just standard Spin.
Or you can use Catalyst as it is.
Or (??) you can modify Catalyst so it does what you want.
Or you can move over to icon/graphics based programs. The propeller is certainly capable of displaying icons - especially if you run them through a Floyd-Steinberg dithering algorithm - 32x32 icons look pretty good. Then use a mouse to click on the icon.
Or use a touchscreen.
Re all the different format LMM XMM etc, I wrote some demo programs to compile 'hello world' for each of these, but my programs tend to grow rather quickly so I use XMM pretty much all the time now. XMM means you don't have to worry about not having libraries because they might take up too much space. Just throw in the floating point library anyway!
Dr_Acula, I have noticed we are working on similar things. You seem to have a lot more free time than me though!
My current goal is to write up how to use Flashpoint modules and Catalina with:
Parallax Demo board
Parallax Proto board
Propeller Platform
PropBox
and any breadboard setup...
Well, we are working on very similar things! I see you have error diffusion working from Photoshop. I have an old version of Paint Shop which can't do this so I had to write the code myself in vb.net (translated from C). I should have checked your site first!!
Catalina should work well with your modules. Are you using the flashpoint to store a large working memory for a big scrollable graphics file, or are you using them as XMM ram for Catalina?
I was using them for graphics memory, but since Ross offered to add support for them to Catalina, I now think using them for running big C codes is also fun.
BTW: For PTP2, I have a Windows app that does error diffusion for TV, VGA, and PTP2 palettes...
BTW2: I like your CP/M machine. That was my first computer experience, so I may try to reproduce your setup one day...
BTW3: Perhaps now I have a quasi-legitimate (IRS approved) reason to write off a trip to the next Aussie expo and discuss Catalina with Ross
Big C programs are great. If Ross is going to add support for your modules that is another feather for Catalina's cap.
Re the CP/M machine it was a joint effort by many here - heater, cluso, pullmoll and many others. And I am sure we can make it faster...
I have this idea that maybe caching can help speed up memory. A question for Ross - if I have a program in XMM, how much of the hub memory is being used? I have a vague feeling that some is being used for stack at the top of memory, and also I suspect some is used for text for the screen. How much is free?
Big C programs are great. If Ross is going to add support for your modules that is another feather for Catalina's cap.
Already done! - it's part of release 3.3 (actually, it's the reason for 3.3). The only complication is that these modules are just XMM modules, not complete propeller boards - so you still have to "tweak" a few things to suit your own Propeller.
I think Rayman is working on individual versions of the configuration files to suit specific platforms, but anyone who has a RamPage or SuperQuad could do the same.
I have this idea that maybe caching can help speed up memory. A question for Ross - if I have a program in XMM, how much of the hub memory is being used? I have a vague feeling that some is being used for stack at the top of memory, and also I suspect some is used for text for the screen. How much is free?
Caching can indeed speed up slow or serial access XMM RAM (such as SPI RAM or FLASH). But it is usually slower than fast parallel access XMM RAM.
As to how much Hub RAM is free - that's difficult. There's several aspects to answering this question, and I can't give you a precise answer since it depends on so many things. But here are the main factors:
First, the top few hundred bytes in ALL Catalina programs are used for specific things (such as the registry).
Next, it will depend on the plugins you compile with, since all plugin data (e.g. keyboard or screen buffers, SD card sector buffers etc) is in Hub RAM. The specific plugin also matters - Hi Res VGA takes much more Hub RAM for the screen buffer than does LoRes TV.
Next, is your XMM program SMALL or LARGE?
SMALL programs have only the code in XMM RAM, and everything else is in Hub RAM. This includes:
constant data space (mostly strings and initializers);
variable data space (mostly global variables);
stack space;
heap space (if your program uses malloc).
LARGE programs have the code, data and heap in XMM RAM, but the stack is still in Hub RAM. How much stack space will your program need? I have no idea!
Next, is your program cached or not? CACHED programs will use an additional amount of Hub RAM as specified by the CACHED option used:
Ross, regarding debug stuff... I haven't tried yours yet, but it sounds like there may be an issue for very, very large programs that won't fit in sram...
One kinda debug thing I see a lot is just to output a string to say where your code is...
Something like:
#ifdef debug
cout<<"here's where I am"
#endif
Is something like this possible with "large" and "cached" Catalina?
Ross, regarding debug stuff... I haven't tried yours yet, but it sounds like there may be an issue for very, very large programs that won't fit in sram...
One kinda debug thing I see a lot is just to output a string to say where your code is...
Something like:
#ifdef debug
cout<<"here's where I am"
#endif
Is something like this possible with "large" and "cached" Catalina?
Sure. Add the following code to your program:
#ifdef DEBUG
t_printf("here's where I am\n");
#endif
Then compile your program like so:
catalina hello_world.c -lc -W-DDEBUG
If you want to know why I use -W-DDEBUG here, see page 87 in the Catalina Reference Manual (if I had used -D DEBUG instead, I would have had to say #ifdef __CATALINA_DEBUG)
Does that mean you have already thought of caching. And have something working?
If so, I'd be interested to see what algorithm you are using. The reason I ask is that the new design I'm working on (which started as the high res graphics driver) has blocks of 256 bytes which may lead to some optimisations that might be possible reading in groups of 256 bytes in one block rather than individual bytes one at a time.
Does that mean you have already thought of caching. And have something working?
You know Dr_A, sometimes I wonder why I bother writing any documents or posting here at all. It is becoming increasingly obvious that very few people actually read what I post
Perhaps I should try shouting ...
CATALINA HAS HAD FULLY CONFIGURABLE CACHING ON ALL XMM PLATFORMS SINCE VERSION 3.0
THE CACHE SIZE CAN BE 1K, 2K, 4K or 8K.
THE CACHE IS BASED ON BILL HENNING'S VMCOG
CACHING WILL SPEED UP XMM ACCESS ON THOSE PLATFORMS THAT HAVE SLOW XMM RAM (E.G. SPI RAM).
CACHING IS REQUIRED ON PLATFORMS THAT USE FLASH RAM AS XMM (E.G. THE C3 AND THE FLASHPOINT MODULES)
Sorry Ross, I missed that one. I see it is on the post from 1st April in the Catalina 3.0 thread.
I checked out the VMCOG thread - there were a few posts saying the dracblade was not supported for caching, but the second to last post contains some code from David Betz. Is this the code you have used?
Sorry Ross, I missed that one. I see it is on the post from 1st April in the Catalina 3.0 thread.
I checked out the VMCOG thread - there were a few posts saying the dracblade was not supported for caching, but the second to last post contains some code from David Betz. Is this the code you have used?
Yes, I based my code on a version that I think Jazzed and David both worked on. It works on the DracBlade.
Comments
Well, the reason that comes to my mind right away is that it takes forever to load these "large"
programs up... If I wanted to demo several programs, it would be a bit painful.
But, if I could have several of them on SD, it seems we could switch between them more quickly...
Actually, now that I think about this... There is already some way of executing a program from SD with Catalyst, right?
I think you mentioned once that is faster...
Yes, I know - my bad. I put it in the top level folder. I created a shortcut to it in the program Start menu. I made the installer display it at the conclusion of the installation process.
You'd think I didn't want people to find it!
Ross.
Correct. While there will always be cases where you do need to load programs serially, anyone who has an SD Card should just load Catalyst into EEPROM permanently and the then load their programs from SD.
Loading a program any larger than a few hundred kilobytes serially will never be fast - even if I improve the speed of Payload.
Ross.
Would that let me switch programs?
Of course!
Catalyst will check on each boot for a file called AUTOEXEC.TXT. If this file exists, it will read one line from the file and execute that line as a Catalyst command. So just add in this file the name of the program you want to auto-execute.
Ross.
Let's see. I have a program called something (not sure - advice needed) but it is a large 200k binary program sitting on an sd card. Let's call it myprog.cat
I'd like to run this from Kyedos. So I type "myprog", and kyedos runs through its internal commands (not found) then all the .exe programs (not found) so it runs through the .cat programs and finds this program.
It then writes the filename to AUTOEXEC.TXT and then runs catalyst.
Catalyst then runs this program.
Next problem - where is catalyst running from?
You suggested catalyst could be in eeprom, but I have Kyedos in eeprom.
This is very exciting - how do you suggest we solve this? Is it as simple as putting Catalyst on the sd card?
And what extension do you suggest for compiled catalina programs (anything except .exe)?
Gosh, you really like making your life complicated, don't you
Catalyst can run from SD card. Just execute CATALYST.BIN.
Catalyst itself will execute any of the following extensions (note that everything except .SMM is just a convention):
.LMM LMM C program <= 32kb
.SMM LMM C program <= 32kb, compiled to use the SDCARD loader
.XMM XMM C program (LMM program > 32kb)
But this is complicated behind the scenes, simpler for the user, who only needs to type one command into Kyedos (the name of the program) not two ("Catalyst", then the name of the program). Also, don't need two versions of Catalyst (one for VGA, one for TV) because the user never sees the catalyst command line (not that I have anything against catalyst, just trying to get a two step process into a single step).
I can add a few lines of code into Kyedos so that it recognises .LMM, .SMM and .XMM and then shells catalyst.
I think I'll just stick to Catalyst. It's a lot simpler. Perhaps I'm too old now to just enjoy complexity for its own sake.
Well, I'm going to just call this one like it is. I checked out Catalyst. I even did that thing that no male is ever meant to do (I read the manual).
It is very good. In fact, it can do more than Kyedos. You have coded something very nice there. Indeed, you may perhaps be underselling this
(I have attached the instructions - in a nutshell Catalyst is an operating system for the Propeller)
Since this program can do so many things, including run compiled spin files PLUS compiled C files, I am now hooked.
I'm using TV and VGA about equally at the moment and Kyedos comes in both versions. Any chance of producing two versions of Catalyst for the dracblade - a TV version as well?
(Bog standard 40x13 TV driver, colors maybe white on blue, pins 16,17,18)
If you could, then this could be a really useful program for the dracblade. Thanks++
Also, possibly related question as I don't think we have tested TV much on the dracblade:
=================== SETTING UP CATALINA =================== CATALINA_DEFINE = [default] CATALINA_INCLUDE = [default] CATALINA_LIBRARY = [default] CATALINA_TARGET = [default] CATALINA_LCCOPT = [default] CATALINA_TEMPDIR = [default] LCCDIR = "C:\Program Files\Catalina" catalina -lcx -D PLUGIN -x5 -M 512k -D DRACBLADE -D SHARED_XMM -D HIRES_TV -D NTSC NEW.C Catalina Compiler 3.1 Homespun Spin Compiler 0.30 parsing C:\Program Files\Catalina\target\xmm_default.spin parsing C:\Program Files\Catalina\target\Catalina_Common.spin parsing C:\Program Files\Catalina\target\Cache.spin parsing C:\Program Files\Catalina\target\Command_Line.spin parsing C:\Program Files\Catalina\target\Catalina_CogStore.spin parsing C:\Program Files\Catalina\target\Floating_Point.spin parsing C:\Program Files\Catalina\target\Catalina_Float32_A_Plugin.spin parsing C:\Program Files\Catalina\target\SD_Card.spin parsing C:\Program Files\Catalina\target\Catalina_SD_Plugin.spin parsing C:\Program Files\Catalina\target\Clock.spin parsing C:\Program Files\Catalina\target\HMI.spin Error: HMI.spin (108, 11): Expected object file name ERROR : HMI OPTION NOT SUPPORTED ON THE SPECIFIED PLATFORM ^I deliberately disable it because my DRACBLADE has no TV out. Is the TV out now stnadard? If so, I'll update my DRACBLADE config files for the next release.
In the meantime, it is easy to re-enable TV and configure the relevant files appropriately - I'll post a new set of configuration files and also a compiled version for you to try over the weekend.
Ross.
Ok, fixed that.
Yes, it changed in the last month or so. Not quite official yet as the boards are still being made and I had to design a new library object in Eagle for the RCA socket that Futurlec sell. Pin 16-18 for TV, and as before, pin 16-23 for VGA.
(There are some changes too with the ram and the SD pins and the 138 which ought to give a significant speedup, but I'll need to test some pasm code first when the boards arrive).
Just to check though, and I think I have asked this before, when the sd card is being accessed, the ram is not being accessed? In other words, the ram driver goes to sleep, the sd code starts up, reads in a block or whatever, then the ram restarts?
Hmm - come to think of it, I hope this new design will work. It does imply that if you are reading a 50k block of data from the sd card into external ram, that the sd card is going to need to be enabled, read block, disable, enable ram and copy block to ram, reenable sd card, read block, disable sd card, etc
Ok, that sounds great. What I'd like to do is show a menu of the different programs on SD card and then have the user hit a key to launch them...
Do you see an easy way to implement that?
Is EMM==Tiny, LMM==Small, and XMM==Large?
I'm trying to figure out if I can debug a "Large" program from within Code::Blocks...
Would it be easy to run the "sst" example in debug mode?
Ok - easy enough to modify the TV configuration - I'll do that on the weekend. The XMM RAM code you may need to modify yourself.
Potential conflicts between accessing the SD card and XMM RAM is common on many board designs. Catalina's SD card driver and XMM kernel know about such things, so all should be well.
Ross.
A couple of options ways, assuming Catalyst is in EEPROM:
1. Modify the Spin part of the Catalyst_XMM_SD_Loader.spin program (in the target directory) to present a menu of whatever it finds in the top level directory, or perhaps read a separate menu file. The advantage of this method is the menu will pop up on each reboot.
2. Write a standalone Spin or C "menu" program to present the options and allow a user to select one. Similar to the mechanism Dr_A proposed above, the program should allow the user to select the command (and perhaps enter any applicable parameters) then write the final command line to AUTOEXEC.TXT file and reboot the Prop. There is a Catalyst compile-time option (AUTODELETE) that can be set which will cause Catalyst to delete the AUTOEXEC.TXT file after each use (necessary to avoid infinite loops). The only disadvantage of this method is that you will return to the Catalyst command prompt after each menu selection - if you want to make another choice you will need to manually start the menu program again.
Ross.
TINY, SMALL and LARGE are the memory modes. LMM, EMM, SMM, XMM are really more to do with the load option:
SMM: program <= 32k (i.e. TINY), two phase "SDCARD" loader
EMM: program <= 32k (i.,e. TINY) two phase "EEPROM" loader (LMM version)
EMM: program > 32k (i.e. SMALL or LARGE), two phase "EEPROM" loader (XMM version)
XMM: program > 32k (could be either SMALL or LARGE), two phase "XMM" loader.
Ross.
Debugging requires an extra cog. That was my next question!
Can't debug flash. But, you can debug from sram. But, I think sst is too big to fit in RamPage's sram, right?
Well, it's not such a big deal since I can debug that program within Visual Studio...
Kyedos gives you a command prompt, and a signon prompt that says "type Help to see the instructions" and then from the help the user can see that by typing "dir *.exe" all the programs are there.
A bit old-skool though.
You can modify Kyedos if you like so that it automatically finds those programs and puts them in a list, and you could have '1 - display palette' and '2 - Run CP/M' etc, and then the user types 1 or 2 etc. Kyedos is just standard Spin.
Or you can use Catalyst as it is.
Or (??) you can modify Catalyst so it does what you want.
Or you can move over to icon/graphics based programs. The propeller is certainly capable of displaying icons - especially if you run them through a Floyd-Steinberg dithering algorithm - 32x32 icons look pretty good. Then use a mouse to click on the icon.
Or use a touchscreen.
Re all the different format LMM XMM etc, I wrote some demo programs to compile 'hello world' for each of these, but my programs tend to grow rather quickly so I use XMM pretty much all the time now. XMM means you don't have to worry about not having libraries because they might take up too much space. Just throw in the floating point library anyway!
What board are you using?
My current goal is to write up how to use Flashpoint modules and Catalina with:
Parallax Demo board
Parallax Proto board
Propeller Platform
PropBox
and any breadboard setup...
Well, we are working on very similar things! I see you have error diffusion working from Photoshop. I have an old version of Paint Shop which can't do this so I had to write the code myself in vb.net (translated from C). I should have checked your site first!!
Catalina should work well with your modules. Are you using the flashpoint to store a large working memory for a big scrollable graphics file, or are you using them as XMM ram for Catalina?
BTW: For PTP2, I have a Windows app that does error diffusion for TV, VGA, and PTP2 palettes...
BTW2: I like your CP/M machine. That was my first computer experience, so I may try to reproduce your setup one day...
BTW3: Perhaps now I have a quasi-legitimate (IRS approved) reason to write off a trip to the next Aussie expo and discuss Catalina with Ross
Re the CP/M machine it was a joint effort by many here - heater, cluso, pullmoll and many others. And I am sure we can make it faster...
I have this idea that maybe caching can help speed up memory. A question for Ross - if I have a program in XMM, how much of the hub memory is being used? I have a vague feeling that some is being used for stack at the top of memory, and also I suspect some is used for text for the screen. How much is free?
I think Rayman is working on individual versions of the configuration files to suit specific platforms, but anyone who has a RamPage or SuperQuad could do the same.
Caching can indeed speed up slow or serial access XMM RAM (such as SPI RAM or FLASH). But it is usually slower than fast parallel access XMM RAM.
As to how much Hub RAM is free - that's difficult. There's several aspects to answering this question, and I can't give you a precise answer since it depends on so many things. But here are the main factors:
First, the top few hundred bytes in ALL Catalina programs are used for specific things (such as the registry).
Next, it will depend on the plugins you compile with, since all plugin data (e.g. keyboard or screen buffers, SD card sector buffers etc) is in Hub RAM. The specific plugin also matters - Hi Res VGA takes much more Hub RAM for the screen buffer than does LoRes TV.
Next, is your XMM program SMALL or LARGE?
- SMALL programs have only the code in XMM RAM, and everything else is in Hub RAM. This includes:
- constant data space (mostly strings and initializers);
- variable data space (mostly global variables);
- stack space;
- heap space (if your program uses malloc).
- LARGE programs have the code, data and heap in XMM RAM, but the stack is still in Hub RAM. How much stack space will your program need? I have no idea!
Next, is your program cached or not? CACHED programs will use an additional amount of Hub RAM as specified by the CACHED option used:- CACHED_1K requires 1kb
- CACHED_2K requires 2kb
- CACHED_2K requires 2kb
- CACHED (same as CACHED_8K) requires 8kb
Ross.One kinda debug thing I see a lot is just to output a string to say where your code is...
Something like:
#ifdef debug
cout<<"here's where I am"
#endif
Is something like this possible with "large" and "cached" Catalina?
Sure. Add the following code to your program:
#ifdef DEBUG t_printf("here's where I am\n"); #endifThen compile your program like so:If you want to know why I use -W-DDEBUG here, see page 87 in the Catalina Reference Manual (if I had used -D DEBUG instead, I would have had to say #ifdef __CATALINA_DEBUG)
Ross.
Re
Does that mean you have already thought of caching. And have something working?
If so, I'd be interested to see what algorithm you are using. The reason I ask is that the new design I'm working on (which started as the high res graphics driver) has blocks of 256 bytes which may lead to some optimisations that might be possible reading in groups of 256 bytes in one block rather than individual bytes one at a time.
You know Dr_A, sometimes I wonder why I bother writing any documents or posting here at all. It is becoming increasingly obvious that very few people actually read what I post
Perhaps I should try shouting ...
THE CACHE SIZE CAN BE 1K, 2K, 4K or 8K.
THE CACHE IS BASED ON BILL HENNING'S VMCOG
CACHING WILL SPEED UP XMM ACCESS ON THOSE PLATFORMS THAT HAVE SLOW XMM RAM (E.G. SPI RAM).
CACHING IS REQUIRED ON PLATFORMS THAT USE FLASH RAM AS XMM (E.G. THE C3 AND THE FLASHPOINT MODULES)
Ross.
I checked out the VMCOG thread - there were a few posts saying the dracblade was not supported for caching, but the second to last post contains some code from David Betz. Is this the code you have used?
Yes, I based my code on a version that I think Jazzed and David both worked on. It works on the DracBlade.
Ross.