A couple of quick questions; I need to understand the registry a bit better. The code for the registry "C" interface appears to be written in assembly, and there are multiple copies which makes it difficult to track down exactly what is going on.
eg: for example, why is _status_of_plugin(int cog_id) returning void in "catalina_plugin.h" ?
I want to run "test_registry.c" in the demos library, for example, to work this out myself -- I compiled it and loaded it successfully, but the serial line output doesn't produce any output;
Given that Gadget Gangster, as deliviered, has no screen, etc. my only choice is serial line for right now. What do I do to get the HMI driver to redirect to the serial port for both input and for output? eg: so I can use scanf() and t_printf() or printf(), etc.
Is there a particular platform that I should compile for, or do I need to set a new one up -- and how are the baudrates determined?
The _status_of_plugin function was never implemented since it is plugin-dependent. I will remove it in the next release. For most plugins, it is easier to check for yourself by looking in the registry.
To redirect stdin and stdout to the serial port, you use the PC HMI plugin - i.e. compile with -D PC. This works on any platform. The baudrates are determined in the files Catalina_PC_Keyboard.spin and Catalina_PC_Text.spin (I really should update these to use the baud rates specified in Catalina_Common_Input.spin).
Thanks. We're getting closer. I am able to get catalina to redirect compiled output to serial by using -D PC. However, it appears to be executing some kind of loop for it continuously prints garbage to the serial port instead of just one message;
eg:
catalina -b -ab -lc -lm -D PC hello_world.c
payload hello_world.binary
The garbage printed changes form if I change baud rates in Catalina_PC_Text.spin, and the kind of characters track with the baudrate in nanocom, so I know that the program is working the serial port -- but no baud rate I choose makes it at all human intelligible. I figured this might be a problem with the GG's frequency -- since I have a 5MHz crystal in the GG, so I edited Catalina_Common_Input.spin -- and changed the settings for "Hydra" to 5MHz, && PLL=80MHz, since the comments say Hydra is the default compile platform -- but it still doesn't improve anything.
What would cause a program designed to only print one string "hello world" to continuously output information to the serial port?
Is that a debugger hook or something?
I'm just about to go out of internet range for another week, so I won't be much help - but I suggest you modify the CUSTOM section of Catalina_Common_Input.spin to suit your needs (and then use -D CUSTOM) on the command line.
The DEFAULT settings are the same as the HYDRA settings, but they are a simple copy - and the HYDRA settings are only used if -D HYDRA is specified on the command line.
i currently have some issues with the different Memory Models..
Currently my Code is about 400 lines long and after compiling with the "build_all HYDRA DOUBLE_BUFFER" my binaries are 18kb 44kb and 45 kb.
But it seems like my code is to big for Propeller using the 128kGame Card and i dont know why.
Here is a working copy of the code (cant attach it for some reason :<)
#include "catalina_graphics.h"
#include "catalina_hmi.h"
#include <stdlib.h>
//#include <stdio.h>
#include <catalina_cog.h>
#include "LMM_array.h"
#define CLKPIN_MASK 0x8
#define LATCHPIN_MASK 0x10
#define DATAPIN_MASK 0x20
#define DATAPIN_MASKR 0x40
#define LOW 0
#define DOWN_RIGHT 0
#define UP_RIGHT 1
#define DOWN_LEFT 2
#define UP_LEFT 3
// these macros provide an easy means of scaling the X, Y coordinates when
// we change x or y tile size - this is done to retain the proportions of
// the original demo on different screen sizes.
//
// Ideally, we should scale like this ...
//
// #define X(n) ((n)*x_tiles/16)
// #define Y(n) ((n)*y_tiles/12)
//
// ... but that makes the code too large, so instead we just hardcode the
// x_tiles and y_tiles values:
//
#define X(n) ((n)*15/16)
#define Y(n) ((n)*10/12)
static unsigned reg = 0;
static unsigned reg2 = 0;
int C_coginit (void func(void), unsigned long *stack) {
int cog;
struct {
unsigned long REG1;
unsigned long PC;
unsigned long SP;
} cog_data;
cog_data.REG1 = _registry(); // regisrtry address
cog_data.PC = (unsigned long)func; // address of C function
cog_data.SP = (unsigned long)stack; // top of stack
cog = _coginit((int)&cog_data>>2, (int)LMM_array>>2, ANY_COG);
_waitcnt(_cnt() + 10000); // small delay for cog to initialize
return cog;
}
void init_gamepad(void)
{
unsigned i;
unsigned savereg;
/*
Setting I/O
*/
_dira(CLKPIN_MASK | LATCHPIN_MASK | DATAPIN_MASK, CLKPIN_MASK | LATCHPIN_MASK);
_outa(LATCHPIN_MASK, LOW);
while(1) {
_outa(LATCHPIN_MASK, LATCHPIN_MASK);
//Set LATCH HIGH
_waitcnt(_cnt() + 500);
//Wait till Counter reaches _cnt() + 500
if(DATAPIN_MASK & _ina() ) {
reg = 0;
}
else
{
reg = 1;
}
//Reads first bit inside _ina(), show 0 or 1
_waitcnt(_cnt() + 500);
_outa(LATCHPIN_MASK, LOW);
//set LATCH LOW ("clear")
for(i = 0; i<8; i++) {
_outa(CLKPIN_MASK, CLKPIN_MASK);
_waitcnt(_cnt() + 500);
if(DATAPIN_MASK & _ina()) {
savereg = reg;
reg = 0 << (i+1);
reg = savereg | reg;
}else {
savereg = reg;
reg = 1 << (i+1);
reg = savereg | reg;
}
_outa(CLKPIN_MASK, LOW);
_waitcnt(_cnt() + 500);
}
//printf("%x\n", reg);
_waitcnt(_cnt() + 1000000);
}
}
void init_gamepad2(void)
{
unsigned i;
unsigned savereg;
/*
Setting I/O
*/
_dira(CLKPIN_MASK | LATCHPIN_MASK | DATAPIN_MASKR, CLKPIN_MASK | LATCHPIN_MASK);
_outa(LATCHPIN_MASK, LOW);
while(1) {
_outa(LATCHPIN_MASK, LATCHPIN_MASK);
//Set LATCH HIGH
_waitcnt(_cnt() + 500);
//Wait till Counter reaches _cnt() + 500
if(DATAPIN_MASKR & _ina() ) {
reg2 = 0;
}
else
{
reg2 = 1;
}
//Reads first bit inside _ina(), show 0 or 1
_waitcnt(_cnt() + 500);
_outa(LATCHPIN_MASK, LOW);
//set LATCH LOW ("clear")
for(i = 0; i<8; i++) {
_outa(CLKPIN_MASK, CLKPIN_MASK);
_waitcnt(_cnt() + 500);
if(DATAPIN_MASKR & _ina()) {
savereg = reg2;
reg2 = 0 << (i+1);
reg2 = savereg | reg;
}else {
savereg = reg2;
reg2 = 1 << (i+1);
reg2 = savereg | reg2;
}
_outa(CLKPIN_MASK, LOW);
_waitcnt(_cnt() + 500);
}
//printf("%x\n", reg);
_waitcnt(_cnt() + 1000000);
}
}
void main() {
int x_tiles = cgi_x_tiles();
int y_tiles = cgi_y_tiles();
long mousex = 0, mousey = 0;
// this structure is used to hold graphics variables - especially when
// it is required that such variables be in Hub RAM when we use XMM:
g_var gv;
int test = 1;
int YofR = 0;
int YofL = 0;
int xball =10;
int yball =-5;
int direction=0; //The direction the Ball is going
int cog = 0;
int cog2 = 0;
register int i, j, k;
//int kk, dx, dy, pp, pq, rr, numx, numchr;
char pchip[5] = "DEMO"; // text
// this is defined locally so it exists in Hub RAM even for XMM programs:
unsigned long stack[20];
unsigned long stack2[40];
cog = C_coginit(&init_gamepad, &stack[20]);
cog2 = C_coginit(&init_gamepad2, &stack2[40]);
//direction = direction();
// setup graphics
g_setup(&gv, x_tiles*8, y_tiles*8, DOUBLE_BUFFER);
direction=0;
while (1) {
switch(reg)
{
case 0x1:
//printf("KEY A IS PRESSED\n");
if(test == 0) {
test = 1;
} else {
test = 0;
}
break;
/*case 0x2:
//printf("KEY B IS PRESSED\n");
break;
case 0x4:
//printf("KEY SELECT IS PRESSED\n");
break;*/
case 0x8:
//printf("KEY START IS PRESSED\n");
break;
case 0x10:
//printf("KEY UP IS PRESSED\n");
if((YofL+40)<105) {
YofL++;
}
break;
case 0x20:
//printf("KEY DOWN IS PRESSED\n");
if(YofL>-30) {
YofL--;
}
break;
/*case 0x40:
//printf("KEY LEFT IS PRESSED\n");
xa--;
break;
case 0x80:
//printf("KEY RIGHT IS PRESSED\n");
xa++;
break;*/
case 0x0:
//printf("NO KEY PRESSED\n");
break;
}
switch(reg2)
{
case 0x1:
//printf("KEY A IS PRESSED\n");
if(test == 0) {
test = 1;
} else {
test = 0;
}
break;
/*case 0x2:
//printf("KEY B IS PRESSED\n");
break;
case 0x4:
//printf("KEY SELECT IS PRESSED\n");
break;*/
case 0x8:
//printf("KEY START IS PRESSED\n");
break;
case 0x10:
//printf("KEY UP IS PRESSED\n");
if((YofR+40)<105) {
YofR++;
}
break;
case 0x20:
//printf("KEY DOWN IS PRESSED\n");
if(YofR>-30) {
YofR--;
}
break;
/*case 0x40:
//printf("KEY LEFT IS PRESSED\n");
xa--;
break;
case 0x80:
//printf("KEY RIGHT IS PRESSED\n");
xa++;
break;*/
case 0x0:
//printf("NO KEY PRESSED\n");
break;
}
// clear display
g_clear(&gv);
if(test == 0) {
g_colorwidth(&gv,3,20);
g_box(&gv, X(-125),Y(-50),235,120);
//***
//PLAYER LEFT
g_colorwidth(&gv,14,5);
g_box(&gv, X(-125), Y(YofL-20), 10, 40);
//***
//Player RIGHT
g_colorwidth(&gv,14,5);
g_box(&gv, X(+115), Y(YofR-20), 10, 40);
switch(direction) {
case DOWN_RIGHT:
xball++;
yball--;
if(yball<-40){
direction=UP_RIGHT;
}
if(xball>100){
if(yball>Y(YofR-20) && yball <(Y(YofR-20)+40)) {
direction=DOWN_LEFT;
} else {
xball=0;
yball=0;
direction=DOWN_LEFT;
}
}
break;
case UP_RIGHT:
xball++;
yball++;
if(yball>73){
direction=DOWN_RIGHT;
}
if(xball>100){
if(yball>Y(YofR-20) && yball <(Y(YofR-20)+40)) {
direction=UP_LEFT;
} else {
xball=0;
yball=0;
direction=DOWN_RIGHT;
}
}
break;
case DOWN_LEFT:
xball--;
yball--;
if(yball<-40){
direction=UP_LEFT;
}
if(xball<-107){
if(yball>Y(YofL-20) && yball <(Y(YofL-20)+40)) {
direction=DOWN_RIGHT;
} else {
xball=0;
yball=0;
direction=UP_LEFT;
}
}
break;
case UP_LEFT:
xball--;
yball++;
if(yball>73){
direction=DOWN_LEFT;
}
if(xball<-107){
if(yball>Y(YofL-20) && yball <(Y(YofL-20)+40)) {
direction=UP_RIGHT;
} else {
xball=0;
yball=0;
direction=DOWN_LEFT;
}
}
break;
}
g_colorwidth(&gv,14,5);
g_box(&gv,xball,yball,7,7);
} else {
g_colorwidth(&gv,14,5);
//S
g_box(&gv,-56,28,14,7);
g_box(&gv,-63,21,7,7);
g_box(&gv,-56,14,7,7);
g_box(&gv,-49,7,7,7);
g_box(&gv,-63,0,14,7);
/*
//T
g_box(&gv,-35,28,21,7);
g_box(&gv,-28,0,7,28);
//A
g_box(&gv,0,28,7,7);
g_box(&gv,-7,0,7,28);
g_box(&gv,0,14,7,7);
g_box(&gv,7,0,7,28);
//R
g_box(&gv,21,0,7,35);
g_box(&gv,28,28,14,7);
g_box(&gv,35,21,7,7);
g_box(&gv,28,14,7,7);
g_box(&gv,35,0,7,14);
//T
g_box(&gv,49,28,21,7);
g_box(&gv,56,0,7,28);
*/
//!
g_box(&gv,77,14,7,21);
g_box(&gv,77,0,7,7);
}
// copy bitmap to display (if double buffering)
g_copy(&gv, NULL);
// increment counter that makes everything change
k++;
}
}
This should output a working copy of a pong like game played with 2 NES Controllers it uses our selfmade Gamepad Driver written in C (see init_gamepad function)
It currently has some issues for example Controller0 can control Controller1 and the input of the keys seems to be unsmooth .. maybe someone has a helping idea about that..
Second it has a "little" memory problem actully i cant add anything more to the code without having the problem of not running anymore. It is compiled with the method above..
Maybe someone can help me with the following:
* making the Code smaller or better fitting for catalina (I dont know how :<)
* looking over the gamepad driver if someone has any idea
But for the Gamepad driver i think Paxi is making a thread the next days ...
RossH is out of internet range (see his last post).
I'm writing C using the Dracblade external memory, as I have very quickly run out of memory using just the propeller. This is the command line for the Dracblade - maybe it will provide a clue?
I have just recently gotten Catalina 2.8 up and running on a Zipit. I've built a custom target for the ASC and successfully compiled and loaded the graphics demo. What I'm kind of stuck on now is the EMM concept and how to implement it. I want to see if a larger-than-32k Catalina program can be loaded and run from the 64k EEPROM on the ASC+. Is this possible with a standard pin 28-29 EEPROM connection? I understand a loader program has to be run from the prop, but I get lost after that.
--EDIT--
Ahhh, Catalina has a reference manual.... {ahem} Which was hidden in plain sight.
i currently have some issues with the different Memory Models..
Currently my Code is about 400 lines long and after compiling with the "build_all HYDRA DOUBLE_BUFFER" my binaries are 18kb 44kb and 45 kb.
But it seems like my code is to big for Propeller using the 128kGame Card and i dont know why.
Hi wuut,
I'm back from my break.
Your problem may indeed be that you are running out of space. You have a couple of options:
Your first option is to use the Hydra 128k game cartridge - but this card just contains a 128k EEPROM. To make effective use of it you will have to compile your program with the -D EEPROM command line flag:
The resulting program will always end up larger than 32k, so to program it into EEPROM you must use a program like the Hydra Asset Manager - the normal Propeller tool will not work for such programs.
This helps significantly since the EEPROM loader is a two-phase loader, which means you don't waste precious hub RAM on plugin code.This should give you more code space for your program even when using normal LMM mode.
I just compiled your program this way and it runs ok.
A second alternative is that since you have a HX512, you can run your program in XMM mode. The best way to do this is to do the following:
1. Build, buy, beg, borrow or steal a CPLD programming cable (they are expensive to buy, but the instructions for building one are included the HX512 documentation - but I found a few problems with the original instructions - see here).
2. Replace the firmware in your HX512 with the one by Eric Moyer (this is included with Catalina - see README.HX512 in the Catalina main directory).
3. Build a mouse serial cable, as described in the Catalina documentation (the Hydra cannot use the serial port at the same time as the XMM card, so we have to load XMM programs via the mouse port).
I just compiled your program this way as well, and it runs - although when using XMM mode the gamepads don't seem to work. This is most likely a timing problem as the program runs much slower from XMM.
Therefore, for the moment, I suggest using the EEPROM option.
I have just recently gotten Catalina 2.8 up and running on a Zipit. I've built a custom target for the ASC and successfully compiled and loaded the graphics demo. What I'm kind of stuck on now is the EMM concept and how to implement it. I want to see if a larger-than-32k Catalina program can be loaded and run from the 64k EEPROM on the ASC+. Is this possible with a standard pin 28-29 EEPROM connection? I understand a loader program has to be run from the prop, but I get lost after that.
--EDIT--
Ahhh, Catalina has a reference manual.... {ahem} Which was hidden in plain sight.
Hi Martin,
I hope you found the answer - you could also see my reply to wuut (above), where I show how he could load his program from EEPROM. However, you have to understand the difference between loading from EEPROM (possible) and running from EEPROM (not currently possible - it would be easy enough to do so, but very slow).
I guess the question boils down to; does the ASC+ with it's 64k EEPROM provide any benefit to Catalina programs when they are compiled with -x1. My understanding is that, while the Prop can only run 32k programs, with the -x1 option more of that 32k is available for C code. Is that correct?
I guess the question boils down to; does the ASC+ with it's 64k EEPROM provide any benefit to Catalina programs when they are compiled with -x1. My understanding is that, while the Prop can only run 32k programs, with the -x1 option more of that 32k is available for C code. Is that correct?
Correct. When a program is loaded normally, all the cog code (which Catalina calls plugins) has to share the 32kb of Hub RAM with the C program code. But when loading a program compiled with -x1 (now equivalent -D EEPROM) from a 64k EEPROM, the program is loaded in two phases:
First, the Propeller loads the first 32kb of the EEPROM as normal - this is a SPIN program that loads and initializes all the plugins and drivers (e.g. screen, keyboard and mouse drivers, SD Card drivers, floating point libraries, graphics libraries, Real-Time Clock etc etc). Since up to 8 cogs may need to be loaded, if this is not done separately then the plugin code can take up to 16kb of Hub RAM (i.e. 2kb for each cog) which is therefore unavailable for C code. The last thing this program does is load the second 32k of the EEPROM into Hub RAM and then start the Kernel. Since the plugins have already been loaded, the full 32kb of Hub RAM (actually, only around 30kb or so for various reasons) can be used for C programs.
Note that there is now an SDCARD mode (invoked using -D SDCARD) that can do a similar thing for platforms that have an SD Card and which use the Catalyst loader.
Great. I understand completely. Now do I need to write a custom utility to use with payload's two-step feature to get the 64k data into the EEPROM? Or is that already built-in somewhere that I'm not seeing?
-EDIT-
I see your reply above mentions HAM to do this. I think I'll use that as a starting point.
Great. I understand completely. Now do I need to write a custom utility to use with payload's two-step feature to get the 64k data into the EEPROM? Or is that already built-in somewhere that I'm not seeing?
-EDIT-
I see your reply above mentions HAM to do this. I think I'll use that as a starting point.
Yes, I never bothered to write a utility to do this, since HAM works well. I use it on the Hydra, for which it was originally written, but it should work on other platforms. If not, post a request in the HAM thread.
Ross.
EDIT - just reread your question - the two load process is built into the EEPROM memory loader that Catalina will include in the program it generates in the first 32k. All you need to do is get the binary that Catalina generates into the EEPROM somehow - the loader will do the rest.
All you need to do is get the binary that Catalina generates into the EEPROM somehow
That's what I thought, and that was my last hurdle. I've gotten HAM to work with an EMM test_suite.c with some modifications to the ham_driver.spin but I may try to build a payload native utility to do this as well. Thanks for your help so far, I'm sure I'll have more questions.
BTW, here is the ASC target for Catalina_Common_Input.spin
#elseifdef ASC
'===============================================================================
'
' Propeller ASC General definitions:
'
'===============================================================================
KBD_PIN = 22 ' BASE PIN (ASC)
MOUSE_PIN = 20 ' BASE PIN (ASC)
TV_PIN = 16 ' BASE PIN (ASC)
VGA_PIN = 16 ' BASE PIN (ASC)
SD_DO_PIN = 12 ' PIN (ASC)
SD_CLK_PIN = 13 ' PIN (ASC)
SD_DI_PIN = 11 ' PIN (ASC)
SD_CS_PIN = 20 ' PIN (ASC)
I2C_PIN = 28 ' I2C Boot EEPROM SCL Pin
I2C_DEV = $A0 ' I2C Boot EEPROM Device Address
SI_PIN = 31 ' PIN (ASC)
SO_PIN = 30 ' PIN (ASC)
'
' Propeller ASC Clock definitions:
'
CLOCKMODE = xtal1 + pll16x ' (ASC)
XTALFREQ = 5_000_000 ' (ASC)
CLOCKFREQ = 80_000_000 ' (ASC) Nominal clock frequency (required by some drivers)
'
' Demo platform Loader and InterProp Comms definitions:
'
SIO_BAUD = 115200 ' Baud rate to use for all interprop comms
SIO_LOAD_MODE = %0000 ' ASC has only one CPU - this is for serial loading
SIO_COMM_MODE = %0000 ' ASC has only one CPU - this is for serial loading
TX_PIN = -1 ' ASC has only one CPU
RX_PIN = -1 ' ASC has only one CPU
'
' Propeller ASC XMM Base Address:
'
XMM_BASE_ADDRESS = -1 ' ASC board has no XMM
'
' Propeller ASC Payload pins (SI/SO pins)
'
PAYLOAD_RXPIN = SI_PIN ' Rx pin to use for Payload comms
PAYLOAD_TXPIN = SO_PIN ' Tx pin to use for Payload comms
'
' Propeller ASC BlackCat debug pins (SI/SO pins)
'
BLACKCAT_RXPIN = SI_PIN ' Rx pin to use for BlackCat comms
BLACKCAT_TXPIN = SO_PIN ' Tx pin to use for BlackCat comms
BLACKCAT_MODE = %0000 ' SIO mode to use for BlackCat comms
'
'
' Propeller ASC Last Cog. The value of LASTCOG specifies the last cog
' that will be restarted during the load process. Since CogStore (if used)
' will always be in Cog 7, this value should always be 6 or less. Set this
' value lower than 6 to reserve another cog for other purposes. Note that
' it is still the users responsibility to ensure that the combination of
' loaded drivers and plugins does not exceed this value
'
#ifdef RESERVE_COG
LASTCOG = 5 ' Last restarted cog is 5 (i.e. reserve cog 6).
#else
LASTCOG = 6 ' Last restarted cog is 6 (7 is for CogStore)
#endif
That's what I thought, and that was my last hurdle. I've gotten HAM to work with an EMM test_suite.c with some modifications to the ham_driver.spin but I may try to build a payload native utility to do this as well. Thanks for your help so far, I'm sure I'll have more questions.
BTW, here is the ASC target for Catalina_Common_Input.spin
#elseifdef ASC
'===============================================================================
'
' Propeller ASC General definitions:
'
'===============================================================================
KBD_PIN = 22 ' BASE PIN (ASC)
MOUSE_PIN = 20 ' BASE PIN (ASC)
TV_PIN = 16 ' BASE PIN (ASC)
VGA_PIN = 16 ' BASE PIN (ASC)
SD_DO_PIN = 12 ' PIN (ASC)
SD_CLK_PIN = 13 ' PIN (ASC)
SD_DI_PIN = 11 ' PIN (ASC)
SD_CS_PIN = 20 ' PIN (ASC)
I2C_PIN = 28 ' I2C Boot EEPROM SCL Pin
I2C_DEV = $A0 ' I2C Boot EEPROM Device Address
SI_PIN = 31 ' PIN (ASC)
SO_PIN = 30 ' PIN (ASC)
'
' Propeller ASC Clock definitions:
'
CLOCKMODE = xtal1 + pll16x ' (ASC)
XTALFREQ = 5_000_000 ' (ASC)
CLOCKFREQ = 80_000_000 ' (ASC) Nominal clock frequency (required by some drivers)
'
' Demo platform Loader and InterProp Comms definitions:
'
SIO_BAUD = 115200 ' Baud rate to use for all interprop comms
SIO_LOAD_MODE = %0000 ' ASC has only one CPU - this is for serial loading
SIO_COMM_MODE = %0000 ' ASC has only one CPU - this is for serial loading
TX_PIN = -1 ' ASC has only one CPU
RX_PIN = -1 ' ASC has only one CPU
'
' Propeller ASC XMM Base Address:
'
XMM_BASE_ADDRESS = -1 ' ASC board has no XMM
'
' Propeller ASC Payload pins (SI/SO pins)
'
PAYLOAD_RXPIN = SI_PIN ' Rx pin to use for Payload comms
PAYLOAD_TXPIN = SO_PIN ' Tx pin to use for Payload comms
'
' Propeller ASC BlackCat debug pins (SI/SO pins)
'
BLACKCAT_RXPIN = SI_PIN ' Rx pin to use for BlackCat comms
BLACKCAT_TXPIN = SO_PIN ' Tx pin to use for BlackCat comms
BLACKCAT_MODE = %0000 ' SIO mode to use for BlackCat comms
'
'
' Propeller ASC Last Cog. The value of LASTCOG specifies the last cog
' that will be restarted during the load process. Since CogStore (if used)
' will always be in Cog 7, this value should always be 6 or less. Set this
' value lower than 6 to reserve another cog for other purposes. Note that
' it is still the users responsibility to ensure that the combination of
' loaded drivers and plugins does not exceed this value
'
#ifdef RESERVE_COG
LASTCOG = 5 ' Last restarted cog is 5 (i.e. reserve cog 6).
#else
LASTCOG = 6 ' Last restarted cog is 6 (7 is for CogStore)
#endif
Your problem may indeed be that you are running out of space. You have a couple of options:
Your first option is to use the Hydra 128k game cartridge - but this card just contains a 128k EEPROM. To make effective use of it you will have to compile your program with the -D EEPROM command line flag:
The resulting program will always end up larger than 32k, so to program it into EEPROM you must use a program like the Hydra Asset Manager - the normal Propeller tool will not work for such programs.
This helps significantly since the EEPROM loader is a two-phase loader, which means you don't waste precious hub RAM on plugin code.This should give you more code space for your program even when using normal LMM mode.
I just compiled your program this way and it runs ok.
A second alternative is that since you have a HX512, you can run your program in XMM mode. The best way to do this is to do the following:
1. Build, buy, beg, borrow or steal a CPLD programming cable (they are expensive to buy, but the instructions for building one are included the HX512 documentation - but I found a few problems with the original instructions - see here).
2. Replace the firmware in your HX512 with the one by Eric Moyer (this is included with Catalina - see README.HX512 in the Catalina main directory).
3. Build a mouse serial cable, as described in the Catalina documentation (the Hydra cannot use the serial port at the same time as the XMM card, so we have to load XMM programs via the mouse port).
I just compiled your program this way as well, and it runs - although when using XMM mode the gamepads don't seem to work. This is most likely a timing problem as the program runs much slower from XMM.
Therefore, for the moment, I suggest using the EEPROM option.
Ross.
Hey RossH i tried the HAM and it seems to work thank you.
but i have one question it seems like HAM and Double Buffer does not work?
Have you tried that? or is it just me?
Hey RossH i tried the HAM and it seems to work thank you.
but i have one question it seems like HAM and Double Buffer does not work?
Have you tried that? or is it just me?
Greetings wuut
Hi wuut,
No, double buffer doesn't work for me either. At this resolution each buffer takes 9600 bytes, so double bufferiing leaves only around 12kb for actual C code (actually less, considering you also need some Hub RAM as stack space) - and you are probably already using this much in C code.
You can try reducing the resolution (set in Catalina_Common_Input.spin) if you don't need it, but a better option is to use singe buffering but do more intelligent screen updates - i.e. instead of erasing the whole screen between each redraw, undraw what you have drawn (i.e. redraw it in the background colour), before drawing the new version in the foreground colour - this will also be significantly faster.
Another option would be to re-implement the gamepade driver into a plugin instead of implementing it in C (which is quite inefficient!)
This was asked a bit back, but I'm still hazy on the concept. Using a SD card with Catalina C, is the program size always limited to 32K, or can the SD card be used to store code which is brought in as needed?
Part of my confusion is due to Dr. Acula's comment about using the memory on the Dracblade to write larger C programs than normal? Or did I misinterpret the intention of the post?
I know it gets confusing - I probably should write a definitive guide to all the various memory and loader options that Catalina offers. I probably confused things originally because one of my original memory models (EMM) was actually a loader option, whereas the others - LMM (TINY), XMM SMALL and XMM LARGE - are true memory models that use/require different internal memory management schemes.
If you think about the way the propeller works, and the way cogs are loaded from Hub RAM at runtime - i.e. using up to 2kb of Hub RAM each just to hold the cog program to be loaded - then you realize that in some cases, of the 32kb of available Hub RAM, a program may be able to use only 16kb of it for actual program code. This is a small problem with SPIN (which is quite memory efficient, and generally used for smallish programs) but becomes a bigger problems with LMM programs (which are not very memory efficient, and generally large programs!).
Catalina uses various tricks to get around this problem. Here is a quick rundown of the various options:
LMM - all programs are limited to the internal 32kb Hub RAM. This model can be used on any Propeller. There are a couple of different load options for LMM programs:
a one-phase loader, as used by Parallax, where everything (code, data, plugins) is loaded into the 32kb of hub ram in one hit, and any space occupied by plugins is unavailable as code space (but can be used as data space once the plugins are running). This load option can be used on any Propeller.
various two-phase loaders, which allows LMM programs to be loaded from EEPROM or SDCARD. I still sometimes call these EMM mode or SMM mode, but they are really LMM load options, not independent memory models:
The EMM load option can only be used on platforms with a 64kb (or larger) EEPROM.
The SMM load option can only be used on platforms with an SD Card, and is currently only implemented in the Catalyst program loader.
These two phase loaders just load an LMM program, and all such programs are still limited to 32kb - but because they do the load in two independent steps, the internal Hub RAM can be reclaimed after the plugins are loaded and is then available as code space for C programs - this means C programs can potentially be twice as large when using a two-pase loader as when using a one-phase loader (i.e. they can use nearly all of the 32kb Hub RAM for program code, instead of just 16kb - even if all cogs are used to run plugins).
XMM - all XMM programs require external RAM, and all XMM programs are larger than 32kb, and all XMM programs must use a two-phase loader (the standard Parallax one-phae loader cannot load external RAM). Just to complicate things, there are actually two different XMM variants, and three different load options for XMM programs:
a two-phase EEPROM loader (stand-alone) - similar to what EMM mode does for LMM
a two-phase SD CARD loader (implemented in Catalyst)
a two-phase serial loader (implemented in Payload)
You should look in the Catalina reference manual for details on the differences between XMM SMALL and XMM LARGE.
At to the DracBlade it actually has 512kb of external SRAM, as well as an SD Card. So when Dr_Acula wants to run programs larger than can be accomodated using the basic LMM mode and a one-phase loader, he has at least two options:
Use the SMM loader built into Catalyst and load the program from SD Card. In simple terms, this simple step can effectively double the code space available to C programs (from 16kb to 32kb)
Use the XMM mode and the external SRAM. This means C programs can be up to 512kb. He can use Catalyst, or load the programs serially using Payload.
This was asked a bit back, but I'm still hazy on the concept. Using a SD card with Catalina C, is the program size always limited to 32K, or can the SD card be used to store code which is brought in as needed?
In XMM mode, you load up to 512k off the sd card, through the propeller and out into the external memory. That is done at startup.
Then the program 'runs' from external memory. So you can define huge arrays for instance, like pictures, and feed them back into the propeller as required.
Catalina is amazingly versatile and is a great solution for larger programs. Plus, it taps into vast libraries of C code.
(addit, the reason you need an sd card is that the eeprom is max 64k). I guess you could get bigger eeprom chips but sd works out much cheaper.
Ross and Dr_Acula, thanks for the explanation, it was actually very clear and helped a great deal. We are currently writing an app that we were thinking of using 2 or 3 props since some of what we want to do is very highly parallel and seperable.
We were able to locate an inexpensive 4 EEPROM addressable board with 4 512K chips on it. Each chip has its own address on the board. We were thinking of using that, or a variant of it (512K eeproms per Prop)a, to allow
us to load each prop with larger programs. We are a bit stuck on passing data/flags between the props (using the sd card is an option), but we were wondering if we could have the props "share" a common EEPROM or literally talk serially to each other.
The serial comms have us a bit muddled at the moment, but your answer on Catalina opens up a solution to a number of our issues. I thank you very much for your time and knowledge.
Is it possible to run in XMM mode on the C3? If yes has anyone tried it?
I suspect it could be made to work fairly easily. I have ZOG running on the C3 now and it allows C code to be developed with the ZPU version of GCC. ZOG is an emulator for the ZPU instruction set.
A catalina question. If I use the mode where the program can now exceed 32K, that would solve our memory issues for our current code base. Can I combine spin and C on the same prop if the C program is over 32K or once I exceed that size, do I have
to write everything in C?
My question revolves around things like Kye's SD routines which are written in Spin. Can I still access and use these spin routines (in a large C program) or do I have access only to the functionality built into Catalina?
An aside, I've been looking over Catalina and that is some compiler. Does anyone have a recommendation as to the best source code debugger to use with it?
I was using viewpoint with spin, but really just need the ability to set breakpoints, check values and step thru routines, the oscilloscope functions etc are not something we really use.
A graphical interface would be nice rather than a command line driven, but either is acceptable. Views from people who have used what is out there?
Is it possible to run in XMM mode on the C3? If yes has anyone tried it?
Hi sssidney,
I currently have a version that can execute code out of the SPI RAM - I intend to add support for the FLASH as well when I get time. It will be slow, but usable.
A catalina question. If I use the mode where the program can now exceed 32K, that would solve our memory issues for our current code base. Can I combine spin and C on the same prop if the C program is over 32K or once I exceed that size, do I have
to write everything in C?
Currenlty, you can only have C and PASM executing concurrently, not SPIN. I have done a very small amount of work on allowing SPIN to share Hub RAM with Catalina (sharing the cogs is already possible) so this may appear in a later release.
My question revolves around things like Kye's SD routines which are written in Spin. Can I still access and use these spin routines (in a large C program) or do I have access only to the functionality built into Catalina?
From C, you would only have access to the functionality built into Catalina - but DOSFS is a fairly complete file system implementation, and of course you have all the C library functions (but to use them you need to use XMM).
An aside, I've been looking over Catalina and that is some compiler. Does anyone have a recommendation as to the best source code debugger to use with it?
An aside, I've been looking o
I was using viewpoint with spin, but really just need the ability to set breakpoints, check values and step thru routines, the oscilloscope functions etc are not something we really use.
A graphical interface would be nice rather than a command line driven, but either is acceptable. Views from people who have used what is out there?
Thanks again for all your kind assistance!
Bob Anderson developed a graphical debugger called BlackCat (see here) - it runs under Windows. Catalina comes with a command-line version (called BlackBox) which runs under Windows or Linux. With either one you can set breakpoints, display source code, single step, examine values etc.
I currently have a version that can execute code out of the SPI RAM - I intend to add support for the FLASH as well when I get time. It will be slow, but usable.
Ross.
I have a combined driver that can handle the SPI flash and SRAM as well as the SD card. It implements jazzed's cache interface so it would probably be pretty easy to hook up to Catalina. Can you send me the code you already have to access the SPI SRAM?
I have a combined driver that can handle the SPI flash and SRAM as well as the SD card. It implements jazzed's cache interface so it would probably be pretty easy to hook up to Catalina. Can you send me the code you already have to access the SPI SRAM?
Thanks,
David
Hi David,
I was going to have a go at adding FLASH support on my Morpheus board this coming weekend. Then I'll publish it and you (or someone else) can get it working on the C3. The main difference should be Andr'es chip select mechanism for the C3.
Ross.
P.S. Do you have any benchmark data for Zog on the C3? I'm doing a simple-minded (non-caching) interface to start with, and I'd be interested how much a caching interface might eventually speed things up.
I've just been reading the C3 manual. It is very good. I am wondering if Catalina could run in XMM in the external 64k memory? I know we have talked about this before, and I know it would be slow, and I know that there seems to be a minimum of 128k in the software, but is there any chance you could look at this?
I have an ulterior motive in that I'd like to get some more C programmers on the propeller, so I can get some help on the somewhat daunting task of porting Spin Obex code into C. You probably need some help on that too!
I've just been reading the C3 manual. It is very good. I am wondering if Catalina could run in XMM in the external 64k memory? I know we have talked about this before, and I know it would be slow, and I know that there seems to be a minimum of 128k in the software, but is there any chance you could look at this?
I have an ulterior motive in that I'd like to get some more C programmers on the propeller, so I can get some help on the somewhat daunting task of porting Spin Obex code into C. You probably need some help on that too!
Cheers, Drac
Hi Dr_Acula,
Yes, I hope to post a version of Catalina this weekend that will be able to execute code from the external SPI RAM of the C3. I also hope to support execution from the FLASH, since that is also SPI. I will initially only support the XMM (SMALL) mode, where only the code is in the external RAM (or FLASH) and all the data has is in the internal 32kb of Hub RAM - but that's enough for some serious C programs, and should give acceptable performance.
I'm not sure what you mean about "a minimum of 128kb" - Catalina has no such requirement. I can execute from the 32kb SPI RAM on the Morpheus board (using the 32kb of Hub RAM as data) quite happily. Using 64kb of SPI RAM is no problem.
I actually decided to order a C3 today - but when I discovered that the shipping from the US was $65 - almost as much as the board itself! - I changed my mind. So I'll write the code, but someone else will have to test it.
Comments
See here for more information on the registry.
The _status_of_plugin function was never implemented since it is plugin-dependent. I will remove it in the next release. For most plugins, it is easier to check for yourself by looking in the registry.
To redirect stdin and stdout to the serial port, you use the PC HMI plugin - i.e. compile with -D PC. This works on any platform. The baudrates are determined in the files Catalina_PC_Keyboard.spin and Catalina_PC_Text.spin (I really should update these to use the baud rates specified in Catalina_Common_Input.spin).
Ross.
Thanks. We're getting closer. I am able to get catalina to redirect compiled output to serial by using -D PC. However, it appears to be executing some kind of loop for it continuously prints garbage to the serial port instead of just one message;
eg:
catalina -b -ab -lc -lm -D PC hello_world.c
payload hello_world.binary
The garbage printed changes form if I change baud rates in Catalina_PC_Text.spin, and the kind of characters track with the baudrate in nanocom, so I know that the program is working the serial port -- but no baud rate I choose makes it at all human intelligible. I figured this might be a problem with the GG's frequency -- since I have a 5MHz crystal in the GG, so I edited Catalina_Common_Input.spin -- and changed the settings for "Hydra" to 5MHz, && PLL=80MHz, since the comments say Hydra is the default compile platform -- but it still doesn't improve anything.
What would cause a program designed to only print one string "hello world" to continuously output information to the serial port?
Is that a debugger hook or something?
--Andrew
I'm just about to go out of internet range for another week, so I won't be much help - but I suggest you modify the CUSTOM section of Catalina_Common_Input.spin to suit your needs (and then use -D CUSTOM) on the command line.
The DEFAULT settings are the same as the HYDRA settings, but they are a simple copy - and the HYDRA settings are only used if -D HYDRA is specified on the command line.
Ross.
i currently have some issues with the different Memory Models..
Currently my Code is about 400 lines long and after compiling with the "build_all HYDRA DOUBLE_BUFFER" my binaries are 18kb 44kb and 45 kb.
But it seems like my code is to big for Propeller using the 128kGame Card and i dont know why.
I also have the HX512 KB Card .. but no CPLD to flash it .. (do i need to?)
The PropTool tells me...
4,461 Longs -> Programm
1 Long -> Variable
3,726 Longs -> Stack / Free
i try to use the first binary (no x2 no x5) because i dont get the others to work..
#include "catalina_graphics.h" #include "catalina_hmi.h" #include <stdlib.h> //#include <stdio.h> #include <catalina_cog.h> #include "LMM_array.h" #define CLKPIN_MASK 0x8 #define LATCHPIN_MASK 0x10 #define DATAPIN_MASK 0x20 #define DATAPIN_MASKR 0x40 #define LOW 0 #define DOWN_RIGHT 0 #define UP_RIGHT 1 #define DOWN_LEFT 2 #define UP_LEFT 3 // these macros provide an easy means of scaling the X, Y coordinates when // we change x or y tile size - this is done to retain the proportions of // the original demo on different screen sizes. // // Ideally, we should scale like this ... // // #define X(n) ((n)*x_tiles/16) // #define Y(n) ((n)*y_tiles/12) // // ... but that makes the code too large, so instead we just hardcode the // x_tiles and y_tiles values: // #define X(n) ((n)*15/16) #define Y(n) ((n)*10/12) static unsigned reg = 0; static unsigned reg2 = 0; int C_coginit (void func(void), unsigned long *stack) { int cog; struct { unsigned long REG1; unsigned long PC; unsigned long SP; } cog_data; cog_data.REG1 = _registry(); // regisrtry address cog_data.PC = (unsigned long)func; // address of C function cog_data.SP = (unsigned long)stack; // top of stack cog = _coginit((int)&cog_data>>2, (int)LMM_array>>2, ANY_COG); _waitcnt(_cnt() + 10000); // small delay for cog to initialize return cog; } void init_gamepad(void) { unsigned i; unsigned savereg; /* Setting I/O */ _dira(CLKPIN_MASK | LATCHPIN_MASK | DATAPIN_MASK, CLKPIN_MASK | LATCHPIN_MASK); _outa(LATCHPIN_MASK, LOW); while(1) { _outa(LATCHPIN_MASK, LATCHPIN_MASK); //Set LATCH HIGH _waitcnt(_cnt() + 500); //Wait till Counter reaches _cnt() + 500 if(DATAPIN_MASK & _ina() ) { reg = 0; } else { reg = 1; } //Reads first bit inside _ina(), show 0 or 1 _waitcnt(_cnt() + 500); _outa(LATCHPIN_MASK, LOW); //set LATCH LOW ("clear") for(i = 0; i<8; i++) { _outa(CLKPIN_MASK, CLKPIN_MASK); _waitcnt(_cnt() + 500); if(DATAPIN_MASK & _ina()) { savereg = reg; reg = 0 << (i+1); reg = savereg | reg; }else { savereg = reg; reg = 1 << (i+1); reg = savereg | reg; } _outa(CLKPIN_MASK, LOW); _waitcnt(_cnt() + 500); } //printf("%x\n", reg); _waitcnt(_cnt() + 1000000); } } void init_gamepad2(void) { unsigned i; unsigned savereg; /* Setting I/O */ _dira(CLKPIN_MASK | LATCHPIN_MASK | DATAPIN_MASKR, CLKPIN_MASK | LATCHPIN_MASK); _outa(LATCHPIN_MASK, LOW); while(1) { _outa(LATCHPIN_MASK, LATCHPIN_MASK); //Set LATCH HIGH _waitcnt(_cnt() + 500); //Wait till Counter reaches _cnt() + 500 if(DATAPIN_MASKR & _ina() ) { reg2 = 0; } else { reg2 = 1; } //Reads first bit inside _ina(), show 0 or 1 _waitcnt(_cnt() + 500); _outa(LATCHPIN_MASK, LOW); //set LATCH LOW ("clear") for(i = 0; i<8; i++) { _outa(CLKPIN_MASK, CLKPIN_MASK); _waitcnt(_cnt() + 500); if(DATAPIN_MASKR & _ina()) { savereg = reg2; reg2 = 0 << (i+1); reg2 = savereg | reg; }else { savereg = reg2; reg2 = 1 << (i+1); reg2 = savereg | reg2; } _outa(CLKPIN_MASK, LOW); _waitcnt(_cnt() + 500); } //printf("%x\n", reg); _waitcnt(_cnt() + 1000000); } } void main() { int x_tiles = cgi_x_tiles(); int y_tiles = cgi_y_tiles(); long mousex = 0, mousey = 0; // this structure is used to hold graphics variables - especially when // it is required that such variables be in Hub RAM when we use XMM: g_var gv; int test = 1; int YofR = 0; int YofL = 0; int xball =10; int yball =-5; int direction=0; //The direction the Ball is going int cog = 0; int cog2 = 0; register int i, j, k; //int kk, dx, dy, pp, pq, rr, numx, numchr; char pchip[5] = "DEMO"; // text // this is defined locally so it exists in Hub RAM even for XMM programs: unsigned long stack[20]; unsigned long stack2[40]; cog = C_coginit(&init_gamepad, &stack[20]); cog2 = C_coginit(&init_gamepad2, &stack2[40]); //direction = direction(); // setup graphics g_setup(&gv, x_tiles*8, y_tiles*8, DOUBLE_BUFFER); direction=0; while (1) { switch(reg) { case 0x1: //printf("KEY A IS PRESSED\n"); if(test == 0) { test = 1; } else { test = 0; } break; /*case 0x2: //printf("KEY B IS PRESSED\n"); break; case 0x4: //printf("KEY SELECT IS PRESSED\n"); break;*/ case 0x8: //printf("KEY START IS PRESSED\n"); break; case 0x10: //printf("KEY UP IS PRESSED\n"); if((YofL+40)<105) { YofL++; } break; case 0x20: //printf("KEY DOWN IS PRESSED\n"); if(YofL>-30) { YofL--; } break; /*case 0x40: //printf("KEY LEFT IS PRESSED\n"); xa--; break; case 0x80: //printf("KEY RIGHT IS PRESSED\n"); xa++; break;*/ case 0x0: //printf("NO KEY PRESSED\n"); break; } switch(reg2) { case 0x1: //printf("KEY A IS PRESSED\n"); if(test == 0) { test = 1; } else { test = 0; } break; /*case 0x2: //printf("KEY B IS PRESSED\n"); break; case 0x4: //printf("KEY SELECT IS PRESSED\n"); break;*/ case 0x8: //printf("KEY START IS PRESSED\n"); break; case 0x10: //printf("KEY UP IS PRESSED\n"); if((YofR+40)<105) { YofR++; } break; case 0x20: //printf("KEY DOWN IS PRESSED\n"); if(YofR>-30) { YofR--; } break; /*case 0x40: //printf("KEY LEFT IS PRESSED\n"); xa--; break; case 0x80: //printf("KEY RIGHT IS PRESSED\n"); xa++; break;*/ case 0x0: //printf("NO KEY PRESSED\n"); break; } // clear display g_clear(&gv); if(test == 0) { g_colorwidth(&gv,3,20); g_box(&gv, X(-125),Y(-50),235,120); //*** //PLAYER LEFT g_colorwidth(&gv,14,5); g_box(&gv, X(-125), Y(YofL-20), 10, 40); //*** //Player RIGHT g_colorwidth(&gv,14,5); g_box(&gv, X(+115), Y(YofR-20), 10, 40); switch(direction) { case DOWN_RIGHT: xball++; yball--; if(yball<-40){ direction=UP_RIGHT; } if(xball>100){ if(yball>Y(YofR-20) && yball <(Y(YofR-20)+40)) { direction=DOWN_LEFT; } else { xball=0; yball=0; direction=DOWN_LEFT; } } break; case UP_RIGHT: xball++; yball++; if(yball>73){ direction=DOWN_RIGHT; } if(xball>100){ if(yball>Y(YofR-20) && yball <(Y(YofR-20)+40)) { direction=UP_LEFT; } else { xball=0; yball=0; direction=DOWN_RIGHT; } } break; case DOWN_LEFT: xball--; yball--; if(yball<-40){ direction=UP_LEFT; } if(xball<-107){ if(yball>Y(YofL-20) && yball <(Y(YofL-20)+40)) { direction=DOWN_RIGHT; } else { xball=0; yball=0; direction=UP_LEFT; } } break; case UP_LEFT: xball--; yball++; if(yball>73){ direction=DOWN_LEFT; } if(xball<-107){ if(yball>Y(YofL-20) && yball <(Y(YofL-20)+40)) { direction=UP_RIGHT; } else { xball=0; yball=0; direction=DOWN_LEFT; } } break; } g_colorwidth(&gv,14,5); g_box(&gv,xball,yball,7,7); } else { g_colorwidth(&gv,14,5); //S g_box(&gv,-56,28,14,7); g_box(&gv,-63,21,7,7); g_box(&gv,-56,14,7,7); g_box(&gv,-49,7,7,7); g_box(&gv,-63,0,14,7); /* //T g_box(&gv,-35,28,21,7); g_box(&gv,-28,0,7,28); //A g_box(&gv,0,28,7,7); g_box(&gv,-7,0,7,28); g_box(&gv,0,14,7,7); g_box(&gv,7,0,7,28); //R g_box(&gv,21,0,7,35); g_box(&gv,28,28,14,7); g_box(&gv,35,21,7,7); g_box(&gv,28,14,7,7); g_box(&gv,35,0,7,14); //T g_box(&gv,49,28,21,7); g_box(&gv,56,0,7,28); */ //! g_box(&gv,77,14,7,21); g_box(&gv,77,0,7,7); } // copy bitmap to display (if double buffering) g_copy(&gv, NULL); // increment counter that makes everything change k++; } }This should output a working copy of a pong like game played with 2 NES Controllers it uses our selfmade Gamepad Driver written in C (see init_gamepad function)
It currently has some issues for example Controller0 can control Controller1 and the input of the keys seems to be unsmooth .. maybe someone has a helping idea about that..
Second it has a "little" memory problem actully i cant add anything more to the code without having the problem of not running anymore. It is compiled with the method above..
Maybe someone can help me with the following:
* making the Code smaller or better fitting for catalina (I dont know how :<)
* looking over the gamepad driver if someone has any idea
But for the Gamepad driver i think Paxi is making a thread the next days ...
greetings
wuut
I'm writing C using the Dracblade external memory, as I have very quickly run out of memory using just the propeller. This is the command line for the Dracblade - maybe it will provide a clue?
There is some discussion about this in the manual but I have to confess I got the above line from Ross, not out of the manual.
--EDIT--
Ahhh, Catalina has a reference manual.... {ahem} Which was hidden in plain sight.
Hi wuut,
I'm back from my break.
Your problem may indeed be that you are running out of space. You have a couple of options:
Your first option is to use the Hydra 128k game cartridge - but this card just contains a 128k EEPROM. To make effective use of it you will have to compile your program with the -D EEPROM command line flag:
The resulting program will always end up larger than 32k, so to program it into EEPROM you must use a program like the Hydra Asset Manager - the normal Propeller tool will not work for such programs.
This helps significantly since the EEPROM loader is a two-phase loader, which means you don't waste precious hub RAM on plugin code.This should give you more code space for your program even when using normal LMM mode.
I just compiled your program this way and it runs ok.
A second alternative is that since you have a HX512, you can run your program in XMM mode. The best way to do this is to do the following:
1. Build, buy, beg, borrow or steal a CPLD programming cable (they are expensive to buy, but the instructions for building one are included the HX512 documentation - but I found a few problems with the original instructions - see here).
2. Replace the firmware in your HX512 with the one by Eric Moyer (this is included with Catalina - see README.HX512 in the Catalina main directory).
3. Build a mouse serial cable, as described in the Catalina documentation (the Hydra cannot use the serial port at the same time as the XMM card, so we have to load XMM programs via the mouse port).
4. Compile your program using a command like:
5. Load your program using a command like:
where N is the port connected to the mouse cable.
I just compiled your program this way as well, and it runs - although when using XMM mode the gamepads don't seem to work. This is most likely a timing problem as the program runs much slower from XMM.
Therefore, for the moment, I suggest using the EEPROM option.
Ross.
Hi Martin,
I hope you found the answer - you could also see my reply to wuut (above), where I show how he could load his program from EEPROM. However, you have to understand the difference between loading from EEPROM (possible) and running from EEPROM (not currently possible - it would be easy enough to do so, but very slow).
Ross.
I guess the question boils down to; does the ASC+ with it's 64k EEPROM provide any benefit to Catalina programs when they are compiled with -x1. My understanding is that, while the Prop can only run 32k programs, with the -x1 option more of that 32k is available for C code. Is that correct?
Correct. When a program is loaded normally, all the cog code (which Catalina calls plugins) has to share the 32kb of Hub RAM with the C program code. But when loading a program compiled with -x1 (now equivalent -D EEPROM) from a 64k EEPROM, the program is loaded in two phases:
First, the Propeller loads the first 32kb of the EEPROM as normal - this is a SPIN program that loads and initializes all the plugins and drivers (e.g. screen, keyboard and mouse drivers, SD Card drivers, floating point libraries, graphics libraries, Real-Time Clock etc etc). Since up to 8 cogs may need to be loaded, if this is not done separately then the plugin code can take up to 16kb of Hub RAM (i.e. 2kb for each cog) which is therefore unavailable for C code. The last thing this program does is load the second 32k of the EEPROM into Hub RAM and then start the Kernel. Since the plugins have already been loaded, the full 32kb of Hub RAM (actually, only around 30kb or so for various reasons) can be used for C programs.
Note that there is now an SDCARD mode (invoked using -D SDCARD) that can do a similar thing for platforms that have an SD Card and which use the Catalyst loader.
Ross.
-EDIT-
I see your reply above mentions HAM to do this. I think I'll use that as a starting point.
Yes, I never bothered to write a utility to do this, since HAM works well. I use it on the Hydra, for which it was originally written, but it should work on other platforms. If not, post a request in the HAM thread.
Ross.
EDIT - just reread your question - the two load process is built into the EEPROM memory loader that Catalina will include in the program it generates in the first 32k. All you need to do is get the binary that Catalina generates into the EEPROM somehow - the loader will do the rest.
That's what I thought, and that was my last hurdle. I've gotten HAM to work with an EMM test_suite.c with some modifications to the ham_driver.spin but I may try to build a payload native utility to do this as well. Thanks for your help so far, I'm sure I'll have more questions.
BTW, here is the ASC target for Catalina_Common_Input.spin
Thanks - I'll include it in the next release.
Ross.
Hey RossH i tried the HAM and it seems to work
but i have one question it seems like HAM and Double Buffer does not work?
Have you tried that? or is it just me?
Greetings wuut
Hi wuut,
No, double buffer doesn't work for me either. At this resolution each buffer takes 9600 bytes, so double bufferiing leaves only around 12kb for actual C code (actually less, considering you also need some Hub RAM as stack space) - and you are probably already using this much in C code.
You can try reducing the resolution (set in Catalina_Common_Input.spin) if you don't need it, but a better option is to use singe buffering but do more intelligent screen updates - i.e. instead of erasing the whole screen between each redraw, undraw what you have drawn (i.e. redraw it in the background colour), before drawing the new version in the foreground colour - this will also be significantly faster.
Another option would be to re-implement the gamepade driver into a plugin instead of implementing it in C (which is quite inefficient!)
Ross.
Part of my confusion is due to Dr. Acula's comment about using the memory on the Dracblade to write larger C programs than normal? Or did I misinterpret the intention of the post?
BruceP
I know it gets confusing - I probably should write a definitive guide to all the various memory and loader options that Catalina offers. I probably confused things originally because one of my original memory models (EMM) was actually a loader option, whereas the others - LMM (TINY), XMM SMALL and XMM LARGE - are true memory models that use/require different internal memory management schemes.
If you think about the way the propeller works, and the way cogs are loaded from Hub RAM at runtime - i.e. using up to 2kb of Hub RAM each just to hold the cog program to be loaded - then you realize that in some cases, of the 32kb of available Hub RAM, a program may be able to use only 16kb of it for actual program code. This is a small problem with SPIN (which is quite memory efficient, and generally used for smallish programs) but becomes a bigger problems with LMM programs (which are not very memory efficient, and generally large programs!).
Catalina uses various tricks to get around this problem. Here is a quick rundown of the various options:
LMM - all programs are limited to the internal 32kb Hub RAM. This model can be used on any Propeller. There are a couple of different load options for LMM programs:
- a two-phase EEPROM loader (stand-alone) - similar to what EMM mode does for LMM
- a two-phase SD CARD loader (implemented in Catalyst)
- a two-phase serial loader (implemented in Payload)
You should look in the Catalina reference manual for details on the differences between XMM SMALL and XMM LARGE.At to the DracBlade it actually has 512kb of external SRAM, as well as an SD Card. So when Dr_Acula wants to run programs larger than can be accomodated using the basic LMM mode and a one-phase loader, he has at least two options:
- Use the SMM loader built into Catalyst and load the program from SD Card. In simple terms, this simple step can effectively double the code space available to C programs (from 16kb to 32kb)
- Use the XMM mode and the external SRAM. This means C programs can be up to 512kb. He can use Catalyst, or load the programs serially using Payload.
I trust this is all now as clear as mudRoss.
In XMM mode, you load up to 512k off the sd card, through the propeller and out into the external memory. That is done at startup.
Then the program 'runs' from external memory. So you can define huge arrays for instance, like pictures, and feed them back into the propeller as required.
Catalina is amazingly versatile and is a great solution for larger programs. Plus, it taps into vast libraries of C code.
(addit, the reason you need an sd card is that the eeprom is max 64k). I guess you could get bigger eeprom chips but sd works out much cheaper.
We were able to locate an inexpensive 4 EEPROM addressable board with 4 512K chips on it. Each chip has its own address on the board. We were thinking of using that, or a variant of it (512K eeproms per Prop)a, to allow
us to load each prop with larger programs. We are a bit stuck on passing data/flags between the props (using the sd card is an option), but we were wondering if we could have the props "share" a common EEPROM or literally talk serially to each other.
The serial comms have us a bit muddled at the moment, but your answer on Catalina opens up a solution to a number of our issues. I thank you very much for your time and knowledge.
Bruce
to write everything in C?
My question revolves around things like Kye's SD routines which are written in Spin. Can I still access and use these spin routines (in a large C program) or do I have access only to the functionality built into Catalina?
An aside, I've been looking over Catalina and that is some compiler. Does anyone have a recommendation as to the best source code debugger to use with it?
I was using viewpoint with spin, but really just need the ability to set breakpoints, check values and step thru routines, the oscilloscope functions etc are not something we really use.
A graphical interface would be nice rather than a command line driven, but either is acceptable. Views from people who have used what is out there?
Thanks again for all your kind assistance!
I currently have a version that can execute code out of the SPI RAM - I intend to add support for the FLASH as well when I get time. It will be slow, but usable.
Ross.
Bob Anderson developed a graphical debugger called BlackCat (see here) - it runs under Windows. Catalina comes with a command-line version (called BlackBox) which runs under Windows or Linux. With either one you can set breakpoints, display source code, single step, examine values etc.
Ross.
I have a combined driver that can handle the SPI flash and SRAM as well as the SD card. It implements jazzed's cache interface so it would probably be pretty easy to hook up to Catalina. Can you send me the code you already have to access the SPI SRAM?
Thanks,
David
Hi David,
I was going to have a go at adding FLASH support on my Morpheus board this coming weekend. Then I'll publish it and you (or someone else) can get it working on the C3. The main difference should be Andr'es chip select mechanism for the C3.
Ross.
P.S. Do you have any benchmark data for Zog on the C3? I'm doing a simple-minded (non-caching) interface to start with, and I'd be interested how much a caching interface might eventually speed things up.
I've just been reading the C3 manual. It is very good. I am wondering if Catalina could run in XMM in the external 64k memory? I know we have talked about this before, and I know it would be slow, and I know that there seems to be a minimum of 128k in the software, but is there any chance you could look at this?
I have an ulterior motive in that I'd like to get some more C programmers on the propeller, so I can get some help on the somewhat daunting task of porting Spin Obex code into C. You probably need some help on that too!
Cheers, Drac
Hi Dr_Acula,
Yes, I hope to post a version of Catalina this weekend that will be able to execute code from the external SPI RAM of the C3. I also hope to support execution from the FLASH, since that is also SPI. I will initially only support the XMM (SMALL) mode, where only the code is in the external RAM (or FLASH) and all the data has is in the internal 32kb of Hub RAM - but that's enough for some serious C programs, and should give acceptable performance.
I'm not sure what you mean about "a minimum of 128kb" - Catalina has no such requirement. I can execute from the 32kb SPI RAM on the Morpheus board (using the 32kb of Hub RAM as data) quite happily. Using 64kb of SPI RAM is no problem.
I actually decided to order a C3 today - but when I discovered that the shipping from the US was $65 - almost as much as the board itself! - I changed my mind. So I'll write the code, but someone else will have to test it.
Ross.