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.
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.
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.
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.
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.
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.
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.
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.
*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]
Hey dzdt, will it matter which REU? In other words, would the 128K version be enough for this to be supported or would it need more RAM (e.g. 512kb, etc.)?
The DMA capabilities are present on all versions of REU. Somewhere MrSid said this Sonic game requires 256k of REU; I would assume that is mostly used for level data and extras; 128k should be plenty to handle the unpacked data for scrolling around a single level.
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.
I have to imagine the development process is a lot better, too. Compile with your 3 GHz processor, launch into it in your emulator… quick feedback loop. (Or maybe this kind of development is still done on the real hardware?)
REU is a bit of a cheat, and for some releases people are using cartridges with far higher capacities than ever sold back in the day. Cross-platform tools and emulation are also huge dev speedups.
But a big thing is that back then, games were often made on a timescale of months, and with a budget. Hobbyist dev has no limits to how much time they want to sink into doing something properly. Ideas & techniques have had many years/decades to percolate into existence.
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
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.
That actually makes a lot of sense, I've only ever played NTSC Sonic. In that case it probably sounds great at the right speed.
Thanks for the insight!
EDIT: In fact watching the video at 1.25x makes the music sound substantially better. I think that's too fast[0], but either way you've nailed the issue I had with it. I'm eager to hear it "as intended".
[0]: I listen to podcasts at 3x speed so my sense of the "right" timing for audio has definitely weakened.
Actually, that’s a popular misconception. The Japanese word for hedgehog is made up of components that transliterate to “needle” and “mouse”, that is true. But the originally intended interpretation was always “Mr. Hedgehog”.
