#homebrew computing

[techav]

On Celebrating Errors

Isn't it beautiful? The lovely formatted tables of register and stack contents, the trace of function addresses and parameters, the error message ... it's the most beautiful kernel panic I have ever seen.

Why on earth would I be so excited to see a computer crash? What could possibly be beautiful about a kernel panic?

This kernel panic is well-earned. I fought hard to get it.

This kernel panic came from a current NetBSD kernel, freshly compiled and running on Wrap030, my 68030 homebrew computer. It is the result of hours upon hours of work reading through existing code, scattered documentation and notes, writing and rewriting, and endless compiling.

And it's just the start.

As I've said before, a goal of this project has always been to build something capable of running some kind of Unix-like operating system. Now that I finally have all the necessary pieces of hardware, plus a good bootloader in ROM, it's time to give it a shot. I'm not that great with this type of programming, but I have been getting better. I might just be able to brute force my way through hacking together something functional.

It is hard.

There is some documentation available. The man(9) pages are useful, and NetBSD has a great guide to setting up the build environment for cross-compiling the kernel. There are some published papers on what some people went through to port NetBSD to this system or that. But there's nothing that really explains what all these source code files are, and which parts really need to be modified to run on a different system.

I had a few false starts, but ultimately found an existing 68k architecture, cesfic, which was a bare minimum configuration that could serve well as a foundation for my purposes. I copied the cesfic source directory, changed all instances of the name to wrap030, made sure it still compiled, then set about removing everything that I didn't need. It still compiled, so now it's was time to add in what I did need.

... how ... do I ... ?

This is where things get overwhelming very quickly. There is documentation on the core functions required for a new driver, there's documentation on the autoconf system that attaches drivers to devices in the tree, and there's plenty of drivers already to reference. But where to start?

I started by trying to add the com driver for the 16550 UARTs I'm using. It doesn't compile because I'm missing dependencies. The missing functions are missing because of a breaking change to bus.h at some point; the com driver expects the new format but the cesfic port still uses the old. So I needed to pull in the missing functions from another m68k arch. Which then required more missing functions and headers to be pulled in. Eventually it compiled without error again, but that doesn't mean it will actually run. I still needed to add support for my new programmable timer, customize the startup process, update hardware addresses, make sure it was targeting 68030 instead of 68040 ...

So many parts and pieces that need to be updated. Each one requiring searching for the original function or variable declaration to confirm expected types or implementation, then searching for existing usages to figure out what it needs ... which then requires searching for more functions and variable types.

But I got something that at least appeared to have all the right parts and compiled without error. It was time to throw it on a disk, load it up, and see what happened.

Nothing happened, of course. It crashed immediately.

I have no debugging workflow I can rely on here, and at this stage there isn't even a kernel console yet. All I could do was add little print macros to the locore startup code and see where it failed. Guess, test, and revise.

I spent a week debugging the MMU initialization. If the MMU isn't properly configured, everything comes to an abrupt halt. Ultimately, I replaced the cesfic machine-specific initialization code and pmap bootstrapping code with functions from yet another m68k arch. And spent another day debugging before realizing I had missed a section that had comments suggesting it wasn't for the 68030 CPU, but turned out to be critical for operation of kernel memory allocation.

Until this point, I was able to rely on the low-level exception handling built into my bootloader if my code caused a CPU exception. But with the MMU working, that code was no longer mapped.

So then came another few hours learning how to create a minimal early console driver. An early console is used by the kernel prior to the real console getting initialized. In this case, I'm using the MC6850 on my mainboard for the early console, since that's what my bootloader uses. And finally the kernel was able to speak for itself.

It printed its own panic.

The first thing the kernel does is initialize the console. Which requires that com driver and all the machine-specific code I had to write. The kernel is failing at its step #1.

But at least it can tell me that now. And given all the work necessary to get to this point, that kernel panic data printing to the terminal is absolutely beautiful.

[commodorez]

How would one go about learning how to make something like the cactus?

Like prerequisites, older code, hardware stuff, etc.

The main prerequisites I can think of are being heavily interested in vintage computers, and having the drive to try and fail and then try again.

I started with building Grant Searle's design, borrowing from other working designs as I went. However, for the front panel? That's alot of time designing, learning, simulating in Logisim, and testing with physical logic gates to produce something 100% original and of my own design. I imagine most folks won't want to go to the trouble of designing an entire front panel state machine like I did.

The good news is that there are way more kits that can help teach the necessary skills than ever before! Most notably, Ben Eater's 6502 kit is a really great way to learn many of the things that I've put into practice here. He has a whole youtube video series associated with it, walking through concepts, construction, programming, etc. step by step. Even if you don't build one of his kits, watching them is an informative process. *I* learned alot, even after having built the Cactus.

If you're going the Z80 direction, the RC2014 series of kits can teach you plenty. There's also glitchworks kits in a few processor types, but those tend to be a bit more for the advanced user. There's the 1802 Membership Card but that's small and not really expandable. I could be here all day listing kits that can help teach and build up experience.

I should mention that I have a computer science degree in my back pocket, but learning logic gates or using assembly was only lightly touched on in the course of my studies. Most of the programming I do involved messing around in BASIC anyway.

I really didn't have a game plan for some of it, so alot of my learning process was trial and error. Alot of errors, in fact. Still making them, and learning from them. I also took the harder route to construction, since I didn't know how to use EDA tools for designing PCBs like KiCAD or Altium or Eagle (don't use Fritzing for the love of fuck).

Oh, one other thing I can recommend: reading through contemporary 1970s computing magazines like Byte (check the internet archive for back issues). There are all sorts of cool projects and ideas present that can really guide you. It doesn't hurt to have a copy of Don Lancaster's TTL Cookbook on hand (I think it's in PDF form online).

Finding a community to help you out is also a great idea. Even back in the 1970s, many folks who jump-started the home computer revolution had the Homebrew Computer Club to help them out. Community meetings to bounce ideas off of, and help one another through debugging are essential in my book -- you don't have to work in a vacuum. I've got a few places I've asked for help, most notably the Retrotech Crew discord server. I've had the benefit of friends who also have homebrewed designs like @techav, who have inspired me with their ideas, but helped me out with mine. In turn, as I've learned, I've been able to help out others.

Hopefully that answers your question. Keep 'em coming!

[auberylis]

20250308 Major ALICE update!

For a couple months i've been working on a bunch of new stuff and improvements for Aubery's Logic Integrated Circuit Emulator (ALICE), and yesterday i concluded the works that have been planned! I am very happy to tell everyone that ALICE now crashes much less, the circuit tracing GUI became much more usable, and even more high-level devices were programmed!~

Circuit integration now works in full - watch me go from a basic logic gate based single-bit full adder to a 4-bit adder IC with a whole demo setup to test it, inside the same project!

Some high-level devices were added: everything but the ALU seems to be working correctly. TruthTable allows you to build a circuit and then compose its truth table in realtime! Using the pre-made compounds can be easier on the CPU than user-made ICs, even though i'm working on making everything run even faster. Oh, and now there's a "text" device to leave notes right on top of the circuit!

All devices now show a memo on what they do when selected, and a cohesive (although still and forever lacking) manual was started!

Finally, there are now demo projects! They and the manual are bundled within ALICE itself, so no need to download them separately from anywhere. I will work on adding more to them, with the general goal of one day having a "full basic 8-bit CPU" on the list!

Aside from these novelties, i worked real hard and made the GUI run smoother and explode less. Frankly, the code was pure spaghetti before this overhaul, and now it's at least meatballs with a side of spaghetti. It became better, i promise. Along with this, a bunch of minor bugs were eliminated, and i'm slowly ridding the project from depending on my old bmco.js utility library, which would make it run smoother.

There's a lot of plans for this project, and seeing people using it at all would greatly increase my motivation to implement them. Not like i am not motivated.. but you could make things happen faster! So! Use the thing, tell me when it explodes in your face - with saves and bug error texts preferrably - and show me what you made with it!

And one last thing: ALICE is now hosted on Gitea because i am tired of github's copilot bullshit. I will shut down the github repository soon enough -- nothing to lose, since there are no open issues out there or anything. If you feel like digging through my caverns of nonsense, or run ALICE locally, go ahead and download the source code from the Gitea repo!

[pidgefudge]

idk where i read this but a special interest really is the lens through which you view the world. or at least mine is

[arconinternet]

Aquarius: An Aquatic Experience (DOS, Shane "Cloudee" Cloud, 2007)

You can play it in your browser here. Made in Sierra's SCI engine. Are YOU at least as smart as a goldfish?

[goodugong]

I’m putting an SSD into the first brand new computer I ever had, a 2009 imac. Actually very accessible! The front panel is held on with magnets rather than glue. It doesn’t know what hit it; it boots up so fast the progress bar doesn’t even fill. It runs way cooler because the SSD is so much more energy efficient (and leaves more open space in the case). The experience of using Finder on this 15-year old machine is so snappy and responsive compared to my current workhorse 2020 imac, it’s kinda wild how much more sluggish macOS has gotten in the last 10 years.

MacOS Sierra is so old that the internet certificates it ships with have expired, so I had to jump thru some hoops to get it working, manually adding Mozilla certificates for example. Homebrew refused to download its own ca-certificates cask, so I ended up having to download it on a different machine and transfer the package so Homebrew thought it had already downloaded it and skipped to installing. Very fiddly, but a labour of love. It takes fucking ages to compile anything though.

[converse-luke]

My brother: let’s do a homebrew dnd campaign we dm together!

Me, vibrating: so you’re saying I get to make a map?

[autistickaitovocaloid]

I miss posting pjd screenshots on here. The reason why I haven't for ages isn't because I lost interest it's literally because I started playing the game on original hardware and barring the diva rooms there isn't a super intuitive way to take screenshots.

[techav]

Looking Back

Today, 26 March 2025, is the tenth anniversary of the first time I put power to a Z80 microprocessor in a breadboard and watched it blink some LEDs.

Within a few weeks that Z80 would be completely surrounded by other chips and hundreds of wires to form my first functioning homebrew computer.

Another week and I was already removing a 68000 from a (presumed) dead motherboard, with grand ideas of moving up to the 16-bit era (but absolutely no understanding of what that would entail)

It would be another two years before the first time I put that 68000 in a breadboard and successfully used it to blink an LED.

By the time another year had rolled around that 68000 was living on a soldered breadboard and for the first time on one of my projects, it was running real software — EhBASIC.

Always looking to more challenging projects, while I was building with a 68000, I was already reading through the manual for the 68030 trying to understand how to build with a proper 32-bit microprocessor. Just one more year and I had that 68030 on a wire wrap board, blinking an LED.

The next year I was doing the most ridiculous thing I could think of — free-running a Pentium CPU on a wire wrap breadboard to blink an LED. Because I could.

By the end of the next year that 68030 had moved from its wire wrap board onto a proper printed circuit board — my first ever 4-layer PCB.

The next year saw the towering expansion of the 68030 build, adding new peripherals and functionality.

Another year and I had an all-new 68030 build on a Micro-ATX form-factor motherboard developed in just a couple months ahead of VCF Southwest 2023.

The next year I focused on developing software for my existing 68030 board stack, rather than building something new from scratch. I succeeded in developing a minimal multi-user kernel to run four instances of BASIC simultaneously.

All along in between working on these projects I have done component-level repairs on various computers, developed expansion cards for the Mac SE, built PCs both new and old, burned out hard, developed some smaller homebrew computers, had a lot of false starts, failed projects, and abandoned projects, and completed some massive projects in my day job.

Looking back at everything I've worked on over these past 10 years I am absolutely amazed at how far I have come and what I have been able to accomplish. Much of it I still don't understand how I managed to actually pull it off, and I'm not entirely sure I could duplicate my successes.

Here's to the next ten years

[ms2253]

smolZINE #42 (released 2025-01-26)

gemini://gemini.cyberbot.space/smolzine/smolzine-issue-42.gmi

(cornquest is wonderful & reminds me of sanitarium)

[spielkritik]

Lesenswert: Spielen als Mutter, Screenfun-Heft-CDs, Blaster Master, Game-Boy-Homebrew, Conquests of Camelot & the Longbow

Die 193. und damit letzte Ausgabe von Lesenswert in diesem Jahr erlaubt sich den Luxus, einmal nur deutschsprachige Artikel zu empfehlen. Gleichzeitig verbergen sich unter den nachfolgenden Empfehlungen gleich mehrere Artikelreihen. Los geht es mit einem Artikel von Steph bei VSG, der den Auftakt für eine Reihe bilden soll. Während die Klage (oft männlicher) erwachsener Gamer, zumeist…

[thekittyburger]

Just had to sit and listen to my computing teacher rant about how much he hates RGB lighting, thinking about my RGB 3ds status light add-on

[prokopetz]

With DND 5e being set up to cause DM burnout, can you give examples of tabletop systems that facilitate easy DMing? I love running a tabletop game but don't have the time to deal with 5e or homebrew anymore.

(With reference to this post here.)

This is an area where you're going to get a lot of bad advice, because there's no such thing as a tabletop RPG that's "easy to GM" in the abstract. Some systems make greater or lesser demands of the GM's time and skill, but the reason that Dungeons & Dragons has a massive GM burnout problem is a bit more subtle than that – indeed, D&D's GM burnout problem is considerably worse than that of many games whose procedures of play place much greater demands on the GM!

It boils down to the fact that games are opinionated. Even a very simple set of rules contains a vast number of baked-in assumptions about how the game ought to be played; in the case of tabletop RPGs, those baked-in assumptions include assumptions about what kinds of stories the game ought to be used to tell. The players of any given group, of course, also have assumptions – some explicit, many unexamined – about how the game's story ought to go. It's rare that these two sets of assumptions will perfectly agree.

Fortunately, perfect agreement isn't necessary, because tabletop RPGs aren't computer games, and it's always possible to tweak the outputs of the rules on the fly to better suit the desired narrative experience. In conventional one-GM-many-players games like D&D, this responsibility for monitoring and adjusting the outputs of the rules so that they're compatible with the narrative space the group wishes to explore falls principally on the GM.

Now, here's where the trouble starts: the larger the disconnect between the story the rules want to produce and the narrative space the group wants to explore, the more work the GM in a conventional one-GM-many-players context needs to do in order to close that gap. If the disconnect is large enough, the GM ends up spending practically all of their time babysitting the outputs of the rules, at the expense of literally every other facet of their responsibilities.

(Conversely, if that gap is large and isn't successfully closed, you can end up with a situation where engaging with the rules and engaging with the narrative become mutually exclusive activities. This is where we get daft ideas like "combat" and "roleplaying" being opposites – which is nonsense, of course, but it's persuasive nonsense if you've never experienced a game where the rules agree with you about what kind of story you should be telling.)

And here's where the problem with Dungeons & Dragons in particular arises. The rules of D&D aren't especially more opinionated than those of your average tabletop RPG; however, the game has developed a culture of play that's allergic to actually acknowledging this. There are several legs to this, including:

a text which makes claims about the game's supported modes of play that are far broader than what the rules in fact support;

a body of received wisdom about GMing best practices which consists mostly of advice on how to close the gap between the rules' assumptions and the players' expectations (but refuses to admit that this is what it's doing);

a player culture which has become increasingly hostile to players learning or knowing the rules, and positions any expectation that players should learn the rules as a form of "gatekeeping"; and

a propensity to treat a very high level of GMing skill as an entry-level expectation.

Taken together, all this produces a situation where, when the rules and the group disagree about how the game's story ought to go, the players don't experience it as a problem with the rules: they experience it as a problem with the GM. A lot of GMs even buy into this perception themselves, which is how you end up with GM advice forums overflowing with people telling novice GMs that they're morally bad people for being unprepared to tackle very advanced GMing challenges right from the jump.

(At this point, one may wonder: why on Earth would a game develop this sort of culture of play in the first place? Who benefits? Well, what we're looking at in practice is a culture of play which treats novice and casual GMs as a disposal resource whose purpose is to maximise the number of people playing Dungeons & Dragons. Follow the money!)

So, after all of that, the short answer is that there isn't a specific magic-bullet solution to avoiding D&D's GM burnout problem – or, at least, not one that operates at the level of the rules, because there's no particular thing that D&D as a system is doing "wrong" that produces this outcome; the problem operates almost entirely at the play culture level.

In practice, two things need to happen:

Placing a greater expectation on the players to learn and understand the game's rules; and

Selecting a system where the gap between the story the rules want to produce and the narrative space the group wants to explore is small.

It's that second one that's the real trick. In order to minimise that gap, we need to know what kind of narrative space your group wants to explore, and that might not be something you have a good answer to if you don't have good lines of communication with your players.

(As an aside, there's a good chance that we're going to see dipsticks cropping up in the notes insisting that their favourite system short-circuits this problem by being perfectly universal and having no baked-in narrative assumptions. These people are lying to you, and lending credence to the idea that there's any such thing as a universal RPG is a big part of how we got into this mess in the first place!)

[the-old-man-has-the-phonebox]

I wanna learn how to 🏴‍☠️ but I know for a fact my dumb ass will fuck it up royally and get a fucking Trojan on my computer on the first try

[baked-bread]

seeing graphics benchmarks online by other users because i'm searching online and i genuinely cannot find anyone posting a score under 1000 for the unigine benchmark softwares?? people are here like "yeah i had 1500 this score is terrible" meanwhile i'm out here w

absolutely winning with this cheap prebuilt desktop from at least 6 years ago. #1 in worst graphics known to man