watching the retro game mechanics explained on how the atari 2600 stores graphics and genuinely how did anything get made for this when having to worry about pretty much everything on a per scanline basis
Näytä tämä ketju
-
Relatively trivially. The individual cycle counts for CPUs based on the 6502 ISA (the VCS had a 6507) were well-documented, and the hardware didn't have to deal with things like wait states, or DMA channels temporarily stealing bus access.
Given that the standard cartridge ROM was 4 kilobytes in size including both code and graphics, you couldn't really go too wild with the overall flow of the code, meaning knowing exactly what cycle you were at was easy enough to document while writing the code itself.
-
-
Meanwhile, if you were in the middle of the active frame, drawing the playfield was pretty much *all* you were doing, so counting cycles was really only necessary for the scanline kernel itself. Game logic would tend to run during the vertical blanking interval.
-
To an extent, it's similar to the effort that went into various demoscene demos on 8-bit and 16-bit home computers: To draw graphics within the border region on a C64, you had to do the same thing as on the VCS - cycle-count to know exactly when to change the border color.
Keskustelun loppu
Uusi keskustelu -
Lataaminen näyttää kestävän hetken.
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.