Well I figured out the build for the Nano without having to download the entire 1.5 Gig Alteras install. I downloaded the "programming and tools" only under 15.1 lite version and had to mess around with comm ports but everything is running now.
I got the pixel mixer all integrated. I hope to get new files out tomorrow and update the doc's, accordingly.
I'm way behind on reading forum posts right now.
Question: I'd like to get rid of GETD and GETS, which read the D and S fields, and then replace their slots with RGBW2L and RGBL2W which would convert between 8:8:8:0 RGB (long) and 5:6:5:0 RGB (word). I think with the ALTD/ALTS instructions, there's reduced need for GETD and GETS, though SETD and SETS are still useful. Any opinions? I really want to keep SEUSSF and SEUSSR, as they will be handy for quick pseudo-random and obfuscation functions.
I think GETS and GETD can be implemented easy enough with shifts, and, etc.
Is it possible to merge ALTS with SETS so a single instruction covers both scenarios and frees up another opcode?
Same applies to ALTD and SETD?
I think RGBW2L and ..L2W could be very useful in certain situations.
(say you want to connect all 24 color bits to an LCD but work internally in 16-bit mode) (or, you want to quickly display a 24-bpp bitmap from uSD card when working in 16-bit mode).
Can't think of any situation where GETD or GETS would be useful for me...
But now I'm curious... I though there were all kinds of opcodes still free. Are they all full now?
As for ops, there needs to be some reserved for the smart pin ops. Being frugal at this stage makes good, general sense, and that's all I think Chip is after right now.
As for ops, there needs to be some reserved for the smart pin ops. Being frugal at this stage makes good, general sense, and that's all I think Chip is after right now.
I think MSGIN and MSGOUT are for the smart pins, the ops will then be in the message you send.
Okay, I'm going to get rid of SETD and SETS and implement RGBW2L and RGBL2W. I'm going to shift a few instructions around in the region to make this look right. All these instructions are in a block of mux-type instructions, so they work on a common ALU path.
But now I'm curious... I though there were all kinds of opcodes still free. Are they all full now?
There was plenty of D field and null operand slots spare but only a few left of the full dual operand instruction slots. Presumably those have been gobbled up already.
I just posted a new file at the top of this thread. I'm going to be updating the documentation over the next 15 minutes, or so, to reflect the changes.
At this point, I don't have any ideas to enhance the design further. I will add to the documentation over the next few days before starting on the smartpin circuit.
I just posted a new file at the top of this thread. I'm going to be updating the documentation over the next 15 minutes, or so, to reflect the changes.
At this point, I don't have any ideas to enhance the design further. I will add to the documentation over the next few days before starting on the smartpin circuit.
At this point, I don't have any ideas to enhance the design further. I will add to the documentation over the next few days before starting on the smartpin circuit.
That is great to hear! Maybe we're starting to see some light at end of the tunnel...
Should VGA work on P123 now?
Never mind, I see there's a VGA demo now with P123 instructions.
A new name? I am beginning to think that it should be called 'Granite' after the founding industry of Rocklin, California - current home of Parallax.
I hope a name like that is not set in stone!
Rocklin V16 conjures up a chip name and a very powerful engine with not one, or two, or four, but 16 Rocklin cores.
I was just trying out Chip's VGA driver with DE2. Seems to work pretty well.
But, I think his "intensity" is too high (for my monitor anyway).
Had to dial it down from 80 to 55 or so.
Update: 80 is good for P123 board, but too high for DE2-115
Also, (and this is really nit-picky) I noticed a lot of pixilation in the image.
Found the source image and re-did it with Photoshop and I think it's a lot better.
But, maybe you have to look real close to see the difference:
I think there's an issue with 4-bpp and 1-bpp LUT modes (and probably 2-bpp too)...
The output order appears backwards from what BMP format uses...
Here's an example 1-bpp bitmap and screenshot showing how it comes out:
Also, for some reason I don't understand, I had to set the orgh to $1000-$3E instead of the $1000-$40 that I thought it should be to get it to come out right...
I had to reverse the font for my character driver. Didn't even notice this, thinking it was reversed because we often did that on the P1. Just checked, and the font is correct, and I've reversed it again for P2. Maybe this was intended for compatability?
Agreed. This would be good to change. Pixel output order is backward. And making low bit rate bitmaps in linear order is something people will do a lot of. It's just frugal use of RAM.
Had I chosen to display a 2 color bitmap, I would have seen this too. Glad you did one.
"By incorporating DDS output with Goertzel input, many interactive real-world measurements can be made to determine things like time-of-flight and resonance."
Just noticed that the forum software changes the format of bmp files that I upload.
Anyway, I'll put them here as a zip in case anybody else wants to try:
I added code to fix the bit order and got it to look right...
Seems the bytes are in the right order, but the bits in each byte have to be reversed to display correctly. Here's the code that fixes and displays 1bpp bird:
If you want more birds, you have to go widescreen
Here's WVGA (852x480):
(it shimmers a little tiny bit, probably due to the pixel clock not being even divisor of 50 MHz clock)
Comments
Here is the link I used for just the tools:
http://download.altera.com/akdlm/software/acdsinst/15.1/185/ib_installers/QuartusProgrammerSetup-15.1.0.185-windows.exe
This gave me the correct USB-Blaster drivers for windoze 8.1
I'm way behind on reading forum posts right now.
Question: I'd like to get rid of GETD and GETS, which read the D and S fields, and then replace their slots with RGBW2L and RGBL2W which would convert between 8:8:8:0 RGB (long) and 5:6:5:0 RGB (word). I think with the ALTD/ALTS instructions, there's reduced need for GETD and GETS, though SETD and SETS are still useful. Any opinions? I really want to keep SEUSSF and SEUSSR, as they will be handy for quick pseudo-random and obfuscation functions.
Is it possible to merge ALTS with SETS so a single instruction covers both scenarios and frees up another opcode?
Same applies to ALTD and SETD?
(say you want to connect all 24 color bits to an LCD but work internally in 16-bit mode) (or, you want to quickly display a 24-bpp bitmap from uSD card when working in 16-bit mode).
Can't think of any situation where GETD or GETS would be useful for me...
But now I'm curious... I though there were all kinds of opcodes still free. Are they all full now?
As for ops, there needs to be some reserved for the smart pin ops. Being frugal at this stage makes good, general sense, and that's all I think Chip is after right now.
I think MSGIN and MSGOUT are for the smart pins, the ops will then be in the message you send.
SETD & SETS s/be GETD & GETS - a typo
Yes, we can live without GETD & GETS.
"That's the left wisdom tooth right?"
"Right!"
"Okay, right then"........
There was plenty of D field and null operand slots spare but only a few left of the full dual operand instruction slots. Presumably those have been gobbled up already.
At this point, I don't have any ideas to enhance the design further. I will add to the documentation over the next few days before starting on the smartpin circuit.
I see this recent news from Spansion, of faster write speeds on DDR QuadSPI memory
http://www.cypress.com/news/cypress-introduces-industry-s-fastest-256mb-quad-serial-peripheral-interface-nor-flash-memory
One part can give 66 MBps, and 2 -wide can give 132MB/s at 66MHz CLK speeds.
I found an issue with Pnut not coding SETS and SETD correctly.
Docs show Pnut codes as
Thanks! It was a typo in the assembler. Fixed it and now updating the main file...
That is great to hear! Maybe we're starting to see some light at end of the tunnel...
Should VGA work on P123 now?
Never mind, I see there's a VGA demo now with P123 instructions.
Rocklin V16 conjures up a chip name and a very powerful engine with not one, or two, or four, but 16 Rocklin cores.
But, I think his "intensity" is too high (for my monitor anyway).
Had to dial it down from 80 to 55 or so.
Update: 80 is good for P123 board, but too high for DE2-115
Also, (and this is really nit-picky) I noticed a lot of pixilation in the image.
Found the source image and re-did it with Photoshop and I think it's a lot better.
But, maybe you have to look real close to see the difference:
We are here now!
The output order appears backwards from what BMP format uses...
Here's an example 1-bpp bitmap and screenshot showing how it comes out:
Also, for some reason I don't understand, I had to set the orgh to $1000-$3E instead of the $1000-$40 that I thought it should be to get it to come out right...
Agreed. This would be good to change. Pixel output order is backward. And making low bit rate bitmaps in linear order is something people will do a lot of. It's just frugal use of RAM.
Had I chosen to display a 2 color bitmap, I would have seen this too. Glad you did one.
-from Chip's docs
Anyway, I'll put them here as a zip in case anybody else wants to try:
Seems the bytes are in the right order, but the bits in each byte have to be reversed to display correctly. Here's the code that fixes and displays 1bpp bird:
(the photo was created by the popular photo program, irfanview, btw)
BTW: I'm wondering why the buffering of xcont doesn't make the vertical sync signal come out wrong... Or, maybe it is wrong but works anyway?
Here's WVGA (852x480):
(it shimmers a little tiny bit, probably due to the pixel clock not being even divisor of 50 MHz clock)