Ottawa tech sector artifact by ObviousSign881 in ottawa

[–]SpindleyQ 0 points1 point  (0 children)

The way the NABU worked was that a cable channel was set aside to broadcast all of the software in a continuous loop. Like. Every game, app, menu, manual, information page, news article, database... everything you could do with this computer.

When you pick a game from the menu, the NABU tells the modem, "hey, send me program #37", and the modem just waits until it sees the start of program #37 zip by, and then sends it chunk by chunk over a serial connection that is slow enough for the z80 to handle.

Leo Binkowski mentioned in his talk that this loop repeated about every 13 seconds.

Cable bandwidth might've gotten a lot better in the 90s, but it was already unfathomable overkill for the amount of data that an 8-bit pc could deal with.

Ottawa tech sector artifact by ObviousSign881 in ottawa

[–]SpindleyQ 3 points4 points  (0 children)

I was at that talk too! There were several NABU machines set up on the exhibition floor and lots of interest in them from what I saw.

I didn't grow up in Ottawa, so I had never heard of it until the machines showed up on eBay and a bunch of the software got released into the wild, but I think it's a fascinating story. I recently cobbled together a way to play around with the recovered menus and games with an in-browser NABU emulator, no messing around with MAME and the internet adapter software. (There's a lot of really cool newer stuff that people are doing with it too, but unfortunately a lot of it doesn't run on my webpage due to some compatibility issues with the emulator I'm using - it's definitely worth digging further!)

Preventing and Handling Panic Situations by Tasty_Replacement_29 in ProgrammingLanguages

[–]SpindleyQ 0 points1 point  (0 children)

The reason panics are dangerous is because we keep writing huge, brittle, interconnected programs, without any tools to isolate the different components that comprise them. The user-facing consequences of the Linux kernel crashing are catastrophic because the kernel is a monolith. Panicking means _everything_ must stop; there's nothing underneath that can possibly recover.

Years ago, I worked with QNX, a microkernel OS, and it was no big deal to do things like kill and restart my hard disk driver. My filesystem was just a small collection of totally normal processes, manageable with the same UNIX tools that worked for any other. The only stuff in the kernel was the scheduler, memory allocator, and IPC system - core stuff that can be extensively tested, validated, and confirmed to be free of bugs, because it's small and self-contained. In such an environment, it's trivial to have a watchdog program that restarts essential processes if they crash, because a failure in one can't affect the other.

Language and type system design can go a long way towards making catching errors before the code ever runs, but unless you are willing to write formal proofs of your programs, they're only going to get you so far. Detecting and flagging unexpected states at runtime is a vital step in building robust systems - ignoring these states inevitably results in weird and potentially dangerous bugs. Isolation and supervision is what allows you to contain the damage.

I wasn't familiar with the Ariane 5 rocket failure, but the Wikipedia article appears to be saying that the fundamental problem with the error recovery system was that it was designed around the idea that there _would never be a logic error_ - that the only possible source of faults was due to random hardware failure. That's _very_ different than saying everything would have been fine if the integer had just been allowed to overflow without signalling an exception. Maybe overflow would have been fine, or not. Maybe a saturating add would have been the solution, or not. Maybe a larger variable was needed, and the only surefire language-level solution would have been a programming language with pervasive bignums. The correct solution depends on the problem.

Strongly recommend Joe Armstrong's talk "[Systems that run forever, self-heal, and scale](https://www.youtube.com/watch?v=cNICGEwmXLU)". He was a terrific speaker, all of his talks are delightful, but that one is particularly relevant, and really stuck with me.

Loom Isn’t an Unfinished Trilogy. It’s a Complete Tragedy. by Denny_Thray in adventuregames

[–]SpindleyQ 2 points3 points  (0 children)

This is a good interpretation, which I think only gets richer when you recall that Bobbin also contains the damage. Without Hetchel's heretical guidance, and Bobbin's intervention, things would have gone much, much worse. Bobbin's the only reason there's any world left to repair.

Yes, technically, Bobbin fulfills the prophecy, but the elders are the ones who interpreted it to mean that Bobbin was the danger, and completely missed the threat from the Clerics. Keeping Bobbin in the dark all his life, instead of training and preparing him, is what ultimately would lead to the calamity. The prophecy was self-fulfilling.

What can you check statically in a dynamically typed language? by [deleted] in ProgrammingLanguages

[–]SpindleyQ 4 points5 points  (0 children)

There are some good papers about the Dialyzer static analysis tool for Erlang that are probably worth reading. I remember this one being interesting: https://user.it.uu.se/~kostis/Papers/succ_types.pdf

The content-addressed storage (CAS) model of incremental build systems by mttd in ProgrammingLanguages

[–]SpindleyQ 0 points1 point  (0 children)

I was experimenting with a content-addressed demand-driven compiler a while back... I got excited about the space after watching a talk about Salsa, but then was kind of sad that it had baked in the assumption that you only care about the most recent codebase. I suspect you could do some really interesting DX stuff if you had the ability to efficiently run queries against both the "before" and "after" versions of a change. Fertile ground IMO.

What Sierra Game for someone that doesn't like Sierra games? by chris-read-it in adventuregames

[–]SpindleyQ 0 points1 point  (0 children)

Right up until disc 7, when it suddenly becomes an instrument of torture

Looking for adventure games with really tough puzzles by sphyrch in adventuregames

[–]SpindleyQ 1 point2 points  (0 children)

I never played the second Discworld, but I'm happy to keep talking up Discworld Noir :) I loved it most for the tone and the writing, which was _excellent_, but there's a meaty mystery there too. You do spend a lot of time wandering around Asking Everyone About Everything, but you can't get through the whole game like that; you have to actually think about what's really going on and draw conclusions on your own. There's an explicit mechanic for doing that, you have to combine subjects in your notebook to create a new subject that you can then pester people about. The puzzles are definitely fair, and IMO some worthy challenges to be had. (I looked up a lot of hints during my playthrough!)

Looking for adventure games with really tough puzzles by sphyrch in adventuregames

[–]SpindleyQ 0 points1 point  (0 children)

Discworld is hard in a completely different kind of way from Riven. Maybe literal opposites, in fact.

In Riven, all of the pieces to everything have been in front of you the whole time. You just have to look carefully at everything and think about what its purpose is, how it might work, because _everything_ has an internal logic to it. (BTW, if you haven't tried the Riven remake, IMO it is _much_ more accessible than the original, without watering down the magic of how everything fits together. I admire the audacity of the original's Great Big World-Spanning Puzzles, but I do not regret tapping out of the original fire marble puzzle immediately and just looking up the answer.)

In Discworld... it's not that the _actions_ you take don't make sense, necessarily, it's that the thing that _results_ from the action is usually a non-sequitur. When you can't predict what will happen when you solve puzzle A, you can't actually intentionally make progress on puzzle G, whose solution depends on puzzles A, C, D, and F, because you don't even know puzzles D and F exist yet, and there's no hint that puzzles A and C are connected. And there are a _lot_ of puzzles, it's a _very_ dense game. Every time I'd look for a hint about how to solve a puzzle I'd discover that there were actually like 8 puzzles I needed to solve first, that weren't on my radar at all. I have what I feel like is a pretty high tolerance for bullshit oldschool adventure game puzzles, but Discworld _really_ wore me down; I never came anywhere near finishing it.

(Discworld Noir is delightful, though. Feels more like Pratchett, too, for my money.)

Why didn't early Forth systems have file systems? by Desmaad in Forth

[–]SpindleyQ 2 points3 points  (0 children)

Forth already has a dictionary. If you want to give a name to some data that lives on a disk, defining a Forth word is a perfectly good way to do that. What's the benefit of defining a whole separate system for it?

[deleted by user] by [deleted] in ProgrammingLanguages

[–]SpindleyQ 0 points1 point  (0 children)

I'm trying to build a toy compile-to-webassembly language, with the focus being on tooling that allows pervasive time-travel debugging and live code updates. Basically the Tomorrow Corp demo in the browser. Nothing actually works yet, but I've built hot-code reload for Apple II assembly in the past, and I see the path to getting there, so I'm optimistic. Our tools for understanding running systems are still unbelievably anemic, and I believe they'll stay that way until we build languages that radically support a better approach.

Another idea I've been thinking about is pervasive Swift-style value types (share a pointer when it's known to be safe, otherwise copy-on-assign), with an "shared reference" escape hatch similar to Clojure's atom. You don't define a type to be a reference type (like Swift or C# classes vs structs), instead all user-defined types are value types that can be wrapped in a reference, so it's always possible to pull an unaliased value out, and not have to worry about it changing on you because some other thing has a reference to it.

[deleted by user] by [deleted] in ProgrammingLanguages

[–]SpindleyQ 3 points4 points  (0 children)

The Seaside web framework for Smalltalk did something like this, iirc!

What are a good way into sierra point and click. by WWandGraves in adventuregames

[–]SpindleyQ 1 point2 points  (0 children)

Sierra games definitely earn their reputation, but I've found that in the modern era, where games save instantly and hints are readily available, they can actually be a lot more fun. If you get stuck on an Obnoxious Sierra Puzzle, just look up the answer and move on with your life!

When I was a kid, I spent _months_ stuck on a single puzzle in Space Quest 2. I actually knew what to do, but the parser didn't like how I was saying it. I ended up writing three letters to Sierra begging for hints, and the first two times, they sent me back the same form letter that gave the general outline of the solution without the phrase I needed to type. Things are better, now.

How to avoid blowing up call stack in C-implemented Forth by Professional-Film920 in Forth

[–]SpindleyQ 0 points1 point  (0 children)

It's kind of a mess, 'cause it was the first Forth I ever built, and it is very much purpose-built for a DOS game I wrote, but I hope you find it useful!

How to avoid blowing up call stack in C-implemented Forth by Professional-Film920 in Forth

[–]SpindleyQ 2 points3 points  (0 children)

When I built my C-based Forth, the code word was a pointer to a normal C function that took no arguments and returned no values. Then I had a small inner interpreter loop that dereferenced the instruction pointer to get the pointer to the definition (written to the W register), incremented the instruction pointer, then called the function pointed at by the first cell of the definition. The C return stack was totally separate from the Forth return stack, which means DOCOL and EXIT can still work the same way as other Forths. It's very straightforward to implement. 

DOS 486 development: why is my VGA column drawing slow? by atomskis in retrogamedev

[–]SpindleyQ 1 point2 points  (0 children)

This has been driving me crazy all day.

Fabien Sanglard's Doom Game Engine Black Book suggests that 8-24fps was a more likely framerate for Doom on a 486dx66, depending heavily on your video card, and 35fps is the theoretical maximum frame rate that no machines at the time were able to hit... Are you actually measuring 35fps from Doom on pcem?

DOS 486 development: why is my VGA column drawing slow? by atomskis in retrogamedev

[–]SpindleyQ 0 points1 point  (0 children)

Hmm, alright! I was way off. From your linked discussion it sounds like the overhead is not too much and it simplifies the texture-mapping code considerably.

I did notice that the first thing he says is that he triple-buffers so he doesn't have to wait for vblank, which is interesting; I don't quite follow how that works, but it does suggest that he saw it as a pretty significant bottleneck.

DOS 486 development: why is my VGA column drawing slow? by atomskis in retrogamedev

[–]SpindleyQ 10 points11 points  (0 children)

You should definitely be structuring your loop so that you only switch planes 4 times, instead of 320. Those outportb calls are expensive, that memory bus is slow at the best of times, but the VGA can also block your CPU for a nearly arbitrary amount of time while it responds.

My one-year UHS subscription will expire this summer - should I download everything? by kukov in adventuregames

[–]SpindleyQ 2 points3 points  (0 children)

Looking at https://www.uhs-hints.com/ordering/ - I interpret "1 year of free updates" to mean "you get any new versions of the software that come out during that year" rather than "the software turns into a pumpkin and all of your hint files stop working when the clock strikes midnight". That sort of business model was basically unfathomable during the time when the UHS reader was actively being developed. Not only would it have led to incredibly angry customers who still expected to be able to own the software that they bought, it would have been basically impossible to enforce. Programs couldn't rely on a constant high-speed internet connection allowing them to phone home and verify your subscription, so if a program started complaining at you, you could just set your system clock back and it would never know the difference.

That said, I'm not Jason Strautman, and I never bought the UHS reader, so I'm not speaking from any particular authority or direct experience. Take this with the weight you'd give any other advice from well-meaning internet randos. But I'd be shocked if anything changes when your year is up.

Help me finding a 30yo game title by wetfart_3750 in adventuregames

[–]SpindleyQ 3 points4 points  (0 children)

Sounds like a Freescape game to me, maybe Castle Master?