51 replies to this topic

[Wickeycolumbus]

I recently put together a daughterboard that sits in a 2600's 6507 socket that allows a WDC65c02 to be installed in place of the 6507. The processor works fine and will run games, though with some bugs due to a slightly different instruction set.

My next goal is to get the processor running at the same speed as the TIA or faster. This will of course allow for better graphics, since you would have 228 cycles to play with per scan line instead of 76. I've done a preliminary experiment where I wired the OSC input of the TIA to the clock input of the 65c02, but all I get is a black screen. Assuming the TIA can handle access of it's registers at 3 times the normal rate, I can think of a few reasons I don't see anything on the screen:

* The ROMs of the original cartridges are too slow
* The RIOT chip can't handle the faster speed
* I misunderstood how to supply a clock to the 65c02

Does anyone have any advice as to how this can be done? Or perhaps experience with a similar project?

Of course, this is mostly for educational/experimental purposes.

[Rybags]

Regarless of that, the problem you have with any existing software is that practically all object placement on the screen relies on the CPU running at the 1.19 MHz speed.

I'd say - Rom speed not enough, definately a possibilty. They'd probably be fine up to 2.5 MHz or maybe a little more but 3.6 could be pushing things too far. If you check the 7800 specs, you'll see that Rom accesses are slower than to Ram (Maria does it's stuff @ around 7.2 MHz) and 7800 Roms are generally "newer" than 2600 ones.

RIOT speed - quite possible. RIOT is also used in 8-bit computer peripherals, not sure what the top speed is there. But you'd think it'd handle 2 MHz. As per ROM it could be that somewhere in the mid 2s is top of the line. On the 7800 RIOT accesses slow the CPU to 1.19 MHz.

What I'd advise - program an EProm that you know can handle 3.6 MHz equivalent read latencies. Either leave graphics stuff out or program something simple, of course making adjustment for the fact you're running at higher speed. Have it play some sounds as verification it's working.

You could get away with doing a simple program without need for Ram. Of course you're talking maybe playing some sound and having a static graphic that's done via hardcoded kernal loop.

ed - maybe just do something that hits TIA. A good example would be a simple colour bar generator that changes Background colour.

Edited by Rybags, Fri Aug 10, 2012 12:39 AM.

[carmel_andrews]

According to the atari musuem w/s the proto 2600 used a 6502 board and according to some site i saw a little while ago it also mentioned that atari had originally planned for a 6502 version of the 2600 but went for the 6507 instead....i guess that warners were trying to take on tramiel at his own game (i.e penny pinching)

edit, just found the latter site i was referring to

http://www.cpushack.com/tag/6502/

And here's the mention of the 2600's 6502 board

http://www.atarimuse.../proto2600.html

Edited by carmel_andrews, Fri Aug 10, 2012 6:15 AM.

[Rybags]

That's not really relevant, the speed is the same and a 6507 is essentially a 6502 die with less pins connected.
7800 in 2600 mode is still using 6502, it just has some tricks to present the same memory map as a 6507 would see.

The problem is that 3.6 MHz might be too quick for some of the chips.

Would some other speed combos be possible? I imagine 1.79 would go fine. how about 2.4, ie 2/3rds NTSC clocking?

[Gemintronic]

Speeding up existing games may be fun. What I'd like to see is something like the DPC+ and ARM assist developments with the Harmony board. What if you used the base 2600 to just draw the screen and collect information about switch settings and joystick input. Have the game code run off the faster processor for nifty tile engines and 3D vector graphics.

[Rybags]

Some sort of soft switch to change speeds would help lots with compatability, ie start up normal, have the option to set a register for quicker speed.
Existing games could then have hacks to do the speed change if more cycles are wanted in VBlank to increase game complexity.

Not that I'm a 2600 expert but I'd guess that running at 3x speed, practically no exisitng software would work at all. Setting HPos of objects is a cycle-exact exercise. Having alternate playfield graphics on the right hand side of screen depends on the correct amount of delay.
Games like Space Invaders use replicated Players and change the graphics registers at precise times. Modern advanced stuff like Boulder Dash is probably even more critical.

Edited by Rybags, Fri Aug 10, 2012 7:38 AM.

[Thomas Jentzsch]

I have to agree. Actually I would be surprised if any existing game would even remotely work.

Maybe it would be more possible to overclock outside the main kernel, but even there things like horizontal positioning would be broken.

[Keatah]

Speeding up existing games may be fun. What I'd like to see is something like the DPC+ and ARM assist developments with the Harmony board. What if you used the base 2600 to just draw the screen and collect information about switch settings and joystick input. Have the game code run off the faster processor for nifty tile engines and 3D vector graphics.

That's what I always thought. Use the original VCS hardware as an interface and output device. You could even push it to do real-time video.

[Wickeycolumbus]

Thanks for the input guys. I'm going to see if I have any higher speed ROM chips and burn a test program that doesn't use RAM. How do I calculate the minimum speed required?

And of course, I don't expect any existing games to work. I was just testing them because I had some laying around and thought I would be able to get at least some visual feedback from them.

[roland p]

I've done a preliminary experiment where I wired the OSC input of the TIA to the clock input of the 65c02, but all I get is a black screen.

Maybe this clock should be buffered first? My elecronics are a bit rusty, but isn't this a sine wave, and maybe the 6502 wants square waves?
In the tia schematic it is buffered: http://www.atariage...._tia/index.html (sheet 1, upper left)

It also seems logical to me that if the signal was a square wave the osc input of the tia would be called clk or something.

Its easy to tell if you have an oscilloscope.

Edited by roland p, Fri Aug 10, 2012 4:14 PM.

[Wickeycolumbus]

I've done a preliminary experiment where I wired the OSC input of the TIA to the clock input of the 65c02, but all I get is a black screen.

Maybe this clock should be buffered first? My elecronics are a bit rusty, but isn't this a sine wave, and maybe the 6502 wants square waves?
In the tia schematic it is buffered: http://www.atariage...._tia/index.html (sheet 1, upper left)

It also seems logical to me that if the signal was a square wave the osc input of the tia would be called clk or something.

Its easy to tell if you have an oscilloscope.

You're absolutely right, and that's probably why I get the same result with OSC hooked up to the clock input as I do with no CPU at all. So do I just put it through a couple inverters? Schmitt trigger maybe? Here is a screenshot of that section for anyone interested:

[SeaGtGruff]

You're absolutely right, and that's probably why I get the same result with OSC hooked up to the clock input as I do with no CPU at all. So do I just put it through a couple inverters? Schmitt trigger maybe? Here is a screenshot of that section for anyone interested:

The main problem you're up against is that the TIA's graphics are driven by polynomial counters or LFSRs, and the main counter-- the horizontal sync counter on sheet 1-- controls when the horizontal blanking is turned on and off, when the horizontal sync is turned on and off, and when the color burst is turned on and off. So if you're driving the TIA at 3-times normal speed by feeding it a faster OSC signal, the best you could hope to achieve would be a screen that's one-third as wide as normal, since horizontal blanking and horizontal sync will still be triggered on the basis of the horizontal sync counter, and it will be counting 3 times as fast as normal, so hsync will occur about a third of the way across the screen. That also means the hblank period will be one-third as long as it should be, hsync will be one-third as long as it should be, color burst will be one-third as long as it should be, and the color burst will not begin when expected.

[Wickeycolumbus]

Well, we're getting somewhere now I put the OSC signal through a single gate of a 74F14 and It seems to be working. I was able to run an older demo of mine, though of course it didn't run as it should. Here is a screenshot:



The (somewhat) steady HMOVE bars are a good sign.

Also, I figured since I had the camera out, I'd take a picture of my setup. There are a few other modifications done to the system, the CPU mod is the one right under the cartridge slot.

You're absolutely right, and that's probably why I get the same result with OSC hooked up to the clock input as I do with no CPU at all. So do I just put it through a couple inverters? Schmitt trigger maybe? Here is a screenshot of that section for anyone interested:

The main problem you're up against is that the TIA's graphics are driven by polynomial counters or LFSRs, and the main counter-- the horizontal sync counter on sheet 1-- controls when the horizontal blanking is turned on and off, when the horizontal sync is turned on and off, and when the color burst is turned on and off. So if you're driving the TIA at 3-times normal speed by feeding it a faster OSC signal, the best you could hope to achieve would be a screen that's one-third as wide as normal, since horizontal blanking and horizontal sync will still be triggered on the basis of the horizontal sync counter, and it will be counting 3 times as fast as normal, so hsync will occur about a third of the way across the screen. That also means the hblank period will be one-third as long as it should be, hsync will be one-third as long as it should be, color burst will be one-third as long as it should be, and the color burst will not begin when expected.

I didn't know about that, thanks for the information. I found an old [stella] post where Chris Wilkson described running both the 6507 and TIA at double speed and said that the screen was smaller. I never understood why though.

Since I'm running the TIA at the same speed, and only increasing the speed of the processor, I don't think this will be an issue. However, if I want to run the processor at more than 3.58 mhz, I may run into problems. Or perhaps I could just have two different oscillators?

[SeaGtGruff]

The main problem you're up against is that the TIA's graphics are driven by polynomial counters or LFSRs, and the main counter-- the horizontal sync counter on sheet 1-- controls when the horizontal blanking is turned on and off, when the horizontal sync is turned on and off, and when the color burst is turned on and off. So if you're driving the TIA at 3-times normal speed by feeding it a faster OSC signal, the best you could hope to achieve would be a screen that's one-third as wide as normal, since horizontal blanking and horizontal sync will still be triggered on the basis of the horizontal sync counter, and it will be counting 3 times as fast as normal, so hsync will occur about a third of the way across the screen. That also means the hblank period will be one-third as long as it should be, hsync will be one-third as long as it should be, color burst will be one-third as long as it should be, and the color burst will not begin when expected.

I didn't know about that, thanks for the information. I found an old [stella] post where Chris Wilkson described running both the 6507 and TIA at double speed and said that the screen was smaller. I never understood why though.

Since I'm running the TIA at the same speed, and only increasing the speed of the processor, I don't think this will be an issue. However, if I want to run the processor at more than 3.58 mhz, I may run into problems. Or perhaps I could just have two different oscillators?

I don't know if you can speed up the processor without speeding up the TIA. The 2600 feeds its 3579575 Hz oscillator signal into the TIA via the OSC pin. The TIA uses that input to get its CLK signal, then multiplies the lengths of the CLK pulses by 3 (thereby dividing the Hz rate by 3) and outputs it to the CPU as PHI_0. The CPU then uses the PHI_0 signal to generate its PHI_1 and PHI_2 clocks, and sends the PHI_2 clock back to the TIA. So the speed of the TIA controls the speed of the CPU. To speed up the CPU separately, you'd have to break the PHI_0 connection between the TIA and the CPU, or maybe feed it through some additional circuit to multiply the PHI_0 rate. As for two different oscillators, I take it you mean the second oscillator would generate the PHI_0 signal for the CPU? That might work, but you would probably have to sync the timing, so it might make more sense to somehow feed the original oscillator's signal to the CPU rather than have two oscillators. In any case, I'm not sure how the TIA would react to the faster PHI_2 signal coming back from the CPU. It would certainly make an interesting experiment!

[Wickeycolumbus]

The main problem you're up against is that the TIA's graphics are driven by polynomial counters or LFSRs, and the main counter-- the horizontal sync counter on sheet 1-- controls when the horizontal blanking is turned on and off, when the horizontal sync is turned on and off, and when the color burst is turned on and off. So if you're driving the TIA at 3-times normal speed by feeding it a faster OSC signal, the best you could hope to achieve would be a screen that's one-third as wide as normal, since horizontal blanking and horizontal sync will still be triggered on the basis of the horizontal sync counter, and it will be counting 3 times as fast as normal, so hsync will occur about a third of the way across the screen. That also means the hblank period will be one-third as long as it should be, hsync will be one-third as long as it should be, color burst will be one-third as long as it should be, and the color burst will not begin when expected.

I didn't know about that, thanks for the information. I found an old [stella] post where Chris Wilkson described running both the 6507 and TIA at double speed and said that the screen was smaller. I never understood why though.

Since I'm running the TIA at the same speed, and only increasing the speed of the processor, I don't think this will be an issue. However, if I want to run the processor at more than 3.58 mhz, I may run into problems. Or perhaps I could just have two different oscillators?

I don't know if you can speed up the processor without speeding up the TIA. The 2600 feeds its 3579575 Hz oscillator signal into the TIA via the OSC pin. The TIA uses that input to get its CLK signal, then multiplies the lengths of the CLK pulses by 3 (thereby dividing the Hz rate by 3) and outputs it to the CPU as PHI_0. The CPU then uses the PHI_0 signal to generate its PHI_1 and PHI_2 clocks, and sends the PHI_2 clock back to the TIA. So the speed of the TIA controls the speed of the CPU. To speed up the CPU separately, you'd have to break the PHI_0 connection between the TIA and the CPU, or maybe feed it through some additional circuit to multiply the PHI_0 rate. As for two different oscillators, I take it you mean the second oscillator would generate the PHI_0 signal for the CPU? That might work, but you would probably have to sync the timing, so it might make more sense to somehow feed the original oscillator's signal to the CPU rather than have two oscillators. In any case, I'm not sure how the TIA would react to the faster PHI_2 signal coming back from the CPU. It would certainly make an interesting experiment!

I wasn't very clear in my last post, the screenshot is of the TIA and 65c02 both running at 3.58 MHz. So it does work Actually, that screenshot has the clock inverted, so it doesn't look as it should. Here is a comparison between the two speeds:

Normal Speed in Stella. TIA 3.58 MHz, 6507 1.19 MHz



TIA 3.58 MHz, 65c02 3.58 MHz (with proper clock inversion):




The thing that worries me is that there is no sound in the demo, though there should be. I think this may have to do with the RIOT being too slow (I have to look at the code again, I wrote it in 2008). I may end up ditching the RIOT and putting in a fast VIA and ~8K of RAM to replace it.

The two oscillator idea was to get the processor running at a multiple of the TIA speed. For now, I will have fun with 3.58 MHz, then I will graduate to 3 or 4 times that if possible

Edited by Wickeycolumbus, Sun Aug 12, 2012 9:23 AM.

[SeaGtGruff]

The thing that worries me is that there is no sound in the demo, though there should be. I think this may have to do with the RIOT being too slow (I have to look at the code again, I wrote it in 2008).

The RIOT shouldn't have anything to do with the sound, aside from values being read from RAM and then stored in the audio registers.

I don't understand what the demo is supposed to be showing, but I have a few suggestions about testing the graphics and audio.

(1) Assuming the TIA (specifically, the horizontal sync counter) is running at normal speed, see how many color changes you can make per line. Turn off all graphics objects so the only color shown is the background, then draw a normal screen (standard timer values for the two portions of the vertical blank period-- 35 for the front porch [or 30 lines] and 43 for the back porch [or 37 lines]), but instead of using WSYNC during the active lines just set the timer again for 227 (or 192 lines), then start changing the background color for a while. If you load the CPU's A, X, and Y registers with three different color values, you can just STA COLUBK, STX COLUBK, and STY COLUBK over and over. You don't need to fill up the whole screen, just repeat those three instructions enough times to fill up a few lines, then poll the timer to see when it's time to start the vertical blanking again. If the instructions for the color changes are occurring at 3.58 MHz, you should get a color change every 3 color clocks.

(2) For the audio, just move immediate values to the audio registers so you bypass any use of RAM.

Edit: I don't know how fast you can go, but for me the ultimate dream would be at least 5 times the color clock rate. Then you could do LDA IMMEDIATE and STA COLUBK over and over (5 CPU cycles) and get any color at any pixel, although to draw a picture that way the color values would need to be stored within the ROM code as the immediate values for the LDA instructions.

Edited by SeaGtGruff, Sun Aug 12, 2012 12:53 PM.

[Wickeycolumbus]

Yeah, the reason the demo won't produce sound is that it fetches notes indexed by a RAM address. It plays the first note but gets stuck on it.

I wrote a color demo as you suggested, the accelerated system does in fact produce 3 pixel width color strips.

Run at normal speed:



Run at 3.58 MHz:



I'm worried that running the processor faster than the TIA will lead to issues storing to the registers, though I could be wrong. The 65c02 I have has a 'max speed' of 14 MHz. I may be able to go up to 4x TIA speed, but 5x will really be pushing it.

[SeaGtGruff]

Now that's a demo I can understand! I don't know what colors you're writing to COLUBK, but maybe it would have been a better suggestion to just alternate between two distinct colors-- like black and white-- so the color transitions are more obvious. Also, maybe do a set number of color changes per line, then WSYNC to finish out the line, so the color transitions line up vertically from line to line.

Anyway, this is looking awesome!

[Rybags]

Once you overclock high enough, you could just do all the graphics by changing the colour registers.
Of course it would just mean the 2600 becomes an oversized video generator, but could be fun.

[Wickeycolumbus]

Spent a good portion of this week wiring up another expansion board with a 32K EPROM, 8K RAM, 6522 VIA, and 64K serial EEPROM. Unfortunately the wires I used to connect it to the 2600 are too long and it isn't working... I knew that would happen. I'm going to redo the expansion board and use the cartridge port rather than the IDE cable I used for this one.

Just wanted to let you all know that I'm still working on this, hopefully I will have some better news soon

Edit: Added pictures. As you can see, some of the signals have to go through a fair amount of wire (10 inches or more). I've checked all the connections, and they are good.

Edited by Wickeycolumbus, Fri Dec 21, 2012 3:06 PM.

[Wickeycolumbus]

Got some better news I'm putting together a new expansion board that currently has a 32K EPROM and 16K RAM. The current memory map is:

TIA $0000 - $003F
RAM $0040 - $3FFF
ROM $8000 - $FFFF

I still need to add the VIA for controllers and timers. I plan on using some of the I/O pins to interface to a PC's parallel port. This will allow for quick code upload to the RAM chip for testing.

The 16K RAM is actually a 32K chip with A14 connected to Vcc. If possible, I may add a zero page hotspot to switch between 16K banks, allowing me more zero page RAM mid frame. Graphics could be stored in ZP RAM and quickly displayed on screen, adding the RAM bankswitch would effectively double the 192 bytes of usable ZP RAM.

Here are some pictures of the unit itself and a simple demo running. The demo has the same 3 pixel COLUBK writes as before, as well as two large colored sections displaying a color from RAM. The top color is incremented every frame (RAM address $0040), and the bottom is decremented (address $1000).

After I get the code uploader going, hopefully I will have some more interesting demos to show

[Wickeycolumbus]

Here are some pictures of the almost complete (for now) hardware. I'm having an issue with the 65c22 VIA, when I read the ports and display them using PF graphics, they flash on and off at a regular rate (about 1.5 seconds displayed, then about 1.5 seconds blank). Not really sure what the issue is, but when I get the chance I'll have to recheck everything and read the datasheet. Other than that everything seems to be working pretty well. I also added a 64K EEPROM that is wired like a SaveKey. I haven't tested it yet due to the VIA weirdness, but once that's figured out the standard SaveKey read/write routines should work with slight modification. The extra pin header seen on the expansion board is intended for the parallel port.



I had to cut a hole in the bottom part of the case to fit the processor upgrade in:

[Rybags]

This is looking cool, just one thing - it seems like the upgrade will be a bigger beast than the machine itself, would it be just easier to yank the TIA out and build on a custom board to replace the old one?

[Keatah]

This reminds me of when I spied on the Voyager 1 & 2 spacecraft with a homebrew radio telescope built with a MicroModem and my Apple II. Imagine the Apple II with 50 billion times the wires you got going.

[Wickeycolumbus]

This is looking cool, just one thing - it seems like the upgrade will be a bigger beast than the machine itself, would it be just easier to yank the TIA out and build on a custom board to replace the old one?

I do agree, but I have pretty limited experience designing PCBs. Getting a PCB made is definitely something I'd like to do in the future. The only thing on the original board that I'm using is the TIA (modified to only be accessible at $00-$3F) and the reset and select switches.