Hi everyone, I found an interesting 3D demo for NES on one of the forums. Author: vitsum. I tested it in an emulator, and it works really well.

Author's notes: *3D maze with doors that open, torches, and a map.

Arrow keys: move. Hold B to strafe. A button: open or close a door. Select: map.

If you don't press any buttons in the menu, the camera will automatically pan through the maze.

Created by artificial intelligence.*

Link

You know the dinosaur from Chrome's no-internet page. This is it running on a real NES — ~4,900 lines of 6502 assembly, NROM-256, NTSC and PAL. I didn't hand-write the assembly: I used two AI models as the programmers and worked as the director, QA, and pixel artist. Sharing the workflow because it worked better than I expected.

Repo: https://github.com/atonamy/nes-t-rex-game
ROM: https://github.com/atonamy/nes-t-rex-game/releases/latest

The approach:

1. Ground truth first. We vendored the actual Chromium dino_game TypeScript source into the repo. Every physics constant, collision box, and obstacle rule was ported from it directly — not eyeballed from gameplay. At the end I made the model audit its own port value-by-value against that source; the audit caught real bugs (a mis-encoded jump-velocity table, an off-by-one in obstacle gaps, a size roll that wasn't uniform). The README now has a fidelity table: what's byte-identical, and what deviates and why.
2. Initial port with Kimi K3 — game loop, physics in the original 600×150 world units (8.8 fixed point), the sprite-zero scroll split for the static score bar, cacti streamed as background tiles so they cost zero sprites.
3. Debugging and polish with Claude (Fable 5). This was the loop that mattered: I play the build in Mesen → I describe the bug or just paste a screenshot / screen recording → the model reproduces it headlessly in a scripted emulator (Lua autoplayers that actually play the game, frame-by-frame RAM/OAM/nametable dumps, forced scenarios by injecting obstacles into RAM) → finds the root cause in the assembly → fixes it → proves it with automated before/after runs. No fix was accepted on "looks right".
4. Art: AI-designed, human-refined. Kimi K3 and Sonnet 5 did the initial pixel art design for the T-Rex and pterodactyl frames; the models also built me a browser-based sprite editor so I could refine and polish that art by hand myself, saving my edits back for the models to import into the CHR pipeline (at one point Fable 5 had to forensically recover a save from my browser's localStorage after I thought I'd nuked it). The game-over restart button is copied pixel-for-pixel from Chrome's own sprite sheet.

Bugs this workflow actually caught (my favorites): phantom walls of cacti painted by a clobbered temp register; invisible cacti from an 8-bit screen-coordinate overflow — you'd die to nothing; the HUD scrolling away on PAL because the sprite-zero wait loops were timed for NTSC's short vblank; ghost pterodactyl parts wrapping to the left edge at max speed; a fast-fall that hung the dino mid-air because two bytes were swapped in a velocity constant. Every one reproduced and re-verified by scripted emulator runs.

What's deliberately different from Chrome: whole-pixel world motion (floor(speed) px/frame), ~2% slower speed ramp from fixed-point granularity, an LFSR instead of Math.random(), night lasting 350 points instead of 12 seconds, and frame-locked timing (PAL runs proportionally slower, as was traditional). Full list in the README.

Builds from source with nothing but cc65. Happy to answer questions about the AI workflow or the NES internals — and if anyone runs it on real hardware, I'd love to hear how it behaves.

RALLY CROSS '87

Single player, Super Sprint style with rally mechanics

Link: (not sketchy I swear) https://files.catbox.moe/cz5qsx.zip

Menus

• Start or A — Title screen → Course select → Race
• Right on title screen — View HOT LAPS records
• Left / Right on course select — Change course
• Left, B, or Start on hot laps screen — Back to title

Driving

• A — Accelerate
• B — Foot brake (reverse when stopped)
• Left / Right — Steer
• Down — Handbrake (locks the rear axle)
• Select — Pause
• Start — Restart race (while paused: exit to course select)

Mechanics

• Race start — Three low tones, then a high tone to go. Clock starts on the high tone.
• Launch control — At a standstill, hold Down + A to rev, then release Down to launch.
• Trail braking — Press A + B together at speed to slow down and tighten the nose.
• Handbrake — Cuts rear grip while held. Steer to rotate the car, then release to catch the slide. Hold too long and you spin out.
• Tip: Down + A keeps the engine revved for a strong exit.
• Spin recovery — Brake (B or Down) below jogging speed, or ride it out.
• Surfaces:
  • Asphalt: fastest
  • Gravel: slower with looser, more slidable grip
  • Grass: slowest
• Jumps — Hit a mound at speed to become airborne. Steering in the air turns the car body but does not change trajectory. Aim before landing. Landing briefly reduces grip.
• Walls — Heavy speed loss on impact.
• Laps — Pass every checkpoint in order, then cross the finish line.
• Hot laps — Beat a course’s best lap time to save it permanently (confirmed by a chime).

HUD

LAP count · TIME (current lap in seconds:frames) · CP (next checkpoint) · V (speed) · S (surface) · D (drift angle) · BEST (session best lap)

Hey all,

Getting NES games running on Steam is something I've been trying to find for a few years. Didn't seem like anything existed and no one was working on it so I ended up building it and figure it could be useful for others.

When I say run on Steam, I mean:

• Native controller input support via the SteamInput system.
• Steam Achievements and proper overlay triggering.
• Works flawlessly on the Steam Deck (and should work on the Steam Machine).
• Built-in localization support.

I've been testing it with one of my projects and it came out very nicely. It's published under Apache 2.0 so do what you want with it.

• The project repo is here: https://github.com/karimhadjsalem/NEShim
• Docs are here: https://karimhadjsalem.github.io/NEShim/

The core emulator under the covers is BizHawk so it supports a lot of the mappers out there (I would say all but there's always edge cases I'm sure it doesn't cover). It natively rendering in DX11 but has a fallback to GDI+ for hardware that can't run DX11. I added a bunch of video, audio, and color filters. It has localization via Steam and OS level for 10 languages.

Hope someone finds it useful

Hi! I’m developing Hyper Pulse, a new NES homebrew shmup built for real NES hardware.

The game has arcade-style shooting, collectable coins, upgrades, and stage hazards like rising lava, falling ceilings, screen-shaking quakes, and living tiles.

Here is two short teaser / gameplay clips:

https://www.youtube.com/watch?v=7oU-kwGP9fM

https://www.youtube.com/watch?v=d7a94_Oc-JA

All feedback is welcome!

Tech info:
I am creating the game with Nesfab language and a custom self upgraded version of the MapFab editor.

The project currently uses the modern Rainbow mapper, but I intend to do a MMC3 conversion as well.

Screenshots:

I'm currently learning C and C++, and I thought it would be fun to try something: porting badapple to the NES without bankswitching

So I compressed the original video down to 16x12 @ 5 FPS (no audio) and stored it as a raw binary format (1 byte per horizontal pixel sequence) to make it fit inside the cartridge

There’s still a bug causing some flash when the screen refreshes, so it’s definitely not perfect yet, but I already wanted to share it

If you want to try it:

ROM: https://github.com/0xagvz/BadApple-NES-NROM

Own emulator: https://github.com/0xagvz/NES-Emulator

Edit:
Youtube: https://youtu.be/by-lQ6QA38I?si=cnemfqBKrbGN0sGH

Hey guys, I created an indie block pushing game for the NES [Nintendo Entertainment System] and was asked to join a promo with 29 other indie game devs. The bundle is 30 games for $30 and its on itch.

Here is the youtube video:

https://www.youtube.com/watch?v=0AumjO9RDGI

Here is the itch page:

https://itch.io/b/3695/new-8-bit-all-stars-bundle

The sale is only for 1 week and it starts this coming Friday.

The idea came from a similar bundle that previously happened for indie Game Boy games.

Thanks for reading!!

Hey everyone!

It was a long time ago when I was trying Nesmaker but was really upset It didn't have the tools like a graphic program to help me with my pixel art needs. I'm inclined on working with Nesmaker again but definitely need a piece of software that give me the tools like old pixel art soft like Graphicsgale did. Any tips on that?

Thank you in advance!

So I've been working on my Blasphemous demake. Lots of new mechanics, new enemies and new levels. Lots of bugs also to work on. There's a new HUD that tracks Health, Fervour, Bile Vessels, Bones and Attack power.

Enemy sprites are a bit sad still, same as background tiles. I tend to work more on mechanics and physics than grpahics, but I need to improve them.

Now there's a self-aware map screen (still buggy) and a work-in-progress Mea Culpa Altar menu (still to be improved).

I also added an AI-generated Manual to explain the mechanics and combos.

ROM here

I made this cover Almost a year ago and the game is still in progress but I’m mainly looking for help with coding, music, sfx, and animation, I already have done a few things like music/sfx, and tilesets but doing this on my own would take a lot longer..

anyways dm me if anyone is interested.

I'm working on a project where i take mother encore tracks that weren't in the original and remake them in the style of the original mother 1. I'm using famistudio, which takes .dmc files.

It's for a NES-style game I'm developing. I'm trying to follow the hardware limitations of the console. What do you think? Is my pixel art good? Would you play a game like this?

Hello,

In the .nes file (ines 1.0 format) of the Donkey Kong game, I extracted the game sprites and assigned random colors. Now I'm trying to assign the correct colors. To do this, I need to find the OAM representation within the .nes file in the PRG-ROM to retrieve the IDs of each sprite and the palette number to assign the correct colors. However, I can't find the starting address to access the sprite attributes in the PRG-ROM.

Despite many hours and days of reading, I still can't find where the sprite tile attributes are located.

Could you tell me where they are?

Here is the header of the .nes file for the game Donkey Kong (JU):

Game name : Donkey Kong (JU).nes

Size file ROM .nes : 24592 bytes

Size of PRG ROM in 16 KB units : 1, Size PRG ROM : 16384

Size of CHR ROM in 8 KB units 1, Size CHR ROM : 8192

Flags 6 - Mapper, mirroring, battery, trainer 0, Has Trainer ? No

Flags 7 - Mapper, VS/Playchoice, NES 2.0 : 0

Flags 8 - PRG-RAM size (rarely used extension) : 0

Flags 9 - TV system (rarely used extension) : 0

Flags 10 - TV system, PRG-RAM presence (unofficial, rarely used extension) : 0

Thank you in advance.

For some time, I've wanted to make an NES game. After some searching, I found NesHacker's tutorial on how to set up a development environment. I made sure to follow the video carefully, and I replicated everything done in the video up until the build part with the demo ROM. Every time I tried, VS Code did not come up with the ca65 option like in the video. I went through the comments, found some advice, but still couldn't get anything. The only thing I can think of is me using Windows 11 while the tutorial said it was for Windows 10. If anyone has any advice or knows if I glossed over something. Please share.

Here's the specific video for reference. NES Development Environment - YouTube

New stable release v0.0.7 available

It allows you to browse CHR and ROM graphics, edit pixels, create static art and animation layouts, manage palettes, and work with ROM-based views such as OAM animations, PPU frame windows, and much more.

• Here's the ItchIO page
• here's the GitHub page
• Here's the DB game tracker

Let u/tavuntu know if you have any questions about the DB tracker or the app in general.

Hello all, I’m looking for some help to understand how difficult it would be take export music written in Famitracker and then put it into a game to play it on a NES.

I’m looking to essentially make my next album playable on a NES. I did this with my first release on GameBoy using GB Studio with the inbuilt music making. I use a NES mini on stage to play back the tracks with the PowerGlove while I sing and play double bass!

I want to make a similar game to test my skill, and I want to use it as a reference. If it's available, how accessible is it?

I was checking the original disassembly code from SMB 1, but in terms of randomness I dont totally get how cannons fire works. Seems like has a cooldown of 14 frames, and three bills at time. How do the fire code exactly works? What does it seems like has some periods of time without shoting?

I know there are big obstacles to overcome until AI could code for the NES (restrictions in space and time, how AI interacts with the emulator, etc).

But, suppose you could feed the AI with, let’s say, King Quest V code (both PC and NES versions) and let the IA learn which decisions to take (those who have played this game in both platforms know what I mean). Then, select another similar game in PC, e.g. another KQ game, and generate the NES code. It would be a new era for gamers, what do you think?

I’d like to share Dark Pillage, a new homebrew game developed for the NES/Famicom.

The game is designed to run on real hardware, respecting original NES limitations in graphics, sound, and gameplay. No emulation tricks — everything was built with the actual console in mind.

This project comes from a love for retro games and the challenge of creating something new for classic systems.

There’s a playable demo available, and we’d love to hear your thoughts — feedback is more than welcome.

Thanks for checking it out!

Demo: https://lucas-favero.itch.io/dark-pillage

Store Page: https://www.dalyengames.com/product-page/dark-pillage-nes

https://reddit.com/link/1qn436n/video/nls1qjhjzlfg1/player

Hi everyone! I wanted to share a summer project that explores the question: what if we had tried to implement language models on the NES in the 1980s?

My thesis was that we didn't lack the silicon for basic LMs 40 years ago. Instead we just lacked the vision, and the NES is capable of running (tiny) LM inference at game time.

So I wrote a bigram language model and turned it into a romhack for Final Fantasy and Dragon Warrior to generate procedural fantasy names for your characters. But apart from the romhack, the NES implementation itself was illuminating.

- Model Weights 729 bytes (uint8 quantized).

- Inference Code 144 bytes.

- Footprint: The entire thing is smaller than the tileset for a single Black Mage sprite, yet it compresses a name space of roughly 18 million possibilities.

As we all know, the 6502 doesn't have a hw multiplication, let alone exponentials or floating points. To get autoregressive token sampling working, I had to avoid standard softmax/logits. I used inverse transform sampling using only sums and comparisons.

The logic looks something like this:

1. Pick a random byte as a target (used FF's own RNG LUT).

2. Iterate through the model row for the current state.

3. Subtract the weight from the target.

4. If the target drops below zero, that's the next token.

Turned out to work beautifully for generating believable fantasy names like DANE, DEIONA, HANNARQUA at interactive runtimes.

Code here: https://github.com/erodola/bigram-nes

I'd love to hear your thoughts on other "modern" concepts that could actually fit on the 6502 if we just got creative with the math!

Hey guys, just finished a new free music pack compatible with the Ricoh 2A03. If somebody could let me know if the .vgm files work on real hardware that'd be awesome!

This pack contains 5 NES-style chiptune tracks designed for indie games.

All tracks are loopable except the victory stinger.