SDrive-Max Using a cheap 2.4 TFT LCD

Posted on June 25, 2020 by Mr. E

One of the things I’ve been interested in for the last year or so, is developing for the Atari family of 8-bit computers. I haven’t done a lot yet, but I’ve been slowly getting software, docs, and hardware to start writing code with all the tools I could possibly need.

I had already built a SIO2Arduino, and that allows me to emulate a disk drive that I can use to load the dev tools I need. Its biggest problem, however, is that it only allows you to mount one disk drive at a time. If I wanted to have any form of operating system, dev tools and my own project files, I would need to create a custom Frankenstein disk image with everything inside.

A more elegant solution, of course, would be to use something that’d allow me to emulate several drives at once. That device already exists, and it’s called SDrive-Max.

ZEPPP : Zero External Parts PIC Programmer

Posted on September 2, 2018 by Mr. E

A couple of months ago I was asked if I could prepare a sort of workshop on one of my favorite topics: ASM Programming for PIC microcontrollers, which I of course accepted on the spot. Now, I wanted to include a couple of “hands-on” lab sessions in this workshop, and because of this, I needed a way for all attendants to actually work with real PICs that hopefully did not involve purchasing PIC-programming hardware in bulk for what is probably going to be a one-shot activity.

The Quest

Simple DIY programming circuits exists, and in fact, my first PIC programmer was a home-built “Enhanced” NOPPP (No-Parts PIC Programmer); a fully functional device that required only a couple of components (Not really “No-parts” but pretty close to it). The problem is that it used the PC parallel port (R.I.P), and required an external power supply. And this goes for pretty much every “classic” DIY PIC programming circuit; they all either require extra hardware or can no longer be used on current computers.
Read More →

Arduino’s broken Random()

Posted on November 25, 2017 by Mr. E

If you are using your Arduino’s PRNG (Pseudo-Random Number Generator) for anything more serious than flashing random lights for your Christmas decorations, there’s a chance you might run into some unexpected issues, as the random() function in Arduino seems to be somewhat broken.

Why? Let me explain.

Background

Most basic random number generators in programming libraries and platforms are based on what is called a “Linear Congruential Generator” (LCG), and I have discussed them before here in my blog. As with any PRNG, the output of the algorithm ends up being a sequence of numbers “seemingly” selected at random, starting from a “seed”.

Given the basic structure of an LCG, after you have drawn X numbers from the generator, you’ll start getting the same sequence again. This is called the “period” of the LCG, and is one of the things you should know about the PRNG you are using (again, if you are serious about your random numbers, or you need a controlled, predictable and stable behavior).

Arguably, you should always know the weakness and strengths of the PRNG you are going to use, before even using it, as to avoid any potential pitfall and/or limitation (and that’s why it’s normally not a good idea to use the default implementation of a random generator in any language; For the most of it you don’t know what you are getting).

An update to my desk clock

Posted on June 25, 2017 by Mr. E

I like to call this revision “Please believe me, I’m not a bomb”

Like a year ago I made myself a nice little desk clock that has worked fine since then. But recently I revisited the project to do certain improvements.

For starters I wanted a smaller board so I could fit it inside an enclosure. I also wanted to power the clock from a rechargeable 18650 battery and add the charging circuitry to the design. I was also willing to give up with the ultra low power consumption and use a DC-DC booster that would of course draw more current but would ensure the clock gets a nice and stable 5V at all times. This has two advantages: It keeps a constant brightness for the display, and, more importantly, will give me reliable 5V in the aux port so I can easily interface the clock with other devices or external circuitry if I so desire. Read More →

Custom PCB for SIO2Arduino

Posted on January 3, 2017 by Mr. E

A while ago -and after a couple of trips to our local “flea market”- I managed to get my hands on a fully working vintage Atari 800XL. It took some tests and soldering work, but I ended up with a fully working 800XL with a XC12 cassette deck (I even got a defective cassette deck that it’s mostly working now after some repairs). I also built a video cable to have the “vastly superior” RCA video output instead of the noisy “TV” RF signal.

The tape deck loads and saves to cassette perfectly, but every read/write operation takes ages. Not that I mind waiting, to be fair, but since there seems to be better alternatives (like the floppy disk drive) it makes no sense to just stick to this, especially since I intend to do some development on the device.

Yes, this picture was taken with a potato.

ORC-KIT with standalone H-Bridge Drivers (and some updates)

Posted on December 22, 2016 by Mr. E

So in the sort of tutorial I wrote about ORC-KIT I mentioned that it was possible to use other boards instead of Adafruit’s friendly motor shield, and in fact, there was space in the board for a couple of very cheap and widely available L9110S Dual H-Bridges, which should give you more control over the build, and “free” some precious Arduino pins that you can use for extra sensors and actuators. You can actually change the Arduino for something else, but that’s beyond the scope of this post.

H-Bridge?

H-Bridges are simple circuits that allow you to control the flow of current through a “load” with 2 control signals (A and B). When the load is a motor, you can make it spin forward, reverse or stop completely by changing the digital values on A and B. H-Bridges normally have an ENABLE line as well, which you can toggle yourself or leave permanently “ON”. Controlling the speed of the motors is easier if you can turn each bridge on and off quickly using PWM pulses applied to the enable lines, but that’s not always possible. The L9110S boards don’t have an enable pin, for instance, so we will need to manipulate only the 2 basic control signals to drive our motors if we use this controller.

Each of these Dual H-Bridge modules can drive 2 motors and has a 6 pin header for the 4 control signals plus power.

Introducing ORC-KIT!

Posted on October 9, 2016 by Mr. E

Earlier this year I embarked on the journey of designing a simple but expandable robot that any electronics enthusiast could build. I knew several nice kits from brands like Lego, Makeblock, OWI Robotics, etc, but I considered them to be normally either too expensive or too simple and limited. There are also many generic unbranded kits on eBay which suspiciously have all pretty much the same design but vary mostly in their debatable choices for hardware and layout.

I wanted to do something flexible but not too expensive nor flashy, much like the unbranded kits, but with better design practices in mind, and engineered to be heavily customizable.

Fully assembled Vanilla ORC-KIT with some extras.

TFT Adventures (Playing with a ILI9341-based display)

Posted on August 10, 2016 by Mr. E

Not long ago I purchased a few 320×240 touchscreen displays from ebay that looked pretty decent and were also fairly cheap. They conform to the Arduino shield form-factor, so they snap directly onto any standard Arduino board, making them really easy to test and use. They also have an integrated microSD slot (connected to the same bus used by the display controller) which is a nice touch and widens the number of possible applications for these modules.

As seen on literally every eBay listing that sells them.

Of course the displays didn’t come with any code, and the most reasonable thing you’ll find online to make them work is Adafruit’s TFT-LCD Library, which includes support for a number of different controllers, and is fully compatible with their very own and versatile GFX framework.
Read More →

Temperature Sensors

Posted on May 15, 2016 by Mr. E

I wanted to add a temperature sensor to a project I’m working on, and while I already had selected the perfect IC for the job, I decided to test a couple of other options I had, to see how they fare in comparison. I was originally going to compare only 3 sensors; the popular LM35, the not-so-popular LM335 and the kinda obscure TMP75, but as I started writing this post I remembered I got a Dallas DS18B20 as part of kit of sensors, so I added it to the mix to balance the digital-to-analog ratio of this comparison.

The original 3 sensors I was going to test.

Brainfuck-on-Arduino: End Of File

Posted on November 23, 2014 by Mr. E

Ok, so this is probably the last post I’ll make about my Brainfuck-on-Arduino project, basically because it has reached a point where I’ve already tried all the things I wanted to try and I’ve decided that there’s no point in taking it out of the breadboard and build a board for it. At least not for Brainfuck. And I’ll explain why.

The Performance Issue

I previously said that I was expecting the performance to “drop” a bit when reading directly from a SD card instead of the internal RAM, but I was hoping to mitigate that with a sector/block cache similar to the one I wrote for the SPI RAM.

And that’s completely reasonable and actually true. Where I made a mistake however, was in also assuming that doubling the SPI clock would result in a noticeable performance boost. That’s definitely false. Reading a whole 512bytes sector currently takes between 1 and 2 milliseconds at 4Mhz, and RAM access is done at the same speed, so being the RAM pages half the size of the SD sectors it probably takes half that much to get a whole RAM page.

Since we are caching so many bytes in advance, the number of page reads (both from RAM and SD) is not really that high, so even if we were to double the SPI bus speed we will only cut around 1ms from each access. Most programs I’ve tested don’t normally cross the RAM page boundaries nor require more than one SD sector to be stored, so the speedup won’t even be noticeable for most cases. It will be barely 1 or 2 ms, so if we run into performance issues, they are somewhere else. They are NOT in the SPI Bus speed.

A BIT OF MYSTERY

Category Archives: Arduino