Right now, one line of Verilog gets commented out to eliminate the character ROM from the DE0-Nano compile, in order to make it fit. I tried doing the first half of the character ROM (characters $00..$7F), but there wasn't even room for that.

The BEMicro CV board is really chip and has plenty of RAM to spare, as well as logic. All one would have to do is make a unique top.qsf file for that board, and compile it with the other files, and they'd be running.

I think many of you will be kind of surprised at how little Verilog code it takes to make a Propeller 1 chip. The cog.v source file is only 4KB, for example.

Since the BEMicro CV might be a better match to the P1 Verilog than the DE0-Nano, is there any chance Parallax will be stocking them? If so, I'll hold off on buying one until Parallax gets them in their store.

Since the BEMicro CV might be a better match to the P1 Verilog than the DE0-Nano, is there any chance Parallax will be stocking them? If so, I'll hold off on buying one until Parallax gets them in their store.

The BEMicro CV has ~3x the RAM of the Nano, so should nicely avoid the P1- effects.

( I'm not sure if something limits using all the RAM, as the Nano on paper has "594-Kb embedded memory" or ~74K Bytes, BEMicro says "1,760 Kbit (Kb) M10K and 196 Kb MLAB memory" )

Parallax could stock a BEMicro CV + a FlashDrive with all the support files on it, for a little value-added ?

Addit : From another comment, Parallax could also pre-load the P1 code with a test program, into the FPGA board they provide, so a first-up use does not have to build or install Quartus first.
This would also help wrt 'student attrition', as a means to know a new board is still ok and 'download read'y helps in any lab

I'm just starting to look at the source package and am wondering why there is a complete set of files for both the DE0-Nano and the DE2-115. Surely most of the files are identical between the two boards. Can't there be just one copy of files that are shared to avoid having them get out of sync with each other when people start making variants? Also, someone will undoubtely add the BeMicro CV soon and that will probably share most of the files as well.

I'm just starting to look at the source package and am wondering why there is a complete set of files for both the DE0-Nano and the DE2-115. Surely most of the files are identical between the two boards. Can't there be just one copy of files that are shared to avoid having them get out of sync with each other when people start making variants? Also, someone will undoubtely add the BeMicro CV soon and that will probably share most of the files as well.

Yes, Chip said this above
["The BEMicro CV board is really chip and has plenty of RAM to spare, as well as logic. All one would have to do is make a unique top.qsf file for that board, and compile it with the other files, and they'd be running."]

- so the unique top file maps the FPGA pins & anything else FPGA unique, and the 'other files' are the core itself, so that would be common.

I'm just starting to look at the source package and am wondering why there is a complete set of files for both the DE0-Nano and the DE2-115. Surely most of the files are identical between the two boards. Can't there be just one copy of files that are shared to avoid having them get out of sync with each other when people start making variants? Also, someone will undoubtely add the BeMicro CV soon and that will probably share most of the files as well.

This is why we really should use github. One time, we combine files, make build conditional, with a script of some sort, or flags, however Quartus works. As new builds happen, the files can be kept track of, or merged back to make more builds possible, etc....

Then people make branches, can merge, and generally keep it sane.

Does Github only work with git, or does it support Mercural? Just wondering. I like that one.

As for why, that boils down to how Chip chose to do development. I'll bet he copies files, syncs things up, then makes specific edits, keeping it in folders from there.

That works well for one person, or a couple working closely. We've now opened it up, and it won't work so well IMHO.

This is why we really should use github. One time, we combine files, make build conditional, with a script of some sort, or flags, however Quartus works. As new builds happen, the files can be kept track of, or merged back to make more builds possible, etc....

Then people make branches, can merge, and generally keep it sane.

Yes I believe there is a strong argument for github for something like this.

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. Something as user friendly as your monitor doc, PH

I downloaded the files and built the DE0-Nano version successfully with Quartus 14.0. I might try it out tomorrow.

I downloaded the files but then got stuck in Quartus hell. Actually, I guess it's Mac OS X hell. Since there isn't a version of Quartus that runs on the Mac I tried to install it on Win XP in a VM. Unfortunately, I downloaded a 64 bit version and XP is 32 bits. I'm not installing Ubuntu 64 in another VM and after that will install the Linux version of Quartus. I might get to compiling the P1 Verilog sometime in the next decade. :-(

I sent some PMs about identifiers being used before being declared etcetera. (e.g. px in cog.v) Maybe someone with more time can try out some of the various free verilog simulators {icarus, verilator, cver, veriwell,....} and see if it's worth making edits so that they can handle this. I think there are some other constructs that those free simulators may not support. Of course someone would have to make a top level in verilog (to replace top.tdf) and a testbench for that to work, but first someone could just try "simulatorx dig.v" and see what pops up.

Edited to add: some people might find v2html (http://www.burbleland.com/v2html/v2html.html) useful for browsing around in Verilog code. If anyone knows about anything better that would be nice. I haven't tried it on this code since I had access to Verdi.

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. I guess I'm off and running with the P1 Source code! Now I just have to study it to understand how it works. :-)

Hey Ken,
This is definitely going to require it's own forum. I am itching to start some threads to discuss some simple additions and I don't want to clog this thread.
Things like...
1. 48/64KB hub ram with small boot ROM. We can always load the upper ram with the rom if required.
2. 64 I/O
3. Overclocking
4. USB FS simple instruction support
5. Debugging support for FPGA only

I'm in favor of Open Source, but when I saw the initial post to the Distributors, I immediately hit reply and questioned on whether Parallax "just gave away the store."

I've been weighing this in my own mind ever since... (since I was asked not to say anything on the forums.)

Potential Upsides:

* Generates interest in Propeller chips.
* I can "emulate" my dream Propeller chip design.
* Generates some waves in the entire microcontroller community. Perhaps folks will take a second (or third) look at Parallax because of this.
* Because of this there will ALWAYS be a Propeller chip. (I can have one of these to play with forever.) Unlike my garbage C64 emulators that don't hold a candle to the real thing.

Potential Downsides:

* 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.

* 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.

I think you over-worry this.

FPGA's that can manage this, are mostly in BGA packages, and quite costly. The base price seems to change little, but the do fit more and more in.

They will never displace an exact P1.

What a FPGA can do, is allow companies to deploy a larger/faster/more tightly coupled P1, but notice that was not actually a job the P1 could meet.
Companies could deploy both P1 and FPGA.P1+ in designs, just like they use varying size PICs right now..

Variations are up to the person creating them to manage.
With a good macro assembler, opcode extensions should not have too much risk.

Maybe a Build/version number needs to go into ROM via the Verilog (if not already there )

If you are already setup with the DE0 for the prior FPGA images, all you have to do is remove the adapter board, look at the picture to see where the Prop plug goes, load the .jic file into the Atera programmer and go. Worked first time.

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). Soft reboot has no effect. I tried using a different serial terminal program. That didn't help.

The specs say to limit power to the external power pins to 5.7V.

I think we need to give serious thought about how to keep Chip away from this discussion for a while:) Possibly we could password the thread and just not give it to him?
It will be years before I grasp most of this. In the meantime, my request for a variant is simply more Hub ram on the DE-115. Next would be hooking up the adapter boards, adding pins and hooking up the SDRAM.

Long before that happens I expect to have a Prop2.jic, which should take care of all that stuff anyway:)