Hi, I'm the guy who discovered the quirk in the first place. You can survive pretty much indefinitely at the river, with or without food. You could cross the river at any point. I just thought it would be a laugh to see if you could get to a five-digit year. Then, upon resumption of the journey, the party very rapidly deteriorates and you can only survive about 5 or 6 days before they're all dead, even if you gather food immediately and wait to restore health. So the unmodded achievement was "I lived for 15,000 years in The Oregon Trail" and then I asked moralrecordings for help in reverse-engineering the game so I could get the satisfaction of a successful arrival.

Just a bit of fun.

edit: And the answer to "Why THAT river?" is simply that it's the last river in the game, and when I was hoping to complete a run without any modding, I thought it might be possible to play normally, get to the final river, wait 15,000 years, and then try to limp my decrepit deathwagon to the finish line before we all expired. This proved impossible, sadly.

Could be the terrain and geology. About 15,000 years ago, after the last glacial maximum subsided, the largest flood in history carved out that part of Oregon. Maybe there is a similar timetable where the Columbia is silted up.

From Wikipedia: "The wagons were stopped at The Dalles, Oregon, by the lack of a road around Mount Hood. The wagons had to be disassembled and floated down the treacherous Columbia River and the animals herded over the rough Lolo trail to get by Mt. Hood."

https://en.wikipedia.org/wiki/Oregon_Trail#Great_Migration_o...

BBC BASIC from Acorn in 1982 supported integers and reals. From page 65 of the user guide [https://www.stardot.org.uk/forums/download/file.php?id=91666]

    Three main types of variables are supported in this version of
    basic: they are integer, real and string.

                     integer       real        string
    example          346           9.847       “HELLO”
    typical variable A%            A           A$
    names            SIZE%         SIZE        SIZE$
    maximum size     2,147,483,647 1.7¥1038    255 characters
    accuracy         1 digit       9 sig figs  —
    stored in        32 bits       40 bits     ASCII values

A%, A, and A$ are 3 different variables of different types.

And to add insult to injury, you write "peperony and chease" on their tombstone.

Edit:

Poor Andy :-(

https://tvtropes.org/pmwiki/pmwiki.php/Trivia/TheOregonTrail

> but for some reason decided not to make integer types available to programmers.

Can you expand upon this? All of the research I've done suggest that, not only was it was possible to use integer math in Basic for the Apple II, there are versions of BASIC that only support integers.

    Please enter your name: John Doe

    Please enter how much money you make every day: 80.95

    Congratulations John Doe you made $400 this week!

Most of the 8-bit BASICs of the time share a common ancestor. Perhaps making every number a floating point was a reasonable decision for the hardware that the common ancestor BASIC was written for and it just got carried over through the generations.

> "for some reason decided not to make integer types available to programmers...It's like they were going out of their way to make BASIC as slow as possible."

BASIC was well-intention to make programming easy, so ordinary people in non-technical fields, students, so people who weren't "programmers" could grasp. In order to make it easy, you better not try to scare adopters with concepts like int vs float and maximum number size and overflow, etc. The ordinary person's concept of a number fits in what computers call a float. You make a good point though that BCD strings might have done the trick better as a one-size fits all number format that might have been faster.

BASIC also wasn't intended for computationally intense things like serious number crunching, which back in the day usually was done in assembly anyway. The latency to perform arithmetic on a few floats (which is what your typical basic program deals with) is still basically instantaneous from the user's perspective even on a 1 MHz 8-bit CPU.

> but for some reason decided not to make integer types available to programmers

They were there, you had to append % to the variable name to get it (e.g. A% or B%, similar to $ for strings). But integers were not the "default."

BASIC is all about letting you pull stuff out of thin air. No pre-declaring variables needed, or even arrays (simply using an array automatically DIM's it for 10 elements if you don't earlier DIM it yourself). Integer variables on BASIC were 16-bit signed so you couldn't go higher than 32767 on them. But if you are going to use your $500 home computer in 1980 as a fancy calculator, just learning about this newfangled computer and programming thing, that's too limiting.

I do remember reading some stuff on the C64 that its BASIC converted everything to floating point anyway when evaluating expressions, so using integer variables was actually slower. This also includes literals. It was actually faster to define a float variable as 0--e.g. N0=0--and use N0 in your code instead of the literal 0.

Floats were 5 bytes in the early 80's Microsoft BASICs, honestly not "massive" unless you did a large array of them. The later IBM BASICs did have a "double precision" float that was 12 bytes maybe?

> It probably would have been faster and more memory efficient if all numbers were BCD strings.

I wouldn't be surprised if Mr. Gates seriously considered that during the making of Microsoft BASIC in the late 70's as it makes it easy for currency calculations to be accurate.

MS BASIC on TRS-80 model 100

default, a normal variable like N=10, is a signed float that requires 8 bytes

optional, add ! suffix, N!=10, is a signed float that requires 4 bytes

optional, add % suffix, N%=10, is a signed int that requires 2 bytes

And that's all the numbers. There are strings which use one byte per byte, but you have to call a function to convert a single byte of a string to it's numerical value.

An unsigned 8-bit int would be very welcome on that and any similar platform. But the best you can get is a signed 16-bit int, and you have to double the length of your variable name all through the source to even get that. Annoying.

I remember having integer variables in Amstrad CPC (Locomotive) Basic. Something with the % symbol. edit: ChatGPT says that BBC BASIC and TRS-80 Microsoft BASIC also supported integer variables with % declaration.

> Something that was very common with BASIC interpreters but still baffling is how they were running on machines with extremely limited memory and fairly limited CPU time, but for some reason decided not to make integer types available to programmers.

To be fair, JavaScript suffers from the same laziness :)

Maybe it was a consideration of code size. If you already choose to support floats then you might as well only support floats and save a bunch of space by not supporting other arithmetic types.

Interestingly enough, the article notes that this program was written for Microsoft’s AppleSoft BASIC, but Woz famously wrote an Integer BASIC that shipped on the Apple II’s ROM.

It’s like knew how popular JS would be someday.

Sounds like JavaScript!

that would be 15 millennia or 150 centuries

Pedantic note - if you have suspended animation, you don’t need Generation ships.

ISTR seeing a sci-fi themed Oregon Trail, actually.

Ah yes, Orion Trail

https://store.steampowered.com/app/381260/Orion_Trail/

over the years i've had to translate a lot of code from academics/researchers into prod systems, and variable/function naming is one of their worst habits.

just because the function you're implementing used single-character variables to render an equation in latex, doesn't mean you have to do it that way in the code.

a particular peeve was when they make variables for indexed values named`x_i` instead of just having an array `x` and accessing the ith element as `x[i]`

have you seen arthur whitney's code style?

https://www.jsoftware.com/ioj/iojATW.htm

i tried this style for a minute. there are some benefits, and i'll probably continue going for code density in some ways, but way less extreme

there's a tradeoff between how quickly you can ramp up on a project, and how efficiently you can think/communicate once you're loaded up.

(and, in the case of arthur whitney's style, probably some human diversity of skills/abilities. related: i've thought for a while that if i started getting peripheral blindness, i'd probably shorten my variable names; i've heard some blind people describe reading a book like they're reading through a straw)

40x25 text screens and line-by-line editors encourage short variable names as well

On the other hand, sometimes less descriptive but globally unique names add clarity because you know what they mean across the program, kinda like inventing your own jargon.

Maybe "PF" is bad in one function but if it's the canonical name across the program, it's not so bad.

> variable names limited to two characters

(It sounds like there was a justified reason for that here, though -- the variable names are not minimized during compilation to disk.)

and then there are the people who name their variables Dennis...

Depends on the version. The original was BASIC, but the one with graphics and sound (which I think was more popular?) was assembly.

If I remember correctly applesoft also had a few single bytecodes that would decode to other key words. Like PRINT and ?. But I could be remembering badly.

Yes, a few minutes spent reading about Applesoft BASIC or Microsoft BASIC would've reduced the cringe factor in reading a neophyte trying to mentally grapple with old technology.

"bytecode" and "virtual machine", no, no, no. That's not the path to enlightenment...

in this case, print debugging, is your best bet.

There are so many different versions of Oregon Trail, you might have played the old version first but substituted the graphics and game play you remember with a later version you also played. Not to mention that imagination fills in a lot of the details when you're playing those games, usually as a child.

There are two versions of Ultima 1, the original has BASIC is basic with assembly and there is a remake in pure assembly. You can definitely tell the improvements the asm version brings with the overworld scrolling faster and the first person dungeons redrawing very quickly.

So - I'm guessing game logic of MECC Oregon was in Basic with some assembly routines to re-draw the screen. BTW original Oregon Trail was also 100% basic and a PITA to read. You're really getting to the edges of what applesoft basic is practically capable of with games like Akalabeth and Oregon

Wikipedia tells me that the 1985 version's hunting minigame is in assembly; it does not explicitly say that the rest is in Basic but it definitely implies this.

Oregon trail was conceptually simple and so well crafted BASIC would be plenty fast. Most other games were move complex and probably needed assembly. Though it was common to call inline assembly (as binary code) in that era as well.

Not uncommon, at least on the A2 and C64, to have a BASIC scaffold acting like a script that runs various machine language subroutines and/or the main game loop.

I also thought it was interesting that it was actually several BASIC programs with data passed back and forth by stuffing it in specific memory locations.