CPU upgrade?

[GameEngine]

I always considered VCS marvel at engineering but, at the same time, it was always to constraining for me so I settled for less perfect but much more capable Atari 800.

Some recently released VCS games seemed to achieve impossible. Quickly I found that some of the games have even more help from the cartridge than what was available back in the day in the form of Display Processor Chip (as used in Pitfall II). In those games it is ARM processor, hidden in Harmony / Melody cartridge, which does the heavy lifting and original CPU (6507) tries hard but can not really keep up. This led me to the following question:

Would it make sense to plug in Harmony-like expansion in place of the VCS original CPU?

[iesposta]

I think the 6507 still has to run the display kernel.

Even with using the ARM to run game logic, there are still only 76 cycles per line.

The original Pitfall DPC made a few routines use less 6507 cycles, such as drawing a single line, multi color player which used to take 12 cycles, DPC allowed that to happen in 7, and the new DPC+ implementation reduced that to 5 cycles. (I may have the actual values wrong.)

 

It is still an art to make games using the 15% idle time of the ARM because even Dracinian is only 32K, the largest size Atari ever used for 1 game released in 1990. Draconian does use extra RAM, but they started adding RAM to the carts in the early 80s.

[Thomas Jentzsch]

Technically TIA and 6507 are couple together closely. E.g. 3 TIA color clocks are equal to 1 CPU clock, TIA can control the CPU via WSYNC etc. So that alone makes replacing the CPU very problematic.

 

Also, even in ARM driven games, the ARM is still controlled by the 6507. While the ARM is doing calculations, the 6507 polls in a loop if the ARM is ready or not. It then consumes the input of the ARM and then calls (and polls) the ARM again. AFAIK there is no way that you can access the TIA or RIOT directly via cartridge port. So the 6507 is always required here.

[Mr SQL]

The 6502 still has to run the display kernel, but only to display what it thinks is a static image which gets manipulated at a high frame rate by the ARM (the heavy lifting).

 

The Atari 2600 games here work similarly but leverage display lists like the A8 but powered only by the 6502 and a software blitter instead of ANTIC, and the games are only 4K or 5K in size:

http://relationalframework.com/Atari2600gamesonline.htm

 

There's an interesting related discussion about adding the ARM to the A8 so that it can run batari BASIC DPC+ games here:

 

http://atariage.com/forums/topic/258924-2600-emulation-on-8-bit-computers/?p=3990727

 

[GameEngine]

...the new DPC+ implementation reduced that to 5 cycles...

Replacing the 6507 with ARM SOC would reduce this further to 1 cycle. Would it allow full 160x200 at 127 colors? If so, would it be to relieving?

 

AFAIK there is no way that you can access the TIA or RIOT directly via cartridge port. So the 6507 is always required here.

6507 is bottlenecking Harmony cartridge, so I was thinking about plugging ARM General Purpose I/O pins to the 6507 socket and emulating 6507 electrically (the same way it emulates intelligent memory in Harmony cartridge). AFAIK there are 31R/W + 1WO GPIO pins available in SoC used by Harmony and 6507 is 28 pins chip.

[Sheddy]

The (single colour) Playfield is still limited to TIA clock. Using players, missiles, ball for more resolution, might partially help, but much more complex, and again, still limited by speed of TIA writes. So, no 160x with 127 colours.

[Thomas Jentzsch]

In theory, if you could update the pflayfield or background color every color clock, then you could reach 160p/128 colors. But I am not sure if the TIA can handle it that way. E.g. there are delays (IIRC 2 color clocks) for each update which might interfere with the next update.

[Sheddy]

would be interesting to see if TIA can work that way. Wonder if Spiceware and Harmony driver writers have experience here. Would be "cheating", but movie playback without "jailbars" would be cool nonetheless.