[petrockblog]

we don’t have those changes in our version currently – I need to update our mirror.

[petrockblog]

It is clearly detailed in the setup instructions on the wiki

https://github.com/retropie/RetroPie-Setup/wiki/First-Installation-%28RetroPie-SD-Image-2.6%29

The image is kept as small as possible – if we had it all partitioned for say a 16gb card, you would need to write 16gb to get up and running. We also don’t expand on first boot, as it’s possible users may want to customise their partition setup. It’s a simple process to expand, and Raspbian works in the same way.

[petrockblog]

You are of course welcome to have your system set up as you want. But the default was changed for the reasons above.

[petrockblog]

You have root access anyway, via the pi user which can sudo to root when needed. See https://www.raspberrypi.org/documentation/linux/usage/root.md

I agree with them regarding safety too

You can also run a superuser shell by using sudo su. When running commands as a superuser there is nothing to protect against mistakes that could damage the system. It is like disabling the safety guards on a machine. It makes it easier to access the insides, but the risk of damage is far greater. It is recommended that you only run commands as the superuser when required and to exit a superuser shell when it is no longer needed.

[petrockblog]

The password is disabled as with Raspbian – to avoid risks with people using root for everything. However you are welcome to enable it if you really need it – just login as the pi user and do sudo passwd root to set a password for the root user.

It is a lot safer to use the pi account and just use sudo when you need to however.

[petrockblog]

That’s not what I mean – what I mean is – if using disk games, you can download an action replay / retro replay rom (they are devices that would plug in a real c64 expansion port). They include fast loaders, so if you download a rom, you can virtually “insert” it into the emulator – then save the config – so it will be there next time you launch. Disk games will then load a lot faster.

I also mentioned it here: https://www.petrockblock.com/forums/topic/c64-game-loads-very-slow/#post-94846

[petrockblog]

you can configure the emulator with a turbo load cartridge and you get very nice load times then with good compatibility.

[petrockblog]

cd ~/RetroPie-Setup
sudo ./retropie_setup.sh

and choose the “Supplementary” menu, then choose “Auto-start EmulationStation” and select “Original boot behaviour”

[petrockblog]

This was answered last time you posted about it – why the new thread ?

C64 load times

[petrockblog]

retroarch is not in the system path – you need to tell it where it is

use

/opt/retropie/emulators/retroarch/bin/retroarch

[petrockblog]

To switch the game pad type you would have to switch it in the ControlBlock config file at /etc/controlblockconfig.cfg and run “sudo service controlblockservice restart”.

[petrockblog]

Not currently. Ignore it for now – before we had separate parent folders for samples/artwork, but that looked messy having directories that were not platform directories in the roms folder.

[petrockblog]

I have decreased the delay now and updated the master branch (https://github.com/petrockblog/ControlBlockService/commit/1c14e7f4a35832e21136cd4ddf40ca748557f748). You can Re-install the ControlBlock driver just as described. I have set the delay from 75 ms to 50 ms – this comes with a slightly higher CPU load, but also increases the sampling rate for polling the controller states.

Is it working better for you now?

[petrockblog]

This might be a timing issue with the ControlBlock driver.

Maybe the delay at

https://github.com/petrockblog/ControlBlockService/blob/master/src/controlblock/main.cpp#L72

Should be set to a (much?) smaller value!? You can modify that value and re-run the compilation and installation of the driver.

[petrockblog]

Glad to hear that you found a solution. RetroArch emulators are configured such, e.g., that you can press the start and select buttons at the same time to exit the emulator.

[petrockblog]

@rumbaldo: Looking at your wiring everything seems to be ok. GND and VCC do not need to be swapped. To be sure, I have updated the ControlBlock article and added a diagram that shows the pin out with which I have successfully connected the original SNES controller front with the ControlBlock. You can find the diagram at https://www.petrockblock.com/2014/12/29/controlblock-power-switch-and-io-for-the-raspberry-pi/#Using_SNES_Controllers_with_the_ControlBlock.

Maybe you have a short somewhere?

Also it is important that only a single service uses the I2C port. Also, there were issues with overclocking. I have tested the bug fix as thoroughly as possible, but maybe there is still something wrong. You could try and set the overclocking setting back to “normal”. Also, you could check the functionality of the GPIO expanders by configuring the gamepad type as “arcade”, manually pulling each pin to GND and using the tool “jstest” to see the status changes of the virtual gamepads.

[petrockblog]

It’s forked from mamedev, so is recent – 0.159 currently.

[petrockblog]

no, but I did start work on including it – but it’s not working yet.

[petrockblog]

Currently, the ControlBlock driver does not offer any shortcuts. However, I could add this functionality.

Could you list some shortcuts that might have become “gold standards”?

[petrockblog]

All right – I have just pushed a fix for the issue regarding the broken polling of SNES controllers with “RPi2” overclocking settings: https://github.com/petrockblog/ControlBlockService/commit/05c2e34984a36c2855a571e6570cf48523d9e7be

Polling of the SNES controllers works for all official (=raspi-config) overclocking modes now!

To update the ControlBlock driver you need to follow these steps:

cd ControlBlockService  # change to repository folder
git pull  # update repository to latest version
sudo make uninstallservice  # uninstall ControlBlock service
sudo make uninstall  # uninstall ControlBlock binaries
make  # re-compile ControlBlock driver
sudo make install  # install ControlBlock driver
sudo nano /etc/controlblockservice.cfg  # enable gamepad type "snes" with the text editor
sudo make installservice  # install ControlBlock service

[petrockblog]

Thanks for that hint!

I can reproduce this issue – interestingly, this “only” occurs with “snes” as “gamepadtype”. Gamepadtype “arcade”, e.g., works with the Pi2 overclocking settings. This seems to be a timing issue within the ControlBlock driver and I will try to find a fix for that!

[petrockblog]

[quote=97786]disregard my last two posts. reinstalled retropie and now it works fine! ha, what the hell.
[/quote]
I am glad to hear that!
Could you briefly describe what you did when you “reinstalled retropie”? I think that might help people here.

[petrockblog]

there is a retropie menu folder at the same level as the roms folder (not under the roms folder). It is also shared by default with samba. Call it “something.sh” and drop it in there, and it should work.

[petrockblog]

Yes – the power switch functionality is optional. You can disable it in the configuration file /etc/controlblockconfig.cfg and set

"powerswitch": false

See also https://github.com/petrockblog/ControlBlockService#configuration.

Does this solve your issue?

[petrockblog]

Well, there are no real internal version numbers. 2.6 was just assigned to the image at that time. I would just use the latest code.

[petrockblog]

neither 2.6 and 3.0 come with a full desktop. X is there, but you will only get a terminal if using startx.

in regards to version numbers you are confusing the kernel version with the image version. There is no actual internal version number in retropie – it is constantly moving – we just take a snapshot of where we are occasionally, and label it.

[petrockblog]

can emulate an arm system with qemu – but don’t expect stuff that utilises pi gpu etc to work. I build retropie in an emulated chroot environment with distcc on top –

google chroot pi / qemu pi for links.

[petrockblog]

C64 game loads very slow

[petrockblog]

A single micro USB power supply is sufficient. You use the micro USB socket from the ControlBlock to power the RPi and have the power switch functionality.

[petrockblog]

You get 5V from USB, so you need to to use a 5V LED. Maybe you can replace the LED that comes with the switch, e.g., with an LED like this: http://www.arcadeworlduk.com/products/awuk-5v-10mm-wedge-base-led.html. I have not tried this myself, though.

[petrockblog]

The “official guide” can be found in the lower part of the ControlBlock article at https://www.petrockblock.com/2014/12/29/controlblock-power-switch-and-io-for-the-raspberry-pi/#Software_Setup_and_Configuration.

[petrockblog]

Are you using a CPU overclocking setting? If so, set the clock to default and look if this behavior persists. Then you could go on and try to increase the CPU clock step-by-step. Hope that helps!?

[petrockblog]

Basically, this question could be related as “How can I use different controller configurations with different emulators?”
This is more a question for the advanced RetroPie section – I have moved this topic there.

[petrockblog]

You need to connect the wires as following:

wire 1 o o
wire 2 o o
       o o

The colors and the side do not matter.
A multimeter would be very helpful here to measure the switch state of the switch :-)

Hope that helps!

[petrockblog]

Are you overclocking the RPi? If so, try to set the clock to default and increase the clock step-by-step to see if this is causing the trouble. Always use the justest tool to check if the controls’ behavior is as expected.

[Author]

Posts