Archives

iCode retro gaming USB adapters get a major upgrade with the release of its latest update, iCode Firmware 9, on Sunday, March 5th. This version brings a lot of new features, which should delight fans of retro video games!

On the hardware side, Firmware 9 is now compatible with the iCode USB models including the UNO, DUO, and QUAD. There are different Firmware 9 downloads specific to each hardware model and revision.

Among the most important new features, version 9 of firmware introduces a new menu navigation system to control all aspects of the device. Once configured, the device remembers all the changes and the last mode of operation, and it will return to the exact state even after a power cycle. This allows the device to be imbedded into arcade cabinets without having to have regular access to the device’s controls.

There has also been a variety of optimizations done which now deliver ultra-low latency play including use of paddles and trackballs.

Below is the list of changes for the release since the prior major release 8.

• Plus editions now support Sega Genesis 3 button and 6 button Controllers. Also supports Start and Mode buttons. Must set settings menu “Console” to Genesis to activate. For Quad, H12 required. For some Duo Plus & Plus Pro H10 and below, special hardware mod may be needed. See iCode Community forums for details.
• Device now remembers the mode you were in, even after a power cycle.
• You can now see mode you are in even if display activity is turned off.
• Device now remembers if your display was off even after a power cycle.
• Optimized trackball and paddle mouse operation to provide much smother control. Keep display off for best experience when using mouse mode.
• Device turns display always off when in trackball mode for optimized smooth trackball operation, unless you specifically turn on after in trackball mode.
• Device no longer switches back to mode 1 when you access the menu system
• When you switch target of where joystick or paddles to be reported to, system now correctly clears all gamepad values from prior target
• Fixed buttons on paddles 3 and 4 on port 2 as they were reversed
• Optimized auto paddle detection
• Optimized screen display
• Optimized Paddle auto calibration
• Support for iCode Quad adapters
• Full and Half duplex Paddle Modes
• Added ColecoVision mode for Plus editions
• New settings for paddle detection mode. OFF setting is useful for ColecoVision controllers
• Added Keyboard on/off mode for Plus editions
• Added compatibility with most recent update of MiSTer Atari 7800 core which changed paddle buttons. In MiSTer mode, Paddle buttons now register as button 3 which works correctly as fire button on Mister. In regular mode, paddle buttons on dual paddles connected to a single port will continue to register as button 0 and 1.
• Fixed bug with mapping and display of buttons 8 through 32
• Swapped default button maps for buttons 0 and 1. Red is now button 0, and Green is button 1 by default.
• Revamped entire settings menu. You now have menus for paddles settings, main menu, and other settings.
• Moved mister mode toggle to other settings menu
• Removed mode 2 and common from UNO Devices
• Improved auto-paddle detection when in MiSTer mode. Pressing yellow button.
• Added status T indicator on display when in Mister mode
• Fixed display not showing all inputs correctly after auto paddle updates
• Fixed port 2 to report correct paddles order for dual paddles on the port.
• In mouse mode, paddle buttons now correctly report to as mouse buttons.
• When in mouse mode, paddles and trackballs now correctly only report as mouse and not gamepads
• Added ability to set destination target as left / right or hat switch for Joystick and paddles data
• Moved default paddles data to be reported as right hand stick instead of left to avoid conflict with joystick stick data which defaults to left hand.
• Added developer menu that allows paddle data views. paddle sensor control, and more.
• Added factory reset to developer menu

Configuring RetroArch Stella 2014 core or Stella desktop emulators to work properly with Atari Paddles can be quite confusing. This guide will help you quickly configure both emulators iCode Duo retro adapters. I recommend Desktop Stella as it will be more responsive and easier to configure.

Stella (Desktop) Configuration

Coming Soon.

RetroArch Configuration

RetroArch has multiple cores that can emulate the Atari 2600. If you want to play paddle games, only the Stella 2014 core will work for you because its the only core that supports absolute positioning that is needed for paddle games. This feature was added to Stella 2014 core starting with version 3.9.3. Here is how you can load the right core and make sure you have the correct version:

1. From the main menu, select Load Core option.
2. Select “Atari -2600 (Stella 2104)”. If this is not present, you can use the “Download a Core” option to get it.
3. Once the core is loaded, you will see it loaded in the bottom left corner of the screen with the version shown. If your version is lower than 3.9.3 you will have to use the Online Updater option from the main menu to download the current version.

Now that your core is loaded, lets make sure RetroArch sees your iCode Duo device and is setup properly.

1. Connect your paddles and turn on the iCode device. Move your paddles fully to right, then full left, then move them to center. This calabrates your paddles on the device.
2. On RetroArch, go to the Main Menu and on the left meu navigation, select Settings and then select Input menu option in the main screen.
3. Scroll down and select the menu option named “Port 1 Controls”
4. Make sure your Device index is set to the iCode device First gamepad. Also Analog to digital must be set to None as shown.
5. Press enter on B Button and system will wait for you to press the paddle 1 button. This should set the B button value to 0.
6. Go to the Select Button menu item and press enter. When system waits, press the yellow button on the iCode device. If you have the wireless Duo , this will set the value to 3.
7. next is Start, map it to White button.
8. Next is Right Analog X+, Spin paddle 1 clock wise
9. Next is Right Analog X-, Spin paddle 1 counter clock wise
10. Next is Right Analog Y+, Spin paddle 2 clock wise
11. Next is Right Analog Y-, Spin paddle 2 counter clock wise
12. X button to Blue button on the iCode Device
13. White you are still in this area, turn off the iCode device and connect the Joysticks and then turn the device back on so its in Joystick mode.
14. Now map D-Pad Up, Down, Left, Right to each of the 4 directions
15. Select “Save Controller Profile” near the top.

Flashing and Booting from an EMMC module on an Odroid XU4 can be tricky. This is because you need a bootloader placed on a hidden Partition of the eMMC memory module. When you clean or flash an EMMC module with normal tools like Etcher or Rufus, you might delete the hidden partition that had the bootloader and the XU4 will simply not boot from your image even if the image you flashed is bootable.

While there are recovery images you can download that have the bootloader needed on it, most images you flash after that will still not contain the bootloader and you would be back to square 1.

The best was found to create a properly bootable EMMC is as follows:

1. If your EMMC module does not boot, its best to first do a recovery process as described on https://wiki.odroid.com/accessory/emmc/recovery_xu4, then see if your EMMC boots to android. You might be able to skip this step 1 but its still recommended. Then go to step 2.
2. Flash the image your want to boot from on to your EMMC module and see if it boots. if it does then you are set. if not, go to step 3.
3. Flash the image your want to boot from on BOTH an SD card and your EMMC module.
4. With the XU4 off and switch set to boot from SD, insert both them flashed EMMC and SD card on your XU4
5. Turn on your XU4 and let it boot from SD
6. SSH into the XU4 or get to a terminal window on it and login
7. At the prompt type: ls /dev/mmc* and hit enter
8. Your will see all the partitions on both the SD and the EMMC device. Both will start with mmc so don’t get confused by that. Almost always, your EMMC module are the mmc words that have blk0 and blkboot0 in them and your SD card will be the other one, probably the ones that have blk1 or blk2 in the name. In the Batocera environment I was testing, my SD card happens to be the one with blk2 in them. This will be important as it will get used in steps below

What we are going to do now is use the linux dd command to copy the boot partition from your SD card to the appropriate area on the EMMC. Your EMMC device we want to write to is typically mmcblk0boot0 and it will be protected. So we first have to unlock it, then use the dd command as follows:

1. Type echo 0 > /sys/block/mmcblk0boot0/force_ro and hit enter. This will unlock and give us access to the partition.
2. Now type dd if=/dev/mmcblk2 of=/dev/mmcblkboot0 bs=512 skip=1 seek=0 count=16381

The last step might take a few seconds or minute. Once you see no more activity, you can now lock the partition again.

1. Type echo 1 > /sys/block/mmcblk0boot0/force_ro and hit enter.

Now shutdown your XU4 and remove the SD card and flip the switch to boot from your EMMC!

This is what worked for me. Here is a screenshot of my session after step 4 of the first part.

Analog to Digital conversion with RC circuit in microcontroller projects.

If you were to take the knob or dial off of an electronic device, you might find a potentiometer underneath it.    A potentiometer is a variable resistor, and the kind shown below changes resistance as the knob turns. This particular one has a resistance range from 0 ohms to 10,000 ohms.

RC circuit use combination of a resistor (R) and a capacitor (C) to control charge rate of a capacitor. One of the applications of RC circuits is to use a potentiometer as the resistor (R) and this allows you to control how it takes to charge the capacitor (C). The higher the resistance, the longer it takes for the capacitor to charge.

These two components together form an RC (resistor-capacitor) circuit.  When the switch is turned on, the capacitor begins to charge. The charge rate always follows the following standard RC charging curve.

The amount of time it takes for charging the capacitor to 63.2% can be calculated using the formula T = R*C in seconds. So for above T = R*C = 100k x 22uF = 2.2 Seconds to get to the 1T line.

TTL circuits on micro controllers typically have a threshold voltage of 1.6V before they recognize an input as HIGH.

So what you can do is connect a digital port to the + side of the capacitor (Vc). Set the port to INPUT mode and force it to LOW. This will discharge the capacitor and immediately the capacitor will begin to charge. Now in a tight loop, just count up from zero and read the PIN till it goas high.

pinMode(pinVC, INPUT);  

digitalWrite(A0, LOW);   // this will discharge the capacitor

Int i=0; While (! digitalread(PinVC)) { i++; }

The value of i will vary based on how you turn the knob!

To calculate how long it takes for the capacitor to get to a certain voltage you can use the following: t = -ln((Vs-Vc)/Vs)R*C

ln mean natural log or log base e, Vs is the supply voltage, and Vc is the voltage across capacitor

For example, an Atari Paddle uses a 1 Meg ohm resistor. Say we wanted to read the paddles at least 30 times per second using a 5v microcontroller board. What value of capacitor should we use? If you use a 1 Meg Ohm Pot and a 5v board with 1.6 volts being the TTL threshold voltage, a capacitor of 0.068uF, it will take 26.23ms for the pin to go high at the max pot value. – ln((5-1.6)/5)*1000000*0.000000068 = 26.23ms This means you can read it ~38 times per second (1000 / 26.23). Since NTSC frame rate is about 30 frames per second, this will allow you to read it at least once per frame! This is probably why Atari hardware uses a 0.068uF capacitor in its RC circuit

Many micro-controller projects use lithium ion (li-ion) batteries and we needs a simple way to display the state of charge (SoC) which is how much battery we have left. This is typically displayed on the screen as a partially filled battery icon and optionally a percentage indicator next to it.

There are however several challenges we need to address to be able to display reasonably accurate information on the screen. We will focus on the three primary items below which does the job with very little effort.

• How o we measure the battery level?
• How does the batteries characteristics taken into account?
• How do we quickly draw this visually without having to worry about bitmaps that can be slow and harder to work with?

Measuring Battery Level

Measuring of the battery level can be accomplished by by using one of the micro-controllers input ports set up as an analog to digital converter (ADC). The main thing is to account for max voltage on the input pins compared to your batteries max voltage. For example, most li-ion batteries produce around 4.2 volts when they are fully charged so connecting them to a 3.3 volt operated micro-controller input pin will either burn out the pin or the input will read it the same level so you will not be able to see the difference between 4.2V and 3.3V.

The solution is to use two resistor as voltage dividers to reduce the voltage slightly so the maximum voltage to the pin is 0.75X of the micro-controllers rating. So say we we have a Li-on battery at 4.2V and running a ESP32 micro-controller at 3.3V, we want the maximum voltage to the Analog Input pin to be: 3.3V x 0.75 = 2.5 Volts

Using ohms law and this example calculator, we find out the values we need for the two resistors we need as shown:

So all we need to do is connect our Li-Ion battery to the 2 resistors and feed the divided voltage to the input pin of our micro-controller and we will be within safe specs of the ESP32 and we will get much more accurate readings, especially on the higher end.

For the lower end, we need to know approximately the minimum voltage the micro-controller will still operate before it just gives up and shuts down. Looking at the ESP32s data sheet for operating range it says it can operate with minimum source voltage of 2.3 volts.

At this low end right before they system gives up, what is the voltage applied to our input pin through our divider? Using the same formula above we get 1.37 volts.

So what will the ESP 32 input pin measure when it sees 2.5V on the high end and 1.37V on the low end? This can vary depending on how many bits the ADC of the micro-controller has. The ESP32 has 12-bit ADCs which means it can report 4096 different levels on the ADC pin. If you assume 4096 = 3.3V and 0 is 0V, this means our range of 1.37 to 2.5v should give us values between 1700 and 3100. In practice, its not 1:1 like this as the ADC performs differently in higher and lower ends and amount of load on battery can effect it, so you may need to measure the full charge level for your project. For now we can use these and I will show you how to adjust for load later in the article. This brings the next challenge as follows.

Li-ion batteries do not discharge linearly!

We need to understand how a Li-Ion batteries discharge over time because if we simply take the voltage we measure and show it as a percentage between low and high range, we will not get correct results because the discharge curve for Li-Ion batteries are not linear. Instead the they typically look something like below.

Between full charge (V full) say 4.2V and (V exp) ~3.3v, the discharge rate is rapid. For majority of the operating time, the discharge rate is very low. this is the mid section of the graph above. The higher the battery capacity, the longer this middle cycle is. Finally, when the voltage reaches (Vnom), the discharge rate picks up quickly. If we do not account for this you will see some ugly results on your display.

For example, lets say you have a 500mah battery that lasts about 4 hours in your project and our battery reading range was 3100 at full and 1700 right before it would shut down as described previously:

• First 30 minutes you would see the battery go down from 100% to 80% (readings of 3100 to 2820 )
• Next 3 hours you would see it go from 80% to 60% (reading of 2820 to 2540)
• Then, you would see it drop from from 60% to 0 in last 30 minutes! (reading of 2540 to 1700)

How did I go from 60% to 0 so fast? Sounds familiar 

We can give users a much better experience and account for this in our project by treating each of these 3 phases differently. We can normalize these phases by

1. Mapping the first phase which was originally 100 to 80%, to be instead 100 to 90%.
2. Mapping the second phase which was originally 80 to 60%, to be instead 90%-10%.
3. Mapping the last phase which was originally 60 to 0%, to be instead 10%-0%.

This is how it would look like in code:

    value = analogRead(GPIO_NUM_36);

    if (value >= 3100) bat_percent = 100;
    else if (value >= 2820)    // 90-100% range
      bat_percent = map(value, 2820, 3100, 90, 100);
    else if (value >= 2540)    // 10-90% range
      bat_percent = map(value, 2540, 2820, 10, 90);
    else if (value >= 1700)    // 0-10% range
      bat_percent = map(value, 1700, 2540, 0, 10);
    else bat_percent = 0;

So I tested this in a test project where I used a small screen with an ESP32 connected to a 500mah Li-Ion battery.

Remember I mentioned earlier that load of projects can effect the range I used above which was 3100-1700. So I fully charged the battery and connected to the ESP32 to capture battery levels and saw the high was almost 2700 and they lows before my battery died was 1700 . I decided to graph my batteries discharge curve by checking voltage every second and sending the values via Bluetooth communication to my PC where I could graph the discharge curve using raw levels and the mapped percentages based on adjustments I made. Here are the results:

You can see the true discharge curve in blue and how the modified code below transformed it to the orange much linear percentage over time.

    value = analogRead(GPIO_NUM_36);

    if (value >= 2650) bat_percent = 100;
    else if (value >= 2500)    // 85-100% range
      bat_percent = map(value, 2500, 2650, 85, 100);
    else if (value >= 2100)    // 10-85% range
      bat_percent = map(value, 2100, 2500, 10, 85);
    else if (value >= 1700)    // 0-10% range
      bat_percent = map(value, 1700, 2100, 0, 10);
    else bat_percent = 0;

Drawing the Battery Indicator

Instead of messing with loading bitmaps which can we a bid difficult to deal with, I found it much easier to just draw 3 of rectangles as follows:

You can then easily update the last filled rectangle with the current percentage adjusted for size of the rectangle. For example if the rectangle is 20 in width, you would just divide your battery percentage by 5 to get the width of the filled rectangle. This is what it looks like on my sample project. You can tell I missed the thickness of my first rectangle 

Good luck and make sure to leave comments and questions!

I recently built a Raspberry Pi 4 unit with Retro Pi and Emulation Station to check out its performance for retro gaming and when I got the Atari 800 emulation to work, it brought back many childhood memories of my first real PC. Games like Star Raiders and M.U.L.E. were well ahead of their time and to get the true experience, they have to be played with real Atari joysticks!

Star Raiders and M.U.L.E. on Atari 800

For past few months, I spent a good amount of time programming micro-controllers for IoT devices for my work projects and I thought about the possibility of using a micro-controllers to adapt Atari Joysticks to a PC so they can be seen as regular PC Gamepads.

I looked online and found some classic joysticks that came with the Atari Game Console Flashback unit for $15 on eBay and decided to give it a shot.

I checked out the Pin Diagrams for the joysticks and it seemed simple enough as they are basically 5 switches (1 for each direction and 1 fire button). Since I wanted at least 2 Joysticks connected for multiplayer games, I needed at least 10 IO ports to connect the 5 switches of each joystick.

I decided to use an Arduino Pro Micro controller since it was only $4, had plenty of IO ports, and most importantly it had a USB port that can communicate with PCs as a HID device.

I created a circuit design on EasyEDA so I could later order a PC baord but initially I created a prototype using PCS Prototype Boards you can get from Amazon or Aliexpress for pennies.

I ordered a few DB9 male connectors where the I could plug the joysticks into and put the parts on the board and soldered the connections.

I wrote some code in Arduino and after several attempts and figuring out custom board files for naming, finally had success. You can get the Dual joystick code from here.

If you are wondering how the animation below shows 5 button working, its not related to directions.. keep reading as there are multi button Atari joysticks.

Next. I decided to make an enclosure for it using my 3D printer! I drew it up in Fusion 360 and printed the top and bottom and made quite a tight fit.

I was finished with first working prototype. Next I refined it to a smaller version with a professionally made circuit board so its more reliable, no jumper wires, and less soldering. So its basically done.

Download STL files here.

But wait, M.U.L.E. is best with 4 players and I had to find a way to get it done so I could play with my nephews. One way was just to build another one taking up 2 USB ports and double the parts, and another was to challenge myself to do a 4 player design with a single USB port. So I did both 

For the 4 port unit, I needed more ports so I decided to use a I2C I/O extender that can extend 2 GPIO pins to 16 using serial communication. I also wanted to support the modified Joysticks that have the extra Start, Select, Menu, and a few more button. Here is the circuit diagram and the outcome.

It worked great and I can tell you we had an amazing time playing 4 player M.U.L.E. ! So give it a shot and make one. You can get the code here.

If you rather just buy one from me, you can get it below. All net proceeds go to charity.

• Sale!Product On Sale