What if VIC had SALLY instead?

[rhurst]

I read about the 7800 having a 6502C named SALLY, and it was clocked at 1.79 mhz (yeah, yeah, it clocked down to 1.19 during "TIA" time). So, 1.79 / 1.02 = 175% for NTSC.

So just for giggles, I ran Berzerk MMX at 175% speed on latest xvic build -- wow, still very playable and it makes for some interesting and cool sound effects at the higher rate.

I realize the "fps" also increases which would be unfeasible for a gaming console of that era, so I merely told it to refresh every other (1/2) and got 52-fps (trying to tweak it to a custom value does some strange things).

Playing some of my other VIC games with a SALLY in place did change the dynamics quite a bit... makes me wonder what if VIC had SALLY instead?

[Mike]

The CPU still would get its 1 MHz from the VIC chip, so you won't notice any speed difference.

[Centallica]

If Vic had Sally, she's be one sore gal

[rhurst]

Yeah, this was a fantasy discussion topic only, not a technical one by any stretch ... I thought it was fitting in this forum index, because this "what if" can only be "realized" via emulation to see the effect. Despite the "" and before I get corrected, I know, I know... it's not an accurate representation of real hardware if tweaked in this manner.

But talk about both ends of the curve with the replies... one is literal and the other is, well, left for another kind of imagination.

I, for one, was rather pleased to get a 2mhz "6502" variant in C128, despite being useful only in 80-column mode (I know, I know, there were many raster-interrupt utilities that gave a 20%+ speed increase souping up 40-column mode by switching between 1mzh / 2mhz during the outer top-bottom border draw), or using FAST / SLOW in my BASIC Quick sort routine to print out my bowling league standings and stats at incredible sub-5 second speeds!! At the time and not knowing much about the intricacies behind chipset clock timings, it made me wonder why there wasn't a more pressing call to improve (appreciably) upon processor speed in the C= line of home computers.

I am only trying to imagine the possibilities with VIC and VIC-II having an option of being 50%, 75%, or 100% faster. I am certain there were a lot of incompatibility concerns, especially with peripherals, and production cost justifications for not pursuing it.

BTW, I recall a vague 3rd party SuperCPU cartridge-based option that ran at like 4mhz or 8mhz even, in the late 1980s? If so, how did that integrate with the rest of the bus, or was it simply for niche applications switching into some "turbo code execution" purposes only when not using any of the native chipset?

[Mike]

If so, how did that integrate with the rest of the bus, or was it simply for niche applications switching into some "turbo code execution" purposes only when not using any of the native chipset?

Indeed, the 65816 had an own copy of the C64 memory, including the ROM chips. Only when the new CPU had to talk to I/O registers, it needed to be slowed down (or synchronised) to the 1 MHz clock. There also was a mechanism to keep the internal RAM in sync so the VIC-II would display the correct data nonetheless.

BTW, in my VIC-20 I happened to find a 6502B, which is capable of running at 3 MHz - i.e. it is underclocked. Supposedly Commodore just used every 6502 they got, regardless of its rating.

Now you could imagine the following scenario: clock the 6502 at 3 MHz, but leave out every 3rd cycle, so the VIC chip has a complete 500 ns half-cycle available to its own:

Code: Select all

      +--- CPU ---+
      |           |
      V           V

   +-----+     +-----+                 +-----+     +-----+                 +---
   |     |     |     |                 |     |     |     |                 |
   |     |     |     |                 |     |     |     |                 |
   |     |     |     |                 |     |     |     |                 |
---+     +-----+     +-----------------+     +-----+     +-----------------+

                             VIC 
                              |
                              V

---+                 +-----------------+                 +-----------------+
   |                 |                 |                 |                 |
   |                 |                 |                 |                 |
   |                 |                 |                 |                 |
   +-----------------+                 +-----------------+                 +---

   |<-------------- 1 µs ------------->|

Result: the VIC-20 would run at twice its normal speed. And screw up all cycle-exact routines.

That idea had been realised for the C64 before, and was published in a German computer magazine (64'er, issue 2/94). They needed to replace the DRAM by SRAM, and also the 6510 was replaced by a 6502 with an external port simulation circuit.

In principle, that mod easily transfers to the VIC-20, even though its SRAMs should also be replaced by faster ones, like those I took for my VFLI mod.

[Jeff-20]

SALLY allowed a billion objects to move on screen at once. Look at Robotron on the 7800. That's hot.

[Mike]

SALLY allowed a billion objects to move on screen at once.

No. In the 7800, the display of sprites was done by MARIA.

[rhurst]

Mike, per usual, an awesome explanation and backed by references, too. Impressive!

I personally could really care less about screwing up cycle exact routines, but understanding that you mean throw "software compatibility" in a lot of cases out the door. Like Jeff, I would care to have a VIC capable of moving 100 objects (not pixels) at once. Faster "arcade" action is always desirable, and BASIC becomes a bit more attractive.

[Mike]

you mean throw "software compatibility" in a lot of cases out the door.

But also no problem for new software. In any case, such a mod should provide a switch back to 1 MHz.

I'm also not quite sure how the VIAs would handle the increased speed, especially accesses to their registers. In the article I mentioned above, there was no indication that the CIAs had problems, so this might be a good sign.

I would care to have a VIC capable of moving 100 objects (not pixels) at once.

You run into memory bandwidth limits very quickly, which is the reason most video chips restricted the maximum number of sprites visible in a raster line to 8 or 16:

As an example: the VIC-II needs to read 4 bytes for each displayed sprite in a line, 1 byte for the sprite pointer, and 3 bytes actual sprite data. 8 sprites -> 32 bytes per line. These accesses are stolen from the 6510 during the horizontal retrace, and are already done at 2 MHz!

In a 'bad-line' the VIC-II steals another 40 cycles from the processor to read the screen RAM, plus the normal 40 cycles accessing the character data we end up at 32+40+40 = 112 cycles at 2 MHz, i.e. a bus utilisation of 56 µs. Which just leaves 7 or 9 cycles free for the 6510 in a 'fully populated' raster line of 63 µs (PAL) or 65 µs (NTSC)!

Unlike the VIC-II which caches the screen and colour RAM for a whole text line, the VIC re-reads the screen and colour RAM on every raster, so rasters on the VIC-20 are always a 'bad-line' - but the necessary bandwidth for each line is only half, and so the 6502 doesn't need to be stalled. There's not much that can be done about the screen RAM accesses, but with the colour RAM my VFLI graphics mode employs this to advantage: it switches to a different colour RAM bank on each raster and so increases attribute resolution to 8x1 pixel cells.