Forum seems to be going in and out so here is the YouTube video linked in the post if it's not loading: <a href="https://www.youtube.com/watch?v=jGp4a00OeRs" rel="nofollow">https://www.youtube.com/watch?v=jGp4a00OeRs</a>
A little background on how this works and why the REU is needed. The C64 has a 1Mhz 8-bit 6510 processor. Its video chip (the VIC ii) displays a 40 column by 25 row screen of customizable characters. That is 1k of memory for the characters which uses a re-locatable 1k block of the system's main 64k memory. There is an additional 1k of nibbles (4bit) memory that gives the color information for the display. This color ram is a separate chip and there is no provision for relocating or double-buffering this memory.<p>The VIC ii chip provides hardware support for 8 pixels of scroll in the horizontal and vertical directions. To scroll more than 8 pixels the program needs* to modify the screen data and the color ram. The screen data can use a double-buffering approach but color ram must be updated on the fly, using the vblank interval and/or racing the raster beam to update the lower part of the screen memory before it is displayed.<p>The fastest possible screen update code on a stock C64 is a completely unrolled loop of LDA/STA : load a character value into a register and store that value to the screen ram. That takes 8 clock cycles (fully unrolled) or 9+ clock cycles (partly unrolled). To update 1k addresses of screen data + 1k addresses of color ram takes a theoretical minimum of 16k cycles of processor time, fully unrolled wasting 12k of code space. More realistically for a game this would be partial unrolling and take somewhere over 19k cycles.<p>A PAL display (Europe) updates at 50 frames per second; a NTSC display (US version) updates at 60 frames per second. In the PAL version that is a maximum 19656 cycles per frame if the display were disabled; with the display enabled and sprites in use the VIC ii "steals" some of the cycles from the processor leaving under 18.5k cycles remaining.<p>This makes it impossible for a full-framerate game with no additional hardware to do scrolling as fast as this Sonic appears to do. There just are not enough cycles per frame to process the video memory moves, much less carry out any game logic on top.<p>The Ram Expansion Unit (REU) gives two advantages: one is just to enlarge the storage space of how much memory can be quickly accessed on top of the machine's built-in 64k. This allows larger maps and more game logic to be stored. But the REU has one more feature that is important here: Direct Memory Access (DMA). The REU has the ability to do the same thing the Vic ii chip does: it can "steal" cycles from the processor and use them for memory access. The Vic ii chip only steals cycles to read memory (for screen and sprite display) but the REU can steal cycles to write memory.<p>The REU's DMA can write sequential memory like in the screen display or color ram at a rate of 1 byte (or color nibble) per cycle. So in contrast to the processor, which requires over 19k cycles to update the whole display memory, the REU can do it in 2k cycles.<p>But in its era, the REU was an expensive and not widely-owned bit of hardware. No commercial games used this approach for accelerated scrolling.<p>*there is a hardware trick to cause the VIC ii chip to display a mis-aligned version of the screen data, which allows scrolling by more than 8 pixels with only a fraction of the data updates required. Unfortunately this trick (named Variable Screen Position (VSP) by the demoscene community) causes the VIC ii chip to send out-of-specification signals to the system ram, resulting in memory corruption on a significant percentage of C64's. Thus this approach was also not much used in commercial games releases. [1]<p>[1] <a href="https://www.linusakesson.net/scene/safevsp/index.php" rel="nofollow">https://www.linusakesson.net/scene/safevsp/index.php</a>
Way past cool! I guess with Super Mario on the C64, a (8 bit) Sonic port was inevitable. This looks to be a really colorful remake of the Game Gear/SMS version of the game.<p>Kudos to the developers for this!
Wow, nice! I also want to try the new 3D space exploration game, Gates of the Ancient [0].<p>(Has anyone remade He-Man yet? It could really use a loving touch of...some sensibility)<p>Happy C64 holidays everybody...<p><a href="https://www.youtube.com/watch?v=MTHRU6V54GU" rel="nofollow">https://www.youtube.com/watch?v=MTHRU6V54GU</a><p>0. <a href="https://drmortalwombat.itch.io/gates-of-the-ancient" rel="nofollow">https://drmortalwombat.itch.io/gates-of-the-ancient</a>
I was kind of hoping this was going to be some wonky bootleg, like the original "Super Mario Bros" for the C64, which was actually a resource edited Great Giana Sisters<p><a href="https://dfarq.homeip.net/super-mario-bros-commodore-64-version/" rel="nofollow">https://dfarq.homeip.net/super-mario-bros-commodore-64-versi...</a>
I didn't know the C64 had blast processing!<p>The levels and characters look great, the gameplay pieces are mostly there, and the music at least sounds authentic, if not exactly pleasant. Something was definitely lost in translation there but short of writing new music I don't know what else they could have done.<p>Great work all around.
Anyone remember the best mario type clone (Mayham in monsterland).
<a href="http://www.psytronik.net/newsite/index.php/c64/96-mayhem25" rel="nofollow">http://www.psytronik.net/newsite/index.php/c64/96-mayhem25</a>
Looks a bit better than the previous attempt <a href="https://youtu.be/B1UpBjITF1I" rel="nofollow">https://youtu.be/B1UpBjITF1I</a>