STM Binary

[venice1200]

Hi, I am going to build your RGB2HDMI FlashFloppy OSD Project but I don’t know how to build the firmware for the STM.

Is there a prebuild binary available from your end?

And do you have any plans plans to patch the current OSD Version from keirf with your changes?

Many Thanks

[solarmon]

Hi,

Do you mean my forked repo for OSD at?:

https://github.com/solarmon/FF_OSD

If I remember correctly, the only change I did was to add the RGBtoHDMI 3-button example (in https://github.com/solarmon/FF_OSD/blob/master/src/default_config.c):

https://github.com/solarmon/FF_OSD/commit/b5f8fc9119af0d06347212f83702bbfb92cdf91b

So you could probably easily make this change to the source file of the original repo at https://github.com/keirf/flashfloppy-osd

Sorry, I don't have any pre-built binaries. I can't even remember how to build it without looking in to it again.

[solarmon]

The build guide from keirf's flashfloppy-osd repo is at:

https://github.com/keirf/flashfloppy-osd/wiki/Building-From-Source

[venice1200]

Many thanks for your response.

Does this means the RGB2HDMI OSD via HDMI works out of the box when i build and use your hardware, even with an unmodified FF_OSD Software from keirf?

[solarmon]

Well, it will work but without the three button integration - so you cannot use the keyboard to control the RGBtoHDMI menu (using F1, F2 and F3 - or whatever button you assign in default_config.c)

[solarmon]

I have updated the README (for https://github.com/solarmon/FlashFloppy/tree/main/FF%20OSD%20Adapter%20-%20Rev%202) to mention the button mapping changes required, and link to how to build the Blue Pill firmware:

https://github.com/solarmon/FlashFloppy/blob/main/FF%20OSD%20Adapter%20-%20Rev%202/README.md#ff-osd-firmware

[venice1200]

I will try!

Many Thx

[venice1200]

Hi again, C1 of the Denise Adapter v1.1 is marked as a unipolar 10uF Capacitator. But the footprint picture looks like a "normal" Ceramic one. Is a bipolar one fine as well?

Are all SMD Parts 0805?

Cheers

[solarmon]

@venice1200

Thank you for pointing this out.

It looks like that C1 symbol was used in the original c0pperdragon schematic (I think) and got transferred over when I made my spinoff versions.

The actual board design and the footprint used is for an 0805 bipolar SMD capacitor.

[venice1200]

I got the boards and the CPLD and the other parts solderred. I have checked every conection to the PI, everthing looks fine, but the CPLD can't be programmed.

8/12 bit board detected
...
CPLD  Design: 3-12_BIT_BBC
CPLD Version: c.f

Any idea what can be the problem?

I left the same question at https://github.com/hoglet67/RGBtoHDMI/issues/379#issue-2279614608

Full log attached. 2024-05-05_Serial_Log.txt

[solarmon]

Hi,

Which RGBtoHDMI board did you build?

Check that non of the CPLD chip pins are shorted or have dry connections. Also check the resistors and caps are OK and connected to where they should be.

[venice1200]

I built a Denise Adapter v1.1.

I have already checked the whole board as good as possible.

[solarmon]

Which CPLD chip are you using - what is the exact part number and where did you get it from?

[IanSB]

@solarmon

The CPLD is already programmed with some other firmware. The fix on a normal CPLD board is to cut JP1, JP2 & JP4 for first programming and then remake them. Are those jumpers present on your board?

[solarmon]

@IanSB

Unfortunately, there are no such jumpers on my board design - so those tracks will need to be physically cut.

[venice1200]

I am using a XC9572XL VQFP44.

TCK (44), TMS (6) and TDI (7) are connected to a dedicated PinHeader on the board together with the pins 11,10 and 9.

@IanSB maybe we can drive the pins up or down for reprogramming? Is this enough or do we need a physical disconnect?

I think i will carefully try to lift the Pins up.

[solarmon]

For my own future reference - details of the solder jumpers (bridged) and what pins/signals they are for:

JP1 = GPI00 = TDI JP2 = GPI020 = TCK JP4 = GPI01 = TMS

These don't currently exist on any of my RGBtoHDMI board designs.

[venice1200]

I think the Pins which needs to be disconnected are TCK (44), TMS (6) and TDI (7). Not the other three pins.

Found here https://raw.githack.com/hoglet67/RGBtoHDMI/master/Kicad_6Bit/v4/rgb-to-hdmi.pdf

Please correct me if i am wrong.

[IanSB]

@venice1200 @solarmon

The pins that have to be disconnected are CLKEN, SPDATA and SPCLK which are Pins 6, 7 and 44 of the CPLD. You have to cut the tracks going to those pins without breaking the connection between the GPIOs and TMS, TDI and TCK which are pins 10, 9 and 11 of the CPLD. Depending on the layout, this might not be easy as the tracks might be under the CPLD or cutting them also disconnects the GPIOS from the TMS, TDI and TCK pins. The other option would be to temporarily desolder and bend up CPLD pins 6, 7 and 44.

[IanSB]

@solarmon I suggest you add those jumpers to any future revisions of your boards. Any reason you didn't include them? The jumpers were originally added when CPLD programming was added to the project in case users accidentally programmed the Atom firmware which has the same effect but it has been useful for coping with recycled CPLDs

I have updated the wiki to cover this in more detail including how to use the 'Delete_This_File_To_Erase_CPLD.txt' feature:
https://github.com/IanSB/RGBtoHDMI/wiki/Troubleshooting

This is likely the cause of the problem with this issue too: https://github.com/solarmon/RGBtoHDMI/issues/6

BTW can you give the latest Alpha 65G a test to see if it works with your monitor(s). It contains a HDMI audio output driver but no audio input yet! https://github.com/IanSB/RGBtoHDMI/issues/29#issuecomment-2099613155

[venice1200]

We will see...

[solarmon]

@solarmon I suggest you add those jumpers to any future revisions of your boards. Any reason you didn't include them? The jumpers were originally added when CPLD programming was added to the project in case users accidentally programmed the Atom firmware which has the same effect but it has been useful for coping with recycled CPLDs

My RGBtoHDMI spinoffs were original based on the c0pperdragon and LinuxJedi designs, which didn't have these jumpers. And this is the first I've heard of this specific issue.

BTW can you give the latest Alpha 65G a test to see if it works with your monitor(s). It contains a HDMI audio output driver but no audio input yet! IanSB/RGBtoHDMI#29 (comment)

Ooh, that is interesting! I will definitely try it and will report back on that ticket.

[venice1200]

Success...

Next Step is testing with the Amiga.

Many Thx @IanSB

[IanSB]

@venice1200 That's great

@solarmon

And this is the first I've heard of this specific issue.

It seems to be getting more common, as you can see from the above photo I added a message about it to the latest release although that doesn't help so much if you just get a blank screen and don't know about the three buttons or the delete file.

One other thing that just occurred to me: There was originally a jumper JP3 which isolated the fourth programming line TDO but the additional CPLD pin it was connected to was re-used for something else and TDO is connected straight to GPIO 24 on the current revision. However GPIO24 is now also used for the FFOSD overlay so you need to make sure that is disconnected when programming the CPLD.

[venice1200]

FFOSD Overlay?

Is this different to this project here?

I built this board especially because of the FF-OSD Feature in combination with the BluePil.

[solarmon]

FFOSD Overlay?

Is this different to this project here?

I built this board especially because of the FF-OSD Feature in combination with the BluePil.

Yes, this RGBtoHDMI board integrates with FF-OSD and this overlay connection is basically how FF-OSD feeds it's OSD menu to the Pi to be put into the HDMI display.

[IanSB]

@venice1200 @solarmon

I just remembered that the blue pill signal should be connected via a 1K resistor which seems to already be in your design in which case there is no need to disconnect it as that protects against the conflict.

BTW there is support for some ECS modes in the most recent stable release but I've not had any feedback on that. It should auto switch to productivity mode but the 640 and 1280 15Khz modes have to be selected manually by changing the "timing set" option in the main menu (This option is only visible when an ECS profile is selected). This can also be switched by toggling SW3 if fitted. (They both have the same timing so I can't detect which is in use.)

[venice1200]

Hi, finally i added all your RGBtoHDMI Boards to my Amiga 500 6A and programmed the BluePil with the original Hex from keirf (for the moment). I am using RGBtoHDMI v20240213.

I closed the JP1 Jumper at the BluePil Board (without this the OLED is no longer working).

I checked the BluePil's config using a serial connection.

RX to RXTX to TX

** FF OSD v1.9 **
** Keir Fraser <keir.xen@gmail.com>
** https://github.com/keirf/FF_OSD

Config corrupt: Resetting to Factory Defaults

Current config:
 Sync Polarity: Low
 Pixel Timing: 15kHz
 Display Height: Normal
 Display Output: PB15/SPI2
 Display Enable: None
 H.Off: 42
 V.Off: 50
 Rows: 2
 Columns: 16-40

Keys:
 Space: Select
 O: Down
 P: Up
Sync lost

I checked if the the FF OSD is enabled at the RGBtoHDMI Menu.

But I get no OSD shown.

Question, do I need the green line from the BluePil Board to the Amiga to get the OSD shown?

My understanding is that I don't need this green line as I only use the PI's HDMI Output and the PI get the OSD Data directly from the BluePil through the connector between the RGBtoHDMI Board and the BluePil Board (PI's GPIO24??).

Do I miss something?

[venice1200]

I have tried with PA15 Low enabled as well but no success.

** FF OSD v1.9 **
** Keir Fraser <keir.xen@gmail.com>
** https://github.com/keirf/FF_OSD

Current config:
 Sync Polarity: Low
 Pixel Timing: 15kHz
 Display Height: Normal
 Display Output: PB15/SPI2
 Display Enable: PA15 Act.LOW
 H.Off: 42
 V.Off: 50
 Rows: 2
 Columns: 16-40

Keys:
 Space: Select
 O: Down
 P: Up
Sync lost

Do I maybe need Sync from the Amiga to BluePil-PCB CN1/Pin1 and/or set anything at JP2?

[solarmon]

Hi @venice1200

You shouldn't need the RGB output signal to be connected. However, it is useful to see/check whether FF OSD is actually working on your Bluepill.

[solarmon]

@venice1200

On your FF OSD Adapter board, have you got JP1 jumpered?

[venice1200]

@venice1200

On your FF OSD Adapter board, have you got JP1 jumpered?

Yes.

I will do some more tests this evening. I think it has something to do with sync.

[venice1200]

Got it working! Had to add a jumper at JP2 between sync (middle) and c/h sync.

But the Oled Display shows now artifacts and the OSD chars are wobbeling.

https://github.com/solarmon/RGBtoHDMI/assets/43762187/f85cd49a-4581-460f-b4e8-a341047465d7

[solarmon]

Glad you figured it out.

Unfortunately, that is the best that the FF OSD will look over the HDMI output.

[venice1200]

Many man thanks for your support and all the best!

[IanSB]

@venice1200

The reason it's jittery is that the pixel clock of the blue pill isn't locked to the Amiga pixel clock so it was either that or nothing. In theory you could run the blue pill from an Amiga derived clock which would stop the jittering but so far no-one has looked at that.

[solarmon]

@IanSB

Would that be a software or hardware thing, or both - to get the Blue Pill to use the Amiga clock?

[venice1200]

Additionally I get problems reading data from the gotek.

Data are not correctly loaded each time. If this happens the screen shows one of the below system messages and the gotek is mostly sent to the eject menu.

If i remove the bluepil board it works fine again.

It can be my installation, i need to test more.

I am using flash floppy 3.42 with an Artery AT32F435 gotek drive.

[solarmon]

@venice1200

I can't see how the Bluepill with FF OSD software could interfere with the FF on the Gotek reading ADF files.

The only connection between the Bluepill and Gotek should be the GND, 3.3V, SCL and SDA lines for I2C communications.

If it is causing FF on the Gotek to eject the ADF image then that might suggest that keyboard binding integration part is possibly interfering with it - so check the KB_CLOCK anf KB_DATA connections, and make sure you use a FF OSD firmware that supports the keyboard integration.

[venice1200]

The Keyboard integration works fine for me, no problems here.

I can't tell you what causes this.

The only thing i know is that it works (for me) only without the bluepil board connected but let me a few more things.

Do you have a running OSD integration in use actually?

[venice1200]

I have changed the display to another one, no change. If I use the OSD as the only i2c device I have these problems as well. Issue opened at FlashFloppy Github: https://github.com/keirf/flashfloppy/issues/913

[solarmon]

@IanSB

When cutting the JP1, JP2 and JP4 signals does this have to be done at the CPLD pin end, or can it be done at the Raspberry Pi pins end?

For example if JP1 signal is cut at the Raspberry Pi end then it will not be pulled down to ground and will be floating - does this matter?

[IanSB]

@solarmon

At the CPLD end. The three Pi pins are connected to three of the CPLD programming pins and also connected to three general purpose CPLD pins.

Cutting the jumpers isolates the connection to the three general purpose CPLD pins while leaving the Pi pins connected to the three CPLD programming pins so that the CPLD can still be programmed. If you isolate at the Pi end they won't be connected to anything and you won't be able to program the CPLD.

[solarmon]

@IanSB

OK - so it's not jumpers for the TDI, TCK and TMS pins on the CPLD pins themselves, but for the other GPIO that it shares connectivity with.

Previously, I had referenced this:

JP1 = GPI00 = TDI JP2 = GPI020 = TCK JP4 = GPI01 = TMS

But I now know it should really be for these pins (at least for the XC9572XL PLCC chip that I'm targeting):

JP1 = GPI00 = SPDATA (13) JP2 = GPI020 = SPCLK (6) JP4 = GPI01 = CLKEN (12)

Thank you

[venice1200]

From my point of view we can close the issue, or not?