OSD does not work, internal gotek #26
Comments
|
I assume it will never work, as signals from gotek are connected to analog RED and CSYNC (after VIDIOT). |
Maybe... There are several potential solutions:
Option 2 is would be relatively simple to try although the quality would not be great. |
|
OK I got that working Download the latest Beta15: Connect Flash floppy video signal to PIN 18 on the Pi zero header via a 1K resistor (That's GPIO 24) When video is detected the screen will dim by 50% and the video will be overlaid in white. It will be a little ragged as the FF OSD pixel clock is not locked to the Amiga pixel clock. Post some screencaps if you get it working (short press on button, files stored on SD card) Here is a screencap showing the dimmed screen with the BBC micro overlay: Normal intensity screen for comparison: |
|
Isn't GPIO18 used to detect the Amiga mode? In my current adapter GPIO18 is pulled to GND via a 3k3 resistor. |
PIN 18 is GPIO 24 |
|
Ah, yes. Of course. This kind of numbering missmatches always confuses me even with my own board designs. |
|
I connected pb15 from the bluepill to pin 18 of the PiZero via a 1k resitor (using the new beta15 files) and couldnt see any OSD. Not sure if it is my error or not. |
|
First try connecting PIN 18 (i.e. GPIO 24) to PIN 17 (+3.3v) on the Pi header using the 1K resistor. The screen should go white indicating that the overlay input is working. I just downloaded beta15 and tried that to confirm it worked on my system. I don't know what the voltage level out of the blue pill is when text pixels are being displayed so can you check that with an oscilloscope if you have one. |
|
Here is a photo of the connection: Wire on the left is PIN 18. The wire on the right on PIN 6 is ground as I was using an external BBC micro source. You shouldn't need that as the blue pill and RGBtoHDMI will both be grounded via the Amiga. |
|
Hi Ian, Thanks for the reply. I will show you some pictures of my A500 so you can see how it is actually setup. (The left monitor is attached to the Pi and the one on the right is RGB The gotek is my design of the Gotek that i redone and made it connect directly to the a500 header and power, I broke out all of the extra signals to make it easier for possible upgrades later. The Bluepill attached is mounted directly to the gotek and needed signals fed to it. My keyboard is hardwired to use the Shift, Alt and amiga keys to access flashfloppy's keyboard menu options The Bluepill has the latest 1.8 FW on it. The 2 wires attached to the lower left of the bluepill are feeding the sync and RGB colour out to enable the OSD on the RGB monitor, I attached it to the Green signal. A 1K resistor is attached to pin 18 of the Pi header and when i short it to pin 17 the monitor attached to the Pi HDMI output will go white. The beta 5 files are set to default. When i connect the blue wire from the bluepill (PB15) to the resistor on the Pi header i do not see any input on the screen. The screen does not dim at all and there are no artifacts displayed at all Looking at the picture of the a500 you can see that the OSD works ok on the RGB monitor, The small OLED display works ok too. (Pin 6 is grounded to the Amiga) |
|
here are pictures
|
|
Have you tried removing the connection of bluepill PB15 from the Amiga and connecting PB15 just to the Pi? |
|
Hi Ian, I pulled the pins from the amiga when testing the Pi. The only active connections from the Amiga gotek to the bluepill are SCL (B6), SDA (B7), 3.3v and Gnd. When mounting the bluepill to the gotek the other mounts are not connected to anything Here is a description of my gotek install. |
|
Have you tried a direct connection without the resistor? EDIT: |
|
I just released an updated beta16 which among other things doubled the frequency at which it checks for white pixels on pin 18 so give that a try as well. |
|
@IanSB i tried beta16 still nothing, i looked at the b15 output on my scope and i couldnt really get a good look at a decent signal, seemed like a lot of noise, (it is probably operator error). I did try bypassing the resistor, and there was no change to the picture at all. Shorting the resistor to pin 17 still changes picture to white. Is there anyone else trying this and getting same/different results ? |
You have to keep the sync pin connected to the Amiga otherwise it definitely won't work because the blue pill needs to synchronise with the Amiga so that it can generate the video signal. Only pull the video pin from the Amiga for testing
Not that I'm aware of, but if anyone reading this got it to work then please post. |
|
wow...
So to recap... add a 1k resistor to pin 18 of the pi header, Using your bluepill, connect B15 from the bluepill to the resistor you added to pin 18 of the Pi header. The sync line from the bluepill remains connected to the Amiga motherboard. Thanks for walking me through it Ian :) |
After re-reading your post and looking at the photos I suddenly realised that you were pulling the two way cable from the Amiga and plugging it onto the resistor which wouldn't work because the sync signal would be missing which is why I mentioned it. (That's an output from the Amiga into the blue pill to tell it when to draw the OSD). The image is ragged because the Amiga pixel clock and the FFOSD pixel clock aren't locked together. This effect is present on the analog output but is less noticeable because of the smoothing effect of an analog output. For the Pi, it's always digital so you get a very sharp ragged edge. I have been talking with Kier about sending the OSD info out of the serial port on the blue pill straight into the Pi which would then display it with it's own OSD and also driving the Pi's menu from an Amiga key combination also from the blue pill so there may be a better solution eventually.
You can try leaving B15 also connected to the Amiga so you get output on analog as well. It might not work if the voltage on B15 is pulled too low by the resistors but you won't know without trying. |
|
I tried to do this here. Connect Pi Header 18 - 1K Resistor - B15 Bluepill. The Bluepill is still and was before connected to my A2000 to display the OSD over analog output. When i connect Pi and Bluepill i get the OSD over HDMI but there are many artefacts and the colors are damaged. When i remove the connection the HDMI output is right again. Any hints for me?
|
|
Try disconnecting the B15 FFOSD video (only the video, not the sync) from the Amiga's analog output. It may be that you can't have the video connected to the analog Amiga signal at the same time because the Amiga's video output is feeding backwards into the Pi's pin 18. |
|
Yes, much better without video signal to Amiga. The OSD is a little nasty with „flickering waves“. Is it possible to get both, HDMI and Amiga analog, connected to the video signal without interference. |
|
|
As mentioned above that is due to the pixel clock on the blue pill video not being synchronised with the Amiga's pixel clock.
I've been discussing with Keir the possibility of directly communicating between the blue pill and Pi zero via the serial port which would allow the Pi zero to use its own OSD so that would mean much better quality and allow both video signals to work at the same time. |
|
Do you plan to create a better cooperation of FF_OSD and Amiga Adapter - RGB2HDMI? I think both are very good hardware mods to the Amiga and using both same time would be very nice. :-) |
|
As far as I know Ian is already planing somerhing together with the creator of the FF |
|
Here is the pinout for the OSD output to HDMI on the A600, i believe all models have the same layout...
(yah, i know wires need to be tidied up a bit, it's on my todo list :) |
|
Does the resistor need to be 1K? Can it be 3K3? I want to do parts consolidation and make use of the 3K3 already used on the RGBtoHDMI board. Or, maybe the other way - can the 3K3 on the RGBtroHDMI be replaced by 1K. I understand this is pull down resistor, so 1K should be OK too? |
|
Yes they are not critical, I think I used 1K for both on mine. |
|
The FF OSD build recommends a 270ohm resistor for the PB15 line. I assume this 1K resistor is meant to replace this 270ohm resistor? Is there a technical reason why it needs to change from 270 ohm to 1K ohm? |
270R should work just as well (and is needed to get the right signal level on the analog output) but increasing the value would reduce the amount of current in the event of two outputs being connected together. |
@IanSB What do you mean by 'two outputs'? What would/could be those two outputs? |
It's explained earlier in this thread: PIN 18 is the FFOSD input but was configured as an output on earlier Pi software so you must use a resistor to protect the FF video output pin in case older software is loaded as two outputs would then be connected. |
|
Thanks for the explanation. Would it be possible to have FF OSD PB15 connected to both the Pi and the Amiga motherboard - so that it will dual work between RGBtoHDMI and the Amiga video output? |
No, as mentioned above the Amiga analog video feeds backwards through the 270R resistor into the Pi's Pin 18 causing a messed up screen. Also it's harder to buffer the blue pill's video output because it is tri state (i.e. low, high or floating) so the simplest option would be to modify the blue pill's software to provide two video outputs on separate pins. A more complex mod would be to sent the OSD data serially from the blue pill to the Pi so the Pi can draw it using its own OSD and I asked Keir to look at that option. |
|
Maybe a stupid question based on my inexperience, but can a diode not be used instead to split off the video signal from the Blue Pill? |
The video signal from the blue pill has 3 levels, 3.3v to represent text pixels, 0v to represent the dark box around the text and floating when video switched off. The diode would need to be on the analog side to prevent the reverse video feedback but that would stop the analog side from "seeing" 0v so it would work in that you would get the text but there would be no dimmed black box around it which might make it hard to read on some backgrounds. Better than nothing I suppose. |
|
I tried the FF OSD support and it indeed does work, albeit a bit ragged/wavy.
For the test I used my existing 270ohm resistor wire connecting to B15 on the Blue Pill, I also wired CSYNC direct from the RGBtoHDMI board to the A8 pin on the Blue Pill and it seems to works. Now that I know wiring CYSYNC to the RGBtoHDMI adapter works, I will add a header point to my custom boards. |
|
Would be nice to connect the standard OLED display-wires from gotek/goex directly to the pi and let RGB2HDMI render the OSD, somehow. |
|
I've added the header pins for CSYNC and 'RGB' to go to the Blue Pill into my custom RGBtoHDMI board.
|
Indeed! And that's very very cool!!! What I was thinking - it should be possible to skip the Blue Pill altogether just reading the information the same way the OLED modification (replacement of the 7-segment display) does work with any Gotek. And let the software in the Pi do the work instead. If i was a bit unclear in the statement :) Simpler to skip-over the analog part. :) |
I understood what you meant. The Blue Pill in FlashFLoppy OSD is effectively an I2C display emulator, but it also does keyboard integration. It communicates with the FlashFloppy on the Gotek via a custom I2C protocol. |
@IanSB Thanks for the explanation. After speaking with Keir about it, he suggested to make use of the Display Enable pin to drive a tri-state buffer. I have now incorporated it in to my custom RGBtoHDMI board design. I need to get it printed and tested out to see whether it does actually work!
|
|
@IanSB When OSD is enabled/visible I seem to keep losing sync frequently - the screen goes blank/black for a second or so and then returns back. Is this a known issue? Do you have any suggestions on how to make it more stable? |
|
Do you mean the FFOSD or the Pi's OSD? Brief blanking like that can mean the monitor doesn't like rate the genlock changes the HDMI frequency. |
@IanSB Sorry, I should have been more clear. I meant when the FFOSD OSD is visible/enabled. I only get the brief blanking issue when this is displayed. The issue does not happen when the RGBtoHDMI OSD is displayed. Should I be using your specific release at https://github.com/IanSB/RGBtoHDMI/releases , but FFOSD OSD seems ot be working with the normal release (albeit with the brief blanking issue, and jagged text). |
I turned on V sync indicator - I assume it is the red horizontal line shown on the screen? When I enabled FFOSD OSD, the line disappeared. Just before the first brief blank I saw the red horizontal line move down in to view from the top of the screen. When the screen came back the line was not there and subsequent brief blanks occurred but the line did not reappear until I turned off FFOSD OSD. Without FFOSD OSD enabled, the image is rock solid, and the V sync indicator line is shown near the top of the screen. |
@IanSB It seems this did the trick! I set Genlock Speed to "Slow" and it no longer brief blanks. The V sync indicator line still disappears when FFOSD OSD is on, but it no longer brief blanks. (Actually, I just saw (once) the V sync indicator line shift down in to view and disappeared again.) |
|
OK it looks like there is a bug which causes lock to be lost when the FFOSD is enabled. On many monitors this would not be noticeable because the fast genlock speed works without causing the screen to blank. On your monitor setting genlock speed to slow works around the problem in a similar way. |
|
Here is beta17 test release which fixes the FFOSD issue plus a couple of other bugs: Wipe your SD card and install the new version |
It worked exactly as you stated - I no longer get brief blanks and the vsync indicator line stays in position! Thank you so much! |
|
Is there any advance in correcting the "wavy" letters? |
1 similar comment
|
Is there any advance in correcting the "wavy" letters? |
Hi,
I have this internal gotek and OSD does not work, over RGB cable it is ok.
https://www.sellmyretro.com/offer/details/amigotek-ff-osd-39893?fbclid=IwAR098xZAcUs8Bv4w7vhVoUmL9JhAcdb9fq1oAJ8F7dV_NatcxiR9coH03Yc
Any solution maybe?
The text was updated successfully, but these errors were encountered: