3 ms·

Keep in mind is these kind of things have a flat memory space between RAM and ROM. It's not like today where disk is some thing way over there that you need to

Keep in mind is these kind of things have a flat memory space between RAM and ROM. It's not like today where disk is some thing way over there that you need to buffer in RAM. All of your code and resources are in ROM which means they're just an address away. Your RAM is scratch space for dynamic values but you can pull everything else from ROM. For instance your bitmaps for pieces/spaces are stored 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. The only part that needs to live in RAM is the board state that the drawing code uses to find the bitmaps to draw. There's no need to draw to an off-screen buffer in RAM that then needs to be drawn to the screen. None of that is to say 128 bytes of RAM is somehow easy but the code and data in ROM can do a lot of heavy lifting without taking much RAM.

toast0 3y ago
> All of your code and resources are in ROM which means they're just an address away. Only until you need more rom than address space available to the cartridge slot, and you need to add bank switching. Then you've got to keep track of what bank resources are in.
JohnBooty 3y ago
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

toast0 3y ago

> All of your code and resources are in ROM which means they're just an address away. Only until you need more rom than address space available to the cartridge slot, and you need to add bank switching. Then you've got to keep track of what bank resources are in.

JohnBooty 3y ago

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