> The next hard drive was an order of magnitude larger than the old one, and so on.
Ah yes, the good old "old PC" folder that you would find on pretty much every Windows PC that used to have another "old PC" folder inside it somewhere, possibly inside an "external HDD (old)" folder :-)
Until the PC (or the HDD inside it) died surprisingly, people didn't have backups, or the backups turned out to be burned CDs that were scratched up and/or sat on a sun illuminated shelf for years.
I was at a class reunion a few years ago where it turned out, I was somehow the only one who still had (digital) photos from early-to-mid 2000s.
> ... even more ephemeral as people started putting data in the cloud where it will eventually be wiped when the accounts stop being paid or lost when the company goes under.
Or the photos they upload gradually degrade in quality as the company repeatedly plays with re-compressing stuff to squeeze more space out.
People have observed old (10+ years) photos on Google Drive to start getting blurry, having weird artifacts, color banding, etc... IIRC there was an article posted on HN at one point with some particular egregious examples. Techmoan also mentioned this in a video some time ago, commenting that the same thing happened to old YouTube uploads of his from the 2000s.
Yet the article goes about the most ass backward way of explaining 8086 segments and constructs a convoluted mental picture of dividing memory into overlapping chunks.
It's really, really simple: segments on the 8086/88 are 64k sliding windows into an 1M address space. You can move them around at 16 byte granularity.
You need more than 64k for code + data? No problem, the CPU knows when it's fetching an instruction vs when it's fetching data, you can have two sliding windows: code (CS) and data (DS). Split them apart, and it's not much different than a Harvard-style machine and gives you access to more than 64k at a time.
Still need more? No problem, the CPU has a hardware stack with dedicated push/pop/call/ret instructions and a base pointer for stack indexing. It knows when it's accessing the stack, so we can split the data window into regular data (DS) and stack data (SS). Oh, you occasionally want to copy stuff between segments or somewhere else in memory? Well, to encode 3 segments we need 2 bits anyway, let's throw in an extra data window (ES) and some DS-to-ES copy instructions.
Michael MJD did a video on this recently, showing off necessary modifications on a vanilla GameCube and the installation procedures: https://www.youtube.com/watch?v=ESV3Qib8eJI
They announced it, they haven't released anything yet. There is not a single real photograph of an actual device on the site. There's a wait list where you can sign up for eventual pre-orders, with an offer that they'll ask you for slightly less money.
Also, it's not Commodore but someone playing "Weekend at Bernie's" with what's left of the brand. The real Commodore went through bankruptcy and liquidation in 1994.
This project has a website that was previously posted on HN[1], I (unsuccessfully) tried to boot it on an actual 486 machine[2], as the site boasts about supporting that.
The version of the SYSLINUX bootloader that it uses had a bug in the fallback path if E820 memory information is not available from the BIOS, and the BIOS on my machine indeed does not support it, or E801 for that matter[3].
I have not gotten around to further testing and fixing the actual issue in SYSLINUX yet (also one of the RAM sticks has sadly developed a parity issue, so I'm stuck at 16M for now). However, I did manage to dig up a newer 486 machine[4][5]. From some testing just this weekend, the BIOS on that one does support INT 15h, AX=E820. I'll have to dig up more memory, but I'm looking forward to another round of trying to get this to boot on the actual hardware, once again :-)
This is really confusing brand/product combination. Who is it trying to appeal to?
I'm pretty sure the people who have fond memories of growing up with a C64 or watching ToS are of an entirely different generation than those with fond memories of flip phones and cyber/color-puke ads for transparent plastic gadgets.
> BASIC Beige Edition
There's a missed opportunity for a better ToS joke here: "Beige... the final frontier"
In October of 2013, Ross Scott did a review of Test Driver III in one of the early "Ross' Game Dungeon" episodes[1]. IIRC in the video, he mentioned that he's fascinated by game maps to the degree of a slight obsession, and would absolutely love if someone could reverse engineer the game assets and extract the maps.
Someone later went on to do just that and responded in the Accursed farms forum, Ross mentioned that in his July 2015 follow up video[2]. In the video he showed some map screen shots from the forum, including a surprisingly intricate map that was apparently only used for the the spinning car menu screen. IIRC the reverse engineering project was not quite complete at the time, since the README doesn't mention any of this, I assume this project is unrelated?
That said, it would be amazing to eventually get the extracted maps integrated into noclip.website[3].
I wonder how many of those are actually still out there. According to Wikipedia, Intel kept making replacement parts (386 and 486) until September 2007, but personally, I have never come across one in actual use. My own career in this field began with an internship in 2008. My day job includes working on a PLC runtime with a code base older than myself, originally written for DOS, but every industrial PC (or other x86 based embedded device) I have ever got to play around with had at the very least a Pentium class CPU in it.
As for the Windows 3.x based industrial equipment: Some industrial devices I have worked on in the past turned out to actually be ARM based, running Linux, but the software went a long way to convincingly fake old Windows style UI or emulate a DOS prompt. I was once tasked to extend such a UI library to faithfully reproduce Windows 98 style color gradient borders.
Only once have I seen an actual embedded 486SX with my own eyes, but not in active use anymore. Last year, someone dragged a dusty, old, weirdo Siemens telephony box to the the local Hackerspace. The box itself had a design language that screamed "Star Trek: Voyager". I found a UART, it was running "On Time RTOS-32" which, according to the German Wikipedia, was an RTOS with a Windows API compatible userspace, developed by a German company in 1996 and discontinued in 2023.
Actual context: Linux 7.1-rc4 release, Linus remarked on a specific documentation change.
The Register somehow turned this into an "article" that says a lot less with roughly the same number of words, and provides "context" by linking to a number of unrelated articles.
> LLMs actually makes retrocomputing a lot more "fun" because you can slop out things that would take way too long to do by hand for pure art and exploration.
Doesn't that kind of completely miss the entire point of the hobby? Like attending an online language class in your spare time and then just using deepl in a separate tab?
> ...powered through emulation under a modern CI server...
I have a 486 PC sitting in my living room. For shits and giggles, I've cobbled together a FAT12 boot loader that runs a program directly off a floppy and played around from there.
And even by that little that I played around so far, I managed to run into more than one issue where something would work perfectly fine in Qemu, but not on the real hardware. Bochs appears to be more faithful, but also not 100% exact.
Btw. did you know that Windows 9x has an interesting TLB invalidation bug that apparently went unnoticed for decades and now triggers in KVM on AMD Zen 2 and newer CPUs? (see: https://github.com/JHRobotics/patcher9x)
AFAIK, part of the reason Linux no longer supports i486 is that it made CMPXCHG8B a hard requirement (and also RDTSC). You would need to maintain a completely separate implementation of a bunch of low-level locking primitives. I'm somewhat skeptical how well that will work when your testing relies entirely on emulation.
This is why lab exercises are important. I remember first building some actual TTL circuits on bread board, I learned very quickly that this whole digital stuff is a lot uglier and messier than on paper or in the simulator.
With sharp rise times, synced up to a common clock, even after soldering in a whole bunch of capacitors, you can still stick a probe pretty much anywhere and see switching spikes all over the place, from power rails to completely unrelated signals that are supposed to be stable. Using actual TTL, there was another funny lesson what this weird "fanout" value in the datasheet meant.
A similar lesson I learned that way (and a very memorable one :-)) was about flyback diodes.
Oh, this is just the usual Microsoft Stockholm syndrome. I've been witnessing this for over 20 years now and have been told that it has been a thing for much longer than that.
"No, we can't switch to OpenOffice you weird Open Source hippie! I can't e-mail documents to other people anymore, nobody can open them. Besides, the UI is all different, I won't be able to find anything!"
Then Office 2007 happened, tossing out the waffle menu for the ribbon and people started receiving e-mails with strange docx/xlsx files that nobody could open. IIRC that was still an issue 3 years later.
But no, when Microsoft does it, it is different: "This is progress! Are you against progress, you weird Luddite?"
I remember by the time Windows 8 was released ("Kachelofen edition" - "hurr, your desktop is a tablet!"), I was discussing with a Unix graybeard friend in the cafeteria how long it will take until the complainers accept that "this is the way now". I think it was him who suggested that if Microsoft sent a sales rep around to shit on peoples lawns, it would take at most a year until they start defending it as the inevitable cost of technological progress.
No matter how slow and bloated the GitHub web UI gets, or how many nonsense anti-features Microsoft stuffs into it. People will accept it and find funny excuses (network effect will be the main one).
https://goliath32.com/
https://github.com/AgentD/
https://hn-wrapped.kadoa.com/st_goliath?share