How To Download Doom On A Calculator
Heidi Sammons
I can at least help you out with the calculator wad, which was sitting on my hard drive. Zom-B might re-upload the others if asked nicely.
The wad's using voodoo dolls to simulate simple logic devices, which can be combined to implement more complex functions. In this case it's a simple binary calculator.
The TL; DR version is this: someone used Boom's (not Doom's) mapping features to emulate the very basic functions of an electronic calculator, with considerable effort, too. If a calculator was a car, what he achieved can be compared to emulating a single nut and bolt or the spark from the spark plugs, so to speak.
It's mostly a proof-of-concept, which is unlikely to have any practical application:
CONJECTURE: you can emulate the functioning a complete, functional computer (electronic calculator) just by using Boom's game logic with a properly created map.
PROOF: with enough mapping effort, you can indeed re-create the functionality of a few very elementary components of a true electronic calculator using just Boom's mapping features. Once this is done, it's simply a matter of incrementally emulating more components until you get to the point of emulating an entire calculator. Hence, a Boom Calculator, Q.E.D.
Thanks Grey & Maes. I somehow understood the calculator part, but at some point they began talking about Pong and Doom inside Doom and a programmable computer, and there's where I got lost. Thanks again.
It must have something to do with it having been developed for a calculator that's, conservatively speaking, a few thousand times more powerful than the TI-83. Actually, that more modern calculator is more powerful even than the computers that most of us veteran Doomers first played Doom on.
I'm not sure, there probably is. I have a TI 83 and TI 83+ and I regularly put all sorts of programs on to my calculators. I put DOOM onto them before, but it really sucked.
I dunno if TICalc.org lists DOOM (I got it off of a different site), but they have a big archive of calculator games.
yeah, it's at ticalc.org. look hard enough. i've found doom for TI-82.
EDIT: I did find something of interest for the TI-89, see two pics here and here. (these were taken on a TI-89 emulator)
I've found a workable Zelda game for the TI-83. It's pretty fun, if nightmarishly hard. It's pretty amazing to see what they managed to do with the calculator's "graphics" engine, although it still looks like shit. Oh, and it takes pretty much every variable slot the -83 has to offer, too. Not something you want on your machine during finals week. :)
My math teacher back in HS was Texas Instrument's cabana boy. Seriously. It was scary.
If you could even get a TI-82 or TI-83 to render Doom 3, it'd take a couple of months for each frame. It's like back in the day when they used to use the equivalent of a PII to render CG.
As far as oldDoom or even Wolfenstein on a TI calculator...I don't think they're 32-bit, even the 89/92s, so Doom is right out, and Wolfenstein requires a goodly bit of memory, more than either calculator has, AFAIK. Not to mention that even Wolf3D would run quite slow on the relatively slow processors of the 89 and 92. They're just not cut out for it.
yea fucking right, it would even be difficult to get a wolf3d clone to work. a TI-82 has only 4mhz and is the equal to a computer of the mid 70's. Infact i think only the high end ones are only equal to a 8086/apple IIe/C64. if u can port doom to any of those then u could do it for the calculators
It's kinda like comparing SkiFree with SSX Tricky.
I messed around with TI-83 programming at one point. The most ambitious program I did was a half-assed (well, third-assed, really) CRPG-style combat system. Thing is, the program kept getting slower as the game moved on. It would fail with an error after the third fight.
Has anyone else monkeyed around with calculator programming?
Sound familiar? The phrase ?(????) might be new, but the practicing of ridiculing doomers goes back at least a half century. In the case of climate change, those who did the ridicule were on the wrong side of history.
And you should care about p(catastrophe widespread AI adoption) whatever you think about p(doom). The risks of current AI (bias, defamation, cybercrime, wholesale disinformation, etc) are already starting to be well documented and may themselves quickly escalate, and could lead to geopolitical instability even over the next few years.
In conclusion: this morning when I could think more clearly 'cause I wasn't standing on a stage, I thought the overall probability of doom was 19% .. but I don't think you should listen to that very much 'cause I might change it tomorrow or something.
For what it's worth, here's a slightly longer overview on my own current preferred approach to estimating "p(doom)", "p(catastrophe)", or other extremely uncertain unprecedented events. I haven't yet quite worked out how to do this all properly though - as Gary mentioned, I'm still working on this as part of my PhD research and as part of the MTAIR project (see -model-based-approach-to-ai-existential-risk). The broad strokes are more or less standard probabilistic risk assessment (PRA), but some of the details are my own take or are debated.
Step 1: Determine decision thresholds. To restate the part Gary quoted from our email conversation: We only really care about "p(doom)" or the like as it relates to specific decisions. In particular, I think the reason most people in policy discussions care about something like p(doom) is because for many people higher default p(doom) means they're willing to make larger tradeoffs to reduce that risk. For example, if your p(doom) is very low then you might not want to restrict AI progress in any way just because of some remote possibility of catastrophe (although you might want to regulate AI for other reasons!). But if your p(doom) is higher then you start being willing to make harder and harder sacrifices to avoid really grave outcomes. And if your default p(doom) is extremely high then, yes, maybe you even start considering bombing data centers.
So the first step is to decide where the cutoff points are, at least roughly - what are the thresholds for p(doom) such that our decisions will change if it's above or below those points? For example, if our decisions would be the same (i.e., the tradeoffs we'd be willing to make wouldn't change) for any p(doom) between 0.1 and 0.9, then we don't need any more fine-grained resolution on p(doom) if we've decided it's at least within that range.
Step 2: Determine plausible ranges for p(doom), or whatever probability you're trying to forecast. Use available data, models, expert judgment elicitations, etc. to get an initial range for the quantity of interest, in this case p(doom). This can be a very rough estimate at first. There are differing opinions on the best ways to do this, but my own preference is to use a combination of the following:
- I currently lean towards trying to specify plausible probability ranges in the form of second-order probabilities when possible (e.g., what's your estimated probability distribution for p(doom), rather than just a point estimate). Other people think it's fine to just use a point estimate or maybe a confidence interval, and still others advocate for using various types of imprecise probabilities. It's still unclear to me what all the pros and cons of different approaches are here.
Step 3: Decide whether it's worth doing further analysis. As above, if in Step 1 we've decided that our relevant decision thresholds are p(doom)=0.1 and p(doom)=0.9, and if Step 2 tells us that all plausible estimates for p(doom) are between those numbers, then we're done and no further analysis is required because further analysis wouldn't change our decisions in any way. Assuming it's not that simple though, we need to decide whether it's worth our time, effort, and money to do a deeper analysis of the issue. This is where Value of Information (VoI) analysis techniques can be useful.
Step 4 (assuming further analysis is warranted): Try to factor the problem. Can we identify the key sub-questions that influence the top-level question of p(doom)? Can we get estimates for those sub-questions in a way that allows us to get better resolution on the key top-level question? This is more or less what Joe Carlsmith was trying to do in his report, where he factored the problem into 6 sub-questions and tried to give estimates for those.
One potential advantage of factorization is that it allows us to ask the sub-questions to different subject matter experts. For example, if we divide up the overall question of "what's your p(doom)?" into some factors that relate to machine learning and other factors that relate to economics, then we can go ask the ML experts about the ML questions and leave the economics questions for economists. (Or we can ask them both but maybe give more weight to the ML experts on the ML questions and more weight to the economists on the economics questions.) I haven't seen this done so much in practice though.
One idea I've been focusing on a lot for my research is to try to zoom in on "cruxes" between experts as a way of usefully factoring overall questions like p(doom). However, it turns out it's often very hard to figure out where experts actually disagree! One thing I really like is when experts say things like, "well if I agreed with you on A then I'd also agree with you on B," because then A is clearly a crux for that expert relative to question B. I actually really liked Gary's recent Coleman Hughes podcast episode with Scott Aaronson and Eliezer Yudkowsky, because I thought that they all did a great job on exactly this.
The first phase of our MTAIR project (the 147 page report Gary linked to) tried to do an exhaustive factorization of p(doom) at least on a qualitative level. It was *very* complicated and it wasn't even complete by the time we decided to at least publish what we had!
31c5a71286