The NES adapter is a hack, basically the NES adapter has all those lines in parallel across the header which shorts the two headers together, so if you want to play games, just hang it over OR make a little cable adapter. I wish that the nes adapter had only a sip header, but the dual header is more stable, so I see parallax's thinking -- but you can always just cut one row off, or make a cable, or just get some nes connectors and built them into your case with another PCB or cable or whatever -- if you want to use it to play games on the C3 that use the NES.
The video memory question -- the Prop can only "see" 64K period. There is 32K RAM and 32K rom, other than that everything else you connect is not part of the memory system. The eeprom is just an image that gets copied byte by byte into the prop's 32K ram, so 32K or 1GB eeprom, only 32K images are pulled in. Then its up to you to do what you want with the extra eeprom, flash, sram, or whatever you connect to the Prop.
I consulted a lot on the new P2's 3D hardware, but haven't talked to chip in a while about it, but one thing that might be nice is an external bus interface mode that allows you to address or at least virtually page blocks of external ram and have the internal buses use an external bus for the 32-64K working ram, but if he hasn't already done that???? (those following the P2 thread) then I doubt he will be able to at this late date without delaying the chip even more.
So, bottom line the Props can only access INTERNAL memory and execute out of it, any other external stuff is "funny" business we trick and make happen with slower code.
Andre: Correct engineering practices would always label the part as Peter has confirmed. However, there is a lot of confusion.
I use SI and SO (meaning serial in and serial out) from the props perspective because there are a lot of novices here who can get confused. I also label the pcb with a "<" and ">" adjacent to the pins to show the direction.
The C3 is a standard Prop board with a particular set of peripherals and boots from either an attached PC or the EEPROM. You can always have a pre-programmed EEPROM, but I think the C3 will come with its demo program preloaded since that would be used for testing.
The C3 is a standard Prop board with a particular set of peripherals and boots from either an attached PC or the EEPROM. You can always have a pre-programmed EEPROM, but I think the C3 will come with its demo program preloaded since that would be used for testing.
So basically, the C3 or a couple of them could use a computer as a file server and have virtual memory? Could you imagine adding commands and libraries to Propbasic now that all you have to do is doanload and overwrite from the PC? You could add extra commands if you were willing to wait for them to be transmitted back to the board.
How does the C3 boot? Does it boot from just EPROM or does it go to Micro SD card as well?
There is no reason why you could replace the EEPROM code with a simple boot routine that looks for an AUTOEXEC.BIN on the SD to boot the C3, but like Mike said, there is no reason we can't do that with existing hardware.
Everyone needs to remember a prop is a prop is a prop. We can't add features to the processor, we can only add features to the PCB. That said, the prop always works the same, has the spin interpreter, no external bus, finite speed, memory etc. But, like anything, the C3, as do other boards, try to put a number of commonly used chips on the PCB using a consistent design architecture (buses, etc.), so you don't have to frankenstein something together.
But, any "can you do this with the C3" in many cases is dictated by "can you do this with the prop" first. We have to work around its core functionality.
For example, we have been working on a number of BASICs trying to find the best way to run code -- interpreter, virtual machine, etc. should we use the main memory for scratch space and page in SRAM? Should we execute out of Flash with a cache, and so forth. But, we are always constrained by the prop and have to try and work around its limits.
So, in most cases, as long as its a "software" problem, you can pretty much code anything you want. As long as the Prop isn't doing something it can't. For example, the Prop can NOT boot from FLASH, SD, Ethernet, and so forth. But, if you put a teenie tiny bootloader into the EEPROM, then that can load a second bootloader that CAN boot from SD, ethernet, wireless, FLASH, whatever you want. And in fact as Mike mentioned there are a lot of those around.
The only real limits of the prop or any processor for that matter is memory and computational abilities, we can't change those -- period. But, we can add extra memory and computational abilities with more chips and software if we are willing to take the speed and IO usage hit.
And in many cases, people are using props to control robots, or real-time "slow" things like doors, pumps, servos, etc. you don't need code that is going blazing fast -- if you did, there wouldn't be a million plus basic stamps out there! You just need a large program mabye, or 64K of ram, etc. and these things are all doable. So the idea of the C3 is to give you a good set of peripherals, keep cost down, and impact on the IO down (thus the decision to go SPI). And then see what people can do with these things
At $79 USD or less, I am look forward to it very much. Most of my programing seems to be inserting delays as the Propeller is extremely fast for a microcontroller.
To date, adding all those other features has been too expensive on a DIY board. And I am sure I need the ADC for certain sensing devices.
I guess this will be a Christmas present to myself.
Also, like I said, the basic stamps executed 1000's of instructions per second and is just fine for 90% of control work. And to put these boards in perspective, even if external memory is hundreds of K per second. The 80's were just fine with 1Mhz processors, and high level languages that ran at 100's of instructions per second And the overall systems (mostly 6502) too 2-3 clocks per instruction, so you were lucky to get a total through put of .25 - .5 Mips. Thus, even accessing memories, flash, and SD over SPI, you still get a very fast machine, and that coupled with some smart caching, you can get a very robust system.
And yes, the A/D was a last minute thing -- I was like, "I have so many SPI selects, its like a candy store what else can I put on here....hmmm, these like $1 A/D look good, plus someone doesn't have to waste a core doing R/C delays and software A/D".
I liked the shield. It would be good if the shield design could be ported to multiple PCB software packages (Eagle, Dip Trace, PCBExpress, etc.). Then people could take the basic shield PCB design and make new shields. Examples could be a robot shield with motor driver chips, game controller shield with joysticks, accelerometers, vibrator motors, LEDs, a data logger shield with sensors to measure whatever you are interested in.
They are fixed at 5V, this way it will work with either a 0...3.3V, or a 0...5V without any other voltage divider, and you still have good accuracy with the 0...3.3v since its 12 bit per channel.
The demo coders are mostly doing boring things like porting the C compiler, BASIC, things like that trying to find ways to take advantage of memory etc. There are also two game developers working on stuff, but nothing yet finished -- so we will see. Since the C3 is for applications and not games per se, I am more interested in things that are boring like drivers, apps, things that perform actual functions or tools that could be used --- so that's what I told everyone to do.
You know that my interest in the C3 is gaming.. No secret there, but some public peeks at that "boring" stuff would make some interesting video footage as well..
Glad to know there is some "boring" stuff going on in the background..
Now pull that that curtain a little bit more.. A lot of us like gears!
The demo coders are mostly doing boring things like porting the C compiler ....
Which one? Getting RossH to sign on to "1000's of instructions per second ...." for Catalina seems difficult at best. I would be very surprised if ImageCraft is involved at all. Of course porting ZOG should be a snap by now.
David Betz the creator of XLisp and the BASIC for the XGamestation and Chameleon has been experimenting with all possibilities. In the end, the C compilers are just ok and he hasn't been happy with the performance, memory, whatever. I think he has decided to port his VM to ASM and run one of his C-BASIC languages, but again these are just interesting things that try and take advantage of the SRAM, FLASH, and SD card.
ZOG is working on the C3 using the two SPI SRAMs for program storage. I have it working both with VMCOG and with a direct-mapped cache implementation I based on SdramCache.spin. I'm currently working on adding file I/O support so I can port my Basic compiler/interpreter to the C3.
Congrats David & Heater. I agree that Zog is a good way to go for a C compiler on the C3 at present.
Catalina will work fine in LMM mode if anyone really needs the speed, but adding XMM support is unlikely to be worth the effort while the only external RAM available is both quite slow (serial access) and also quite small (64kb). Interpreted or byte-coded languages like BASIC or Zog can make better use of such RAM than Catalina can.
(Having said that - I would still do it if I had time - I just hate to see Zog beating Catalina at anything! ).
Of course, this would change if someone developed a parallel RAM "add on" for the C3 - in that case adding XMM support to Catalina would be both easy and worthwhile.
I have tried Catalina C and like it very much. Unfortunately, even split into three phases, my Basic bytecode compiler won't fit in hub RAM. Also, I wasn't able to write even a simple program that did file I/O compiled to run in hub RAM. It seems Catalina really needs a fast external RAM to run most programs.
True - if you need the full ANSI compatible C library (including SD-card file system support) then you currently need to execute Catalina programs from fast XMM RAM.
Adding the option of a "reduced functionality" C library with a much smaller memory footprint is still on my "To Do" list
Wow, I did not know that the C3 was the target for your Zog and BASIC compiler work. Perhaps I was not paying enough attention.
I have to be sure to get my self a C3.
David, could you use an extra kilobyte of RAM? I should make a replacement for the C start up code (crt0.S) with a lot of stuff Zog does not need removed.
Actually what Zog on the C3 needs is for the C byte codes to be out in external memory but the variables and stack to be in HUB. We would get a huge speed up that way. Also the code could be in FLASH rather than RAM.
First one has to understand GCC linker scripts so as to locate code and data wherever you like. So far this has eluded me. The default ZPU linker script is a huge and complicated thing most of which I'm sure we don't need.
Zog itself would need a little change so that code fetches can be redirected to external RAM independently of data access.
Comments
The video memory question -- the Prop can only "see" 64K period. There is 32K RAM and 32K rom, other than that everything else you connect is not part of the memory system. The eeprom is just an image that gets copied byte by byte into the prop's 32K ram, so 32K or 1GB eeprom, only 32K images are pulled in. Then its up to you to do what you want with the extra eeprom, flash, sram, or whatever you connect to the Prop.
I consulted a lot on the new P2's 3D hardware, but haven't talked to chip in a while about it, but one thing that might be nice is an external bus interface mode that allows you to address or at least virtually page blocks of external ram and have the internal buses use an external bus for the 32-64K working ram, but if he hasn't already done that???? (those following the P2 thread) then I doubt he will be able to at this late date without delaying the chip even more.
So, bottom line the Props can only access INTERNAL memory and execute out of it, any other external stuff is "funny" business we trick and make happen with slower code.
Andre'
Andre'
Andre'
I use SI and SO (meaning serial in and serial out) from the props perspective because there are a lot of novices here who can get confused. I also label the pcb with a "<" and ">" adjacent to the pins to show the direction.
So basically, the C3 or a couple of them could use a computer as a file server and have virtual memory? Could you imagine adding commands and libraries to Propbasic now that all you have to do is doanload and overwrite from the PC? You could add extra commands if you were willing to wait for them to be transmitted back to the board.
Yes, but so could pretty much any Prop board.
Keep in mind that the PC connection is just a serial port, probably practically limited to 230KBps under the best of circumstances.
There is no reason why you could replace the EEPROM code with a simple boot routine that looks for an AUTOEXEC.BIN on the SD to boot the C3, but like Mike said, there is no reason we can't do that with existing hardware.
OBC
But, any "can you do this with the C3" in many cases is dictated by "can you do this with the prop" first. We have to work around its core functionality.
For example, we have been working on a number of BASICs trying to find the best way to run code -- interpreter, virtual machine, etc. should we use the main memory for scratch space and page in SRAM? Should we execute out of Flash with a cache, and so forth. But, we are always constrained by the prop and have to try and work around its limits.
So, in most cases, as long as its a "software" problem, you can pretty much code anything you want. As long as the Prop isn't doing something it can't. For example, the Prop can NOT boot from FLASH, SD, Ethernet, and so forth. But, if you put a teenie tiny bootloader into the EEPROM, then that can load a second bootloader that CAN boot from SD, ethernet, wireless, FLASH, whatever you want. And in fact as Mike mentioned there are a lot of those around.
The only real limits of the prop or any processor for that matter is memory and computational abilities, we can't change those -- period. But, we can add extra memory and computational abilities with more chips and software if we are willing to take the speed and IO usage hit.
And in many cases, people are using props to control robots, or real-time "slow" things like doors, pumps, servos, etc. you don't need code that is going blazing fast -- if you did, there wouldn't be a million plus basic stamps out there! You just need a large program mabye, or 64K of ram, etc. and these things are all doable. So the idea of the C3 is to give you a good set of peripherals, keep cost down, and impact on the IO down (thus the decision to go SPI). And then see what people can do with these things
Andre'
To date, adding all those other features has been too expensive on a DIY board. And I am sure I need the ADC for certain sensing devices.
I guess this will be a Christmas present to myself.
And yes, the A/D was a last minute thing -- I was like, "I have so many SPI selects, its like a candy store what else can I put on here....hmmm, these like $1 A/D look good, plus someone doesn't have to waste a core doing R/C delays and software A/D".
Andre'
John Abshier
Andre'
How about some videos to see what kind of action is happening here?
OBC
Andre'
Glad to know there is some "boring" stuff going on in the background..
Now pull that that curtain a little bit more.. A lot of us like gears!
OBC
Andre'
Don't know what will be the results in the end.
Andre'
Catalina will work fine in LMM mode if anyone really needs the speed, but adding XMM support is unlikely to be worth the effort while the only external RAM available is both quite slow (serial access) and also quite small (64kb). Interpreted or byte-coded languages like BASIC or Zog can make better use of such RAM than Catalina can.
(Having said that - I would still do it if I had time - I just hate to see Zog beating Catalina at anything!
Of course, this would change if someone developed a parallel RAM "add on" for the C3 - in that case adding XMM support to Catalina would be both easy and worthwhile.
Ross.
True - if you need the full ANSI compatible C library (including SD-card file system support) then you currently need to execute Catalina programs from fast XMM RAM.
Adding the option of a "reduced functionality" C library with a much smaller memory footprint is still on my "To Do" list
Ross.
Wow, I did not know that the C3 was the target for your Zog and BASIC compiler work. Perhaps I was not paying enough attention.
I have to be sure to get my self a C3.
David, could you use an extra kilobyte of RAM? I should make a replacement for the C start up code (crt0.S) with a lot of stuff Zog does not need removed.
Actually what Zog on the C3 needs is for the C byte codes to be out in external memory but the variables and stack to be in HUB. We would get a huge speed up that way. Also the code could be in FLASH rather than RAM.
First one has to understand GCC linker scripts so as to locate code and data wherever you like. So far this has eluded me. The default ZPU linker script is a huge and complicated thing most of which I'm sure we don't need.
Zog itself would need a little change so that code fetches can be redirected to external RAM independently of data access.
Jeff Ledger, but close enough.
Guess it'll be me that does videos?
OBC