Commodore 64 external hardware acceleration of smooth scrolling?

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
Post Reply
nitro2k01
Posts: 252
Joined: Sat Aug 28, 2010 9:01 am

Commodore 64 external hardware acceleration of smooth scrolling?

Post by nitro2k01 »

https://www.youtube.com/watch?v=jGp4a00OeRs

I'm no C64 programmer so forgive me if I'm getting any of the details wrong.

I was recommended the video above, which is a modern game made for the REU (RAM Expansion Unit). I asked in a retro gaming forum what a game like that might need all the RAM for (assuming level data is stored on a ROM cartridge and can be retrieved quickly.) One suggestion was that it contains "pre-shifted" copies of graphics. This in turn got me thinking about background scrolling on the C64.

Reading up on the topic, it appears the only scrolling supported natively by the VIC, is a 0-7 pixel offset in X and Y. (Lower bits of $D011/$D016) If you want courser scrolling, you'll have to implement it in software by shuffling a whole row/column 1 byte in the appropriate direction, when you hit the end of the available range of the smooth scrolling. It seems like this is not necessarily a huge problem because you can also move the source in RAM for the BG layer using $D018. Effectively you can double (or more) buffer the changes so you don't have to apply the changes within a single frame.

But it makes me wonder, was there ever any hardware that sought to accelerate hardware scrolling? Such hardware would need a couple of things:
  • Enough memory to hold as much video matrix data as you wish to design for.
  • Some logic that translates requests coming from the VIC
The logic would figure out when the VIC starts reading from RAM, and whenever it has read 40 bytes, and translate that into a position in RAM with the X and Y scroll offsets added. There's obviously a bunch of specifics regarding how the C64 and the VIC works, but it seems like a feasible idea. In fact, to me, this seems like such low hanging fruit that I think that if it was possible, someone, somewhere must have attempted it. So, well, is it possible? Did anyone attempt it?
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Commodore 64 external hardware acceleration of smooth scrolling?

Post by NewRisingSun »

My impression has been that the C64 scene sneers at hardware add-ons to do graphical effects. There are several games that manage to create a very good impression of smooth scrolling with the existing hardware, so there must be clever programming ways to make it happen.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Commodore 64 external hardware acceleration of smooth scrolling?

Post by lidnariq »

The VIC-2 has a bug that can be carefully corralled that allows full-width X scrolling. They're all coaxed by telling/preventing the VIC-2 to start drawing when it wants to, which causes other bits of state to be not updated/updated multiple times.

A few writeups:
https://bumbershootsoft.wordpress.com/2 ... technique/
https://bumbershootsoft.wordpress.com/2 ... n-purpose/
https://www.linusakesson.net/scene/safevsp/
User avatar
cdoty
Posts: 24
Joined: Tue Jan 03, 2006 7:17 am
Location: Houston TX
Contact:

Re: Commodore 64 external hardware acceleration of smooth scrolling?

Post by cdoty »

The real problem is having the system decide what the full screen scrolling resolution is. Is it two screens horizontally, or maybe four, or maybe even 2 x 2? It's better to leave it to the programmer to decide. It's not terribly time consuming to copy 1k of data around for scrolling.

There is the C64DTV, which could be considered an add-on.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Commodore 64 external hardware acceleration of smooth scrolling?

Post by tepples »

CRTCs used in CoCo and IBM CGA have an explicit row offset setting, which controls the distance in bytes from the start of one row of tilemap to the start of the next.

Speculation: I imagine some old 8-bit home computers with unified memory don't attempt variable display pitch because they (ab)use the display circuit for DRAM refresh. If a machine organizes the frame buffer and RAM address lines so as to guarantee that all rows of RAM are always read at least once during each frame buffer scan, it doesn't need to steal extra cycles from the CPU just to refresh RAM.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Commodore 64 external hardware acceleration of smooth scrolling?

Post by Oziphantom »

https://beamracer.net/ is the only really one, C0pperdragon doesn't really add much if anything ( it might allow you to change the palette now ). For all new external hardware there is Megawang 2000 https://www.youtube.com/user/fnagaton

But you could do hardware scrolling offsets on a C64 with an external cart by abusing Ultimax Mode on VIC cycle which would allow you to visualize the VIC-IIs reads of Char, Screen and Sprite data. It's just that rows of 40 are a real pain to wrap around unlike the NES/SNES/MS 32 wide. So you would probably need to expand each row to 64 wide.

Shifting the screen + cram in a memory efficient way really eats the clocks and is the main reason C64 games lag behind NES one in terms of speed and action, having large instant bank carts is the 2nd one, but we have overcome that limitation now.

@Tepples, that is nice theory but a screen has to be linear in memory so a 1K/8K screen is not going to refresh all 32K/64K/128K/256K of RAM, it would work on something with say 1 or 4K I guess though. However machines that old tend to use Static RAM.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Commodore 64 external hardware acceleration of smooth scrolling?

Post by tepples »

If the column and row addresses are exchanged such that bytes with consecutive addresses are in different rows of the DRAM chip, then reading as many consecutive bytes from RAM as there are rows will refresh everything.
User avatar
Hojo_Norem
Posts: 137
Joined: Mon Apr 16, 2007 10:07 am
Contact:

Re: Commodore 64 external hardware acceleration of smooth scrolling?

Post by Hojo_Norem »

I can't say that I underatand all of it, but this is how the VIC-II does DRAM refresh according to Christian Bauer's VIC-II article 1996:

Code: Select all

3.13. DRAM refresh
------------------

The VIC does five read accesses in every raster line for the refresh of the
dynamic RAM. An 8 bit refresh counter (REF) is used to generate 256 DRAM
row addresses. The counter is reset to $ff in raster line 0 and decremented
by 1 after each refresh access.

So the VIC will access addresses $3fff, $3ffe, $3ffd, $3ffc and $3ffb in
line 0, addresses $3ffa, $3ff9, $3ff8, $3ff7 and $3ff6 in line 1 etc.

 Refresh addresses

 +----+----+----+----+----+----+----+----+----+----+----+----+----+----+
 | 13 | 12 | 11 | 10 |  9 |  8 |  7 |  6 |  5 |  4 |  3 |  2 |  1 |  0 |
 +----+----+----+----+----+----+----+----+----+----+----+----+----+----+
 |  1 |  1 |  1 |  1 |  1 |  1 |REF7|REF6|REF5|REF4|REF3|REF2|REF1|REF0|
 +----+----+----+----+----+----+----+----+----+----+----+----+----+----+
Insert witty sig. here...
mcmartin
Posts: 8
Joined: Wed Sep 29, 2004 8:22 pm
Contact:

Re: Commodore 64 external hardware acceleration of smooth scrolling?

Post by mcmartin »

It's worth noting that while Bauer's 1996 VIC-II article is pretty much the definitive guide for the VIC-II, it was written before the connection between the Horizontal/Variable Screen Positioning and the RAM corruption bug was understood. The text in Lft's demo in the above links goes into the full detail on it, and as far as I know, he's the one who discovered it back in 2012. But we do now know that that bug is intimately tied into the VIC-II's support for handling DRAM refresh.
cdoty wrote: Fri Dec 17, 2021 11:16 pm The real problem is having the system decide what the full screen scrolling resolution is. Is it two screens horizontally, or maybe four, or maybe even 2 x 2? It's better to leave it to the programmer to decide. It's not terribly time consuming to copy 1k of data around for scrolling.
If you're using VSP, you have something that's very close to one screen repeated in both directions, but there are glitches when you do. HSP shoves the screen to the right, but characters to the left of the "zero point" are the characters that, unscrolled, would have been on the previous line, so you need to do single-column copies not unlike what you'd need to do to scroll in the "wrong" direction on an NES with Horizontal or Vertical mirroring set. If you use techniques to abbreviate the vertical screen, it will loop with a half a line or so of garbage at the bottom that rounds out a 1KB spot (and which also may include sprite information).
laubzega
Posts: 1
Joined: Sun Mar 27, 2022 9:26 pm

Re: Commodore 64 external hardware acceleration of smooth scrolling?

Post by laubzega »

@nitro2k01: have a look at https://docs.beamracer.net/doku.php?id= ... _sequencer

The difference from what you're describing is that it is not really possible to translate VIC-II memory reads to new destinations in C64's DRAM, as address bus writes are done in two stages, and by the time you understand what VIC wanted to get, it is already too late to rewrite the bus with a translated address. BeamRacer thus fully overrides VIC's requests and redirects them to its own static RAM.

@cdoty: With a properly designed video sequencer screen organization is not an issue. See the doc above, or how 8-bit Atari or Amiga handle it.

@tepples: Some machines indeed relied on accesses done by video hardware reading screen content to also perform DRAM refresh. For example ZX Spectrum or Apple II. As for the C64, VIC-II handles DRAM refresh, but the refresh cycles are fully independent from other activities and thus also from the organization of video memory.

@oziphantom: On the contrary, machines that old tend to use DRAM, because it was (and is) much cheaper, and the price of RAM was an important factor at that time. C64 only has 0.5 KB (1024 4-bit nibbles) of SRAM for so-called color RAM.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Commodore 64 external hardware acceleration of smooth scrolling?

Post by Oziphantom »

laubzega wrote: Sun Mar 27, 2022 11:12 pm @oziphantom: On the contrary, machines that old tend to use DRAM, because it was (and is) much cheaper, and the price of RAM was an important factor at that time. C64 only has 0.5 KB (1024 4-bit nibbles) of SRAM for so-called color RAM.
I'm talking about the older machines relative to the C64, the ones that have 1-4K, the Atari 2600 with 128 bytes, the Commodore Max 2K, Commodore Vic-20 5K, the Commodore PET 4K, the Apple ][ 4K, the Atari 400, the KIM-1s etc I.e the computers that have 1-4K are SRAM not DRAM. Computers mostly got past the 4K barrier thanks to switching to DRAM.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Commodore 64 external hardware acceleration of smooth scrolling?

Post by Bregalad »

One suggestion was that it contains "pre-shifted" copies of graphics. This in turn got me thinking about background scrolling on the C64.
I'm unsure how you'd do that. A graphic tile can be pre-shifted, that's for sure, but then you have to pre-shift it's neighbour into it as well to make a new tile. Applying this concept to actual games with a high complexity of graphics sounds like infeasible.
Useless, lumbering half-wits don't scare us.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Commodore 64 external hardware acceleration of smooth scrolling?

Post by Oziphantom »

the X-rally port actually does this if you want an example.
Post Reply