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

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

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

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

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.

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.

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.

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.

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)

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

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.

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

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

“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

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.

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.

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