TTL 6502 Here I come

[SpottedGal]

But would the clock need gated? Could you keep the clock going and only use a transistor/latch to just unhook it from where it feeds the program counter while keeping the clock on the rest of the CPU? Not sure, just wondering.

For room, if you need 2 more chips, it seems that they can be added to the socket end on the header board.

[BigEd]

(Gating clocks is possible, but usually it's easier to have an enable input for the receiving latch or register, because the enable signal can be setup later than a clock enable, and because there's not the same difficulty or risk with introducing clock glitches or clock skew.)

[Drass]

SpottedGal wrote:

But would the clock need gated? Could you keep the clock going and only use a transistor/latch to just unhook it from where it feeds the program counter while keeping the clock on the rest of the CPU? Not sure, just wondering.

Ah, my mistake. I assumed gating the clock was the intention (the schematic ttlworks pointed to shows what looks to be a 74LS02 at the CPU clock input). Yes, the clock can be manipulated inside the CPU, as it already is by the RDY, STP and WAIT signals. (see Card A, Page 3 here: download/file.php?id=8135&mode=view).

Quote:

For room, if you need 2 more chips, it seems that they can be added to the socket end on the header board.

You’re probably right, but I have to admit to more than a little vertigo at the thought ...

[SpottedGal]

I am not sure... I think suspending the CPU and unhooking it from the data/address lines is the goal. Antic would need to pause the 6502 and be able to be the sole device accessing memory. The 6502 (preferably with the "Sally" mod, though it can be done externally with 4 additional chips like on earlier Atari 800s) writes a display list, then Antic interprets it and sends it to the GTIA (or CTIA, or FGTIA), which then makes the image displayable. Antic is also the DMA controller and enables the Freddy chip and 2 others to refresh the RAM. Homebrew and heavily modded Ataris don't use those latter 3 chips due to the use of SRAM.

[BigEd]

There might be a question about RDY: on the original NMOS 6502, RDY only stalls reads. On later 6502s, RDY also stalls writes. For a clean-sheet design, I imagine you could do either. Or even both (selectable) for some kind of compatibility reason.

And, if you have a full-fat RDY, and a BE to get the 6502 off the bus, are you more or less done?

[Drass]

RDY is configurable based on whether 6502 or 65C02 operation is selected for the CPU (via a jumper). I agree that BE and RDY together seem to achieve the desired effect.

[SpottedGal]

Yeah, I think that is how some manage to get the 65816 to work. I think that only takes 2 chips to get the halt signal from the board to those 2 lines and maybe convert a few other signals.

Now, an issue with going to 6502C is that you may lose some undocumented instructions. A lot of vintage software used those.

[Drass]

Ah, good point!

I originally implemented only the 65C02 RDY behaviour, and then had to patch the boards to make the CPU work with C64 code that relied on NMOS-style RDY. There is currently no way to select NMOS microcode (to support undocumented opcodes) and CMOS RDY.

Early in the design process, I argued we should have a single CMOS and NMOS mode switch that was easily selectable with a single jumper. I reasoned it would be easiest that way to configure the CPU for operation with either an NMOS or CMOS host. Dieter argued each option should be individually selectable to make the CPU most flexible. Hmm, it’s clear Dieter was right in this case.

[SpottedGal]

I do wonder if there is a way to keep the default behavior the original way but get the halt line to enable the newer behavior as needed.

[Drass]

I expect there is, by manipulating the internal RDY and BE signals. One thing to be aware of is that timing will matter. You want to bring RDY low before the fall of PHI2 to pause the CPU. But BE must be brought low only once the CPU is paused, after the fall of PHI2. Dropping BE and RDY at the same time prior to the fall of PHI2 risks a glitch in the address lines during the critical phase 2. It’s likely that bus capacitance would save the day, but one would want to wait a bit to be on the safe side.

So, dropping RDY on the rising edge of PHI2 and then dropping BE on the falling edge of PHI2 is probably right.

[SpottedGal]

Thanks. It sounds like a scope is certainly necessary to make sure.

And I imagine also if one is doing this for Atari, it would likely be more stable on the SRAM clone machines. That is just in case the timings are a little off, there won't be any refresh problems. Converting one of those machines to use SRAM reduces the chip count a bit. Without DRAM, you don't need the entire Freddie chip or the two MMU chips. And with the number of pins that a single 64K SRAM has, it can connect directly to the address lines without using multiplexers or decoders for banking (in originals, there are up to 4 16k boards, so maybe 31 fewer RAM chips if using a single 64Kx8 and no banking). The chip reduction can reduce latency. And I imagine doing that not only makes things more stable (provided you have a strong enough power supply) but can also make audio and video slightly cleaner.

Speaking of cleaner video, I've seen a thread on that. One of the best fixes for that is to remove the choke going to the Vcc of the GTIA chip and run a wire from the power supply to there (GTIA side). Nobody mentioned running shielded wire there, but I think that would be worth a shot. Since voltage might travel about 6" per ns, you would have less ripple if you get it directly from the power supply area and not pick up noise from nearby chips. Of course, if they had more backfill on the PCB, the signal could have been made cleaner that way too. On the original Atari boards, they cheated in other ways too. For instance, one of the resistor values is off (which can adversely affect impedance with the RF modulator), and there is what seems to be an unnecessary capacitor. That has to do with pixel timings. Since the multiplexers or whatever are not exact and there are fluctuations in the pixel voltages due to the system clock, a capacitor is added to average that out. That removes the fine vertical lines at the expense of some image sharpness. If you have the 80-character mod added and enabled, then vertical lines would make things unreadable.

[vfxsoup]

Sorry if this has already been asked elsewhere in this topic, but why are the two ICs 74'132 and 74'245 thru-hole DIP parts when all the other logic ICs are SMD?

[ttlworks]

The 74245 buffers the external data bus, the 74132 buffers some external control signals which go into the CPU.

Logic level threshold is what separates the logic LOW voltage from the logic HIGH voltage at an input pin.

74ACT has a logic level threshold of ca. 1.3V, that's compatible to good old standard 74LS TTL.
74AC has a logic level threshold of half the supply voltage, would be ca. 2.5V at a 5V supply.

By default, we are plugging a 74ACT245 and a 74ACT132 into the sockets.
In, for instance, a C64 (running at ca. 1MHz) we could assume that the output drivers of the chips inside the computer make ca. 3V logic HIGH max.,
and that they have a logic level threshold of ca, 1.3V, so 74ACT is fine.

If it should become necessary to have improved noise immunity when plugging the CPU into a computer running at 20MHz max. built from modern parts,
we still have the option to plug a 74AC245 and a 74AC132 into the sockets instead.
If 74AC won't cut it, another option would be plugging slower chips (which might be less sensitive to spikes at the inputs) into the sockets, like 74HCT\74HC.

[vfxsoup]

ttlworks wrote:

By default, we are plugging a 74ACT245 and a 74ACT132 into the sockets...

Of course - that makes sense now.

Thanks.

[ttlworks]

Drass is away for a while.

I have tried to integrate the list of patches into the schematics and PCB layouts of the CPU,
then to make a cleanup of the PCB layouts (vias were too close to the SMD pads etc.).

My modified schematics and PCB layouts are not verified by Drass,
so it is _not_ an "official release" of a "production quality design".

Since it's been nearly a year that the list of patches had been posted in the forum,
I now got permission from Drass to post all of the schematics and PCB layouts.

;---

Edit: the microcode:

microcode.zip

(34.1 KiB) Downloaded 293 times

Original schematics and PCB layouts from Drass:

Eagle Files.zip

(1.83 MiB) Downloaded 287 times

Patched and cleaned up schematics and PCB layouts from ttlworks:

ttlworks_patch_cleanup.zip

(1.53 MiB) Downloaded 317 times

After 20 years+ of making PCB layouts for a living, I would dare to say that the PCB layouts for the CPU are the most complicated/dense design
that I ever have encountered so far, and considering that this is Drass's first project, I'm amazed/impressed that he was able to route them.

No free space left on the PCBs for implementing something like an "Atari modification", sorry.
Have fun.