Thanks!! Let me know if you run into any problems. I have noticed that if I type ^C to get out of the terminal emulator on the Mac, I sometimes get an error. I'll try to track that down later tonight.
Now as it function ---> Can You add second line parameter to specify Baud-rate
While I was waiting for my company IT to resolve my network connectivity problem to my office I added your -b option to select the baud rate. I don't, however, have time to try it. Let me know if it works for you. It uses standard Windows baud rates up to 256K but then lets you enter anything you want. The updated zip file is in message #224.
While I was waiting for my company IT to resolve my network connectivity problem to my office I added your -b option to select the baud rate. I don't, however, have time to try it. Let me know if it works for you. It uses standard Windows baud rates up to 256K but then lets you enter anything you want. The updated zip file is in message #224.
Ugh... Never mind. There is a bug in the -b option. I'll be back with a fix.
While I was waiting for my company IT to resolve my network connectivity problem to my office I added your -b option to select the baud rate. I don't, however, have time to try it. Let me know if it works for you. It uses standard Windows baud rates up to 256K but then lets you enter anything you want. The updated zip file is in message #224.
I'm going to have to fix this later today. I forgot that I need to tell the second-stage loader to use the new baud rate as well. That will require patching the COG image before downloading it. That isn't a big deal but it's more than I can handle in the middle of a work day. Sorry!!
I'm going to have to fix this later today. I forgot that I need to tell the second-stage loader to use the new baud rate as well. That will require patching the COG image before downloading it. That isn't a big deal but it's more than I can handle in the middle of a work day. Sorry!!
In the meantime do you think I can go with mine Cyclone III FPGA Starter Board equipped with the HTG(M) HSMC card? It have more or less the same characteristics of the DE0-NANO (EP3C25: LE 24,624; M9K 66; RamKb 594; 18x18mul 66; PLLs 4; GC nets 20).
BTW: here you have the HSMC specifications, I haven't verified if the same apply on the DE2-115, but I think so because the HTG(M) daughter-board is the same.
In the meantime do you think I can go with mine Cyclone III FPGA Starter Board equipped with the HTG(M) HSMC card? It have more or less the same characteristics of the DE0-NANO (EP3C25: LE 24,624; M9K 66; RamKb 594; 18x18mul 66; PLLs 4; GC nets 20).
BTW: here you have the HSMC specifications, I haven't verified if the same apply on the DE2-115, but I think so because the HTG(M) daughter-board is the same.
Regards
I guess you could try loading the DE0-Nano configuration file and see what happens. :-)
Edit: Maybe that's a bad idea. If your board has outputs where the DE0-Nano expects inputs you might release the magic smoke? I'm not really sure. I guess Chip is the one who will have to answer this.
In the meantime do you think I can go with mine Cyclone III FPGA Starter Board equipped with the HTG(M) HSMC card? It have more or less the same characteristics of the DE0-NANO (EP3C25: LE 24,624; M9K 66; RamKb 594; 18x18mul 66; PLLs 4; GC nets 20).
BTW: here you have the HSMC specifications, I haven't verified if the same apply on the DE2-115, but I think so because the HTG(M) daughter-board is the same.
It is possible that You can add one more directive to PNut.
ORGHUB XXXXX.
I thought about that a little more and what would that mean with respect to the output .BIN and .obj files? Would they still start at location zero but have zeros in them up to the lowest ORGHUB address? Or would they start at the lowest ORGHUB address?
My thinking was OBJ file --- I use name CODE.HUB --- as OBJ -- are win file type
BIN file with only 1 COG code I will Chip leave that it is
> GOOD to made COG blobs for import in other files/Compilers GCC and like as Driver files.
Fill 0000 between last code and start of ORGHUB xxxxx.
0E80: some code
fill with 0000
ORGHUB xxxxx
some code
fill with 0000
ORGHUB xxxxx
I thought about that a little more and what would that mean with respect to the output .BIN and .obj files? Would they still start at location zero but have zeros in them up to the lowest ORGHUB address? Or would they start at the lowest ORGHUB address?
My thinking was OBJ file --- I use name CODE.HUB --- as OBJ -- are win file type
BIN file with only 1 COG code I will Chip leave that it is
> GOOD to made COG blobs for import in other files/Compilers GCC and like as Driver files.
Fill 0000 between last code and start of ORGHUB xxxxx.
0E80: some code
fill with 0000
ORGHUB xxxxx
some code
fill with 0000
ORGHUB xxxxx
and so on
In other words, you want the OBJ file to contain a memory image starting at $0 and ending with the last address of code/data to be loaded. Is that right? Since locations $0-$0e7f would overlay the ROM I guess we could make the file start at $0e80 and save some space and load time since writing over the ROM will not accomplish anything.
In other words, you want the OBJ file to contain a memory image starting at $0 and ending with the last address of code/data to be loaded. Is that right? Since locations $0-$0e7f would overlay the ROM I guess we could make the file start at $0e80 and save some space and load time since writing over the ROM will not accomplish anything.
BUT First addres to load are 0E80
0E80: some code
this place in my explanation
Okay, sorry I misunderstood you. By the way, I got the -b option working but now I think I need to be able to specify separate baud rates for the first-stage loader, the second-stage loader, and the terminal emulator. I found that when I changed the baud rate to 230400, my p2-hello program no longer worked because it has 115200 baud hard-coded into it.
Okay, sorry I misunderstood you. By the way, I got the -b option working but now I think I need to be able to specify separate baud rates for the first-stage loader, the second-stage loader, and the terminal emulator. I found that when I changed the baud rate to 230400, my p2-hello program no longer worked because it has 115200 baud hard-coded into it.
Fun, I have 5 COG's running now, code works both with Dave's loader and with Pnut (probably because the total object size is less than 512 longs)
DAT
org
setcog #1
coginit hub1, param
setcog #2
coginit hub2, param
setcog #3
coginit hub3, param
setcog #4
coginit hub4, param
live nop
nop
jmp #live 'keep COG alive
hub1 long $0EC0
hub2 long $0EE0
hub3 long $0F00
hub4 long $0F20
param long 0
DAT
org
mov dira,#1 'make P0 an output
:loop1 mov count1,#100 'increment the pins 100 times
:inc1 add pina,#1
djnz count1,#:inc1
reps #100,#1 'now let's do it faster
nop '(could do something useful here)
add pina,#1
jmp #:loop1 'repeat (watch P0 on an o'scope)
count1 res 1
DAT
org
mov dira,#2 'make P1 an output
:loop2 mov count2,#100 'increment the pins 100 times
:inc2 add pina,#1
djnz count2,#:inc2
reps #100,#1 'now let's do it faster
nop '(could do something useful here)
add pina,#1
jmp #:loop2 'repeat (watch P0 on an o'scope)
count2 res 1
DAT
org
mov dira,#4 'make P2 an output
:loop3 mov count3,#100 'increment the pins 100 times
:inc3 add pina,#1
djnz count3,#:inc3
reps #100,#1 'now let's do it faster
nop '(could do something useful here)
add pina,#1
jmp #:loop3 'repeat (watch P0 on an o'scope)
count3 res 1
DAT
org
mov dira,#8 'make P3 an output
:loop4 mov count4,#100 'increment the pins 100 times
:inc4 add pina,#1
djnz count4,#:inc4
reps #100,#1 'now let's do it faster
nop '(could do something useful here)
add pina,#1
jmp #:loop4 'repeat (watch P0 on an o'scope)
count4 res 1
Fun, I have 5 COG's running now, code works both with Dave's loader and with Pnut (probably because the total object size is less than 512 longs)
DAT
org
setcog #1
coginit hub1, param
setcog #2
coginit hub2, param
setcog #3
coginit hub3, param
setcog #4
coginit hub4, param
live nop
nop
jmp #live 'keep COG alive
hub1 long $0EC0
hub2 long $0EE0
hub3 long $0F00
hub4 long $0F20
param long 0
DAT
org
mov dira,#1 'make P0 an output
:loop1 mov count1,#100 'increment the pins 100 times
:inc1 add pina,#1
djnz count1,#:inc1
reps #100,#1 'now let's do it faster
nop '(could do something useful here)
add pina,#1
jmp #:loop1 'repeat (watch P0 on an o'scope)
count1 res 1
DAT
org
mov dira,#2 'make P1 an output
:loop2 mov count2,#100 'increment the pins 100 times
:inc2 add pina,#1
djnz count2,#:inc2
reps #100,#1 'now let's do it faster
nop '(could do something useful here)
add pina,#1
jmp #:loop2 'repeat (watch P0 on an o'scope)
count2 res 1
DAT
org
mov dira,#4 'make P2 an output
:loop3 mov count3,#100 'increment the pins 100 times
:inc3 add pina,#1
djnz count3,#:inc3
reps #100,#1 'now let's do it faster
nop '(could do something useful here)
add pina,#1
jmp #:loop3 'repeat (watch P0 on an o'scope)
count3 res 1
DAT
org
mov dira,#8 'make P3 an output
:loop4 mov count4,#100 'increment the pins 100 times
:inc4 add pina,#1
djnz count4,#:inc4
reps #100,#1 'now let's do it faster
nop '(could do something useful here)
add pina,#1
jmp #:loop4 'repeat (watch P0 on an o'scope)
count4 res 1
Congratulations! You people with the DE2-115 boards have all the fun!
nutson: Congratulations!
I have not even ordered my DE0-Nano yet! I cannot take the chance of it arriving before I finish some other work - I just know I will get distracted!
I was lucky enough to find a few hours to get a DE0 up and running this morning. It was all very painless (thanks Cluso for the thread and Chip for the photos of pinouts and clear instructions), and big thanks to Parallax for bothering.
So... I pushed on and now have a very basic SVGA test pattern running (800x600x60Hz, 40MHz pixel clock, 1.5 Altera clocks per pixel). I love this reps instruction.
I've got to say its all a bit of a throwback to the late 80s for me. We invested in an Altera Aplus system back then, and toured the (relatively small, then) Altera office in Santa Clara. I was also dabbling in 80386 assembler about then. The Altera Aplus software came on floppy disks. I note PNut is about 600kB, and the current Altera programmer wanted almost 1GB of space to install when unpacked.
The monitor is a really nice, thoughtful idea. Now to order that DE2 from digikey...
I was lucky enough to find a few hours to get a DE0 up and running this morning. It was all very painless (thanks Cluso for the thread and Chip for the photos of pinouts and clear instructions), and big thanks to Parallax for bothering.
So... I pushed on and now have a very basic SVGA test pattern running (800x600x60Hz, 40MHz pixel clock, 1.5 Altera clocks per pixel). I love this reps instruction.
I've got to say its all a bit of a throwback to the late 80s for me. We invested in an Altera Aplus system back then, and toured the (relatively small, then) Altera office in Santa Clara. I was also dabbling in 80386 assembler about then. The Altera Aplus software came on floppy disks. I note PNut is about 600kB, and the current Altera programmer wanted almost 1GB of space to install when unpacked.
The monitor is a really nice, thoughtful idea. Now to order that DE2 from digikey...
At first I couldn't figure out how you got the video running, as it's not documented yet, but then I realized you were bit-banging it! If you've programmed the current Prop's video before, you're going to find Prop2's video circuit much simpler to work with. I need five more of me just to write documentation.
At first I couldn't figure out how you got the video running, as it's not documented yet, but then I realized you were bit-banging it! If you've programmed the current Prop's video before, you're going to find Prop2's video circuit much simpler to work with. I need five more of me just to write documentation.
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
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
Comments
.......
Look on PIC
No problem --- Thanks
I am considering the DE2-115.
In the meantime do you think I can go with mine Cyclone III FPGA Starter Board equipped with the HTG(M) HSMC card? It have more or less the same characteristics of the DE0-NANO (EP3C25: LE 24,624; M9K 66; RamKb 594; 18x18mul 66; PLLs 4; GC nets 20).
BTW: here you have the HSMC specifications, I haven't verified if the same apply on the DE2-115, but I think so because the HTG(M) daughter-board is the same.
Regards
Edit: Maybe that's a bad idea. If your board has outputs where the DE0-Nano expects inputs you might release the magic smoke? I'm not really sure. I guess Chip is the one who will have to answer this.
DE0-NANO have Cyclone IV -- Not Cyclone III
It is possible that You can add one more directive to PNut.
ORGHUB XXXXX.
I thought about that a little more and what would that mean with respect to the output .BIN and .obj files? Would they still start at location zero but have zeros in them up to the lowest ORGHUB address? Or would they start at the lowest ORGHUB address?
My thinking was OBJ file --- I use name CODE.HUB --- as OBJ -- are win file type
BIN file with only 1 COG code I will Chip leave that it is
> GOOD to made COG blobs for import in other files/Compilers GCC and like as Driver files.
Fill 0000 between last code and start of ORGHUB xxxxx.
0E80: some code
fill with 0000
ORGHUB xxxxx
some code
fill with 0000
ORGHUB xxxxx
and so on
Sorry for misunderstanding.
BUT First addres to load are 0E80
0E80: some code
this place in my explanation
Change baud rate in spin file are not big problem --- > If I can specify correct one in loader
Congratulations! You people with the DE2-115 boards have all the fun!
Also, you should be able to use labels instead of hard-coded addresses by making changes similar to what I did above.
I don't have money to buy that one ---> so no fun for me.
I have not even ordered my DE0-Nano yet! I cannot take the chance of it arriving before I finish some other work - I just know I will get distracted!
So... I pushed on and now have a very basic SVGA test pattern running (800x600x60Hz, 40MHz pixel clock, 1.5 Altera clocks per pixel). I love this reps instruction.
I've got to say its all a bit of a throwback to the late 80s for me. We invested in an Altera Aplus system back then, and toured the (relatively small, then) Altera office in Santa Clara. I was also dabbling in 80386 assembler about then. The Altera Aplus software came on floppy disks. I note PNut is about 600kB, and the current Altera programmer wanted almost 1GB of space to install when unpacked.
The monitor is a really nice, thoughtful idea. Now to order that DE2 from digikey...
At first I couldn't figure out how you got the video running, as it's not documented yet, but then I realized you were bit-banging it! If you've programmed the current Prop's video before, you're going to find Prop2's video circuit much simpler to work with. I need five more of me just to write documentation.
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
Why You don't post code and sch -- so others can experiment and learn from Yours code