nmelnick

The Comeback of a Language

2007-06-22T00:00:00Z

Not sure what was going on with me this morning, but I think I was trying to pick a fight in #catalyst this morning. I was at work all of about ten minutes before I asked a simple question, amounting to: "Are there any plans to bring Catalyst to a wider audience?" Confusion followed, followed by a decent discussion. The general point I was trying to make is simple. If you ask someone who works near web development if they've ever heard of Ruby on Rails, chances are, they have. If you ask them about Catalyst, you'll usually end up with a shrug. Those who are willing to listen further generally stop listening as soon as you say "framework for perl".

There is a stigma attached to perl for various reasons -- people view perl as unreadable, or slow, or hard to develop in on a large scale. Most people have a perception of perl that dates back to the late 90's, coding against cgi-lib.pl or CGI.pm. Hell, back then, I was rolling my own CGI scripts so they were 'lightweight'. God forbid anyone look at my code from back then. Perl was pushed as a rapid-development, but hacky language, and most people produced a lot of code that looked like line noise or otherwise, and that is what is burned into people's minds. There is an unfortunate percentage of the current perl population that still writes kludgy one script wonders and calls it a web application, and that's also bad for the community, in my opinion. Frankly, a language that holds contests on who can make the most unreadable code, or who can fit the most into one line, generally deserves that stigma.

The other side of the coin is Perl 6, the upcoming complete rewrite of Perl. If you Google for perl 6, you'll find articles talking about its impending release dating back to 2001, yet we still don't have a final revision. The bytecode interpreter is far from complete, and the closest thing there is to a working, usable interpreter is written in Haskell, another higher level language. The whole thing feels kludgy and incomplete to an outsider, and that's probably because compared to other modern object oriented languages like Ruby and Python, Perl 6 is kludgy and incomplete.

So, disillusionment and wankery abounds when it comes to perl, and a lot of it is deserved. It's a perception problem, and one that is almost impossible to solve. But, hell, I'm stubborn, and other people have made far inferior products rise from the ashes.

Those who remember a few years back realize that not many people were aware of or used Ruby before Rails came out, and a lot of old perl hands fell right into Ruby because of its similarities. I find Ruby to go against 'what I mean', so it's a reach when I start pounding out any code. I was hoping to find an alternative when I stumbled upon Catalyst, and I've been hooked since. I think quite a few people would see the same thing, if they only knew what was there.

My plea to #catalyst was simple. Catalyst is a diamond in the rough, a flexible, fast, and powerful web application framework that is very easy to use once you get over the first learning curve. It is an excellent demonstration of modern OO perl development, despite any flaws or issues that still remain in the framework. The problem, however, is there is very little marketing or outreach happening, and without any kind of constant public opinion, the userbase stagnates and eventually shrinks, leaving frameworks like Catalyst to die on the vine. Someone within the Catalyst community, or even tangentally related to the Catalyst community needs to find a way to bring people back into the perl fold by making them aware of the strengths of the framework.

A few things would need to happen, in no particular order. Note that this is only my opinion, and I'd be happy to be told I was wrong.

They want their wiki moved from Trac to MojoMojo before they do any major wiki work. Fine, I'll give that one.
Get some nice looking skeletons into the default Catalyst project template. Make it look pretty. For some reason, this actually works, and makes people want to do the same.
Catalyst's primary development happens on mailing lists and on IRC. This should be outlined somehow within the wiki so creep doesn't occur.
The primary focus of catalystframework.org should be marketing and outreach -- a bulletproof example of the stability and scalability of an application written in the framework, with easy to deal with tutorials and a complete set of hyperlinked documentation. Links should be given to external sites who use the framework, as well as third party Catalyst tutorial sites.
There needs to be a third party tutorial and development site! You can toot your own horn, but it's hard to convince people that what you have works really well unless they can see other people getting together and doing things really well. The real championing of OS X doesn't happen on apple.com, so the real championing of Catalyst shouldn't be on catalystframework.org. Luckily, it's not, as the site is a bore and makes the project look dead, as it is hardly updated.
Along with the third party site comes some community support. Bring people together. Show people to IRC, bring people to a forum. Get a forum of a couple of hundred and hold CatalystConf or something similar. The key to getting the product into the eyes of many is to show people that there is an active following behind it. Lesser languages and frameworks do it and give people confidence to continue developing. Check out Lasso and REALbasic if you have no idea what I mean.
Tell people you're using Catalyst. If you run a site that is truly great, and starting to get public attention, mention the framework. The Rails apps are doing it. The PHP people just try to hide that it's PHP behind it.

I'm not talking about zealotry, here. I'm not talking about Catalyst being the best or brightest, or that perl is the best or the brightest. I'm not talking about how Ruby, Python, or PHP suck (this time). I'm only talking about bringing a really great language and a fantastic framework into the foreground so people are at least aware of the options before they talk some smack.

Or maybe, just maybe, I'm completely full of it.

Rest in Peace, Mr. Butterfield

2007-07-01T00:00:00Z

Jim Butterfield died last night at 1:30 in the morning, from complications from cancer. He inspired many a geek who hacked their way through Commodore 64's in the old days. He certainly helped me explore the inner workings of computers, and he will be missed.

The sad thing is that he leaves with a whimper, when he was such an influential person in the 80's, in that scene. Anyone who opened a copy of COMPUTE, COMPUTE's Gazette, or RUN knows who he is, and how brilliant he was.

My best wishes to his family. Know that he left his mark on so many people, and he will be remembered.

For some reason, this amused me

2007-08-01T00:00:00Z

This amused me. :)

Because you can't tell a great hacker except by working with him, hackers themselves can't tell how good they are. This is true to a degree in most fields. I've found that people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent.

From Great Hackers

Happy 25th Anniversary, Macintosh.

2009-01-25T00:00:00Z

Twenty-five years ago today, January 24th, 1984, Apple offered the first Macintosh for sale to the public. Released with a huge amount of fanfare using arguably the first high-budget "Super Bowl Ad" during Super Bowl XVIII on January 22nd, Apple aimed to change the computing marketplace forever. Contemporary personal and business computers used a command line driven interface to operate, and programs written for these platforms followed the same type of functionality. IBM's PC, Commodore's 64 and 128, even Apple's II series all followed the same idea, and few computers on the marketplace tried to change that at the time. The big contender, Apple's Lisa, was a market flop, mostly because it was sold at over $10,000, 5x the amount of the average business computer at the time. Macintosh offered a 32-bit processor (on a 16-bit bus, but let's not get caught up in the technicalities), 128k of RAM, a high resolution monochrome screen, and a mouse to control one of the friendliest user interfaces at the time. $2,499 was very steep in 1984, but it took the world by storm, and became the envy of every platform.

We got our first Macintosh in the fall of 1986, a smoke and fire damaged Macintosh 512K Enhanced, complete with an Apple HD20 (20mb hard drive!), a LaserWriter Plus printer and an Abaton Scan/300 sheet-fed scanner. My grandmother's house had burned to the ground, and her basement tenant and friend was getting into desktop publishing -- this was her machine. My dad took the machine in while she was relocating, cleaned the smoke damage out of everything, and powered it on. I remember hearing the chime the first time and watching it power up, and it was completely different than the Commodore 64 I grew up with. My dad let me play with MacPaint, and I was hooked. It wasn't until years later that I realized my dad was letting me play on a setup that was $15,000 when purchased new in 1985.

That machine lasted me until 1993 as a full time machine. I learned Pascal, HyperCard, and MacBASIC on that machine. I did the best looking school papers and projects on that machine, using the scanner to include maps and other data, and using the laser printer to provide crisp, clean printouts. I had Aldus PageMaker and Microsoft Word to create brochures, flyers, and homework. I ran a BBS off of WWIV/Mac for a couple of years. I tried to squeeze System 6 and MultiFinder in the scant, un-upgradeable 512K of RAM. I got into the first BBSs with MacTerminal, and later, ZTerm, all with my Racal Vadic 1200 baud modem, and later, my generic Hayes-compatible 2400bps modem. I really, really used that poor machine with the warped, fire damaged vents.

To this day, that machine boots, hard drive and everything. The LaserWriter Plus and Abaton scanner were sold off by the next owner long before.

The machine taught me about typography, user experience, software development, and the appreciation of a great graphical user interface. I've had many PCs and Macs since, and they are exponentially better than that poor little FatMac I used to have. Without Apple's leadership with that little machine, though, the computing world would be a far different place.

I just had to share.

Happy 25th anniversary for your crazy creation, you guys. Thank you.

MooseX::Declare, TextMate, and TmCodeBrowser

2010-02-18T00:00:00Z

Do you use TextMate?
Do you use TmCodeBrowser?
Do you use MooseX::Declare?

Must be a pain that nothing shows up the side pane when you start using it. It was for me.

Open '~/Library/Application Support/TextMate/PlugIns/TmCodeBrowser.tmplugin/Contents/Resources/.ctags.tmcodebrowser' in a text editor. Add the following:

--regex-perl=/^[ t]*(class)[ t]+([^ t;]+)s*[ t]*[{;]/2/c,class,classes/--regex-perl=/^[ t]*has[ t]+'([^ t;(]+)'/1/p,property,properties/--regex-perl=/^[ t]*method[ t]+([^ t;(]+)/1/m,method,methods/

Reload TextMate.

Bask in the awesome.

Fun facts for hard times

2011-04-09T00:00:00Z

When developing for Android, the default button height is 48 dip.

Lifecycle of an Android Application

2011-04-20T00:00:00Z

Every time I get a new gadget, something possesses me to try to write an application for it. It's happened with dang near everything since the Newton, yet only a few gadgets have ever had a finished project. I tried the hardest on Symbian, but never came up with anything useful. I'd like to blame the SDK, but you should never blame your tools, no matter how much they completely sucked.

In October of 2008, a brand new T-Mobile G1 arrived via UPS, one of the first Google Android devices to hit the market. I had always owned smartphones, whether they ran Windows Mobile or Symbian (S60 or S80), but I wanted to get something that was easy to develop for, and would work well on my network. So, Symbian was out (hated the SDK), iPhone was out (Just started supporting apps, plus no one wants to be on AT&T), Blackberry was out (SDK even worse). Android seemed like a really neat, but young option. Being on the bleeding edge never scared me, it just usually screwed over other people.

So, approximately 3 days after receiving that G1, I downloaded the SDK, and started to use my extremely rusty Java skills to bang out a LiveJournal client for Android. It's not as though I still really used LiveJournal, but I felt like it'd help me try out all of the neat APIs in Android. Web services, location tracking, image capture and manipulation, they were all there and usable. A shell of an application started to emerge around a series of mocked up layouts, and I was able to hook up login, posting, preferences, and user pictures in a short amount of time. ElJay was born, and I even wrote about it here. I'm amused at how proud I was that it was pretty complete after a few days -- because it shows. Since I decided to dive right in instead of going through tutorials and example applications, it was subject to many of the first time Android developer errors. Screen rotation would lose settings, or interrupt a login, or interrupt a post. Web activity would throw exceptions that I never caught. Nothing was in a service, so switching applications or views would interrupt the same interruptables as above. Everything I did was in onCreate, so switching back to the application after Android cleaned house meant that someone would have to log in again. Sometimes, state wasn't kept, so you'd post to no account at all. It was a barrel of laughs. I updated and updated until it was a mess of spaghetti code and generic exception catching. Android 2.0 finally broke it, and I didn't care for a while.

I eventually pulled it from the market.

... until the screams entered my inbox.

A few weeks ago, I recommitted to ElJay, but instead of running through to try to fix it, I made the best and worst choice I could make, and started over. This time, I started it as if I were doing one of my Perl-based web applications, or writing a desktop application -- I started with the back end. My first task was my XML-RPC interface, followed by my LiveJournal model. I created a unit test suite for those external interfaces. I created a suite for all of my display controllers. After a while, I got to the point where I had a decent unit test suite, and a few test accounts that passed the unit test suite. This process took a lot longer than the "few days" it took to bang out the first version, but from a system level, it worked well. It also helped me solve a long-standing bug I ran into in the first version, where the default Java XML library used by Android doesn't handle some output from LJ very well. Hey, I could have saved myself from a rewrite! ... Nah.

Tangent.

Only then did I start working on the user interface. This time, I could actually plan for exception handling, threading, the external service, the sync API, even basic user interaction. It also honors resolution independence properly, since I'm no longer using pixels as measurement. :P It's amazing how much more confidence I feel in this application -- not that I believe it's bug free or foolproof, beta testing will prove that wrong within minutes -- but that I can easily work with it, fix issues, and section pieces out for later. Things are getting really close now, and the beta rolls out in less than two weeks.

For those keeping track, the first version allowed posting with user pictures, security options, tracked your location, worked with tags and moods, and allowed you to save entries for later. The new one does all of that -- and well -- but also adds friends list support, attaching photos to your posts, and with any luck, manage your messages. I'm also throwing ads in, but they're optional.

It does live.

Detecting scrolls in an Android ScrollView widget

2011-05-31T00:00:00Z

So, Android.

You would think that Google would have an event available for when someone scrolls a ScrollView widget. After all, it's the basic way to make some view scroll. Even better, there is an event for the AbsListView and other scrollable widgets. Turns out, there is an event that gets fired in a ScrollView, but you have to subclass the widget to get at it. Then, you have to figure out how to get that message back to your controller.

Lame.

So, for those of you who want to see if a scroll changed on a ScrollView, do the following:

Create a class, call it whatever you'd like, but subclass ScrollView. You'll probably need to override the three existing constructors to be able to instantiate from your controller or XML layout.

public class ExampleScrollView extends ScrollView {
    public ExampleScrollView(Context context) {
        super(context);
    }
    public ExampleScrollView(Context context, AttributeSet attrs) {
        super(context, attrs);
    }    public ExampleScrollView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);
    }
}

Add an interface within our new class to be able to set a listener. We'll call it something different so we don't override any existing OnScrollListeners.

public interface OnScrollViewListener {    void onScrollChanged( ExampleScrollView v, int l, int t, int oldl, int oldt );}

Let's add a private attribute and a way to set that listener in the class.

private OnScrollViewListener mOnScrollViewListener;
public void setOnScrollViewListener(OnScrollViewListener l) {
    this.mOnScrollViewListener = l;
}

Now, set onScrollChanged to fire the event we provide.

protected void onScrollChanged(int l, int t, int oldl, int oldt) {    mOnScrollViewListener.onScrollChanged( this, l, t, oldl, oldt );    super.onScrollChanged( l, t, oldl, oldt );}

You're done! You can now set up one of these in your XML layout, or built on the fly. Set your new listener like this, provided you have one in your layout with an id of 'example_scroll_view':

ExampleScrollView exampleScrollView = (ExampleScrollView) findViewById( R.id.example_scroll_view);exampleScrollView.setOnScrollViewListener( new OnScrollViewListener() {    public void onScrollChanged( ExampleScrollView v, int l, int t, int oldl, int oldt ) {        Log.d( "Scroller", "I changed!" );    }} );

Adventures in Vala: Ambition Framework

2012-07-18T00:00:00Z

Quite some time ago, I posted about my Adventures in Objective-C, postulating that people would be willing to rapidly develop in a static-typed language if the language was easy to deal with. I created the foundation of a web framework that didn't do too much, but was functional enough to prove that it was possible. I also gave up shortly after, as I found development on Windows and Linux to be a gigantic pain -- too few libraries, not much support.

Some of the same ideals I was going for in that previous post still hold true. Java still clicks in a weird way for me, even if it's too verbose and runs in a VM and 90% of the web frameworks for it annoy me to death. Objective-C was cute, but mostly useless for me. I don't mind the idea of C#, except for the fact that it's Windows-centric, and I'm still uncomfortable putting my eggs in the Mono basket.

In the meantime, I stumbled across a language called Vala. Vala's roots are in the GNOME community, where they have a couple of great C libraries: GLib, and included in that, GObject. Using this standard library, C-based GNOME applications have had a lot of the great benefits of object oriented programming while maintaining the speed and support of the C language. Unfortunately, you got everything else that C provides: no memory management, no namespaces, and difficulty in reading it later.

I'm going to get flamed for that.

Nevertheless, other people saw some of those same things. They also saw some Mono applications creeping into the GNOME core, and felt that all the pieces were there to do something better. Vala was born as a true object oriented programming language, with a very similar design to C#. The difference is, it relies on GLib and GObject to accomplish the OO goals, and therefore, compiles into C, which is then compiled by gcc. As a result, you get significantly smaller and faster binaries than VM-hosted languages, with very minimal pain. Furthermore, you don't need to use GTK or anything like that, it's still a general purpose language that can be hosted on any platform that can compile GLib. That means I can code on OS X and Linux, and, while I haven't done it in a while, Windows can join the party as well.

You see where this is going.

In the end, I took my ideas for a reasonable web framework, and started porting them to Vala. Months ago, I had a proof of concept similar to the ObjC example in my previous post. But, I kept working on it. Routing, templates, plugins, configuration, build systems, all managed to find their way in. Then, the nice things. Session, Authorization, and Form frameworks are a part of it. I've started on a fairly simple ORM, as well, Almanna. The result is, well, this.

This blog is the first production test of the framework. I ported the blog software from Catalyst to Ambition, launched it here on the existing database, and I'm going to see all the places it fails. It will likely do a lot of failing, but it's a decent first effort. After a little stress testing, I'll open this up on GitHub, and see where else it can go.

Welcome Back

2013-08-22T00:00:00Z

After some thought and paging through many years of old, outdated technical advice, I have migrated my blog to a new domain with a bit of a fresh start. Because I never want to let go of what I've said in the past, I kept a few entries around for grins, but will start fresh and new from here on forward.

Welcome to my new blog.

The main reason I'm writing here is to share thoughts and elicit some conversation about modern development on the web and in the cloud, using old and tired technology, as well as new and busted technology. With any luck, none of the entries will end with "get off my lawn".

I'm speaking at Twin Cities Code Camp 15!

2013-10-08T00:00:00Z

I will be presenting the Ambition MVC Framework at TCCC15. Twin Cities Code Camp is a free event that occurs twice a year at the University of Minnesota in Minneapolis, MN, and it caters to novice to advanced developers using multiple languages and devices. TCCC15 will be held on October 19th, 2013, starting at 8:00am, and you can register here.

The synopsis of my talk:

There are tons of great MVC web frameworks out in the wild, for most major compiled and dynamic languages. They're great tools to get projects prototyped and quickly into production. The Ambition MVC framework is a hobby that turned into a reasonable web framework. Written using Vala, the Ambition framework allows a developer or team of developers to create web applications or RESTful services using a static-typed object oriented language without relying on a VM or a garbage collection cycle. Plus, being compiled, it allows cloud deployment to be easy and inexpensive, as memory and CPU requirements can be a fraction of PHP, Ruby, Python, or Perl sites. While it's not "officially" released, it's available on GitHub, and being actively developed. Patches, help, and end users are very welcome, and I'd like to show you more.

GCouchbase - A reasonable Couchbase library for Vala

2014-01-02T00:00:00Z

I'm pleased to announce that there is a reasonable Couchbase library coming along for Vala, and it is semi-functional at this point. Sure, an announcement seems weird at "semi-functional", but considering the absence of a library up to this point, I'm calling it good.

Introducing GCouchbase (github/web).

GCouchbase is a combination of a fully functional vapi wrapper around the C libcouchbase library and a pleasant GObject layer on top of it. The libcouchbase functionality is available to the end user via GCouchbase or on its own, but GCouchbase makes the library work more like how one would expect out of a higher level language. The structure is loosely based off of the .NET library, but does not rely on libmemcached or any other proxy layer.

For those who may not be aware of what Couchbase is, it is (in my humble opinion) NoSQL done right. While similar in functionality to other offerings like MongoDB or CouchDB, Couchbase combines a persistence layer with a memory layer to provide fast, scalable JSON blob storage and retrieval that scales evenly with memory and CPU. In other words, you don't need to have a cache layer, a data layer, and a replication layer, Couchbase handles it for you. The built in view functionality is powerful, but can directly connect to an ElasticSearch instance for advanced queries.

It's very neat, and blends in nicely with the speed of Vala.

Introduction

2014-03-29T00:00:00Z

I keep finding myself in situations where I say, "Yeah, I could totally do that myself." Honestly, I have no freaking idea what I'm doing, but at least I can share the knowledge after I've broken everything.

You may also find instances where my wife and I have both not had any idea what we were doing at At Our Own Risk.

Project Audi TT Audio: Amp Power

2014-03-29T00:00:00Z

I've installed amps in vehicles all of twice, and both of those cars were not German. One was a 1997 Dodge Intrepid, and one was a 2001 Mitsubishi Eclipse Spyder. The Intrepid was fairly easy because it was huge and had a lot of open spaces, so finding a place to drill wasn't terrible. That said, I made someone else do the drilling, as I was 18 and stupid, but not stupid enough to ruin my only car. The Eclipse was easy because the thing was a tin can and you could route wires through any of the wide open, uninsulated spaces in the whole car. I hated that car. Anyway, since the Audi is getting a whole build, I elected to start taking stuff out of the car first, to make the process (theoretically) easier. First, I yanked out the head unit, and then pulled out the seats. Well, first first, I disconnected the battery. Let's not be ridiculous.

Audi recommends the use of an adapter of sorts when removing the seats from the car, to prevent the airbags from going off. Dr. Google seems to have the opinion that this isn't required if you're doing this in a space where static electricity isn't much of an issue. I ran with that, pulled four bolts from the bottom of each seat with an allen wrench, disconnected the three wire harnesses underneath, and put the seats aside. This gave me plenty of room to work in the car. Note that there isn't a lot of room under those seats to remove those clips, and they fasten on the top and bottom. I ended up using a flathead screwdriver to lift one clip while wiggling it out. It helps to unbolt first and then rock the seat back to get more room to work.

After that was complete, I pulled out the lower dash panel under the steering wheel. To do that, remove the cover of the fuse box, which you'll see if you open the driver's side door, and look on the left side of the dashboard. Those are just push clips, so it'll pull off if you slide a flathead under and pull outward gently. There are two hex screws on the lower curve, and then one nearly dead center, that is inset somewhat, as it's bolting in the dash cover and not the outside of the fuse box. Then, underneath the steering wheel, there are two hex screws on the bottom that need to be pulled out. The dash cover can then be pulled straight toward you from the steering wheel, and then downward. You'll want to pull the wiring from the headlight switch and from down below, and then you can pull the whole thing out, if you want.

Once you're done, you're left with this:

I started with the guide on Waks Wide Web, the defacto source of garage how-to for the TT, to run the amp power cable. The guides on that site assume a RHD UK TT, so when he mentions "glove box", it's under the driver's side for the US. I also ignored everything about the remote wire, since this is being controlled by an aftermarket head unit with a dedicated remote lead. I was stumped with what I saw there. First, the box that can "easily be unclipped and moved to the side" is either the thing on the left or on the right. The thing on the left provided no more visibility or ease to me when it was unclipped and moved. The thing on the right wasn't going to budge for anyone or anything. So, I tried from the inside. He talks about the big loom, so I found that above the dead pedal, taped my 4-gauge power cable to a wire hanger, and tried to push it through.

Nope. Not going anywhere.

So, I'm shining a flashlight behind the engine. I pulled out the airbox entirely (which came in handy later), to see if I could see another hole with more room. I'm shining a flashlight all around under the driver's side, and I'm starting to get ready to find a place to drill, or try to remove the white covering that is all along the firewall on the inside of the car, thinking maybe something is covered on my car that isn't covered on others. Then, as usual, it was actually staring at me all along. There's a dime to nickel size rubber grommet almost directly above the gas pedal. I pushed on it, it came out, and I could see the light from the open hood of the car. Success! I took my taped cable and ran it through that hole until it it something.

It comes out somewhere around that box that Waks Wide Web was talking about. Mine poked through the heat shield behind the engine, but I pushed it back and routed it to the right hand side. In a perfect world, this would run along the wire track that you see on the right, but as I mentioned before, I have no idea how to gain access to it. I successfully unclipped it from the bottom, but without getting to it from the top, that's useless.

I kept the cable below the airbox, covered the cable, and put the airbox back into the car. I'm not attaching it to anything yet, but now I know my cable length, and I know where it's going. Insert a new grommet so the metal is not rubbing against the cable, and put some sealant on there so water doesn't get in the cabin.

Project Audi TT Audio

2014-03-29T00:00:00Z

So, last fall, I picked up a 2002 Audi TT 225 Roadster with a little over 160,000 miles. It's super high mileage, but drives super well, and I figure it's a great little car to learn on. Luckily, nothing terrible has happened yet, but I can guarantee you that this car will be featured more than once on this blog in the near future. Once winter came, the convertible was in the garage quite a bit, and I noticed that after a couple of weeks, the car needed a jump start.

Super annoying.

After some considerable trial and error using the fuse box, turns out that it's the Bose amplifier that is causing a pretty big power drain while the car is off. Not a big deal if it's driven every few days, but significant enough that it's dead after about a week and a half. Well, go big or go home, right? Instead of picking up a new amp to provide the same lackluster sound, why not spend a little more and redo all of the audio? I have the Bentley manual, how hard could it be?

I love bad ideas!

So far, on the build list:

Sony DSX-S310BTX for the head unit
Alpine MRP-F300 4-channel amplifier to drive speakers
Alpine MRV-T320 2-channel amplifier to drive subwoofer
Alpine SPR-60C 6.5" Component speakers for the doors
Infinity Reference 4032cf 4" 2-way speakers for the rears
JL-Audio 8W1v2-4 8" Subwoofer for the rear
A boatload of Dynamat, cabling, and fuses

I've already started the project, slowly but surely, as I have an infant and a job, so I'll be updating with some of the ridiculous crap I've dealt with so far, and continuing from there.

Project Audi TT Audio: Head Unit

2014-04-06T00:00:00Z

I always felt that the head unit was the easiest component of most vehicles to replace. Modern vehicles have hugely custom setups, some controlling HVAC and car preferences, which makes it a pain. Luckily, in this case, the only sin is that Audi uses a slightly wider faceplate on their head units. I actually replaced my head unit last fall as the original Concert unit was failing, so there's going to be some stuff from memory here. I grabbed parts as required for the first installation, however, since I'm bypassing the Bose amplifier now, it's possible that we can go for a cheaper wiring harness.

Metra 70-1787 Radio Wiring Harness for VW/Audi - Bose
Metra 40-VW54 Amplified Antenna Adapter

Wiring Harness and Power

I had to modify the wiring harness before as the pinouts didn't match what the TT was bringing out at all. The yellow power lead didn't connect to anything, and it required me to pull pins out and replace them elsewhere. For this install, I yanked everything else out. So, you'll only need the black harness, providing power, as everything else is for either audio output or the amp remote wire, which isn't necessary, as I'm disconnecting the Bose amp. To be clear: You're getting constant 12V power via the yellow line, and ground via the black line. Switched power has to be tapped.

To tap switched power, I went under the driver's side again, and ran a wire from the 30X terminal on the far left side of the power bar directly under the steering wheel. It does what it needs to do -- it's on when the key is on, it's off when the key is off, and it provides 12V. I wouldn't power anything more intense than a head unit off that line, but it works really well for this purpose.

For FM radio to work, the 40-VW54 adapter is just connected to the separate antenna connector in the TT, and the blue line is connected to either the amp remote or antenna remote of your head unit. The Sony head unit I purchased had two separate leads, so I could connect the amp remote to one, and the antenna remote to my adapter. If the head unit doesn't have separate leads, connect both the amp remote and the 40-VW54 to the amp remote lead of the head unit. If one were using the original Audi head unit, you could wire it into the amp remote line on the red wiring harness in the above Metra kit.

Audio Line Out

Log4Vala - A logging framework for Vala inspired by Log4J

2014-06-19T00:00:00Z

It's getting pretty easy to see that I should start finishing some entries for this blog if it's going to be at all relevant or useful, but I'll take a moment to introduce another "thing".

This past weekend, while working on a web project in Ambition, I started wishing I could control logging in a better way than what was already provided. Specifically, I wanted to be able to amp up logging in one controller while keeping another one quiet. In a horrific turn of events, I found myself longing for something like log4j/log4perl/log4net so I could use a configuration file to handle that.

A few days go by, and here we are.

Introducing Log4Vala, available on GitHub. Available as a shared library to integrate into your Vala application or library, Log4Vala provides most of the core concepts available in the other logging frameworks, without a lot of overhead. Yes, there are still a few method calls for each logging pass, but it's quiet a bit tighter than a VM environment. I'm pretty happy with the result.

Patches/documentation/heckling welcome.

Shopping for Cars

2016-03-31T00:00:00Z

My current car, a 2013 Chrysler 200 Limited, is under a lease that will be up in June. I loved this car far more than I expected to, given the reviews on it, but I can provide more color to that later. The end story is that the residual value of my car (the amount I'd have to pay to purchase it) is going to be about $5,000 more than what it blue books for, so it makes precisely zero sense to purchase it. I have to find a new car.

I thought it'd be interesting, maybe only for my own historical purposes, to talk about the vehicles as I drive them and come to a conclusion. I managed to hit the local auto show a few weekends ago to pull my list under ten cars, but I'm still all over the place in terms of size, power, and price. Currently, in the running, I have:

2016 Chrysler 200C - I liked mine so much, and the new one apparently looks/feels/performs so much better.
2017 Chevrolet Volt Premier - The concept of mostly electric driving sounds great, with a little bit of fuel to back it up. The second generation actually looks like a car.
2016 Fiat 500x Lounge - Not much for SUVs, but this looks classy while still being small enough to whip around.
2016 Buick Regal Premium II or GS - Buick wasn't on my list until the auto show, these looked nicer than I ever expected.
2016 Volkswagen GTI SE 4-Door - I love the idea of a small car with a nice turbo.
2016 Nissan Maxima SL or Platinum - I can't stop staring at these -- the design is funky but approachable, the interior looks amazing, and it has the big Nissan V6.
2016 Kia Optima SX or SXL - Kia wasn't originally on my list, but a good friend of mine has one and likes it a lot.
2016 Audi A4 - With the introduction of the 2017s, these actually become reasonable. I had a 2008 that I really liked, except for what the previous owner did to it.

What do I want? I want something that is comfortable to commute in, with a great stereo system with navigation and/or Android Auto, comfortable seats with heat, and enough performance to let me smile once in a while. I already have a project car, so it doesn't have to be insane, but I don't want a dog. Naturally, I err on the side of more interesting gadgets, so I'd love to have things like adaptive cruise control and lane departure warnings. I'd also love to have ventilated seats. Bonus points if I can get a brown leather interior.

The 200 I have now has an incredible sound system, by Boston Acoustics, of all people, navigation, heated leather seats, a sunroof, and the Pentastar V6, a 283hp beast that was ill-suited for this car's platform, but puts a big grin on my face regardless. It seems you can get it to 60 in 6 seconds, but that implies you have traction.

On with it!

New intake

2016-05-13T00:00:00Z

A little over a year ago, I decided it'd be neat to replace the intake on the TT, and while research brought me to the Modshack VTDA, they didn't sell it anymore. I did find a K&N unit for a price I could afford, and made the switch. It completely replaced the stock airbox with a cone filter, a mini breather filter, and a big holder for the whole unit. It looked great, and sounded pretty awesome (extra woosh is better woosh), but there were two problems. First, it exacerbated a random CEL I was experiencing, and on longer trips, the wooshing got annoying, as I'm old.

Fast forward to today, and someone was selling a used VTDA on quattroworld.com. I jumped on it, and he shipped it super quickly. In a box, I got the VTDA... cylinder with a K&N filter inside, a mini breather filter, and some packing material. Browsed Google a bit until I found someone else who had installed it, and did the installation. Since the airbox already came out in the K&N install, the installation took me about 15 minutes, including a quick clean of the MAF sensor and devane of the MAF.

I'm super happy with how it looks, though the whole engine bay could use a cleaning, along with the VTDA. The best part, though, was the drive. It gave me the same level of breathing as the K&N did, but the sensor clean seems to have resolved my CEL and my hesitation, and the sound is still gently enhanced, but muffled a bit more so it's not in my face when the top is down.

Highly recommended easy modification.

In the meantime, I never really finished project Audi Audio on the above, though I did take pictures. I may create a summary post, may not. Nevertheless, when I did the installation originally, I installed two amps to drive the speakers and the 8" subwoofer. The sub was driven by an Alpine MRV-T320, and the speakers were driven by an Alpine MRP-F300. They both provided ample power for the installation, but I was always bothered by having two amps throwing off heat in the cramped shelf of a trunk of a roadster. I replaced those two with a Precision Power P900.5 five channel amplifier this weekend, and what a great replacement. The sound quality is great, the unit is super compact but still throws out the power I need, and it doesn't give off more heat than one single of those Alpine amps.

I've also been working on cutting and moving things to make the TT head unit a double DIN unit. I started with a Nexus 7 install, but got frustrated with how finicky it was in terms of powering on and resetting, so I grabbed one of those inexpensive Chinese Android-based head units, since I have to custom cut anyway. I've completed the wiring, and cut the radio frame appropriately so that it's mounted, stays there, and works well. I'm in the process now of altering the bezel to make it look like it belongs, and I'll post progress there later.

Adventures in "Going Elsewhere"

2016-05-19T00:00:00Z

Just had to share.

I purchased the TT nearly three years ago, shortly after my son was born. Since then, it has gone to an actual shop once, and that was to do an oil change as we were mid move, and I didn't have any of my stuff. When I bought it, the A/C blew cold air on a very hot day, which I was surprised and impressed with for a 165+k mile car. Unfortunately, by the next summer, it was gone.

I've tried a recharge kit, but the gas blew right out, leading me to believe there's a leak somewhere. I bought a kit with dye, but the nozzle was too shallow for the low pressure port, so I got dye all around the port. Fine. I lack the tools or knowledge to do much of anything useful with air conditioning, so I brought it to a local shop to see if they could track down the issue.

They charge me $50 for the inspection, which I pay whether it gets repaired or not. I did not. Here's what they found.

a) There's a "big leak", and they don't know yet what's doing it. My guess is that it's the dye from my kit that they're looking at, because if you listen to the noise of the gas leaving, it's from the back of the engine, not the front. But, no dye at the back.

b) Even though they don't know what's leaking, they're very sure I need a "freon temp sensor", which will cost $108.57 for the part, and $96.60 in labor. Two issues. One, there's no such thing as a refrigerant temperature sensor in the TT, only an ambient temperature sensor. There's a coolant temperature sensor, but that has nothing to do with the HVAC. Chances are, they're talking about the high pressure sensor which is in a static open state, which could be due to the leak *or* because the system is empty. Second issue, and this is minor, but stop calling it freon, as no car since about 1994 uses freon.

c) After they replace that, then they can evaculate and recharge the system for $172.62, and recheck to see where the leak is from.

In the end, they wanted $475.44 to diagnose, repair, and recharge, but no guarantees it'd work after.

I'll just keep the top down, and worry about the switch later.

New V6 rear valance!

2016-06-27T00:00:00Z

In non-mechanical repairs, finally had a chance to replace two issues on my vehicle, and one looks pretty awesome. First one was replacing the passenger side lower grille, where most cars would have a fog light. It was missing, and there was just one big stupid looking hole in the front. Second, I replaced the rear valance (lower bumper, surrounding exhaust pipes) with the one that came with the upmarket V6 model. It wasn't just for the look -- at some point, someone rear ended this car, likely before I owned it, and it was cracked and snapped from the retaining bolts. I'm just happy I didn't need a whole bumper.

It looks great. Ignore the fact that I'm in the reflection.

Timing Belt Service

2016-10-13T00:00:00Z

After 3 years of ownership, finally had to do some real work on the TT, and when it rains, it pours -- but more on that later. This Audi TT has one of the VW/Audi 1.8T variants, which means it uses a timing belt, and the replacement interval on these has dropped due to premature failure of the timing belt over the years. If the belt goes, so goes your engine -- with bent valves at the very minimum. The manual states that it should be replaced every 105,000 miles, whereas the common knowledge now is 60-70k. I have no idea when it was done last, but if I'm going to do anything fun in the car, should probably take care of this.

The nice thing about owning a 15 year old car is that everything's been done already by someone else, so I followed the excellent Timing Belt replacement guide by BlueTTop on the AudiWorld forum. I used the ECS Timing Belt kit with the Gates belt, and picked up a new Coolant Expansion Tank as mine was yellowed, and one 4-pin connector to replace a cracked housing on my 1st cylinder coil pack. Total replaced on the car included the aforementioned connector and coolant expansion tank, as well as the timing belt, accessory belt, tensioning pulley, tensioning dampener, water pump, and thermostat. For good measure, I also did an oil change.

I won't go through every step of what I did, as the guide above did it far better than I, but just to highlight a few things...


Everything was dirty. This is almost-before, with the charge pipe removed, but most everything else still in place. Notice the very yellowed coolant expansion tank in the upper left.


Purchased an engine support bar from Harbor Freight for the occasion, as I'd have to either do that or get another jack, and felt this was safer if I had to buy something. Oddly, this was the most nerve wracking part for me, as I was so afraid of what would happen if something broke and the engine came loose. Note the trusty Bentley manual and what I've dubbed as "the tool tray" on the front of the car.

Purchased an engine support bar from Harbor Freight for the occasion, as I'd have to either do that or get another jack, and felt this was safer if I had to buy something. Oddly, this was the most nerve wracking part for me, as I was so afraid of what would happen if something broke and the engine came loose. Note the trusty Bentley manual and what I've dubbed as "the tool tray" on the front of the car.


When draining your coolant, make sure the hose is on all the way, or you get a garage floor full of coolant. Doh.


The existing timing belt looks dry and old, but maybe the new one does already.


There is not a lot of room to work with these connectors, and I have a feeling this is already an aftermarket harness. The Lisle 57750 wire terminal tool kit from Amazon did a great job here, and way cheaper than the VW/Audi tool.


After everything was said and done, it sure looks a lot cleaner. I used Simply Green as I went to clean off parts as I disassembled and reassembled. I didn't clean everything under the hood, as you can see by the battery tray, plastic surround, and some of the hoses.

Honestly, this was a lot of fun. It's a 1-2 day job that took me about a month in between job and kids and time with family, but it was nice to just work on one piece at a time, especially when I needed something calming. There were frustrating parts -- bolts that were nearly impossible to get to (hello, bottom thermostat housing bolt), missing tools (bought a torque wrench that only went up to 30 lb ft, while the engine needs 33 and 40, and the wheels need 89), things that didn't make sense (is that supposed to spin or no?). There were also fantastic parts, like when the timing belt finally went on, every TDC mark lined up, and after a few spins, still lined up.

The test drive after went well, except for not putting quite enough coolant in. A new problem cropped up, though. On one of my drives, all of this lit up:

ABS, Brake, ESP, and Alternator. Not a good sign. VAG-COM doesn't help me, as I have another persistent K1 Short to Ground issue that pulling fuses is not helping me track down. Battery is putting out 12.5, but testing the alternator gave me over 16V. I guess there's the problem. Either it's the voltage regulator on the alternator, or something else in the alternator, or both... Next up, replace the alternator!

New Alternator

2016-10-21T00:00:00Z

I had no idea alternators were so heavy. Dense little bastards, aren't they?

Alternator change was mostly uneventful, except inconveniently placed -- like everything else in this car. I followed this guide to get down in there. It was mostly uncovered during the timing belt work, but I really didn't want to do the full disassembly, so the guide helped. While removing the vacuum reservoir tank (what the guide calls 'the black canister'), I snapped a connector off the tank, which means that I had to replace the tank (8n0 131 541). Hooray plastic molding, and hooray Wolf Auto Parts.

Picked up a remanufactured alternator from Advance Auto Parts. Looks to be a rebuild in a Bosch housing. Everything lines up well and looks good, so we'll see how long it lasts. I have the receipt if not. Bosch offers their own remanufactured units, but they don't have any dealers in Minnesota, and don't seem to sell online. Oh well. Out the door for under $130 for a nice looking, easily installed unit.


New on the left, old on the right. Have a weird feeling that the old one was original.

So, of course, this nice, new looking unit stands out a bit.


Shiny!

The big issue was that it would have been far easier to do while I was doing everything else, but I'm glad I did the timing belt beforehand. Reattaching the accessory belt blind, without removing the sound dampener or putting the car on jack stands was doable, but far easier when I remembered where everything was. The other issue was getting enough clearance without taking everything out that I had already taken out before. Most people seem to take out a vacuum reservoir tank that sits next to the passenger side headlight. Easy enough to remove -- disconnect the hose tangle on top, remove one 13mm bolt, remove a vacuum line, remove. Except while trying to remove the self-clamping vacuum line, I broke the plastic piece it attaches to clear off the tank.


Dammit.

So, thanks Wolf Auto Parts for the quick delivery of a replacement tank. Pro tip - to remove this line, you can see the outline of a little button on the lip of this thing, about 1cm long, running along the lip. That has to be pushed in, and then the line can be removed safely and successfully. Save yourself the $35-$40 to replace the tank.

Needless to say, everything is a success. All my lights disappeared, and running voltage is perfect.

Random thoughts

2016-12-08T00:00:00Z

Every day that I take off the engine cover and oil hasn't exploded everywhere is a good day.

Bigger than double DIN

2016-12-10T00:00:00Z

A bigger write up later, but I had to share. This is a "double DIN" bezel/console -- actually, VW Golf sized -- from tt8n.de installed in a 2002 Audi TT, with a Joying JY-VL130 VW-focused Android-based head unit.

Migration and Merging

2019-01-23T00:00:00Z

Hey, welcome to the new nicholasmelnick.com, largely the same as the old nicholasmelnick.com.

Given that the Ambition Framework has gone to sleep, and I've largely stopped hobby development on Vala, it was about time that I both migrate my blog away from Parchment, and also merge together some of the other blogs I've maintained over the past few years.

While I'm not the biggest fan of WordPress, it provided two things that I really wanted out of a writing platform -- a solid history of maintenance and security updates, and the ability to host comments without too much pain. Here we are.

Installing ChromeOS on Surface Go

2019-02-17T00:00:00Z

Note: Hi from the past, everyone! This post is likely very out of date. There are new tools to replace Project Croissant, and new driver packs available for Surface products including the Go. This hasn't been updated since February of 2019.

I'm a tablet hopper. I love the idea of a tablet, but they always seem to fall short in one way or another. I've had a ton of Surface devices, iPads, and even a few Galaxy Tabs. My favorite device of all time is probably the first generation ThinkPad 10, but it's just slow enough at this point that it's not as fun as it once was. My current primary is a 10.5" iPad Pro.

I do love the Surface lineup, but Windows 10 is a surprising shortcoming. Don't get me wrong, I really like Windows 10, but from a tablet perspective, it's a huge step back from Windows 8. Do note, however, that's the only nice thing I'll say about Windows 8.

What I've really been waiting for is a really good 10-11" ChromeOS tablet. ChromeOS has a great core, Android support, Linux support for the apps you need, all wrapped up in easy updates and elegant consistency. Usually. The only devices in this form factor are the Acer Chromebook Tab 10, and the clone tablets that are based on that form factor. The ARM chip is somewhat anemic, but I'm mostly okay with that. My concern is the lack of supporting hardware -- namely, decent cases, and nicely integrated keyboard designs. Once something comes out that fits that niche, I'm first in line.

Until then? Haxxxxx.

Enter Project Croissant. Croissant, formerly Chromefy, is a tool to convert a ChromiumOS image to a full ChromeOS image. ChromiumOS is the open source version of ChromeOS, consisting of most of what makes ChromeOS good, but missing closed source bits, including Android support. By utilizing a ChromeOS recovery image, Croissant can generate a ChromeOS image that can be installed on most anything with some reasonable driver support. Armed with this, I'm hoping to make a Surface Go, arguably one of the best form factors out there right now, a much more useful tablet for me.

ymmv.

What definitely doesn't work:

Front and Rear Cameras
Power button to wake, but other touch events or keys seem fine

What's fiddly:

Touch response is odd, a press event occurs even on light touches or drags
The type cover function key icons do not correspond to their ChromeOS functionality
Sleep still burns some battery

What really works:

Wi-fi and bluetooth seem to work splendidly
The stylus responds well, and the pen icon appears
The type cover attaches and disconnects as one expects, backlight works, everything is fine
The SD card mounts just fine
USB-C devices work exactly as they should
Audio output
Lid sensor with Type Cover

To create this image, I used another machine running Linux. This can be done in a virtual machine, or using a Linux live image.

To begin, we need to gather dependencies
1. Obtain chromefy.sh from GitHub
2. Obtain the nocturne 71 recovery image
3. Obtain the caroline 71 recovery image
4. Obtain the ArnoldTheBat R72 Special image
We'll also need to grab updated firmware for wi-fi and bluetooth support within Chromium/Chrome
1. Retrieve an up to date firmware-6.bin from ath10k firmware
2. Retrieve updated board.bin from Killer Networking wireless firmware
With all of our dependencies gathered, we can actually create our installation image
1. Uncompress each image into a directory
2. Copy chromefy.sh into the same directory
3. Execute chromefy to create the image, using something similar to sudo bash chromefy.sh chromiumos_image.img chromeos_11151.113.0_nocturne_recovery_stable-channel_mp.bin chromeos_11151.113.0_caroline_recovery_stable-channel_mp.bin
Write the updated chromiumos_image.bin to a USB stick using Etcher or similar
Upon completion, remove and reinsert the USB stick
Insert updated firmware and configuration to our ChromeOS image
1. Find the partition containing the rootfs, which may have automounted under /media/your-username/, and contains directories like 'bin', and 'lib'
2. Remove [path-to-rootfs]/lib/firmware/ath10k/QCA6174/hw3.0/board-2.bin
3. Replace [path-to-rootfs]/lib/firmware/ath10k/QCA6174/hw3.0/board.bin with the previously downloaded file
4. Replace [path-to-rootfs]/lib/firmware/ath10k/QCA6174/hw3.0/firmware-6.bin with the previously downloaded file
5. Create [path-to-rootfs]/etc/modprobe.d/ath10k.conf and add options ath10k_core skip_otp=yto the file
Unmount the mounted USB filesystems
Get your Surface Go and running
1. Within Windows, go to Settings > Update and Recovery > Recovery
2. Under Advanced Startup, select Restart Now
3. Navigate to Troubleshoot > Advanced, and select UEFI Firmware Settings
4. Under Boot Configuration, disable Secure Boot and set USB Storage to the top of the boot order
5. Select Reboot to boot from USB stick

This is a bit of the test front for the image. One is able to log in and poke around a bit within the USB live image. The installation process got a little hairy, though, at least for ArnoldTheBat 72 + Eve 71. Note that the first command run will blow away the copy of Windows installed on the Surface Go. There are instructions available on the Project Croissant GitHub README for doing multiboot. As I have the 64gb Go, multiboot makes no sense for me. Also note that the 128gb Go uses SSD instead of eMMC, so the device name is going to change, likely to some derivative of /dev/nvme0n1.

Execute /usr/sbin/chromeos-install --dst /dev/mmcblk0 --skip_postinstall
Reboot into a live image of Linux
Using Gparted, or similar, resize /dev/mmcblk0p3 (H-STATE) down one gigabyte
Remove /dev/mmcblk0p12, the EFI_SYSTEM partition
Create a new partition, 1gb, fat32, with a partition name of EFI_SYSTEM
Apply
Right click the EFI_SYSTEM partition and then "Manage Flags"
Select legacy_boot, boot, esp
Open a terminal
sudo mkdir /mnt/cros /mnt/efi
Insert the USB stick containing your ChromeOS image
Find the device of the USB stick, likely /dev/sdb, and replace sdx with the device found, and execute mount /dev/sdb12 /mnt/cros to mount the Chrome image's EFI partition
Execute mount /dev/mmcblk0p12 /mnt/efi to mount the installed EFI partition
Execute cp -Rp /mnt/cros/* /mnt/efi/ to copy the EFI partition over
Reboot and remove the USB stick

Welcome to your new ChromeOS installation!

MMI 3G+ Upgrade on a 2010 Audi A5 Cabriolet

2019-09-25T00:00:00Z

Completed Facelift MMI 3G+ Installation

I recently completed an infotainment upgrade on my B8 Audi A5 Cabriolet 2.0T Prestige, bringing it from the stock MMI 3G system to MMI 3G Plus. The updated MMI unit brings an updated interface, speed increase, Audi Connect, online map destinations, Google Earth overlays, bluetooth audio over A2DP, and without any data to back it up, better audio quality.

I did all of this with used parts, which meant a trip to an Audi service center to remove component protection. This amounted to an hour of labor charged, which is still far cheaper than buying any of these parts new. This was done in the US, on a left hand drive model, so other countries may have different part numbers, or may require a reflash -- particularly the 5F or 56 modules.

There are a ton of HOWTO guides on the forums, all with slightly different information. I'm adding to the chorus with things I ran into while installing this in an A5 cabriolet, which can be different than those installing in an A4 sedan or Q5 crossover.

Tools Required

Audi Radio Keys: The radio keys are required for removing the original stock MMI unit. They slide into slots on either side and allow the unit to slide out.
Plastic Trim Removal Tools: I used the trim tools for removing the shift boot while removing the MMI control panel, for easing out the temperature control unit, for jimmying apart the plastic pieces behind the screen for snaking through the antenna connector from the top vent down to the 5F unit, and for removing trim pieces during trunk disassembly to install the radio
Flathead screwdriver
Torx screwdriver - T25 (radio) and T20 (antenna)
10mm and 13mm sockets and wrench (Radio only)

Parts Used

8R1 035 746 B - MMI Control Unit (5F): This is the brains of the upgrade, powering the user interface, housing the hard disk, DVD drive, and cellular module, and interfacing with CAN and MOST buses. They have revisions all the way up to G, and it looks like F and G have an updated cellular module with UMTS support. These can be sourced from any B8.5 model -- A4, S4, RS4, A5, S5, Q5, SQ5.
8T0 919 611 L WFX - MMI Control Panel: This is the tactile interface to MMI in your center console, providing the control knob, and function buttons. This model has the start/stop button, as mine was originally equipped with it, the model without is 8T0 919 611 K WFX. This has to be changed due to the communication speed change between the two models. Though you can use an older control panel with VCDS changes, the updated layout is really nice. These can be sourced from any B8.5 model -- A4, S4, RS4, A5, S5, Q5, SQ5.
4G0 035 082 G - Radio (56): This can be optional. Some radio units have difficulties communicating with the updated control unit, and will throw errors or reset itself while operating. Mine was one of them, but it wasn't a huge deal, but I also wanted HD Radio, so did the upgrade. These can be sourced from a /ton/ of Audi and VAG models.
8K1 820 043 AR - Temperature Control Unit (08): This is absolutely optional, skipping this will still result in a fully functional upgrade. I wanted this for aesthetic reasons -- it matches with the new 5F well, and I like the white text and simple ventilation buttons. The model number shown here provides dual zone and heated and vented seat controls. These can be sourced from any B8.5 model -- A4, S4, RS4, A5, S5, Q5, SQ5. The Q5/SQ5 models will have an additional plastic strip on the bottom with a foam tape backing. This can be pulled off to fit in the car models.
An external GSM antenna: It appears, according to other guides, that many A4 and A5 models have a built in cellular antenna to connect the new MMI unit to, my cabriolet either didn't have it, or just wasn't accessible enough for me to find. I ended up buying an external antenna on eBay with a FAKRA connector to wire into the unit
Ross-Tech HEX-V2 cable and VCDS: VCDS is required for enabling diagnostic mode and coding your new devices. There are other tools that may allow this functionality, and some less than above board options, but these are the tools I used.

Preparation

Make an appointment at your Audi dealership, or Audi-enabled service center with access to Audi's service network. The MMI Control Unit, Radio, and Temperature Control Unit will all need to have component protection removed to operate. That means the drive will be without music and without heating or air conditioning, so plan accordingly.

Before getting started, retrieve the current coding and configuration of the installed modules using a combination of VCDS and the "green menu" diagnostic screens of the existing unit.

To enable the "green menu" in VCDS

Open module 5F - Control Head
Select the 10 - Adaptation button
Select Channel 06 and press the Read button
If the value is 0, change to 1 and press the Save button
Exit the module
Reboot the MMI by pressing SETUP + Control Knob + Upper Right button
Once rebooted, go to RADIO, and then hold down SETUP and CAR at the same time to enter the green menu

"Green Menu" Main Screen

Grab your phone or digital camera, and start taking shots of some screens in here, as they will need to be duplicated once the new unit is installed. Each of the headings above have subheadings, and then potentially multiple pages of options to scroll through. You will want to capture:

car > carcodingvehicle (1 page)
car > cardevicelist (3 pages)
car > carextdevicelist (1 page)
car > carfunctionlist (1 page)
car > carmenuoperation (3 pages)

Now we want to capture coding in VCDS, but only if replacing the radio or temperature control unit. If not, skip ahead.

Radio:

Open module 56 - Radio
Select the 07 - Coding option
Take a screenshot or copy the code directly to another file or note taking application

HVAC:

Open module 08 - Auto HVAC
Select the 07 - Coding option
Take a screenshot or copy the code directly to another file or note taking application

MMI GSM Upgrade

I created a bit of a monster for mine. My first MMI Control Unit was a F-model, but a dud. It was sold as a non-working model, and I was hoping it was just a bricked logic board, and I could recover it with a serial cable and a laptop, but it was truly and completely dead. It was in fantastic condition, though, so I kept it around.

My next model was a B model with a carved up fascia. I transplanted the nice fascia from the F-model to make it look great, and then I took the GSM module out of the F-model and placed it in the B-model so I could access UMTS towers. That module just requires the top cover to be unscrewed, and then one screw from the back of the module with the purple connector on the back.

The one hiccup in place is that the upgraded GSM module requires drivers for the control unit. This can be accessed at the Audi dealership under ServiceNet >> AUDI >> Technician References >> Audi MMI Scripts : MMI3GP_UMTS_Driver_Script.zip. I am still working on acquiring this, but everything connects okay at 2G speeds with the old module.

Fitting the MMI Control Unit (5F)

This is actually incredibly easy, but if installing the optional components, I'd almost install it last, as it's easier to take care of some of the other components while this unit is taken out.

Make sure the vehicle is off, and the parking brake is on
Shift the vehicle into neutral. This gives you more room to slide out the MMI without a fight
Place the two Audi radio removal keys into the two corresponding slots on the unit until they lock into place
Using the keys, slide the unit out from the dashboard
Remove the connectors from the rear of the unit, and the button modules on the front of the unit
Remove the button modules from the control unit. There are four tabs -- two visible, two on the top of the module, you can slide a wedge in to release them, and work them out.
Place the button modules in the new unit
Now is a good time to pause until you're done with everything else.
I'll wait.
Reconnect each of the connectors, matching color to color. All of the connectors are the same, but the purple connector will be used by the optional GSM antenna
Slide the unit back into the dashboard
Shift back into Park

Fitting the MMI Control Panel

This one is futzy, but not awful. It's highly recommended that the HVAC control panel is removed to be able to get this out.

Make sure the vehicle is off, the parking brake is engaged, and the vehicle is in neutral

Grab a plastic wedge tool and insert it to the right of the shift boot, near the bottom, and gently pry it up. The bottom of the boot should pop up slightly, and you can work out the rest of it
Lift the boot up and over the knob to give yourself some room. Don't try to remove the boot, we're just creating a little cone.
Pry up the shift indicator (PRNDS) vertically with your hand, and disconnect the cable
Pry up the remainder of the unit from the bottom of the new hole you've created, and it'll pop out of the clips holding it into the center console. Be gentle, there are connectors.
Remove connectors from the bottom center, upper left under the parking brake switch, and under the start/stop button if equipped
Install the new unit in reverse order. There are no new connectors or surprises, but the new unit will have a difference shift indicator that doesn't match how the B8 is set up, which is why we removed the old one.

Optional: Installing the External GSM Antenna

As I mentioned at the start of this entry, I was unable to find a GSM antenna on my cabriolet. The A4 and Q5, and presumably the A5 coupe have a sharkfin antenna that leads to a breakout box with a FAKRA connector that transmits GSM signals. My service manual states that I may have one, but I did not find the module on mine, nor was I particularly looking forward to running 500cm of cable from the rear of my car to the front, so I took the "easy" way. If anyone would like that 500cm of cable, let me know, and I'll ship it to you for the cost of shipping.

The unit I purchased provides 3 meters of cable connecting to a small antenna. This is far more cable than I needed, but it was readily available to ship without doing anything custom. I chose to fit it underneath the top vent/speaker cover and route the cable down to the MMI unit. To do this, one has to remove that vent cover, and then get behind the MMI display for access to that area.

Remove the 5F MMI control unit if it is not yet removed. You will be threading a cable into that area, and connecting the cable to the rear of the MMI unit.
Remove the top vent using the plastic trim tools. The vent is secured by 10 plastic clips. By inserting a thin wedge and gently tilting it to pry them out, I was able to remove the piece without breaking clips. Make sure each clip is released before trying to pull, as the cover is incredibly flimsy, and then you'll be heading over to wolfautoparts.com for part 8T1 819 636 (in black).
Remove the silver trim surrounding the MMI display. This is also secured by clips, but it's far less flimsy. Note that the silver portion is a cover over the frame assembly, so make sure you're pulling from under the frame (slide in from the top of the vents), and not the flimsy cover, or they will separate. A cable is connected to the warning flasher button -- pressing down on the tab facing away from the edge, and gently pulling the connector out in the same direction will disconnect it.
To remove the MMI display, there are four T20 torx screws. Please, for the love of everything holy, use a screwdriver or bit that is magnetized. The area underneath the display has two cavities on either side that love swallowing bolts, and I have literally no idea where they go. I have lost two bolts and a microSD card. Don't ask. The display simply pulls away, and there are a few cables connected. You could lay a cloth down and let it dangle, there should be some wiggle room.
It will be hard to see, but looking straight back into that newly found cavity, there's a seam in the plastic that can be revealed using a small wedge trim tool. Pushing that open will show light on the other side. Using that sliver, push the antenna itself through the left hand side of that slot will get that antenna into the left chamber of that top vent. Pull it through, and adhere the antenna to either the front or rear side.
Toward the right of that cavity, push the connector side of that cable into the void, and continue to thread it until you can't anymore. More often than not, this will send it down the right hand side of the stack. Reach into the cavity where the MMI control unit once was, up the right hand side, and attempt to fish the FAKRA connector down into that cavity, and pull the rest of the cable through.
Wrap the remaining cable into a bundle, leaving enough to stretch to the control unit, and zip tie the bundle.
Connect the FAKRA end to the upper purple connector at the rear of the unit, connect any other missing cables, and reinstall the control unit.
Reinstall the MMI screen. This is done in reverse of the above with no real gotchas. Place screen back in front of the cavity. The bottom two mounting holes also have bumps above them that fit into small holes on the screen, allowing one to align the screen properly. Screw bolts into place.
Reinstall the trim piece. Reconnect the emergency flasher button to avoid a fault code by inserting the cable back in the module. No force should be required. The trim piece snaps into place, paying careful attention to the top of the trim, as it requires some finesse to slide into place.
Reinstall the top vent. Align each clip carefully and gently push into place. Remember how flimsy it is.

Optional: Installing the Radio (56)

Audi makes the infotainment rack really easy to find and test against, it's in the trunk behind an easy-to-open panel. Unfortunately, the convertible makes the process of replacing the radio far more difficult than the HOWTOs elsewhere describe. Apparently, on other models, that easy-to-open panel is all that's required to unbolt the assembly, get the radio out, and replace it. On the Cabriolet, we have to worry about a hydraulic pump, and the whole side trim piece had to come out as it didn't provide enough room for the rack to come out.

Remove trunk floor covering
- Lift the floor release, as if getting to the spare tire
- Using a forked plastic trim tool, release the three expanding clips at the hinge of the floor covering, save them
- Pull out the floor covering
Remove front floor covering
- Fold down the rear seats using the release levers
- Inside the passenger compartment, release the four expanding clips between the seats and the floor covering
- Remove the floor covering in the direction of the trunk
Remove rear cross panel trim (plastic piece surrounding the lip and pin where the trunk closes)
- Pull back the rubber seal and use a wide trim tool to pull the plastic piece up and over the seal
- Using the wide tool, start pulling the whole plastic piece up vertically to release the clips holding it in
- You'll note at the bottom of the inside portion of the plastic piece that two arms come down and align with metal pins that come out, which won't be affected if one is pulling vertically, but you'll need those to align to when reinstalling
Remove left tie-downs
- Fold up the tie down hooks, revealing 2 phillips-head screws
- Unscrew those screws
- Pull out the tie downs
Remove release lever
- Pull the lever, revealing a circular expanding rivet
- Remove the rivet using a small pry tool or flathead screwdriver. It is stubborn, just keep prying at the edges, following the circle until it heads out.
- Pull out the remaining rivet, save
- Use the trim tool to gently pull the assembly away from the carpet. There is something of a retaining hinge on the left side, so pull from the top and right to get it to come out
- Leave it dangling, do not remove the cable

Location of the metal bar that needs to swivel upward

Prepare top of panel
- Close the trunk
- Open the roof enough that the back glass portion convertible top is fully up, and the compartment cover is fully up
- Support the back of the convertible top with a wood stick or something else supportive
- Reach under the enclosure trim where the top would lay, and push it up as if putting a large object in the trunk
- Unclip the left hand side of that enclosure. There's a vague L shape from the metal piece that you pushed up, down a couple of inches, and then toward the seat back. That portion is a plastic frame pushed with 4 clips toward where you are standing. Gently push them out so that the piece dangles.
- Those were attached to a carpet piece that continues to taper forward toward the seat backs. At the end of that taper is another expanding clip that can be removed with the forked trim tool.
- Remove wood support
- Close roof
- Open trunk
Remove panel
- To remove the side trim, use the plastic trim tool to cleanly separate it from the rubber trim, and then pull the clips away from the body. There are three clips to separate, and they aren't adhered strongly, so make sure the trim is getting under the clips, and not just pushing at the side carpet. One clip is left and slightly down from the left of the release lever. One is to the right and down slightly further of the release lever. One is down further from that left hand clip, closer to the opening of the trunk. Once pulled open, be mindful of the cable connecting to the trunk light.

Inside of the side panel on an A5 Cabriolet

Move hydraulic pump
- Remove the two bolts securing the retaining bracket over the green foam pump cover
- Remove two connectors from the top of the retaining bracket, but no need to disconnect
- Remove two connectors from the side of the bracket, and it's far easier to disconnect them by pinching the side buttons and gently pulling apart
- Remove the bracket
- Swivel the hydraulic pump out. The lines on the right side of the pump should not be removed, the pump can just swivel out that direction.
Remove radio
- There's a rack and possibly an amplifier now in view. There are 4 nuts securing the rack in place -- left of amplifier, bracket right lower amplifier, right lower rack, bottom center rack, remove them
- Disconnect cables from the rear of the radio
- Swivel the rack out so that the radio can slide out toward the front of the car. This will require some screwing around, I ended up pulling it toward me, and leaning the top toward me so the radio could slide out nearly horizontally
- There are two "buttons" of sorts on the sides of the radio, but as the radio is positioned in the car, it'll be on the top and bottom of the unit, on the edge closest to you. Those have to be pushed in, and then the radio will slide toward the front of the car.
Install radio
- Slide the new radio in just like the old one came out, connectors facing the rear of the car, buttons on the edge closest to you
- Push the rack into place. Note the bottom center stud almost requires a slight lift of the rack to set into place. Once that's in place, it's much easier to guide back into place
- Connect cables to the rear of the radio
- Replace 4 nuts
Reassemble
- Do it all in reverse order. Some hints and tricks:
  - If the clip came off the back of the carpet, use a torch to melt the plastic into the carpet fibers. A quick hit with a butane torch does wonders. Don't melt it or start a fire, just re-engage what's already there
  - Don't forget to align the arms of the cross panel trim with the pins, or things will break
VCDS fun
- Open module 56 - Radio
- Select the 07 - Coding option
- Select Long Coding
- Coding is as follows
  - 0: 02 (USA)
  - 1: 00 (Sirius, US)
  - 2: as is
  - 3: 01 if standard amp, 02 if B&O
  - 4: 00
  - 5: 00
  - 6: 00
  - 7: 00
  - 8: 01

Optional: Installing the Temperature Control Unit (08)

This is the easiest thing to install, with the most annoying software.

Remove the old unit
- With the 5F out, pull back on the temperature control unit with two hands, applying equal pressure. The unit is held in place by 4 clips.
- Disconnect the two cables at the back. There's a plastic pin at the top center of each that slides easily away from the unit, and then a tab that is pushed down while the cable is slid out.
Install the new unit, same layout, same cables
VCDS fun
- Open module 08 - Auto HVAC
- Select the 07 - Coding option
- Enter in the old coding value from your previous HVAC unit, but append an additional '00', as there's an additional byte on these new units
- Go back
- Select the 10 - Adaptation button
- In channel 79, change from 1 to 0. This changes the blower unit to this generation to allow fan control speed to work.
- In channel 35, use '0' if you have a humidity sensor, '1' if you do not. Chances are, you do not.
- In channel 85, change 0 to 1

Adventures in running an AMI locally

2020-06-22T00:00:00Z

I recently had to do some spelunking into a long-updated AMI image to move it over to automated builds. The AMI had been updated over the period of a few years with security updates, OS patches, configurations, and more, and very little documentation was generated on those changes, as organic growth tends to do. I wanted the opportunity to poke at it over time, but didn't necessarily want to burn the compute time in EC2 to maintain the instance, so I wanted to get it booting locally.

Of course, Amazon does not let you download AMIs unless you had them built and uploaded in the first place.

In this example, I'm using Linux to create disk images, and I'm running the resulting image in Hyper-V on Windows 10. Some commands can be altered to work with other environments.

Tools Needed

awscli
gunzip or 7zip or WinRAR to decompress a .gz file
qemu-img from chocolatey or here

The Process

Start a new instance with the AMI you'd like to work with. When creating the storage, uncheck delete on termination.
Once created, terminate the instance, it isn't needed anymore.
Create a new, nano Linux instance with default settings.
Within Volumes, attach the volume from your first instance to the new Linux instance.
Create or identify an S3 bucket to store your image to, and make sure the instance profile of the Linux EC2 instance can access that S3 bucket.
SSH into the Linux machine, and open a screen or tmux instance to shield you from disconnections.
Identify the device node of the new image. You can dmesg | tail or look in /dev/nvme* for new matching, unmounted nodes.
Now we image that device directly to S3. Replace /dev/nvme1n1 with the device you found, and your_bucket_name with the destination you chose in S3. This command pulls a raw image, compresses it, and transmits it directly to S3:
dd if=/dev/nvmen1 - | gzip | aws s3 cp - s3://your_bucket_name/ami-disk-image.img.gz
With that image saved, you may now terminate the Linux EC2 instance you created, and delete the volume.
On your local machine, pull the disk image:
aws s3 cp s3://your_bucket_name/ami-disk-image.img.gz .
Use gunzip, 7zip, or WinRAR to gunzip the disk image
Use qemu-img to convert the image to Hyper-V:
qemu-img.exe convert ami-disk-image.img -O vhdx -o subformat=dynamic C:\Users\Public\Documents\Hyper-V\ami-disk-image.vhdx
Create a new Hyper-V instance in version 8, with this disk image mounted to IDE
Remove the generated image from S3

Congratulations, you now have your environment in a local VM to play with.

Sharing your WSL2 environment with Linux

2020-07-07T00:00:00Z

It seems like I'm in a constant state of switching between Windows 10 and Linux on my personal laptop, so I keep both environments available in a dual boot. I've really enjoyed using WSL2 on my Windows 10 side, so much so that I have a bunch of projects that are in active use within that environment.

WSL2 uses a lightweight virtual machine to boot a Linux kernel, and each WSL Linux distribution keeps a complete ext4 Linux filesystem as a virtual hard disk image for faster -- and native -- file access on your Windows 10 host. Luckily, it's pretty easy to mount this filesystem if you're booted on the Linux side.

I'm using Windows 10 2004 and Pop_OS! 20.04, but this process will work with any Linux distribution that is set up to mount NTFS partitions read/write using ntfs-3g and can install the guestmount utility via libguestfs.

To do this, the Windows 10 disk will need to be mounted within your Linux environment. On my Linux installation, I mount my Windows 10 volume using ntfs-3g under /mnt/c.

You will need to find your root virtual disk, which is located in the application package directory of the WSL Linux distribution being used. In Windows, this follows the pattern "C:\Users\username\AppData\Local\Packages\distribution\LocalState\ext4.vhdx", where C is your drive letter, username is your Windows username, and distribution is the generated name of the distribution used. If one is using Ubuntu, the generated name is "CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc". I'm going to use this path in the example below.

The other tool we'll need is guestmount. This can be installed on Debian/Ubuntu/derivatives by installing the libguestfs-tools package using APT.

sudo apt install libguestfs-tools

Now, let's mount the partition. The mount points in the image do not like being mounted as a normal user, and I'm happy to hear suggestions on how to get around this. We're using the allow_other flag to let other users have access to the filesystem, and mounting it under /mnt/wsl. You can alter the username, distribution, and mount point to match your system.

sudo mkdir -p /mnt/wsl
sudo guestmount -o allow_other \
  --add /mnt/c/Users/username/AppData/Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/ext4.vhdx \
  -i /mnt/wsl

Your WSL2 distribution is now available under /mnt/wsl. I haven't found any odd side effects, except that Visual Studio Code reminds you to install the Remote - WSL extension, as WSL is available on your system. Go figure. :)

Remember to use guestunmount when complete, before the Windows filesystem is unmounted. Too many force unmounts will eventually cause problems with the WSL2 environment, and there isn't a lot of self-healing available.

The Ongoing Saga of this Commodore B128 (1/4)

2021-02-26T00:00:00Z

This is my Commodore B128, serial C002720. The B128 is the low-profile US version of the Commodore CBM-II, a machine designed to replace the PET/CBM series, released around the same time as the Commodore 64. Other pages, linked below, do a great job covering the history of this machine.

When I received it, it looked great but did not work. Upon applying power, the LED lights, but the connected screen over composite is garbled, looking almost like it lost sync. On a 1084S, presents almost looking like characters. On a LCD over composite, just looks like flickering.

No sounds are made when power is applied. Pressing CONTROL-G on the keyboard does not produce a beep. As a side project, connected the keyboard via USB to another machine, and verified that the keyboard works splendidly. Connecting a Commodore 4040 drive to the IEEE-488 bus will light up when the B128 is booted, but that could just be power applied to the bus. Attempting to type commands does not result in any activity from the drive.

After a little bit of starting, I decided to remove the variable of potential ripple or power shorts by recapping the OEM power supply. There are plenty of forum posts of DOA power supplies, might as well get one win in.

Resources

First up, the resource list. None of this diagnosis would be possible without the following pages, created with obvious love and care by the community of people who continue to appreciate Commodore and/or the CBM-II machines.

Diagnosis

Time for some diagnosis with absolutely no knowledge of how anything this works, armed with schematics and images from zimmers.net. I'm making this post to keep myself accountable.

Power rails
- No short to ground
- Clean 4.99v at power LED
- Clean 4.96v-5.02v on major ICs across the board
Addressing, timing, reset
- CPU clock is clean
- Dot clock is clean
- RESET line starts low, then moves high, and the address lines start to make some noise, so it seems like the 6509 might be ok
- Address lines have continuity throughout
- Address lines out of 6509 at U9 look like decent square waves showing proper TTL. Each look okay on the oscilloscope, but A13-A15 on the logic analyzer look stuck high after a short amount of time -- maybe after the RAM test?
  - Some research here suggests my kernal ROM isn't in a good place
Traced video lines from plug, through TTLs back to the 68B45P at U7
- Continuity is good across each path
- Video signal looks something approaching normal
- In most, but not all, cases, there is no hsync signal out of the 6845
- In some cases, there is an hsync pulse, with no relevant change in output
- It seems that the 6845 isn't going to initialize on its own, the CPU needs to initialize the 6845, which also sets sync
ROMs
- Signals out of kernal ROM at U61 look fine, from a TTL perspective
- For a fleeting moment, having the BASIC HI ROM at U60 inserted would cause a very noisy looking data bus, leading to a wild goose chase that I couldn't reproduce later
- Forums seem to indicate having a kernal without basic lo or hi would boot into a monitor, but no change when leaving those out
- Building a 2364 to 2764 adapter and testing in a TL866-II show that each socketed ROM content matches the binaries available online
- Buying a 2764 to 2364 adapter, burning a ROM to a 27C64, and inserting does not change anything for any of kernal, basic lo, or basic hi. I did not try all three at the same time, but I have no reason to believe that it warrants further checking
- Chip select coming from a 74S138N at U40 looks high on kernal (U40p7), basic hi (U40p10), and basic lo (U40p11), and that also seems super suspect. Chip select comes out of a 74S138 at U40, which is soldered. Could be bad? Can't test until desoldered, but maybe this is a RAM issue
RAM
- Initial checks of the data in/out lines (which are bridged) show that U65 and U73 kinda look shorted to ground on the oscilloscope, certainly a lower frequency on the logic probe
- For a brief moment, every single data line looked weird, but that could be the 275 doing its job, or the 275 sucks
- Tracing back to a 74LS275 at U12 shows the same grounded line. The opposite side of the 275 looks normal, so either the 74LS275 has a short, or something else on D1 has a short
  - D1 comes from U12p12
  - Passes through U65, U73, and the other bank of RAM if populated
  - Passes through P9p4
- No obvious issues on the top or bottom of P9
- Maybe a RAM IC is dead?

I'm at the point now where it's time to desolder parts. I'm likely starting with the 74LS275, and if that ends up good, moving on to the two RAM chips, and then looping back around to the 74S138.

I also have a standing offer to test the rest of my socketed chips in a working B128, and if this desoldering doesn't go well, that's my next step.

The Ongoing Saga of this Commodore B128 (2/4)

2021-03-02T00:00:00Z

In the last post, I introduced my US-market Commodore B128 that wasn't feeling like being a computer. A lot of the diagnostics looked okay, and I was just about to start desoldering components out of a combination of hope and despair.

Some Soldering Required

Each desoldered component was replaced with a same-size socket, and continuity tested from the pin receiver to the bottom of the board.

Step one was desoldering the 74LS275 at U12. I wasn't sure if there was an internal short that was bringing down D1 at pin 12, and I couldn't test it in circuit effectively. Once out, I put it in my TL866-II to test, and it tested good. For fun, I replaced it with another 74LS275, with the same results. Drat.

Second was the RAM connected to D1, at U65 and U73. That is, theoretically, the only other thing on D1. I don't have a DRAM tester, but I do have some 3764s which should be 1:1 compatible. Popped those in, no appreciable change. Drat.

Third was the 74S138 at U40, to figure out if there's an issue with chip select, since what I was seeing in the oscilloscope didn't really match what I thought the truth table said. It also tested good in the TL866-II. I tried a replacement SN74AS138N1 but that didn't change any of the chip selects, so maybe I'm reading that truth table wrong.

Hands in the Air

It was this point that I started to wonder if I was going to desolder every TTL chip on this board. Due to my lack of experience, I don't know what these address and data lines are supposed to look like on an oscilloscope, but something about them bother me. It shouldn't be power ripple, but I just have this nagging feeling that something is affecting the data bus on this board, and that's why things are getting weird. Furthermore, there's a huge difference in how the bus looks when the BASIC ROMs are installed versus when they are empty. While I've already successfully read them in my EPROM programmer, something is bugging me.

With that, I'm taking up the offer of another member of the B128 community. He's going to burn me a new 82S100 PLA, and while doing that, he's taking all of my socketed chips and testing them in a working B128 board. I still have a feeling everything's going to check okay, but at least it'll eliminate those chips, particularly the 6509. Next entry will be after those chips are tested and back in the board.

It's incredibly difficult finding a 74S138 nearby, though fairly available as used stock on eBay. I went the instant gratification route after reading up on legacy vs modern versions of these TTL chips. The S is a faster max propagation delay (8ns), high power component. The LS was a low power, but somewhat slower (21ns) variant. The AS has a typical delay of 9ns, whereas the ALS is 12ns. Figured the AS was the closest match to the component.

The Ongoing Saga of this Commodore B128 (3/4)

2021-03-15T00:00:00Z

In the last post, I ended up desoldering some components that I thought could be a problem, only to find that they appear to be just fine. I moved on to second guess my assumptions due to my experience level, specifically wondering about whether these address and data lines are correct. I then sent off all of my socketed chips to another member of the Commodore CBM-II community to see what he thinks.

Oh, ho, ho.

My new Commodore friend popped my 6509 CPU, 6526A CIA, PLA, and 3 ROMs into one of his test boards to verify functionality. My ROMs and PLA successfully ran for an hour of diagnostics. My CIA checked out okay (but looked quite different than the CIAs he had). My 6509... was toast. In two different machines, it hung up before it could even hit diagnostics. I don't know for sure if what he saw was similar to what I see on my board, but it certainly was not computing, and that looked a lot like what I was running into.

Now, nothing else using the 6509 was released by Commodore, so finding these chips in the wild is rare to impossible. Luckily, back in December, I ordered a Nu6509 from RETRO Innovations, and with any luck, that will arrive soon. The Nu6509 allows one to use a 6502, 65C02, or 65C816S CPU, and adds the memory banking logic of the 6509 to provide a fully compatible CPU for these machines. I ordered it as a "just in case", and now it looks like we have a winner.

That said, I'm fully aware that this could be one element of potentially multiple failures in this board, so I am not getting my hopes up.

In the meantime, I am awestruck by the work of Michal Pleban creating a replacement 8088 card for the CBM-II. Commodore originally created an 8088 board to allow CBM-II owners to use MS-DOS 1.25, however, since none of the I/O ports matched up with the IBM PC, it was DOS-compatible, but not PC-compatible, so of limited usefulness. Michal took the original card design, and created a quasi-virtualization layer to proxy those requests to Commodore hardware. Furthermore, he managed to get FreeDOS running on it from an SD card, making it a fairly usable XT-style machine that can work in high profile and low profile CBM-IIs. Now he has a schematic available, and is building boards to sell this fall. If I get this machine working, that may end up being my next step -- unless I can convince him to send me a card. :)

Next update when I receive my parts and my Nu6509.

What if I replaced Google Photos? (1/x)

2021-09-10T00:00:00Z

Years and years ago, as I started using operating systems besides Mac OS X full time, I decided to let go of iPhoto and start doing my photo management elsewhere. I ended up on Google Photos for a few big reasons. One, the launch photo editing was pretty amazing. Two, since the primary interface was web-based, it was easy to use pretty much anywhere. Three, since most of my photos were coming from my phone by that time, having it auto-upload from my phone was pretty amazing.

Some time has passed, and I'm starting to get that itch again. I still use Android as my primary mobile OS, but I'm less trusting of Google both from a privacy standpoint and a feature standpoint. They absolutely have the ability to mine through my data, even if I am paying for the storage. They also have a terrible track record of removing features and functionality that they feel doesn't get a lot of traction.

So, I have a home file server, I have outside cloud backup, maybe the landscape is better now for multi-device photo management than it once was. I'm going to explore.

What do I want?

There are some hard points that I like about Google Photos that I'd like out of any solution, and then there's other functionality that I'd really like to have but wouldn't stop me from migrating. I'm open to both open source and proprietary solutions, provided the proprietary solution doesn't limit me to the consuming platform.

Must have

Photos should sync to the destination without me performing the action manually
Photos could be viewed, added, or removed from a web interface
Albums could be created, viewed, or removed -- and photos could be moved in and out from a web interface
I should be able to download images locally from that interface
Basic categorization should exist automatically...
... and in particular, automatic facial recognition should exist and be navigable

Nice to have

Open source
Does not require a separate cloud service
A server side agent that works on FreeBSD
A native application for Android and/or iOS for faster, fluent navigation
Google Photos is pretty good at determining other objects, words, and locations from photos, and I'd like to see something similar. For instance, searching for "green", or searching for "car"
Location categorization for determining where photos were taken
Video organization along with photo organization
Automatic file organization, similar to iPhoto, to make it easier to export, back up, and avoid collision
Duplicate detection, in case two photo sources get mixed up
Public sharing of photos or albums, to allow those with a certain link to view certain photos without giving away everything

Where to from here

At the time of this post, without veering off to other solutions, these are the ones I'm going to be looking at, in alphabetical order:

Adobe Lightroom (proprietary, requires subscription)
LibrePhotos (open source)
Mylio (proprietary, requires subscription, potentially allows for self hosting images)
Photonix (open source)
PhotoPrism (open source)
Piwigo (open source)

Auto syncing from my phone

While some of the solutions I'll be looking at have some capacity for auto sync from my phone, I wanted to at least have a solution to get photos from my phone to my file server without having to mess around with it.

Enter Syncthing

Syncthing provides bidirectional or unidirectional sync between folders on two different devices. In some cases, this could be a documents folder on your laptop and your desktop, or maybe important files between work and home. They have agents for Windows, Linux, macOS, the various BSDs, and even Solaris. Even better, they have a first party client for Android. A third party is currently working on an iOS client that will likely cost some money to use.

I was able to set up my file server and my Pixel 4 very easily, and was able to point the Pixel at the QR code from the file server's web interface to link up the two devices. By default, the Android client is set up to send pictures one way from the camera folder to another device, so it was a matter of flipping the switch to enable it, and authorizing the connection from the file server and setting the destination folder. All of the NAT traversal was automatic, and within a few minutes, all of the photos from my phone were safely on my file server.

That seems like a good starting point to me, I'll worry about a Google Photos export once I find a decent solution.

More to come.

A Surprisingly Annoying Amiga 3000

2021-12-20T00:00:00Z

The Amiga 3000 was a high-end Amiga released in 1990, with a redesigned case, a 68030 processor, up to 16mb of RAM on board, and built-in SCSI support. They didn't sell incredibly well, and at least for me, were remarkably hard to find. Naturally, I found myself a broken one.

This one would boot immediately to nothing -- a dim power LED, and a black but active display on both the VGA and RGB ports. The battery had already been cut out, and the situation looked really good at a glance, though I saw some damage next to where the battery was.

I started out with the usual suspects. Most of the ICs moved significantly when pushing on them, so every socketed DIP and PLCC was pulled and put back into place. I then checked voltages coming in from the power supply, and each rail looked close enough, then a select few voltages taken at important ICs, all looking close enough to normal. Still no boot. I then went through jumpers and found that one of them was out of place, leading me to believe this used to have an accelerator installed.

At that point, the system booted... once, but it was glorious to see that purple screen come up. Something was still flaky, and was causing no boot or partial boots, but generally couldn't make it to Workbench. Oddly, the more the machine was on, the less likely it was to boot. I initially thought it was a bad floppy drive as the problem got worse after I connected a floppy, but the system quickly stopped making it to the purple screen with or without the drive. I burned a couple of DiagROM EPROMs and started digging in. DiagROM would report errors while testing the upper bounds of Chip RAM, and sometimes fail while testing Fast RAM. After removing the upper bank of chip and all of the fast, we could occasionally start booting again, but the system would still occasionally hang. Sure, some of the fast RAM was MT, but even putting in some combination of fast to get only 4mb, the flakiness would continue to get worse.

Trying to be methodical, I went for Fat Agnus first as it does memory control. Doing a continuity check on lines coming out of the chip found issues with a data line. I pulled the board out from the case and flipped it over and found that the previous battery had leaked before it was cut, with obvious signs spreading out the bottom of the board. I treated the area with vinegar to neutralize, and then alcohol to clean it. Deciding that the corrosion got to it, I elected to replace the PLCC socket for Fat Agnus. Unfortunately, I managed to destroy a via in the process (or it had already become a problem due to corrosion, but either way, womp-womp), so I not only had to replace a socket, but had to add bodge wires anyway. Given that it was in the area, I decided to replace the Denise socket as well, but that went far better.

Once that was finished, still had some extreme flakiness ranging from no boot, to only outputting the DiagROM header over serial, to making it all the way but getting address errors while doing memory tests. I used the schematics to make a spreadsheet of each of Agnus, Denise, Paula, and Gary, their pins, signals, and next hop. I then used that sheet to trace each line from each of those chips and check for continuity.

At this point, this flaky Amiga was driving me nuts. Again, every address line and data line had continuity. The Amiga would even boot into workbench on occasion, provided I didn't have the second bank of chip ram in, or any fast ram in. Generally, the first boot of the day would work fine, but over time, the flakiness would get worse. DiagROM would start testing RAM and then start throwing address error exceptions, and sometimes just not even get to the point where it would finish the initial diagnostics before failing.

The address errors led me to believe that I still had an issue on the address lines causing an echo or something on the address bus was getting weird. I tried pulling out chips that were connected thinking they were artificially bringing down lines -- ramsey, buster, and the super dmac would all cause things to fail, but the address errors would persist. I put in an older 8372A agnus, but the symptoms were still the same, and I knew the 8372A was good. Running out of ideas, I pulled out the schematics for the ReAmiga 3000 board, converted the board layout to a png, and used a paint app to trace address lines all around the board. I noticed a few address lines went the other direction from agnus over to a 74LS147 TTL IC right next to the battery. I took out my magnifying glass and saw that there was a ton of green corrosion still remaining in the area. Treated it again, and desoldered it -- which was a huge pain due to the corrosion and the large ground plane. Replaced with a socket and a new 74LS147, and finished a chipmem test successfully. Got weird display artifacts, and then an address error while testing fastram. Due to the display artifacts, I reseated Denise again, and while boots would happen, there was still definitely some flakiness.

I was out of ideas that I could point at with evidence, and that's a lack of experience at work. Running out of options, but desperate that I was so close, I decided that since some of the capacitors were in the battery blast zone, and the machine itself is thirty years old, might as well replace all the electrolytics. I picked up a cap kit full of Rubycon capacitors from Retro Rewind, and recapped the main board and the daughterboard. After that, well.

At this point, it was just adding back fast RAM and retesting with the Amiga Test Kit until I ended up with a really solid 2mb of chip, and a really solid 12mb of fast, and I'll finish that out another time. This Amiga 3000 really works, does not crash, passes all tests, I'm super pleased. Next step will be getting a SCSI drive that will partition properly, and potentially a little retrobrighting of this very yellow case.

A Forgotten Amiga 500

2021-12-27T00:00:00Z

I came across a pretty nice condition, but broken, Commodore Amiga 500. The Amiga 500 was a cost reduced, mass market successor to the Amiga 1000, wrapped in a wonderful case with a built-in keyboard, side expansion, and a floppy drive. It didn't have the most amazing specifications, but it had tons of room to grow, particularly compared to some of the competitors at the time. By default, it had an 8 MHz 68000, 512k of RAM, side and trapdoor expansion slots, and a plethora of ports in the back. It, and the successors, were wildly successful in the UK and Europe, and had decent traction in the United States and Canada.

Initially, this one would boot to a black screen. The red power LED would light up, but the floppy wouldn't spin, no colours would appear on the screen, but at least the video would initialize. The power is probably good!

Opening up the case showed a fairly normal looking rev 5 motherboard. Two resistors by the serial port were black, likely due to someone blindly plugging something in at some point in the Amiga's lifetime. Worst case, that would affect serial, but shouldn't affect boot. It had a Commodore OEM Kickstart 2.04 ROM, with pins 1 and 31 joined together. There was quite a bit of dust, but no other obvious damage. Sitting in the trapdoor slot was a SupraRAM 512k chipmem expansion with a clock chip, which was a nice bonus.

Maybe because I've had some difficult Amigas before this, but I started out with DiagROM this time. Burned a 16-bit EPROM and popped it in with an adapter. Hooked up video and a serial cable, powered up, and... nothing. Black screen, no serial output. Crud. My guess was Agnus or CPU, as the Amiga will usually boot something with a dead chip elsewhere.

The Amiga 500 is notorious for ICs popping out, at least from the factory. Commodore would recommend that dealers drop them from a short height just to reseat ICs in case something went awry. I'm not sure if it was cheap sockets or poor assembly, but they had a history. That's where I started, and that seemed to be the culprit. Each socketed IC was incredibly stuck, so much that my chip puller was just not cutting it. I had to use a flathead screwdriver as a lever to gently rock the ICs out of their socket. Once finally out, there were no signs of corrosion, but the fact they were in so tightly led me to apply some De-oxit to the sockets before re-inserting.

Heyyyyyy, there's the DiagROM we all know and love. From there, it was pretty smooth. RAM tested well with the original 512k, as well as the 512k expansion. The CIAs tested OK, serial was functional, Paula pushed out sound just fine. The only real issue was the Enter key did nothing, no matter how firmly it was pressed. I pulled the DiagROM out, replaced it with the original Workbench ROM, and it fired right up. I was incredibly pleased.

The next step was the keyboard. Many Amiga keyboards are Mitsumi manufactured, with a soft membrane handling the keyboard matrix contacts and an on-board keyboard controller to talk back to the motherboard. I disassembled the keyboard to find a thankfully intact membrane with decades-old buildup of coffee or soda. I gently cleaned the membrane with water and just a hint of soap, and it cleared up nicely. Checking the continuity of the contacts under the enter key was successful, so it was likely to need either a new layer of graphite. Thinking the damage wasn't bad, I did the paper trick instead -- rub a piece of clean copier paper across the carbon contacts on the plunger to rough it up a bit. While apart, I also removed all the keys, washed the plastic keyboard base, as well as did a full scrub of each individual key. Reassembled the keyboard, booted it up, fired up the Amiga Shell, and tested each key. Success! Functional enter key, and all of the other keys worked as well.

In the home stretch, I replaced those resistors next to the serial port. No drama there, they pulled out great, easy to replace, serial still worked. Hot dang, this is a fully functional Amiga 500.

The Ongoing Saga of this Commodore B128 (4/4)

2022-01-21T00:00:00Z

In the last post, I found out my MOS 6509 was garbage, at the very least, and was waiting on an order of a Nu6509 from RETRO Innovations. There were some delays in receiving PCBs and getting them soldered up, but it finally arrived a couple of weeks ago. In the meantime, I ordered a WDC 65C816S CPU to pop into it.

The great news was that it booted up to a screen I've literally never had a chance to see on this machine. The bad news is that any command I'd enter would result in a trap to the built-in monitor, with a program counter somewhere in the BASIC RAM space. To add insult to injury, at some point while debugging, the whole thing went dark again, going back to the symptoms before. It felt like I was starting all over again. I packed it up and put it on a shelf, too upset to keep going with it.

Well, time to drag it out again. Given how the last three machines have worked out for me, I knew exactly where I was going to start before digging any further holes -- I'm recapping this thing. No readily available recap kits, so Mouser to the rescue, once you have the list of capacitors you need. It was incredibly uneventful, no ridiculously large ground planes, no battery leakage to power through. The capacitors all were somewhat within spec, so it may not have been needed, but at least it has another 40 years of life.

Once I powered it up, it was exactly as I left it. Power is fine, screen isn't behaving. I decided to go a different route, and I used Ben Eater's 6502 project to test my 65c816 and 65c02 chips to make sure they're working the way they should. On rare occasion, the Commodore would boot to the initial prompt, but would either provide a syntax error for anything read, or freeze entirely for any command.

I remembered reading that on the Commodore PET (at the very least) what you typed didn't go into any sort of buffer RAM, but was just sitting there in video RAM, and the machine would read what was typed right out of video RAM. If that was the case here, maybe these syntax errors or occasional start issues had something to do with the access to video RAM. I checked the lines in and out of the video RAM, and the chip itself seemed to be responding properly. Moving backwards to the latch at U8, power looked good, and while I was holding the oscilloscope probe to OE to watch the signals on power on, it booted. Not only did it boot, but it started executing commands. Not only that, but my AV2HDMI started working due to proper sync.

Hot dang. I reflowed the joints on U8 thinking this was a cold solder joint situation. Thinking back to the original issues, moving and pulling chips nearby could have easily caused movement of that joint, causing intermittent issues on the data bus, power fluctuations, and so on. That, combined with a loose socket for the CPU, easily explains the last part of the symptoms I saw. I'll take that win.

Further testing is showing that this thing is now fully working, and while some of those chips didn't need to be desoldered and socketed, it'll help for any future work that's required. The worst part was reassembling the machine. It's been disassembled for over a year and a half, I had a hard time remembering how the jigsaw puzzle went together. Next steps? See if I can get my SD2PET Future to cooperate with the B128, order Space Chase, and maybe see how those 8088 boards are coming along.

Varta'd by the Amiga 4000

2022-02-02T00:00:00Z

In very early 2021, really bored by the pandemic, I was on the lookout for busted Commodore and Amiga machines. Someone reached out with an Amiga 4000 they had available. They had no way to test it, all of the cables and accessories were missing, and it's been in a garage for decades. Sounds like my kind of thing.

The Amiga 4000 was the last of the "big box" Amigas, and a pretty decent last hurrah for Commodore. Housed in a fairly generic PC-like desktop case, the Amiga 4000 had a 68030 or 68040 processor, 2mb of chip RAM, up to 16mb of fast RAM, the new AGA chipset providing enhanced graphics, and IDE instead of the SCSI of the 3000. There has long been a debate on whether the Amiga 3000 or 4000 is the superior machine, with a lot of gotchas. I think they're both fantastic machines with a ton of expansion opportunities, but for me, the edge goes to the 4000 with AGA. Why Commodore didn't include the scan doubler on this one eludes me.

Taking Inventory

This 4000 looked and smelled like it had been in a garage for some time, and after coming inside and warming up, you could smell the leaking capacitors. Pulling off the case revealed a motherboard awash with blue-green from a long-leaking Varta clock battery. The green was in the case, on the pins, between the slots, and even on the pins of the 2 DE-9 joystick/mouse connectors. Along with that, the 4000 suffers from the same issues as early to mid 1990s Macintosh machines, where the SMD capacitors weren't all that great, and failed by leaking electrolyte as well. That's two major sources of trace-eating damage, and this one was full of it. I may have bitten off more than I could chew.

On the plus side, this came with everything and then some. It already had a CD-ROM drive, the original floppy drive, a working power supply, and some additional Zorro cards to be investigated later. Once I got under the drive cage, the best surprise appeared, a Warp Engine 68040 card with 32mb of RAM on board, expandable to 128mb. If anything, that would be useful in another machine if this never came back to life.

Clean up

Job one was to get rid of everything that could be continuing to damage the board before actually trying to fix anything. First thing was snipping off the battery with side cutters, then lightly scrubbing the board with isopropyl alcohol to get off the initial battery fuzz. I desoldered and/or removed all of the capacitors, and pulled out all of the jumpers and socked chips. From there, the board was covered in paper towels soaked in vinegar to neutralize the chemicals eating at the board, followed by a scrub with soap and deionized water, followed by isopropyl alcohol. The end result didn't look too awful. There's obvious damage where the battery was, one of the capacitor's pads completely lifted off the board due to the damage, there's some corrosion on the backing plate for the DE-9 connectors, but most of the stuff is still there.

Doing a continuity check around the clock area of the board showed at least nine connections that were not meeting up. In many of these cases, the connection between a pad and a trace was missing, so at the very least, there is going to be some bodge work.

Half the effort in twice the time

As I was early in my learning to repair adventure, I was methodical but naive. Each of the electrolytic capacitors was replaced, and for the one with the missing pads, wires were attached to the via on each side and strung to the capacitor. I dutifully added bodge wires to each of the nine connections that were missing, and verified the connections with the multimeter. Everything seemed to be in order, at least from a connection perspective in the clock area.

The power supply was disassembled and cleaned out, as it was full of all the things one would find hidden in a machine after being stored for a few decades. All of the rails tested out okay with a multimeter, and I couldn't see any obvious damage to the capacitors on the power supply board.

For fun, I attempted to boot the machine. It did power on. It showed a grey screen and nothing more. On one hand, at least we have hsync and vsync, on the other hand, we don't even know if the CPU card works or not -- the power LED sure didn't get any brighter. Still, that's progress. After running out of reasonable ideas for a next step, this 4000 went on a shelf for a while so I could find some successes elsewhere.

In the middle of my Amiga 3000 repair, I had the chance to test the Warp Engine on that motherboard, and it worked. I couldn't use it permanently, for multiple reasons. The Warp Engine is the wrong size to fit around the 3000's daughterboard, and there's no way to fit the drive cage over it with the way the memory is positioned. At least I knew it worked. Knowing that I had a valid and working CPU, and now that I knew about DiagROM, I threw the DiagROMs in the 4000 to see what would happen. It sure didn't give me a display, but it absolutely gave me output over serial... though e x t r e m e l y s l o w l y. Fewer than 10 characters per second. It gave me hope that this board could return to life, or at the very least, there were some good components left on here.

More effort with more thought

As I mentioned, I was methodical but naive. There are a bunch of small ICs near that battery, particularly two 74HCT166 at U975 and U976 and a 74HCT174 at U177. A bunch of those bad connections were on the U177 which meant a lot of damage was done to the board in that area.

I assumed at this point that the chip was also bad much like the connections beneath it, and took it off. Out of an abundance of caution, I also yanked U976. I assumed U975 was good since DiagROM booted at all, and there's a pin on U975 that is required for anything to happen at all. I removed them extremely carefully, but a ton of pads on U177 came with it, which meant they had completely detached from the board anyway and were only held down by the pressure of the IC on the other pads. That sure explains the number of busted connections. U976 came off cleanly. I cleaned the whole area well, and scraped the corrosion off the remaining pads. I attached a new 74HCT166 to U975, which went shockingly well. Checking continuity showed that two of the pads off U976 did not make contact with the resistor bank below, and so two wires had to be bodged from the chip to those resistors. Then, turns out the +5v on the other side of those resistors was not making contact, and so wires had to be placed between the vias and the resistors. One via was too badly damaged, so the wire had to be wrapped around the edge of the board to the capacitor feeding the 5v on the other side of the board.

I started the machine, and DiagROM started! and died!

It did not come back.

Using the oscilliscope, I started poking around at signals, not really finding anything amiss. There's a 74F245 at U891, and its job is to handle signaling of fast RAM. I didn't have any fast RAM installed, as it's sitting on the Warp Engine, so I hadn't bothered checking it until last. As I'm probing, I touch it to the ground pin in the lower right of the chip, and it springs to life. More trace damage. Turns out the ground on that chip is important, even if you don't have any RAM... I took the opportunity to drag some flux around all of the ICs in the area, and apply some fresh solder around each.

We have a winner. DiagROM started up just fine, detected the CPU, chip RAM, fast RAM just fine. I ran a full memory test, as well as the CIA/IRQ tests to make sure those survived okay, and things were going splendidly. Everything seemed to pass! I swapped out the ROMS with the Kickstart ROMs it came with and started it up. My bench LCD lit up, then went back to power save mode.

Back to the scope.

I couldn't find anything. Everything seemed to be okay. For grins, I hooked the 4000 up to a Commodore 1084S wondering if somehow I was using a screen mode that was not supported. Turns out, yes. I still don't know why that's different between the 3000 and 4000.

That was an excellent sign. What I still had was some extreme flakiness, occasional nothings on power up, and no boot to Workbench. While finding the issue with U891 earlier, some of the probing would cause the board to work, and I was seeing similar results here. I realized that it wasn't necessarily the act of probing causing things to work, but the logic board slightly bending when probing certain areas. Heading back to the oscilloscope and tracing around the same area, it became obvious that the +5v connections on the bottom of the set of resistors near the edge of the board were not all completing. In fact, only one resistor was consistently getting +5v, and the only reason anything was working was the voltages generated on the other side of the resistors or the occasional connection that occurred when the board was bent slightly. Not a great situation. I started bridging the connection from the input side of the resistor to the vias on the board just below providing the +5v with short unshielded wire, but it looked incredibly messy. Instead, I used slightly longer wire with the sheath still on, and created a line of curved/looped wires instead. One via didn't have enough viable copper to create a good connection, so a wire was looped around the edge and connected directly to the capacitor on the other side. Sure, it's still ugly, but easy to understand what's happening.

That fix sealed the deal, and we had boot. I still hadn't connected the real time clock latch at U177, as the chips I had ordered long ago were not the correct size. The 4000 will happily boot without it, though, you just can't save the time. I was able to connect up a gotek and run Amiga Test Kit successfully, with everything except the clock passing tests. The memory on board the Warp Engine checked out just fine, so it was time to make it do something real. I connected a CF card and adapter to the IDE interface, pre-configured the card on WinUAE with Amiga OS and some games, and booted it up. Everything was checking out fine, I was able to play a couple of games and listen to some music, and sat a little surprised at how well it was working considering what a hack job it was.

The hack job gets worse

As mentioned, U177 came off with a bunch of pads. I made an attempt to connect some slightly thicker wire from the vias underneath where the chip was to where the pads were supposed to be, in preparation for the IC replacement. I received a batch of 74LS174 SOIC, and finally got around to putting it on the board. Carefully balancing tweezers, a pre-tinned pad 9, and the 174, I put down the first leg of the chip successfully and delicately started working on each new leg. Much of the pads on the "left" side of the chip (pins 9-16) aren't connected to much, but those were the pads I had. That side went well, and the chip was fairly secure. I started work on the right hand side, and it all went downhill fast. The heat of the iron against the wires had a tendency to desolder them from their vias given how little was actually adhered. Instead of trying to do the same thing again, I pulled out those wires out completely, and soldered legs to the remaining pads on that side of the chip. Resigned to more bodge wiring as there were already missing pads on the left side, I went for the remainder.

In total, pins 1, 2, 3, 5, and 9 all had to be hand wired to the resistor pack above it, to a via near it, or to resistors on the other side of the board. The above blurry picture is in the middle of the process, as I was merely trying to see if it would work, but hadn't shortened or cleaned up the mess.

The chip itself checks out just fine, the wiring is all beeping out on the multimeter, it's ugly as sin.

Guess what, though? Clock found.

Pure Amiga goodness

I'm still left with something of a hack job. The board in this machine is so very far gone, and I have no way of knowing for sure that I've neutralized all of the damage. The number of visible traces around that part of the logic board is worse than I've seen so far, and I'm frankly surprised at how well the machine works now. Given that all of the custom chips are working great, and all of the supporting hardware is functioning normally, this could be a good candidate down the road for a A4000 replica board or an AA3000+. It's possible that I won't bother deciding until something else fails horribly, but as it stands, this machine is going to be staying in the permanent collection due to the amount of failure.

That said, all of the traces were covered in enamel and double checked. The case went through one more round of vinegar treatment on the places that battery corrosion had leaked onto the metal. It also had a re-clean, as I hadn't cleaned it since early 2021. I reassembled the board back in the case, which was incredibly challenging as it had been disassembled since January of 2021, but made it. I reinstalled the Sunrize AD516 sound card that came with the machine, along with a freshly upgraded CyberVision 64 that came with another machine. Booting up the machine looked downright perfect, and I'm still in awe that this machine was so far gone and yet boots up into a modern Amiga OS without any real difficulty.

Next up is some minor work to make it a better machine long term. The CD-ROM has an obvious stripped plastic gear, you can hear it when it first spins up, though it doesn't affect its ability to read. I will probably replace the whole device. I have RAM on order to bump the machine from 32mb to 128mb. I'd also like to get an IDE splitter to allow the CF card to mount in one of the slots at the rear of the case while still having the IDE CD-ROM work in the front.

Other than that, it's pretty great to have an Amiga 4000 around.

A Macintosh LC Out of the Spotlight

2022-03-04T00:00:00Z

The Macintosh LC was a mid-range computer released in 1990, as part of a trio of new Macs (including the Classic and IIsi) allowing Apple to target a more cost-sensitive user. At $2,499, it was the lowest cost colour Macintosh released at that time. It was hobbled intentionally by Apple from the getgo. While the 32 bit 16 MHz 68020 wasn't necessarily a bad processor, Apple saddled it with a 16 bit data path, didn't provide a way to add a FPU, and limited the maximum RAM to 10mb. To add insult to injury for a wistful retro enthusiast, the LC was the last nail in the coffin for the somewhat more interesting IIgs.

Nevertheless, this was a machine I wanted so badly at launch. I had a Macintosh 512Ke at the time, and the idea of having a colour Macintosh for what appeared to be a reasonable price was really alluring. By 1990, a black and white Macintosh with 512k of RAM and a 68000 was already losing usefulness. Unfortunately, it was only a reasonable price compared to other Macs, and it just wasn't in the cards for me. My school got a couple, though, and I was able to play with some great applications while there.

I picked up this particular machine from a local computer reseller. It was obviously turned in, but far too old for this particular retailer to reasonably sell. I found it on Facebook for a price I was comfortable with and brought it home. The machine was in pretty great condition, inside and out -- no major damage, no obvious leakage anywhere. Booting it up for the first time gave me a display, but a flashing question mark and a grating squealing noise. There was absolutely a hard disk in there, but maybe it had been wiped, or maybe it was the source of the noise. I inserted a System 7 floppy, and it brought me to a desktop. Drive Setup didn't see anything on the SCSI bus and the sound was driving me nuts, off it went again.

I opened up the LC again. I first assumed that something was going on the power supply to make the squealing noise, but the power supply was quiet. The hard disk was spinning up on boot, but I couldn't hear it seek at all. The squeal was louder, though, but it turned out to be coming from the speaker. Oh, right, we're in the 1990s now, and these are surface mount capacitors. I wondered a little if the capacitors had anything to do with SCSI being functional. A quick browse to Console5 to order a new cap kit, and I wrapped up the machine to work on later.

Capacitors in hand, I opened up the machine and removed the board. The LC uses captive plastic brackets to mount the board to the case, so it's incredibly easy to remove. There are 17 capacitors on the board, all sitting near some melty plastic, but this was pretty easy compared to the Amigas. I have been using the controversial twist and remove method to get rid of the caps, used braid to remove the remainder of legs and solder from the board, and replaced each with their appropriate cap. I then rinsed the board with flux remover and alcohol to get rid of the soldering debris as well as the left over capacitor "juice", and reassembled. The machine turned on, and the squeal was gone. Unfortunately, still no disk.

Doing some web searches on old Macs and their disks, turns out that old SCSI drives -- Quantums in particular -- had a tendency to have their heads stick to the bumpers on either side of the platters. Figuring I had literally nothing to lose by trying, I removed the cover of the hard disk and found that no obvious damage was there, but the head was not planted up against a bumper. I powered it on while open, and the head simply would not move. For grins, I put a shim around the rubber bumpers on either side, even though they didn't feel sticky or tacky. I then powered it on again and started lightly tapping on the head until it started seeking... and the Mac started booting. I immediately powered down. I added a little bit of oil to the head and reassembled the disk. One last power up, and it boots! Before buttoning up the machine, I replaced the PRAM battery with something from this decade, and added 2 4mb SIMMs for a total of the maximum allowed 10mb of RAM.

The disk itself had System 6.0.8 and a wide variety of personal documents and kid projects dating up to 2001, which is a heck of a run for a 4mb 68020 Macintosh. I took the opportunity to make some System 7.1 floppies, wipe the drive, and create something close to period correct. With the keyboard and mouse already in working order, that was about it, this Macintosh LC lives to be admired for another day. As a future to do, I am very likely to replace the hard disk. That head is probably going to stick again, and those platters looked absolutely terrible. It'd be fun to increase the VRAM on the machine as well, if something reasonable comes along. Even better if I could find a IIe card for the PDS connector, but I don't think a reasonable one will come along...

Basement dwelling Commodore SuperPET SP9000

2022-08-30T00:00:00Z

The Commodore SuperPET (or MMF - Micro Main Frame in Europe) was an enhanced 8032 designed by the University of Waterloo for programming education, and then sold retail. It added a second CPU, the Motorola 6809, as well as a total of 96k of RAM to the original 8032. In 6809 mode, on the software side, it supported a different BASIC and 6809 assembler, as well as APL, COBOL, FORTRAN, and Pascal, as well as a built-in text editor and terminal. In addition, the machine had a real RS-232 port, allowing it to connect up to a university or corporate mainframe for sending their code and w ork upstream.

While I had a decent amount of experience on PETs from elementary school, this is the first PET series machine I've owned... unless you count the CBM-II. I've wanted to add one to the collection for a long time, but the ones I've found were either wildly expensive, or rusted out husks that were best used for parts. One also has to consider their size -- there's no breaking them down for storage, you're going to get a huge, heavy hulk of a computer.

I purchased this SuperPET SP9000 in the above condition in a known not-working state. I powered it on and heard the transformer hum, but there was no output from the display, no startup chirp, no sign of life. I attempted playing with the switches on the side to enter 6502 or 6809 mode, but no changes occurred, and I couldn't tell if it was the board or the monitor. For my initial checks, I tested for AC voltages from the transformer, verified they were coming through the connector, and then checked 5v at the CPU, CRTC, and RAM. All of that seemed just fine, it just wasn't doing anything. As the SuperPET is effectively an 8032 with a daughterboard containing 64k of RAM, the 6502, the 6809, and supporting hardware, it seemed easier to me to make this an 8032 and debug that side first. The 6809 daughterboard was pulled off, and the original 6502 was placed in the original socket on the primary board. I checked the chip selects of the ROMs, and it appeared to not be leaving the kernel ROM at all. Seeing that there are also 12v, 9v, and -5v rails on the board, I checked the -5v and 12v at the RAM, and saw -6.5v and 10v. Probably not good, but also not sure if I had a power source problem or something wasn't initialized properly.

Given my complete lack of experience with this era, I took this as an opportunity to try out bitfixer's ROMulator, and ordered one. The ROMulator is a neat device that accepts a 6502 processor, but takes over regions of the memory map. This allows you to swap out entire ROMs for debugging purposes or to try out different code. It can also replace the existing RAM, or extend it. It looked like an incredible tool for repair and debugging, but could also allow me to swap out ROMs down the road without having to desolder existing ROMs. I picked up order #9000 which I thought was a good sign that this was the right move, and it took about a month to arrive.

When the ROMulator arrived, it didn't take long to assemble it. I ordered mine with the independent programming board, which allows one to flash firmware and debug a live system without the use of an additional Raspberry Pi. The Pi is hard to find inexpensively right now, and my only spare is a Pi 1, having the shorter, non-standard header. It was easy to solder, everything that needed to be done was through-hole, so within about 20 minutes, I was ready to rock. I inserted the ROMulator into the 6502 socket, inserted the 6502 on top of the ROMulator, and set the DIP switches to emulate an 80-column CRTC PET with 32K of RAM. I flipped the switch, heard the startup chirp, and the display lit up with the familiar 31743 bytes free.

The fun thing with the ROMulator is that you can configure each memory region independently. If you only want to replace one ROM, for instance, you just redirect that region of memory to a binary file. In my case, I used it to try to determine if I had a RAM problem, a ROM problem, or both. I started out by flipping only the RAM region to the ROMulator, and allowing the original ROMs to passthrough. I restarted the machine, and I got a chirp and the boot screen -- signs point to the ROMs being okay. Then, I tried the reverse, letting the ROMulator handle the ROMs and passing through the RAM. Flipped the switch, and nothing.

Neat, it's RAM access.

My first thought was that it wasn't actually the RAM itself -- a lot of 8 bit machines from this era will boot with some bad RAM and just fail miserably at doing anything, so I felt like I was dealing with a buffer or some other logic chip. With the oscilloscope, I started looking at address lines from the CPU to the various buffers, and then from the buffers to the RAM chips, and I was getting activity.

OK. Let's start over with the basics, and check voltages. Remember back when I saw 10v on the 12v rail? Sure enough, it's still 10v at the RAM chips. Following it back to the 12v regulator at VR2, it was still around 10v. The -5v rail was still -6.5v, but that regulator is fed by the 12v rail, so I figured I could attack this one at a time. Removing VR2 was a pain. The 7812CK is a TO-3 package, sitting on top of a large heat sink shared with one other voltage regulator. The poles are soldered in like one would expect, but Commodore riveted the regulator to the board. I tried using a punch tool to knock them out, to no avail, and ended up using progressively larger drill bits until the regulator came loose. Did not enjoy, at all. Once out, I noticed that there's no barrier between the bottom of the regulator and the heatsink it's attached to, so life got less expensive. My local electronics store carried both regulators, so I picked them up. I then reattached the new regulator, and used screws and nuts to secure it to the board and heat sink.

Now there was a nice, clean 12v. The -5v regulator at VR1? Still -6.5v. Doh.

I'm not sure what happened to this machine that two voltage regulators decided to give up, but that's in the past. I'm glad I picked up both regulators, and luckily, VR1 was a lot easier to replace. It's a LM7905CT in a TO-220 package with three through hole pins going into the board, and no other carrier or heat sink. A quick desolder of the three pins, insert the new one, solder it and bend it back to a reasonable angle. I applied power to the machine, but still no startup chirp. The voltages at the RAM chips, however, looked great.

Now what?

I went back to the ROMulator and continued messing around with RAM a bit. Instead of having the RAM completely pass through, I started dialing down the passthrough so that the ROMulator would handle some of the RAM available, but let the rest of it pass through. If I had the ROMulator handle $0000-$0400, I could get the PET to boot with less than 4kb free, but it absolutely would not do anything useful. The ROMulator also had pettester available to do memory checks and other diagnostics. It would start up just fine, but once it got to the memory test, the screen would start filling every other character with the @ symbol. Turns out, that's hex 00, and I started to assume that there was some sort of addressing problem. I started looking at the address lines starting at the CPU all the way to the RAM, and noticed that some of the readings coming out of the 74LS393 at UD13 toward the RAM looked off. I connected a logic analyzer to the inputs and outputs and realized that it wasn't quite lining up during the initial memory test. I piggybacked another 74LS393 on it, and the symptoms changed significantly, where more RAM would be detected, and that was the final straw. Out came the original 74LS393, and replaced with a new one.

With the ROMulator still keeping the first 1k of RAM internally, it was now detecting slightly more RAM, but still not working properly. The big difference now was that pettester no longer crashed hard, but actually declared some memory failures. We probably actually have RAM faults at this point, likely not helped by bad voltages and age. At this point, I ended up using a trick from Adrian's Digital Basement to find the bad RAM. I entered the following BASIC program:

10 for i=1 to 4096:poke 1280+i,82:next i

I'd then use SYS 4 to enter the machine language monitor, and looked at the memory from $0400-0440 (m 0400,0440), which represented the BASIC program I just entered. I exited back to BASIC and ran the program until it ate itself, which was quickly, and then redisplayed that memory range. Comparing the two outputs, it became clear when converting hex to binary which bit was sticking, which was the first one, corresponding to data line D0, which means the 4116 at UA19. Out it came, in went a socket and a new 4116. Once I confirmed it started up, I yanked out the ROMulator to see where we were at.

Ayyyyy.

Okay, sure it's the wrong amount of RAM, but that's a success no matter how you look at it. Since it was a problem with the upper bank of RAM, I had to change methods just a little bit. I started by looking at the other 74LS393, but that all looked just fine. On startup, the PET will do a memory test to determine the upper bound, and all of the signals looked normal. I then tried a variant of the above BASIC program. Since we were no longer overwriting BASIC memory, I had it start in the upper bank, and just had it read back values after poking them, to see if 82 turned into something else.

10 for i=1 to 4096:poke 16383+i,82:print peek(16383+i) " ";:next i

This time, we ended up at the opposite end with D7 giving trouble. Out came the 4116 at UA4, socketed, and a new one put into place.

Hello.

At this point, I could finally start writing BASIC commands and getting the proper response, including loading programs from a SD2PET Future. Pretty satisfied with the result, I reattached the 6809 daughterboard and the side switches to see what might be broken there.

Turns out, nothing.

From here, it's time to play around a little bit. To come in the future will be a better cleanup of the case, and at some point in the future, the Super OS/9 MMU will arrive from RETRO Innovations, and I can give OS/9 a go on the 6809 side of this SuperPET. I may also have a very broken Commodore SFD-1001 heading my way, so I might have an option for using actual disks in the near future.

How to dumpster dive for CRT monitors

2022-11-21T00:00:00Z

I have started to pull together a few different sources online for 15 KHz capable CRT monitors, mostly to support this awful Amiga habit I've formed. This would also be useful if someone was searching for Atari ST monitors, Amiga monitors, or even retro gaming and arcade monitors. I will probably find another way to publish this information, but while it's in progress, Google Sheets it is.

Amiga or Atari ST or Console 15KHz Monitors

Connecting an Amiga mouse to a classic Macintosh

2025-03-25T00:00:00Z

I find myself without a classic Apple M0100 mouse for my Macintosh 512K Enhanced, which sure makes it hard to test out some repairs. While I work out how to get one in reasonable shape for a reasonable amount of money, I still needed something to test with. Turns out, the classic Mac, Amiga, and Atari ST all have the same theory of operation, a quadrature encoder sends X, Y signals to pins, 1 or more mouse buttons send a signal. Luckily, all of these quadrature mice send the same approximate signals, so it's a rewire job. Want to wire an Amiga mouse to a Mac, or vice versa?

Signal	Mac Pin	Amiga Pin
Chassis GND	1	--
+5v	2	7
Signal GND	3	8
X1	4	2
X2	5	4
n/c	6	--
Button	7	6
Y1	8	3
Y2	9	1

One interesting note, most of the Macintosh mouse pinout diagrams label X1/X2, Y1/Y2 on the Mac mouse differently than the above table. I think these are making assumptions about how Apple labeled these pins. If you wire X2->X2, Y2->Y2 based on those pinouts, you'll have a reversed cursor in both directions.