I've got PortC going on my DE0-Nano already.
I removed the video circuit and replaced $1FE,$1FF with DIRC,OUTC.
Its just output only at the moment but I can use SPR[14] SPR[15] in spin to operate portC.
Seems to be working Ok so far.
PortC may be useful to make a full system bus for the Propeller. Then portb can become data[31..0] and portc will be address[27..0] (?) and some control bits like R/~W. We can then map RAM and devices available on DExx to this address space.
That was next on my list. The list is growing rapidly.
This FPGA stuff has made the imagination go wild!
Baby steps......have to be careful not to get ahead of myself.
We have serial output ,the video circuit. We don't have serial input. Maybe some messing with video circuit can do this.
It may need a combination of both COUNTER and VIDEO.
Video has a single register, and lacks the pin-mapping ability of the counters, and video needs one counters set to a fixed mode. (which then has two Pin-map fields presently unused, but available for SERio)
Some have been looking at disabling the video, so it will be interesting to see the Logic-footprint of that.
PortC may be useful to make a full system bus for the Propeller. Then portb can become data[31..0] and portc will be address[27..0] (?) and some control bits like R/~W. We can then map RAM and devices available on DExx to this address space.
You could go this way, but it may be simpler to try to map any internal peripherals into an expanded hub space or hole inside 64kB and leave porta/b/c? for all external device I/O which could still be made to look like SRAM I guess if you wanted.
Not sure there is any point in having more than 64 I/O. It was decided that 64 I/Os sufficient for the p2.
With target FPGAs having high pin counts (eg 484BGAs), a means to support their expanded IO makes sense for those targets.
Some means to also expand WAITPxx would be nice in this case.
I'd agree it is less important for any eventual silicon-target, but this sort of extra IO is easily made conditional.
It may need a combination of both COUNTER and VIDEO.
Video has a single register, and lacks the pin-mapping ability of the counters, and video needs one counters set to a fixed mode. (which then has two Pin-map fields presently unused, but available for SERio)
Some have been looking at disabling the video, so it will be interesting to see the Logic-footprint of that.
Yeah in many cases you may only need one video output or no video at all. It makes sense to be able to compile with internal video disabled. If external SDRAM is available and mapped into the hub, you could always try to introduce your own framebuffer VGA video controller inside the FPGA (single shared instance) which is something I'd like to try.
The two counters are ripe for experimenting with serial I/O IMO. Dual independently clocked synchronous or async I/O and SPI using reverse WAITVID is something I like the sound of and hope to also experiment with eventually.
The peripherals can be mapped to hub, but not these MB of RAM I have on board
Fair enough. It is probably a quick and simple way to get visibility to your external SRAM from the FPGA based prop but will come at the expense of other GPIO pins, I guess it all depends on your application. The other way is to expand hub address space to use more than 16bits to drive your onboard SRAM but that could require a lot more decoding/changes. I really don't know the details of what would be involved there yet.
inb works now. I have now the port B as simple bidirectional port without "whistles" (counters and video)
....
This needs to be tested and cleaned now
I have extended port B to the counters and video. I have not check to see if they work on hardware yet -- need to buy stuff to attach to my DE0-Nano. If anyone want to verify that they work, I would be glad to hear your results.
In my first post there are changes to make a simple port B without a video and counters.
In the post #46 there is a solution with counters and video added. I didn't test this yet.
Then, there is my "extended Port B" which I used in my SRAM/VGA driver. This is still without counter and video support, but it has separated INB, OUTB and DIRB which can be used independently: OUTB and DIRB are 32bit outputs, INB is 32bit input. You can look at this solution in my video project.
Thanks for the advice... at this point I want to add the extended port b facililies. I love your video project. There is a lot there to look at.
I had to get away temporarily to deal with the other issues I've been posting about and didn't want to get going again in the wrong direction:)
By the way: It seems like most people didn't change the Jumper at J11
to 3.3V VCCIO instead of 2.5V VCCIO. Please refer to the Hardware Manual
for more information about this.
Pin Mapping:
- PORTA 0-31: As the original release (Edit: P28/29 are on-board EEPROM now).
- PORTB 0-27: On left (P2) header as 3.3V LVTTL
- PORTB 28-31: Mapped to internal SD-Card slot.
Pin Mapping:
- PORTA 0-31: As the original release (Edit: P28/29 are on-board EEPROM now).
- PORTB 0-27: On left (P2) header as 3.3V LVTTL
- PORTB 28-31: Mapped to internal SD-Card slot.
Now I tested my code and I see that fsrw & for example sidcog don't work at all.
I didn't try other examples, but maybe @pik33, you could take a look?
I have extended port B to the counters and video. I have not check to see if they work on hardware yet -- need to buy stuff to attach to my DE0-Nano. If anyone want to verify that they work, I would be glad to hear your results.
Comments
The P1B was only to have 64 I/O.
Might be better to spend the time on doing things that could make it to the P1.5.
I removed the video circuit and replaced $1FE,$1FF with DIRC,OUTC.
Its just output only at the moment but I can use SPR[14] SPR[15] in spin to operate portC.
Seems to be working Ok so far.
This FPGA stuff has made the imagination go wild!
Baby steps......have to be careful not to get ahead of myself.
It may need a combination of both COUNTER and VIDEO.
Video has a single register, and lacks the pin-mapping ability of the counters, and video needs one counters set to a fixed mode. (which then has two Pin-map fields presently unused, but available for SERio)
Some have been looking at disabling the video, so it will be interesting to see the Logic-footprint of that.
With target FPGAs having high pin counts (eg 484BGAs), a means to support their expanded IO makes sense for those targets.
Some means to also expand WAITPxx would be nice in this case.
I'd agree it is less important for any eventual silicon-target, but this sort of extra IO is easily made conditional.
Yeah in many cases you may only need one video output or no video at all. It makes sense to be able to compile with internal video disabled. If external SDRAM is available and mapped into the hub, you could always try to introduce your own framebuffer VGA video controller inside the FPGA (single shared instance) which is something I'd like to try.
The two counters are ripe for experimenting with serial I/O IMO. Dual independently clocked synchronous or async I/O and SPI using reverse WAITVID is something I like the sound of and hope to also experiment with eventually.
This is done, I have a 800x600x24bit framebuffer made for DE2-115. It was created for the NIOS processor, so I have to make it Propeller compatible.
Fair enough. It is probably a quick and simple way to get visibility to your external SRAM from the FPGA based prop but will come at the expense of other GPIO pins, I guess it all depends on your application. The other way is to expand hub address space to use more than 16bits to drive your onboard SRAM but that could require a lot more decoding/changes. I really don't know the details of what would be involved there yet.
Awesome.
I have to check if it works... Now all the fun begin to start
I have extended port B to the counters and video. I have not check to see if they work on hardware yet -- need to buy stuff to attach to my DE0-Nano. If anyone want to verify that they work, I would be glad to hear your results.
myP1V.zip
Is everything in your first post... there was a lot of conversation after that and I'm not exactly sure.
Thanks,
Rich
In the post #46 there is a solution with counters and video added. I didn't test this yet.
Then, there is my "extended Port B" which I used in my SRAM/VGA driver. This is still without counter and video support, but it has separated INB, OUTB and DIRB which can be used independently: OUTB and DIRB are 32bit outputs, INB is 32bit input. You can look at this solution in my video project.
I had to get away temporarily to deal with the other issues I've been posting about and didn't want to get going again in the wrong direction:)
https://git.no-route.org/syso/p8x32a_emulation/commits/v0.1-PORTB
BeMicroCV Pin Mapping:
Problem: Replaced ina/outa/dira in FSRW with the corresponding portb
constants, but it seems not to work.
Debugging result: inb seems to be inverted somehow (or there are pull-ups).
Tieing pins to ground makes them appear as LOW.
Code at: https://git.no-route.org/syso/p8x32a_emulation/tree/Altera
By the way: It seems like most people didn't change the Jumper at J11
to 3.3V VCCIO instead of 2.5V VCCIO. Please refer to the Hardware Manual
for more information about this.
64 Pin Version (utilizing both 40 Pin I/O Headers on the BeMicroCV) with counters + video generator:
https://git.no-route.org/syso/p8x32a_emulation/commits/v0.4-PORTB
Pin Mapping:
- PORTA 0-31: As the original release (Edit: P28/29 are on-board EEPROM now).
- PORTB 0-27: On left (P2) header as 3.3V LVTTL
- PORTB 28-31: Mapped to internal SD-Card slot.
Now I tested my code and I see that fsrw & for example sidcog don't work at all.
I didn't try other examples, but maybe @pik33, you could take a look?
Yes, and they still work with the current version.
Here you can see all my changes made https://git.no-route.org/syso/p8x32a_emulation/compare/327d0b911937162d9024533c3b6c6dace66bb169...Altera
you will need to scroll down to see differences (red removed, green added)
I tried it - unfortunately at least the counters don't work for me.