Heater said By the way, I understand Catalina does have an IDE now.
Yes, here is a screenshot of one in action. See the Catalina thread for what it took to get this far.
1) One button to compile/download/save on an sd card/run
2) Code all running in external 512k sram
3) hub ram free for video buffers or other uses
4) two pass loader - load the cogs first, then reload hub ram. No wasted hub ram left over from loading cogs (which can be over 40% of the space in spin)
5) uses a vga display, keyboard, two serial ports and an sd card with gigabytes of storage
We may not have Big Spin, but we do now have Big C.
I was so excited when CP/M enabled C to go from 32k up to 50k of code space. But this takes it up to 512k. Who knows where it may end?
That's great. I have been eagerly following your progress.
As you see, Catalina is a phenomenal piece of work. There is lot's of gold in it's huge directory tree. A compiler, loaders, lot's of platform support, most of an OBEX etc etc. I fear you might be giving up CP/M and BDS C very soon:)
One button compile will come to Zog when I get hold the Arduino IDE for ZPU but is not a high priority for me.
512K, pah small fry, Zog is living in 32MBytes:) But I still want to get Zog working on the DracBlade via VMCog.
Zog can have all HUB RAM free to.
VGA display is something Zog desperately needs.
Yep, we have had big C for some time. Looks like you are all set with Catalina.
Who knows where it may end?
Indeed, there is a lot happening here. Jazzed wants to get uCLinux running on the Prop, Crazy. I'd be happy with FreeRTOS. Whe we get to Prop II things will go orbital yet again.
RossH,
Happy birthday. Welcome to the "Old Geezers Club":)
Then it needs some file I/O which David has done again just using Spin for the FAT because it's there.
Actually, I'm using C code now to do FAT file I/O. I only use Spin code for raw sector I/O. The FAT code I'm using supports both FAT16 and FAT32 and can handle multiple open files at once. I didn't write it but I made a few minor changes to get it to compile cleanly.
Actually, I'm using C code now to do FAT file I/O. I only use Spin code for raw sector I/O. The FAT code I'm using supports both FAT16 and FAT32 and can handle multiple open files at once. I didn't write it but I made a few minor changes to get it to compile cleanly.
Very nice David! When will we see a new ZOG package with this?
Very nice David! When will we see a new ZOG package with this?
I have to figure out why my cache interface is flakey. I did some more testing and determined that it is the call to siprintf in hello.c that is failing. I suspect there is a bug in my cache code but I haven't been able to find it yet.
I have to figure out why my cache interface is flakey. I did some more testing and determined that it is the call to siprintf in hello.c that is failing. I suspect there is a bug in my cache code but I haven't been able to find it yet.
What terminal emulator are people using? It seems that all of the programs I download or get from other people assume they can send a linefeed character ("\n") to get to the start of the next line but the terminal emulators I use (putty), emulate a hardware terminal where it is generally necessary to send "\r\n" to get the start of the next line. I'd like a terminal emulator that works well with the Propeller conventions of just "\n" but also has a way to capture the terminal output so I can paste it into a forum message if necessary. Any suggestions?
@David, I wrote my own terminal emulator, but even when given the choice, I chose to copy standard terminal conventions rather than propeller conventions. My reasoning is that there are two different characters that come from the teletype/typewriter world. Linefeed means move up one line. Carriage return means move the carriage (the big thing that types on a typewriter) to the return position.
It has meant in the past that I've had to rewrite huge amounts of propeller code, but at least the code then works with all terminals (except the propeller one).
I'd like a terminal emulator that works well with the Propeller conventions of just "\n" but also has a way to capture the terminal output so I can paste it into a forum message if necessary. Any suggestions?
I've been using a custom variation of "nanocom" on linux (no windows) that has a "-n" option to allow LF->LF+CR newlines. It also has the ability to detect a user specified string and exit if found "-x string". That allows for timing measurements or just letting me get back to editing in the same window after I've seen enough output. Copy/paste is easy since the program runs in a command window.
Comments
Yes, here is a screenshot of one in action. See the Catalina thread for what it took to get this far.
1) One button to compile/download/save on an sd card/run
2) Code all running in external 512k sram
3) hub ram free for video buffers or other uses
4) two pass loader - load the cogs first, then reload hub ram. No wasted hub ram left over from loading cogs (which can be over 40% of the space in spin)
5) uses a vga display, keyboard, two serial ports and an sd card with gigabytes of storage
We may not have Big Spin, but we do now have Big C.
I was so excited when CP/M enabled C to go from 32k up to 50k of code space. But this takes it up to 512k. Who knows where it may end?
That's great. I have been eagerly following your progress.
As you see, Catalina is a phenomenal piece of work. There is lot's of gold in it's huge directory tree. A compiler, loaders, lot's of platform support, most of an OBEX etc etc. I fear you might be giving up CP/M and BDS C very soon:)
One button compile will come to Zog when I get hold the Arduino IDE for ZPU but is not a high priority for me.
512K, pah small fry, Zog is living in 32MBytes:) But I still want to get Zog working on the DracBlade via VMCog.
Zog can have all HUB RAM free to.
VGA display is something Zog desperately needs.
Yep, we have had big C for some time. Looks like you are all set with Catalina.
Indeed, there is a lot happening here. Jazzed wants to get uCLinux running on the Prop, Crazy. I'd be happy with FreeRTOS. Whe we get to Prop II things will go orbital yet again.
RossH,
Happy birthday. Welcome to the "Old Geezers Club":)
Nick
It has meant in the past that I've had to rewrite huge amounts of propeller code, but at least the code then works with all terminals (except the propeller one).