Being a software engineer by trade, I got into hardware design as a hobby a couple of years ago. By hardware I mean mostly printed circuit boards (PCBs). Having control over both hardware and software is a great way to get creative. I’ve only designed 3 boards so far yet I feel like I already learned a lot in the process. In this post I’m going to share some of the things I learned. That being said, I’m by no means an expert on PCB design nor on electrical engineering — please keep that in mind when reading this.
I’ve recently been approached by a young start-up because they needed an app for their delivery business. Time to market was crucial and the app was supposed to be available for both Android and iOS right from the beginning. Having done native development for both platforms in the past, I knew that this wasn’t going to work this time. At least not if we wanted to keep the cost down to a reasonable level. The app had to be cross-platform, meaning one code base for both platforms. Here’s why I chose Flutter and how it turned out.
Vor einiger Zeit bin ich von einem jungen Start-Up kontaktiert worden, weil sie eine App für ihren neuen Lieferservice benötigten. Die App sollte so schnell wie möglich marktreif und gleich von Anfang an sowohl für Android als auch für iOS verfügbar sein. Nachdem ich in der Vergangenheit bereits Apps für beide Plattformen nativ entwickelt habe, war relativ schnell klar, dass hier nur eine Cross-Platform-Entwickling in Frage kommt — zumindest wenn die Kosten im Rahmen bleiben sollen.
Für Cross-Platform-Entwicklungen gibt es verschiedene Technologien. Ich habe bereits Apps mit Ionic erstellt, was sich einerseits sehr gut für das Rapid Prototyping eignet und…
We’re in the midst of a big paradigm shift in the world of software development. Just like object oriented programming became fashionable a couple of decades ago, functional programming may become an idea of similar significance. The term functional is becoming synonymous with words like pure and stateless. If you’re interested in why this is I suggest you look up functional programming in general. In this post I’m going to cover React’s transition from stateful classes to stateless functions in practice.
Let’s first have a look at a typical React class component.
The constructor sets the initial state of the…
It’s been almost a year now since I set out to build my own handheld console. I learned a lot about the inner workings of the original Gameboy as well as about electronics in general. In the last installment of this series I talked about creating a display timing circuit with mostly 74xx components and I was planning on moving on to creating VRAM next. Things didn’t exactly go as planned, though.
As you may have gathered from the title picture, I replaced the countless 74xx ICs for the display system with something more compact. However, that was only after…
Automated build pipelines are a crucial part of professional software development. Now, you may not think of your typical hobby Arduino project as professional software development but let’s assume you’re creating an Arduino library for others to use – or even just a small open source project that may become relevant to the community at some point.
With an automated build pipeline aka continuous integration you can guarantee a certain level of quality for your project. I’m going to discuss two major things continuous integration can do for you:
In the last installment of this series about creating my own handheld console I’ve shown my version of a Gameboy emulator running on a Teensy 4 with a 2.4 inch Arduino display module attached to it. For the final build I intend to use a 4 inch display. For this I’ll need to write my own drivers as well as come up with some supporting circuitry. This blog post including a video will cover the timing circuit required to drive the display.
Driving the display ultimately requires three different components to work together: the timing circuit, the video RAM, as…
This is part 4 of a series that started with my introduction to the project of creating my very own handheld console. After learning a lot about the internal workings of the original Gameboy, it’s finally time to see some results. This is also going to conclude the emulator development part of the project for a while as it will be time to build some hardware first. But now: Tetris.
In the second part of this series I was talking about the Gameboy’s CPU and how it can be emulated. The DMG CPU’s contact to the outside world is through memory and memory alone — at least that’s what it looks like to the CPU itself. Some of the memory is actually peripherals in disguise. I’m about to explore what this means.
When I say memory I actually mean the address bus. As discussed in a previous post, the DMG CPU uses 16 bits to address contents in memory. The program counter (PC) uses 16 bits to fetch instructions from…
In the first part of this series I’ve been introducing the whole project of building my own version of this iconic handheld gaming console while also discussing some of the requirements to the hardware. Now I’m going to dig in and start working on the heart of the console: the CPU.
In principal, a CPU does the same three steps over and over again: fetch, decode, execute.