Emulating the Atari 2600 on the VIC-20? Hear me out...

[RJBowman]

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.

[Mike]

The operation mode and capabilities of 2600 TIA and VIC-20 VIC-I chip are suitably different that any of your envisaged conversion processes are not going to work out.

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.

Even with the most simple games on the 2600, most of the scanline was used to execute code. The SYNC register was necessary as the horizontal positioning of objects depended on when exactly certain register writes where performed within the scanline.

There is no general method one could think of to convert 2600 binaries over to the VIC-20, exceptions confirm the rule: check out Imagic's Dragonfire and Demon Attack, and - more recently - Victragic's port of Pitfall! from 2013, all of which use programming methods quite similar to racing the beam on the 2600 to create the background graphics and multi-coloured hires(!) foreground characters on the VIC-20.

[beamrider]

What about a static conversion running on the PC?

edit: thinking about it that's not really possible too, you would need to understand and hand convert the code I guess even if trying to copy the scanline approach.

You would need to essentially run a 2600 emulator on what ever hardware you envisaged achieving this on generically. The Vic isn't powerful enough to do that, maybe the Amiga?

edit2: I can see a potential way forward with an external cartridge containing an ARM CPU, FPGA or similar running an atari emulator and writing to / reading from Vic memory, with the Vic simply providing joystick input and displaying an approximation of the 2600s screen. Whether this approach would count or prove anything, I'm not sure.

[Mike]

I can see a potential way forward with an external cartridge containing an ARM CPU, FPGA or similar running an atari emulator and writing to / reading from Vic memory, with the Vic simply providing joystick input and displaying an approximation of the 2600s screen.

You would throw resources at the problem whose capabilities and specs farly surpass those of the Atari 2600 or stock VIC-20 hardware, yet still arrive at an unsatisfactory result. VIC-I cannot overlay PM graphics objects over background in the way the TIA chip can, the VIC-I has only 16 colours instead of 128 colours with TIA, you would be missing a second joystick port, etc.

Whether this approach would count or prove anything, I'm not sure.

I would rather play those games on the original console, or on the PC in emulation which of course does not "count" but also neither does not need to "prove anything", because the capabilities of a current PC to emulate a 70ies game console can be taken for granted. In the latter case I still get a result with high fidelity, modulo some possible bugs in emulation that however have a high hope to get fixed.

In some cases, games may get a good port from 2600 to VIC-20, where the look of the TIA graphics can be kept on the VIC-I - I already mentioned Pitfall! as example, but it is also thinkable for other 2600 games. All attempts in that direction will in general require a thorough analysis of the display kernel to make a faithful VIC-I adaptation.

[beamrider]

Of course, you are correct.

The only benefit is that you would have a headline grabbing device that can plug in to a Vic and play 2600 games (in a fashion) finally materializing the mythical device from the 80s.

[chysn]

You guys got me reading about Atari 2600 development now.

[bjonte]

The Atari 2600 felt interesting to develop on until I understood that horizontal sprite positions can’t just be set by poking the position into a memory location. You can just instruct it to move -8 to 7 pixels or set it to the current horizontal raster position.

I’ll chime in and say that the problem with emulation are the sprites, sprite colors and collision detection. A lot of CPU time and memory needs to be spent on emulating these things on the VIC, which is completely free on the Atari. So any port would grow drastically in size and has to be tailored to deal with the important properies of each individual game to reach the 60 Hz frame rate. Audio is also problematic since the Atari can play two noice waves at the same time and the VIC is unable (unless dedicating all CPU to it).

[beamrider]

I don't think the Vic would be involved in the actual emulation, with the hardware approach anyway.

The way I see it, an ARM CPU would run the emulator rendering the output to something representing the Vic-20s display as best as possible, this would then be made accessible to the Vic either by monitoring address bus access like "Kung-Fu flash" or dual port ram or a low cost bridging FFPGA. The Vic for it's part would simply copy this "memory" to the internal memory accessible to the Vic-chip every frame using an unrolled loop. Actually, the arm CPU could even directly generate the necessary 6502 code to update the display (a diff-gram between frames) as well as the sound output using "wave-out" functionality that we have already seen in pulse, Bezerk MMX etc.

The second (or even both) joystick port(s) could be placed on the cartridge itself.

Of course, this is totally pointless - so I don't expect anyone would do this, but some people have made VGA outputs for the Vic which have additional enhanced graphics/sprites etc, which you could argue are equally pointless. At least this hack would open up additional software.

[English Invader]

The best emulation the VIC-20 can do is through direct ports. Even with its own software library, I still regard the VIC as one of the best systems for early 80s arcade games. There are a few shortcomings compared to the 2600 (particularly noticeable with a comparison between the Centipede ports for each system) but those flaws are only going to be exposed even further with an emulation attempt.

The BBC Micro (or even a Master 128) might be able to do a better job and that's another system with a very under-rated games library (including an arcade perfect port of Centipede).