Emulating the Atari 2600 on the VIC-20? Hear me out...
Posted: Wed May 25, 2022 3:36 pm
Something I've put some thought into. Circa '81, when the VIC-20 was gaining traction, but games were scarce, Protecto Enterprises, who had Hong Kong connections and sold things like VIC-20 80-column cards, ran an ad in computer magazines offering something called an Atari Game Loader for the VIC-20. The product doesn't seem to have ever materialized.
This would have been a dream come true for VIC owners. The device would make hundreds of games available. The description "loader" implied that it loaded the game into the VIC-20's memory; possibly converted it to run with the Commodore hardware. Maybe you would be able to save it to tape and trade tapes with friends.
The inner workings of Atari's console are more publicly known now. It was very different from how the VIC20 works; games could not simply be converted through automation. If the device really existed (I never read a review, but I remember a mention in Compute! magazine that suggested that Compute!'s staff had access to one), it would have contained hardware copied from Atari's design. The 2600 produced a single scan line of graphics; 40 horizontal regions of background pixel mapped to 20 bits of RAM (it could either repeat to the left and right sides of the screen, mirror at the halfway point, or be altered by the CPU at the halfway point). It had a couple of 8-bit wide player sprites which could each be duplicated two or three times along the scanline, and a 2 2-pixel-wide "ball" sprites and 2 1-pixel-wide "missile" sprites. If left at a single setting, these would produce vertical patterns from the top to the bottom of the screen, but to produce useful game graphics, they had to be changed every scanline.
Which seems drastically different from the VIC-20, except I've seen the VIC do things like that in demoscene demos. I've seen demos that use the vertical positioning register to position the same horizontal line of graphics all over the screen. If it were possible to write code to convert the 2600's background and sprites into a line of VIC-20 graphics during the blanking interval, 2600 emulation might be possible....however...
I don't think that the VIC-20 is quite fast enough. It would have to do that instant graphic conversion at the same time that it was running the original Atari game's code. There just wouldn't be enough CPU cycles.
But...
There is a tantalizing possibility that some of the simplest (and probably earliest) Atari games could be made to work on the VIC-20 this way. The Atari graphics hardware controlled the CPU; there was an interrupt every scanline. A piece of game code was activated by the graphics hardware each scanline, and that bit of code ran, and if there was any time left, the CPU sat idle for the remaining cycles until the graphics hardware woke it up again. Enough unused cycles to convert the graphics to VIC-20? If the graphic conversion code could be pushed to the absolute limits of optimization, maybe it could happen.
It would be a hell of a demoscene demo.
This would have been a dream come true for VIC owners. The device would make hundreds of games available. The description "loader" implied that it loaded the game into the VIC-20's memory; possibly converted it to run with the Commodore hardware. Maybe you would be able to save it to tape and trade tapes with friends.
The inner workings of Atari's console are more publicly known now. It was very different from how the VIC20 works; games could not simply be converted through automation. If the device really existed (I never read a review, but I remember a mention in Compute! magazine that suggested that Compute!'s staff had access to one), it would have contained hardware copied from Atari's design. The 2600 produced a single scan line of graphics; 40 horizontal regions of background pixel mapped to 20 bits of RAM (it could either repeat to the left and right sides of the screen, mirror at the halfway point, or be altered by the CPU at the halfway point). It had a couple of 8-bit wide player sprites which could each be duplicated two or three times along the scanline, and a 2 2-pixel-wide "ball" sprites and 2 1-pixel-wide "missile" sprites. If left at a single setting, these would produce vertical patterns from the top to the bottom of the screen, but to produce useful game graphics, they had to be changed every scanline.
Which seems drastically different from the VIC-20, except I've seen the VIC do things like that in demoscene demos. I've seen demos that use the vertical positioning register to position the same horizontal line of graphics all over the screen. If it were possible to write code to convert the 2600's background and sprites into a line of VIC-20 graphics during the blanking interval, 2600 emulation might be possible....however...
I don't think that the VIC-20 is quite fast enough. It would have to do that instant graphic conversion at the same time that it was running the original Atari game's code. There just wouldn't be enough CPU cycles.
But...
There is a tantalizing possibility that some of the simplest (and probably earliest) Atari games could be made to work on the VIC-20 this way. The Atari graphics hardware controlled the CPU; there was an interrupt every scanline. A piece of game code was activated by the graphics hardware each scanline, and that bit of code ran, and if there was any time left, the CPU sat idle for the remaining cycles until the graphics hardware woke it up again. Enough unused cycles to convert the graphics to VIC-20? If the graphic conversion code could be pushed to the absolute limits of optimization, maybe it could happen.
It would be a hell of a demoscene demo.