So, we still have no way to get access to an older games source

>>3867309
That's what a disassembly is. Idk how they're made, but it's more complicated than running the rom through a program, apparently.

And even then it's in assembly language, not something readable like C.

>>3867309
Disassembling software is really, really, really hard. You can figure out what it's doing, but without building a specific decompiler for each game, you cannot just decompile an app.

Think of it like ground beef. First, you kill the cow and cut it into slices. Then you push it through the grinder and make a burger out of the resulting slurry. That burger has little resemblance to the original cow, and determining what color that cow was would require serious DNA analysis of the beef. You can't ungrind ground beef.

Some games we do have sources to some games. SMB for NES was decompiled and commented. https://gist.github.com/1wErt3r/4048722

Atari 2600 games are just fucking assembly, so they're relatively easy to reverse and have been: http://benfry.com/distellamap/ They look cool, but you won't be understanding or modifying them. 2600 games are optimized down to the fucking bit. Pitfall has 256 screens, all defined by generative code, rather than laid out in memory.

The source code we have today was either saved by someone working on the game who kept the stuff on a print out or on a disk in their garage, or it was disassembled over the course of a months by hand by very smart people.

"Brute Forcing" is a meaningless term. I suppose this would be analogous to trying to reassemble the cow from the ground beef. In the end, it'd just be a really gross, shambling pile of ground beef in the shape of a cow.

You'd be better off just becoming familiar with reading and hex editing nes roms directly. Start with gameshark codes, learn how they're developed, develop some of your own then go on to learning how patches are created.

If games are written in BASIC you can simply read their code but then they are still written in BASIC.

>>3867343
Yes, because BASIC is an interpreted language, not a compiled language. It's like a scripting language, or JavaScript. Some BASIC's compile, though. It's a spurious analogy. Like saying "I can put an oyster back in its shell, so you can put ground beef back in a cow skin.

Java compiles to C compiles to Assembly compiles to binary. 1's and 0's. Computers only understand 1's and 0's. All other languages are an abstraction for humans to make building software easier.

>>3867319

assembler is barely readable at least...

>>3867340
I know enough about coding to put a game prototype together purely in text

I'm attempting to make a sequel to the game DBZ legendary super warriors, I mostly just need to figure out exactly how the original AI works, how the stats interact, and all that for game mechanics.

Not really trying for a ROM hack

>Kid Chameleon is one of my favorite games
>Found a disassembly of it
>Somewhat competent in C
I-if I put in a lot of my NEET time into it, how possible would it be to step through the disassembly, rewrite it in C and make it use a modern library like SDL?

File: 1488927378068.jpg (63KB, 495x600px) Image search: [Google]

63KB, 495x600px

>>3867309
The process of mapping source code (Like C, or assembly) to machine code is not invertible for many reasons. The most straight forward way to see this is that the symbolic names used by the programmer to reason about their code are lost; a computer doesn't refer to a variable by a name (ie "damage"), but by a number (ie, $00AD).

Consider a program in an RPG that computes x2 critical damage. The program might look something like this in C

damage *= 2;

In 65816 assembly (a language that has no native multiply instruction) this could look something like:

LDA damage
CLC
ADC damage
STA damage

or perhaps if you are bit savvy and know that shift right is multiplication by 2, you could write the more efficient program:

ASR damage

or if your 65816 is hooked up to hardware that has multiply functionality, perhaps

LDA damage
STA mult_a
LDA #$0002
STA mult_b
LDA product
STA damage

Immediately it is clear that there are multiple solutions to performing the same action. For a compiler, whose job it is to map high level source code to assembly, the resulting code may look very different if optimization is performed (say, using a shift rather than an add in the above code).

Moreover, when assembly is assembled into machine code, as mentioned all symbolic constants are lost. If you disassembled machine code (0's and 1's) back into assembly, it would read something like this:

LDA $00AD
CLC
ADC $00AD
STA $00AD

This is what us hackers usually work with. If this was the first time I ever saw this program, all I could say is it appears to multiply address $00AD by 2 and store the result back. I would have no clue it's a critical hit damage modification routine. To figure that out, I would have to deduce this fact by experimentation or reasoning about how it relates to other parts of the code (which may be just as cryptic).

Being able to actually understand what the intention of such code is and give a name to the variable is an art only a person can ply.

>>3867363
well, how well do you understand 68000?

>>3867371
So just guess as to what the info I need is?

File: codestart.png (22KB, 1106x913px) Image search: [Google]

22KB, 1106x913px

>>3867372
Nothing, but I could google everything I come across and learn as I go.

Like, here's the top of the file. From what I understand, it looks like these would be rewriten as five global structs.

File: 1487921314783.jpg (9KB, 156x258px) Image search: [Google]

9KB, 156x258px

>>3867371
This entire post mostly dealt with the symbolic variable name problem. It takes a lot of work to back out what all the variables do in an unknown program. For example, some guy posted an NES demo that generated a map randomly. I asked him to release his code, he refused, so I reversed engineered it and posted the result: https://github.com/gewballs/unmap. Even a simple program like this took me an afternoon to break apart, and I'm no newb.

There are several other problems. Chiefly, given a block of bytes, it isn't always trivial to determine what bytes are code and what are data or unused. Essentially you must execute the program to see where it goes, and there is no guarantee the program will terminate. In fact, in general, this is equivalent to the halting problem, which is proven to be undecidable. In other words, in the most mathematically general terms, you can't write an algorithm to do what OP asks.

That being said, just because you can't do it in general, doesn't mean you can't get pretty far. One can always run a debugging emulator to capture a HUGE portion of executed code. Granted, a bug that, say executes level data as code, can stymie this effort. Alternatively, you could try to write a disassembler that eats a rom and poops out source. If you are working with something like ARM, where everything is 4-bytes, this process may be trivial. If you are working with something like the 65816, where not only instructions are variable length, but also the lengths are state dependent, you are right back to the halting problem.

Another point of difficulty are things like function pointers, which are runtime values, but control program flow. You have to figure out what values they take on in execution to know where they go. Halting problem is knocking, can you here it? Often values are organized in rom tables, but this isn't always the case.

You can write a disassembler that gets around many of these issues but not all of them. You still need hackers.

>>3867393
All of these observations are from my attempts to write a disassembler. I have put that project on hold for a while because I wanted to write a custom assembler to target, and that project is only now just bearing fruit.

Ultimately the solution that I have settled on will take a rom and a "decision file", and output disassembly and an updated decision file. The disassmbler will start at entry points defined in the decision file, and will get as far as it can before it hits a wall (for instance, a function pointer call), which it then prompts the user for advice, and records any advice in the decision file. In this way, as a game is disassembled over many sessions, when you fire up the program it reads the decision file and fast forwards you to the last point you left off.

>>3867382
Sure, that's what hackers do. But realize how difficult it is when thousand of variables are interacting. Experience is a huge boon. For instance, when hacking a game, the very first thing I hack is the NMI routine that updates the video display. Anything accessing hardware registers is great too. This way, I understand the I/O of a program, and then work backwards to see how things I understand interact with things I don't. I think it's a lot of fun, but it's fairly laborious.

>>3867360

You are basically saying you can now write your name in Japanese Kanji, so you're going to start trying to write a great epic in Japanese.

Or that you've just gotten your drivers license and now you want to race in NASCAR.

Text adventures are very far away from building NES games. I cannot tell you how many people I have heard say "I want to learn to make a NES game," only to be utterly consumed by the amount of work that actually entails.

If you REALLY want to make a NES game from scratch, first, learn binary math, then hex. Then 6502 assembly. Then the NES.

>>3867337
>Atari 2600 games are just fucking assembly, so they're relatively easy to reverse and have been

NES and the vast majority of decent SNES games are the same. They're just assembly but are not "relatively easy to reverse". You sure make it sound like you know a lot for someone missing this key point.

Not to take away from the interesting disassembly discussion in this thread so far, but are there any examples retro console games (including 5th gen) having their source code leaked/released? There are games like Doom released in that time that have had their sources released, but I want to see console source code.

Disassembly is cool and all but it seems like you would be missing some of the insights that you would get from the original code that the dev wrote.

>>3867309
That's the dumbest post I've seen on /vr/. Do you have even the SLIGHTEST idea of how programming works? Did you NOTICE by chance that source codes are only released for old PC games and only by their devs?

>>3867570
Nope. He is asking for source code from the devs and failing that to brute force disassembly back to something resembling code that we could work out.

Some of the interpretations of and answers to his question have been bad, but the OP by itself is decent.

>>3867563
well i think the PS1 dev tools got leaked at the very least so you can have an idea of how the libraries for that worked

>>3867384
you can do it dan

>>3867642
I mean, they released a special edition of the PS1 just for homebrew dev, it's hard to imagine those being secret

>>3867560
OMG, this has to be OP

You really have no idea what yer talking about. The 2600 is like sticks and stones and the NES is like a porsche, by comparison. There's not a lot you could even do on the 2600, FFS. It had 3 sprites it could move: Player 1, Player 2 and ball. Everything else is a hack, like Freeway. The memory is constrained on the 2600, and the processor so limited that the actual graphics, for example, are stored as 1's and 0's. Dot no dot. There's no ASCII, no text, nothing. The system is so limited, reversing 2600 games is much easier than reversing NES games.
Go read Racing the Beam. https://mitpress.mit.edu/books/racing-beam

Remember that when you start to learn about something, you have no idea how much you don't know.

>>3867563
Console sources in general never get deliberately released because they make use of proprietary stuff from console makers. You can only count on accidental leaks.

>>3867690
The Net Yaroze's libraries were gimped and partial versions of the real PS1 libraries, precisely so the real libraries and tools would remain secret.

>>3867774
I am not OP. I don't feel like entertaining your childish nonsense, just fuck off and don't talk unless you know and understand something.

>>3867309
There's a handful of games where the developers have released actual source code. There are also a handful of games where, due to assembler bugs, fragments of source code and other files were included in the ROM binaries and extracted by NEETs.

Aside from that, no, you can't go back from binary to source. You can disassemble it which will give you something pretty close to the original in the case of early console games which were written in assembly, but that's not source code. Assemblers do optimizations that change the code around in weird ways, the linker shuffles code segments around, symbols are replaced with memory addresses, all kinds of stuff that make it very reader unfriendly.

>>3867774
You'd probably be better off just reading the actual developer manual than some sensationalized garbage book.

The NES is barely different from your points. Instead of each pixel of a graphic being a single binary digit, they're 2 binary digits representing a palette color. There's no built-in ASCII or anything like that on the NES, that's all implemented by the developer just like on the Atari. And maybe not to the extent of the Atari, but the NES's memory was pretty constrained even by the standards of the time.

What you call hacks were pretty much just standard practice. It's functionality that was in the hardware by design, so it's hard to say it's a hack since it's not abusing any hardware bugs or anything. It is convoluted to work with, though, since the 2600 was pretty much designed to make it easy to make Pong clones and exceeding that took ingenuity.

The one thing the NES did have was a far more proper graphics chip. The TIA on the Atari barely did more than produce a video signal, the CPU had to do all the work.

>>3867774
Shill your trash novelization elsewhere

>>3867774
And these are the sorts of posts that differentiate between people who've actually done a thing, and people who've just read about it.

>>3867309
>What's preventing us
The u in us is the only problem. Without that I can do it just fine. kek

>>3867319
Some of us can read assembly, Japanese, and many other cryptic languages. Hell I even remember a bit of ML for the NES cpu.

>>3867337
No. Disassembling software is really, really, really easy and figuring out what's going in is the hard part. But cool parroting bro.

>>3867340
Depends what you want to do. For gameshark tier shit changing branch conditions and nop will do. OP wasn't clear on what he was fantasizing about doing.

>>3867393
Anything can be reduced to an algorithm.

>>3867570
OP wouldn't have posted if he knew how to do it, eh? And probably didn't NOTICE the incorrect shit you did.

>>3867774
Irony: The Post

File: 1487915940963.jpg (26KB, 237x285px) Image search: [Google]

26KB, 237x285px

>>3869841
>Anything can be reduced to an algorithm.
false. the set of computable functions (read algorithms) is a zero measure subset of all functions. Read another way, algorithms comprise nearly none of all functions taken as a whole. There are far more functions that we can't compute than there are that we can.

The Halting Problem is a prime example: Given an arbitrary piece of code, determine if the program will terminate (halt).

Read another way, the halting problem asks : when does a section of code execute (namely the halt instruction)?

"When does a section of code execute?" can be rephrased as "does this code execute?", which is essentially the process of disassembly. Thus, disassembly is equivalent to the halting problem, a proven undecidable problem.

What do I mean by undecidable? I mean no algorithm exists that solves the problem. An algorithm is defined to be a program that can produce a solution in a finite number of steps, and fundamentally no such algorithm exists. Go ahead, build the best disassembler you can, there will always be situations where either your program produces wrong results or gets stuck in an infinite loop. Augment your assembler all you want to deal with these special cases, there will still always be input that will always run in to the same problems.

This is the most general case, though. You can make a pretty good disassembler that could probably handle most things you throw at it. Just know that there will always be input that can trip it up, no matter how clever you get.

As I mentioned, perhaps things like ARM are very easy to disassemble because everything is aligned to 4 bytes. However processors that have state dependence are a much more slippery subject.

>>3869841
>Anything can be reduced to an algorithm.
I love reading posts written by dumbasses who think they know everything, yet expose themselves as understanding nothing in such an obvious way.
You seem to think you are oh so much smarter than all the posters you responded to, but who's buying that now?

>>3870128
Anyway thank god this avatarfagging hero is here to give you all some free education.
Learning assembly isn't impossible, even for the OP of this thread I bet, but it's best to start small. He should try writing a chip8 game or something.

>>3867309
>check out this stupid doomfaggot

>>3870128
Cool story Edgar. Picking a term you don't understand out of a google search and then proving how little you know about it doesn't prove anything other than ignorance. You can't even test a halting problem scenario without an algorithm.

>>3870254
I'm not that guy, but I don't think you even know what an algorithm is.

The halting problem exists, and is a famous and well known example of a problem which no algorithm can solve because it is a very easy problem to define. Intro level CS classes will teach you about it so that you can use it as a test case (as that guy is doing): if a solution to some other more complicated problem would involve solving the halting problem, then you have proven that the more complicated problem also can't be solved with an algorithm. Distinguishing code from data is equivalent to answering "will this byte be executed as code," and if you could answer that question for any arbitrary byte in any arbitrary program, you could also solve the halting problem (as the other guy already explained).

Half the reason I come here is that this is one of the few boards that people come to shitpost and you can learn a lot from observing the threads.

Do what that absolute madman did back in the HL2 days, he hacked into Valve's server and actually fucking downloaded it

There's a guy who did a 100% commented & labeled disassembly of FF1. Pretty rad for hacking. That sort of thing is a huge undertaking, and that's why it isn't done more often.

>>3870128

>Thus, disassembly is equivalent to the halting problem, a proven undecidable problem.

Not quite true. The halting problem is based on theoretical turing machines, while game consoles are finite state machines. So you CAN theoretically solve the 'halting problem' for a NES program on a more powerful system.

>>3871074
You are technically correct. I was about to bring up this point when writing my post because no memory pool is infinite, as required by a turing machine.

However, the temporal and spatial complexity needed to brute force a modern computer state-machine is mind boggling huge. For all intents and purposes, treating modern computing hardware as a Turing machine practically useful. Even "little" systems like the NES.

When you consider the Busy Beaver problem (the question of what is the longest running program for a Turing Machine of a given complexity), and that we don't even know the 5th or 6th number in that sequence, you can begin to appreciate just how quickly the combinatorics blow up in your face. In fact, for the Busy Beaver, the pattern grows so large so fast that the number sequence itself is not computable; we literally can't write mathematical expressions that grows quickly enough.

>>3867563
B.O.B. (SNES) source code was leaked so that's something you could check out. I don't know what kind of a development environment you need though.

>>3871129
https://archive.org/details/SpaceFunkyBOBSourceCode.7z
>It has a few interesting things in there. I love how there's a label in there named "fuck"

>>3870281
I know what an algorithm because I actually use them instead of just reading about them. The halting problem is a mental circle jerk. You solved it ho ho ha ha he he you have to solve it for your own solution. Ad infinitum. Prove we stop at on you're preferred state just before we run out of space in the universe. lol

>>3872025
If you are a programmer, then you know that someone who wants to be able to take an arbitrary binary and turn it back into the original human readable code automatically Is asking for something that just isn't going to happen.

Unless it's one of the rare cases where the source code happens to be available, or where a maestro has lovingly re-created his favorite game instruction by instruction, OP is not going to get that. And if he had to ask like this, he probably won't be able to do that himself for a very long time.

>>3872050
I'm not a programmer in the way you know it. I'm someone who grew up programming for many platforms back when you had to have an intimate knowledge of them. If you think I'm some sort of meta human because I can read several types of ML without disassembling it then thanks. But no, I'm just a man.

OP is a kid asking questions. Maybe you feel he implied it but he never actually said he thought he could do anything with the source. Maybe he was just asking?

>>3867337
I'd have thought that disassembly would be the easy part, given that these games were probably written in assembly. Isn't there a one-to-one mapping between machine code and assembly?

The main gotcha would be losing all variable names (instead just getting addresses).

>>3872142
>I can read several types of ML without disassembling it
You know this isn't the same thing as "brute forcing through it and restoring the source code from a ROM"
But,
>OP is a kid asking questions. Maybe you feel he implied it but he never actually said he thought he could do anything with the source. Maybe he was just asking?
Fair enough. I think it's also fair for me to address the question by pointing out the qualitative differences between being able to transliterate opcodes into mnemonics automatically vs actually having the game's source as the developer wrote it.

>>3872156
>Isn't there a one-to-one mapping between machine code and assembly?
Kind of, but how do you know whether a a range of bits is supposed to be code or data? You can kind of intuit it sometimes, for instance it would be pretty easy to tell data defining a sprite apart from game code if you know what to look for, but that changes from game to game. All of the various caveats add up to making (complete) disassembly into a significant undertaking. If you are just looking to make minor tweaks to a game, in the vein of making gameshark codes, that's another story and is definitely not prohibitively difficult for most people.

>>3872156
Isn't there a one-to-one mapping between machine code and assembly?

Not always, but usually it's pretty close. (You'll lose any macros or label names in the source code, at least).

>The main gotcha would be losing all variable names (instead just getting addresses).

This. It's not just variables, though - you're losing all the symbol names and comments too. Not that you usually need that information to follow the code, but it's very helpful when you're disassembling something.

>>3870128
If it's so difficult to determine what code will do then how does the target CPU do it effortlessly, time and time again?

>>3872180
>If it's so difficult to determine what code will do then how does the target CPU do it effortlessly, time and time again?
This post is a fundamental misunderstanding. The CPU doesn't know what it is going to do before it does it. If the question I'm asking is "will the program halt?" you might think I could just run the program and see if it does. But how long should I wait? The CPU doesn't know.

Put another way, let's say we have a ROM and want to map it to determine which sections are code and which are game data. You could just run the game with a debugger and wait to see if a given byte ever gets executed as code. But what if there is a series of bytes somewhere in the game that code a yet-unknown easter egg? I could play through the entire game without triggering it, so in the end I might think "well, the CPU never executed those bytes, so they must be data I didn't use."

>>3872170
>Kind of, but how do you know whether a a range of bits is supposed to be code or data?
While you're right in the general sense, for architectures with fixed-width instructions (like the 6502), determining code/data for a large portion of the ROM isn't difficult. The CPU starts executing code in an expected place, and you can disassemble instruction-by-instruction from there - following branches and subroutine calls as necessary - through most of the code. Even things like jump tables and tricky pointer math aren't impossible to figure out, especially if you can sit back and debug the code while it's running. Almost anything the decompression algorithm (if there is one) works on is data. Anything being sent to the PPU is data. Once you identify what the sprite data structures look like, you can tag most of those as data.

No, you're probably not going to find easter eggs, or obscure parts of the code in general, but you can get a decent understanding of how the game works most of the time (obfuscated or bizarre coding aside, anyway).

>>3872180
checkmate son

>>3872170
I don't see how using a huge analog computer to convert ML to source is any different in principal than using a smaller digital one. Just because I can read ML doesn't mean I'm not a brute. A drinking smoking swearing womanizing lock isn't brute enough for you? You draw the line at props?

>as the developer wrote it
I often wrote in ML in the early days. I had to deal with timing so the code was full of NOPs and I removed them and replaced them with instructions that took the same size/cycles. Tools were shit so it was much quicker just to fix the code in situ. So in those cases raw bits is as the developer wrote it

>>3872170
>code or data
This is a construct invented by hllfags. On a machine with limited resources like axy and a few k, modifying a "code" comparison value was was almost always the best way to go.

>>3872191
>fundamental misunderstanding
Correct. It is a fundamental misunderstanding that the CPU "knows" anything. It's just part of the process. Your thang is great as a thought experiment but in reality, and certainly in the context of this thread, it's useless. Any shit phone could simulate all inputs and record all outputs for any NES game. And not even at all what OP asked about.

>>3872332
This is the dumbest post I've read today.

Under the pleadge of my bf, I managed to check a lot of old source codes, mostly from NES. But I don't care much for NES games so I just saved it and gave it to him. Just stop being lazy and do it yourself lol, its not hard if you know coding.

>>3872429
This is the dumbest post I've read today.

>>3872475
so sad

>>3872332
Holy shit you are retarded. You sound like a script kiddie who read a wikipedia article and is now regurgitating very badly misunderstood terminology.

File: download.png (14KB, 496x384px) Image search: [Google]

14KB, 496x384px

I've actually disassembled an 8-bit game, Sonic 1 for the SEGA Master System, and discovered an unused song: https://www.youtube.com/watch?v=XWT5N2jTf10

Disassembling a game is like being handed a book in a foreign language nobody knows and you have to translate it. This can be done only through sheer brute force bloody mindedness.

>>3872191
Yeah I see what you mean now. It's hard to account for every single byte of the image without executing it and setting up every eventuality.

>>3872939
But I'm a programmer and have been working as one for over 30 years. So if I sound retarded there's clearly something wrong with your ears or with that shit in between.

>>3872332
Babbage, put your trip back on.

>>3874264
Comparing anyone to that faggot is a really low blow. Not cool.

File: 1490164582213.png (86KB, 1366x738px) Image search: [Google]

86KB, 1366x738px

A huge majority of digital media is already lost or inoperable.

Print your shit out.

>>3875582
That seems like a bit hyperbolic
It's true that if humanity suddenly disappeared today all digital media would be fucked, but assuming we keep going, digital media is easily copied and reproduced, and with the internet there's archives of archives of archives. Everything is archived and reproduced. The de-centralized and chaotic nature of it kind of makes it hard for something getting lost. There's just too many people archiving shit. Obviously something like source code is easily lost because it never finds its way to the internet, but games aren't necessarily being lost. As soon as the internet claps its claws on something it's not letting it go.

>>3875582
And nothing of value was lost

>>3867418
I like you

>>3875598
You're confusing "humanity" with "very fragile and delicate modern society".

>>3867828
>>3867828
>sensationalized garbage book.
"This book offers a detailed and accessible study of this influential video game console from both computational and cultural perspectives. "

I'm glad you're explaining things dude, but this isnt some stupid Steve Jobs biography
you're a shitcunt

>>3875582
I mean, they probably have no reason to do this since the movie is almost 20 years old, but it would cost approximately nothing to copy that 1.6TB onto a newer or more well-supported storage medium.
Most of the time when masters are permanently lost, it's a conscious decision to destroy them because the studio can't foresee ever needing them again.

>>3875582
Theoretically, wouldn't a magnetic hard drive last a very, very long time once data is written to it? I'm talking the actual magnetic disc it uses, not the mechanical aspects that make that disc spin.

I know practically speaking, it's super fucking expensive to recover a broken drive, but there are places that can do it.

>>3876880
Not really. They do degrade. There are specific long-term storage solutions that are pretty good though. The cost of just throwing 1.6TB on a professionally maintained and backed up server would be trivial for a movie studio though, they don't need to invest in special "built to survive the end of the world" level hardware.

I've heard of people taking magnetic HDDs and sealing them in evacuated airtight vessels like a pressure cooker, and then burying them like digital time capsules. I guess in the absence of air, water vapor, and electric/magnetic fields they would probably last a very long time. I don't know how long though. It's definitely more practical to just pay the $10/year or whatever it would cost to back that much data up in a reliable datacenter.

>>3876949
I was thinking more of creating something like you said, a digital timecapsule that could be sealed for future generations. While I'm certainly not an archive, I've made a point to try and obtain a near-complete library of games for various systems so that in the event of catastrophe (Doesn't have to be an apocalyptic event, could just be the internet in the future no longer exists in this form due to laws and you can only access very specific global sites or sites within your state/region) I'd have a history preserved and ready to be picked up by another generation.

Imagine restrictions tighten down on communication and file sharing for a century or so, then one day when the system opens up again, countless movies, games, and music are simply no longer available in their original form, instead only a few pieces were preserved or cataloged, and that future generation has a very skewed and incomplete view on our time period. I want to make sure that one day, when we're the subject of history, that people aren't just talking about what we had and corrupting it with their modern interpretations, I want them to know in exact detail the sum of our culture and ways of thinking.

>>3877179
>I was thinking
Pretty sure this is gonna turn out like all the other things you've been "thinking" about.