Week 2: Load Goblin

Week 2: Load Goblin

52 Projects in 52 Weeks | October 11, 2026

I recently bought a Timex Sinclair 1000 on eBay. It came with the computer, a 16K RAM expansion pack, a stack of cassette tapes, and that miserable little blister membrane keyboard that makes typing anything feel like punishment.

I never owned a TS1k as a kid, but my friend Bruce did.

Bruce and I, mostly Bruce, would spend hours painstakingly typing BASIC programs from magazines like SYNC. Usually games. We had no idea what most of the code actually did, but figured typing it in was probably a good way to learn. More often than not, the program wouldn’t run. Somewhere in those hundreds of lines was a typo, and finding it could consume the rest of the afternoon.

If we finally got something working, or simply ran out of patience and wanted to pick it up the following weekend, it was time to connect the cassette recorder and enter SAVE “GAME”.

Sometimes it even worked.

I eventually got a Commodore 64 with a C2N cassette drive, which was specifically designed for the job and still managed to make loading and saving software an adventure.

I’m not saying those experiences scarred me. I’m just saying I know better than to repeat them.

Which brings me back to my newly acquired TS1k and its stack of tapes. Especially “The Cube Game” as I refuse to research it, and want to experience it for the first time myself.

I found a crusty old Jensen portable cassette player at a thrift store, but I wasn’t particularly optimistic that cassette technology had improved while nobody was looking.

Then I started thinking. The cassette contains software encoded as sound. The tape player sends that sound to the computer through an audio cable. My phone can store files and play audio.

Why not replace the entire pile of tapes and the Walkman with my phone? Yet another tech made obsolete by the super computer in your pocket.

And that’s where a perfectly reasonable little project started getting out of hand in my brain.

If my phone can play programs into the TS1k, why not keep an entire library of them? Maybe find programs other people have shared? Better yet, if the sound is just code converted into noise, couldn’t I write BASIC on my laptop and turn it into something the Sinclair can load?

Or have AI write the BASIC?

Now we’re talking.

Forty-some years after sitting at Bruce’s house, I could finally make my own game without wanting to take an axe to that blister keyboard. Maybe a version of Doodle Jump. Or Super Breakout, in homage to Woz.

See, my brain has a habit of taking a perfectly good solution to a problem and making it a bit extra.

Sometimes a lot EXTRA!

So, Week 2 of my 52 Projects in 52 Weeks challenge is Load Goblin.

Why Load Goblin? Because anyone who has ever waited for a cassette to load on an vintage computer knows there must be a mischievous little goblin bastard living inside that tape deck. IYKYK

The idea is a mobile website that turns your phone into a cassette player for vintage computers, starting with my Timex Sinclair 1000.

The first milestone is simple: connect my phone to the computer, select a program, press Play, and get the damn thing to actually load.

If that works, I’ll work on a library of programs. If that works, I’ll see whether I can convert BASIC code into the audio the computer expects. And if everything somehow falls into place, maybe I’ll have an AI-generated game running on actual 1982 hardware by Saturday.

Of course, I have no idea whether the phone’s audio output will work. Old cassette loading was notoriously finicky, and I don’t know whether converting BASIC to cassette audio will require a simple utility or a graduate-level education in noises.

I could discover tonight, after the Michigan basketball exhibition game, that this entire idea is nonsense.

Or I could spend the week recreating the exact frustration Bruce and I experienced forty years ago, only this time with AI helping me find the typos.

Either way, I get seven days.

And I’d really like to finally play a game I made myself on one of these little machines.

Wk 2 – Update 1

A Process, a Plan, and Absolutely Nothing Working

One week down, fifty-one to go.

Last week, while rebuilding Wheel of Questions, I realized I had another problem to solve. If I’m going to build and document a new project every week, I need a repeatable way to get ideas out of my head and into something resembling a plan.

As anyone who has worked with me will attest, getting ideas out of my head is rarely the problem. Getting them organized, and keeping them from multiplying along the way, is another matter.

So thwe came up with a process.

Six questions. Every Sunday.

Thwe developed six questions that I’ll answer at the beginning of every project:

  1. What’s the story?
  2. Where did the idea come from?
  3. What am I trying to make?
  4. What do I hope to demonstrate on Saturday?
  5. What could possibly go wrong?
  6. How should the story end?

The questions aren’t particularly sophisticated. That’s intentional.

I don’t want to spend Sunday morning filling out a project charter. I want to capture the idea, why it interests me, what I hope to accomplish, and why anyone else might find it interesting.

The answers become the starting point for my Sunday blog post. AI helps me organize my thoughts, explore different ways to tell the story, and improve the flow. I make plenty of changes, rewrite things that don’t sound like me, and decide what ultimately gets published.

It’s a collaboration, not an exercise in outsourcing my personality.

Thwe developed this approach while writing about Wheel of Questions last week. Today, I used it again for Load Goblin.

Within a few minutes, I’d worked through the story of my friend Bruce, the Timex Sinclair 1000, cassette tapes, and my ambition to make forty-year-old technology do something it was never intended to do.

But getting the story down is only the beginning.

Stop building. Start asking.

I’ve been experimenting with another change in how I work with AI.

Rather than describing an idea and immediately asking AI to build it, I’m asking it to interview me first.

That sounds obvious. It’s what product managers do. We ask questions, challenge assumptions, explore possibilities, and try to figure out what we’re actually making before anyone starts writing code.

Yet when working with AI, it’s incredibly tempting to skip that part. You describe something, and the machine is more than happy to start building it.

Sometimes a little too happy.

So I’m trying to establish a repeatable process, and it starts with telling AI how I want us to work together.

Here’s a simplified version of the prompt anyone can try:

I’m starting a new project that I want to build and demonstrate by Saturday.

Before writing any code, act as my product management partner. Help me turn my initial idea into a realistic scope for one week.

Start by asking me those six questions, one at a time:

  1. What’s the story?
  2. Where did the idea come from?
  3. What am I trying to make?
  4. What do I hope to demonstrate on Saturday?
  5. What could possibly go wrong?
  6. How should the story end?

Once I’ve answered, interview me to refine the product scope. Ask one question at a time, using my previous answers to guide the next question. Challenge my assumptions, identify decisions I haven’t considered, and suggest simpler alternatives when I’m making things unnecessarily complicated.

When I introduce a new feature or idea, don’t automatically agree or add it to the project. First explain what it would cost in time, complexity, or risk, and ask what we’re willing to remove to make room for it.

Look for existing components, code, and services thwe can reuse rather than rebuilding things that don’t differentiate the product.

Don’t start writing code until thwe have agreed on the scope and I’ve explicitly approved moving forward.

Help me turn the initial story into a blog post that sounds like me, but treat it as a working draft. I’ll make the final editorial decisions.

At the end, summarize what we’re building, what we’re not building, the biggest risks, and what success looks like on Saturday.

It’s not magic. It’s just a set of instructions about how I want AI to behave.

The important part is asking one question at a time. That creates an actual conversation rather than a giant questionnaire or a fifty-page requirements document that neither of us will read.

For Load Goblin, this led us through decisions about guest access, personal libraries, sharing programs, metadata, and the cassette-player experience.

The conversation was productive, not because AI had all the answers, but because the questions forced me to make decisions about things I hadn’t fully considered.

Of course, I still managed to expand the scope along the way. Apparently, 20 years of product management experience doesn’t cure that condition.

Why build the boring stuff twice?

Another thing that came out of Sunday’s conversation was realizing how much of last week’s work thwe could reuse.

Wheel of Questions and Load Goblin are completely different products. One spins a wheel to randomly select questions. The other attempts to resurrect software from cassette tapes for a forty-four-year-old computer.

But underneath, they have quite a bit in common.

User accounts, login, password management, administration, database connections, and some of the basic website infrastructure. None of those things make Load Goblin particularly interesting, but they still need to work.

And thwe just spent a week building and improving many of them.

Rather than asking AI to reinvent all that stuff, thwe decided to reuse the pieces of Wheel of Questions that make sense.

This is something I’ve advocated for throughout my product management career. Spend your time and resources on the things that differentiate your product. Reuse, borrow, or buy the things that don’t.

It’s especially important when you’ve given yourself exactly seven days to build something.

The interesting part of Load Goblin isn’t whether I can create another login screen. It’s whether I can get a modern phone to successfully load a program onto a Timex Sinclair 1000 through an audio cable, and eventually give people a way to discover, play, and share those programs.

That’s where I want to spend my time.

Hopefully, the hours invested last week will save us hours this week.

And if this continues, perhaps by Week 52 I’ll have a pretty decent collection of reusable components.

Fifty-two domains? Oh crap.

One other thing I hadn’t fully considered when committing to 52 projects in 52 weeks was the cost of giving each project its own little home on the internet.

Wheel of Questions already had a domain. Load Goblin did not.

So naturally, I bought loadgoblin.com.

It’s a great name. I’m happy with it.

But at one new domain every week, this little experiment could turn into an expensive collection of DNS records.

I’m starting to think some future projects may need to live on subdomains of something I already own. Not every idea needs its own piece of internet real estate, especially when I have absolutely no idea whether it’ll survive until Saturday.

Perhaps domain registration needs to become another question in my new process.

Does this ridiculous idea really deserve its own domain?

I suspect I’ll be terrible at answering that one.

And now for the part where nothing works.

With the storytelling, scope, and reuse strategy reasonably sorted out, it was time to actually make something.

Thwe already had a rough plan for Load Goblin, and work had begun on generating the software. In theory, the process seemed straightforward enough. Take some BASIC code, turn it into a program file, encode it as audio, and play that audio through the Timex Sinclair 1000’s cassette input.

Thit seemed pretty confident about this.

I was considerably less optimistic.

Before going much further, I wanted to prove that the computer could load anything.

I’d already powered up the TS1000 and confirmed it could accept BASIC commands. But that didn’t tell me whether its cassette-loading circuitry actually worked.

Thwe searched for a known-good WAV file online to establish a baseline, but finding one I could actually download and use proved surprisingly difficult.

So thwe built a little test application to play audio files and started with the programs thwe had generated, including Hello World.

I connected the TS1000 to my TV, plugged in the 16K RAM expansion pack, hooked everything up, typed LOAD "", pressed Enter, hit Play, and wished for the best.

Nothing.

The squiggly lines on the screen stayed squiggly. No indication that anything interesting was happening.

Maybe the volume was wrong.

Adjust. Play.

Nothing.

Try again.

Nothing.

At this point, I started wondering whether the damn computer worked at all.

Enter the janky thrift-store Walkman.

Time for a control test.

I’d picked up an old portable cassette player, along with some tapes, hoping I could use the original technology to verify the machine.

I replaced the batteries, opened the cassette compartment, and discovered a tape containing some strange recording of an alternative-news program.

No idea. Put that aside for another rabbit hole.

Out came the mystery news tape. In went a game called Cube, which I was hoping might be some sort of Rubik’s Cube clone.

At this point, I didn’t particularly care what Cube did. I just wanted to see something happen.

Typed LOAD "".

Pressed Play.

Nothing.

Flipped the tape. Adjusted the volume.

Nothing.

Swapped the audio cable.

Nothing.

Switched back to the phone.

Nothing.

Back to the Walkman.

Nothing.

I was running out of combinations, patience, and comfortable positions on the floor.

My knees were not enjoying this trip down memory lane.

Wait. What the hell is EAR?

Eventually, I pulled out the original manual that came with the computer.

Yes, the manual.

That thing I generally avoid reading until I’ve exhausted every other possibility.

And there it was.

The TS1000 has two audio jacks: MIC and EAR.

I’d been plugging the cable into MIC because, well, I was sending audio into the computer.

Apparently, in the world of 1982 cassette computing, EAR is the input and MIC is the output used to record programs.

That makes perfect sense once you understand that the labels refer to the cassette recorder’s connections.

It made absolutely no sense to me while sitting on the floor wondering why nothing worked.

Aha!

I’d found the problem!

Hopes restored. Optimism returning.

Plugged the cable into EAR.

Started with the phone.

Nothing.

Adjusted the volume.

Nothing.

Fuck.

Switched to the Walkman.

Nothing.

Adjusted the volume.

Nothing.

Fuck. Fuck.

Mono? WTF?

Now I’m on my phone, searching for every possible reason a Timex Sinclair 1000 might refuse to load a cassette.

Volume levels. Audio settings. Cable types. Signal quality.

I have an enormous box of random cables that I’ve been accumulating for years. I almost never use any of them, but I keep them because someday I might need one.

Apparently, someday had arrived.

I dug through the collection and found a handful of audio cables left over from when my son was trying to connect some unusual microphone and iPhone setup to his gaming rig.

Surely one of these would work.

Back to the phone.

Nothing.

Volume.

Nothing.

Different cable.

Nothing.

At this point, I was starting to question not just my wiring skills, but my entire choice of project.

Wait.

What did that say about a mono cable?

Seriously? I don’t have one of those!

After more research, I ordered a shielded mono audio cable for delivery Monday.

Order placed.

Hopes slim.

Bruce, we’ve been here before.

Somewhere in the middle of all this, I couldn’t help thinking about my friend Bruce.

Forty years ago, thit didn’t exist to help us troubleshoot anything. Bruce and I struggled to load programs onto a Timex Sinclair using cassette tapes, trial and error, and whatever patience two kids could muster.

Here I was, forty years later, doing essentially the same thing.

Except this time I had AI helping me.

Thit was perfectly happy to figure out how to generate BASIC programs, encode them into .p files, and convert those into audio.

And I was sitting on the floor, with increasingly unhappy knees, trying to get a computer to do absolutely anything.

Maybe vibe coding software to make vibe coding on a TS1000 possible wasn’t such a brilliant idea after all.

I started this experiment because I wanted to see what I could build in a week with AI.

Now I was wondering whether I’d managed to pick a pipe dream for Week 2.

All I wanted was to see that mysterious Cube game run. I didn’t even know what it did.

Surely that wasn’t asking too much.

Sunday night.

By the end of the day, thwe had accomplished quite a bit.

A repeatable process for starting projects. A clearer product scope. A plan to reuse the infrastructure from Wheel of Questions. The beginnings of a website. And another domain name to add to the collection.

But the one thing that mattered most still hadn’t worked.

Not Hello World.

Not our test program.

Not even Cube. Whatever that is?!

Nothing.

I hadn’t proven the computer could load anything, from anyone, using any method.

I was only two weeks into this fifty-two-week experiment, and I’d already managed to choose a project that might be impossible to demonstrate.

Maybe the cable would fix everything.

Maybe the TS1000 was broken.

Maybe I’d made a mistake.

I go to bed unsettled, nervous, and hoping that one last Hail Mary would work.

That package couldn’t come soon enough.

Wk 2 – Update 2

Black Squigglies

My ambitions for the day were modest.

I wanted to get anything to work.

I had a thrift-store cassette player of questionable reliability, a 45-year-old Timex Sinclair 1000 of equally questionable reliability, and a brand-new mono audio cable that I hoped would somehow bring them together.

The cable had arrived, so I was cautiously optimistic.

First, I wanted to prove the cassette player worked and that the Timex could still load a program from an audio signal.

That was a pretty big assumption, considering I hadn’t gotten anything to work yet.

If, and that was an enormous IF, I could get the phone talking to the Timex, I had a plan. Thwe already had a little test application with the basic cassette-player interface. I could build on that foundation, add the features needed for a functioning website, and maybe even spend some time thinking about the user experience.

But first, I needed the damn computer to do something.

Bauhaus on the television

There I was, sitting on the floor of my me cave, surrounded by cables, a thrifted cassette player, and a ancient computer that I was increasingly convinced existed solely to torment me.

I connected my janky Jensen to the Timex Sinclair 1000, typed LOAD "", hit Enter, and pressed Play.

Squiggly lines appeared on the television. After a split second, these were different! Much darker, bolder squiggly lines. Like a Bauhaus album cover.

That seemed promising.

The tape reached the end and stopped with a loud thud as the play button popped back up.

The squiggly lines disappeared. The screen went completely white.

Nothing.

Was it loading? Had it crashed? Was I supposed to do something?

That moment felt like forever.

Then, like magic, the screen started slowly painting a picture.

IT WORKED!

Whatever this program was, it had loaded from a cassette tape onto a computer designed when Ronald Reagan was president.

And now I could finally experience what had presumably been a cutting-edge piece of entertainment in 1982.

It was awful.

I have absolutely no idea what that game was about. Ten minutes of pressing keys and feeling like I was failing an IQ test. Perhaps there was some brilliant gameplay lurking beneath the surface, but I wasn’t going to find it, and I clearly wasn’t going to read the manual. Is there even a manual?!

Enough of that. Unplug the power. Plug back in. Hard reset.

Okay. Now for the real test.

Apparently my iPhone is the janky one

I disconnected the mono cable from the cassette player and plugged it into the USB-C audio adapter on my iPhone.

Opened our bare-bones Load Goblin test page. Selected “Hello World.”

Back to the Timex. LOAD "". Enter.

Press Play on the phone.

Pray.

Squiggly lines! But these were the first kind. Less gothic rock, more garden-variety squiggly.

And then… nothing.

Wait. What’s happening on my phone?

An earphone symbol kept appearing. The volume was going up and down on its own. Playback kept stopping.

What the hell?

I had a janky Jensen cassette player that worked perfectly, and now my iPhone 16 Max was the janky piece of equipment?

I’m going to puke. IYKYK.

Reload. Retry.

Same flashing headphone nonsense.

Off to the internet on my janky iPhone in the basement. Legit Google searches, screw Gemini. I tried every possible combination of search terms involving mono cables, USB-C dongles, headphones, and iPhones.

Eventually, a clue. Like on page 3.

Apparently, plugging a mono cable directly into certain USB-C audio adapters can cause problems with how the adapter detects headphones and microphones, or thinks there is a short and goes into fault protection mode.

Wait. What?

How on earth aren’t audio jack’s backward-compatible technology. It’s a headphone jack! How complicated could this possibly be?

The proposed solution was to put a stereo extension cable between the mono cable and the dongle.

The mono cable connects to the stereo extension, the stereo extension connects to the USB-C dongle, the dongle connects to the knee bone…

Something like that.

Surely this was ridiculous.

But I had the cable from my son’s brief tenur as an streaming gamer.

Back to the browser. Queue up Hello World. Back to the Timex. LOAD "". Enter.

Press Play.

Pray much harder this time.

BLACK SQUIGGLY LINES!

A second or two later, there it was.

Hello World

Two words. White screen. Black letters.

O. M. G.

It worked.

I had just sent a computer program from a website on my iPhone, through a bizarre collection of audio cables, into a Timex Sinclair 1000.

And the machine understood it.

Of course, I immediately wanted more.

The worst game I’ve ever played

Unplug the computer. Plug it back in.

Select Super Breakout, the little game thwe had vibe-coded while building the test application.

Press Play.

Black squigglies. And behold!

Our title screen.

PRESS ANY KEY TO START – it beckoned me.

Instructions appeared. I contorted myself into the appropriate position to operate the Timex’s famously terrible membrane keyboard. Pressed 0 to launch the ball.

Nothing.

Absolutely nothing.

Well, crap.

Now what?

I took a picture of the television, uploaded it to ChatGPT, and asked what was wrong.

Apparently that C/7090 on the bottom left of the screen is the line number that had an error.

Thit found an issue with the keyboard-handling code. Apparently, even artificial intelligence can get confused by the peculiarities of a great grandpa of a computer.

Thwe fixed it. Generated another version. Loaded it again.

This time the ball moved!

And then it went straight through the paddle. Lives = 2.

Fantastic.

Another diagnosis. Another problem.

This time fix the trails the paddle was leaving when I (slowly) moved left.. Another audio file. Another round of black squigglies.

But something interesting was happening. I wasn’t just trying to get a program to load anymore. I was actually playtesting a game that I had created.

Move the paddle. Watch the ball. Find a bug. Take a picture. Tell ChatGPT what happened. Generate a fix. Reload. Repeat.

We were discovering problems with paddle collisions, disappearing graphics, bricks that didn’t behave, and new features I added that needed testing.

About 30 minutes of playtesting and iteration, and an AI that could inspect photographs of my 300lb 36″ Sony Trinitron television.

My assessment of the game was not particularly generous.

This may be the worst game I have ever played.

The only fun was seeing whether I could use sheer willpower to complete a level so I could test the new levels feature.

Then I discovered my favorite bug.

Occasionally, the ball would get wedged between the tops of the remaining bricks and the ceiling, ricocheting around and clearing bricks without my having to do much of anything.

Excellent!

This saves so much time!

Wait, that is a feature, not a bug. I love Breakout on the Atari 2600.

I cleared the level!

…now, can I get to Level 3?!

Crap, maybe it is fun.

Somewhere along the way, I’d stopped thinking about whether the technology worked and started caring about whether I could beat my own terrible game.

Game over.

What? I didn’t even add a high-score feature!

Apparently, I was now losing track of the features in a game I had implemented.

And I was buzzing.

I had vibe-coded a very slow moving, crappy Breakout clone for a Timex Sinclair 1000. I had vibe-coded a website that turned that program into audio the computer could understand. I had delivered it from an iPhone into real, physical hardware.

And it was running.

Not perfectly. Not even close.

But the entire chain worked.

From an idea, to code, to a website, to an iPhone, through a Franken-cable, into a computer manufactured in 1981.

YES!!!

Welcome to the modern internet

With the hardware working and Super Breakout mostly cooperating, it was time to turn our test application into an actual website.

How hard could that be?

Domain names. DNS records. SFTP credentials. MySQL database. Database usernames and passwords. Server configuration. Adding my IP address to an allowlist.

Good grief.

So many tiny, precise tasks. Each one has to be done correctly, and if any one of them is wrong, nothing works.

The computer doesn’t tell you that you’ve almost succeeded. It just refuses to cooperate.

Here I was, using artificial intelligence to create software for computer with 16k memory, debugging it by photographing my television, and making remarkable progress.

Yet getting a modern website deployed required me to painstakingly navigate an obstacle course of configuration screens and credentials.

Perhaps there’s a future LinkedIn post about this.

Dear DreamHost Product Manager,

Who designed this scavenger hunt, and what did I do to make them so angry?

Wait. This isn’t a single-player game.

Something else happened after I got Super Breakout running.

I wanted to show somebody.

Not because it was a particularly good game. It wasn’t. I had just created something that ran on Timex Sinclair 1000, and I was ridiculously proud of it.

Then it occurred to me.

There must be other people out there with these computers. People who still remember writing programs in BASIC, who spent hours squeezing something clever into a few kilobytes of memory.

People who might get the same ridiculous satisfaction from making something work.

And maybe some of them would want to create something new, too.

Why should Load Goblin just be a place where people download my programs?

What if anyone could publish their own?

Someone might make a better Breakout. Someone else might create a clever puzzle game. There could be ten versions of Snake, each an opportunity to show off some elegant programming hack that made it better.

People could share their creations, play each other’s games, offer feedback, and celebrate the particularly clever ones.

I realized I’d been thinking about this all wrong.

Load Goblin wasn’t supposed to be a single-player experience.

This was a multiplayer game. A community of people who love making things.

The cassette player was just how we got in the door.

Unfinished business

I finally went to bed around 1:30 in the morning.

I was buzzing. I could hardly sleep.

In two days, I had accomplished what I’d set out to do. I’d proven the Timex Sinclair 1000 worked, loaded software directly from my iPhone, created a game for it, and built a website that could deliver that game to the computer.

Was the project finished?

Well, the website still sucked. The user experience made almost no sense. I was already assembling a punch list of things to fix tomorrow night when I got back from the gym.

But that didn’t matter. Not tonight.

Something much more important had happened.

Back in tiny Farwell, Michigan, Bruce and I had imagined what we might create with these little computers. But learning the programming language, understanding the operating system, and figuring out how to make something actually work was an enormous undertaking.

I could have spent months learning all of that from scratch today. Maybe longer. And realistically, I probably wouldn’t have.

This Timex Sinclair 1000, all the tapes (including whatever Cube is) would just be sitting in a pile with the rest of my unfinished projects in my basement.

Instead, thwe compressed that entire learning curve into a couple of days. Really hours.

I could focus on what I wanted to make, experiment, test it on real hardware, and keep improving it.

And somehow, thwe made a game that was almost worth playing. Almost.

Forty-five years later, I finally got to check that box.

Look at us now, Bruce!

Now what?

Here’s the problem with accomplishing something you weren’t entirely convinced was possible.

Suddenly, you start expecting a whole lot… more.

I have the rest of the week. Sherry is visiting family, so I have some extra time to work on this. Family first, of course, but an unusually quiet house is a dangerous thing to give someone with a new project and a punch list.

Tomorrow night, I’m going to tackle the user experience.

Make the site flow the way I want it to. Make it look the way I imagined. Turn this collection of working parts into something that makes sense to someone who wasn’t sitting on my man-cave floor watching Bauhaus album covers squiggle on a television.

Then?

I have no idea.

Two days ago, I was hoping an overnighted mono cable would work.

Now I’m imagining a community of people creating and sharing software for computers that haven’t been manufactured in decades.

And I still have the rest of the week.

What could possibly go wrong?

Wk 2 – Update 3

The Tape Recorder Gets Its Revenge

When I first deployed Load Goblin and saw everything working end to end, it felt a little like opening a present under the Christmas tree.

Which is funny, because it reminded me of the Christmas I got my Commodore 64. I was thrilled, although mildly disappointed that I got the cassette tape recorder instead of the floppy drive I really wanted.

Forty-some years later, here I am, building a website dedicated to making that same miserable tape-loading experience possible again.

I suppose the tape recorder finally got its revenge.

The original Load Goblin vision was code-complete in just a couple of days. A player that could send software to my physical Timex Sinclair 1000, along with personal and public libraries of programs.

Thwe had built what I asked for. And it worked.

But you don’t really know what you’ve built until you can see it running.

A little less Goblin, please

The first thing I noticed was that the AI had taken the request for personality quite seriously. Everything was on brand. Some of it was excessively on brand.

Too much flair, unnecessary details, cluttered workflows. I started questioning everything. Why is that there? Do I really need two ways to do this? What happens when I mash this button?

This was the kind of QA I don’t particularly enjoy, but it’s part of the job. Not testing whether Brick Goblin plays correctly, which was yesterday’s adventure. Testing whether the website actually makes sense to somebody trying to use it.

One particularly frustrating exercise involved the cassette player’s branding. I knew what I wanted it to look like, but I couldn’t find the words to explain it to the AI. Thwe went around a few times, getting closer but never quite there.

Finally, I pulled out a picture of an actual Timex Sinclair 1000.

Like this.

That established the visual baseline. Words could take us the rest of the way.

Sometimes a picture really is worth a thousand prompts.

Thwe tightened the workflows, refined the jobs to be done, added screenshots to the program library, and worked through some of the stuff nobody gets excited about. Rights, permissions, publishing rules, and other vaguely lawyerly things that suddenly become important when you let people share software.

I tested on desktop, but spent considerably more time on my phone.

That’s where I imagine the actual customer. Sitting on the basement floor, in front of a beloved childhood computer, with an iPhone connected to the EAR jack through a ridiculous collection of cables.

The experience needed to work there, not just on my big monitor.

Eventually, thwe reached that wonderful point where I couldn’t find anything else that needed fixing in the core player and libraries.

Done.

Well, done with what I originally set out to build.

Pack the briefcase

There were also some things missing from that first deployment. Not because the AI had done a bad job, but because I hadn’t asked for them.

One was customer feedback.

At Amazon, I helped iterate on something called “How’s My Driving,” an approach to collecting feedback in context, when the customer actually has something to say.

I’ve carried that idea with me ever since. If somebody is having a problem, or has a suggestion, I want to give them an easy way to tell me.

Why had I forgotten to include it?

More importantly, why should I have to remember to ask for it every week?

That led to expanding our metaphorical briefcase, the collection of features and practices thwe would take from one project to the next. Feedback, analytics, authentication, and other capabilities that should be part of the starting point rather than things to retrofit afterward.

Fifty-two projects means fifty-one opportunities to benefit from what I learned the week before.

The briefcase isn’t just reusable code. It’s accumulated experience.

Another addition was a coming-soon feature.

I’m not a developer by trade. The languages I learned in college before dropping out were BASIC, Assembler, and Pascal. Later, at Channel Intelligence, I taught myself Classic ASP and Microsoft SQL Server, even building an online stationery site, SelectStationers.com, from scratch, so I could better understand the technology the company was using.

My development process has always been a little unconventional.

There’s an old meme:

“I don’t always QA my code, but when I do, I do it in production.”

Yeah, that’s me.

With little or no installed base, I don’t see much value in spending my limited time building a separate staging environment for these weekly experiments.

But I realized something. I’m blogging about these projects as I build them. Anybody sufficiently curious could visit the site before Saturday’s big reveal and see what’s under construction.

So thwe added a coming-soon layer, with toggles in the admin interface to hide unfinished functionality until I decide to reveal it.

I’m not suggesting that developing in production is a best practice. I’m suggesting that it’s my practice, and I might as well put a few guardrails around it.

There’s a whole separate story in that one.

Is anybody out there?

While I can’t imagine that many people are reading my blog, I figured I should at least have a way to find out.

And if I care whether anyone is visiting the blog, I should care whether anyone is using these projects.

Visits are a vanity metric I’ve loved to hate throughout my career.

Naturally, they were the first thing I wanted to measure.

But visits aren’t the same as value.

What does success look like for Load Goblin? Someone hitting Play? Listening all the way to the end? Loading a program successfully onto real hardware? Uploading something they created?

Those are very different things.

Thwe started thinking about analytics as more than counting visitors. I want the data to be a canary in the coal mine when something isn’t working, and eventually a way to guide decisions about what to improve or build next.

That definition of a high-value action will be different for every one of the 52 projects.

Another thing for the briefcase.

And then there was the $2 problem. Thinking about what makes something worth $2 a month, versus $20 or $100 (I’m looking at you ChatGPT Pro), sent me down another interesting rabbit hole. That deserves its own blog post, so I’ll leave it there for now.

Which rabbit hole next?

Once the original vision was working, the possibilities multiplied.

Could thwe build a way to record programs from the physical TS1000 back onto an iPhone? Could thwe add an emulator so people without the hardware could play the games? A programming workbench? A converter? High scores that somehow travel between real and virtual computers?

Brainstorming was the easy part.

Deciding what to build was considerably harder.

Thwe explored some of these ideas in separate conversations, deliberately keeping them away from the actual project’s scope. Interesting possibilities aren’t commitments, and a fascinating rabbit hole isn’t necessarily somewhere you should spend the rest of the week.

I learned at Amazon to start with the customer and work backwards.

In this case, I actually am a customer. I’m not just dogfooding Load Goblin. I’m using it for the reason I built it.

But I’m only one customer.

Without doing real customer development, choosing among all those possibilities is something of a fool’s errand.

One technique Amazon used extensively was tenets. We would establish a set of principles, often after considerable debate, and then use them as lenses through which to evaluate decisions.

So thwe wrote five for Load Goblin.

And they changed my thinking more than I expected.

Before writing them, I was particularly excited about recording programs from the TS1000 back onto my phone. Completing that loop would be technically fascinating.

I still want to explore it.

But once thwe established that authentic hardware owners, measurable usefulness, and a community of creators were what mattered most, the priorities shifted.

What I really wanted wasn’t just to move programs back and forth. I wanted to share this experience with other people who appreciated it.

Maybe ten people will write their own versions of Snake. Maybe the eleventh is so clever and elegant that everybody wants to see how it was done.

That’s the kind of community I’d love to help create. As they push the boundaries of what this ancient tech can do.

The technology can serve that ambition, rather than the other way around.

Music to my ears

I talked about Load Goblin over lunch with some coworkers.

There’s no better way to explain this stuff than to show it, so I whipped out my phone, logged in, selected a program, and hit Play.

Out came the familiar squeaking and screeching sounds of a computer program being loaded from tape.

Music to my ears.

To the younger people at the table, mostly just noise.

These are technically sophisticated people, but the idea that a cassette tape could be a storage and retrieval mechanism for software was completely foreign. Most know what a floppy disk is, even if they’ve never used one. An audio cassette full of computer programs is another matter entirely.

Two coworkers suggested Reddit as a way to find the niche communities that might actually appreciate these projects.

Which is an interesting blind spot for someone who has spent a career around advertising and marketing.

I’ve read Reddit plenty, but I don’t remember contributing much, if at all. Maybe it’s time to change that.

And maybe that’s where some real customer development begins.

Tomorrow’s problem

I’ve touched the stove enough times over the years to know what happens when scope starts creeping halfway through a project.

You don’t ship.

That is particularly dangerous when you’ve publicly committed to building and shipping something every Saturday for 52 weeks.

The original Load Goblin vision is complete. Thwe have refined it, tested it, added the necessary infrastructure, and shipped several more iterations.

Thwe have also discovered a lot more things that might be worth building.

Something else changed this week, too. Thwe started doing these daily retrospective interviews, walking back through what happened, what surprised me, and what I was thinking at the time. It turns out reliving the experience and trying to tell the story is almost as enjoyable as doing the work in the first place.

So, where do thwe go tomorrow?

Should thwe shoot for the moon and attempt to build a Timex Sinclair emulator from scratch, so the people who heard nothing but noise at lunch could actually play Brick Goblin?

Or spend that time adding something useful for the people who have a real TS1000 sitting on their basement floor?

I haven’t decided.

That’s a problem for tomorrow.


P.S. The Load Goblin Tenets

For anyone curious about the principles thwe established to help guide decisions, here are the five:

  1. The hardware enthusiast comes first. Prioritize authentic Timex Sinclair 1000 owners and features that deliver measurable, useful outcomes. Support both physical and virtual experiences, but don’t sacrifice the primary customer’s needs to attract casual visitors.
  2. Build a community of creators, not merely a catalog of programs. Celebrate ingenuity, elegance, and quality. Encourage ratings, reviews, contributions, and constructive peer moderation, with credibility earned through participation.
  3. Everything should have personality. Load Goblin should be fun, distinctive, and unmistakably itself. Even something as mundane as saving a high score might become an opportunity to connect the physical and virtual worlds in a memorable way.
  4. Respect the original machine. Preserve the authenticity, limitations, and peculiarities of the hardware. Those constraints are part of what makes creating something remarkable on a TS1000 so satisfying.
  5. Let creations travel, and make ongoing value worth paying for. Where practical, programs and achievements should move between physical and virtual systems. Any paid features should deliver meaningful, repeatable value rather than simply putting existing capabilities behind a paywall.

The tenets aren’t a roadmap. They’re a way to decide which road is worth taking.

Wk 2 – Update 4

One More Way to Fail

Last night I ended my blog wondering what to do next.

Should thwe build an emulator for the Timex Sinclair 1000? Figure out how to record programs back from the computer to an iPhone? Or focus on improving the experience for the handful of people who actually own one of these ancient machines?

Before bed, I recorded an audio note to myself.

I kept coming back to the same question. Would this thing actually be useful to anyone?

I’d built a website that could deliver programs to a real Timex Sinclair 1000. I’d even built and played a game on it. But was there enough value here to justify inviting other people to create and share their own programs?

How would I know?

Maybe I should build and publish a few more programs myself.

Dogfooding, but something I was going to do anyway!

Experience what an actual contributor would experience. Not just test whether buttons worked, but whether the whole thing was worth doing.

That seemed like a pretty reasonable next step.

Fifteen little problems

It’s called Load Goblin. I should probably have a game with a goblin in it. Duh.

What about the classic sliding tile puzzle, the game of fifteen?

Fifteen numbered tiles in a four-by-four grid, with one empty space. Slide the tiles around until they’re all back in order.

Except instead of numbers, what if the tiles were pieces of our grumpy goblin’s face? Solve the puzzle, reveal the goblin.

Simple enough.

Well, no.

The first challenge was getting ChatGPT to stop showing me attractive pictures of a game that couldn’t possibly run on the Timex Sinclair 1000.

Thwe were designing for a computer with a 32-by-24-character display and a whopping 16K of expanded RAM. The AI kept producing beautiful mockups with graphics, proportions, and effects that weren’t realistic for the machine.

They looked great!

They were also useless.

The issue was ChatGPT would switch from Work mode to image creation mode when I talked about making a graphic. I had to work to reframe this through the context of the code itself.

Ani image conceptually drawn on graph paper, then migrated to code, then I finally felt comfortable that the game could actually be rendered using Sinclair block graphics.

Then I complicated matters.

What if thwe also had the traditional numbered version? And what if completing that version gradually revealed the goblin picture underneath?

Difficulty settings? Sure.

Some snarky messages from our goblin when you completed the puzzle? Obviously.

Eventually, thwe had several versions, a design that respected the machine’s limitations, and something that looked like a pretty decent little game.

Now to find out if it actually worked.

This is going to be great!

I was positively giddy.

Still riding the high from getting Brick Goblin working the previous night, I fully expected GOBLIN 15 to load on the first try.

I wasn’t worried about loading the program anymore. I’d solved that problem!

I was looking forward to playtesting the game and finding bugs.

I connected everything, hit Play, and watched my television fill with what looked like the cover of a never-released Bauhaus album.

Black squiggly lines everywhere.

Beautiful.

The audio finished, the screen cleared, and there it was.

[K]

Oh shit.

[K]

That terrifying little K prompt. The last thing I wanted to see.

Well, at least it was easy enough to type LOAD "" and try again.

Nope.

Maybe something was wrong with the new game. Let me try one of the programs that worked yesterday.

Nope.

Hello World? Surely Hello World!

Nope.

I had a working system last night. What the hell happened?

Then I remembered something.

Apple had been warning me about excessive headphone volume. Apparently, my iPhone thought I was trying to damage my hearing.

Turn down your volume!
Headphone Safety > USB Audio Accessories

I wasn’t wearing headphones. I was trying to load software into a Timex Sinclair 1000.

Apparently Apple was trying to protect my computer’s EAR port from damage.

That gave thwe something to investigate.

Some things never change

Thwe started comparing versions of the website’s cassette player, looking for something that might have changed the audio playback.

One possibility was our spectrum analyzer.

Those bouncing bars that dance along with the music.

I loved those things when I was a kid. My friend Robb had a sweet Kenwood stereo component system, complete with a graphic equalizer. I remember watching those bars dance while hearing Pearl Jam’s debut album for the first time.

Fascinating.

I’d added something similar to Load Goblin. But thwe wondered whether reading the audio file to generate the visualization might somehow interfere with playback.

Not proven, but easy enough to eliminate.

Thwe turned it off by default. That also cleaned up the retro design a bit.

Meanwhile, I was digging around in my iPhone settings.

I found something called USB Audio Accessories. I wasn’t entirely sure what those settings did, but while ChatGPT was explaining them, I was already deleting things.

I suspect someday I’ll discover what I’d disabled when something else that used to work suddenly doesn’t.

Back to the basement.

Back to Bruce’s house, figuratively speaking, trying to find exactly the right volume setting to get a program to load.

Black squiggles.

White screen.

Nothing.

I waited.

And waited.

Well, at least this was a new way to fail.

I pulled the power cable to reset the computer.

Somewhere in all this, I found the original instruction sheet for The Cube Game, one of the cassette games that came with my Sinclair.

The Cube Game
The Cube Game Instructions Continued

The instructions were every bit as confusing as the game itself.

X, Y, and Z axes. Three-dimensional cube rotations. Row movements. Counter-clockwise this, clockwise that.

I’d spent ten minutes trying to figure out what the hell I was doing in that game earlier in the week. Reading the instructions didn’t help much.

But there was some useful information about loading programs.

Right there on the first page:

LOAD TIME: 5 Min. 37 Sec.

And elsewhere, a warning that a 16K program could take ten minutes or longer to load.

Good to know.

Information that I would soon completely ignore.

A Crazy Ivan

I’d been going in circles trying to figure out why GOBLIN 15 wouldn’t load.

Was it the new code? The size of the file? Something in the cassette player? The iPhone? The machine itself?

Time to change direction.

Thwe were going to make an entirely new, tiny program. Something so simple that if it failed, I could stop blaming the complexity of GOBLIN 15.

And I knew just the program.

When I was a kid, I discovered that the Commodore 64 on display at the Kmart in Mount Pleasant, Michigan, could be programmed.

So I wrote a little BASIC program that printed “KMART SUCKS!” over and over again.

An early contribution to in-store retail media.Who knew where I’d end up…

Thwe recreated that masterpiece for the Sinclair.

The Timex didn’t even have an exclamation point, so the sentiment needed a little editorial compromise.

I loaded the WAV file onto my phone, connected everything, and pressed Play.

It worked!

KMART SUCKS: KMART SUCKS: KMART SUCKS:

Now we’re getting somewhere.

I went back and tried Brick Goblin.

That worked too!

I even got some playtesting in and found another bug. Apparently the ball could eat its way through the walls. Must be a bug introduced when we fixed the paddle movement trails.

Never enough playtesting.

Which reminds me, my younger brother Karl used to be a playtester for Sega Genesis games. They’d mail him prototype cartridges that he wasn’t allowed to play around his friends. He’d play the games and send them back with his thoughts.

I think Donald Duck QuackShot was one of them. Fantastic game.

Apparently, playtesting runs in the family.

But at least I knew the hardware could still load and run programs.

That narrowed things down considerably.

Or so I thought.

The incredible shrinking goblin

Maybe GOBLIN 15 was just too big.

Thwe had been adding features, graphics, and different ways to play. The program had gotten considerably larger than those tiny test programs.

What if thwe stripped it back to just the goblin picture puzzle?

Smaller program. Shorter WAV file. Faster loading.

Thwe made a new version.

It loaded!

And then crashed.

2/470

Excellent.

At least this was progress. Thwe had a specific error to investigate.

Thwe found a missing array declaration and prepared a correction, but I hadn’t tested that version yet.

I had also started gathering the WAV files from all our different builds so I could load them directly from my phone, rather than repeatedly uploading programs through the website.

Speaking of the website, I’d discovered that the program-upload workflow sucked.

So thwe changed it to a wizard-style experience, which I liked considerably better. I also wanted to extend the flow to include screenshots.

Thwe had added ZIP support as well, but I quickly realized that accepting arbitrary ZIP files was opening a security can of worms I didn’t want to deal with this week.

Out that went.

Meanwhile, I still hadn’t played GOBLIN 15.

I went back downstairs, determined to make this work.

Back to being twelve

By now my butt and legs were going numb.

I’m 54 years old, sitting on the floor in front of a Timex Sinclair 1000, just like I would have been doing when I was twelve.

There’s a perfectly good chair nearby.

And a beautiful oak coffee table that Tom, the guy I call Dad, made years ago.

Unfortunately, the table was still covered with the aftermath of a solo Four Against Darkness dungeon crawl I’d recently been playing.

Maybe I should clean that off and sit in a chair like an adult.

But there was something special about sitting right there on the floor, forty-some years later, doing essentially the same thing I did as a kid.

There was one big difference.

At the beginning of the night, I’d been so excited to press Play.

Now I was dreading it.

I decided to try one of the earlier, larger versions of GOBLIN 15 again, using the WAV file downloaded directly to my phone.

Play.

Black squiggles.

White screen.

Nothing.

Again.

I’d had enough. My bones had definitely had enough.

I got up and sat in the chair that had been beckoning me all night.

Maybe the problem was the way I was playing the WAV file directly from my phone. That was a shortcut I hadn’t really tested before. Maybe going through the Load Goblin website would work differently.

I started opening the site and filling out the forms for another test.

Then I looked up from my phone.

IT FUCKING LOADED!

It worked

Wait.

What?

There was GOBLIN 15, running on my actual Timex Sinclair 1000!

And not the small version.

This was the big one, the earlier version that included both the classic numbered puzzle and the goblin picture puzzle.

The same one I thought had failed.

Oh.

I’d pulled the power too soon.

Apparently, the computer had been doing something useful during that endless white screen after all.

I had just been too impatient to let it finish.

Remember those instructions that mentioned ten-minute loading times?

Yeah.

The universe has peculiar ways of revealing her mysteries.

The magic

I started with the classic numbered puzzle on Easy.

Classic 15 mode

Moved the tiles around. Got everything back in order.

And then something happened that I wasn’t expecting.

The reveal

The game slowly revealed our goblin image, tile by tile, followed by a little appropriately snarky message.

I hadn’t seen that image rendered on the actual computer yet.

It was magical.

I mean that.

I’d spent the last few days watching the Sinclair painstakingly render graphics, trying to understand its limitations, rejecting beautiful mockups that couldn’t possibly work, and figuring out how to squeeze this game into a ridiculously constrained machine.

And there it was.

I felt that familiar physical rush of energy.

Vindication!

It’s something I’ve felt many times in my career, and something I remember feeling as a kid. That jolt of satisfaction when you’ve been wrestling with a difficult problem and finally get it working.

It’s part of what drives developers, mathematicians, inventors, and people who enjoy making things.

You push through all the frustration and suddenly your brain rewards you with a wonderful blast of chemicals.

It’s addictive.

And apparently, after forty-some years, it still works on me.

I pressed R to play again, this time choosing the goblin picture puzzle.

Definitely harder without those numbers!

I solved it too, but I imagine harder setting would be practically impossible.

Then, because apparently I can’t help myself, I found something I wanted to fix.

When moving a tile, the game drew it in the new position before erasing it from the old one.

For a brief moment, there were two copies of the same tile on the screen.

That felt wrong.

Thwe talked about making the tiles actually animate as they slid around. But having watched this computer render graphics over the last few days, I knew that modern flair wasn’t going to work particularly well here.

What if thwe just erased the tile first, then drew it in the new position?

That would feel a little more like sliding without trying to force the computer to do something it wasn’t particularly good at.

Thwe made the change.

Another thing to test tomorrow.

Tomorrow is another day

I made one final cosmetic fix to the website, aligning the tab experience, and got things organized for a fresh round of testing.

I still had several versions of GOBLIN 15 to sort through. The smaller version needed another test. The tile movement change needed verification. And I was starting to think about how Load Goblin should handle different versions of the same program.

All interesting problems.

But I’d had enough for one night.

I started out trying to determine whether Load Goblin would be useful to someone who wanted to build and publish software for an old computer.

I ended up rediscovering something I hadn’t felt quite this way in decades.

I’d made a game. I’d loaded it onto a real Timex Sinclair 1000. I’d played it, completed it, discovered bugs, and asked for improvements.

And somewhere in there, I was twelve years old again.

So I stopped while I was ahead.

Tomorrow is another day.

Saturday is the reveal.

I can’t wait to show you what thwe have built!

Assuming I can resist pulling the plug…