Can you complete the Oregon Trail if you wait at a river for 14272 years?

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...

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.

Sounds like JavaScript!

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.

> 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.

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

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.

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.

> "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.

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.

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

> 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.

that would be 15 millennia or 150 centuries

> 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 :)

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/

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.

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]`

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

> 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.)

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.

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

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 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

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.

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.

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.

> This is so completely wrong I question the person's ability to understand what's happening in the emulator.

I'd argue that it's not completely wrong in the context of a BASIC program; other addressing modes exist, but I don't think the BASIC interpreter will use self-modifying code to make LDA absolute work.

> IIRC, the address + Y can't cross a page - Y is added to the least significant byte without a carry to the MSB.

If wikipedia is accurate, the address + Y can cross a page boundary, but it will take an extra cycle --- the processor will read the address + Y % 256 first, and then read address + Y on the next cycle (on a 65C02 the discarded read address will be different). But if you JMP ($12FF), it will read the address from 12FF and 1200 on an 6502 and a 12FF and 1300 on a 65C02 --- that's probably what you're thinking of.

Yeah. I got as far as the zero-page description and stopped reading. The 6502 was the first microprocessor I learned (on the KIM-1) in 1979. All that zero page addressing offers is a faster way to access memory, because when using zero-page addressing modes, you only need one octet for the address instead of two. When using them on a 1MHz CPU with no cache, you've just saved many microseconds because you didn't need to fetch the high order address octet from program memory!

On the 6502, you can absolutely access all 64K of memory space with an LDA instruction.

The other weird thing about the 6502 is "page one", which is always the stack, and is limited in size to 256 bytes. The 256 byte limit can put a damper on your plans for doing recursive code, or even just placing lots of data on the stack.

I've done lots of embedded over the years, and the only other processor I've developed on that has something similar to the 6502 "zero page" memory was the Intel 8051, with it's "direct" and "indirect" memory access modes for the first 128 bytes of volatile memory (data, idata, bdata, xdata, pdata). What a PITA that can be!

“A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.”

― Robert A. Heinlein

TI BASIC has some unique implementational own goals, however, particularly with respect to system architecture and the middle-level interpreted language TI BASIC is written in. It really makes the 9900 CPU look unfairly bad.

The geology of the PNW has been so unstable for millions of years ... that about once every century your riverside would likely either be flooded-out or buried in volcanic ash.

> You'd have load up on ammo like it's a war wagon. And it's likely you'd blow your leg off at some point, yet still somehow die of dysentery.

XKCD says that's what happened in real life.[1] And that was for the people who made it to Oregon.

[1] https://xkcd.com/623/

Well if you tried this in real life your great...grandkids would now have modern cars to drive to the nearest store and buy more ammo anytime they want. Or they could just buy food from a modern grocery store.

The scarce hunting was a lie. Dysentery was a risk of speed. Rest and eat well, and it would go away. Wagons were limited, as were Oxen, clothes, food, wagon wheels. The only thing that could grow without limit was money, and there was the 'cook.' A provable way to get as high a score as you wanted. The true weakness was trading a clothes for an ox. $5 profit every time. If you hung back a few miles from the Dalles, you could trade as much as you want, back and forth, and then sell all your profits.

You could pass the 14,000+ years by hunting... and trading... at some point, all you need to do was trade...

I had not played the CDC-Cyber mainframe version, nor the Apple II version, I started with the Macintosh version, and having passed Econ with flying colors set my sight on 'cooking' the game, but the same 'cook' was available on the Apple ][ and the PC.

I would suspect that in 10,000 years... that Oxen in 500 generations would have been bred for extreme longevity, as well as the humans too.

Finally, the source code was published at May 1978, Creative Computing, page 137. So.... hack the source. ( CDC-Cyber Basic, I believe... ) for which "On CDC Cyber Basic, the size of an integer is typically 16 bits, meaning it can represent whole numbers ranging from -32,768 to 32,767."

Lol. I played Oregon Trail as part of curriculum in elementary school in the mid 90s, I guess by then it was already a retro throwback.

EDIT: I played the 1985 version, I didn't know there was a text adventure.

Yesterday I was at a gaming parlor in SF and they had "Oregon Trail the card game". I sent my brother a picture. I couldn't my kids to even know why it was special.