blog.jmp.no

Electronics, coding and hacking. And ADD.

Engraving transparent stuff, making shiny things

2016
24
June

When I received this laser engraver, I read warnings against attempting to engrave transparent or metallic materials. Good thing I'm not a smart guy, so I decided to try it anyway. It had to work. Guess what? Turns out it works a treat!

I decided to try and make LED illuminated signs, kind of like those "exit" signs you see places. The principle is simple: light passes through the sheet, and wherever there are bumps, engravings or scars, light will exit.

I bought two sheets of 300x300x2mm styrene acrylonitrile. They are easy to cut and come with a protective film on each side. This is a good thing, because these guys scratch easily. The sheets were cut by tracing the desired route with an utility knife, and then giving it a friendly whack to split the board.

Here's the sheet with the protective film on each side intact.


Here you can see the transparent sheet (without the protective film) being engraved. It's from another project, but shows the job being done. It had to run at a low speed in order to have an impact on this particular material.


Dickbutts aside, here's the first successful project I made. A square blue LED is superglued in an bottom insert, flush with the rest of the board. The edges are quite illuminated, this can be prevented either with electrical tape, or painting the edges with a solid colour. I think it looks cool the way it is.


Here's the CR2025 battery wedged between the LED's cathode and anode pins, which conveniently serves as a rest. The internal resistance of this battery is so high that a current limiting resistor is not required.


By adjusting the focus and the burn time, I was actually able to cut through the 2mm styrene acrylonitrile completely. However, while experimenting with this I stumbled across something unexpected - but I'll save that for a later post. (How's that for a cliffhanger ending?)

Sharks with frickin laser beams, hold the sharks.

2016
15
June

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.

Pros:

  • Dirt cheap
  • Pretty much plug and play
  • Small and compact
  • Beginner friendly software

Cons:

  • 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.

Although my room now smells like a forest fire.

3D printer

2016
3
April

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 kilogtrams 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.

WiFi-enabled RC car

2016
21
February

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.


PT8A978BPE

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.


C++/Qt client

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.

Ripping graphics

2016
9
February

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:

l_6051e:
    dc.l %11111111111111111111111111111111
    dc.l %01111111111111111111111111111111
    dc.l %00111111111111111111111111111111
    dc.l %00011111111111111111111111111111
    ; etc...

In other words, the above table is used for looking up when to switch on a pixel. The l_605a2 table was done in similar fashion:

l_605a2:
    dc.l %00000000000000000000000000000000
    dc.l %10000000000000000000000000000000
    dc.l %11000000000000000000000000000000
    dc.l %11100000000000000000000000000000
    ; etc...

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.

Add to Google