Yes bit banging is exactly the right way to describe it. But it's getting the job done effortlessly, and I can easily extend the color depth too
The slow release of instructions actually suits me. A bit like an advent calendar, with a different instruction every day or few days... for a fuller appreciation of what you've implemented
I hope to get a new version of the doc's out tonight. Next up is the cog multitasking. It's only a page, or so, but has taken me all day (with lots of interruptions) to write. I look forward to documenting the video, because it's really fun to program - much cleaner code than the current Prop, and all the colors stay in 8:8:8 RGB, no matter what the output color space is. Also, the CORDIC is going to be fun - logs, exponents, complex circular functions, and hyperbolics. I probably have got a cumulative year into just the CORDIC.
Hi Tubular.
Why You don't post code and sch -- so others can experiment and learn from Yours code
Sapieha, I really doubt much could be learned from what I have done today. I am very 'rusty' on assembler, but it's coming back to me gradually, and I'm very encouraged to get some working SVGA output, however basic.
Given Chip will have something official documented soon, let me send you (and anyone else that wants it) my code to test. I'd rather do that then fork (divide) the forum threads any further. (See post #268 above for code).
The schematic is the same as the VGA demo board but shifted down (Pins P0..P7 instead of P16..23). The ground is picked up on the VSS pin between pin P8 and P10 on the 40 pin connector.
Let me take this opportunity to say excellent and very speedy work on the breakout board you designed. It's exciting to see this rapid progress on all fronts.
Chip: I agree with Lachlan. It is much easier to let it sink in by getting a few related instructions each day. It also means we can think about them much better and note if there is something missing or we don't quite understand.
Thanks
-- But as I work on another PCB for DE0-NANO - I had much work already done - It was simple copy parts from it to new Layout design and draw traces
Sapieha, I really doubt much could be learned from what I have done today. I am very 'rusty' on assembler, but it's coming back to me gradually, and I'm very encouraged to get some working SVGA output, however basic.
Given Chip will have something official documented soon, let me send you (and anyone else that wants it) my code to test. I'd rather do that then fork (divide) the forum threads any further. The schematic is the same as the VGA demo board but shifted down (Pins P0..P7 instead of P16..23). The ground is picked up on the VSS pin between pin P8 and P10 on the 40 pin connector.
Let me take this opportunity to say excellent and very speedy work on the breakout board you designed. It's exciting to see this rapid progress on all fronts.
I hope to get a new version of the doc's out tonight. Next up is the cog multitasking. It's only a page, or so, but has taken me all day (with lots of interruptions) to write. I look forward to documenting the video, because it's really fun to program - much cleaner code than the current Prop, and all the colors stay in 8:8:8 RGB, no matter what the output color space is. Also, the CORDIC is going to be fun - logs, exponents, complex circular functions, and hyperbolics. I probably have got a cumulative year into just the CORDIC.
Very timely. I was about to attempt some crazy interleaving of the horizontal scan like with getting data from an MCP3208. Both take 20 uSec, but the bit banged video (40MHz dot clock) needs at most 2 instructions out of every 3. I was actually contemplating using that spare instruction to fetch an ADC sample, to do something like the microphone-to-vga demo ('scope). Let me hold off on that and do it an easier way...
CORDIC... I can just imagine it taking that long. Its going to be a heap of fun to play with this new stuff (cordic, goetzel, clut, blending/mapping). Not to mention analog capabilities on every pin. I'm determined to use it all...
Tubular: Tks for the code. Nice to see the P2 bitbang VGA simply, especially since the emulation is only running about 30% speed. Single clocks and the REP instructions sure help.
I noticed in your code the REPS instruction has only 1 instruction skipped - I thought it was 2 clocks (2 instructions)???
Here is a draft version of my first P2 pcb. It is my first take at generating a 3D view of the pcb. I used KiCad and the footprints and 3D images come from Walter (found on the internet). The 3D rendition shows through the pcb and I have not found a way to turn it off. The board is 1.6"sq. I am not ready to post this in its own thread yet. I hope to have these pcbs by Xmas (with other pcbs).
I really like the minimalist nature of that board.
Is it so that we no longer have to worry about placing R's and C's tight up against the Prop pins in order to get analog inputs working nicely. Do we even need R's and C's anymore?
Here is a draft version of my first P2 pcb. It is my first take at generating a 3D view of the pcb. I used KiCad and the footprints and 3D images come from Walter (found on the internet). The 3D rendition shows through the pcb and I have not found a way to turn it off. The board is 1.6"sq. I am not ready to post this in its own thread yet. I hope to have these pcbs by Xmas (with other pcbs).
Sapieha: no just the usual 2 layers. I have a pair of quad spi chips and a 512KB sram as options, plus 2 vregs. I have yet to place the xtal and a couple more decoupling caps. The 4 pins in each corner contain 5V, 3V3 and Gnd. That leaves 2x12 pins on each side for the I/O. Even Pxx pins will be on the outer pins and odd Pxx pins on the inside.
Sapieha: no just the usual 2 layers. I have a pair of quad spi chips and a 512KB sram as options, plus 2 vregs. I have yet to place the xtal and a couple more decoupling caps. The 4 pins in each corner contain 5V, 3V3 and Gnd. That leaves 2x12 pins on each side for the I/O. Even Pxx pins will be on the outer pins and odd Pxx pins on the inside.
I find it awkward to have to add $0e80 to the addresses of all of my labels so I've come up with a hack that prevents the need to do that. First, I start my DAT section with a dummy array that is $0e80 bytes long. After that, I can refer to labels using @label instead of BASE+@label.
Then the problem becomes how to load the resulting file because it will begin with $0e80 bytes of zeros. I handled this by adding a -s option to p2load that skips over the first $0e80 bytes before loading.
Of course, a way to set the hub origin as suggested by someone else here would be a better solution.
CON
BASE = $e80
DAT
byte 0[BASE]
org
start reps #$1F6-@reserves+@start,#1 'clear reserves
...
hello byte CR, LF, "Hello, Propeller II!", CR, LF, 0
long
hello_addr long @hello
Notice that the argument to my reps instruction must now add on @start since I can no longer assume that hub ram addresses start at zero.
I find it awkward to have to add $0e80 to the addresses of all of my labels so I've come up with a hack that prevents the need to do that. First, I start my DAT section with a dummy array that is $0e80 bytes long. After that, I can refer to labels using @label instead of BASE+@label.
Then the problem becomes how to load the resulting file because it will begin with $0e80 bytes of zeros. I handled this by adding a -s option to p2load that skips over the first $0e80 bytes before loading.
Of course, a way to set the hub origin as suggested by someone else here would be a better solution.
CON
BASE = $e80
DAT
byte 0[BASE]
org
start reps #$1F6-@reserves+@start,#1 'clear reserves
...
hello byte CR, LF, "Hello, Propeller II!", CR, LF, 0
long
hello_addr long @hello
Notice that the argument to my reps instruction must now add on @start since I can no longer assume that hub ram addresses start at zero.
Thanks for reminding me. Sorry I didn't mention you by name. I'm afraid I was too lazy to lookup your message before I posted mine. It was a great idea!
Here is a draft version of my first P2 pcb. It is my first take at generating a 3D view of the pcb. I used KiCad and the footprints and 3D images come from Walter (found on the internet). The 3D rendition shows through the pcb and I have not found a way to turn it off. The board is 1.6"sq. I am not ready to post this in its own thread yet. I hope to have these pcbs by Xmas (with other pcbs).
I think I'm confused about byte vs. long addresses. I'm particularly unclear about how the following code works:
start reps #$1F6-@reserves,#1 'clear reserves
Isn't @reserves the hub addess of the label "reserves" expressed as a byte address? But $1F6 is a long COG address. Wouldn't it be more correct to use the expression "$1F6-(@reserves>>2)"?
I've just finished a quick port of Dave Hein's pfth Forth interpreter to the P2 on the DE0-Nano. I suspect it will work equally well on the DE2-115. To load this you'll need to get the latest version of p2load.exe because this program uses the new -s option to p2load that strips the first $0e80 bytes from the .obj file before loading it.
Use this command to load pfth:
p2load -v -s pfth.obj -t
Here is an example session:
david-betzs-macbook-pro:pfth-p2 dbetz$ p2load -v -s pfth.obj -t
Trying /dev/cu.usbserial-A700fKXl
Found propeller version 32
Loading 'pfth.obj' on port /dev/cu.usbserial-A700fKXl
.....................
[ Entering terminal mode. Type ESC or Control-C to exit. ]
PASM pfth 0.59
ok
: double dup + ;
ok
3 double .
6 ok
More work is certainly needed to provide access to all of the Propeller II features but this is a first step.
Here is a zip file containing the P2 version of pfth: pfth-p2.zip
I think I'm confused about byte vs. long addresses. I'm particularly unclear about how the following code works:
start reps #$1F6-@reserves,#1 'clear reserves
Isn't @reserves the hub addess of the label "reserves" expressed as a byte address? But $1F6 is a long COG address. Wouldn't it be more correct to use the expression "$1F6-(@reserves>>2)"?
Thanks,
David
If you reference an address label in an asm instruction or byte/word/long, you'll get the cog register address. If you use @label, you'll get the absolute address in hub memory.
Use Ctrl-L in PNUT.EXE to make a list file of this code:
DAT
org $100
a long 1[10]
b long 2[10]
c long 3[10]
long a,b,c,@a,@b,@c
Comments
I hope to get a new version of the doc's out tonight. Next up is the cog multitasking. It's only a page, or so, but has taken me all day (with lots of interruptions) to write. I look forward to documenting the video, because it's really fun to program - much cleaner code than the current Prop, and all the colors stay in 8:8:8 RGB, no matter what the output color space is. Also, the CORDIC is going to be fun - logs, exponents, complex circular functions, and hyperbolics. I probably have got a cumulative year into just the CORDIC.
Sapieha, I really doubt much could be learned from what I have done today. I am very 'rusty' on assembler, but it's coming back to me gradually, and I'm very encouraged to get some working SVGA output, however basic.
Given Chip will have something official documented soon, let me send you (and anyone else that wants it) my code to test. I'd rather do that then fork (divide) the forum threads any further. (See post #268 above for code).
The schematic is the same as the VGA demo board but shifted down (Pins P0..P7 instead of P16..23). The ground is picked up on the VSS pin between pin P8 and P10 on the 40 pin connector.
Let me take this opportunity to say excellent and very speedy work on the breakout board you designed. It's exciting to see this rapid progress on all fronts.
Chip: I agree with Lachlan. It is much easier to let it sink in by getting a few related instructions each day. It also means we can think about them much better and note if there is something missing or we don't quite understand.
This is going to be one hell of a chip!!
christofferj2@gmail.com
Thanks
-- But as I work on another PCB for DE0-NANO - I had much work already done - It was simple copy parts from it to new Layout design and draw traces
Very timely. I was about to attempt some crazy interleaving of the horizontal scan like with getting data from an MCP3208. Both take 20 uSec, but the bit banged video (40MHz dot clock) needs at most 2 instructions out of every 3. I was actually contemplating using that spare instruction to fetch an ADC sample, to do something like the microphone-to-vga demo ('scope). Let me hold off on that and do it an easier way...
CORDIC... I can just imagine it taking that long. Its going to be a heap of fun to play with this new stuff (cordic, goetzel, clut, blending/mapping). Not to mention analog capabilities on every pin. I'm determined to use it all...
Now that is a take I never thought of... ROFL.
I noticed in your code the REPS instruction has only 1 instruction skipped - I thought it was 2 clocks (2 instructions)???
P2 Blade looks really nice. Any chance of making those pics bigger?
Is it so that we no longer have to worry about placing R's and C's tight up against the Prop pins in order to get analog inputs working nicely. Do we even need R's and C's anymore?
Shall it be 4 else 6 layers.
The 3D picture's look great, do you have a link for "Walter" ?
My one are more moderate -- Possible to hand solder.
http://forums.parallax.com/showthread.php?144199-Propeller-II-Emulation-of-the-P2-on-DE0-NANO-amp-DE2-115-FPGA-boards&p=1146196&viewfull=1#post1146196
Then the problem becomes how to load the resulting file because it will begin with $0e80 bytes of zeros. I handled this by adding a -s option to p2load that skips over the first $0e80 bytes before loading.
Of course, a way to set the hub origin as suggested by someone else here would be a better solution.
CON BASE = $e80 DAT byte 0[BASE] org start reps #$1F6-@reserves+@start,#1 'clear reserves ... hello byte CR, LF, "Hello, Propeller II!", CR, LF, 0 long hello_addr long @helloNotice that the argument to my reps instruction must now add on @start since I can no longer assume that hub ram addresses start at zero.
Can You change DOC's in zip file to.
Done.
Does SETTASK invalidate instructions in the pipeline as well?
That be me
http://forums.parallax.com/showthread.php?144199-Propeller-II-Emulation-of-the-P2-on-DE0-NANO-amp-DE2-115-FPGA-boards&p=1147702&viewfull=1#post1147702
No. It just writes a new value into the TASK register which immediately affects which task is going to execute next.
Thanks for reminding me. Sorry I didn't mention you by name. I'm afraid I was too lazy to lookup your message before I posted mine. It was a great idea!
I think I'm confused about byte vs. long addresses. I'm particularly unclear about how the following code works:
Isn't @reserves the hub addess of the label "reserves" expressed as a byte address? But $1F6 is a long COG address. Wouldn't it be more correct to use the expression "$1F6-(@reserves>>2)"?
Thanks,
David
Use this command to load pfth:
Here is an example session:
More work is certainly needed to provide access to all of the Propeller II features but this is a first step.
Here is a zip file containing the P2 version of pfth: pfth-p2.zip
Nice work !!!
If you reference an address label in an asm instruction or byte/word/long, you'll get the cog register address. If you use @label, you'll get the absolute address in hub memory.
Use Ctrl-L in PNUT.EXE to make a list file of this code:
You'll get:
You can see what happens. The label values are stored as cog-byte-address-in-high-word, hub-byte-address-in-low-word.
By the way, in the ROM_Monitor.spin program, that line was:
reps #$1F6-reserves,#1 'clear reserves
There was no @ before 'reserves'.