KCDN.PL Blog http://blog.kcdn.pl/ Sat, 29 Aug 2020 12:02:50 +0000 en-US hourly 1 https://wordpress.org/?v=5.3.4 https://blog.kcdn.pl/wp-content/uploads/2020/03/favicon.ico KCDN.PL Blog http://blog.kcdn.pl/ 32 32 ATC2 – a new game about air traffic control https://blog.kcdn.pl/atc2-a-new-game-about-air-traffic-control/ Fri, 28 Aug 2020 18:42:12 +0000 https://blog.kcdn.pl/?p=123 Continue reading ]]> I made a new game computer game that can be played in a web browser. It’s a real-time strategy game about controlling airplanes. Click here to play.

This game wasn’t my idea

So, a while ago (9 years to be exact) I wrote a browser game to teach myself JavaScript. It was a remake/re-interpretation of a text mode game “ATC” written by Ed James in 1987. It was about controlling air traffic in a given area. Planes would enter the game board through exits or spawn at airports. Each plane had to be carefully guided to its destination, which could be either an airport or an exit. The player command the planes, so that they would reach their destinations, without crashing into each other. The game was remarkably fun, and can still be played today. If you happen to be on a Debian-like operating system, you can get it by installing the bsdgames package.

The 2011 remake

My 2011 remake was a browser game written in JavaScript, and I based it around the Canvas element, which was a very new thing back then. It followed the original gameplay very closely, while introducing very simple graphics and small quality-of-life improvements. The game was controlled exclusively with keyboard, just like the original.

While I did learn a lot about writing JavaScript while making the game, I was never truly happy with how it turned out. The graphics was plain ugly, with small hard-to-read labels. When two or more planes got on top of each other, it was impossible to know which ones they were and where they were headed. The keyboard input system was very confusing to modern players, who were used to clicking everything with mouse. There was also no visual indication of which plane you were commanding, and if the command was actually accepted. Combine this with lack of tutorial, and the only way to learn this game was to have someone standing over your shoulder explaining the game as you played it. The code itself wasn’t that horrible for someone self-taught, but it didn’t escape from some anti-patterns, which made it difficult to find and fix bugs. Two major bugs remain up to this day: it’s possible for a plane to leave the game area through its southern edge and keep flying until it runs out of gas; it’s also possible for planes named “I” and “l” (capital “i” and lowercase “L” respectively) to both appear on the board at the same time, confusing the players. I attempted to fix the problem twice, both times without success. The game can still be played here.

The 2020 remake

My motivation for re-making this game again was mostly because I really liked the idea (which by the way is attributed entirely to Ed James), and I thought the game deserved a remake that was actually good. Therefore, I decided to spend a couple of days recreating the game from scratch, using modern technology.

The 2020 version features improved graphics with animations, a mouse-controlled interface that’s hopefully easy to understand, and several tutorial scenarios that gradually introduce all gameplay aspects and rules. One very big change is that airplanes actually fly across the board in real-time, rather than making chess-like movements that were characteristic to the original game. As a consequence of this, it’s possible to have many different kinds of airplanes that cruise at different speeds. The game is still based on a square grid, though unlike the original, planes travelling diagonally will take more time to reach the next square than those travelling horizontally or vertically.

Another big thing is a white line that predicts the path that an airplane will take. It’s only displayed for the currently selected airplane and goes through all squares the plane will travel through in the future. It’s also used for issuing delayed commands for planes passing over radio beacons and airfields. The line makes it easy to see whether a diagonally-travelling plane is actually lined up with its exit or not. The line is so useful in fact, that it made me realize some things about the default map from the original game that I hadn’t known about, like for example that airport A0 is located diagonally from beacon B0. Its most important advantage however, is that it shows you immediately how your commands affect a plane’s path.

I realize of course, that to make it a true product of 2020, I should’ve made it into a mobile game with touchscreen controls. I chose not to do so because a) I’m not very fond of mobile games, and b) real-time strategy games such as this one work very poorly on small screens with touch controls. Therefore, I envisioned this game to be played exclusively on a computer with mouse. Of course it’s theoretically possible to load it on a mobile browser, but I imagine the experience would be nothing but frustrating.

The game is written in TypeScript, which is compiled and packed to a minified JavaScript file with webpack. Other than some webpack loaders for development, I did not use any libraries or frameworks, so the game is very light-weight. The minified .js file currently sits at 127KiB, and can likely be reduced further by cleaning up the SVG assets.

Enjoy playing.

Welcome to KCDN.PL blog https://blog.kcdn.pl/welcome-to-kcdn-pl-blog/ Tue, 18 Aug 2020 12:06:21 +0000 https://blog.kcdn.pl/?p=117 This blog contains development updates for All These Worlds (ATW), a space exploration and combat computer game, and also various articles about electronics.

ATW News 2020-08-18 https://blog.kcdn.pl/atw-news-2020-08-18/ Mon, 17 Aug 2020 23:25:38 +0000 https://blog.kcdn.pl/?p=107 Continue reading ]]>

Progress is slow but steady.

A map with RTS-like controls for allied ships is the main new feature. Making sure that various things work well with map (for example the nebula from Exploration Demo) is taking more time than anticipated.

I made a new “Command Demo” to showcase the map feature. It has the player use a small fleet to protect several unarmed ships that explore a star system. I’m not happy with how it turned out gameplay-wise, and now I’m considering extending the Starship Battle Demo with tactical elements instead.

Another big thing going on is integration with a graphics toolkit for greatly improved visuals of planets and the outer space. Also, some better music.

I’d like to make a new gameplay video soon, as the 2019 one is becoming quite outdated.

Missiles are next in the queue. I’m looking forward to making some highly destructive warp-capable torpedoes. These should be effective against very heavy and cumbersome ships, and maybe also some of the lighter ships that are caught with their warp power recharging.

That’s it for now. I’ll try to go for a less-than-one-year interval for future updates.

How I broke and fixed a Woodpecker CNC control module https://blog.kcdn.pl/how-i-broke-and-fixed-a-woodpecker-cnc-board/ Thu, 19 Mar 2020 21:14:42 +0000 https://blog.kcdn.pl/?p=38 Continue reading ]]> “Woodpecker” is a controller circuit board for some small and cheap CNC milling machines that one can order from China. These machines can be used, among others, for making DIY printed circuit boards.

“…but then I noticed a stack of smoke coming up from behind the screen. I stood up and looked at the mill. The probe cable was melting before my eyes. I rushed screaming to the power switch…”

While playing around with mine, I managed to damage it by accidentally applying high voltage to the “probe” terminal of the module. This caused the module’s microcontroller chip, an ATmega 328P to malfunction, and no longer respond to GRBL commands, effectively turning the machine into quite an expensive paperweight. Thankfully, I was able to replace the broken chip, and even program the replacement with a more recent version of GRBL firmware.

The trouble started when I first attempted to use a probe to generate a height-map of a copper laminate board. When making circuit boards, we want the mill to remove the ultra-thin layer of copper in certain places, while leaving intact as much of the underlying laminate as possible. Moreover, the board is never laid exactly level on the machine’s working area because of clamps holding it down. The difference in height sometimes can’t be seen with naked eye, but is guaranteed to be much larger than the thickness of the layer of copper that we want to remove.

If the height problem is not dealt with, the machine can simply punch through the board and keep going.

The height-map approach solves this problem by having the machine take very exact height measurements at multiple points across the board. During a single measurement, the machine’s head is descending very slowly until it touches the board. Then the software saves the exact height at which contact took place, and then the machine makes another such measurement in another place.

How does the machine tell that its tool is touching the board? The most common way is to attach electrodes to the tool and to the board itself. If the tool is touching the board, an electrical connection is made between the electrodes. This can be used to tell the machine that it’s reached the board. The woodpecker control module supports probing in a very simple way: one electrode is attached to the ground terminal, and the other one to the A5 pin on the module.

There’s a terrible catch however, and if unlike me you take the time to actually read the instructions, you’ll notice they want you to disconnect the spindle motor before attaching the probe electrodes. Why? Well, the spindle motor is connected in such a way that the positive terminal of its power line is connected to the motor’s casing. This means that the motor, its shaft, and the tool itself (!) has a potential difference of some +12V with respect to the module’s ground.

Now, what happens if you attach the probe in such conditions? The first thing that I noticed was that the spindle motor started spinning as soon as the alligator clip touched the tool. Thinking it was some software problem, I walked over to the computer intending to stop the spindle. I thought it was odd that bCNC claimed that the spindle was stationary, but then I noticed a stack of smoke coming up from behind the screen. I stood up and looked at the mill. The probe cable was melting before my eyes. I rushed screaming to the power switch. After ventilating the room, I ended up with melted isolation on the probe wires, and a non-responding control module.

What happened electrically was that the high voltage from the tool found its way to the ground through the alligator clip and the cable leading to the A5 pin on the control module, and finally through the microcontoller. The flow of current caused the motor to spin, even though it was not commanded to. Poor ATmega was not designed to have such high currents passing through it, so it must’ve broken down almost instantly. The current was also too high for the probe cable, which ran so hot the isolation was melting.

Lesson learned: Always check the voltage before making an arbitrary connection in a circuit you don’t know very well.

The good news was that the stepper motors, the spindle, and other parts of the control module appeared to be undamaged. So, I thought, perhaps the module could be saved by just replacing the ATmega? I’d have to program it though, but the Woodpecker is running GRBL, which is free software, and I found a discussion on the Internet (a gold mine of information, BTW) where people reported they were able to flash a more recent version of GRBL to the very same Woodpecker variant that I broke, so the plan didn’t seem impossible.

Since I didn’t have a spare ATmega on hand, I tried playing around with the broken chip first. I discovered that it was running very hot as a soon as power was switched on, suggesting a short-circuit. I guessed it was the pin that was connected to the probe when the accident happened, but I was too lazy to verify it with a meter. I extracted the ATmega from the module with the help of some hot air, and then managed to bend the offending pin slightly. Then I connected the power while pressing the chip to its footprint on the module. It became hot in an instant, so I decided to give up and wait for a replacement microcontroller.

When the replacement ATmega arrived, I promptly soldered it to the board, first with hot air and then touching every pin with soldering iron. I connected my Arduino Uno to act as a programmer, with connections just as shown in the blog post. I loaded the Adafruit In-system programming sketch, and tried to connect to the Atmega with avrdude. Unfortunately, avrdude could not read the device signature correctly: it was reading different gibberish for each attempt. I checked the connections with the meter and found a 100Ω resistor between the MISO pin and the connector. I wondered if it was messing up the timing.

Arduino Uno connected to the Woodpecker module

I reloaded the Adafruit sketch with “slow mode” switched on and my suspicion proved to be correct – this time avrdude was able to read the device signature and even the fuse bits correctly. Unfortunately, the sketch did not support programming the flash memory with this speed, so I had to find something else. A brief search on GitHub turned up DEPlayground fork of ArduinoISP, which supports variable programming speed. Even its default setting was enough for the ATmega to catch up, and I was able to flash GRBL version 1.1 (an improvement over the board’s default v. 0.9) successfully. Now, what about the fuse bits?

Someone in the gold mine thread managed to read the fuses from an undamaged board, and the value was zero for both high and low fuses. This seems highly improbable, as such configuration would disable in-system programming, and also the reset pin. The presence of a reset button on the Woodpecker board strongly suggest a non-zero value for the high fuse at least. Perhaps some lock bit was making it impossible to read the fuses? I tried flashing various fuse bit combinations with various clock settings, but ATmega was showing no signs of life.

In desperation, I flashed the Arduino bootloader to the ATmega, followed by a sketch that would constantly output noise on the serial port, with various baud rates. None of it had any effect and the serial monitor remained stubbornly silent. In the end, I flashed the following values: 0xE2 for the L-fuse, and 0xDA for the H-fuse. This configuration used the microcontroller’s internal RC oscillator as the clock source, so it should “just work”. Then I flashed the GRBL again, disconnected the programmer and went to sleep.

The following day, when I got around to messing with the Woodpecker board again, I started with simply opening the serial port. Lo and behold, I was greeted with GRBL prompt! Perhaps severing all connections to the programmer board did the trick, I thought that just disconnecting the “slave reset” signal would’ve been enough.

Anyway, I reconnected the stepper motors and the spindle (gulp!), and ran some basic tests with bCNC. Everything turned out to be working fine, except for the x-axis motor – it was making noise, but not actually moving in either direction. Suspecting a cold solder, I’ve decided to reflow the ATmega. I applied generous amount of solder paste, and then proceeded to re-solder every single pin on the microcontroller with fresh tin. I made several short-circuits, and even partially melted the x-axis driver socket in the process. Oops. After fixing collecting the solder blobs and making sure the socket was still conductive, I reconnected the motors once again. This time everything was working correctly. What remained was the GRBL settings.

Someone posted the defaults for CNC1610, my model exactly, in the gold mine thread. I took the opportunity to modify them a bit: my machine is still new and not oiled very well, so the motors tend to skip during acceleration and deceleration. The problem was fixed by applying more conservative top speed and acceleration limits.

So, in the end I was able to not only recover my Woodpecker module, but also improve it with a more recent version of GRBL as well. In the process I learned a lot about using an Arduino for programming another board. I also managed to get the probe working, and I won’t be forgetting to disconnect the spindle before attaching the probe any time soon!


  1. [INFO] The gold mine thread
  2. [INFO] Connecting Arduino to Woodpecker CNC
  3. [LISTING] My GRBL settings
  4. [LISTING] DEPlayground’s Arduino in-system programming sketch
  5. [TOOL] Atmel AVR fuse calculator
  6. [DOCS] ATmega 328P datasheet
  7. [DOCS] Arduino Uno pinout
  8. [INFO] Upgrade your CNC
  9. [INFO] AVR Programming with Arduino
  10. [INFO] About Arduino ISP and bootloaders

ATW Tech Demos revision 8 is out! https://blog.kcdn.pl/atw-tech-demos-revision-8-is-out/ Sun, 26 May 2019 11:00:00 +0000 https://blog.kcdn.pl/?p=104 Continue reading ]]> In addition to complete revamp of the sensor system, this release also comes with an experimental Mac OSX build. I literally have no way to test it, so it can be completely broken and I wouldn’t know.

All These Worlds Tech Demo collection (for Windows | for Linux | for Mac ) [~120MB]