Yay!Xaranar wrote:Just upgraded to the new version, and I can confirm that the wobbling issue has been resolved, thanks!
(someone else reported that 2.1 now causes issues with a certain Dell monitor that was ok before =( )
Yay!Xaranar wrote:Just upgraded to the new version, and I can confirm that the wobbling issue has been resolved, thanks!
Urgh, fix one thing and something else breaks! Oh dear, well, I appreciate all your hard work on this. When I put the new software on my Pluto II I totally didn't know that you didn't need the external power supply in order to flash it, so I plugged my 9V DC adapter into my little TXDI board, and when I plugged that into my Pluto, to my surprise, my Cube powered on! Well, the LED and the fan did, though I don't know if it was outputting a display signal as it wasn't plugged in to my monitor. Anyway, flashing the board that way didn't seem to work, so I plugged the GC power supply in and switched it on, and was able to flash the board that way. Thanks for the free settings reset, by the wayUnseen wrote: Yay!
(someone else reported that 2.1 now causes issues with a certain Dell monitor that was ok before =( )
I would just re-use the existing high-bandwidth channel from the Gamecube to the FPGA: The video data stream. It has a few limitations because it can't output all possible 8-bit-values, but even with just a single line on screen and four bit per pixel you can transmit about 20 kByte/s (60fps, 640 pixels, no delays). To acknowledge a successful data reception, the FPGA could use the Cable Detect pin.meneerbeer wrote:I guess this could be done through the controller line?
I would probably ask the user to select an "Update firmware" option in the OSD and add some checksum to the data to be on the safe side.meneerbeer wrote:I had been thinking about that as well. How can we distinguish between video and firmware data though?
Probably yes, if the timing required by the TFT is close enough to standard EDTV that it can be fed with the Cube pixel data without adding a full frame buffer. I don't have any experience with driving stand-alone TFTs though, so this is pure guesswork.bentomo wrote:Do you think it would be possible to convert the digital signal from the gamecube directly to an 18bpp or 24bpp clocked 40 pin bus that could drive a stand alone TFT LCD display?
The .svf file is useful for programming the chip with non-Lattice tools which support SVF playback, e.g. Xilinx' Impact.
Are you sure about the 190 microseconds? IIRC the 480p output of the Gamecube was close to if not spot-on to the CEA timings, but 190 microseconds would be a VSync length of 7.125 lines instead of the expected 6 lines (160 microseconds).Aurelio wrote:I checked vsync and hsync pulses and I get durations of ~190 us and ~2.4 us (respectively), which are not standard.
No, the sync outputs are just the decoded signals provided by the Gamecube.Is there a way to change their durations?
Thank you for answering me.Unseen wrote:Are you sure about the 190 microseconds? IIRC the 480p output of the Gamecube was close to if not spot-on to the CEA timings, but 190 microseconds would be a VSync length of 7.125 lines instead of the expected 6 lines (160 microseconds).Aurelio wrote:I checked vsync and hsync pulses and I get durations of ~190 us and ~2.4 us (respectively), which are not standard.
No, the sync outputs are just the decoded signals provided by the Gamecube.Is there a way to change their durations?
The last part of that sentence seems to indicate to me that the lines show up in swiss even though the sync length is still 160us? In that case I'm not sure if changing the timing would help.Aurelio wrote:When I turn on the GameCube the vsync duration is 160 us and it stays this way until I run a game from swiss when it changes to 190 us (still the lines are visible also in swiss).
In theory yes, in practice I wonder if it would introduce new compatibility issues - it's not just about the sync duration, the position is also important.About changing the sync durations I was thinking about two counters that could be reset on the falling edge of the sync flags to provide correct timing on output syncs. Could it be possible?
I'm a PAL user too and I haven't seen such stripes yet. NTSC or PAL isn't that much of a difference for the Gamecube anway since it uses a 13.5/27MHz pixel clock, which is the the same pixel clock used for standard 480i/576i/480p/576p video timings.EDIT: I'm using a PAL console, could the problem be related to this? Still I get the same lines both with NTSC and PAL games
I can't think of any specific fault on a GCVideo Lite board that would cause this - my first idea was interference from the SPDIF signal, but that wouldn't be vertically aligned between adjacent image lines.Aurelio wrote:I've tried to rewire again everything using different wires, but nothing changed. I'm going to try to assemble a new gcvideo lite. Do you have any idea if it could be some particular component causing this issue?
In the first command you have to specify the path to the directory where the BSDL of the FPGA is stored (/Users/Aurelio in my case), while in the last one you have to specify the complete path to the .svf file of gcvideolite.cable UsbBlaster
bsdl path /Users/Aurelio
detect
part 0
svf /Users/Aurelio/gcvideolite.svf
No, I don't think it is (directly) related to 480i support.Aurelio wrote:Sorry if I post again. I've a "theory" about my issue. Both my LCD and my TV don't seem to handle 480i, while they show 480p but with those lines. Is it possible that since they can't handle 480i a slight difference in the timings (front/back porch?) can cause those lines? Maybe a LCD capable of handling 480i is more flexible to timings differences and it can handle the video with no issues... could it be right?
Neat, thanks!Oh BTW, I think this might be useful to others. I found a way to flash the FPGA with a cheap Altera USB Blaster clone. This works also on non-Windows OS.