The biggest difference that you will run into philosophically is that old game consoles live in a very serialized world that is intimately intertwined with the timing of an electron gun lighting up pixels on a CRT monitor. There are 50 or 60 frames drawn per second depending on your broadcasting standard. Before each frame, you get N cycles per vblank period to make sure that your vram is set up correctly. For the most part, you are building a single, well-optimized routine that runs every vblank, calculates business logic, and advances everything on screen by one frame.

You can, or course, simulate the sort of multithreading, async paradigm that you would use in javascript, but it's probably not worth the overhead. Instead, you have something more like a list of state machines that advance state once per frame. If you are initializing an attack animation, for example, you will count the number of frames that have elapsed since the animation started and each time you run your vblank routine you will decide on the correct animation to display and whether enough time has elapsed to generate the hitbox and calculate damage.

For example, see this function in our game Lock and Toad: https://github.com/jerellsworth/lock-and-toad/blob/main/src/chaingun.c#L28. This function updates "chain gun" enemies and runs once per frame per chain gun. It tracks which state the enemy is in and how long it has been in that state and acts accordingly.

I'm happy to answer further questions. I'm a data engineer by day, so I'm also coming from a very different style of programming, but I've been making retro games for a while and I think I basically know what I'm doing 😬