Finding Atari Games in Randomly Generated Data | Hacker News Reader

Finding Atari Games in Randomly Generated Data

bbenchoff.github.io

174 pointswanderingjew37 comments

When I was a kid, I had a ZX Spectrum 48K with a cassette tape as the storage unit. Tapes are notoriously unreliable. One day I loaded a game [1] and got the dreaded "R tape loading error".

Instead of adjusting the azimuth and retrying, I decided to take my chances and typed RUN to execute the one-line BASIC bootloader that starts the actual machine-code game.

To my surprise, the game started, but there was something odd. Even though I should have lost all my lives, the game kept going. Somehow the loading error had modified a few bytes in the game that were responsible for checking the game-over condition.

I finished the game several times without ever seeing the Game Over message. Well, the probability isn't as low as accidentally writing a game from scratch, but it's certainly interesting when you think about it.

[1] https://en.wikipedia.org/wiki/Firebirds_(video_game)

I remember weirdness in c64 games because of tape errors. I remember playing tusker and it was like it was haunted. Main character changed colour and disappeared entirely, hud elements turned Eldritch between game screens. It was wonderful

I had a corrupted save of Ultima III for the C64 on a disk. The game worked normally, but the world data had been corrupted into a bizarre mis-mash of all available terrain types and monsters. I kept that disk around and periodically loaded it just to fool around.

I think you could deliberately insert the wrong disk at some point and get corrupted terrain that had an ‘infinite’ chest in it (or was that Última IV?)

Pokémon Blue/Red/Yellow had a similar glitch.

I had a different, but in some ways similar, experience with the game Elite on the Amstrad CPC. At the time I borrowed it from my friend who raved about it, the elastic band in my tape deck was starting to stretch, and the tape speed was somewhat inconsistent. Listening to it load sounded horrible - you could hear it warbling on the normally steady tones, but generally things loaded just fine so I wasn't massively worried about it.

Anyway, in Elite, you can save and restore your progress, so I did that because I felt like I'd accomplished something. However, after a week or so, I was getting pretty bored that I was just flying from place to place, trading, but not a lot else was happening. I had the occasional fight with another ship on my way to a new planet, but only maybe every 2nd or 3rd flight. It was basically a trading game and nothing much else.

I returned the game to my friend a couple of weeks later and told him how I found it pretty boring. He was surprised and said you get attacked almost every flight. We loaded it up on his CPC, and sure enough, I played for about an hour, and there was lots of combat. Borrowed the game from him again, and this time didn't load up my old save game, and had the same - lots of combat. Reluctantly, I started again, losing all my credits from trading, but suddenly the game was actually fun again.

My best guess is that some data that controlled how much combat action I got had been corrupted in a way that wasn't detected by the checksum, and once that was reloaded it got persisted in every subsequent save. It sounds implausible, but actually most checksum schemes on the CPC don't differentiate between runs of 00 bytes or runs of FF bytes, as they're usually done as mod-255. [0]

[0] checksum code is often a bit like this: IN: A byte that was written, HL previous CRC. ADD A,H: ADC A,0: LD H,A: ADD A,L: ADC A,0: LD L,A [1]

[1] Often called Fletcher-16, it's much simpler on an 8-bit CPU than the pseudo-code on Wikipedia suggests [2] if you pre-initialise the counters to 1 instead of 0

[2] https://en.wikipedia.org/wiki/Fletcher%27s_checksum

I think Elite on CPC had a Firebird loader, which had its own checksum algorithm different from Amstrad ROM. It had way shorter blocks. It might be weaker against certain patterns more than the stock ROM as you said.

Rubber keys and rotten leads

Rand and run and load and screens

Then five minutes fingers crossed

Hoping not to witness the terror

Of R: Tape Loading Error

(M.J. Hibbett & The Validators - Hey Hey 16k)

There was a sub-industry created around doing this sort of memory modification on purpose with devices like the "Game Genie".

https://en.wikipedia.org/wiki/Game_Genie

Game Genie was a device that could replace values on the cartridge bus, allowing it to change what the system sees when it fetches bytes from ROM.

Unlike many other cheat devices, this meant that Game Genie modified ROM (game program) rather than RAM (game variables).

I had a cracked version of Turbo Esprit game on Amstrad CPC. There was one utility pole in the game in one of the maps. You reached to it by turning left at the start and then right, and it was second pole on the right, or something like that. If you hit that pole using "street turn" action, you'd instantly get teleported to another street with hundreds of pedestrians, climbing up to the sky. I thought I'd found heaven, but now thinking about it, the glitch might be caused because of the crack and repackaging. I loved discovering such an obscure behavior in a game though. I couldn't reproduce it on an emulator again.

Another way to induce memory corruption glitches on old computers was to quickly turn off and on again. I never managed to get anything useful like your unlimited lives hack out of it but I did see lots of interesting graphical glitches on my Atari 800XL back in the day.

Nifty and fun.

I would say, however, given the staggering space of possible ROMs, it's not particularly cheating to change from using the acceptance criteria to judge random ROMs, to using the acceptance criteria in the generation phase. It's fine to do things like generate random opcodes instead of purely random numbers for the first 1KB, for instance.

It's really just an optimization of what you're already doing; it's equivalent to randomly generating a lot of options then rejecting the ones that don't fit, except it goes much faster and produces a lot more output of interest instead of burning energy on things that are just going to be rejected anyhow.

Fun. It's basically Borges Library of Babel[1] where each book is a 4K ROM!

If you do the math based on the specs given in the story (and crucially, you assume that each possible book appears once) you end up with a library several times larger than the observable universe.

1: https://en.wikipedia.org/wiki/The_Library_of_Babel

https://libraryofbabel.info/ is inspired by that story and is a library of all combinations of 3,200 characters (well lowercase letters, space, comma and period)

There's also a later implementation at https://libraryofbabel.app/ which has a search space of 1.3M characters. Though this does make it less easy to share them, since at that scale, the reference locations become very much unwieldy.

> All of these produce valid video output and show dynamic or structured data.

While they will usually produce video on old CRTs, the video signal they generate is technically not valid. The VSync signal needs to be generated in software, and random programs are unlikely to do so correctly. Different TVs will behave differently (usually rolling on old TVs, blank on new TVs), and probably none would look like what the emulator is showing.

I tried running the game-like ROM in Stella and couldn't get it to work. It seems to depend on the startup state, which means it likely wouldn't run on an actual console.

All fun and games until you look up and notice that overhead, without any fuss, the stars were going out.

The simplest 2600 games were just 2k in size not 4k. Combat for example, is a 2k rom.

If you want to increase your chances of finding something but still generating a "complete" rom, then limit the size to 2k.

If 256 bytes is enough to code a demo...

https://www.youtube.com/watch?v=wlW84fEHngM

https://www.youtube.com/watch?v=O-WjF_dxdHM

I'd say gentlemen (m/f) start your random number generators

Let me introduce you to Hard 2632, a device for 32 byte demos: https://xayax.net/hard2632/

SectorLisp:

https://justine.lol/sectorlisp2/

Ok, Lisp and Forth can bootstrap themselves from a small core, but still...

Great concept. Very Library of Babel[1] -esque.

[1] https://libraryofbabel.app/ disclaimer - my own project

Reminds me about "Pulling JPEGs From Thin Air": https://news.ycombinator.com/item?id=8571879

Interesting. I know the author thinks asking an LLM to make Atari games is cheating, but did he consider just randomly sampling from the assembly code of Atari games?

Ace!

Quite a while ago I did something similar [1] with a much simpler problem space: 32-byte DOS programs and rudimentary genetic programming.

[1] https://www.pouet.net/prod.php?which=59302

This is one of the dumbest projects I've ever seen, and I mean it as a compliment.

I'm in awe.

Chip8 would be easier.

Also, instead of Z-Machine games, try writting Inform6 code, the games are highly modular and OOP oriented so creating something understandable can also be made without even an AI, just premade phrases with cliché settings.

I love it, it's crazy!

It would be cool to start with a random ROM image and then use a Monte Carlo technique (simulated annealing), making a set of random changes to the image by flipping bits, use the change in the "composite score" for the decision step in the MC iteration, and have your image "evolve" into something.

Repeat until one finds a game that is new!

Should only take a few ages of the universe. :-)

When did we get from pulling games to pulling something that runs on Atari? Entropy theory describes why the monkeys won't write shakespeare even after billion years. It's not about probability, it's about information which those monkeys will lack. Randomly generated data might contain parts of the game but not the game itself.

This is such an interesting experiment! Somebody else already mentioned Borges, but yeah!

Not exactly the same but reminds me of one time I did an experiment with rational number attempting to see which patterns emerged… 111? 112? 113? etc.

51014 is tantalizing! I wish the author had taken this farther to see what else would materialize from the aether!

Interesting project! The buzzing from the emulator was quite the jump scare though.

Thanks to the author for the humorous read. Great project!

Proof that scaling compute is all you need.

Scaling compute is all you need.

Now someone has to find interesting ROMs in Pi.

Reply on news.ycombinator.com