Posts made by aTg

@ian57 Any new? I'm working on the others parts of the circuit but the buttons are the most important.

While I'm waiting for @ian57 to look at the problem on the repo of moving the pins, I'm going to continue with the sound section.

After investigating different options and see which speakers have the most arcade machines that are usually 8 Ohms and between 10 or 15w I think there are two clear options to choose from.

We have the TDA2003 that is a mono amplifier of 10w and option number two is the TDA2005 which is a stereo amplifier of 10w per channel and can be configured in bridging mode getting 20w mono.

The interesting thing about the second option would be in the case of MVS machines that had a stereo wiring in the jamma, could change from 20w mono to stereo 10w + 10w playing with some jumpers and have compatibility with jamma and mvs.

I'm going to prototype two amplifiers and try to configure them with the minimum number of components.

One thing that f**k me a lot is that the encapsulates are not SMD and they should be soldered by hand, they are also upright and they are very ugly, it has occurred to me to knock them down and use the PCB as a heatsink, later also It could be placed on the back of the PCB to save space.

What do you think is more interesting in terms of power? Maybe 20w is too much? The pc2jamma adapter works with a TDA2003.

@substring said in [PROJECT] JAMMA-Pi:

@atg i2cdetect ?

I thing i2cdetect don't detect nothing, I got this message:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                

I follow the steps from the readme, my setup on the addresses of the chips in A0 A1 A2 are 000 in one and 100 in the other, I try only with one chip on 000 and the same result, when a run modprobe mk_arcade_joystick_rpi map=1,0x20 the i2c port is enabled on pin 2 or 3 and not on 10, 11 and lose the sincronism of the image.

This can be made because the driver acces to the ports by harware and don't use the DeviceTreeOverlays.

Well I'm back again with the project, following the recomendations of @Substring I change the prototype to allow one MCP23017 conected by the port i2c to talk with Recalbox, I add to the circuit one RGB-Pi PCB for the video output and here is the little frankenstein.

I use the overlay i2c-gpio to move the pins from 2, 3 to 10 , 11

dtparam=i2c_arm=on
dtoverlay=i2c-gpio,i2c_gpio_sda=10,i2c_gpio_scl=11

Now is the moment to enable the option en recalbox.conf, I thing the work is made by mk_arcade_joystick_rpi included but I read in the repo "The branch hotkeybtn now support one more button per player in place of MCP23017 support" and the scheme don't show any pin for i2c, this would be say not longuer avaible use i2c for controllers?

I try to activate on recalbox.conf

 # ------------ D2 - GPIO Controllers ------------ #
## GPIO Controllers
## enable controllers on GPIO with mk_arcarde_joystick_rpi (0,1)
controllers.gpio.enabled=1
## mk_gpio arguments, map=1 for one controller, map=1,2 for 2 (map=1,map=1,2)
controllers.gpio.args=map=1

But the program interfiring with the video output, and I don see what can be user to talk by i2c...

I need a little help from the Devs to talk with Recalbox by i2c and pins 10 & 11, any help is much apreciated!

@llegoff I'm going to discard the SPI prorotype and make another based on i2c because I think with this bus is possible move all the pins.

Thanks for your participation.

@substring Can I offer a bounty to contirbute to the Recalbox project?

This is a preview of the final aspect of the adapter.

The idea is reach a low-cost product for 30€ without any extra cables needed.

@substring Ok, it seems a good way, the only important point is that the integration of the SPI port allows to move the CS pin in any GPIO, this can be done, there are several examples but I do not know how it would have to be done in RB, this point Is the key part of the whole project.

@substring Aaa ok I2C not I2S, I need GPIO3 for h_sync an 5 for one bit of blue.

The DPI is not negociable.
https://www.raspberrypi.org/documentation/hardware/raspberrypi/dpi/README.md

I study all the option for a long time, the only way is use SPI and move CS.

Now before the launch of the 4.1 not is possible compile ControlBlockService2 into the release?

These drivers give support for JAMMA-Pi and ControlBlock at the same time.

@substring I2S use these pinout right?

GPIO 18 (Pin12) is BITCLOCK;
GPIO 19 (Pin 35) is LRCLOCK;
GPIO 20 (Pin 38) is DATA IN;
GPIO 21 (Pin 40) is DATA OUT; (probably not needed for buttons)

These can be compatible with the DPI output for RGB in mode 4 but interfering with the audio PWM output at GPIO19 or 18.
RB can handle MCP23S17 by this port? I see HiFiBerry use these same port, I don't know if is possible use two different functions by the same port, and if is possible you need a DAC and more hardware for the sound and sure you need use the GPIO21 for data out and these collide with the DPI

After working with @ironic on the RGB-Pi project for Recalbox now I'm starting a bigger challenge, to create a jamma adapter for RPi fully integrated with amplified sound, buttons, rgb and power all through the gpio without any additional cable.

I have some progress made, for the video we use mode 3 of the DPI output of the Pi, this leaves us free the outputs GPIO9, 10 and 11 where we will connect two MCP23S17 with which we will introduce the buttons, a pin is needed for the CE Or CS (ChipSelect) at the moment use pin 8 that currently belongs to a bit of the RGB blue channel, later we must move this CS to another pin, it is the only pin with the ability to move and this is the only combination of hardware to do everything through the GPIO and I have been studying it for a long time.

This is the prototype:

Here a little video:
https://www.youtube.com/watch?v=FzMKjC5MNCc

To control the MCP23S17 by the SPI port I am using a ControlBlock2 drivers that are open source, but they are compiled in Raspbian, I need the way to integrate them into Recalbox or control the MCP23S17 by different way, at this point I need a Little collaboration from the Recalbox Devs.

@idarius I do not understand because you have so many problems, with rgb-pi distribution you have snes at 256 perfectly framed and at 60Hz

The black stipe is by the camera.

Interesting news, however recalbox is still not prepared to manage different resolutions per game.

@Substring The maths behind the hdmi_timings will never arrive while the pixelclock remains locked.
It is necessary resize to 1920.

One is RGB-Pi and the other a Megadrive by RGB modified at 60Hz, which is which?

The problem is that we still do not know how exactly the custom hdmi_timings of AdvMAME works to carry it to the other emulators, the Ironic method can be used with all the emulators already.

Does Recalbox plan to introduce these changes officially? Or is it going to have to be another mod?

@ironic but the horizontal resolution needs to adjust to the screen, by default many machines resice the native resolutions to 4:3 format and if you expand horizontal many games to 1920x224 the aspect ratio of the game is not 4:3

In SNES for example I need to put 1778x224 in snes.cfg (using 1920 timing) to view the correct aspect of the game.

The case of CPS3, is inside the list of 224p games but is 384 in the horizontal resolution, this shows incredible ovescan for inportant games like sf2.

I think the solution is a database, based on a one standar resolution and with the resicing parameters for every rom, is a lot of work I know but is the only way.

@ian57 Great, finally try the cable, I think it will not be necessary to generate hdmi_timings, the games are not seen in a correct aspect ratio if we generate the hdmi_timing, for example snes is 256x224 but this is 8:7 aspect ratio and need to rescale to 4:3, with the timing and nothing more the image show with much overscan. So it is better to start from a resolution like 1920x240 and expand it horizontally to 4:3 but keeping the 224 pixels vertical.

I've been testing for a long time and this is definitely the best option because in this way we do two jobs in one, we have a universal timing and at the same time we rescale the games to 4:3

The tests that I am currently doing are 480x300 for fronend and recovery (this is a custom timing the most "HD" posible), default for n64 and 1920x240 for global.videomode.

After each machine has its .cfg with the necessary rescaling and center parameters, the next step is to create .cfg for each game as a temporary solution to see all games in the original aspect.

I'm much more concerned not being able to generate hdmi_timings or see interlaced modes.

@ajefr Is the same as the signal RGB from digital paralel outputs, this generates a squared signal, what is the problem?

Did the original games have analog audio chips? I would say that the audio outputs of game consoles were of worse quality than the output of the RPi