rjo__ wrote: »
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?
David Betz wrote: »
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...
This post will be revised as a place to put new file downloads created by the community, if desired.
Does Github only work with git, or does it support Mercural?
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.
* Nothing happens at all, and after all week or two of hoopla, things go back to "normal".
* 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)
* Variations from the original design could create code confusion, instability, and incompatibility with existing code.
jmg wrote: »
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
Heater. wrote: »
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.
Rayman wrote: »
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...
Cluso99 wrote: »
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 tha
Heater. wrote: »
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.
Cluso99 wrote: »
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.
rjo__ wrote: »
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).
potatohead wrote: »
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!
That's bad for us, them and Parallax too.
David Betz wrote: »
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.
Cluso99 wrote: »
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.
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.
$ git clone https://github.com/ZiCog/P8X32A_Emulation.git