Jump to content
mytek

Overclocking the Stock 6502c: Is it Possible?

Recommended Posts

Seems to be a custom and improved version of the WDC 65C02, so would have been somewhat less powerful than the 65816 as per SNES and Apple IIgs.

But the graphics and sound are pretty good - I remember getting into some of the games by emulation.  They were OK but the system suffered from a lack of recognised titles as well as poor marketing and not so good timing where it was fairly quickly surpassed by the likes of SNES and Sega Megadrive/Genesis.

 

Just the name of the thing didn't help either - Turbographx 16 was seen as misleading, and in other markets (such as here) it was called The PC Engine which was confusing at best.

 

Not sure I've ever seen a real one up close.

Share this post


Link to post
Share on other sites

I have not found my 7/14mhz stuff yet...

 

Basically, your cycle starts with PH02 going low. One of the chips will drive an address onto the buss, either ANTIC (HALT is active) or CPU (HALT is inactive). If the CPU is accessing SRAM, you pull PH02 high at the first clock (70ns at 7mhz) and them back to low after another 70ns. Anything else has to be aligned with the 1.79 master clock at fall of PH02 and changes state at 280ns.

 

You can see that going to SRAM and then to anything else will take two full cycles - you only get to go fast when SRAM is accessed consecutively.

 

If I find my stuff, I'll post it here. I don't think there is a schematic. There is no logic, just a 22V10 or some such. Bunch of wires go in, bunch of electricity comes out.

 

Bob

  • Like 3

Share this post


Link to post
Share on other sites
7 hours ago, mytek said:

If believe that Rybags is correct on the limit for Sally being 2.5 Mhz, so I might switch over to a 65816 as I take this farther. It's fairly trivial to allow for the use of the /HALT line to tri-state this device, and of course there is no limitation on the clock speed as compared to the Sally. 

 

  

Well even some (non-Sally) 6502s can run pretty fast...

http://forum.6502.org/viewtopic.php?f=4&t=5368

Edited by foft
  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, ZuluGula said:

How does TurboGrafx HuC6280 works? It's a custom 6502 that operates at 1.79 MHz and 7.16 Mhz.

 

4 hours ago, Rybags said:

Seems to be a custom and improved version of the WDC 65C02, so would have been somewhat less powerful than the 65816 as per SNES and Apple IIgs.

But the graphics and sound are pretty good - I remember getting into some of the games by emulation.  They were OK but the system suffered from a lack of recognised titles as well as poor marketing and not so good timing where it was fairly quickly surpassed by the likes of SNES and Sega Megadrive/Genesis.

 

Just the name of the thing didn't help either - Turbographx 16 was seen as misleading, and in other markets (such as here) it was called The PC Engine which was confusing at best.

 

 

It's hard to understand the HuC6280 in isolation, because it's part of a completely custom-designed integrated 3 chip solution for a video-game console/computer (with the HuC6270 VDC and HuC6260 VCE).

 

The HuC6280 is a complete re-implementation of the 65C02 architecture that was never designed as a 6502 replacement/upgrade, so you can't easily compare how it operates to any of the original NMOS 6502 variants, or to WDC's 65C802/65C816.

 

For instance, it has a single 21.477MHz clock input (with internal dividers down to 1.79MHz & 7.16MHz), built-in 2MB memory manager (eight 8KB pages in the 6502's 64KB address space), block move instructions with 1MB/s transfer rate, other new instructions that make programming more pleasant, plus built-in 6 channel wavelet-based sound chip.

 

One of its big hardware improvements was that the memory accesses are full-cycle, so it runs the same 120ns speed RAM as the SNES, but it does a read/write cycle at 7.16MHz per byte access, instead of the SNES's 2.68MHz per byte access.

 

From an assembly-language programmer's POV, it's as-fast-or-faster (in practical usage) than the 65C816 in the SNES and Apple IIgs ... you just don't get the 16-bit CPU registers, or the stack addressing.

 

I worked on both the SNES and Megadrive in the 1990s, and have no desire to work on either of those architectures ever again ... whereas the PC Engine is an absolute joy to program (I'm the current maintainer of HuC, the PCE's equivalent to CC65).

 

P.S. While the PC Engine / TurboGrafx was a spectacular failure in the USA, and was never officially marketed or sold anywhere else but its home market of Japan. It's worth noting that it outsold the Megadrive in Japan, and has hundreds of high-quality titles that most Western gamers aren't aware of.

 

P.P.S. While the marketing folks, and gamers too, thought that the "16-Bit" generation was in reference to the CPU, developers and hardware folks at the time knew that it was in reference to the transition of the video chips from 8-bit data bus bandwidth, to 16-bit data bus bandwidth, allowing the shift from 2-bits-per-pixel (4 color) to 4-bits-per-pixel (16-color) at the same resolution.

 

 

Anyway ... back to the Atari, my other favorite machine. ;-)

 

  • Like 3

Share this post


Link to post
Share on other sites
17 minutes ago, elmer said:

I'm the current maintainer of HuC, the PCE's equivalent to CC65

Interesting. How is HuC's code quality compared to CC65?

 

Edited by ivop
typo

Share this post


Link to post
Share on other sites
2 hours ago, bob1200xl said:

If I find my stuff, I'll post it here. I don't think there is a schematic. There is no logic, just a 22V10 or some such. Bunch of wires go in, bunch of electricity comes out.

 

So I take it that you never breadboarded any of this before going with a CPLD?

 

Actually unless I'm mistaken there is still logic, boolean to be exact.

 

 

2 hours ago, Larry said:

Appears they are archived at the Internet Archive.

 

Volume 3, Number 3 is the issue that I was referring to:  https://archive.org/search.php?query=atari classics

 

Bob's article is on page 34.  This is where he discusses technical issues with doing what you suggest.

 

Thanks, I'll check it out.

 

Share this post


Link to post
Share on other sites
23 hours ago, mytek said:

I'll have to check that out. It certainly looks intriguing, but if it is to be used for our A8 systems it would need to also support the HALT line to pull itself off the bus.

 

It supports RDY, which I assume is your HALT line?  If so, as long as you adhere to the 6502 timing requirements (pulling it low during PHI1) then it should have no problem.

 

I actually control PHI1 and PHI2.  I can change these asynchronously to the PHI0 to increase the speed of the 6502 without needing a faster external clock.  That is one method of operation, which seems might work pretty well with the Atari if it has 15ns RAM (as stated above).  Otherwise, with the 65xxT you set accelerated/non-accelerated regions that you want.   This is to allow things like VIAs to operate at their normal clock speed.  You can also move any ROM into the 65xxT's internal memory map so that it is always accelerated.  There is 32K of cache memory and the zero page and stack can always be (or never be) cached.

 

It's pretty fast, with the ability to execute up to 8 complex instructions within 1us.  A single complex instruction normally requires 6+ cycles.

 

Currently, the 65xxT supports the NMOS version and all of my testing so far has been done with the Commodore 1541 disk drive.  So, all illegal opcodes are supported.  I am currently working on obtaining information for the hundreds of various stand-up arcade machines because this can be used as a diagnostics tool to test RAM/ROM/Peripherals (who knew?).  I plan to add support for the 65C02 as well as make different pinout versions for the 6510, 8502, and a couple of other 6502 variations.  This same design will also be spun into a version for the Z80 and 6809E.

The board uses a dual core 190MIPs microcontroller, with the code written in hand optimized assembly.

 

I will say that I do have an Atari 400, 800, and 800XL here - but I have only looked at them enough to know where the 6502 is physically located to make sure that the 65xxT will fit.  Other than that, I couldn't tell you how to boot a disk with an Atari system.  :)  I do have a couple of 1050 drives though should I get brave enough to try!  My focus has not been on Atari systems, but I will doing some testing when I get some free time.

 

I plan to release this at CRX 2019, to be used with Commodore 1541 disk drives, and VIC-20s... maybe more system (Apple II, Atari, etc.) by then?  We shall see.

 

 

Edited by JimDrew
  • Like 4

Share this post


Link to post
Share on other sites

/RDY isn't suitable as a replacement for Halt, BA etc since the 6502 ignores it if it's performing consecutive write operations.

  • Like 2

Share this post


Link to post
Share on other sites

Hello,

Technically a bit of topic.

And I've made the assumption that Bob has no objections, as he offered to look for some stuff.

A while ago, Bob has done some significant speedup of a 1200XL.

And I've tested it on the 600XL, 800XL and 130XE. It worked on all boards. !

But I don't recall ecactly what's what.

And I also tried to get it to work at 14Mhz and include the OS and Basic-Roms and XE-GS ones as fast Rom.

It didn't work and I should have bought a logic analyser to get it to work.

Never done that or spend enough time....

 

BR/

Guus

Speedy816_Bob_Wooley.zip PCBS.zip SCH.zip

  • Like 7

Share this post


Link to post
Share on other sites
6 hours ago, guus.assmann said:

Hello,

Technically a bit of topic.

And I've made the assumption that Bob has no objections, as he offered to look for some stuff.

A while ago, Bob has done some significant speedup of a 1200XL.

And I've tested it on the 600XL, 800XL and 130XE. It worked on all boards. !

But I don't recall ecactly what's what.

And I also tried to get it to work at 14Mhz and include the OS and Basic-Roms and XE-GS ones as fast Rom.

It didn't work and I should have bought a logic analyser to get it to work.

Never done that or spend enough time....

 

BR/

Guus

Speedy816_Bob_Wooley.zip 22.89 kB · 4 downloads PCBS.zip 671.41 kB · 5 downloads SCH.zip 258.18 kB · 4 downloads

 

Not off topic as far as I'm concerned. Thanks for uploading 👍 .

 

I know this topic started out as an overclocking of the original Sally chip, but more and more that isn't looking to buy us much. So now it's morphed into changing processors to do acceleration, while still looking at an old school approach with the control logic, all the while attempting to keep the costs reasonable (not a lot of bells and whistles).

 

The information you provided appears to confirm what was talked about in the Atari Classics magazine article, where the 6502 is retained along with the addition of the 65816. Actually I'd just like to see a 65816 flying solo with a moderate speed up, and of course have the ability to downshift to 1.79 Mhz full time any time desired. Part of the plan would be to stick with 64K base RAM being shared, although that would be better served with higher speed static RAM. Since the 1088XEL and the soon to be released 1088XLD have fast SRAM already, that will be my initial target platform for any prototyping I'll be conducting. Please keep in mind that this is just a for fun exercise, so there might not be an end product coming out of this from my end, although the intention is to share methodology being applied in the experiments to follow.

 

  • Like 4

Share this post


Link to post
Share on other sites
10 hours ago, Rybags said:

/RDY isn't suitable as a replacement for Halt, BA etc since the 6502 ignores it if it's performing consecutive write operations.

Was this directed at me?  The 6502 only has RDY as a means to halt it.  I will have to take a look at the Atari schematics to see how/why they are needing to take the 6502 off the bus.

 

BTW, I can make the 65xxT support the 65816 instructions by just changing the firmware.  This is something that I will be doing for David Murrary's project, now that it has gone to a 6502.

 

  • Like 2

Share this post


Link to post
Share on other sites
34 minutes ago, JimDrew said:

Was this directed at me?  The 6502 only has RDY as a means to halt it.  I will have to take a look at the Atari schematics to see how/why they are needing to take the 6502 off the bus.

 

BTW, I can make the 65xxT support the 65816 instructions by just changing the firmware.  This is something that I will be doing for David Murrary's project, now that it has gone to a 6502.

 

Because ANTIC (the graphics display list processor) needs access to the bus. It’s why the Atari machines are clocked at 1.79MHz instead of the 1MHz typically used by its competitors of the era. 

  • Like 1

Share this post


Link to post
Share on other sites

I've run an 800xl at 2.12 MHz. You really get to know the problems that come with even a small change in clock rate. The ANTIC/GTIA is already at the limit for sync pulse width. Any speed increase will shorten the sync pulse to the point where the video goes unstable. It isn't tough to stretch the pulse, I just used a gate with a cap/resister to get it back, but everything is still kind of screwed. The display gets narrowed and mischief going on outside of what is normally displayed becomes visible on the margins.

 

Just about everything is changed since everything uses the system clock. I mean stuff like SIO timing, sound, et al. Things you take for granted like setting sound and doing other stuff, well the sound is off by whatever the speed increase is. It even changes things like keyboard scanning IIRC.

 

I don't think it is an insurmountable problem, just that most of the simple solutions end up being not good enough. For example, you could use a chip like a 6551 that uses its own crystal for timing, but then you have to rewrite the OS and maximum SIO speed will be 19k. You could still use the existing POKEY, but then you would have to change all the divisors while the fast clock was active. 

 

I think you could get an increase in speed running the processor faster via some constraints like Bob did. Something like only enable the high speed clock to the processor during the VBI while the system clock used for everything from determining when to do a VBI to sound pitch stays the same. No joke, I just used two wires touched together to switch processor speeds and it worked consistently w/o crashing. If you had the processor running at double speed during the VBI, well obviously you could do twice as much work.

  • Like 4

Share this post


Link to post
Share on other sites

Ever since the Uno Cart, I have been thinking about creating a testboard and a 40 pin flat cable to the CPU socket and have it emulate a 6502c instead of a cartridge. The ARM processor used is fast enough to monitor the bus. If you consider the 6502 state machine, it should be possible to implement every clock cycle it does and be 100% compatible.

 

After that, you could add a mode where it runs faster by using the ARM's internal RAM and disable the Atari RAM completely. Similar to the Uno Cart, it can serve its RAM contents to ANTIC if it pulls /HALT down and wants to read the screen memory.

 

ROM can be put inside the ARM, too. The only time you would have to slow down is when you are reading/writing hardware registers.

 

And/or you could optimize the implementation of the opcodes (less states/combine states) so they take less clock cycles.

 

And you could load another core and have a Z80 based Atari computer, or another CPU. Or even run plain ARM (thumb) code and drive ANTIC/GTIA and Pokey as fast as you can :)

  • Like 3

Share this post


Link to post
Share on other sites

If you click through, you end up here:

 

https://en.wikipedia.org/wiki/Renesas_740

 

Besides mul and div, this: 

 

A special read-calculate-write mode can be enabled that allows the results of arithmetic operations to be stored in any Zero Page location as opposed to the accumulator. The Zero Page address is controlled by the Index X register.

 

is also pretty interesting.

 

But those chips have on-board RAM and (P)ROM and seemingly no way to extend that. Most pins are I/O ports. Definitely aimed at the embedded market and no way to adapt it to the Atari, i.e. no address- and databus. You can still buy them from Renesas. They are not recommended for new designs though ;)

 

But, thanks tebe. Never heard of these MCUs before!

Edited by ivop

Share this post


Link to post
Share on other sites
4 hours ago, ricortes said:

I think you could get an increase in speed running the processor faster via some constraints like Bob did. Something like only enable the high speed clock to the processor during the VBI while the system clock used for everything from determining when to do a VBI to sound pitch stays the same. No joke, I just used two wires touched together to switch processor speeds and it worked consistently w/o crashing. If you had the processor running at double speed during the VBI, well obviously you could do twice as much work.

This I find very interesting 🌝 .

 

How did you determine when a VBI was active? So when you say you touched 2 wires together to shift clock speeds without glitching the system, how was that actually done in reality? Diagram?

 

Share this post


Link to post
Share on other sites
3 hours ago, ivop said:

https://en.wikipedia.org/wiki/Renesas_740

 

A special read-calculate-write mode can be enabled that allows the results of arithmetic operations to be stored in any Zero Page location as opposed to the accumulator. The Zero Page address is controlled by the Index X register.

 

 

The HuC6280 copied that read-calculate-write mode from the original 1984 Mitsubishi 740, but unfortunately, only with the ADC, AND, ORA and EOR instructions, and not the SBC, LDA and CMP instructions.

 

I've had a hard time finding a practical use for the capability in my code. I had thought of using the instructions to help with math on a software-stack in zero-page, but they didn't seem to help much.

 

If anyone has a better idea for using that capability, then I'd love to hear it.

 

  • Like 1

Share this post


Link to post
Share on other sites

How about a fast replacement CPU card for the original 800 that works with Incognito? That would be great. Is there any space left on the card to incorporate a VBXE?

:)

 

Share this post


Link to post
Share on other sites

My 65xxT just might be ideal for the Atari machines.  You can set speed to be normal during any hardware accesses (mapped to whatever I/O addresses are needed).  Taking the CPU off the bus (Z-stated) when forced to via the RDY signal is already supported, so there should be no issues with anything that needs the bus for access video memory.

 

Since I control PHI1 and PHI2, those can actually follow the normal PH0 relationship, but multiple instructions can be executed (in a single PHI0 cycle) from internal memory when they don't require any slow down.  So, the 65xxT is actually a variable speed CPU.

 

 

 

Edited by JimDrew
  • Like 1

Share this post


Link to post
Share on other sites
10 hours ago, mytek said:

Hold your horses 🦙!!!

 

This looks like what I'm wanting.

Bob's bare-bones 7.16Mhz accelerator .

 

Bobs_Simple_Accelerator.png.fe03c4586b8ecdae7731619d43d7f21b.png

 

Bob can we get a schematic and the PLD code?

 

Is this what you called the XL7?

 

The XL14 is more flexible -- supports hard drives, etc. PAL folks say it is not stable at 14 MHz, but my ntsc system is/was 99% in XL14 mode,  100% in XL7 mode. I think the last cpld version was M? (If you're going to go, go fast or go home!)  🙂

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, Larry said:

The XL14 is more flexible -- supports hard drives, etc. PAL folks say it is not stable at 14 MHz, but my ntsc system is/was 99% in XL14 mode,  100% in XL7 mode. I think the last cpld version was M? (If you're going to go, go fast or go home!)  🙂

 

That's just it, I'm not looking for all the extras. I already have those features with the built-in U1MB and IDE on my 1088XLD, so just looking for a simple as possible accelerator. And at 4x the normal clock speed, I think that's nothing to sneeze at. However without more information to go on, I'm left wondering if the XL7 would be compatible with my existing hardware, because I strongly suspect that it wasn't built with that in mind, so there may be conflicts.

 

Bob's XL7 is also something that better fits the DIY aspect, which is the core requirement of everything I develop for the A8. If he is willing to release the design, I can do a new PCB layout to fit my purposes, while still giving full credit for the concept to Bob.

 

  • Like 4

Share this post


Link to post
Share on other sites
8 hours ago, JimDrew said:

My 65xxT just might be ideal for the Atari machines.  You can set speed to be normal during any hardware accesses (mapped to whatever I/O addresses are needed).  Taking the CPU off the bus (Z-stated) when forced to via the RDY signal is already supported, so there should be no issues with anything that needs the bus for access video memory.

 

Since I control PHI1 and PHI2, those can actually follow the normal PH0 relationship, but multiple instructions can be executed (in a single PHI0 cycle) from internal memory when they don't require any slow down.  So, the 65xxT is actually a variable speed CPU.

 

Your board also looks very promising, but before it will work on an Atari it would need to fully support the /HALT line for Hi-Z the same as is presently done on these systems. You might not realize that the Atari 8-bit computers employed a custom 6502c CPU often referred to as Sally that would take the address and data off the bus when this signal went low, and halt any internal activity. This allowed the custom graphics chip (Antic) to grab display lists from the shared memory. 

 

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...