ZX NOXROM V1.0

I have been designing a ZX Spectrum Cartridge "clone" for a while (case, board and silicon skirt), to be able to make new software releases or replace original damaged cartridges. I always liked the fact that these cartridges were small and had a sleek look.
However, Cartridges have a nasty limitation, which is the hard coded limit to 16KBytes. In fact it's a limitation imposed by ZX Spectrum inner workings and how ROMCS control line works, which can be used to disable internal ZX Spectrum ROM, which has 16KBytes, hence the size limit.

This new Cartridge, will have up to (128K, 256K or 512K Bytes), paged in 16KB blocks into the same address space as ZX ROM.
This will allow this cartridge to work as a replacement for multiples of 16KB ROMs, or eventually, as a fast application snapshot loader, so that larger than 16KB applications can be loaded by using several 16KB Banks.
Another important factor in the design, is to be able to quickly switch banks, in order to use the cartridge as ROM data bank, for an application larger than 48KB or 128KB. This allows for larger games or levels to be included, without ever needing to use a tape deck or similar serial loading.

However, due to limited Bus Address control lines available at ROM Cartridge slot, several hurdles had to be overcome, since we need to send at least bank switch commands to it, but no Read (RD) or Write (WR) control lines are available (see available control lines on the right, in green when compared with regular Z80 CPU control lines for opcode fetch.
So after several brainstorming sessions, I developed a method to trigger these commands, by manipulating the address lines into a specific sequence, that is almost impossible for a regular program to generate in normal operation.

It basically consists, in managing to output the same exact address 3 times in sequence, which is usually impossible, since each Z80 fetch instruction cycle (M1 cycle), always outputs a refresh address in between. So at most, two consecutive addresses could happen, in normal operation. But with some very specific trickery one can manage to output these 3 consecutive addresses.

So after validating this idea, it was time to make some simulations, and find some digital logic that would accomplish this mechanism.
On the right is an example of a simulation to validate the bank mechanism with a few test cycles.
It tests, regular Reading of addresses from ROM and RAM, the trigger mechanism for setting a Bank and also a another mechanism to allow writing to the Flash Memory being used as Cartridge ROM.

All that was left to do was to implement a suitable PCB (last image).
To make this a reality, able to fit inside the very small ZX Spectrum original Cartridge case, all components had to be SMD and low profile variant (TSOP and TSSOP).

Home built quadcopter - Maiden flight

After receiving last missing parts, namely: propellers, battery and flight controller, I had the minimum required parts to have a working prototype.
Another useful addition was a power distribution board, which is crucial to minimize cable mess and organize power lines and provide a single connector to battery. This is specially relevant when motor power draw can reach 60Amps of peak current.
I also bought a propeller balancer, which helps in having well balanced propellers that will help avoid most vibration from the frame.
Balancing a propeller is a simple procedure that resumes to adding duck tape to the lighter side of a propeller, depending on the quantity of tape and position where you add it, you can balance a propeller by simple trial an error, until you instinctively know where and how much tape to add.

During setup, special care must be taken to correctly wire components to the control board, whatever it may be (motor ESCs or radio receiver lines), to prevent swapped connections. We don't want the controller to "think" that it's controlling the forward right motor ESC, when in fact we connect the backward left motor ESC to it, or that it is receiving yaw input, but instead we connect pitch input to it.
Any mismatch and it can be disastrous, specially if we reverse power lines (+ and -), because that will surely fry some component or your entire board almost immediately.
All motors must also be tested for correct spinning direction. If spinning is incorrect, just swap two of the three cables connecting the ESC to the motor, this will reverse the spinning direction. There is also a setting in most ESCs configuration, but it's better, faster and safer to just swap cables.

After setting it all up, I locked the frame to a table, so that it would not fly, even if it wanted to, so that I could try all the motors and direction controls and assert that everything was working as supposed.
Once everything checked out ok, I went outside for my first test flight, the maiden flight. After a few centimeters of lift, it was obvious that there was something out of balance, because the quad kept on moving side-ways when it was supposed to be still. I checked the radio to see if any trimming was being applied, but that was on center, X and Z.
From further inspection it appeared to be some difference where the ESCs are attached to the arms, but it can also be related with the feedback loop constants that came pre-defined with the board, that I have not checked yet.

Did some more test flights in a more controlled environment, with an even level ground (a tennis court).
However, to my surprise, I managed to flip over the quad while it was trying to lift off. After inspection, I noticed that two motor power connections where disconnected, which was probably the cause of the flip over. I also noticed that although the 60Amps connectors that I bought looked great, they were not holding a good connection, and from further inspection I discovered this was happening because there was too much plastic (length wise) in the female connectors, that was preventing connector metal parts to mate and lock correctly.
For a quick solution, I removed all female connectors plastic covers so that this will not happen again. Later I can cut them to size, and prevent metal exposure by using plastic covers for both connectors.

After checking all motor connections again, the quad refused to power on, like if the controller was completely dead. After a few minutes I was starting to convince myself that I had fried the controller. But then I noticed that every time I connected power to the board, a light column of "magic smoke" emerged from the board. After a couple of tries, I managed to identify the SMD component that was leaking "magic smoke". And it was a simple power diode.

Partially disconnected motors (only one cable, + or -) besides flipping the quad, also have the side effect of running too much current through the ground rail, which eventually toasted the small SMD power diode.
I replaced the SMD diode with a more beefy power diode, and the board came back to life.
Once I got the board working, I re-checked every electric connection, to guarantee nothing else was loose or disconnected. I even added a few rubber bands to prevent ESC power connections to disconnect during flight.

Everything checked and ready to go, so I went for another test flight outside. A few seconds later and about 50cm high from the ground, the quad just dove to the ground, and one of the motors decided to fly solo :)
Could not believe my eyes, what was going on ?
Later I realized that on previous flip over crash and some other ruff landings from previous tests, I had cracked one motor support, without noticing it. In this last flight, the cracked support just gave in to the operational stress and finally snapped out, letting the motor loose and propeller almost cut its own motor power cables when it snapped.

Lessons to be learned ?
Check, double check and triple check everything, not just electric or electronic components and connections, but also all mechanical and moving parts, including wiggling cables that can become trapped on moving parts (propellers are killers).

Motor Bike Helmet Hanger/Support Prototype

After some time searching for a spindle-moulding machine, I finally found a cheap one that I can also adapt to my circular table saw. After initial cut of wood shapes to build by prototype Helmet Hanger, it is apparent that I made a simple mistake when cutting, since both head parts will not mate as expected, when compared to my 3D sketch. In this case, I lucked out, since I cut the matting area too short, which is not a problem because I can always increase cut length to correct size, which I did, preventing me to trash the wood.

Once the parts were correctly cut, I had to assemble a gig to fix the two head parts in the correct angle, to be able to cut it so that it will sit flush with the Helmet Hanger Base.
After I used the spindle-moulding machine to round all the required edges, to make support less prone to stick to helmet interior. Assembling the Helmet hanger is as simple as 1,2,3. First fit both head shaped parts together, and then stick this assembly into the base hole. Once the final shape is setup, we just to need to fix the head two the base, using two wood screws, that must be threaded in the correct angle.

To correctly thread base screws at the correct angle, to make it easy to assemble, it is recommended to drill these slanted holes into the parts first, which will work as a guide when threading screws for final assembly.
To finish it off, I still have to put a coat of wood varnish, to make smoother, which is useful to facilitate insertion and removal of helmet on the anger.
The ideal way to insert the helmet is to rotate it about 45º degrees, insert it on hanger and then straighten it out by rotating another 45º in direction opposite to initial rotation. To Remove it, just do the same actions in reverse.

One can make a larger base to provide support for several helmets, either vertically or horizontally.
To fit several helmets, one must also consider helmet size (S, M, L XL), and either use the smallest size that fits all intended helmets, but larger sizes will probably become too loose, with this configuration.
For a better fit, the ideal is to make a hanger "head" specific for each helmet/person, so that it will fit snugly and prevent movement.

Stereo Amplifier for MAME

I have a PC setup as a MAME arcade machine, using an Asus Terminator T2-R Deluxe, a 17" Viewsonic Monitor and an X-Arcade Dual joystick. This is one of the few PCs that still included a 15 pin joystick port, which is a requirement for a retro compatible gaming machine. I also added a NVidia G-Force FX5500 graphics board for better performance and compatibility.

However, the embedded sound chip is not like the old Sound Blaster boards, that included a pre-amplifier that had enough power to drive medium sized 8 Ohm speakers.
I'm using a pair of 8 Ohm Pioneer Car Audio speakers, which can barely be heard, when there is any ambient noise.
So, arcade gaming experience was suffering of poor sound power, due to lack of a proper sound amplifier.

Wondering on which amplifier to get, I found that most car amplifiers are somewhat expensive and would required a separate transformer, since they work on 12V DC power.
During this exercise, I found a trashed TV, and noticed that most electronics where removed but the original speakers were still in there and appeared to be in working order. So I got my trusty screwdriver, and detached them both and tested them and concluded they were working fine.

The nice thing about these speakers (besides being free) is that they are powerful enough and have an oval shape, that was just right to fit inside my arcade table. Taking this into account I cut a shape to fit them in the available space. Now that I had smaller and free 8 Ohm speakers, buying an amplifier didn't seem reasonable due to cost. So I decide to build my own, using a Velleman kit, a transformer and a black plastic box.

Everything went smooth, until I found out that the transformer did not fit the box, it was 3mm too high. Ok, I can fix it if I add some height between the box and the lid, with a rectangular "ring" around it, ensuring transformer will fit, and just have to swap screws for longer ones.
But this gave me an idea, since I had already a 12V power supply at hand, I could use some translucent plastic and glue a few 12V LED stripes, to light up the plastic, making it easy to see when amplifier is on. Having an independent power cord from PC, it's possible to leave the amplifier on by mistake, if you just switch off the PC.
The light "ring" did not need to be perfect, but just good enough. I did not add lights on corners (there is a screw on each corner, to secure the lid), hence corners will be darker when lit, as can be seen in the picture.
I could make it lit perfectly, but in this case I believe it wasn't worth all the extra effort required to beautify this hack :)

Motor Bike Helmet Hanger/Support

Another project I started, to create something useful to store away my helmet when I arrive at home, instead of leaving it on some table or other flat surface.

Basically, I wanted a Helmet Hanger, but it should be easy to make and assemble, and eventually store, if you don't need it for a while.

Since it's all made from flat boards that attach to each other, it's easy to store or to carry arround or eventually sell to others :). I made the first prototype from some wood left overs from another project that I had laying arround.

I plan to make a version for two helmets also. When finished I will re-post with some more info.

ATtiny85 + Max7219 Matrix Displays

While waiting for some parts to arrive to complete the assembly of my quadcopter, I started assembly of a few Max7219 display kits I had bought previously.

Once I had a few displays assembled, I wanted to test if they were working. I used a few push buttons and pull-up resistors and simulated Max7219 serial protocol by hand.

Obviously this is not the best and fastest way to test, but since putting max7219 into display test mode is easy, just push 2 x 'FF' bytes, and it's in test mode with all LEDs on.

As soon as I had confirmed that display were ok and working, it was time to step up the game. So I decided to see if ATtiny85, would have enought punch to handle a dew displays with the internal 8Mhz.

I have never used Arduino before, but it seemed pretty simple, when compared to ASM firmware that I have done some time ago. At least it's in C/C++, so it should be easy.

In one day, I did the following:

• Installed my hardware programmer
• Setup Arduino development environment
• Setup ATtiny support (not using any arduino board)
• Started developing some code

At the end of the day, using an already available Max7219 lib (LedControl), I had an example working, that was filling several matrix displays, pixel by pixel or by full rows (faster).

During the night I added some more features, namelly to support a basic bitmap font (just a dozen chars) and support scroll left and scroll right (default lib font does not work with my configuration, and it's only 5x8).

However, looking at the way the LedControl library was implemented (looked at source code), I see two major problems:

• Writes to the sequence of displays one at a time (forcing NO_OP, on other devices)
• Mix & matches display processing with device access.

What I mean is, this thing should be split into two or more parts, since it doesn't make sense (for example) to have an hardcoded font inside the library code used to access devices, because some people may not need it, or may want to use some other mapping.

This is specially important, when you consider that each hardware implementation (schematic) can have different configurations for matrices (row vs col orientation), and also how they serially connect adjacent modules (horizontaly or vertically) or a composed lines x columns of devices, making any assumed font invalid for these configurations.

Another factor, is program space, which seems large for its current functions, mostly due to internal buffers and font bitmap and some Arduino bloat.

So interfacing, should be distinct of how it is actually used as a whole (as a screen).

After adding a few more displays (gone from 2, to 3 and then 4), it become painfully apparent that the library was slow, because of the way it's writting to each display, and it gets exponencially worse each time a display is added.

Max7219, suports 8x8 matrix display, or 8 x 7 segment displays (plus '.'), which gives you control of 64 LEDs (8x8=64). But the most it can do, is to write one row (one byte, 8 bits) to each display at a time.

So to completly update a single display we need 8 writes, one for each row. Since each Max7219 command uses 2 bytes, we transfer a total of 16 bytes (2*8).

However, when several displays are serially connected, the command that just went through the first display, enters the next display, untouched. So they provide a NO_OP command, that allows a display to do nothing.

Resuming, if we have for example a screen composed of 3x1 displays in series, if we want to update display 2, we can do the following:

• Write 1 command (2 bytes) with NO_OP for display [3]
• Write 1 command (2 bytes) to update a single row of display [2]
• Write 1 command (2 bytes) with NO_OP for display [1]

Since we want to update all rows we have to repeat this process for all 8 rows of display 2.

In total, we have to write 3 commands x 8 rows = 24 commands (48 bytes), just to update a single display device. This is how LedControl library works, and it makes sense since it is the correct way to do it, when you want to update only one of the display devices, without afecting the others.

However, you tipically want to update the entire screen (all 3 display devices) at once. But LedControl, doesn't allow you to to this, you have to write one display at a time, in sequence, which equates to 3 x 24 commands = 72 commands in a total of 144 bytes to be transfered.

But the problem is that it gets worse, when you start to add displays.

For 4 displays in sequence you get:

• Update one display row = 4 commands
• Update all display rows = 8 x 4 commands = 32 commands
• Update entire screen (4 displays) = 4 * 32 commands = 128 commands (256 bytes).

So to refresh one full screen frame we have gone from 72 commands (for 3 displays) to 128 commands (for 4 displays), and from 144 bytes to 256 bytes respectively. For 5 displays and up, it only gets worse.

With 3 display devices and running ATtiny85 at 8MHz, some form of wobbling is clearly apparent when screen is animated. i.e. updates are not fast enought.

But there is a better way, which is to allow the library user to control the max7219 latching mechanism (Load/CS), so that the screen controller can decide what to do, including optimizing the writting to all display devices at once, row by row.

Worst case cenario, writing a full screen frame, will take the following number of commands:
{num_displays} * 8 rows * 1 command/row

So for a screen using 4 displays in sequence, we get: 4 * 8 * 1 = 32 commands

This grows linearly with number of displays. Compare that to 128 commands we had before!

After all this babeling and technical mumbo-jumbo, there is another issue that can be improved, which is to swap the bit-banging style of the library, and instead use the SPI support of the chip.
NOTE: bit-banging can be useful when we are out of pins (it's more flexible) or when the SPI is already being used.

Hence 2 versions of the library should exist, one bit-banged and another with native SPI support.
I will probably implement my own library(ies), taking into account all these concerns and optimizations and then release it to the public.

Home built quadcopter

So here is my first attempt of building a quad copter. The build is made from discrete parts, that I started to buy since January.
I started with a simple X600 kit for the frame, but I plan to change it using extra long arms (Carbon square rods, that I already bought/have), for improving stability and airflow (less turbulence if motors are further away from the central structure).

I also plan to clean up the wiring in order to minimize turbulence. Eventually I may pass all wiring inside arms. Some screws used for landing gear, make this more difficult to accomplishing cleanly.
Currently I have mounted the entire frame, including all mechanical legs, that use a spring to dampen any stronger landing, and also allows for some skidding, hopefully preventing tilting the Quad.

One of the advantages of this frame, is that it can be easilly folded to a more compact shape, that will make it easier to fit in a car, specially when I increase wingspan to about double the original size, 1200mm (1.2 meters).
I have mounted and correctly centered all 4 engines on each frame arm. Engine connections are still not done as can be seen on the pictures.
I also mounted all 4 ESCs on expected final position. ESCs are 40 Amps, with switching BEC, to prevent heating and avoidable battery consumption, that happens with typical linear BECs.
Something of concern is that ESCs may need some extra air flow to cool off appropriately. If this is the case, I will have to put them closer to engines/propellers, which will spread the overal mass, making the quad less reactive/nimble.
It's better to have most of the mass near the center and below the thrust plane, for better maneuverability and stability.
Next step is to balance all 4 Propellers correctly.
I'm still waiting for the next batch of parts to arrive, namely: Flight Controller, Battery, Charger and power distribution board (I already have a Radio and Receiver on standby :).
After all these items arrive, next step will be to add a camera suitable for taking pictures and videos, and in due time, FPV flight :)

Clu Gravity Ball - Self Contained Prototype

Following my development schedule, I created my first self contained Clu Gravity Ball, i.e. battery, electronics and lighting are all inside the gadget. This is only possible because I shrunk the electronics, using SMD components.

Since space is at premium inside the ball, I do not have enought space for regular battery holders, which use springs that take too much space. So I had to figure out another way to solve this problem.

I created two battery end caps using two vinnegar bottle caps (cut to size) that provide a snug fit to the battery, and used two copper battery pads to make a stable connection.

I still have some issues to sort out, like finding a better way to connect battery connectors to the board. Currentlly I have 2 tiny wires that will not withstand much handling without breaking. I already had to resolder them a couple of times, while doing some experiments and testing.

Current electronics version, is just barebones. I just have a basic reliable lighting circuit, but without any form of control, i.e. no on/off and no dimming or similar features.

Next scheduled improvements in electronics:

1. Power management circuit
2. Support a re-chargeable battery
3. Add MicroController and build firmware
4. Add Acelerometer
5. Support configurations in firmware (using acelerometer)
6. Suport RGB lights

I still have a long way to go, to create and shrink all scheduled features. Nonetheless, this is a step in the right direction.

I have already selected and aquired all required components for the next phase. Now I need to do some prototyping.