1. We know video DAC output is only on COG 0. I assumed that was due to the large number of resources required. Is the pixel engine (PIX) available on other COGS? It executes, but I've not yet collected output. Just wondering what the limits are.
2. How do we get 16 bit output from PIX, or can we quickly transform output from 32 bit color?
3. Maybe PIX works in ways appropriate for the WAITVID mode in use. Is this true?
@Cluso, the loader part of Pnut won't load past a given point, but it compiles it all. Use CTRL-L to get the object listing.
Here's your program with a 5000 element test array at the end: (attached)
You could format this for input through a terminal. I've done this a few times, and the format is in my monitor document. Basically, you need a starting hex address, followed by all the data, one colon per line to keep specifying addresses.
2000: FF AA FF (16 bytes per line)
: AA BB CC (16 bytes more, for as many as you want)
OBJ bytes: 6,964
_CLKMODE: 22
_CLKFREQ: 03938700
0E80: 0D 9C FC 0C 50 9C BC 80 00 9C BC FC 49 00 7C 1C
: 0D BE FC A0 59 BC FC 1F 37 BE FC A0 59 BC FC 1F
: 38 BE FC A0 59 BC FC 1F 39 BE FC A0 59 BC FC 1F
: 0D BE FC A0 59 BC FC 1F 52 BE BC A0 59 BC FC 1F
(lots of code, and optionally start addresses)
: 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
: 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
: 33 33 33 33
Edit: It would be great if Pnut.exe output a monitor compatible object code listing.
@Cluso, the loader part of Pnut won't load past a given point, but it compiles it all. Use CTRL-L to get the object listing.
.....
Edit: It would be great if Pnut.exe output a monitor compatible object code listing.
Thanks potatohead. Thought I was going nuts for a while.
Do you know if the p2loader will load the pnut binary? (I will go looking for it to see)
1. We know video DAC output is only on COG 0. I assumed that was due to the large number of resources required. Is the pixel engine (PIX) available on other COGS? It executes, but I've not yet collected output. Just wondering what the limits are.
2. How do we get 16 bit output from PIX, or can we quickly transform output from 32 bit color?
3. Maybe PIX works in ways appropriate for the WAITVID mode in use. Is this true?
Um.. Video DAC output is only on COG0? It's only that way on the FPGA boards because it's simulating the DACs with a bunch of FPGA output pins, also the daughter board for the DE2-115 only has the external Smile for 4 DACs (DE0 only has 1 cog). The real Prop2 will be able to drive 4 DACs per cog (at full speed, more at lower speeds), and the VID and PIX stuff will be in all cogs.
Also, pretty sure the GETPIX output is a 32bit color, you'll have to either convert it to the pixel format you want.
potatohead, looks like I was right, it's gonna have to be either downsized to 16bit or less, for each pixel, or screen buffers will have to be 32bit.
I guess I should have made GETPIX handle 5:5:5 RGB data, not just 8:8:8. If we wind up making any necessary RTL changes in the future, I'll add that in.
For now, you are stuck with only highest-quality 8:8:8 pixels when using the texture mapper. This, of course, results in lower-resolution displays which use a whole long per pixel.
Thanks Chip
I have however managed to come up with a quick solution for GETPIX to handle 5:5:5, tested and working, I will post demo tomorrow.
But yeah, if you get to allow it to handle 5:5:5 that would be awesome , but I don't want it to come back with anything needing changing.
Don't think on this.
I was not thiniking that P29-Pxx need be converted to HEX
Now I reprogrammed my DE2-115. BUT it don't function that pinout.txt describe.
P29 no connection on DE0-Nano, LED15/KEY1 on DE2-115
pin command - 29 H --- Starts LEDR9
P30 no connection on DE0-Nano, LED16/KEY2 on DE2-115
pin command - xx H don't change any led
P31 no connection on DE0-Nano, LED17/KEY3 on DE2-115
pin command - xx H don't change any led
Port B
P32 no connection on DE0-Nano, LED0/SW0 on DE2-115
pin command - 32 H --- Starts LEDG0, LEDG1, LEDG2 --- 32 L -- don't place LED's in off state
P33 no connection on DE0-Nano, LED1/SW1 on DE2-115
pin command - xx H don't change any led
P34 no connection on DE0-Nano, LED2/SW2 on DE2-115
pin command - xx H don't change any led
P35 no connection on DE0-Nano, LED3/SW3 on DE2-115
pin command - xx H don't change any led
P36 no connection on DE0-Nano, LED4/SW4 on DE2-115
pin command - xx H don't change any led
P37 no connection on DE0-Nano, LED5/SW5 on DE2-115
pin command - xx H don't change any led
P38 no connection on DE0-Nano, LED6/SW6 on DE2-115
pin command - xx H don't change any led
P39 no connection on DE0-Nano, LED7/SW7 on DE2-115
pin command - xx H don't change any led
P40 no connection on DE0-Nano, LED8/SW8 on DE2-115
pin command - xx H don't change any led
P41 no connection on DE0-Nano, LED9/SW9 on DE2-115
pin command - xx H don't change any led
P42 no connection on DE0-Nano, LED10/SW10 on DE2-115
pin command - xx H don't change any led
P43 no connection on DE0-Nano, LED11/SW11 on DE2-115
pin command - xx H don't change any led
Sapieha,
Wouldn't you just write a new program and store in flash like this???
DAT
org 0
''=======[ Return to the ROM Monitor ]=========================================
'------------------------------------------------------------------------------
Run_monitor setcog #0 ' not required if still cog 0
coginit monitor_pgm,monitor_ptr ' init cog0 with monitor
monitor_pgm long $70C ' monitor program address
monitor_ptr long 90<<9 + 91 ' monitor parameters
Sapieha,
Wouldn't you just write a new program and store in flash like this???
DAT
org 0
''=======[ Return to the ROM Monitor ]=========================================
'------------------------------------------------------------------------------
Run_monitor setcog #0 ' not required if still cog 0
coginit monitor_pgm,monitor_ptr ' init cog0 with monitor
monitor_pgm long $70C ' monitor program address
monitor_ptr long 90<<9 + 91 ' monitor parameters
David, looking at the instruction set, COGID takes till the next hub cycle, SETCOG should only take 1 clock cycle. Setting b3=1 %1xxx uses the next available cog.
I know this works...
'------------------------------------------------------------------------------------------------
' Return to the ROM Monitor...
'------------------------------------------------------------------------------------------------
Run_monitor setcog #0 ' not required if still cog 0
coginit monitor_pgm,monitor_ptr ' init cog0 with monitor
monitor_pgm long $70C ' monitor program address
monitor_ptr long 90<<9 + 91 ' monitor parameters
and I just modified this and the following works too (on the DE0)...
''=======[ Return to the ROM Monitor ]=========================================
'------------------------------------------------------------------------------
Run_monitor 'setcog #0 ' not required if still cog 0
cogid cog
setcog cog
coginit monitor_pgm,monitor_ptr ' init cog0 with monitor
monitor_pgm long $70C ' monitor program address
monitor_ptr long 90<<9 + 91 ' monitor parameters
cog long 0
David, looking at the instruction set, COGID takes till the next hub cycle, SETCOG should only take 1 clock cycle. Setting b3=1 %1xxx uses the next available cog.
I know this works...
'------------------------------------------------------------------------------------------------
' Return to the ROM Monitor...
'------------------------------------------------------------------------------------------------
Run_monitor setcog #0 ' not required if still cog 0
coginit monitor_pgm,monitor_ptr ' init cog0 with monitor
monitor_pgm long $70C ' monitor program address
monitor_ptr long 90<<9 + 91 ' monitor parameters
and I just modified this and the following works too (on the DE0)...
''=======[ Return to the ROM Monitor ]=========================================
'------------------------------------------------------------------------------
Run_monitor 'setcog #0 ' not required if still cog 0
cogid cog
setcog cog
coginit monitor_pgm,monitor_ptr ' init cog0 with monitor
monitor_pgm long $70C ' monitor program address
monitor_ptr long 90<<9 + 91 ' monitor parameters
cog long 0
Very odd. Is there any chance that the COGID opcode is wrong in the instruction table? I guess I'll have to dump some code from PNut to see what bit pattern gets generated for it.
instructions clocks
-------------------------------------------------------------------------------------------------
000011 ZCR 0 CCCC DDDDDDDDD SSSSSSSSS COGINIT D,S ''launch COG at D, COG PTRA = S 1..9
000011 000 1 CCCC DDDDDDDDD 000000000 CLKSET D ''set clock to D 1..8
000011 001 1 CCCC DDDDDDDDD 000000001 COGID D ''get COG number into D 2..9
000011 000 1 CCCC DDDDDDDDD 000000011 COGSTOP D ''stop COG in D 1..8
000011 ZC1 1 CCCC DDDDDDDDD 000000100 LOCKNEW D ''get new lock into D, C = busy 2..9
000011 000 1 CCCC DDDDDDDDD 000000101 LOCKRET D ''return lock in D 1..8
000011 0C0 1 CCCC DDDDDDDDD 000000110 LOCKSET D ''set lock in D, C = prev state 1..9
000011 0C0 1 CCCC DDDDDDDDD 000000111 LOCKCLR D ''clear lock in D, C = prev state 1..9
-------------------------------------------------------------------------------------------------
Very odd. Is there any chance that the COGID opcode is wrong in the instruction table? I guess I'll have to dump some code from PNut to see what bit pattern gets generated for it.
instructions clocks
-------------------------------------------------------------------------------------------------
000011 ZCR 0 CCCC DDDDDDDDD SSSSSSSSS COGINIT D,S ''launch COG at D, COG PTRA = S 1..9
000011 000 1 CCCC DDDDDDDDD 000000000 CLKSET D ''set clock to D 1..8
000011 001 1 CCCC DDDDDDDDD 000000001 COGID D ''get COG number into D 2..9
000011 000 1 CCCC DDDDDDDDD 000000011 COGSTOP D ''stop COG in D 1..8
000011 ZC1 1 CCCC DDDDDDDDD 000000100 LOCKNEW D ''get new lock into D, C = busy 2..9
000011 000 1 CCCC DDDDDDDDD 000000101 LOCKRET D ''return lock in D 1..8
000011 0C0 1 CCCC DDDDDDDDD 000000110 LOCKSET D ''set lock in D, C = prev state 1..9
000011 0C0 1 CCCC DDDDDDDDD 000000111 LOCKCLR D ''clear lock in D, C = prev state 1..9
-------------------------------------------------------------------------------------------------
Thanks Sapieha! Those are the encodings that GCC currently uses. I went back to my original code and now it seems to work. I guess there was some other problem that I've since fixed. Sorry for sending everyone on a wild goose chase!
That give 5B B4 00 00
In position B4 I wanted me 90 = $5A for correct pin number
It's that way because in PASM it's easy to move into that 9-bit field using the MOVD instruction. In a high-level language, it wouldn't matter. So, I made it easy in assembly.
It's that way because in PASM it's easy to move into that 9-bit field using the MOVD instruction. In a high-level language, it wouldn't matter. So, I made it easy in assembly.
Comments
1. We know video DAC output is only on COG 0. I assumed that was due to the large number of resources required. Is the pixel engine (PIX) available on other COGS? It executes, but I've not yet collected output. Just wondering what the limits are.
2. How do we get 16 bit output from PIX, or can we quickly transform output from 32 bit color?
3. Maybe PIX works in ways appropriate for the WAITVID mode in use. Is this true?
Here's your program with a 5000 element test array at the end: (attached)
You could format this for input through a terminal. I've done this a few times, and the format is in my monitor document. Basically, you need a starting hex address, followed by all the data, one colon per line to keep specifying addresses.
2000: FF AA FF (16 bytes per line)
: AA BB CC (16 bytes more, for as many as you want)
Edit: It would be great if Pnut.exe output a monitor compatible object code listing.
Thanks potatohead. Thought I was going nuts for a while.
Do you know if the p2loader will load the pnut binary? (I will go looking for it to see)
Um.. Video DAC output is only on COG0? It's only that way on the FPGA boards because it's simulating the DACs with a bunch of FPGA output pins, also the daughter board for the DE2-115 only has the external Smile for 4 DACs (DE0 only has 1 cog). The real Prop2 will be able to drive 4 DACs per cog (at full speed, more at lower speeds), and the VID and PIX stuff will be in all cogs.
Also, pretty sure the GETPIX output is a 32bit color, you'll have to either convert it to the pixel format you want.
Was just wondering how PIX worked and what options there were.
I guess I should have made GETPIX handle 5:5:5 RGB data, not just 8:8:8. If we wind up making any necessary RTL changes in the future, I'll add that in.
For now, you are stuck with only highest-quality 8:8:8 pixels when using the texture mapper. This, of course, results in lower-resolution displays which use a whole long per pixel.
I have however managed to come up with a quick solution for GETPIX to handle 5:5:5, tested and working, I will post demo tomorrow.
But yeah, if you get to allow it to handle 5:5:5 that would be awesome
Don't think on this.
I was not thiniking that P29-Pxx need be converted to HEX
Now I reprogrammed my DE2-115. BUT it don't function that pinout.txt describe.
P29 no connection on DE0-Nano, LED15/KEY1 on DE2-115
pin command - 29 H --- Starts LEDR9
P30 no connection on DE0-Nano, LED16/KEY2 on DE2-115
pin command - xx H don't change any led
P31 no connection on DE0-Nano, LED17/KEY3 on DE2-115
pin command - xx H don't change any led
Port B
P32 no connection on DE0-Nano, LED0/SW0 on DE2-115
pin command - 32 H --- Starts LEDG0, LEDG1, LEDG2 --- 32 L -- don't place LED's in off state
P33 no connection on DE0-Nano, LED1/SW1 on DE2-115
pin command - xx H don't change any led
P34 no connection on DE0-Nano, LED2/SW2 on DE2-115
pin command - xx H don't change any led
P35 no connection on DE0-Nano, LED3/SW3 on DE2-115
pin command - xx H don't change any led
P36 no connection on DE0-Nano, LED4/SW4 on DE2-115
pin command - xx H don't change any led
P37 no connection on DE0-Nano, LED5/SW5 on DE2-115
pin command - xx H don't change any led
P38 no connection on DE0-Nano, LED6/SW6 on DE2-115
pin command - xx H don't change any led
P39 no connection on DE0-Nano, LED7/SW7 on DE2-115
pin command - xx H don't change any led
P40 no connection on DE0-Nano, LED8/SW8 on DE2-115
pin command - xx H don't change any led
P41 no connection on DE0-Nano, LED9/SW9 on DE2-115
pin command - xx H don't change any led
P42 no connection on DE0-Nano, LED10/SW10 on DE2-115
pin command - xx H don't change any led
P43 no connection on DE0-Nano, LED11/SW11 on DE2-115
pin command - xx H don't change any led
If You will have Flash installed -- But start in Monitor mode.
Wouldn't you just write a new program and store in flash like this???
DAT org 0 ''=======[ Return to the ROM Monitor ]========================================= '------------------------------------------------------------------------------ Run_monitor setcog #0 ' not required if still cog 0 coginit monitor_pgm,monitor_ptr ' init cog0 with monitor monitor_pgm long $70C ' monitor program address monitor_ptr long 90<<9 + 91 ' monitor parametersIt is not problem write that - But not necessary.
If You run program in PNut I posted in previous post with Flash installed - Emulator will start with Monitor and see Flash as not programmed.
.
cogid t1 setcog t1 coginit cmd1, cmd2 'relaunch cog0 with loaded programFor some reason, my program hangs if I try this. On the other hand, this sequence works:
mov t1, #0 setcog t1 coginit cmd1, cmd2 'relaunch cog0 with loaded programAm I using COGID wrong?cogid t1 setcog t1 coginit monitor_pgm, monitor_ptrI added this to the current program I was working on. Figured it would launch, kill itself off and spawn the monitor in COG 0, which it did.
I know this works...
'------------------------------------------------------------------------------------------------ ' Return to the ROM Monitor... '------------------------------------------------------------------------------------------------ Run_monitor setcog #0 ' not required if still cog 0 coginit monitor_pgm,monitor_ptr ' init cog0 with monitor monitor_pgm long $70C ' monitor program address monitor_ptr long 90<<9 + 91 ' monitor parametersand I just modified this and the following works too (on the DE0)...''=======[ Return to the ROM Monitor ]========================================= '------------------------------------------------------------------------------ Run_monitor 'setcog #0 ' not required if still cog 0 cogid cog setcog cog coginit monitor_pgm,monitor_ptr ' init cog0 with monitor monitor_pgm long $70C ' monitor program address monitor_ptr long 90<<9 + 91 ' monitor parameters cog long 0It is what I have on BIT's used.
monitor_ptr long 90<<9 + 91 'Pins for one monitor
Why pin number 90 are shifted 9 positions --Not 8
That give 5B B4 00 00
In position B4 I wanted me 90 = $5A for correct pin number
Any info on use Internal "D" port
Function it as all others -- else is it differences ?
It's that way because in PASM it's easy to move into that 9-bit field using the MOVD instruction. In a high-level language, it wouldn't matter. So, I made it easy in assembly.
Right now, I'm almost done with the first SDRAM driver.
Thanks.
Now I understand that
Time to wait for me.
Thanks
Looking forward to the Port D docs as well.
In Yours "PropII_Monitor v2.spin" ---- You use instruction "cmpr" but it is still not described.
CMPR D,S/#n is SUBR D,S/#n NR
It compares S/#n to D and sets C if S<D.
Thanks