Posts tagged "show your working"
Show Your Working: Making Powerline Ethernet faster
Sun 25 February 2024
Having wired networking is nice! The current iterations of Wi-Fi are admittedly very fast, but I feel a bit iffy trusting that the signal will always work at a good latency, when there's rogue slabs of concrete and surprise microwave sources to deal with.
My house has fiber internet which terminates at the wireless router I keep under my TV. To enable mission-critical house activities (e.g. streaming from my studio to Twitch/Diode Zone, using Steam Link from the couch), I have some Powerline Ethernet adapters which link the router to my studio PC upstairs. And for the past several years, they have been indistinguishable from magic; somehow they turn 1970s home electrical wiring into Cat 5e!
Until the rubber finally met the road; I tried to watch a Blu-Ray on my Home Theatre PC, streamed from my Studio PC, and it had big buffering pauses every 60 seconds. An early speed test I did showed the link speed for streaming the Blu-Ray was only 24 Mbps! But for some reason, downloading things from the studio PC was absolutely fine! At this point I realised I knew very little about how the magic boxes worked, or how I would go about isolating the problem.
Article continues here! KEEP READING, YOU
Show Your Working: Forcing Linux to print at actual size
Fri 19 May 2023
One day I decided I've had enough of computers and wanted to do literally anything else. Specifically, in that moment I wanted to print out some sewing patterns. Here is a 100mm test square I printed on my printer. Except it's only 94mm. 94mm!!!
Not going to lie, searching the internet for useful information has become real bleak lately. There's plenty of advice floating around to "Open the PDF in Acrobat and select "Actual size" when printing", but no advice about the Linux equivalent. To be honest the coward's way out would be to dig out the sacrificial Windows laptop, find a print driver and use Acrobat Reader, but I figured other people might like to know how to fix it, so here you go!
Article continues here! KEEP READING, YOU
Show Your Working: Fixing a pile of bugs in MAME
Sun 03 December 2017
Show Your Working is a brand new segment where I write up things I have attempted to fix in open source software. Sometimes it's interesting to debug a problem yourself from first principles, even if the codebase is huge and you don't know anything going in. I will try and explain my thought process as I venture out into the weeds armed only with a butter knife.
The software
If you haven't heard of it, MAME is an emulation project with the aim of supporting basically every arcade machine ever made. To do this, thousands of circuit boards and custom chips have been probed, analysed, decapped with acid, and ultimately written out as code. By adding board ROMs (whole dumps of the memory chips containing the copyrighted program data), MAME can emulate a system by connecting together drivers for all of the chipsets as per the layout of the original board. Recently, the sister project MESS has been merged back into the MAME main codebase, adding ~2200 consoles and home computer systems to the lineup. It is an incredible feat of volunteer-driven engineering.
Unlike other emulators, MAME places accuracy and preservation above all else. All CPU code is interpreted (with some IL speedups via the UML architecture) and runs time-shared in a single thread. Instead of tightly coupling the hardware code with the framework for performance, MAME has an infinitely-rewirable generic module architecture, to encourage reuse of chip drivers across platforms. Imagine MAME as a big box of all the different types of chips, plus some templates that explain what chips to take from the box and how to wire them together to make a system.
Also I was not exaggerating when I said every arcade machine ever made. The MAME source tree has slightly north of 6900 .cpp files, and a princely 2.9 million lines of code (4 million if you count headers!). This is a Big Codebase.
Article continues here! KEEP READING, YOU
Show Your Working: Patching a bug in a 25 year old Sierra game
Sat 23 September 2017
Show Your Working is a brand new segment where I write up things I have attempted to fix in open source software. Sometimes it's interesting to debug a problem yourself from first principles, even if the codebase is huge and you don't know anything going in. I will try and explain my thought process as I venture out into the weeds armed only with a butter knife.
The software
ScummVM is a heroic effort to make a cross-platform engine for hundreds of classic adventure games, making them natively playable on modern systems. Since 2010, ScummVM contains an interpreter originally from the FreeSCI project, and by now does a pretty good job playing games based on the Sierra Creative Interpreter. If you haven't heard of ScummVM, I can't recommend it enough.
It's gotten to the point where ScummVM provides a much better experience than emulating the games in DOS/Windows. Still, given that the engine is reverse engineered without the original code, there's all manner of edge cases and quirks that have to be emulated in order for the games to work correctly, as we'll find out!
Article continues here! KEEP READING, YOU
Show Your Working: Turning off PulseAudio "flat volumes"
Sun 23 July 2017
Show Your Working is a brand new segment where I write up things I have attempted to fix in open source software. Sometimes it's interesting to debug a problem yourself from first principles, even if the codebase is huge and you don't know anything going in. I will try and explain my thought process as I venture out into the weeds armed only with a butter knife.
The software
PulseAudio is the software audio mixer for most desktop Linux distributions. Let's not mince words; PulseAudio has an awful reputation, mostly earned from the botched rollout by Ubuntu and other distributions back in 2008. Long-time Linux users remember these as the dark years where games were unplayable, and everything was punctuated by a loud crackling from the constant buffer underruns. The most egregious problems were caused by the aforementioned shonky buffering, plus a reliance on timing-related ALSA features which had never been used/tested properly for many sound drivers. It didn't help that barely any applications had direct support for the PulseAudio API; there were compatibility shims for ALSA/OSS applications, but they were a crapshoot at best.
But that was a decade ago! We've moved from version 0.9 to version 11.1, a metric ass-ton of effort has gone into making the mixer first rate, most Linux sound libraries are fully Pulse compatible, etc. etc. Surely everything is perfect now, right?