bad days but ... unseen is a star and saved the day 
he sent me a cut down version of the infoframe vhdl which got me close 107% overmapping to get the dam thing to fit I had to remove spif vhdl code 99% mapped now.Thank you happy_bunny flashed my shuriken video audio is working great. Do you think you could compile the code so I could use the xilinx xcs200a so we can have OSD and everything the GCvideo-DVI has. I would even pay you for your time to do it I can't code sohappy_bunny wrote:ok so I tried to compile the gcvideo-dvi 2.0 code for my board but it didnt fit, 112% overmapping
I have uploaded the now code on my website, I have tried it on the TV and monitor I own seems to produce the audio output over HDMI good work unseen and thanks for the info frame vhdl code.
0.3 half works, it has some green noise pixels on screen, here are some photos taken from my TV:happy_bunny wrote:Oh thats a bit weird does version 0.3 work on your tv
Indeed it seems that 0.3 has fried my FPGA. I don't think it could Handle it after 1 hour of gameplay its dead. Going to have to order more pcbs and build again i sold my other 2HyperIris wrote:0.3 half works, it has some green noise pixels on screen, here are some photos taken from my TV:happy_bunny wrote:Oh thats a bit weird does version 0.3 work on your tv
I've tried 0.4 again, still no HDMI signal to TV.
That really doesn't solve my problem. I really dont want to use this FPGA again i would rather buy a xcs200a instead so i could have all options and osd. Im away from home right now and bring this cube with me to pass time. Go thing i have my regular av cableHyperIris wrote:I have enough FPGAs and PCBs for build other 8 boards, so this is not a problem.
0.3 fried the FPGA??? what?andre104623 wrote: Indeed it seems that 0.3 has fried my FPGA. I don't think it could Handle it after 1 hour of gameplay its dead. Going to have to order more pcbs and build again i sold my other 2
>>> BadAssConsoles.com <<<emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving
>>> BadAssConsoles.com <<<emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving
I've done diff between the 0.2 and 0.3 source, I think there is NOT ANY wrong in your modification. the only different is audio part.happy_bunny wrote: @hyperIris will do a diff between the 0.2 and 0.3 tonight and see what I did. Cant remember the differences now, maybe I can spot something wrong.
I'm not home right now I won't be for a few days but "I'm guessing" that the update fried my FPGA I don't know for sure. It was working fine for a while I have it hooked up at the hotel I was staying at last night and all the sudden the picture started to flicker and cut in and out then nothing no video or audio. I won't be able to flash the older version till I get home the cube still works fine from normal AV cablesmegalomaniac wrote:0.3 fried the FPGA??? what?andre104623 wrote: Indeed it seems that 0.3 has fried my FPGA. I don't think it could Handle it after 1 hour of gameplay its dead. Going to have to order more pcbs and build again i sold my other 2
can you elaborate on this?
I was using the older 0.3 update. When I get home I will check everything caps, resistors, and regulators. I will say that the FPGA seemed to get hot after the update I been using this PCB for sometime now without problems. I never used this TV before since I was in a hotel but it was a newer sony LED TV. About half of the PCB sticks out the back of my cube so I can easily see the FPGA and with the 0.2 update the fpga would be warm after an hour of use but with this update it was hot like very hot seemed to me it overheated. There wasnt any smoke or anything like that or any damage like burned pins I was thinking that the FPGA doesn't have enough block ram to have the audio over HDMI so it overheatedhappy_bunny wrote:@andre104623
which update did you use audio over HDMI (0.4)? or the older one 0.3, is the fpga burnt? If not can you do me a favour when you get home can you check the outputs of the 1.2 vreg and 5 vreg please.
I want to know if the TV was back feeding voltage into the 5 vreg and the 100 ohms resistor didnt protect it and that popped or the 1.2 vreg gave up. The 1.2 vreg is the same as the pluto board but the input and ouput caps are different maybe they need to be beefed up.
between the wife / kids and work I dont have time to do another spin of the board with the bigger fpga on, hopefully at xmas I can look again. Saying that the kids will probably want to play with daddy all xmas so I not use if I will be able to do anything
@hyperIris will do a diff between the 0.2 and 0.3 tonight and see what I did. Cant remember the differences now, maybe I can spot something wrong.
LOL I can see it now. That's funnymegalomaniac wrote:
If I had to guess I would say latch-up or ESD damage - it is very unlikely that the damage is caused by the bitstream if the same bitstream works for other people.andre104623 wrote:About half of the PCB sticks out the back of my cube so I can easily see the FPGA and with the 0.2 update the fpga would be warm after an hour of use but with this update it was hot like very hot seemed to me it overheated.
Nope - if it doesn't have enough block RAM, the synthesis will fail and no .bit file is generated.I was thinking that the FPGA doesn't have enough block ram to have the audio over HDMI so it overheated
It wont burn me if i were to touch it. It just gets hot like if i had to guess maybe 90 to 100 Fahrenheit maybe more. Yes i did have the Spdif line hooked up Because it would have been a hassle removing it. Like i said i can build the pcbs but when it comes to troubleshooting Im kind of lost in that department i can still check all the components with a multimeter thats not a problem. When i get back on Monday hopefully i can figure this out but i want to flash the 0.2 update and see if its back to normal firsthappy_bunny wrote:@andre104623
i have run this dol for an hour (using 0.5 update)
http://www.chadheim.com/projects/projec ... o-gamecube
its second level of quake 3, I can touch the fpga easy for a minute without it burning me I would say its warm 30C no more. Really weird it gets hot (it should never got really hot) did you have the spdif connector still soldered up? the only thing I can think is it dont like the spdif connector / wiring.
@HyperIris
I think its noise with only the video stuff only ond DCM block was used running at 54Mhz with audio you have two clock circuits running. I think the ground plane is jumping / noisy due to the clocks can you try this please (dam it didnt let me attach the vhdl) its from gcdv_decoder.vhd
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use work.video_defs.all;
entity gcdv_decoder is
port (
-- Gamecube signals
VClockI : in std_logic; -- 54 MHz clock, pin 2
VData : in std_logic_vector(7 downto 0);
CSel : in std_logic; -- "ClkSel" signal, pin 3
-- output clock enables
PixelClockEnable : out boolean; -- CE relative to input clock for complete pixels
-- video output
Video : out VideoY422
);
end gcdv_decoder;
architecture Behavioral of gcdv_decoder is
signal current_y : unsigned(7 downto 0);
signal current_cbcr : unsigned(7 downto 0);
signal current_flags: std_logic_vector(7 downto 0);
signal prev_csel : std_logic;
signal in_blanking: boolean;
signal input_30khz: boolean := false;
signal modecounter: natural range 0 to 3 := 0;
signal vdata_buf: std_logic_vector(7 downto 0);
signal csel_buf : std_logic;
begin
process (VClockI)
begin
if rising_edge(VClockI) then
-- buffer incoming data to relax timing
vdata_buf <= VData;
csel_buf <= CSel;
-- read cube signals
prev_csel <= csel_buf;
-- read cube signals
if prev_csel /= csel_buf then
-- csel has changed, current value is Y
current_y <= unsigned(vdata_buf);
if vdata_buf = x"00" then
-- in blanking, next color is flags
in_blanking <= true;
else
in_blanking <= false;
end if;
-- detect if it's a 15kHz or 30kHz video mode
modecounter <= 0;
if modecounter < 2 then
input_30khz <= true;
else
input_30khz <= false;
end if;
else
-- current value is color or flags
modecounter <= modecounter + 1;
-- read color just once in 15kHz mode
if (not input_30khz and modecounter = 1) or input_30khz then
if in_blanking then
current_flags <= vdata_buf;
else
current_cbcr <= unsigned(vdata_buf);
end if;
end if;
end if;
-- generate output signals
if prev_csel /= csel_buf then
-- output pixel data when the next Y value is received
PixelClockEnable <= true;
Video.Blanking <= in_blanking;
Video.HSync <= (current_flags(4) = '0');
Video.VSync <= (current_flags(5) = '0');
Video.CSync <= (current_flags(7) = '0');
Video.IsProgressive <= (current_flags(0) = '1');
Video.IsPAL <= (current_flags(1) = '1');
Video.IsEvenField <= (current_flags(6) = '1');
if in_blanking then
Video.PixelY <= x"10";
-- color during blanking is ignored by the 422-444 interpolator
--Video.PixelCbCr <= x"80";
else
Video.PixelY <= current_y;
Video.PixelCbCr <= current_cbcr;
end if;
Video.CurrentIsCb <= (csel_buf = '1');
Video.Is30kHz <= input_30kHz;
else
PixelClockEnable <= false;
end if;
end if;
end process;
end Behavioral;
This code works, it looks nice now. and I'll try 0.4 again now.happy_bunny wrote: @HyperIris
I think its noise with only the video stuff only ond DCM block was used running at 54Mhz with audio you have two clock circuits running. I think the ground plane is jumping / noisy due to the clocks can you try this please (dam it didnt let me attach the vhdl) its from gcdv_decoder.vhd
>>> BadAssConsoles.com <<<emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving
no, I'm not connected the SPDIF port, the FPGA chip is cold (as room temperature).megalomaniac wrote:@HyperIris
with 0.4 or even 0.3 do you notice any elevated temperature of the chip?
if so, can you remove the spdif port and try the tests again to check thermal increase of the chip...
