@ravenkallen - sounds like you are making good progress, and also finding where the limitations are.
Can you use a binary value to send to the dira/outa registers, like you could in SPIN.. You know something like this:
Outa[%10000000] := 1
C89 can't do binary and I am not sure why, but then again, neither could many versions of Basic at the time <zips up flame proof suit>
So you find a workaround using Hex and the workaround I use is to have the Windows calculator always open on the screen. Programs/Acessories. Open Calculator and then select View and Scientific. At the top left are Bin Dec Oct Hex. Write your binary number in there and then convert it to hex. Then write all the numbers in Hex in C starting with 0x (zero then small x). After a while you start to notice patterns, and after a long while you start to be able to convert binary to hex in your head. (Then you feel a strong desire to go out and buy a cap with a propeller on it...)
So 0000 is 0 and 0001 is 1 and 1110 is E and 1111 is F etc. So you can then work out bytes, eg 0xEE is %11101110, and even longs in your head if you want.
So that would be the same as saying,
Count = count + some value
Yes and count = count + somevalue is the old-skool way I tend to write things, when I forget in newer languages that += exists. But += is not in C89.
However, not all is lost! Because most of the time "somevalue" is either +1 or -1. And there is a shortcut for that, which is ++ for +1 and -- for -1. So in a loop where you increment a variable by 1, you can use ++, eg
int i;
for (i=0;i<40;i++)
I'm not sure about your other question, with dira supporting all 32 pins but I presume it does.
Re buying books, there are are some great ones around, but if you can't wait for delivery, type "c tutorial" into google and skim read through all the chapters. The other way to get up to speed quickly is to look at code, and there are lots of examples in the c:\program files\catalina\demos folder.
That would be pretty cool. I've got a Gadget Gangster tower that is 4 boards high, but if you did this, you should be able to run big C programs on the Gadget Gangster USB board as it is: http://gadgetgangster.com/
Now I have Hello World on either a VGA or TV simply by setting a checkbox in code::blocks, I've found one thing is that on the TV screens I am getting a lot of shimmering on the screen with catalina, but not with kyedos. They are using the identical 40x13 TV driver, so I traced through the differences and it comes down to one line in mode
long 010 'mode
Set that last bit to 1 and it shimmers, set it to 0 and it doesn't.
That last bit is the NTSC/PAL select. My little TVs autoselect and I've found NTSC looks better. But of course, here in Australia we are PAL. But then again, all the US is NTSC. I don't know if you feel strongly about this but I was wondering about making the default NTSC rather than PAL?
Hi Dr_A,
Just specify -D NTSC on the command line, or select NTSC in Code::Blocks (in the HMI related Options in the build options).
If you want to make this change permanent, modify Catalina_Common.spin
Ross, I have Optimizer 3.1. So you must have sent it to me somehow. Though I am at a loss to remember how or find the email. If you do have a second, I'd appreciate if you could send a test message to martin@1mgh.com and PM me the bounce message if you get one.
The email address I got was "sales@1mgh.com". Maybe you have a redirect?
Anyway, I've sent you test message to martin@1mgh.com- so far no bounce!
Ross, I can see "small" mode on SD card using cache. But, how would "LARGE" mode work?
I don't think it would be a good idea to be contuously writing to SD (besides being extremely slow).
Or, do you mean using SD along with some other SRAM chip?
Yes, using the SD Card as "writable" memory might wear out your SD Card a bit. But as you say, you could use the SD Card as read-only Flash XMM, and use SRAM as read/write XMM.
Ross, I did one (single, maybe not enough motivated) attempt at using the uSD on RamBlade as raw flash for code, while using another card on a companion board for disk services.
Tried to load a stripped copy of femtospi under that, as a low level driver to provide intialization, read_block and write_block, but probably is not the correct way (should be using it as a plugin maybe).
This because lately both my RamBlades have been misteriously failing with XMM stuff. :depressed:
I have an unrelated question: is the refresh of dynamic rams still supported?
As I understand, it should be managed by the cache driver, but the memory test reading seems to indicate that I still have a refresh problem, even including the cache (and calls to refresh function in the cache command loop).
Hi Antoine,
Can you send me a copy of your C program that fails? Are you overclocking your RamBlade?
Dynamic RAM is theoretically supported via the cache, but I have no hardware or code that actually supports it. Jazzed was going to work on it, but I think now that he is busy with GCC work, so I think this is unlikely.
@Ross... I have read over the LED demo several times just to get a handle on everything that is going on, but i have two(Maybe three) questions.
First being: The _dira/ outa commands can support ALL 32 I/O pins right?
And the other question relating to that is: Can you use a binary value to send to the dira/outa registers, like you could in SPIN.. You know something like this:
Outa[%10000000] := 1
Or a numeric value like
Outa[12] := 1
No - use the mask parameter to specify the pins you want to affect.
I tried using the % and C didn't know what it was. I am not really sure what number system that the #define bitmask 0x00008000 uses? Is that hex? Sorry, i should probably know this stuff by now.
Yes, that's hex - but converting hex to binary is easy since each hex digit is 4 binary digits, so 0x1234 (or $1234 in Spin) is %0001_0010_0011_0100 etc
My last question was the += command(That the count variable uses)... I read online that that is a compound assignment operator for addition... So that would be the same as saying,
Compiled and runs in "small" mode with LORES_VGA.
Seems to actually work in 2-player mode.
But, I can't figure out how to get it in 1-player mode (against the computer)...
It looks like, from DOS, you'd enter the executable name with any one argument to start a 1-player game.
But, this code is really, really obfuscated and my C isn't so good as my C++, so I don't think I'd ever figure this one out...
Sorry man.... Looks like i got another problem. I tried changing the bitmask constant to to another value(Eg 2 or 3) and nothing happened at all. None of the other I/O pins responded. Furthermore, i changed it back to it's original setting and the LED on pin 0 turned on, but it wasn't blinking. I tried re-building it several times, saving it and re-loading to to the RAM. There was no warnings or errors reported. I also checked over the hardware using a SPIN program to make sure it wasn't the ASC.. Here is the exact code i am using...
#include <catalina_cog.h>
#ifdef __CATALINA_C3
#define BITMASK 0x00008000 // On the C3, use bit 15 (VGA LED)
#else
#define BITMASK 0x00000001 // Otherwise, use bit 1 (Debug LED on Hydra)
#endif
int main(void) {
unsigned count;
unsigned mask = BITMASK;
unsigned on_off = BITMASK;
_dira(mask, mask);
_outa(mask, on_off);
count = _cnt();
while (1) {
_outa(mask, on_off);
count += 1000000000;
_waitcnt(count);
on_off ^= mask;
}
return 0;
}
And to everybody... I have C++ book that was made especially for Code:Blocks. It is C++ for Dummies. I guess i should get something a little more substantial?:)
Compiled and runs in "small" mode with LORES_VGA.
Seems to actually work in 2-player mode.
But, I can't figure out how to get it in 1-player mode (against the computer)...
It looks like, from DOS, you'd enter the executable name with any one argument to start a 1-player game.
But, this code is really, really obfuscated and my C isn't so good as my C++, so I don't think I'd ever figure this one out...
I'm not quite sure what the parameters do, but try changing the main function I provided to:
include <stdio.h>
void main() {
my_main(1,0,0,0);
}
Otherwise, you'll have to modify the program itself. I'll have a look at it tonight.
Sorry man.... Looks like i got another problem. I tried changing the bitmask constant to to another value(Eg 2 or 3) and nothing happened at all. None of the other I/O pins responded. Furthermore, i changed it back to it's original setting and the LED on pin 0 turned on, but it wasn't blinking. I tried re-building it several times, saving it and re-loading to to the RAM. There was no warnings or errors reported. I also checked over the hardware using a SPIN program to make sure it wasn't the ASC.. Here is the exact code i am using...
Ross, guess I will ask here as others who may be adding their drivers may benefit as well...
I am adding drivers to support RamBlade3, so with the file "RamBlade3_XMM.inc" I understand the following (just to ensure I have it correct)...
XMM_Activate sets up the SRAM bus for subsequent and continued access by Catalina
XMM_Tristate disables the SRAM bus for alternate access such as the SD card
Is it possible that between XMM_Trisatate and XMM_Activate the outa value could be changed by this cog??? If not, then we can save two (2) instructions.
XMM_ReadLong is entered when a long (4 bytes) is to be read from SRAM into the cog
XMM_ReadMult is entered when up to 4 bytes is to be read from SRAM into the cog and the length is in XMM_Len
XMM_ReadPage & XMM_WritePage are conditional routines and read/write SRAM to/from Hub Ram
Is there any possibility that the XMM_Addr can be >19 bits because the XMM_ReadLong and XMM_ReadMult masks this (in RamBlade)? The same applies to XMM_WriteLong and XMM_WriteMult.
Is it possible that between XMM_Trisatate and XMM_Activate the outa value could be changed by this cog??? If not, then we can save two (2) instructions.
You mean changed by the Kernel cog? That should not happen.
XMM_ReadLong is entered when a long (4 bytes) is to be read from SRAM into the cog
XMM_ReadMult is entered when up to 4 bytes is to be read from SRAM into the cog and the length is in XMM_Len
XMM_ReadPage & XMM_WritePage are conditional routines and read/write SRAM to/from Hub Ram
Correct. XMM_ReadLong is used for instruction fetches, and should be optimized to be as fast as possible.
XMM_ReadMult can do long, word or byte fetches, and is used for data fetches. Since the number of bytes to fetch is a parameter, it will always be slightly slower than XMM_ReadLong.
Is there any possibility that the XMM_Addr can be >19 bits because the XMM_ReadLong and XMM_ReadMult masks this (in RamBlade)? The same applies to XMM_WriteLong and XMM_WriteMult.
Yes. In general XMM_Addr could be up to 24 bits. I probably mask it to 19 bits on the RamBlade since it only has 512kb. Other platform support more address bits.
Just specify -D NTSC on the command line, or select NTSC in Code::Blocks (in the HMI related Options in the build options).
Absolutely perfect! Screen timings seem to be optimised for NTSC - now the "Hello World" is in the top left corner instead of in a bit, and the screen is not shimmering.
For the record, the checkboxes I have checked in the Build options are Dracblade platform, Small memory mode, 8k cache, NTSC drivers and TV, or VGA.
I have also nailed down another problem that was a confounding factor - why is it that if I check "libc - standard c library", it won't compile? Is this because libc is already included in the Dracblade?
I have also nailed down another problem that was a confounding factor - why is it that if I check "libc - standard c library", it won't compile? Is this because libc is already included in the Dracblade?
Probably - post your build log (or command line) and I'll check.
Yes looks like "lc" is in the command line, but it is not checked in the build options. No problem, easy workaround.
Next little job is to get catalyst working. I'm getting a blank screen at the moment.
I tried recompiling from the Tools/Build Catalyst and there are errors about 'make' not being installed. I think this needs mingw and msys - are these big programs and ?? could they be included in the catalina package?
So I read the manual (Yay, 'bout time I hear you say!) and on page 8 are some step by step instructions. I followed them through and lots seems to happen. No luck though. I then checked the TV option and NTSC option and did a rebuild. Again, all seemed to work, but every file *except* catalyst.bin was rewritten in the directory. Also step 6 in the manual says that the files will be .binary but they seem to be coming out as .bin.
So how do I go about rebuilding catalyst for different displays? Specifically, what I would like is to create CATTV.BIN and CATVGA.BIN so I can run either of these from Kyedos and test out each display. So where do you change the display settings? In Tools/Build Catalyst it does not ask any questions about the display so how does this one know which display to use? Or do you follow those steps on page 8 of the manual and change the settings in Project/Build Options and then do a rebuild?
I'm reading the manual now! Am I on the right track?
And one thing I just thought of - does code::blocks let you add custom things to the Help menu so you could add all the .pdf help files?
Yes looks like "lc" is in the command line, but it is not checked in the build options. No problem, easy workaround.
Next little job is to get catalyst working. I'm getting a blank screen at the moment.
I tried recompiling from the Tools/Build Catalyst and there are errors about 'make' not being installed. I think this needs mingw and msys - are these big programs and ?? could they be included in the catalina package?
That's just a warning message. You no longer need MinGW or MSYS, but if you don't have them then you must build some of the Catalyst demos (but not Catalyst itself) in Code::Blocks.
So I read the manual (Yay, 'bout time I hear you say!) and on page 8 are some step by step instructions. I followed them through and lots seems to happen. No luck though. I then checked the TV option and NTSC option and did a rebuild. Again, all seemed to work, but every file *except* catalyst.bin was rewritten in the directory. Also step 6 in the manual says that the files will be .binary but they seem to be coming out as .bin.
The command-line script renames the binary files to have a .bin extension, but the Code::Blocks build leaves them as .binary and they have to be manually renamed. Annoying, but that's a limitation of Code::Blocks.
However, if catalyst.bin is not being generated at all (it will be put in the bin subdirectory), then that is a problem - please run the build_all script within a Catalna Command Line window and send me the output - i.e:
cd catalyst
build_all DRACBLADE TV CACHED_1K
dir bin
So how do I go about rebuilding catalyst for different displays? Specifically, what I would like is to create CATTV.BIN and CATVGA.BIN so I can run either of these from Kyedos and test out each display. So where do you change the display settings? In Tools/Build Catalyst it does not ask any questions about the display so how does this one know which display to use? Or do you follow those steps on page 8 of the manual and change the settings in Project/Build Options and then do a rebuild?
I'm reading the manual now! Am I on the right track?
Just specify different options to the commands above, and rename catalyst.bin after each build.
And one thing I just thought of - does code::blocks let you add custom things to the Help menu so you could add all the .pdf help files?
Yes, this could be done - but I generally try to restrict my Code::Blocks changes to just the compiler plugin - that way, people who already use Code::Blocks can continue to use their current version and just update the compiler plugin to add Catalina support. Maybe I shouldn't worry about this so much?
I recommend the following about C style:You should use the form 'unsigned int mask' instead of 'unsigned mask', the latter is a very old-fashioned form back from the seventies. So, unsigned int, unsigned short, unsigned char.. (and unsigned long, not unsigned long int, which is also an old form. Just to catch a few more which can sometimes be seen in oldish code).For signed, you just use 'int', 'long', 'short'. The exception is 'char', which can be either default unsigned or default signed, which varies by platform. So, if you need unsigned char (values from 0..255) then always be explicit about it: 'unsigned char my_byte;', or signed (values from -128..127): 'signed char my_little_number;'. Just 'char' is used when it holds a character.-Tor
(What's wrong with the forum, by the way? It totally messes up any attempt to group my posting into paragraphs! Is this the forum software upgrade?)
Can you send me a copy of your C program that fails? Are you overclocking your RamBlade?
Ross, thanks for the offer but I think it's an hardware problem: it's failing on ALL xmm programs, and Catalina ram test is reporting some bits flickering in the trivial test alredy (on both boards), see the attached test. They've also both stopped working with zicog, qz80, etc
Funny that at least one worked flawlessly 'til this summer with catalina, and the other was surely executing the emulators without any problem.
Here's what I tried so far:
- underclocking to 80MHz
- inserting nops in the memory loop
- carefully refreshing all the solder joints
- temporary downgrading to Catalina 2.9
...and you won't believe this one: a memory driver that I dubbed "brain damage edition" that treats single bits as it was 8x 512Kbit serial RAMs, with rearranged memory map to have the good chunks first. This last one even passes the test multiple times up to 256KB, but then still fails on execution.
Dynamic RAM is theoretically supported via the cache, but I have no hardware or code that actually supports it. Jazzed was going to work on it, but I think now that he is busy with GCC work, so I think this is unlikely.
After all the failed attempts with RamBlades, I dug up an old experiment with 1MB dynamic ram and tried to get that one working.
And it does, as long as "the flow" it's never interrupted: on the memory test doesn't fail if I manage to say "again" quick enough, while it starts losing an increasing number of cells the longer I make the pause between repeats. That's why I think I'm nearly there.
Similar behavior with XMM programs, no matter how large they are, they seem to run until they pause execution (i.e. dbasic+trek15.bas, pint+basics.pas).
Now the problem is, that I'm not sure about the hierarchy of modules when cache is operating: I inserted the refresh call in Catalina_SPI_Cache.spin command loop, but that doesn't seem enough.
Also, can I assume that once the cache is working all XMM access happens in one COG only?
Ross, thanks for the offer but I think it's an hardware problem: it's failing on ALL xmm programs, and Catalina ram test is reporting some bits flickering in the trivial test alredy (on both boards), see the attached test. They've also both stopped working with zicog, qz80, etc
Funny that at least one worked flawlessly 'til this summer with catalina, and the other was surely executing the emulators without any problem.
Here's what I tried so far:
- underclocking to 80MHz
- inserting nops in the memory loop
- carefully refreshing all the solder joints
- temporary downgrading to Catalina 2.9
...and you won't believe this one: a memory driver that I dubbed "brain damage edition" that treats single bits as it was 8x 512Kbit serial RAMs, with rearranged memory map to have the good chunks first. This last one even passes the test multiple times up to 256KB, but then still fails on execution.
After all the failed attempts with RamBlades, I dug up an old experiment with 1MB dynamic ram and tried to get that one working.
And it does, as long as "the flow" it's never interrupted: on the memory test doesn't fail if I manage to say "again" quick enough, while it starts losing an increasing number of cells the longer I make the pause between repeats. That's why I think I'm nearly there.
Similar behavior with XMM programs, no matter how large they are, they seem to run until they pause execution (i.e. dbasic+trek15.bas, pint+basics.pas).
Now the problem is, that I'm not sure about the hierarchy of modules when cache is operating: I inserted the refresh call in Catalina_SPI_Cache.spin command loop, but that doesn't seem enough.
Also, can I assume that once the cache is working all XMM access happens in one COG only?
Hi Antoine,
How odd. It does indeed sound like you have a hardware problem, but it's strange that it should affect multiple boards. Have you tried Cluso's original RamBlade test program?
As to your dynamic refresh, can you post the chunk of code from Catalina_SPI_Cache.spin to show me exactly where you have put your refresh call?
And yes, if the cache is in use, all XMM access is done from the cache cog.
Ross, I just took another look at the Chess program Crafty. In the "chess.h" file it mentions that it can support systems with no 64-bit type. It just says it'll be slower because the functions will be done by proceedure calls...
Ross, I just took another look at the Chess program Crafty. In the "chess.h" file it mentions that it can support systems with no 64-bit type. It just says it'll be slower because the functions will be done by proceedure calls...
Ok - I'll have another look at it when I get time. Or you can try to compile it.
I have had a bit of a play with the "toledo" chess program. I can almost see why it is not working - I think it may have exposed a bug in the Catalina code generator. I need to do some more work on it to be sure. I hope to have a fix for it on the weekend.
Well, I can sure see that Toledo chess program being a good test for the code generator...
BTW: Does Catalina produce a more readable version of the code somewhere in the pipeline?
BTW2: (Maybe showing my ignorance here) I had the "main" call at the top of the program with a call to "my_main" in it. Shouldn't that have produced an error in C, since (without a header), it doesn't know what "my_main" is, since it is at the bottom of the program?
Catalina ram test is reporting some bits flickering in the trivial test alredy (on both boards
You seem to be having more than your share of hardware issues lately. With the Gameduino+ASC and now this. And it all seems to be data corruption of some kind or another. I'd really check your environment for intense RFI/EMI or very noisy power supplies.
Comments
C89 can't do binary and I am not sure why, but then again, neither could many versions of Basic at the time <zips up flame proof suit>
So you find a workaround using Hex and the workaround I use is to have the Windows calculator always open on the screen. Programs/Acessories. Open Calculator and then select View and Scientific. At the top left are Bin Dec Oct Hex. Write your binary number in there and then convert it to hex. Then write all the numbers in Hex in C starting with 0x (zero then small x). After a while you start to notice patterns, and after a long while you start to be able to convert binary to hex in your head. (Then you feel a strong desire to go out and buy a cap with a propeller on it...)
So 0000 is 0 and 0001 is 1 and 1110 is E and 1111 is F etc. So you can then work out bytes, eg 0xEE is %11101110, and even longs in your head if you want.
Yes and count = count + somevalue is the old-skool way I tend to write things, when I forget in newer languages that += exists. But += is not in C89.
However, not all is lost! Because most of the time "somevalue" is either +1 or -1. And there is a shortcut for that, which is ++ for +1 and -- for -1. So in a loop where you increment a variable by 1, you can use ++, eg
int i; for (i=0;i<40;i++)I'm not sure about your other question, with dira supporting all 32 pins but I presume it does.
Re buying books, there are are some great ones around, but if you can't wait for delivery, type "c tutorial" into google and skim read through all the chapters. The other way to get up to speed quickly is to look at code, and there are lots of examples in the c:\program files\catalina\demos folder.
Hi Dr_A,
Just specify -D NTSC on the command line, or select NTSC in Code::Blocks (in the HMI related Options in the build options).
If you want to make this change permanent, modify Catalina_Common.spin
Ross.
I thought that construct had been in C for all time.
The email address I got was "sales@1mgh.com". Maybe you have a redirect?
Anyway, I've sent you test message to martin@1mgh.com- so far no bounce!
Ross.
Yes, using the SD Card as "writable" memory might wear out your SD Card a bit. But as you say, you could use the SD Card as read-only Flash XMM, and use SRAM as read/write XMM.
Hi Antoine,
Can you send me a copy of your C program that fails? Are you overclocking your RamBlade?
Dynamic RAM is theoretically supported via the cache, but I have no hardware or code that actually supports it. Jazzed was going to work on it, but I think now that he is busy with GCC work, so I think this is unlikely.
Ross.
Ross.
Ross.
http://nanochess.110mb.com/chess1.html
Compiled and runs in "small" mode with LORES_VGA.
Seems to actually work in 2-player mode.
But, I can't figure out how to get it in 1-player mode (against the computer)...
It looks like, from DOS, you'd enter the executable name with any one argument to start a 1-player game.
But, this code is really, really obfuscated and my C isn't so good as my C++, so I don't think I'd ever figure this one out...
#include <catalina_cog.h> #ifdef __CATALINA_C3 #define BITMASK 0x00008000 // On the C3, use bit 15 (VGA LED) #else #define BITMASK 0x00000001 // Otherwise, use bit 1 (Debug LED on Hydra) #endif int main(void) { unsigned count; unsigned mask = BITMASK; unsigned on_off = BITMASK; _dira(mask, mask); _outa(mask, on_off); count = _cnt(); while (1) { _outa(mask, on_off); count += 1000000000; _waitcnt(count); on_off ^= mask; } return 0; }And to everybody... I have C++ book that was made especially for Code:Blocks. It is C++ for Dummies. I guess i should get something a little more substantial?:)
I'm not quite sure what the parameters do, but try changing the main function I provided to:
include <stdio.h> void main() { my_main(1,0,0,0); }Otherwise, you'll have to modify the program itself. I'll have a look at it tonight.
Ross.
You've added an extra zero to the line:
It may just be flashing much more slowly than you were expecting.
Ross.
I'll check it out tonight.
Ross.
oops, my bad <goes and hides under rock>
I am adding drivers to support RamBlade3, so with the file "RamBlade3_XMM.inc" I understand the following (just to ensure I have it correct)...
- XMM_Activate sets up the SRAM bus for subsequent and continued access by Catalina
- XMM_Tristate disables the SRAM bus for alternate access such as the SD card
Is it possible that between XMM_Trisatate and XMM_Activate the outa value could be changed by this cog??? If not, then we can save two (2) instructions.- XMM_ReadLong is entered when a long (4 bytes) is to be read from SRAM into the cog
- XMM_ReadMult is entered when up to 4 bytes is to be read from SRAM into the cog and the length is in XMM_Len
- XMM_ReadPage & XMM_WritePage are conditional routines and read/write SRAM to/from Hub Ram
Is there any possibility that the XMM_Addr can be >19 bits because the XMM_ReadLong and XMM_ReadMult masks this (in RamBlade)? The same applies to XMM_WriteLong and XMM_WriteMult.XMM_ReadMult can do long, word or byte fetches, and is used for data fetches. Since the number of bytes to fetch is a parameter, it will always be slightly slower than XMM_ReadLong.
XMM_ReadPage is used for cache page fetches.
Yes. In general XMM_Addr could be up to 24 bits. I probably mask it to 19 bits on the RamBlade since it only has 512kb. Other platform support more address bits.
Ross.
Absolutely perfect! Screen timings seem to be optimised for NTSC - now the "Hello World" is in the top left corner instead of in a bit, and the screen is not shimmering.
For the record, the checkboxes I have checked in the Build options are Dracblade platform, Small memory mode, 8k cache, NTSC drivers and TV, or VGA.
I have also nailed down another problem that was a confounding factor - why is it that if I check "libc - standard c library", it won't compile? Is this because libc is already included in the Dracblade?
Probably - post your build log (or command line) and I'll check.
Ross.
I do now. Thanks for pointing that out. Everything's set.
Next little job is to get catalyst working. I'm getting a blank screen at the moment.
I tried recompiling from the Tools/Build Catalyst and there are errors about 'make' not being installed. I think this needs mingw and msys - are these big programs and ?? could they be included in the catalina package?
So I read the manual (Yay, 'bout time I hear you say!) and on page 8 are some step by step instructions. I followed them through and lots seems to happen. No luck though. I then checked the TV option and NTSC option and did a rebuild. Again, all seemed to work, but every file *except* catalyst.bin was rewritten in the directory. Also step 6 in the manual says that the files will be .binary but they seem to be coming out as .bin.
So how do I go about rebuilding catalyst for different displays? Specifically, what I would like is to create CATTV.BIN and CATVGA.BIN so I can run either of these from Kyedos and test out each display. So where do you change the display settings? In Tools/Build Catalyst it does not ask any questions about the display so how does this one know which display to use? Or do you follow those steps on page 8 of the manual and change the settings in Project/Build Options and then do a rebuild?
I'm reading the manual now! Am I on the right track?
And one thing I just thought of - does code::blocks let you add custom things to the Help menu so you could add all the .pdf help files?
However, if catalyst.bin is not being generated at all (it will be put in the bin subdirectory), then that is a problem - please run the build_all script within a Catalna Command Line window and send me the output - i.e:
Just specify different options to the commands above, and rename catalyst.bin after each build. Yes, this could be done - but I generally try to restrict my Code::Blocks changes to just the compiler plugin - that way, people who already use Code::Blocks can continue to use their current version and just update the compiler plugin to add Catalina support. Maybe I shouldn't worry about this so much?
Ross.
Ross, thanks for the offer but I think it's an hardware problem: it's failing on ALL xmm programs, and Catalina ram test is reporting some bits flickering in the trivial test alredy (on both boards), see the attached test. They've also both stopped working with zicog, qz80, etc
Funny that at least one worked flawlessly 'til this summer with catalina, and the other was surely executing the emulators without any problem.
Here's what I tried so far:
- underclocking to 80MHz
- inserting nops in the memory loop
- carefully refreshing all the solder joints
- temporary downgrading to Catalina 2.9
...and you won't believe this one: a memory driver that I dubbed "brain damage edition" that treats single bits as it was 8x 512Kbit serial RAMs, with rearranged memory map to have the good chunks first. This last one even passes the test multiple times up to 256KB, but then still fails on execution.
After all the failed attempts with RamBlades, I dug up an old experiment with 1MB dynamic ram and tried to get that one working.
And it does, as long as "the flow" it's never interrupted: on the memory test doesn't fail if I manage to say "again" quick enough, while it starts losing an increasing number of cells the longer I make the pause between repeats. That's why I think I'm nearly there.
Similar behavior with XMM programs, no matter how large they are, they seem to run until they pause execution (i.e. dbasic+trek15.bas, pint+basics.pas).
Now the problem is, that I'm not sure about the hierarchy of modules when cache is operating: I inserted the refresh call in Catalina_SPI_Cache.spin command loop, but that doesn't seem enough.
Also, can I assume that once the cache is working all XMM access happens in one COG only?
Hi Antoine,
How odd. It does indeed sound like you have a hardware problem, but it's strange that it should affect multiple boards. Have you tried Cluso's original RamBlade test program?
As to your dynamic refresh, can you post the chunk of code from Catalina_SPI_Cache.spin to show me exactly where you have put your refresh call?
And yes, if the cache is in use, all XMM access is done from the cache cog.
Ross.
Ok - I'll have another look at it when I get time. Or you can try to compile it.
I have had a bit of a play with the "toledo" chess program. I can almost see why it is not working - I think it may have exposed a bug in the Catalina code generator. I need to do some more work on it to be sure. I hope to have a fix for it on the weekend.
Ross.
BTW: Does Catalina produce a more readable version of the code somewhere in the pipeline?
BTW2: (Maybe showing my ignorance here) I had the "main" call at the top of the program with a call to "my_main" in it. Shouldn't that have produced an error in C, since (without a header), it doesn't know what "my_main" is, since it is at the bottom of the program?
You seem to be having more than your share of hardware issues lately. With the Gameduino+ASC and now this. And it all seems to be data corruption of some kind or another. I'd really check your environment for intense RFI/EMI or very noisy power supplies.