A couple of weeks ago I ordered a NEJE DK-8-KZ 1W laser engraver/cutter from China, basically because the price was too good to let go. I spent a couple of hours yesterday trying to etch and cut a few different materials.
Fume extractor and lights mounted on top.
The Neje was surprisingly easy to set up and use. After unboxing and connecting the cables, simply install the CH340 driver and the software from the supplied MicroSD card and off you go. The device did not require any assembly or calibration.
It needs power from two 5VDC USB sources, one for the motors and one for the laser. I used an old 2A iPad charger and the PC's USB port for the other, which also happens to control the device.
The overall build quality is good. I went over all the screws and tightened them with the included Allen key, but all seemed to be sufficiently fastened. No loose ends, no rattling, no cracks or unwanted gaps in the plastic.
The software included is very simple to use. Basically, all you need is to drag'n'drop a 500x500 pixels image and start printing. The program supports some basic image rotation/translation/zooming. Before engraving, the printer goes into preview mode, hit the red button to switch to print mode.
I tested a few different materials out of curiosity. It easily engraved paper, cardboard, colored plastic, FR4 PCB, paper based PCBs. It would cut thin plastic, colored plastic foam, paper and thin cardboard. Unfortunately, but not surprisingly, it did not engrave transparent acrylic glass. Metals and other reflective surfaces were not tested.
Pros and cons time.
Pretty much plug and play
Small and compact
Beginner friendly software
Very small print area, about the size of a box of matches.
Bottom plate easily gets engraved/cut if you're not careful
Overall conclusion: I'll make use of it, and I'm satisfied. Money well spent.
A few weeks ago I bought a second-hand 3D printer, namely Kossel 800 delta printer. It lacked the stepper motors, pulleys and a general clean-up of the wires. After a week of trying to figure out how this works, I had my first successful print last night.
Unfortunately I did not take pictures during the build, so you'll just have to take my word for it. We'll skip straight to the end result.
This is the latest print, the letter J. I'm quite pleased with the result so far, there are a few calibrations I need to do still, but all in all I'm very excited. Time to order a few kilograms of filament.
Oh, and if you're wondering why my latest posts have been from the kitchen table, it's because I'm building a new hobby room, so my daughter can have her own room in the house. The new hobby room is a converted outdoor shed; smaller and colder than ever before. Can't wait to move in.
My son owns an RC car that lacks the remote control. It's a cheap car, but still, instead of throwing it away I decided to rescue it somehow. I guess I could find a cheap replacement controller... but why not go all the way and hook it up to my WiFi network?
Good looking car does not know what's about to happen
I decided to use a WeMos D1 board that I had spare, which is an Arduino form factor ESP8266 based board. The ESP8266 specs are amazing, I encourage you to look into this if you need to WiFi-ify something (did I just invent a new word?)
WeMos D1 ESP8266 WiFi board
Not many surprises awaits when you have a transparent chassis. Either way, here's the case that holds the current motherboard. Two more screws and we're in.
Bottom's up! The bottom side appears crowded, but is actually quite nicely laid out. The easiest way to figure out what went where, is to follow the traces backwards - i.e. from the motors to the main IC.
The top side of the board reveals the main IC, which is a PT8A978BPE. It appears to be a common controller for low and mid range remote controllers. I had already figured out the pinouts for forward, reverse, left and right earlier.
Here are the pins labelled 1, 2, 3 and 4 clockwise by yours truly. I applied 3V3 directly to the pins and the wheels started spinning. This is the operating voltage of both the WeMos D1 and the PT8A978BPE, so I figured it's OK.
Wires were soldered to the pins, going directly to the WeMos board since the original motherboard provides the pull-down resistors required. The brown wire in the bottom left corner is to connect the ground planes.
All wired up!
The original battery case had room for six 1.5V AA batteries. Unfortunately I didn't have enough AAs, so I improvised with one 9V battery. However, on the bench I used a traditional power supply.
My heavy-duty power supply
The WeMos D1 found its new home, and I started writing the server software. At first I thought it would be fancy to use a web interface, and improvised a web server on it. Turns out that web calls isn't the best candidate for quick response applications, so I rewrote it down to a simple TCP client. I can even telnet to it and drive it from the command line.
The protocol is dead simple: there are four directions the car can go: forwards, backwards, left and right. The initial letter dictates the direction (F, B, L, R). Uppercase means on, lowercase means off. A sequence of commands to the car may look like this: FRfrBLbFl, and they are parsed on the fly.
The D1 found its new home
Now we're getting somewhere. All parts are wedged into place, and we are ready to start focusing on the client side of the software.
Professionally secured with electrical tape
Here it is on the test bench, a.k.a. an IKEA lamp. No wires attached, running 100% from battery power, controlled via WiFi.
Looking pretty sweet. The car looks a lot better without the original, limp antenna. And it probably does wonders for the aerodynamics as well, don't you think?
All mounted and ready to race.
It's hard to tell from the outside what's going on, but once you take a closer look you can see some of the modifications.
The client software was written in C++/Qt and works perfectly. You can click the buttons or use the keyboard, which is a bit more intuitive. The response time is around ~150-200ms, which is good enough for someone with my driving skills. Meaning I crash a lot anyway.
Here's a quick video of the thing in action. Turns out it's hard to drive around when you can't see a thing... Adding a camera to the equation is tempting...
The above video could be much cooler if I were a better driver.
There's an old strip poker game for the Amiga called Hollywood Poker Pro. The game had an introduction screen featuring the silhouette of a woman dancing to a catchy 80's tune. I wanted to rip that animation, and thought it could be an interesting read to see how it was done.
Just to get an idea of what I'm against, I loaded the game into WinUAE and took a full memory snapshot. Unfortunately, all I could find was the current frame, so it was obvious that the image was rendered in real-time somehow.
I then decided to take a closer look at the game files. Since the diskette image was NDOS (i.e. not directly readable from by AmigaDOS) I had to lift out the files somehow. I saved some time as I found the WHDLoad image of the game, with all files in a readable directory. One file in particular caught my interest, namely dance.dat.
I examined the dance.dat file in a hex editor, but it left me clueless. I rolled up my sleeves and prepared for some debugging to figure this out. I loaded the game loaded in WinUAE with just 512kB RAM, 68000 CPU, OCS/ECS compatibility.
You see, in the good old days almost every program was run from a run loop. This is a loop that calls several subroutines to get things going.To identify this loop, I fired up the WinUAE debugger by hitting SHIFT+F12 several times.
After a few iterations, I started to notice a pattern in the breakpoints. It landed in the $66Exx address space every time. Dissassembling this memory neighbourhood revealed that the run loop started at $66E1C. Here is the run loop, and those of you who know Amiga assembly will recognize the classical btst #6,$bfe001 (test for left mouse button) at the end:
As you can see there are three JSRs from here, to $66B0C, $67152 and $66EAC. Interestingly, each of these subroutines begin with the instruction NOP ("no operation", opcode $4E71), so by replacing this with RTS ("return to subroutine", opcode $4E75) the function could easily be skipped without too much hassle. Using this technique, I quickly noticed that $66EAC was responsible of the upscroller, $67152 drawing the animation and $66B0C did the frame selection.
Time to debug $67152. You may scroll past this section, I'll try my best to explain it further down.
Okay, let's examine the code and try to figure out what's happening here. The first few lines are simple, the A0, A3 and A4 address registeres are loaded with three different memory addresses. By examining the addresses, I realized that A0 was the destination screen, and A3 and A4 were two lookup tables which I will cover further down.
In the next code you can see that we are loading the next byte from A1, and post-incrementing the address pointer. But what's in A1? As you may remember from the run loop above, A1 was set just before calling thus subroutine. After further inspection, it turned out that A1 is indeed pointing to the datas from dance.dat, although slightly offset.
The byte from A1 was loaded in to D7, and the code now attempts to clear the contents of (A0) "D7 times", and then one more time without incrementing the address pointer. This is probably an attempt to clear the previous image before applying the next.
The next byte from (A1) is loaded into D0. If it's zero, we'll jump ahead to $6720A, meaning we want to advance to the next scanline. If it's $ff (255) the code will jump to $67216, which is just an RTS - meaning the frame is finished.
This is where it gets interesting - and slightly confusing. First, D0 is copied to D1, and D1 is ANDed by $1F and shifted left by 2. In C, this would be D1=(D1&0x1f)*4;. D1 will later be used as an offset to look up in the table stored in A3, and this bit manipulation was to make sure the value is between 0..31 and multiplied by 4 to make sure it evens out with the 32-bit values in the table.
D0 is shifted left by 3 and then ANDed by $FC, which in C would be D0=(D0*8)&0xfc;. It's shifted left by 3 to multiply by 8, and ANDed by $FC to make sure it's not hitting an odd address - the 68000 doesn't like writing 16- and 32-bit values to odd addresses.
Now it's time to check if D2 is equal to D0. If it is, it means we're ready to draw the 32-bit value from the A4 table to the screen right now. If the carry is clear, we'll jump to $671F6. If neither of these kicked in, we'll draw a full 32-bit value of pixels before looping again.
This is the last part of the code, and it draws graphics from the A4 table.
The tables included in A3 and A4 are actually quite clever:
Using this technique, one can "compress" a single line of (simple) graphics down to just two bytes - a start byte and a stop byte.
So it all makes sense. I entered the code on my A600 and included the dance.dat file to my project. After correcting a few typos and inserting a few skipped lines, stuff started happening on my screen! We have a rendered frame. The next part was looking through the $66B0C subroutine to find the offset table, which was located at $3a000 if you ever need to find it. Turns out there are a total of 106 available frames in the animation - not half bad!
The original code is very slow, and leaves very little wiggle room for other routines. It spends anywhere between 60-100% CPU each frame rendering the graphics. I did some optimizations, such as using a few faster instructions, and double-buffering where the blitter clears one frame while the CPU renders in the next. I was able to get it down to 40-70% CPU which is good enough. I have plans to use this animation in an Amiga demo I will release later. I will also rip the music, but I'll save that for later...
If you made it this far and understood all my ramblings, my hat's off to you.
I wrote a little emulator for the Historic computer, and I'm currently using that as a toolbox for importing other systems into the firmware. It took a day of tweaking to get this thing running, but now I'm proud to show the fourth system this computer is capable of running. Here's the Commodore VIC-20 kernel running as if there's no tomorrow.
Now, I have to be fair, this just works. Lots of I/O's for the VIC-20 is located in the memory area where the 32K ROM currently sits, so it can't update those locations. However, the video image is as real as it gets: a big chunk of data being transferred between the RAM and the ATmega16 each frame to present the output.
As you may remember, this computer is already running a homebrew ROM, as well as unmodified ORIC-1 ROM, Apple ][ ROM and now the VIC-20's ROMkernal.
Any ideas for 6502 based arcade systems I should try?