Sonic the Hedgehog for Commodore 64/128 + REU
lemon64.com
lemon64.com
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]
replace 8 existing chips = 256KB version, replace 8 existing with 16 higher density = 512KB
Kudos to the developers for this!
(Has anyone remade He-Man yet? It could really use a loving touch of...some sensibility)
Happy C64 holidays everybody...
1) Transfer a block of data from main memory to expansion memory
2) Transfer a block of data from expansion memory to main memory
3) Exchange a block of main memory with a block of expansion
4) Verify a block of main memory with a block of expansion memory
copy is ~1MB/s compared to manual CPU speed of <120KB/s
Compare to Amstrad CPC Sonic, for a similar 8-bit machine—but only the final and most expensive models.
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.
https://dfarq.homeip.net/super-mario-bros-commodore-64-versi...
Sonic The Hegehog. For the NES. And you play as Mario.
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.
Great work all around.
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.
https://jsfiddle.net/d9ob0teg/1/
Original NTSC https://m.youtube.com/watch?v=_q1ozyZ6xYI
Differences:
- Mickey Mouse has small eyes, Sonic has big eyes.
- Sonic is blue, Mickey Mouse is black.
- Sonic has spiked hair, Mickey Mouse has big ears.
- Sonic has red pointy shoes, Mickey Mouse has yellow round shoes.
- Sonic has no shorts, Mickey Mouse has red shorts.
- Mickey Mouse has a mouse tail, Sonic has a stubby hedgehog tail.
- Sonic wears socks, not Mickey.
The only thing that's common is the fact both have white gloves.