Thanks! I went so far with it that I was honestly questioning my own sanity.
The HAL has a virtualized CPU, and I spent more time than I’d care to admit precisely timing instructions on various period-accurate hardware (386SX, 486DX). I even tuned it to the point where programs that take advantage of it actually run faster on the 486 because of the built‑in math coprocessor.
> Writing directly to VRAM? WAIT for vsync?
All screen modes are supported including the ability to draw to hidden pages. It’s got a fully emulated VGA hardware layer and even a synthetic VGA beam clock, so you can do tricks like `WAIT &H3DA, 8, 8` for vertical retrace to minimize flicker.
> Call absolute for mouse usage?
Yup! Int 33h is fully supported, we basically use a virtual TSR driver which is pointed to by the interrupt vector table. I actually tested it with an old pixel art editor I made in the 90s!
PEEK/POKE and much of the BIOS are fully simulated, so you can use more advanced QuickBasic 4.5 features like calling interrupts (including silly stuff like rebooting the computer via int 19h).
There's a ton more (including a Hayes compatible modem plugged into COM1) as well.
I basically dug out a stack of my old PC books from the late ’80s and early ’90s, and they’ve been my bibles for the past several months (Undocumented DOS, The Programmer’s PC Sourcebook, etc.).
It’s about 99% done at this point. I’m hoping to do a Show HN in the next couple of weeks.
Wow, I didn’t expect this kind of reply at all. What a labor of love. Can’t wait to try it out! What made you decide to emulate things at this level instead of using a more off the shelf hardware stack?
So I wanted to build more than just a simple online QuickBasic simulator - I've seen a few of them but they all kind of fall apart at the last mile.
You really can't create a QuickBasic interpreter with any expectation of accuracy unless you also flesh out the corresponding hardware that would have accompanied it back in the day.
What I’m really aiming for is to recreate the world we grew up with as kids in the late ’80s and ’90s. I want to tap into that feeling of discovering QuickBASIC on a computer for the first time and realizing you could bring your own creations to life.
For me, and I bet a lot of kids back then, QuickBASIC was the closest thing to sorcery: you could conjure whatever was in your imagination and watch it traced out pixel by pixel on your 14-inch VGA monitor.
I’ve been thinking about this a lot lately. For the last month I’ve been living in a camper van, working and traveling, which I’m really lucky to be able to do by choice. It’s lonely to be sure, but I also feel mentally far more resilient than I have in ages, and I’m trying to figure out why.
Being in nature is good for us, so that’s probably part of it, as is the constant practice of being self-reliant.
Another theory is friction. I can’t just roll out of bed to the couch, and back. I don’t have a fixed place to shower, so I swim in a river most days, and usually it’s freezing. Camping alone was terrifying at first, but objectively not that dangerous and not worth worrying about. All these little moments are a chance to exercise that mental muscle to do uncomfortable things.
Modern life is devoid of this friction. I could try to take a cold shower every day, but a not-cold one is just a turn of the wrist away. I could try to make myself go outside a bit every day, but I don’t need to.
This isn’t a new observation, but I can’t believe how stark the contrast is. I’m getting stuff done that I’ve been procrastinating on for years.
Ha, Chris McCandless is to vanlife what Alex Honnold is to rock climbing: technically the same activity but with a very different level of consequence for failure.
but you might projecting deep purpose and meaning to your travails that you are subjecting yourself out of pure choice.
your heart knows that you can go back to comfortable modern life whenever you please so you wont really experience the pain that comes from hopelessness which i belive is really needed ingriedient to humble you.
Congrats on the traction you’ve got with this project. We used Gin back in 2016 for a while. I honestly don’t understand those Go devs who claim that the standard library is sufficient for building a serious API — there’s still so much boilerplate, and you end up writing your own mini-framework anyway.
The main reason we don’t use it anymore is that the default handlers don’t return the error type, which means error handling and HTTP status tracking get tricky and non-idiomatic as soon as your handlers start calling functions that can fail. It’s essentially a function coloring problem.
One could argue that HTTP status is a totally separate thing from normal errors, and I get that perspective, but that’s a significant ergonomic hit to take for the sake of philosophical purity.
I don’t know about the company’s ethics*, but the app is fine and it’s genuinely useful. For one thing, it has a map with the most popular running routes around you. And if you want to be part of an exercise community in the US or Europe (at least UK), it’s the only game in town.
*Strava is one of the worst apps I’ve seen in terms of aggressively upselling you to a subscription. Genuinely infuriating.
Have you tried https://github.com/simulot/immich-go for dealing with the some of the complexity of google takeout? Not sure how much it actually handles, and whether it can be used easily if you're not migrating to immich, but it's what came to mind here. (I'm a new user of immich but never used google photos)
It’s not about ease of use and freemium, it’s the strong network economies at play, just like credit cards or social networks. It’s impossible for a competing product to get traction if it’s merely a little better than GitHub.
This is the real issue. We’re currently migrating from GitLab+Jira to GitHub. I did most of the migration, including our CI/CD with a self-hosted runner, and it was… fine.
The straw that broke the camel’s back was that Claude managed cloud agents are awkward to use with anything other than GitHub. In general, we realized that the whole world was on GitHub and we were swimming upstream.
But the original mistake was separating issue tracking and source control when we didn’t need all that power. Everything is so much simpler if you don’t have to maintain those integrations.
Maybe they’ll really enshittify GitHub in the future. We’ll cross that bridge when we come to it.
reply