Im somehow interested in audio production, but only as my hobby. My main job is lead of control system installation in research facility. So that means I usually dont want to spend huge money on the equipement.
And rigth about now is quite good time to get some old-ish wireless audio equipement for decent price. The reason is that there was change (info) in wireless bands and bands that were free before are not avaliable for the professional audio eq. That means that lot of productions are ditching their stuff to buy new one, compatible. But not all the old stuff is useless as some of it can be reprogrammed. As there is tigth window from 822 to 830 Mhz in EU. This window is quite narrow, but at least it free all the time. Other option is to go below 700Mhz, but then you migth get into collision with local TV transmitter. So I settled for the narrow band since I dont plan to use too many transmitters at once.
The “double ratchet” algorithm is integral to modern end-to-end-encrypted chat apps, such as Signal, WhatsApp, and Matrix. It gives encrypted conversations the properties of resilience, forward secrecy, and break-in recovery; basically, even if an adversary can manipulate or observe portions of an exchange, including certain secret materials, the damage is limited with each turn of the double ratchet.
The double-ratchet algorithm is a soup of cryptographic components, but one of the most computationally expensive portions is the “Diffie-Hellman (DH) key exchange”, using Elliptic Curve Diffie-Hellman (ECDH) with Curve25519. How expensive? This post from 2020 claims a speed record of 3.2 million cycles on a Cortex-M0 for just one of the core mathematical operations: fairly hefty. A benchmark of the x25519-dalek Rust crate on a 100 MHz RV32-IMAC implementation clocks in at 100ms per DH key exchange, of which several are involved in a double-ratchet. Thus, any chat client implementation on a small embedded CPU would suffer from significant UI lag.
There are a few strategies to rectify this, ranging from adding a second CPU core to off-load the crypto, to making a full-custom hardware accelerator. Adding a second RISC-V CPU core is expedient, but it wouldn’t do much to force me to understand what I was doing as far as the crypto goes; and there’s already a strong contingent of folks working on multi-core RISC-V on FPGA implementations. The last time I implemented a crypto algorithm was for RSA on a low-end STM32 back in the mid 2000’s. I really enjoyed getting into the guts of the algorithm and stretching my understanding of the underlying mathematical primitives. So, I decided to indulge my urge to tinker, and make a custom hardware accelerator for Curve25519 using Litex/Migen and Rust bindings.
In this project I added a Raspberry PI Zero to the insides of the laptop. Both are connected via a serial link and can exchange data via it. You could use this for several applications:
Using the 286 with a terminal emulator as an interface to the Linux of the Raspberry PI. This way you can do the typical Linux shell stuff on a retro machine. With this you are quite far up on the hipster level
Connecting the DOS on the 286 to the Internet
Transferring files to the DOS filesystem
It’s been over a year since the original PinePhone, also known as the “Braveheart” edition was made available. When I reviewed it, it showed a lot of promise, despite being intended for developers. While the software has been incredibly improved since then, it failed to replace my Android phone.
The problem revealed itself when I tried to sort out why I couldn’t use a USB hub with the device. I tried every one in the house, and then even a few more, and none worked. More research landed me on the PinePhone Wiki, where I found a page listing various hardware issues discovered in the Braveheart.
A possible fix was to remove several tiny components on the board to correct the USB issue. This, however, would only fix one of several problems I was having. The worst of which was it didn’t have enough memory. The newer Community Edition PinePhones have 3GB of memory in addition to other hardware fixes.
Instead of buying a new PinePhone outright, I decided instead to do something I never attempted before:
Replace a phone’s mainboard.
I became interested in high precision GPS time after listening to a podcast about network clock synchronization on Signals & Threads. My original goal was to setup a local NTP time server that I could sync all my devices to. However, I got sidetracked along the way – and this is the story of my Raspberry Pi home dashboard.
The Apple M1 available in the MacBook Air, MacBook Pro 13”, and Mac Mini has been the focus of a ton of benchmarking writeups and blog posts about the new chip. The performance overall, and especially performance/watt, that Apple has achieved with the chip is very impressive. As a ray tracing person, what caught my eye the most was the performance AnandTech reported in their CineBench benchmarks. These scores were 1.6x higher than I got on my old Haswell desktop and 2x higher than my new Tiger Lake laptop! I had also been interested in trying out the new ray tracing API for Metal that was announced at WWDC this year, which bears some resemblance to the DirectX, Vulkan, and OptiX GPU ray tracing APIs. So, I decided to pick up a Mac Mini to do some testing on my own interactive path tracing project, ChameleonRT, and to get it running on the new Metal ray tracing API. In this post, we’ll take a look at the new Metal ray tracing API to see how it lines up with DirectX, Vulkan, OptiX and Embree, then we’ll make some fair (and some extremely unfair) ray tracing performance comparisons against the M1.
Given the scarcity of combo organ top octave generator ICs, what’s a hack supposed to do? Emulate!
I posed a “bar bet” against myself — can I emulate a top octave generator chip with an Arduino? The Arduino is a bit slow and I wasn’t sure if it would be fast enough for the task. Good thing I didn’t best against it…
If you browse the Web, you’ll find other solutions. I chose Arduino UNO out of laziness — the IDE is already set-up on my PC and the hardware and software are easy to use. Plus, I have UNOs to spare. Ultimately, one can always cobble together a barebones solution consisting of an ATMEGA328P, a 16MHz crystal and a few discrete components, if small size is an issue.
There is nothing I find more liberating than to spend a Saturday afternoon coding on some toy project.
There is no expectation or obligation to ever become more. It is just for fun, learning, and curiousity. I can add whatever features I want. I can use whatever technologies I want. I can throw it all away if I want. These are the projects I yearn for and look forward to when I’m busy with work.
Perhaps George Bernard Shaw was on to something: “We don’t stop playing because we grow old; we grow old because we stop playing.”
Funny enough, Titus Barik published a paper that contributes a qualitative analysis on the sentiment of programming and play on Hacker News. The themes he found include play as artistry, catalyst, fun, playgrounds, spontaneity, tinkering, and anti-work. There is a quote that I particularly like, “The joy of programming for programming’s sake is something you do in your own time.”
This is not a transistor computer. In fact, it is a computer with a CPU made up of discrete transistors, and the CPU instructions are composed by microcode stored in the same memory that also contains the application program.
This computer consists of 1897 transistors for the CPU, 598 transistors for the four 8-bit I/O-ports and additional 124 transistors for the LCD I/O board. Furthermore, three integrated memory chips were used. Of course it would be possible to build the SRAM chip with transistors and the ROM chip with transistors and diodes as well, but this would have required much more transistors.
The complexity of my design is somewhere between the Intel i4004 CPU (2250 transistors) and the 6502 (3218 transistors). The i8080 already has 4500 transistors and the Zilog Z80 even has 8500 transistors, so you get an idea how small my design still is. The most complex component that I use in the computer is the EEPROM memory chip. And even the LCD is also more complex than the TraNOR CPU.
My design goal was to build a transistorized computer that is 100% compatible with MyNOR. I have reached this goal, software written for MyNOR runs on TraNOR with the same speed. And TraNOR doesn’t need a special EPROM image either, it also works with MyNOR ROM v1.0 and later versions.
Bit banger is built around an ATtiny15 microcontroller, which runs at 1.6 MHz and has 1 kB of flash ROM and a claustrophobic 32 bytes of RAM. In fact, those 32 bytes are the CPU registers. Only the most basic AVR instructions are supported; they occupy at least two bytes each, and can obviously not be compressed since they are executing from ROM, so a maximum of 512 instructions will fit inside the chip (fewer if static data is needed).
The microcontroller supports interrupts, but they would have been too costly to use. Instead, the entire demo is cycle counted.
At a clock rate of 1.6 MHz, the visible part of each line of the VGA signal swooshes by in exactly 36 clock cycles. The entire line, including horizontal blanking, is 51 clock cycles wide. During this time, both graphics and sound must be generated.
I quickly arrived at the following overall design: Three registers make up a 24-bit frame buffer, organized as a 3x8 grid. Every 60 raster lines, these registers are rotated one bit, to prepare for the next row of the grid. At three different positions along the visible part of the line, the MSB of the corresponding frame buffer register is interpreted as an instruction to either keep or invert the current colour; the resulting colour is then transmitted onto an output pin. At the end of the visible line, black is selected.
In the gaps between these four positions and the two places where the horizontal sync signal is flipped, sound must be generated and emitted. The ATtiny15 luckily has a PWM output that runs on a separate peripheral clock at a staggering 25.6 MHz, which is high enough for 8-bit audio output. Writing a sample to the PWM output is a simple one-cycle instruction; the challenge is to calculate the value of the sample during the remaining clock cycles.
Many consumer personal tracking devices seem to have a shelf life of only a couple of years. So if you’re interested in keeping a long-term history of your progress, you have to figure out how to work around their apps to get your own data back from their servers. Otherwise, the day their app or servers stop working, your data will simply disappear.
I’ve used two tracking devices where data was not easily exportable, the Microsoft Band (shut down May 2019), and the Hello Sense (shut down June 2017, and never sent the data export instructions that they said was forthcoming), so I’m documenting the process I went through to retrieve my own data in hopes it may be useful for others trying to do the same for other devices.
As part of my work on reverse-engineering eInk price tags I ran into an interesting problem. One particular company (Samsung Electro Mechanics/SoluM) switched from a third party chip I had figured out (Marvell 88MZ100) to a new chip in their next generation tags. This chip seemed to be made by them, custom, for this purpose. This never bodes well for reverse-engineering. A friend provided me with a few tags containing this chip to play with. There were two types that had a segment-based e-Ink display and one that had a normal graphical eInk display. They had the same main chip on them, so I started with the segment-based device, since it is easier to understand a simpler unknown system. It was not quite clear where to start, but, of course, that kind of puzzle is always the most interesting!
Among security professionals, a “drop box” is a device that can be covertly installed at a target location and phone home over the Internet, providing a back door into what might be an otherwise secure network. We’ve seen both commercial and DIY versions of this concept, and as you might expect, one of the main goals is to make the device look as inconspicuous as possible. Which is why [Walker] is hoping to build one into a standard USB wall charger.
This project is still in the early stages, but we like what we see so far. [Walker] aims to make this a 100% free and open source device, starting from the tools he’s using to produce the CAD files all the way up to the firmware the final hardware will run. With none of the currently available single-board computers (SBCs) meeting his list of requirements, the first step is to build a miniature Linux machine that’s got enough processing power to run useful security tools locally. Obviously such a board would be of great interest to the larger hacker and maker community.