Pascal is not one of the biggest programming languages these days; it’s fallen into the background as the world moved on to newfangled things like C#, Python and Java. However, the language has its fans, one of whom put together a new compiler which targets retro platforms – and it goes by the name Turbo Rascal.
The list of supported platforms is extensive, with Turbo Rascal able to compile highly-optimized binaries for the C64, Amiga 500, BBC Micro, IBM PC, Atari ST, Game Boy, Amstrad, NES, ZX Spectrum, and more. There’s a usable IDE and even an included graphics editor for getting projects put together quickly. Also known by its full name of Turbo Rascal Syntax Error, or TRSE, it’s the work of one [Nicolaas Groeneboom].
The compiler runs on 64-bit Windows, Linux, and OS X, and there are extensive tutorial videos available on YouTube, too. Thus, there’s no excuse not to start developing a new retro game immediately. Check out the demo video below, and remember – as long as we keep using it, Pascal isn’t dead!
We’ve all become familiar with the Arduino ecosystem by now, to the point where it’s almost trivially easy to whip up a quick project that implements almost every aspect of its functionality strictly in code. It’s incredibly useful, but we tend to lose sight of the fact that our Arduino sketches represent a virtual world where the IDE and a vast selection of libraries abstract away a lot of the complexity of what’s going on inside the AVR microcontroller.
While it’s certainly handy to have an environment that lets you stand up a system in a matter of minutes, it’s hardly the end of the story. There’s a lot to be gained by tapping into the power of assembly programming on the AVR, and learning how to read the datasheet and really run the thing. That was the focus of Uri Shaked’s recent well-received HackadayU course on AVR internals, and it’ll form the basis of this Hack Chat. Then again, since Uri is also leading a Raspberry Pi Pico and RP2040 course on HackadayU in a couple of weeks, we may end up talking about that too. Or we may end up chatting about something else entirely! It’s really hard to where this Hack Chat will go, given Uri’s breadth of interests and expertise, but we’re pretty sure of one thing: it won’t be boring. Make sure you log in and join the chat — where it goes is largely up to you.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about. Continue reading “AVR Reverse Engineering Hack Chat”→
One of the nicest amenities of interpreted programming languages is that you can test out the code that you’re developing in a shell, one line at a time, and see the results instantly. No matter how quickly your write-compile-flash cycle has gotten on the microcontroller of your choice, it’s still less fun than writing blink_led() and having it do so right then and there. Why don’t we have that experience yet?
If you’ve used any modern scripting language on your big computer, it comes with a shell, a read-eval-print loop (REPL) in which you can interactively try out your code just about as fast as you can type it. It’s great for interactive or exploratory programming, and it’s great for newbies who can test and learn things step by step. A good REPL lets you test out your ideas line by line, essentially running a little test of your code every time you hit enter.
The obvious tradeoff for ease of development is speed. Compiled languages are almost always faster, and this is especially relevant in the constrained world of microcontrollers. Or maybe it used to be. I learned to program in an interpreted language — BASIC — on computers that were not much more powerful than a $5 microcontroller these days, and there’s a BASIC for most every micro out there. I write in Forth, which is faster and less resource intensive than BASIC, and has a very comprehensive REPL, but is admittedly an acquired taste. MicroPython has been ported over to a number of micros, and is probably a lot more familiar.
But still, developing MicroPython for your microcontroller isn’t developing on your microcontroller, and if you follow any of the guides out there, you’ll end up editing a file on your computer, uploading it to the microcontroller, and running it from within the REPL. This creates a flow that’s just about as awkward as the write-compile-flash cycle of C.
What’s missing? A good editor (or IDE?) running on the microcontroller that would let you do both your exploratory coding and record its history into a more permanent form. Imagine, for instance, a web-based MicroPython IDE served off of an ESP32, which provided both a shell for experiments and a way to copy the line you just typed into the shell into the file you’re working on. We’re very close to this being a viable idea, and it would reduce the introductory hurdles for newbies to almost nothing, while letting experienced programmers play.
Or has someone done this already? Why isn’t an interpreted introduction to microcontrollers the standard?
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
In an age of streaming media it’s easy to forget the audio CD, but they still remain as a physical format from the days when the “Play” button was not yet the “Pay” button. A CD player may no longer be the prized possession it once was, but it’s still possible to dabble in the world of 120 mm polycarbonate discs if you have a fancy for it. It’s something [Daniel1111] has done with his Arduino CD player, which uses the little microcontroller board to control a CD-ROM drive via its IDE bus.
By and large, the Raspberry Pi is a computer that eschews legacy interfaces. Primarily relying on SD cards for storage and USB ports for further expansion, magnetic hard drives are a rare sight. However, [Manawyrm] decided that some 40-pin goodness was in order, and set to making a PATA IDE adapter for the platform.
To achieve the task of interfacing now-vintage IDE devices with the Raspberry Pi, [Manawyrm] elected to use the single board computer’s GPIO pins to get the job done. 23 pins are required, with 16 used for the data bus, with the rest dedicated to address lines, strobes, and other features.
The adapter is no speed demon, netting 800 KiB/s on reads and 500 KiB/s on writes with a Raspberry Pi 4. The main bottleneck comes from relying on libgpiod, which [Manawyrm] readily admits is designed for general IO tasks, not data transfers. Despite this, it’s still fast enough to play an audio CD from an IDE CD-ROM drive without skipping. A kernel build is required, however, as Raspberry Pis are unsurprisingly not configured to use ATA disks by default.
What if your microcontroller IDE was running on the microcontroller itself and not hosted on the computer you use to do the programming? The greatest legacy of Arduino in all its forms has arguably been a software one, in that it replaced annoying proprietary development environments with one that installed easily on a range of operating systems, was easy to use, and above all, worked. The next level of portability is to get rid of any specialize computer-side software. [Ronny Neufeld] wrote MicroIDE for ESP32 as an IDE accessible through a web browser, which interestingly is hosted on the target device itself.
Using the IDE is easy enough, install a binary, connect to the ESP with a web browser, start writing MicroPython code. There is a choice of connecting directly to the chip as a hotspot, or connecting via another WiFi network. The interface is looking pretty slick but he’s at pains to remind us that it’s a work in progress. Sadly there is no source code yet as it’s a binary distribution that is free for non-commercial use, we’d hope that an open-source release might one day happen. It’s not for everyone, but the convenience of accessing the same interface from almost any modern device should help attract a healthy community.
As the common myth goes, the average human utilizes only about 10% of the true potential their smartphone is capable of. Especially when it comes to electronics projects, it seems that we often overlook how we can integrate and take advantage of their functionality here. Maybe that’s not a big surprise though — while it isn’t rocket science, getting into mobile development certainly has its hurdles and requires a bit of commitment. [Victor Diaz] figured there had to be a better way, so he went on and created PHONK, the self-contained creative scripting toolbox for Android.
Once the app is opened, a web server is started, and connecting to it from any modern browser within the same WiFi network presents you the PHONK development environment with everything you need: editor, file browser, console, and API documentation. You can write your code in the browser, and pressing the run button will execute it straight on the device then. As everything is self-contained within the app itself, no additional software is required, and you can start right away by exploring the set of provided examples that showcase everything supported so far: sensor interaction, BLE server and client, communication protocols like MQTT or WebSockets, OpenStreetMap maps, and even integration with Pure Data and Processing. Attach a USB OTG cable and you can program your Arduino, have serial communication, or interface a IOIO board. You can even connect a MIDI controller.
This is really impressive work done by [Victor], and a lot of attention to detail went into the development. If you have an old Android phone collecting dust somewhere, this would be a great opportunity to revive it and build something with it. And as [Victor] writes on the project’s GitHub page, he’s always curious what people will come up with. If you’re thinking about building a mobile sensor lab, or want to learn more about the sensors inside your phone, have a look at the 36C3 talk about phyphox.