This last weekend me and many others were participating at the third incarnation of the STNICCC Atari ST conference. The first and original one was held in 1990 – where sadly I didn’t attend – and the second one was held as a reunion in the year 2000. Back then they joked about meeting up again in the far far away future of 2015.
… and that happened. Me and two others from my old demo crew had written a brand new demo that we showed at the demo competition, and additionally I had been asked by the organizer to do a talk on the latest findings with regards to two of the Atari ST’s more magical demo tricks – overscan and sync scroll.
The talk was recorded, and I’ve uploaded a version where I’ve tried to clean up the audio to Youtube. My slides (even the final version which I was unable to use during the presentation) can be found in the video description.
update 2015-12-31: I mention in the talk that I will release source code showing how you can detect the wakestates yourself. Now done. Code and pre-built binaries here.
A few weeks ago I spent some time with the excellent sc68 software written by Benjamin Gérard (Ben/Overlanders). It’s a suite of software that can faithfully reproduce the workings of the YM2149 sound chip in the Atari ST and convert/play songs made for it. Additionally, which was the reason I took a look at it, Ben had made a VLC compatible plugin.
Since the Mac sorely lacks a competent playlist capable Atari ST music player (XSC doesn’t do playlists, Audio Overload isn’t fully compatible) I was really interested to see if the *nix support in sc68 was enough for me to be able to compile a working plugin for OS X as well.
It was. Enjoy. (I am! Thanks Ben :))
It’s somewhat easy finding modern software able to read ancient data formats (note, “somewhat”). It’s often more difficult finding the opposite – conversion from modern formats to older ones.
When I’ve wanted to edit graphics using modern software (GIMP) and convert it to Atari ST I’ve so far used the excellent Netpbm package. The steps have involved converting my image in GIMP to use a colormap of suitable size, save the image as a .ppm file and then use ppmtopi1 to (finally) get an Atari ST compatible low resolution image in “Degas” format, a popular image editor back then.
This weekend I grew somewhat tired at all those steps – and additionally I wanted to convert an image to the Atari ST medium resolution format (.pi2). There’s no such application in the Netpbm suite.
It’s not completely plug’n’play, but here’s a link to PNGconv, a project I just published to Github. It’s a Java program that takes any input format Java understands (JPG, BMP, PNG, GIF .. ) and outputs as Atari ST low/medium/high (.pi1/.pi2/.pi3).
I’m probably the only one who’s ever going to use it, but you know what they say about programmers. We’ll happily spend hours now making sure we’re spending “less” hours somewhere down the road ;)
-You’re getting a 3D printer? Why – what will you use it for?
-Oh you know, it’s handy to have around when stuff around the house breaks down. Making spare parts, repairs, stuff like that.
I’ve seen it lots of times. I’ve said it more than a few times leading up to when I purchased my own 3D printer. And finally it came true. Well, almost. Apparently when me and my sister, with families, visited our parents recently they felt the coffee machine needed a good cleaning. However, either because of the dishwasher or just due to age a piece of plastic holding a metal spring developed a crack – making the drip stop quite ineffective.
A perfect opportunity to show how useful a 3D printer can be around the house – wouldn’t you say? It also looked quite easy – there was plenty of room around the actual plastic component to force a printed holder, a belt of sorts, onto it. After careful measurements while I was there, which turned out to be in error, followed by renewed measurements by my father, I sent the printed part by postal mail earlier this week. And tonight I got the following picture.
The piece fits perfectly and the drip stop is back in action. Score one for the 3D printer – a few hundred more of these repairs and it’ll have paid for itself! ;)
Legend: Metal = spring, black plastic square = original & cracked, white square = newly printed part
It’s retro computing time again!
As part of my quite extensive rebuild of one of my Atari STE machines I want to have both an HxC SD floppy emulator as well as the original floppy disk drive mounted internally in the machine at the same time. While that in itself is just a question of making a cable that supports both, another problem quickly arises. In most cases you would want the machine to boot off the HxC (drive A:) and the internal floppy would then be drive B:. However, in some cases there’s clearly a point in booting off the internal floppy instead – and for that it has to be drive A:.
In real Shugart floppy speak this amounts to the drive select signals, DS0 and DS1. On a modern ST both are available on the internal cable, and one (DS0) on the external. What we want is obviously to mount a switch that will swap these two signals at will.
This is a solved problem. DS0 originates from pin 20 of the YM 2149 sound chip (really!) and DS1 is on pin 19. Cutting these two pins and then soldering two cables from the motherboard to the middle pins of a DPDT (dual pole, dual throw) switch and two cables from pin 19 and 20 to one side, crossed over to the other side, will do. It’s also possible to achieve a swap between an internal floppy and an external drive without cutting pins – some prefer to avoid that – but it won’t swap the two internal signals.
Yesterday I really wanted to avoid cutting pins – but at the same time I needed a way to switch not only internal and external, but the two signals on the internal cable as well. I thus had to innovate a bit, and this post details the result. All pictures from a regular STE – I haven’t looked into what’s different on a regular ST or Mega model.
This is our area of interest – before any modifications have been done. Pin 20 and 19 of the YM 2149 soundchip are clearly visible (upper left of the chip from this angle) – and you can also see that pin 19 can be traced to a via. There’s no visible trace from pin 20 – leading us to conclude that it’s on the bottom side of the motherboard. Also note the three solder points named W300 and W301 respectively (square solder pad is pin 1 on each) – these are very much involved in what we want to do. DS1, pin 19, is available on W300-1 and DS0, pin 20, is available on W301-1. We see that W301-1 can be traced to a via just below it as well.
Turning over the motherboard we can see that pin 20 is indeed connected to the same via we just traced from W301-1 – but it’s also traced to another via on the other side of the chip! This second via is found topside at the ‘C’ in ‘C113’. With this knowledge we can now conclude that if we do not want to cut the actual pins 19 and 20 of the sound chip, we have a few cuts to make to traces on the motherboard. We must cut both traces originating from pin 20 on the bottom side of the motherboard, before the vias, as well as the trace to the via topside from pin 19.
Make sure to measure resistance with an Ohm meter to know when you’ve cut through the traces, and don’t cut off anything else. There’s plenty of space on the bottom side of the motherboard, a bit less topside.
Once we’ve done these cuts, we’ve effectively severed the connections of the originating signals on the sound chip pins from where they go on the motherboard (internal cable as well as external port). However, we’ve also severed the connection between the two different directions pin 20 went off to – so we have to repair that topside. The easiest way is to solder a wire between the vias we just traced it to.
We also have to mount the wires to our switch, of course. We pick up the signals directly from pin 19 and 20 – to the end points of our switch (crossed over at one of the sides). We then solder wires from the middle pins of the switch to W300-1 and W301-1. And we’re done.
This will switch not only the signals on the internal cable – but also swap internal and external. It’s effectively exactly the same as what’s achieved by cutting the pins off the chip as described in many places on the web.
So why didn’t I just do that?
Well. I seem to have misplaced my side cutter. So .. there. Enjoy.
I just did a writeup on how to replace the original PSU in an Atari ST/E with a modern picoPSU. I’m quite satisfied with how it came out – click the link for some pretty pictures ;)
or: Why my Mac Mini from 2008 (model 2,1) went from Snow Leopard to Lion to Mavericks in the last 24 hours.
I like my Mac Mini. It’s the first Mac I ever bought, on a whim, and it’s served me well both as a workstation and lately more of a combined NAS, Minecraft and darknet server. I populated it with 4 (3.3 usable) GB RAM from the outset, and a few years ago I switched out its 5400 rpm hard drive for an SSD. If I remember correctly it came with Leopard but I bought Snow Leopard on the same day, or just afterwards.
Earlier this year Apple stopped supporting Snow Leopard with security updates (in my opinion, I know others disagree). Understandable, somewhat, and while I knew I could update it to Lion I had never really come around to doing so. The amount of apps not compatible with SL (Github, I’m looking at you) were quite low and often they seemed to require Mountain Lion anyway.
But. As a somewhat Internet facing machine I felt I needed to make sure it at least got security updates, and thus I upgraded it to Lion yesterday. It was a huge pain freeing up enough space on the internal SSD to be able to remove the per user FileVault encryption – but eventually I got it done.
And realized way too late that turning on full disc encryption with FileVault 2 kind of defeated the purpose of having a headless NAS in a closet – since any reboot now meant I had to connect at least a keyboard, possibly a screen.
A quick search realized that I wasn’t alone in feeling cheated – apparently in 10.8.2 (Mountain Lion) and Mavericks Apple added a possibility to pre-authorize an account when scheduling a restart because of this.
Lion is the end-of-the-line when it comes to OS support for my Mac Mini 2,1. It’s a 32 bit EFI system, and Mountain Lion onwards require 64 bit EFI support.
Enter a hacker under the alias Tiamo and a script written by a Mac Sysadm named Oem, called SFOTT. Sixty Four on Thirty Two. The script takes a valid Mavericks (or Mountain Lion) installation .app and patches it to consider the target hardware valid. It also uses a shim layer (Tiamo’s boot.efi) to patch through the 64 bit kernel syscalls to the 32 bit EFI on too-old hardware.
My Macmini2,1 is now running the latest version of Mavericks. That’s pretty awesome. Not yet headless with full disk encryption though – the pre-auth functionality has its own hardware requirements and still does not work.