128b (as in BYTES) of RAM

>128b (as in BYTES) of RAM
>4k ROM size for cartridges

How exactly did they make games for this thing? I mean, all of the text in this post will probably be more than 128 bytes. I know that Atari games weren't exactly complex, but I have no idea how they managed to make shit like Pitfall with those specs.

Attached: origin.jpg (1240x930, 168.72K)

Other urls found in this thread:

en.wikipedia.org/wiki/Pitfall!
youtu.be/e4sq9OhPWKs
youtube.com/watch?v=tfAnxaWiSeE
atariage.com/forums/topic/143750-70s-development-tools/
twitter.com/NSFWRedditImage

read the wikipedia page, it says exactly how he did it
en.wikipedia.org/wiki/Pitfall!

>How exactly did they make games for this thing?
Assembly magic bullshit

They just made smaller games.

It amazes me how small they managed to make games back then. This gif is literally bigger than then original Doom game.

Attached: BjlN.gif (636x357, 2.83M)

Jack Black made it himself dontcha know
youtu.be/e4sq9OhPWKs

Pitfall is one of my favorite examples of finding a solution to limited hardware.

Rather than have a fistfull of levels by actually making and storing level data, the game "randomly" generates them from a fixed seed, 255 "screens" to be exact, only using up 50 bytes!

They tried a number of seeds until they arrived at one what was fun, and that let them save room for graphics and gameplay code.

You could, in theory, make a cartridge that truly randomized this seed value each run to have a new "map" every play, like any other procedurally generated game (minecraft, etc)

Obsolete technology. Sorry guys, it can't be discussed on Any Forums.

>text
hahahaha

>Obsolete technology
Half the people here are pajeets running loonix on 10 year old chinkpads. Most of Any Forums is about obsolete tech.

youtube.com/watch?v=tfAnxaWiSeE
by the dev himself. good video

With assembly. You can literally look at the source code for a lot of these games. None of this shit is rocket science, it's more tedious.

It's actually more incredible how many resources that modern programmers waste. I see Microsoft team using several ghz of CPU power regularly which is absurd for a fucking chat application.

>It's actually more incredible how many resources that modern programmers waste.
It's a concession to productivity. Slow high-level programming practices are faster and cheaper to develop.

>How exactly did they make games for this thing?
with talent. something you will never have

Any Forums has /vr/ why Any Forums doesnt have /gr/ yet?

>>How exactly did they make games for this thing?

>"I worked for Atari and then one of its successor companies (Atari Games) for 13 years, designing hardware for coin-operated video games. When I arrived in 1979, software for the games was cross-assembled on two DEC PDP-11/20 systems in batch mode.
> We had two computer operators who would take your marked-up listing, do the edits, and run the program. If it actually ran without any fatal errors, it would produce a listing and a paper tape. Paper tape? (Well, at least it wasn't punched cards.)
> On a good day the process would take less than an hour. On a bad day, when someone else's project had been designated as "hot" because it was about to go out on Field Test or be Released, you might get only two runs that day.

atariage.com/forums/topic/143750-70s-development-tools/

Attached: 1651783181011.png (1883x776, 64.55K)

modern games need to load a significant amount of data into ram as the cpu has no direct, high-speed access to any other kinds of storage, so like all the data for the level you're in needs to be in ram for it to be fast enough
this isn't the case for cartridge-based consoles, look at other pre-5th gen console and you'll find similarly very small amounts of ram, this is because the carts themselves are roms, just as fast as ram, and attached to the same bus as the ram, with the only difference is that they're read-only, this is why cart-based games "don't have to load", because all the data for the game is already in the same place it would be if copied to ram the moment you plug the cart in, it's like plugging in a stick of ram that has the game permanently on it
some carts even literally also contain extra ram (not on the 2600 though afaik)

2600 games work a line at a time, there's no framebuffer because there's not enough ram for that

like another example which may surprise you is that the NES has only 2k of ram, it's just that it's not comparable to non-cart-based systems, because of the reasons explained

Most 2600 games simply just sucked. There were few talented and creative people that could really use the hardware to its full potential. There's a reason why the 2600 collector market is basically dead compared to the NES/SNES collector market.

>It's actually more incredible how many resources that modern programmers waste
This is the problem right here, a huge change in the attitude of programmers and developers. In the early days they wanted to make things that would work on what people had. Now, they arrogantly just make huge things, don't even bother with optimization, and "here, you figure out how to make your system run it."

sure, but the more you look into the limitations of the system, the more you wonder how you could make a games for the system /at all/, let-alone a good game