Overclocking the Stock 6502c: Is it Possible?

[_The Doctor__]

The Halt circuitry is external on the early 800's that used a standard 6502 and is easy enough to replicate.

[+DrVenkman]

14 minutes ago, _The Doctor__ said:

The Halt circuitry is external on the early 800's that used a standard 6502 and is easy enough to replicate.

But earlier 6502B’s aren’t necessarily as easy to get hold of as a SALLY (only one of my 800’s has a B version, the others all have SALLY). And designing something to drop into a board with a socket meant for SALLY just means more complexity and board space on whatever gets dropped in there. It can be fined, sure, but we need to remember Michael’s whole goal here. 

[+mytek]

The majority of A8s use Sally, not a standard 6502. Adding circuitry such as what was done in the early 800 to allow for /HALT wouldn't make sense when it can probably be emulated within Jim Drew's 65xxT. Coming from the CBM/Apple community Jim probably wasn't aware of the custom nature of Sally vs. a normal off the shelf 6502, so there was a bit information that needed to be exchanged before his board can be expected to work in an Atari. as to whether or not that happens, that'll of course be entirely up to Jim. There will be other concerns as well, such as physical fit in our systems, and compatibility both physical and operational to get along with other upgrades.

 

Here's an excerpt from Atari Mania describing Sally and a bit of its history...

Quote

Several manufacturers produced the SALLY 6502 for Atari, including MOS
Technology, Synertek, Rockwell, NCR, and United Microelectronics (UMC).  It is
important to note that chips marked "6502C" such as the MOS Technology
MCS6502C, MOS Technology MPS6502C, Synertek SY6502C, Rockwell R6502C, or UMC
UM6502C are NOT the Atari "6502C" but rather equivalents to the standard
MCS6502 that are certified for 4MHz operation.  Atari SALLY 6502 chips are
never marked "6502C" but, other than the UMC UM6502I, always carry the Atari
part number C014806.

In contrast to the MCS6502 and equivalents, the SALLY 6502 has the addition of
a /HALT signal on pin 35.  The SALLY 6502 also has a second R/W signal on pin
36 (in addition to pin 34).  Pins 35 and 36 are not connected on the MCS6502
and equivalents.

The Atari's second microprocessor, ANTIC, must routinely interrupt the 6502 in
order to utilize the processor bus for itself for direct memory access (DMA).
/HALT on the SALLY 6502 facilitates this system design.  Atari's earlier
implementation of the same functionality in the 400/800 using the MCS6502 or
equivalent requires a series of 4 additional chips that are unnecessary in
computers designed for the SALLY 6502.

 

[+ZuluGula]

Mq from atariarea made adapter that let's you use standard 6502 in XL/XE.

http://www.atari.org.pl/forum/viewtopic.php?pid=239882

[guus.assmann]

Hello,

I have made a PCB, many years ago, that made it possible to use a 65C02 in the XL's or XE's.

And the XL7 is already in this forum, look at the attachments I put in.

Schematics and source code are there. Just needs some sorting out. There's "logic" in the file names.

 

BR/

Guus

[+bob1200xl]

The XL7 has two small CPLDs, SRAM memory, and a 65816 that replaces the 6502C. It needs wiring changes on the system. Runs at 7.16 or 1.79mhz.

 

This is an XL14. It has one large CPLD, SRAM memory, a 65816 that replaces the 6502C, and 512K of battery-backed SRAM. No wiring is required - it just drops into a socketed XL. You don't need the Battery-backed SRAM. Runs at 14.32, 7.16, or 1.79mhz.

 

I'm looking for the docs...

 

Bob

 

 

 

[+mytek]

Hi Bob. As I said I would be interested in the XL7 because of it's use of all through hole parts that would lend itself better towards DIY. When you find the docs and the CPLD code, I would like to play with this. I know your XL14 does more, but probably none of the extras do anything that isn't already handled by the U1MB and a CF/IDE interface. just looking at an easy, cheap path to acceleration ? .

 

You mentioned wiring changes... do you recall what kind of changes are required? How is the SRAM being interfaced? Could I use the SRAM that's already on my 1088XLD?

 

Wait a second, you also said...

Quote

This is an XL14. It has one large CPLD, SRAM memory, a 65816 that replaces the 6502C, and 512K of battery-backed SRAM. No wiring is required - it just drops into a socketed XL. You don't need the Battery-backed SRAM. Runs at 14.32, 7.16, or 1.79mhz.

Are you implying that in my proposed usage already having 1088K of RAM (64K base SRAM + U1MB 1024K SRAM) that I could use this instead? If so, that makes for a very simple board. Basically just a single CPLD and the 65816 (unless I'm missing something).

 

[+bob1200xl]

The XL7 re-wires the clock circuit to use a 14.32 oscillator on the new PCB. I might have isolated A15, also. The XL14 uses the Atari oscillator and a PLL on the new board. No wiring needed. A15 is how I control ANTIC selection since ANTIC does not have a -CS pin.

 

You can use your SRAM if it is fast enough (<70ns), but I have no way to select linear memory above $FFFF with the 65816. Looking at the XL14, you could map a PDIP into the space used by the two SRAMs. Run it like an XL7 but with drop-in convenience.

 

If you could get inexpensive boards made for this, what? $40 or less for the whole thing?

 

Bob

[elmer]

On 6/26/2019 at 1:51 PM, ivop said:

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

 

 

Both compilers are direct descendants of Ron Cain's Small C, and so only really offer peephole optimization, rather than the more-sophisticated optimizations that modern compilers can do.

 

CC65 has had *much* more work put into its peephole optimizer than has gone into HuC's peephole optimizer, and so it will generally produce better code than HuC. That doesn't mean that HuC can never do better, just that it has had far less development hours put into it.

 

 

CC65's developers have also put a lot of time into adding stuff to the compiler so that it can compile relatively-modern C code, which has never been a goal for HuC.

 

HuC is much more like a C-syntax version of Action! ... it offers a lot of built-in functionality and library functionality that programmers can use for making games.

 

For instance, this Kickstarted (and released) game was developed with HuC ...

 

 

 

Anyway, the current version of HuC relies on the extra instructions in the 65C02/HuC6280, and so it's not usable on the Atari.

 

I've been toying with the idea of doing a major overhaul on HuC's code-generation, and quite-by-accident, I found that what I'm thinking of doing would actually work just as well on the original NMOS 6502 that's in the Atari.

 

Which is why I'm here, rekindling my old love of the Atari 800, and trying to decide if it's worth my time to try to make the next big version of HuC usable for Atari development.

 

[ivop]

24 minutes ago, elmer said:

I've been toying with the idea of doing a major overhaul on HuC's code-generation, and quite-by-accident, I found that what I'm thinking of doing would actually work just as well on the original NMOS 6502 that's in the Atari.

 

Which is why I'm here, rekindling my old love of the Atari 800, and trying to decide if it's worth my time to try to make the next big version of HuC usable for Atari development.

 

 

Thanks for your thorough explanation. Just in case you missed it, I once started this thread:

 

 

which might be slightly interesting to you, too. Note that I did not write the 6502 backend. Just made it spew out Atari binaries.

 

[elmer]

24 minutes ago, ivop said:

 

Thanks for your thorough explanation. Just in case you missed it, I once started this thread:

 

 

Thanks, yes I read that thread recently.

 

I don't want to keep on polluting this thread with digressions, so I'll start up a new thread to talk about this stuff.

 

[+mytek]

2 hours ago, bob1200xl said:

The XL7 re-wires the clock circuit to use a 14.32 oscillator on the new PCB. I might have isolated A15, also. The XL14 uses the Atari oscillator and a PLL on the new board. No wiring needed. A15 is how I control ANTIC selection since ANTIC does not have a -CS pin.

 

You can use your SRAM if it is fast enough (<70ns), but I have no way to select linear memory above $FFFF with the 65816. Looking at the XL14, you could map a PDIP into the space used by the two SRAMs. Run it like an XL7 but with drop-in convenience.

 

If you could get inexpensive boards made for this, what? $40 or less for the whole thing?

 

Does this require a 4-layer board? If so could probably get 10-15 made for around $30 including 3 week shipping ($2-3 a piece). Of course in larger quantities the price drops dramatically.

 

I would be interested in pursuing this. I'm assuming you have this already in ExpressPCB, which would make doing an alternative layout a bit easier for me.

 

Quote

Looking at the XL14, you could map a PDIP into the space used by the two SRAMs. Run it like an XL7 but with drop-in convenience.

I'm a bit fuzzy as to how much RAM we are talking about. Keep in mind I already have banked RAM provided by the U1MB. So is the 65816 working in a 64Kx8 memory space, or is it larger? A schematic would really help. If you did this in ExpressPCB, I would think finding the files would be relatively easy. We aren't talking about digging through bankers boxes looking for hard copies are we?

 

 

 

[+bob1200xl]

The 65816 can output an 8-bit address as bits A16 - A23 on the data buss during the first half of the cycle. You latch those bits and use them to drive from 64K to 16mb. On the XL14 and XL7, this gives you a 512K memory space of random access memory. Your RAM uses some sort of register to select banks, no? RAMBO style?

 

Well, maybe a little bit... what's wrong with banker boxes?

 

Bob

 

[ijor]

9 hours ago, mytek said:

Here's an excerpt from Atari Mania describing Sally and a bit of its history...

The SALLY 6502 also has a second R/W signal on pin 36 (in addition to pin 34).  Pins 35 and 36 are not connected on the MCS6502 and equivalents.

(Bolding is mine) It this actually true? All references claim pin 34 is N.C., implying R/W is connected to 36 pin instead (and not in addition) to pin 34.

Edited June 29, 2019 by ijor

[+mytek]

4 hours ago, bob1200xl said:

The 65816 can output an 8-bit address as bits A16 - A23 on the data buss during the first half of the cycle. You latch those bits and use them to drive from 64K to 16mb. On the XL14 and XL7, this gives you a 512K memory space of random access memory. Your RAM uses some sort of register to select banks, no? RAMBO style?

 

Well, maybe a little bit... what's wrong with banker boxes?

 

Bob

 

 

Nothing wrong with banker boxes, unless you have too many of them to sort through ?.

 

No my RAM is strictly for the base 64K. The other memory (ROM and Banked RAM) are handled by the U1MB. It can be configured by jumping into a setup menu in the U1MB to give you a few different banking schemes, and you can also select one of 4 possible OS ROMs, one of 4 possible language ROMs, and several other PBI/SIO configuration settings. The battery backup is for the included RTC. The U1MB has been around for quite sometime now, and has become a highly desirable upgrade.

 

So if and when you find your XL14 stuff, please post what you got going on, and then we'll be able to figure out what will work. Obviously there has got to be a way for your accelerator and the U1MB (and its companion the SIDE2 CF drive) to play together nicely, since that is something the Rapidus is already capable of.

 

BTW, the U1MB is also acting as the MMU, having taken over the functions of the original one with it being removed from the motherboard, and the U1MB plugged into where it used to go. I have a funny feeling that your XL14 has done the same thing. If so, then that will be a potential problem.

 

[Kyle22]

I think we can put RAM above $FFFF on the board with the CPU, and mask off the Address Bus to the chipset for accesses above $FFFF. That way we won't have problems when accessing addresses such as $1D302 and such.

 

Accelerated 800 CPU card, anyone?

 

[Rybags]

I'd have thought a 6502B would be easier to aquire than a Sally - though I guess outside of Apple II and C64 there were few out there other than from Atari (and C64 is 6510 which is another offshoot).

 

I guess 7800 + computer sales + <Sally in arcades ??? > would have come to near enough 8 million and Atari's sometimes laughable stockpile policy might have seen another million sitting around as NOS.

Edited June 29, 2019 by Rybags

[+DrVenkman]

5 hours ago, Rybags said:

I'd have thought a 6502B would be easier to aquire than a Sally - though I guess outside of Apple II and C64 there were few out there other than from Atari (and C64 is 6510 which is another offshoot).

 

I guess 7800 + computer sales + <Sally in arcades ??? > would have come to near enough 8 million and Atari's sometimes laughable stockpile policy might have seen another million sitting around as NOS.

A few hundred thousand (a couple million? Have no idea ... ) 5200’s also use SALLY so add them to the total.

[ricortes]

On 6/27/2019 at 5:02 PM, mytek said:

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?

 

I didn't do anything beyond changing the clock speed. In hindsight it would have been good to take it a little farther. Circuit was just one of Bob's tidbits he used for his 80 column design. I just did the counter/crystal and a gate to switch from existing on board crystal circuit going into the GTIA to Bob's clock. It really was a sweet set up for testing how fast the chips would run. Just plug in a 4 MHz resonator and pick off the 2 MHz of the 74LS193 or use a 16 MHz resonator and pick a different line =>2 MHz. I think I tested about 5-6 combinations to determine max clock rate before everything went south. I'm not sure what i used to gate the clk, could have been a multiplexer like a 74LS151. In hindsight it would have been better to keep the GTIA running at stock speed and see if I could switch the output of the GTIA system ClK to the faster CLK going to the processor. 

[JimDrew]

On 6/28/2019 at 8:44 AM, mytek said:

The majority of A8s use Sally, not a standard 6502. Adding circuitry such as what was done in the early 800 to allow for /HALT wouldn't make sense when it can probably be emulated within Jim Drew's 65xxT. Coming from the CBM/Apple community Jim probably wasn't aware of the custom nature of Sally vs. a normal off the shelf 6502, so there was a bit information that needed to be exchanged before his board can be expected to work in an Atari. as to whether or not that happens, that'll of course be entirely up to Jim. There will be other concerns as well, such as physical fit in our systems, and compatibility both physical and operational to get along with other upgrades.

 

Here's an excerpt from Atari Mania describing Sally and a bit of its history...

 

 

Well, you definitely got that right!  I had no clue that the Atari had a custom 6502.  I was thinking that since it ran at >1MHz that the 'C' version (6502C) was the 4MHz capable chip!

 

So... some questions for you...

 

It seems that the pinout for Sally is identical to a standard 6502 with the exception of pin 36 now being R/W.  Is pin 34 also the exact same R/W signal?  I don't see pin 34 connected in an Atari schematic I found.  Pin 35 is the /halt line, and that is very easy to support.  I can take the address and data bus offline at any time  - I do that already for the /RST signal.   Is there some type of correlation of when the bus should go Z-state after the /halt line goes low?  Most everything depends on a cycle state, such as RDY.  Is there any documentation at all about Sally?

 

I am going to make a 65816 emulation in the 6502 pinout so you can just drop this in an have a 65816.  The emulation will run a bit faster than the 6502 emulation because the microcontroller I am using is a 16 bit version, and I am having to strip and swap bytes because it is little endian and I have to get the low byte for flags and register results.  I don't have to do that when the 65816 is in 16 bit mode.

 

 

 

[Rybags]

Unsure if there's any specific Sally 6502 docs around - supposedly it should be the same as the 6502B except the pinout difference and with the external logic employed to implement /HALT onboard the die rather than the CPU board as per original 400/800.

 

/HALT as far as I know simply keeps the clock as witnessed by the CPU in the high (?) state which has the effect of keeping it off the bus, and is "immediate" in the sense of holding instructions such as read/modify/write (INC) midstream unlike /RDY which allows sequential writes to comlete.

[ijor]

4 hours ago, JimDrew said:

It seems that the pinout for Sally is identical to a standard 6502 with the exception of pin 36 now being R/W.  Is pin 34 also the exact same R/W signal?  I don't see pin 34 connected in an Atari schematic I found.  Pin 35 is the /halt line, and that is very easy to support.  I can take the address and data bus offline at any time  - I do that already for the /RST signal.   Is there some type of correlation of when the bus should go Z-state after the /halt line goes low?  Most everything depends on a cycle state, such as RDY.  Is there any documentation at all about Sally?

Hi Jim,

 

As I said before, that note claiming that pin 34 is also R/W has to be wrong. R/W seems to be at pin 36 only.

 

HALT is asserted by ANTIC one cycle before the CPU should disconnect from the bus. Note that HALT might have almost half a cycle delay. There is an ANTIC datasheet here:

 

As also already mentioned, the earlier 8-bit computers used a standard 6502 and the HALT logic was external. You can check the Atari 800 (or 400) schematics and you would see exactly the HALT logic. It just stops the clock at the right time when the 6502 releases the bus. These schematics are widely available, sometimes as part of the Atari Technical Reference Notes: http://www.atarimania.com/documents/atari-800-technical-reference-notes.pdf

 

[JimDrew]

Thanks for the info!  I will check the schematics to see how the external halt logic works, that will tell me what I need to know.  Is there any reason why R/W could not be on both pin 34 and 36 at the same time?  Pins 35 and 36 are normally not connected internally with the 6502 - but I am wondering if some slick hardware engineer found that these pins make great "vias" and used them that way in some design.  I would hate to have add another set of gates and control logic just to handle pins 34 and 36 individually, if I didn't need to.

 

[ijor]

1 hour ago, JimDrew said:

Is there any reason why R/W could not be on both pin 34 and 36 at the same time?  Pins 35 and 36 are normally not connected internally with the 6502 - but I am wondering if some slick hardware engineer found that these pins make great "vias" and used them that way in some design.  I would hate to have add another set of gates and control logic just to handle pins 34 and 36 individually, if I didn't need to.

 

Well, I can't say I know for sure. Atari XL field service manual shows this pin as internally N.C. And on all the schematics I've (previously) seen it is indeed not connected. Now ... I just looked at the console schematics that also used Sally, 5200 and 7800. And according to those schematics both pins are connected one to the other, externally, at the board level. Not sure what this is supposed to mean ??? AFAIK, there is no Sally datasheet. Might be interesting to scope pin 34 and see if there is any output.

Edited June 30, 2019 by ijor

[+CharlieChaplin]

Well,

 

Bob's XL-7 was taking part in the Abbuc hardware contest 2008. Attached are the pics and other stuff which Abbuc got for the contest...

 

 

hw2008-65816cpu-speeder-bob-woolley.zip