39 ms·

Keep in mind is these kind of things have a flat memory space between RAM and ROM This is true and is very central to how these miracles were pulled off.

Keep in mind is these kind of things have a flat memory space between RAM and ROM This is true and is very central to how these miracles were pulled off. While you know this, for the benefit of those reading: you could also use ROM for time/space tradeoff purposes -- for example instead of doing a bunch of trig calculations in real time for character movement purposes you could just have lookup tables in ROM. the code called when a scanline is drawn goes and accessed the values in ROM (it's just a memory address) without needing it to ever living in RAM This went away at some point in console history, and I'm not sure exactly when. For example the Sega Genesis/Megadrive has a scanline based video chip. No framebuffer, etc. But you've got to copy graphics data from ROM into the 64KB of video RAM before it can be drawn onscreen -- no rendering directly from ROM. You can do this during the VBLANK interval (the time between frames) but there is not enough time to rewrite all 64KB so you've got to be crafty. Typical procedure was to stream animation data for the main character into VBLANK because you would like your main character to be animated as smoothly as possible. [1] Contemporary systems like the Neo-Geo did not have that restriction and could render ROM data directly,[2] although it was several times more expensive than the Genesis and had many more address lines physically exposed on the ROM cartridge connector. May have used faster ROM chips too; dunno. [1] https://rasterscroll.com/mdgraphics/graphical-effects/animation/ https://rasterscroll.com/mdgraphics/graphical-effects/animat... [2] https://wiki.neogeodev.org/index.php?title=VRAM https://wiki.neogeodev.org/index.php?title=VRAM

JohnBooty 3y ago
Addendum: Contemporary systems like the Neo-Geo did not have that restriction and could render ROM data directly ...which was obviously advantageous for typical use cases! However, it came at a cost in flexibility. The NeoGeo could draw from ROM, but could not draw from video RAM. Games on the Genesis and SNES could therefore use video RAM as sort of a makeshift kludgy framebuffer for polygonal games or for fancier raster effects. The Neo-Geo could do no such thing. The Neo-Geo might have been able to given some custom hardware on the cartridge itself, with a cartridge-based CPU rendering data to RAM on the cart that was seamlessly mapped into the cartridge's address space. I have seen some wacky emulator projects that work this way, like DOOM on NES: https://hackaday.com/2019/06/06/doom-on-the-nes/ https://hackaday.com/2019/06/06/doom-on-the-nes/
kstrauser 3y ago
Wait, the Genesis, which came out in '88, had to race the beam like an old Atari?
- toast0 3y ago
  The races are quite a bit different. On an Atari, pretty much all games spend the screen on time feeding the TIA chip; with most or all of the game logic happening during vblank. On a Genesis, games spend most of vblank feeding the VDP chip with sprite and other graphics data, and then can run their game logic during the screen on time. With some effects requiring frobbing the VDP chip during the drawing phase. However, the genesis and contemperaries still don't have a frame buffer, so their graphics chips are processing background tiles and sprites pretty much just in time. I see some notes that the Genesis VDP does some of this work earlier than most others, so something like changing sprite position data in vram won't be effective until the next frame, whereas contemporaries can reuse a sprite on the top and bottom of a frame by repositioning it in the middle. Otoh, the Atari 2600 doesn't really have sprites, you have to program the TIA with patterns each line.
  - ddingus 3y ago
    "Frobbing" -- added to my goofy nerd lexicon
- JohnBooty 3y ago
  It's beam-chasing, BUT in a much more powerful and programmer-friendly (declarative, really) tile based way. All of the 8- and 16-bit home and arcade systems essentially worked this way. For the Genesis you've got two independent background layers. They are made of tiles. You also have 80 sprites which are also tiles. For each sprite, you give the system an X,Y position and a pointer to VRAM for the graphics data. For each background layer, you give it a scroll offset and a list of pointers to VRAM for the graphics data. Very similar to sprites, but you move the whole layer at once so each tile doesn't get its own X,Y. You don't have to do this on every frame. It will just keep drawing the same thing over and over until you change something. You don't have to do steps 1 through 3 on every single frame - you just make the changes you need. If the game is paused or the player hasn't moved, for example, you might not do anything at all. You have a limited amount of time during VBLANK (the time between frames) to do graphics work. This is where you update sprite/background positions, transfer data, change palettes, whatever. You have an even more limited amount of time during HBLANK (the time between individual lines in a frame) to do things as well. A common use for this is updating the background scroll position in the middle of the frame. This is how you get "line scrolling" effects like the cool pseudo-3D floor effect in Street Fighter II. You can also change palette colors. This is how you get the transparent water effect in Sonic the Hedgehog even through the Genesis doesn't have true alpha transparency - you change the palette part of the way down the screen during VBLANK.

JohnBooty 3y ago

Addendum: Contemporary systems like the Neo-Geo did not have that restriction and could render ROM data directly ...which was obviously advantageous for typical use cases! However, it came at a cost in flexibility. The NeoGeo could draw from ROM, but could not draw from video RAM. Games on the Genesis and SNES could therefore use video RAM as sort of a makeshift kludgy framebuffer for polygonal games or for fancier raster effects. The Neo-Geo could do no such thing. The Neo-Geo might have been able to given some custom hardware on the cartridge itself, with a cartridge-based CPU rendering data to RAM on the cart that was seamlessly mapped into the cartridge's address space. I have seen some wacky emulator projects that work this way, like DOOM on NES: https://hackaday.com/2019/06/06/doom-on-the-nes/ https://hackaday.com/2019/06/06/doom-on-the-nes/

kstrauser 3y ago

Wait, the Genesis, which came out in '88, had to race the beam like an old Atari?

toast0 3y ago
The races are quite a bit different. On an Atari, pretty much all games spend the screen on time feeding the TIA chip; with most or all of the game logic happening during vblank. On a Genesis, games spend most of vblank feeding the VDP chip with sprite and other graphics data, and then can run their game logic during the screen on time. With some effects requiring frobbing the VDP chip during the drawing phase. However, the genesis and contemperaries still don't have a frame buffer, so their graphics chips are processing background tiles and sprites pretty much just in time. I see some notes that the Genesis VDP does some of this work earlier than most others, so something like changing sprite position data in vram won't be effective until the next frame, whereas contemporaries can reuse a sprite on the top and bottom of a frame by repositioning it in the middle. Otoh, the Atari 2600 doesn't really have sprites, you have to program the TIA with patterns each line.
- ddingus 3y ago
  "Frobbing" -- added to my goofy nerd lexicon
JohnBooty 3y ago
It's beam-chasing, BUT in a much more powerful and programmer-friendly (declarative, really) tile based way. All of the 8- and 16-bit home and arcade systems essentially worked this way. For the Genesis you've got two independent background layers. They are made of tiles. You also have 80 sprites which are also tiles. For each sprite, you give the system an X,Y position and a pointer to VRAM for the graphics data. For each background layer, you give it a scroll offset and a list of pointers to VRAM for the graphics data. Very similar to sprites, but you move the whole layer at once so each tile doesn't get its own X,Y. You don't have to do this on every frame. It will just keep drawing the same thing over and over until you change something. You don't have to do steps 1 through 3 on every single frame - you just make the changes you need. If the game is paused or the player hasn't moved, for example, you might not do anything at all. You have a limited amount of time during VBLANK (the time between frames) to do graphics work. This is where you update sprite/background positions, transfer data, change palettes, whatever. You have an even more limited amount of time during HBLANK (the time between individual lines in a frame) to do things as well. A common use for this is updating the background scroll position in the middle of the frame. This is how you get "line scrolling" effects like the cool pseudo-3D floor effect in Street Fighter II. You can also change palette colors. This is how you get the transparent water effect in Sonic the Hedgehog even through the Genesis doesn't have true alpha transparency - you change the palette part of the way down the screen during VBLANK.