Skip to content

Kokoon Relax headphones review

March 14, 2019

April 2018 I saw a Facebook ad for a pair of headphones that sounded like the perfect match for my needs. I’m a severe insomniac, and a frequent flier. I’ve had the same pair of Sony MDR-NC32NX in-ear noise canceling headphones for a decade, and I was looking for something new.

Yesterday they arrived. Now, this was originally a Kickstarter (and I have seen that not all backers have gotten theirs yet) but when I ordered they expected to ship them in July the same year. Delays happen.

Now, for the rest of this review. If you’re looking for the best sound quality, or the best noise cancelation, these are not the headphones for you. My circles tell me the Sony WH-1000XM3 would be what you’re looking for. If you’re however looking for an extremely slim profile with a focus on helping with relaxation and insomnia – keep reading.

After having unpacked them, and tried them on (wow – they’re heavy!) I charged them up and started to play around. Connecting them to my iPhone was no problem (they’re Bluetooth) and the Kokoon Relax app is nicely laid out for you to download calming soundscapes to have in the background. This worked well during the evening yesterday.

Later at night, I connected them to my Macbook Pro (again, wirelessly) when going to sleep. I listened to some tv-series and Youtube episodes, and then decided to try to go to sleep. No matter what audio source you’re listening to, they’re supposed to detect when you have fallen asleep and turn down the sound a few minutes after.

I’m a side sleeper, which Kokoon has this to say about:

Earbuds and bulky noise canceling headphones will make it difficult to sleep for side sleepers. By relocating the headphone electronics from the ear cups to the headband, we have been able to achieve the lowest possible profile, maintaining the natural shape and characteristics of the head in bed. Combining this with cushioning has enabled us to ensure the headphones are comfortable.

… yeah, no. I have the perfect pillows to support this (soft and deep) but there’s no way I can side sleep with these comfortably at home in my bed. That’s a bummer, because that was one of my hopes. However, I still need a pair of headphones for when I’m traveling, and I don’t always upgrade to business class so sit-sleeping is still a thing.

This morning (day of use #1) I was unable to connect the headphones to my phone when leaving in the morning. The battery had run flat, which I now realize is because while the headphones can detect that you take them off (and pause the audio) the ability to turn themselves off is still a feature in development. I then charged them at work, and tried again on the way home. I was still not able to connect – until I tried re-pairing them with the phone.

This caused me to believe that they can only be recognized by one device at a time – but this also turned out to be wrong. When back home, the audio kept disconnecting from the phone and at one point connected to the computer (where a Youtube video started playing automatically). So I had to turn off Bluetooth on the computer. But I still have had no luck this evening – the few times I’ve managed to connect the headphones to the phone I’ve had a few minutes at the most before they suddenly disconnect (and turn off – with a very unpleasant audible ‘pop’ in your ears) and I have problems connecting them back again.

I now tried to hard-reset (power+action buttons for some 10 seconds) them a second time but it seems the battery has run flat.

Conclusion after unpacking day and 1st day of use is: Wow, this is a very very unfinished product.

… to be continued

GrafX2 SDL2 version for macOS 64-bit

July 2, 2018
tags: ,

update 21/7: I’ll make regular builds of this, and hope to have it completely automated soon. They can be found here (link might change in the future):

original post: 12 hours ago SDL2 support was merged into the popular retro graphics program GrafX2. Here’s a fully distributable macOS x86_64 binary (only tested on macOS High Sierra) built from that.

Thanks to evil/DHS for letting me know of the new SDL2 support, even before it was actually merged ;)

(If you try to build from source yourself there are edits I’ve done on my local branch to make it build and include the support libraries/frameworks. Ask away)

Batterieliminera Ljusbox TORLEIF från Jysk

February 19, 2018

När jag fyllde år fick jag en ljusbox från Jysk av familjen. Barnen tycker den är helfestlig eftersom man kan skriva egna saker med hjälp av de medföljande bokstäverna, och den passade alldeles utmärkt på nattduksbordet. Den är, precis, stark nog att kunna fungera som sänglampa – än har inte åldern kommit ifatt min förmåga att kunna läsa böcker i dämpat ljus.

Däremot drivs den enbart av batteri (6st AA). För att ha den som långvarig mysbelysning kändes det suboptimalt, så idag satte jag mig och byggde om den.

6st 1.5V batterier betyder att den drivs med 9V. Jag hade redan en sådan nätadapter liggande, annars kan de köpas från Kjell & Company, där jag även köpte honkontakten för chassimontage.

Här kan man stanna, om man inte längre vill ha kvar möjligheten att använda batterier. Eftersom jag har gott om DPDT-switchar liggande var det dock inte mycket merjobb att lägga till möjligheten att växla mellan nät- och batteridrift.

Efter att ha öppnat upp ljusboxen (den är knäppt på, använd en flat skruvmejsel och bänd försiktigt tills du lyckats lyfta upp en kant. Skruvarna på baksidan håller enbart fast batterihållaren och behöver inte tas bort) så ser vi snabbt att konstruktionen är väldigt enkel. Batteripacket är kopplat minus direkt till LED-slingan, och pluspolen går via strömbrytaren.

Vi återkommer strax till omkopplingen, men först sätter vi dit de nya kontakterna. Jag använder en liten dremel för den här typen av arbete, samt en nagelfil av metall för att göra fyrkantiga hål fyrkantiga. Desto mer tid man lägger ner på att få det snyggt, desto bättre blir det. Här lade jag ner medelmycket tid.

Och därmed är vi framme vid omkopplingen. Batteripackets minus samt pluspol går till de två lödöronen på ena sidan switchen, och till den andra sidan kopplar vi plus och minus från DC-honan. Mitten på switchen kopplas minus till LED-slingan, och plus kopplas via strömbrytaren.

Och sedan är vi klara. Tack vare DPDT-switchen finns det inget problem i att ha både batteri samt nätadapter inkopplade samtidigt, även om det är lämpligt att enbart ha det senare för att inte riskera att oanvända batterier ligger och läcker.

En av bilderna här är tagen med batteridrift, en med nätdrift.


(Och som ni förstår öppnade jag raskt upp ljusboxen igen och flyttade in kablarna till kanten … )

Atari ST wakestate nudger

January 14, 2018

I’ve added yet a new little description to Projects – a circuit and modification to “nudge” wakestates on Atari STs without needing to power cycle.

Atari ST new video modes

October 12, 2017

I’ve done an extended writeup of a little project I’ve been working on and off on for the last few months. Extending the video modes of an old Atari ST in new and interesting ways.

Going from 4 colors to 16 might not sound much with today’s tech, but for us oldies this is pretty fascinating ;)

Hatari macOS nightly builds

June 19, 2017

For a few years now I’ve helped out the excellent Hatari Atari 16/32 bit emulator project with macOS builds. However, the Hatari release cycle is about once every year and I’ve myself noticed that the developments that take place in between are very useful and so I’ve sporadically made development builds available as well. Sometimes. When I’ve felt like it.

Of course, I can do better. While I don’t have a 24/7 macOS server running, and thus can’t completely automate a nightly build setup, my laptop will now try to produce new builds (whenever the source repository has changed) during other usage and publish them here: Hatari macOS nightly builds.

Please let me know if you find this useful, and if there are any changes I could do to make it even better.

The tale of high density Atari mystery

January 20, 2017

The Atari ST, like other computers at the time, had Dual Density disk drives with 720KB of storage. DD for short. Since High Density (1.44MB) appeared shortly after, Atari used such drives in the more top of the lines models Mega STE and TT. Additionally, us enthusiasts and hardware hackers added HD capability to the regular ST and STE range since it was neat to store twice the amount of data on suitable disks (and it worked pretty well cutting a hole in DD disks tricking the drives into thinking they were HD, even though the magnetic layer is slightly different).

All the above is of course very well known. However, recently I’ve managed to dig up some less well known information as well as adding new discoveries about our dear 30 year old hardware. This is a post about that.

Atari used several different makes of DD drives in the ST computers, but one of the more common is the Epson SMD-380. For the higher end models with HD support Atari however used one model exclusively, the Epson SMD-340. For after market HD modifications of ST:s one drive in particular became quite popular, the Sony MPF-920. If you search online for kits and instructions, that’s the drive you’ll find the most info on.

It’s not only the drive that decides whether to write in Double Density or High Density however. The data needs to be clocked faster through the drive onto the disk, and so it’s not enough just swapping in and out the drives mentioned above to choose between DD and HD support. A neat little trick is that the floppy controller used by Atari, the 1772 (made by WD and VL), outputs a DD capable signal when clocked at 8MHz and HD when clocked at 16. In a regular ST it’s always clocked at 8MHz, and in the Mega STE and TT Atari used carefully tested chips that could do 16MHz (and later elected to produce a variant themselves, known as the AJAX chip, that was designed to run at 16).

The way to get HD support in a regular ST is thus to clock the floppy controller at 16MHz when writing/reading an HD disk. I might be misremembering, but I think my own first HD mod needed manual selection through a switch and so I needed to select the right position depending on the disk I used. A much better option is of course to ask the drive if there’s a DD or HD disk inserted, and switch clock speed depending on that. This is what’s well documented for the Sony MPF-920 and is how the many different “HD kits” know what to select.

Now here’s where things start to get confusing. In many places you can find documentation to the effect of pin 2 of the floppy interface being a density select signal. An output. While that might be true for some drives, my research says that it’s an input. The Atari Mega STE and TT (the Epson 340 drive) does not get told whether there’s an DD or HD disk in the drive, and yet they still have full support for both formats. This part of the mystery took me to an old discussion thread from 2008 which seems to be the first time someone actually looked into how this was done. There’s a memory mapped register, handled by a PAL chip, that the Atari operating system (TOS) writes to to set the clock frequency of the floppy controller. The logical conclusion is thus that TOS switches frequency when encountering errors and retries.

In that sense, the after market ST mods did a much better job. The drive told a piece of circuitry what it should use and the clock frequency was then set correctly. Many many ST top cases have been horribly butchered to make room for the normal eject button of most HD drives instead of Atari’s nice slanted cutout.

Of course, I wanted to make my tricked out STE (see other posts) read HD disks as well, since I spend a lot of time archiving lost treasures and sometimes come across HD disks. I did not want to butcher the top casing though.

Idea: Use the same HD drive as Atari. The front plate and eject button of the Epson 340 and 380 are interchangeable, and the Epson 340 can still be found used online (and after some digging I found that it was also sold by Hewlett Packard under their brand as D2035-60011). I also bought an HD-kit from exxos that seemed to handle some obscure effects (steprate issues) adding HD to ST:s can cause.

hdkit_hp_epson

Here’s where I realized that although it’s easy to find where to pick the density detect signal on other drives (like the Sony) absolutely no one seemed to have ever done it on Atari’s HD drive of choice (!). After some measuring and tracing I found the spots to use, and although the drive can be set to handle density internally I also only got it to work if giving the drive its own density detect signal as input on the density select pin #2, and told it to use the external signal (jumper 1-2 & 5-13).

epson340_density_signal_small_instr

Since I have two drives internally (an HxC and the internal floppy) and a switch to choose which is A: and B: respectively, I also had to create a logic table on which signals should select which input and density. The result was (disregard the wiring on the image, I don’t seem to have one from the final conclusion) that the kit should get post-switch signals and D1 should get density detect from the drive. With all this done, my STE now has full DD and HD support – with a beautiful and newly refurbished Epson 340 as the internal drive. I save my case cutting for LCD displays, SD card slots and USB ports ;)

DD: YM DS0 —— no switch —— HD-kit DS0 —— cable DS0 (8MHz) = floppy A:
DD: YM DS1 —— no switch —— HD-kit DS1 —— cable DS1 (8MHz) = HxC B:
DD: YM DS0 ———— switch ———— HD-kit DS1 —— cable DS1 (8MHz) = HxC A:
DD: YM DS1 ———— switch ———— HD-kit DS0 —— cable DS0 (8MHz) = floppy B:

HD: YM DS0 —— no switch —— HD-kit DS0 —— cable DS0 (16MHz) = floppy A:
HD: YM DS1 —— no switch —— HD-kit DS1 —— cable DS1 (8MHz) = HxC B:
HD: YM DS0 ———— switch ———— HD-kit DS1 —— cable DS1 (8MHz) = HxC A:
HD: YM DS1 ———— switch ———— HD-kit DS0 —— cable DS0 (16MHz) = floppy B:

hd_install_done

(Oh, and since Atari had their own way of handling media change detect – knowing when a new disk had been inserted and you needed to re-read the FAT – a lot of disks have been trashed from the use of non-compliant drives. The exxos kit above has an optional workaround in that it always forces a re-read, but the best solution is of course to use the same HD drive as Atari did, and not having to use any media change workarounds at all)