I really don't belong in this conversation... but I paid my money, got my FPGA's directly from Parallax... one of them... the expensive one. So, for one day at least, I'm feeling entitled:)
Is everything really available so that a really bright, motivated person could modify the P1... and then modify everything else required to make it programmable from an OpenIDE using extensions to SPIN and PASM?
Or are we really saying that C (or possibly Forth) will be the only way to go and that some conspiracy will be required?
One question: I have DE2-115 but no Propplug and no possibility to get it fast. Is it possible to use any available rs232 to usb dongle with circuit like this:
Anyone understands the trick Chip is playing with the "fake" counter PLL in module in module "cog_ctr.v"lines 109-119 ? He is using a 36 bit register to count in but then??
In the real P1 each counter has its own PLL to multiply the frequency of the counter MSB with 16, but in the FPGA emulator so many PLL's are not available
Can someone that is a better coder than me browse the *.src files and confirm if an eeprom is connected to pin 28-29 that the EEprom is programmed the same way as P1, and that the FPGA emulator can boot from the EEprom??
Is everything really available so that a really bright, motivated person could modify the P1... and then modify everything else required to make it programmable from an OpenIDE using extensions to SPIN and PASM?
Or are we really saying that C (or possibly Forth) will be the only way to go and that some conspiracy will be required?
I'm not following the question ?
What runs in the FPGA looks exactly like a P1 (assuming there is room for things like Character ROM).
It swallows binary files just the same as a genuine 40 pin part.
ANY language that runs on a 40 pin part, will run the same on the FPGA version. They are (currently) binary compatible.
At the same clock speed, it should run exactly the same timing.
Okay, I found an older copy of Quartus on my Windows 7 machine and used it to build the P1 Verilog sources. I then downloaded the resulting image to my DE0-Nano board and the programming was successful. I unplugged the DE0-Nano and moved it to my Mac where I compiled and downloaded fibo and ran it getting the following results...
Are those numbers the same as a P1 (I guess this is at 80MHz ?)
- a column for each of FPGA & 40pP1 could be nice here.
I have to join the chorus here and say this is fantastic. Audacious. Amazing.
This post will be revised as a place to put new file downloads created by the community, if desired.
Once again I have to say github is the place for this. Parallax will keep the repository there and accept contributions if they are deemed worthwhile. The "community" will be busy cloning and forking from that repository and may keep them on git hub or wherever they like.
This does not mean that Parallax would not have it own repo off of github. In the git world every repo is a peer.
By the way: I love that logo, an Open Source Hardware gear with a Propeller Beanie on it. However I do wonder what the owners of the Open Source Hardware logo would say about it. Or indeed the owners of the Open Source Software logo from which it is derived. I recall the the OSS and the OSH guys had a tussle about that a while back.
potatohead,
Does Github only work with git, or does it support Mercural?
No. github could not do all the wonderful things it does without git.
And then there's also a strong argument for a friendly web page/blog/pdf doc linking across to reference builds, for those less used to github.
Yes indeed. And all that stuff plus a wiki can also be on github included in the projects area.
This should have all been in place before announcing open sourcing anything. Simply throwing up a zip file does not cut it. I would look at little projects like the Espruino to see how easily it can be started of https://github.com/espruino/Espruino. Just the code a licence and a nice README.md file.
That was excellent coverage on AdaFruit. They really get it.
I appreciate your concerns but you should not worry so much.
I concur with all your stated "upsides" to this idea. This is what I think about the "down sides":
* Nothing happens at all, and after all week or two of hoopla, things go back to "normal".
This is not really a down side. That would just mean things just carry on as they are. The only wasted cost being the time Chip and others have put into preparing this release.
* While you can't create your own Propeller chip cheaply "today", this will likely change in the future. FPGA will become cheaper & more common. (fightens me most)
I don't think so. FPGA's have actually been getting bigger, more complex and more expensive over time. It's hard to find one that does not have billions of pins in an BGA and requires multiple supply voltages and other complications. I don't see this trend reversing any time soon. Don't forget that for any piece of logic an FPGA will use a lot more silicon than a dedicated chip. I imagine it's impossible for the FPGA to ever compete on price, power consumption and simplicity with the real thing.
* Variations from the original design could create code confusion, instability, and incompatibility with existing code.
True. This is also true of a lot of opens source software. There are thousands of different, patched, customized, tweaked Linux kernels out there for example. A lot of them with changes that may never get into the "main line" kernel. Everything works out just fine.
Yes they do. Great coverage. And man, Limor is just a kick! She's ultra geeky. Loved the show. I'm a fan, and it's well done. Great way to stay connected and motivated, IMHO.
Seconded on "this should have been in place", but it can always get done.
Frankly, it might make some sense for Parallax to simply authorize somebody to get it all setup, then hand the keys over to Parallax and consult for a little while to get the crew there up to speed. IMHO, doing that is worth it, and I really don't think it's that big of a deal.
We are kind of in a bubble here. It's a nice bubble, and some of us are out there working in OSS land proper. A lot of us aren't. Going forward, a lot of us won't need to, but if we are to maximize this move, I really do think we also need to start participating as more of an OSS peer, particularly with something like this. Eventually, the Parallax repo contains the obex, and we've got links to users all over the place and their repositories and the ecosystem is more accessible to people outside. Yes, I realize that's a big jump for most of the community. That's OK. For a considerable time, nobody has to. But those of us who understand this, and who are contributing really should model it. Parallax can continue to take the best and put it out there as they always have and slowly move the whole works forward.
It should not take more than a couple of hours for someone at Parallax to put that code and a licence file and a READ.md text file and whatever other documentation in to a github repo. A day tops. Just follow the dead simple instructions on the github site. Stick an initial release tag on it.
Figuring out how to work with git nicely into the future can be done at leisure after that.
Of course there is the worry that someone will take the P1 design and put up the cash to clone it, getting them made in huge quantities and selling them for 50 cents a piece. Perhaps adding some desperately needed features like more RAM or whatever to increase their market potential.
Is this likely? Give the current market size of the P1 it seems like an unlikely choice for a cloner.
Why stop at 64k ?
No real reason to stop at 64io either..
Someone who has a 484 pin FPGA, has something like 224 ios on the device
I like the way you think... Guess we could have PortB, PortC, PortD....
On the other hand, if we only had PortB, 2X RAM and 2X Speed we could still use Prop Tool as is (except maybe you couldn't load into the upper RAM).
Otherwise, you also need to modify the Spin/C compilers...
Hopefully, someone who knows FPGA will probe the boundaries...
Of course there is the worry that someone will take the P1 design and put up the cash to clone it, getting them made in huge quantities and selling them for 50 cents a piece. Perhaps adding some desperately needed features like more RAM or whatever to increase their market potential.
Is this likely? Give the current market size of the P1 it seems like an unlikely choice for a cloner.
That's what I think too although I suppose you could try to make a case that the P1 sells poorly because it is too expensive or too slow. In that case, some company that could afford to fab it in 28nm could possibly make a faster one with more memory that sells for a fraction of the cost. How many more people would use P1 if it cost < $2? Anyway, I find this highly unlikely. As Chip keeps saying, the code for P1 is surprisingly simple. Anyone who had the resources to fab a 28nm chip would probably also have a chip designer who could clone the P1 in short time without access to the source. I think Parallax is pretty safe.
I might argue that the Propeller sells poorly because it is a weird and unusual architecture that few take the time to discover the benefits of. That it comes from an almost unknown and small vendor. Who would base their designs on it when they can use familiar MCU's from renowned and trusted vendors? Even if it does mean cobbling together custom logic to support those corners of the design that a regular MCU cannot tackle.
It could be that having a couple of decent clones around would increase awareness of the Propeller, increase it's acceptability as a part you can rely on with multiple vendor sources. In that way the total Propeller market would grow. Increasing sales for Parallax even if the majority of the market is filled by some one else.
I like the way you think... Guess we could have PortB, PortC, PortD....
On the other hand, if we only had PortB, 2X RAM and 2X Speed we could still use Prop Tool as is (except maybe you couldn't load into the upper RAM).
Otherwise, you also need to modify the Spin/C compilers...
Hopefully, someone who knows FPGA will probe the boundaries...
I suggested 64KB hub and 64 I/O because those two additions are quite simple to achieve, and the tools quite simple to change.
Beyond 64 I/O becomes a problem of how to address them within the P1 framework, as does to a lesser extent with >64KB hub.
Just preload the top 32KB of hub ram with the ROM code would work fine.
I have now looked closely at the Verilog code. It's not that difficult to follow, although making changes will certainly be a learning curve beyond anything simple.
Personally, I would rather the code remain here, at least for the time being. I don't know anything about Github, and I don't want to bother learning this atm. I see a lot of advantages of us being able to post Verilog code questions, changes, etc here. IMHO there is a significant benefit to Parallax for both the code and forums to remain here too. If and when it becomes necessary, it can always be put on Github later.
I have seen what has happened on "thingiverse". I am not saying this can/will happen on Github. I am more concerned to make sure Parallax benefits from this magnificent gesture.
I suggested 64KB hub and 64 I/O because those two additions are quite simple to achieve, and the tools quite simple to change.
Beyond 64 I/O becomes a problem of how to address them within the P1 framework, as does to a lesser extent with >64KB hub.
Just preload the top 32KB of hub ram with the ROM code would work fine.
I have now looked closely at the Verilog code. It's not that difficult to follow, although making changes will certainly be a learning curve beyond anything simple.
Personally, I would rather the code remain here, at least for the time being. I don't know anything about Github, and I don't want to bother learning this atm. I see a lot of advantages of us being able to post Verilog code questions, changes, etc here. IMHO there is a significant benefit to Parallax for both the code and forums to remain here too. If and when it becomes necessary, it can always be put on Github later.
I have seen what has happened on "thingiverse". I am not saying this can/will happen on Github. I am more concerned to make sure Parallax benefits from this magnificent gesture.
I suppose Parallax could run a server hosting the git repositories. If the code remains here I think they should consider that. Just keeping everything in forum messags with attachments or in a downloads section is not really workable. There isn't an easy way to see the history of changes to a file and you end up with lots of incompatible versions. Look what has happened with OBEX and the zillions of variants of something as simple as FDS. I think some sort of revision control system that supports branching and merging is needed. It doesn't need to be git but it can't just be zip files.
It is easier to clone a repository from github or pull updates than it is to search around for a zip file, download it up pack it etc etc. What would be so hard about "git clone https://github.com/parallax/propeller.git."? You would not even have to type that you can cut and paste it from the front page of the github repository. That single action is possibly the only thing about git you would ever have to use.
Having the code in github would not mean you have to learn git or use it in any serious way.
Having the code in github does not preclude having versions of it zipped up and mirrored here available for download in exactly the same way.
Thinyiverse or whatever has nothing to do with any of this.
Right now, the current forum code policy is MIT license code only. If it's not MIT, it has to be hosted elsewhere. Parallax is hosting the code from their own server, not the forum, so that works, but just putting builds here doesn't. FYI.
I'm in favor of continuing that policy too.
Frankly, just tossing it around here in the forum is most likely to make a mess than it is anything else.
As for benefit, here's a counter argument:
Many people, who are experienced enough to understand this release and do stuff with it, are not going to have any trouble with GitHub at all. It's the de-facto place to release and work with open code. As an example of even niche, obscure things bene fitting from GitHub, consider the Prince of Persia source code release for the Apple 2. That's a 6502 machine from the 70's, though that game was written and worked on 6502 machines produced into the 90's, but still. Old 6502 assembly language code lived on GitHub just fine.
What happened is a ton of people looked at the repository, it got cloned a few times, and one guy decided to write an assembler that behaves like Merlin, the original assembler in the day, built the code and demonstrated how it can assemble into working disk images for use in emulators and the real machine today. And it does work too. I've got the game to play on my Apple 2 and I can see all the work done on that code too, nicely organized. Should I want to do something like make a new level, or add a feature, I would do the same thing, and the history goes all the way back to the original, untouched release. Nice.
If it can happen for that, we've got no reason not to. And like Heater says, it's just not hard.
To be honest here, we are working in somewhat of a state of isolation here. It's comfy, and we all do what we do, but really it's not all that accessible to interested people. That's bad for us, Parallax and them!
Now, say they do get at the code and find they want to work with it. Who to work with? US! We would be quite pleased to have new blood join us and who knows what could happen? So how do we work? Most people, and a growing number of people overall, use management tools in order to actually work together on larger code or more complex code bodies. With this thing, there could very easily be a few projects going on, several different builds, etc... Keeping that sane is going to matter. And the burden of sorting things out increases exponentially with the number of contributors and versions and features too.
If it's on GitHub, the way of working is cut n' dried. They can jump in, make an account here and join the party, no worries. If not, then they have to unpack that code, look it over, wonder why it isn't setup proper for this kind of thing, maybe consider their own repository, then make an account here only to find we've got stuff all over the place, and it's hard!
And example #2. When David got some of GCC working for the earlier P2, I wanted to jump in, along with Baggers and do some stuff. Now, PropGcc is using Google Code, which uses a little different type of management, but the core way to work was no different. So I got on my Mac this time, as that's the machine I wanted to use, got myself a client, pulled down the PropGCC project and took a look around. Not 10 minutes later, I had a nice build going of the P2 branch David was working on, and I compiled a program and put it on my DE2. Didn't take but a couple hours start to finish.
Here's the beautiful part:
David updates a coupla days later. I mash on a button or two, my local copy syncs up, I do a build, and now I've got that feature super easy. And there is more! Somebody here asked for PropGCC V1.0 build. That's all in the Repository. Mash another button, get the history, sync up to that version, build it, done, package, and put the package out there for others.
Today, months later, I can mash on those buttons, get all caught up, and be synced up, add my contributions, tag, and be rocking in a very short amount of time. And when Chip gets the P2 FPGA done, and it's PropGCC time, that's exactly what I'll do. Won't take but a few minutes, and I can even ask that repository for the old and the new, compare, do whatever I want with no worries about filenames and zip files, etc... It will just be right.
That's what most people are going to expect on something like this. Not zip files floating around with funny names, etc...
It's to our great advantage to do this right, step up, and put the code out there as an Open Source peer, not keep it tucked away, difficult to interact with, and with us.
I suppose Parallax could run a server hosting the git repositories. If the code remains here I think they should consider tha
But isn't that totally pointless, expensive and unreliable? It will certainly take a lot more work than sitting down with the github instructions for an hour and walking through them.
Git is a distributed system. At git clones of a repo are peers on an equal footing. Chip and Ken and Parallax the corporation itself will have their own git repos on their machines at the office at home in the cloud, wherever they like. They need not be publicly reachable. The "clone" repository on github is not special among it's peers. It is only the public facing repo.
If github were to close down or otherwise become undesirable to use, no problem, then is the time to think about hosting your own public repos.
I am thinking about the minimum Verilog changes to get hubexec running on the P1...
PC needs to be increased (16 bits to support 64KB hub)
Addresses > 2KB will be in hub
Need a CALL/JMP/RET instruction(s) with
16bit (for 64KB hub) destination address
Initially store return address in a fixed cog location $1EF
Other support instruction(s) may be helpful later.
The initial PASM memory model would be...
Registers in lower memory - 512 cog longs
Code may reside and run from register space (as it is now)
Code may reside and run from hub (>512 long)
Hub code cannot be self modifying
Before anyone comments. Initially this is not going to provide much of a performance boost over LMM due to the need to wait for the hub cycle to fetch the next hubexec instruction. However, it makes the code significantly easier to write, and it saves double longs for each CALL/JMP/RET instruction which also means a small speed improvement.
But isn't that totally pointless, expensive and unreliable? It will certainly take a lot more work than sitting down with the github instructions for an hour and walking through them.
Git is a distributed system. At git clones of a repo are peers on an equal footing. Chip and Ken and Parallax the corporation itself will have their own git repos on their machines at the office at home in the cloud, wherever they like. They need not be publicly reachable. The "clone" repository on github is not special among it's peers. It is only the public facing repo.
If github were to close down or otherwise become undesirable to use, no problem, then is the time to think about hosting your own public repos.
I agree but it would be better than zip files if they want to keep it on a Parallax-owned site. I think github or Google Code would probably be best. I'm happy to setup the github repository if no one else wants to.
I am thinking about the minimum Verilog changes to get hubexec running on the P1...
PC needs to be increased (16 bits to support 64KB hub)
Addresses > 2KB will be in hub
Need a CALL/JMP/RET instruction(s) with
16bit (for 64KB hub) destination address
Initially store return address in a fixed cog location $1EF
Other support instruction(s) may be helpful later.
The initial PASM memory model would be...
Registers in lower memory - 512 cog longs
Code may reside and run from register space (as it is now)
Code may reside and run from hub (>512 long)
Hub code cannot be self modifying
Before anyone comments. Initially this is not going to provide much of a performance boost over LMM due to the need to wait for the hub cycle to fetch the next hubexec instruction. However, it makes the code significantly easier to write, and it saves double longs for each CALL/JMP/RET instruction which also means a small speed improvement.
You also need a way to load a 32 bit constant. That is where my BIG instruction came from that turned into AUGS and AUGD.
I'm on a Mac so I usually use BST. In this context, at least when using full serial duplex, a power cycle is required between downloads to the RAM of the FPGA-Prop1 (otherwise the Prop isn't found on subsequent ttys).
I found the same was required using Prop Tool. Otherwise works fine.
BTW is a $$$subscription version of Quartus required to "get serious" with compiling Verilog code.
I currently have the "Web Edition 13.0"
Cheers
Brian
Right now, the current forum code policy is MIT license code only. If it's not MIT, it has to be hosted elsewhere. Parallax is hosting the code from their own server, not the forum, so that works, but just putting builds here doesn't. FYI.
I'm in favor of continuing that policy too.
Frankly, just tossing it around here in the forum is most likely to make a mess than it is anything else.
What happened to the forum software??? I didn't see the rest of this post until I went to reply.
??? Now its there! Was it a postedit???
Now, IIRC isn't it only the code on OBEX that must be MIT?? I thought code posted on the forum isn't part of that requirement although it has never bothered me.
As for benefit, here's a counter argument:
Many people, who are experienced enough to understand this release and do stuff with it, are not going to have any trouble with GitHub at all. It's the de-facto place to release and work with open code. As an example of even niche, obscure things bene fitting from GitHub, consider the Prince of Persia source code release for the Apple 2. That's a 6502 machine from the 70's, though that game was written and worked on 6502 machines produced into the 90's, but still. Old 6502 assembly language code lived on GitHub just fine.
What happened is a ton of people looked at the repository, it got cloned a few times, and one guy decided to write an assembler that behaves like Merlin, the original assembler in the day, built the code and demonstrated how it can assemble into working disk images for use in emulators and the real machine today. And it does work too. I've got the game to play on my Apple 2 and I can see all the work done on that code too, nicely organized. Should I want to do something like make a new level, or add a feature, I would do the same thing, and the history goes all the way back to the original, untouched release. Nice.
If it can happen for that, we've got no reason not to. And like Heater says, it's just not hard.
To be honest here, we are working in somewhat of a state of isolation here. It's comfy, and we all do what we do, but really it's not all that accessible to interested people. That's bad for us, Parallax and them!
Now, say they do get at the code and find they want to work with it. Who to work with? US! We would be quite pleased to have new blood join us and who knows what could happen? So how do we work? Most people, and a growing number of people overall, use management tools in order to actually work together on larger code or more complex code bodies. With this thing, there could very easily be a few projects going on, several different builds, etc... Keeping that sane is going to matter. And the burden of sorting things out increases exponentially with the number of contributors and versions and features too.
If it's on GitHub, the way of working is cut n' dried. They can jump in, make an account here and join the party, no worries. If not, then they have to unpack that code, look it over, wonder why it isn't setup proper for this kind of thing, maybe consider their own repository, then make an account here only to find we've got stuff all over the place, and it's hard!
Is it just for an address - ie 16 bit for now???
Anyway, I am going to look at getting the CALL/JMP/RET working first, just as absolute for now.
Yes, it could just be 16 bits which would then have to be followed by a RDLONG to get the actual constant but it would be nice to have the possiblity of >64K of memory. I guess you could make it a long address which would allow addressing 256k of memory.
Now, IIRC isn't it only the code on OBEX that must be MIT?? I thought code posted on the forum isn't part of that requirement although it has never bothered me.
I'm not suggesting anyone actually use my repo, it's for my convenience, but it's there if you want to and it's easy to view the code from some iPad or something.
Why is it called "Emulation"? I don't consider it an emulation in the normal meaning of the word in computer circles.
Why are there duplicate sets of files? Not a good idea.
Why isn't there a src directory for the booter, interpreter and runner?
Comments
Is everything really available so that a really bright, motivated person could modify the P1... and then modify everything else required to make it programmable from an OpenIDE using extensions to SPIN and PASM?
Or are we really saying that C (or possibly Forth) will be the only way to go and that some conspiracy will be required?
Rich
http://forums.parallax.com/showthread.php/118843-Programming-the-Prop-Chip-via-RS232-Interface-Help-advice-please.
(post #8)
to connect it to pc?
Can options be enabled and disabled easily?
In the real P1 each counter has its own PLL to multiply the frequency of the counter MSB with 16, but in the FPGA emulator so many PLL's are not available
I'm not following the question ?
What runs in the FPGA looks exactly like a P1 (assuming there is room for things like Character ROM).
It swallows binary files just the same as a genuine 40 pin part.
ANY language that runs on a 40 pin part, will run the same on the FPGA version. They are (currently) binary compatible.
At the same clock speed, it should run exactly the same timing.
Are those numbers the same as a P1 (I guess this is at 80MHz ?)
- a column for each of FPGA & 40pP1 could be nice here.
I have to join the chorus here and say this is fantastic. Audacious. Amazing. Once again I have to say github is the place for this. Parallax will keep the repository there and accept contributions if they are deemed worthwhile. The "community" will be busy cloning and forking from that repository and may keep them on git hub or wherever they like.
This does not mean that Parallax would not have it own repo off of github. In the git world every repo is a peer.
By the way: I love that logo, an Open Source Hardware gear with a Propeller Beanie on it. However I do wonder what the owners of the Open Source Hardware logo would say about it. Or indeed the owners of the Open Source Software logo from which it is derived. I recall the the OSS and the OSH guys had a tussle about that a while back.
potatohead, No. github could not do all the wonderful things it does without git. Yes indeed. And all that stuff plus a wiki can also be on github included in the projects area.
This should have all been in place before announcing open sourcing anything. Simply throwing up a zip file does not cut it. I would look at little projects like the Espruino to see how easily it can be started of https://github.com/espruino/Espruino. Just the code a licence and a nice README.md file.
That was excellent coverage on AdaFruit. They really get it.
I appreciate your concerns but you should not worry so much.
I concur with all your stated "upsides" to this idea. This is what I think about the "down sides": This is not really a down side. That would just mean things just carry on as they are. The only wasted cost being the time Chip and others have put into preparing this release. I don't think so. FPGA's have actually been getting bigger, more complex and more expensive over time. It's hard to find one that does not have billions of pins in an BGA and requires multiple supply voltages and other complications. I don't see this trend reversing any time soon. Don't forget that for any piece of logic an FPGA will use a lot more silicon than a dedicated chip. I imagine it's impossible for the FPGA to ever compete on price, power consumption and simplicity with the real thing. True. This is also true of a lot of opens source software. There are thousands of different, patched, customized, tweaked Linux kernels out there for example. A lot of them with changes that may never get into the "main line" kernel. Everything works out just fine.
Yes they do. Great coverage. And man, Limor is just a kick! She's ultra geeky. Loved the show. I'm a fan, and it's well done. Great way to stay connected and motivated, IMHO.
Seconded on "this should have been in place", but it can always get done.
Frankly, it might make some sense for Parallax to simply authorize somebody to get it all setup, then hand the keys over to Parallax and consult for a little while to get the crew there up to speed. IMHO, doing that is worth it, and I really don't think it's that big of a deal.
We are kind of in a bubble here. It's a nice bubble, and some of us are out there working in OSS land proper. A lot of us aren't. Going forward, a lot of us won't need to, but if we are to maximize this move, I really do think we also need to start participating as more of an OSS peer, particularly with something like this. Eventually, the Parallax repo contains the obex, and we've got links to users all over the place and their repositories and the ecosystem is more accessible to people outside. Yes, I realize that's a big jump for most of the community. That's OK. For a considerable time, nobody has to. But those of us who understand this, and who are contributing really should model it. Parallax can continue to take the best and put it out there as they always have and slowly move the whole works forward.
Those are my higher level thoughts on it anyway.
Figuring out how to work with git nicely into the future can be done at leisure after that.
Is this likely? Give the current market size of the P1 it seems like an unlikely choice for a cloner.
I like the way you think... Guess we could have PortB, PortC, PortD....
On the other hand, if we only had PortB, 2X RAM and 2X Speed we could still use Prop Tool as is (except maybe you couldn't load into the upper RAM).
Otherwise, you also need to modify the Spin/C compilers...
Hopefully, someone who knows FPGA will probe the boundaries...
It could be that having a couple of decent clones around would increase awareness of the Propeller, increase it's acceptability as a part you can rely on with multiple vendor sources. In that way the total Propeller market would grow. Increasing sales for Parallax even if the majority of the market is filled by some one else.
Beyond 64 I/O becomes a problem of how to address them within the P1 framework, as does to a lesser extent with >64KB hub.
Just preload the top 32KB of hub ram with the ROM code would work fine.
I have now looked closely at the Verilog code. It's not that difficult to follow, although making changes will certainly be a learning curve beyond anything simple.
Personally, I would rather the code remain here, at least for the time being. I don't know anything about Github, and I don't want to bother learning this atm. I see a lot of advantages of us being able to post Verilog code questions, changes, etc here. IMHO there is a significant benefit to Parallax for both the code and forums to remain here too. If and when it becomes necessary, it can always be put on Github later.
I have seen what has happened on "thingiverse". I am not saying this can/will happen on Github. I am more concerned to make sure Parallax benefits from this magnificent gesture.
It is easier to clone a repository from github or pull updates than it is to search around for a zip file, download it up pack it etc etc. What would be so hard about "git clone https://github.com/parallax/propeller.git."? You would not even have to type that you can cut and paste it from the front page of the github repository. That single action is possibly the only thing about git you would ever have to use.
Having the code in github would not mean you have to learn git or use it in any serious way.
Having the code in github does not preclude having versions of it zipped up and mirrored here available for download in exactly the same way.
Thinyiverse or whatever has nothing to do with any of this.
I'm in favor of continuing that policy too.
Frankly, just tossing it around here in the forum is most likely to make a mess than it is anything else.
As for benefit, here's a counter argument:
Many people, who are experienced enough to understand this release and do stuff with it, are not going to have any trouble with GitHub at all. It's the de-facto place to release and work with open code. As an example of even niche, obscure things bene fitting from GitHub, consider the Prince of Persia source code release for the Apple 2. That's a 6502 machine from the 70's, though that game was written and worked on 6502 machines produced into the 90's, but still. Old 6502 assembly language code lived on GitHub just fine.
What happened is a ton of people looked at the repository, it got cloned a few times, and one guy decided to write an assembler that behaves like Merlin, the original assembler in the day, built the code and demonstrated how it can assemble into working disk images for use in emulators and the real machine today. And it does work too. I've got the game to play on my Apple 2 and I can see all the work done on that code too, nicely organized. Should I want to do something like make a new level, or add a feature, I would do the same thing, and the history goes all the way back to the original, untouched release. Nice.
If it can happen for that, we've got no reason not to. And like Heater says, it's just not hard.
To be honest here, we are working in somewhat of a state of isolation here. It's comfy, and we all do what we do, but really it's not all that accessible to interested people. That's bad for us, Parallax and them!
Now, say they do get at the code and find they want to work with it. Who to work with? US! We would be quite pleased to have new blood join us and who knows what could happen? So how do we work? Most people, and a growing number of people overall, use management tools in order to actually work together on larger code or more complex code bodies. With this thing, there could very easily be a few projects going on, several different builds, etc... Keeping that sane is going to matter. And the burden of sorting things out increases exponentially with the number of contributors and versions and features too.
If it's on GitHub, the way of working is cut n' dried. They can jump in, make an account here and join the party, no worries. If not, then they have to unpack that code, look it over, wonder why it isn't setup proper for this kind of thing, maybe consider their own repository, then make an account here only to find we've got stuff all over the place, and it's hard!
That's bad for us, them and Parallax too.
And... You can get a nice GUI!
https://windows.github.com/
Trust me. This is really cool.
And example #2. When David got some of GCC working for the earlier P2, I wanted to jump in, along with Baggers and do some stuff. Now, PropGcc is using Google Code, which uses a little different type of management, but the core way to work was no different. So I got on my Mac this time, as that's the machine I wanted to use, got myself a client, pulled down the PropGCC project and took a look around. Not 10 minutes later, I had a nice build going of the P2 branch David was working on, and I compiled a program and put it on my DE2. Didn't take but a couple hours start to finish.
Here's the beautiful part:
David updates a coupla days later. I mash on a button or two, my local copy syncs up, I do a build, and now I've got that feature super easy. And there is more! Somebody here asked for PropGCC V1.0 build. That's all in the Repository. Mash another button, get the history, sync up to that version, build it, done, package, and put the package out there for others.
Today, months later, I can mash on those buttons, get all caught up, and be synced up, add my contributions, tag, and be rocking in a very short amount of time. And when Chip gets the P2 FPGA done, and it's PropGCC time, that's exactly what I'll do. Won't take but a few minutes, and I can even ask that repository for the old and the new, compare, do whatever I want with no worries about filenames and zip files, etc... It will just be right.
That's what most people are going to expect on something like this. Not zip files floating around with funny names, etc...
It's to our great advantage to do this right, step up, and put the code out there as an Open Source peer, not keep it tucked away, difficult to interact with, and with us.
Git is a distributed system. At git clones of a repo are peers on an equal footing. Chip and Ken and Parallax the corporation itself will have their own git repos on their machines at the office at home in the cloud, wherever they like. They need not be publicly reachable. The "clone" repository on github is not special among it's peers. It is only the public facing repo.
If github were to close down or otherwise become undesirable to use, no problem, then is the time to think about hosting your own public repos.
I am thinking about the minimum Verilog changes to get hubexec running on the P1...
- PC needs to be increased (16 bits to support 64KB hub)
- Addresses > 2KB will be in hub
- Need a CALL/JMP/RET instruction(s) with
- 16bit (for 64KB hub) destination address
- Initially store return address in a fixed cog location $1EF
- Other support instruction(s) may be helpful later.
The initial PASM memory model would be...- Registers in lower memory - 512 cog longs
- Code may reside and run from register space (as it is now)
- Code may reside and run from hub (>512 long)
- Hub code cannot be self modifying
Before anyone comments. Initially this is not going to provide much of a performance boost over LMM due to the need to wait for the hub cycle to fetch the next hubexec instruction. However, it makes the code significantly easier to write, and it saves double longs for each CALL/JMP/RET instruction which also means a small speed improvement.I found the same was required using Prop Tool. Otherwise works fine.
BTW is a $$$subscription version of Quartus required to "get serious" with compiling Verilog code.
I currently have the "Web Edition 13.0"
Cheers
Brian
??? Now its there! Was it a postedit???
Now, IIRC isn't it only the code on OBEX that must be MIT?? I thought code posted on the forum isn't part of that requirement although it has never bothered me.
Re: HUBEX
I think the super easy thing to do would be to make a jump with increment instruction, so that the fastest LMM loop isn't a backwards one.
Anyway, I am going to look at getting the CALL/JMP/RET working first, just as absolute for now.
Nope. If it's here, it's MIT.
http://forums.parallax.com/misc.php?do=showrules
https://github.com/ZiCog/P8X32A_Emulation
It can be fetched with a simple:
As a bonus I included the PDF setup guides there.
I'm not suggesting anyone actually use my repo, it's for my convenience, but it's there if you want to and it's easy to view the code from some iPad or something.
Why is it called "Emulation"? I don't consider it an emulation in the normal meaning of the word in computer circles.
Why are there duplicate sets of files? Not a good idea.
Why isn't there a src directory for the booter, interpreter and runner?