TTL 6502 Here I come

[Dr Jefyll]

Drass wrote:

The fallback, of course, is to get the boards made separately (although at a significantly higher price).

Maybe you've already thought of this, but there's also a certain advantage if the boards are made separately. You'd have the option to temporarily set aside the TTL CPU design and begin by completing the SBC (which is a viable project in itself as it can work using an actual 6502). The experience you gain from assembling then debugging the SBC may lead to some insights later when it's time to put the finishing touches on the CPU PCB's before pulling the trigger for their manufacture.

Dunno how important this is in the big scheme of things. But as I recall you come from a software background, not hardware, so maybe a step-wise approach is best. (The decision involves many factors, of course.)

-- Jeff

[Drass]

Dr Jefyll wrote:

there's also a certain advantage if the boards are made separately.

Of course, you're right. I'm likely to learn A LOT at the outset, and savings from a panel will quickly evaporate with any remakes - which is a virtual certainty in my case. A step-wise approach is much more sensible. Thanks for mentioning it.

Quote:

you come from a software background, not hardware

Yes, indeed - I'm pretty far out on a limb on this project. Better press on and not think about that too much

[Arlet]

Drass wrote:

Yes, indeed - I'm pretty far out on a limb on this project. Better press on and not think about that too much

Most progress is made by people underestimating the problem

[ttlworks]

Dr Jefyll wrote:

You'd have the option to temporarily set aside the TTL CPU design and begin by completing the SBC (which is a viable project in itself as it can work using an actual 6502). The experience you gain from assembling then debugging the SBC may lead to some insights later when it's time to put the finishing touches on the CPU PCB's before pulling the trigger for their manufacture.

I agree with Jeff:
The SBC is a nice project for getting started and for increasing skill level (especially SMD soldering skills).
Would suggest to focus on the SBC first, and to start building the CPU after the SBC is up and running.

Would also suggest a little modification for the SBC, just to make sure that a 6526 could be plugged into the 6522 socket, too...
because building a TTL implementation of the 6526 might become a future project.

Hey, there had been an experimental TTL implementation of the 6522 running at 4MHz, so a 20MHz TTL 6526 might be feasible.

Go, Drass, go !
...Just be careful that your brain won't go into "overflow condition".

[Drass]

I've been making some progress on finalizing the SBC. At Dieter's suggestion, I changed the 6522 VIA to a DIP package and added a little address decoding logic to accommodate a 6526 being used in it's place (the 6526 has a /FLAG input signal on PIN24 where the 6522's CS1 positive logic chip-select is. A pull-up on pin 24 plus the added glue logic makes the socket compatible for either a 6522 or a 6526).

It took a little re-routing to manage the much larger DIP package and the DIP pads ended up making a rather lively frame on the silkscreen title. All in all, it was all done in reasonable order:

Other changes included adding a jumper to make WAIT states on peripherals optional, and other fixes and clean up items. I'm going to do some final desk checking and I'll post up a final schematic shortly.

That's it for now.

Cheers.

[hmn]

Hi Drass (and everybody). I have been a long time lurker on these forums (and this thread in particular), and upon reading it again this weekend, I got confused by this bit about the write pulse latching, and the accompanying schematic:

Drass wrote:

[...] Instead, I now latch the signals with a 74273 (with the Async Clear signal) on the trailing edge of phase2 and clear the latch on the leading edge of phase2 to prepare it for the next cycle.

Here is my ASCII-Art representation of the relevant part of the schematic:

Code: Select all

                | 74273 |
                |       |
/CLK --+---|>o--| CLK   |
       |        |       |
       `-------o| CLR   |
                |       |

I don't quite understand how that works - as far as I can tell, the positive edge on the clock input would always occur while /CLR is held low (active). Do the FFs "remember" data that was latched while the clear was active?

[BigEd]

Might be clearer with a true clock signal, Hmn (welcome, by the way!) In 6502 land the clock is almost always Phi2, which means cycle boundaries are on a falling edge.

Looks to me too like the text and the schematic are telling different stories.

It might be crucial that the signal arrives first at the \CLR input, and one gate delay later at the CLK input, which is different from how you've drawn it there. (One gate delay might be a bit short compared to the spec of the '273.)

Personally I'd try only to use "latch" to mean a transparent latch, whereas the '273 is a flop.

[hmn]

BigEd wrote:

It might be crucial that the signal arrives first at the \CLR input, and one gate delay later at the CLK input, which is different from how you've drawn it there.

Hi Ed! I'm confused - that seems to be exactly what I tried to "draw"? (signal goes directly to /CLR, and to CLK via an inverter).

Anyway, I have just now noticed that in a later revision of the schematic, a couple of posts down from the one I linked to, this part has changed yet again, to something that makes a bit more sense to me (CLR is delayed until after CLK), so I think we can disregard my confusion about the earlier revision - unless I *really* misunderstood how that FF works, in which case I'd like to know

[Dr Jefyll]

Welcome, hmn. I too was just looking at that later revision.

The original definitely has something amiss. I suspect it ought to've used two inverters -- like this:

Code: Select all

                  | 74273 |
                  |       |
 --+---|>o---|>o--| CLK   |
   |              |       |
   `-------------o| CLR   |
                  |       |

cheers,
Jeff

[BigEd]

Ah, if there were different versions of the schematic, I might be confused... I meant to include a screen grab.

[Drass]

Hello hmn (and welcome as well).

Yes, the first schematic is wrong and is corrected in the second version. Apologies for the mix-up!

The circuit in question is what Dieter called a "monoflop" (the gates on the lower part of the image below):

The basic idea is to let the rising-edge of the clock through to the flip-flop (thereby releasing the WR signals at the right time), and then to generate a brief low-pulse (which clears the flip-flop) on the falling-edge. Because the low-pulse is brief, /CLR is high when the next rising clock-edge arrives. In this case, the clock is PHI11 which is a CPU-internal version of PHI1 - that is, the rising-edge of PHI11 corresponds to the falling-edge of PHI2 at the end of the cycle.

Looking at it more closely: when PHI11 is high, input 1 of the NAND is also high (4 inverters precede it) and input 2 is low (1 inverter precedes it). The output of the NAND is therefore high. When PHI11 falls, the signal travels through the first inverter taking input 2 high and (briefly) the NAND output low. A short time later, the signal makes it's way through the additional three inverters and takes input 1 low, which in turn takes the output of the NAND high again. The output remains high through the next low-to-high transition of PHI11, and the cycle then repeats.

Three inverters are used in series to make the pulse long enough to be reliable (a 74AC74 requires /CLR to remain low for at least 5ns to take effect).

Hope that helps.

Cheers!

[ttlworks]

Hi hmn, and welcome to the forum.

Drass already did a good description of how it works,
so I'm adding some ASCII art:

Code: Select all

        |  machine     | machine    |
        |  cycle n     | cycle n+1  | 

                -------        ------
PHI2    |      |       |      |      |
         ------         ------        ------

Microcode... ------------- ------------- --
ROM         /             \             X
output   --- ............. ------------- --
        
          -----   ------------   ---------
/CLR           | |            | |
                -              -

register  ............. ------ .........
write                  |      |
signal    -------------        ---------

         |register|   ^
         |read    |   | 
                      register write cycle n

One machine cycle is one PHI2 period.
(Drawing is not to scale.)

A register is read when PHI2 is low, then the "function blocks" in the CPU data path (ALU) "do something",
and at the end of the cycle (the falling edge of PHI2) the result is written into a register.


Registers are something like 74574 latches, with the CLK input fed by one of the "register write signals".
So the rising edge of a register write signal makes the register load the data.

The problem is to generate a nice register write signal, because the microcode ROMs need some time
to have their output stable etc.


Our trick was to load the "register write related outputs" from the microcode ROMs into 74273 latches
triggered by the falling edge of PHI2 (the start of the next machine cycle).


The 74273 latches then generate nice register write signals with a rising edge at the falling edge of PHI2...
of course, this causes another problem: if we would try to write one register in two successive machine cycles,
a register write signal generated this way would stay high for two cycles.


To be able to do successive writes to the same register, we need to clear the 74273 microcode latch with /CLR
at the rising edge of PHI2, in the middle of the machine cycle.
So the register write signal only is high for half a machine cycle.

/CLR is generated by a monoflop (built from some logic gates) at the rising edge of PHI2.


What had confused you was an old revision of the hardware that was implemented a bit different,
we discarded it because it probably wouldn't have worked in a reliable way.

Of course, I'm simplifying things a little bit here... but that's the basic concept.
I hope, my description was helpful so far.

[Drass]

While validating the ROM cycle-times on the SBC, I noticed an unfortunate side-effect of my implemetation of wait-states. Rather than using RDY to pause the CPU (as I had seen in other designs), I opted instead for stalling PHI2 for a cycle. It seemed the simpler option, and allowed RDY to be reserved for the Single-Step clock. However, the SBC has an on-board VIA which relies on the clock, so pausing PHI2 makes real-time processing with it all but impossible. Something as simple as a regular IRQ from the VIA will have variable timing, depending on whether a wait-state happens to be triggered by, say, a ROM access. Thankfully, the SBC can disable wait-states with a jumper, or by switching to the SLOW (Div 2) clock under software control. That will do, but in truth I would have preferred the more elegant RDY-based wait-state design.

On another note, I stumbled upon Garth’s WM-1 memory expansion module, which seems a very fitting way to put the TTL CPU’s 24 bit address bus to work. After a quick chat with Garth, I added a WM-1 pin-header to the SBC, and thereby equipped it with an optional 32Mb RAM expansion card - nice! A freshly made WM-1 module is on it’s way and it's going to be a lot of fun to get that going with the TTL CPU once built. Thanks Garth!

Beyond that, there were a few more changes: I swapped the 70ns DIP ROM for a faster 45ns one and the 128k RAM chip for the same 512k variant Garth uses in his memory module. I also had to move the DIP VIA from the underside of the board to the top layer as it would bump up against the microcode-ROM PLCC socket on the Registers Card below when mounted on the TTL CPU. And finally, I was able to tidy up an issue with the STEP clock which would have caused problems at faster clock rates. Naturally, all that meant lot's of re-routing of traces

—————

I think that may be it for changes. The PCB mockups look pretty good now:

The two 40-pin receptacle headers shown above actually go on the bottom layer and will connect with the TTL CPU below. The glue logic and UART are on the bottom layer as well, and those footprints check-out nicely:

Taking a look at manufacture: I decided to go back to OSH Park since I’m not panelizing and it looks like PCBWay.com may have a challenge with the vias I’m using (10mil drill, 4mil annular ring). I can probably make the SBC work with larger vias, but certainly not the other cards, so I’m sticking with them for now. (Not sure I like the purple OSH Park PCBs though - what’s wrong with the standard green?)

OSH Park takes Eagle BRD files directly, which is nice, but I also tried to generate the Gerber files. I’m not sure that’s working correctly as the gerber viewer (Pentalogix ViewMate) shows all the pcb data miniturized on the bottom left corner of the pcb while the remainder is blank. Some sort of scaling issue which I’ll have to sort out. If anyone has run into something like this with Eagle, please let me know.

Latest schematics, and what I hope may be the final layout attached. (Incidentally, I added some additional parts to the schematic and put in sourcing info so the BOM is complete. As it stands, the BOM Eagle generates uploads directly to Digikey, which is nice)

Cheers!

[Drass]

This is probably "old-hat" to many here, but it's nothing short of amazing to me! I know it's supposed to look exactly like the screen I've been staring at - but to have the actual board in front of me, well, it just seems like magic. It's a first, and I feel like I want to frame it

As you'll notice: green solder mask, rather than the OSH Park purple and gold. pcbway came back saying they could manage the via sizes after all, and it certainly seems that way from what I can tell. I wanted to given them a try just in case I do end up looking at a panel later on, and, I have to say, the pcb looks quite nice. Of course, I can immediately see things I might have done differently, but I'm very happy on the whole.

While the pcb was being made, I took some time to set up a little work space and get some tools sorted out ... power supply, soldering station, rom burner, etc. Very nice to get these things going. I've been putting in some practice with one of those SMD soldering kits as well. Things were quite dismal at first, but I'm beginning to get the hang of it. The biggest issue was using too much solder (and not being able to see the darn things!). It all proved much easier with smaller diameter solder and a magnifying glass. It's going to take a little time, and lots more practice, but it's beginning to look feasible. I may yet conquer those 0603 caps!

That's it for now ... can't wait to get started on the real board!

[Drass]

It's alive!

Well, barely ... I did get something assembled though, and It feels great to be building and not just drawing schematics, finally. Actually I'm thrilled - only about 1,000 things had to work out just to get this far, and it's a joy to see the thing execute a simple NOP test. If you look closely, you can see that the Data Bus has an $EA value in the pic below:

I'm also pretty happy with how the soldering went. I even managed to install only one IC backwards (funny how hot these little chips can get when you do that). The trickiest parts so far were those resistor arrays, but I've yet to solder the J-lead packages for RAM and the UART. I had trouble with them in the first go around so I've left them out for now.

I installed a 4MHz oscillator to start (which is generating a 1MHz PHI2 signal after going through a couple of flip-flops). I'm able to stop the clock on the fly and switch to "Manual" mode, at which point I can step the machine and watch the address bus increment - wonderful.

Still, there were lots of issues with the PCB:

1) Drill holes for the RESET and clock TICK push-buttons are too small (hence the rather gangly switches I installed instead)
2) Drill holes for toggle switches are too small ... I had to file down the pins to make them fit
3) Toggle switches are wired upside down what a newbie mistake! Well, they work, as long as you remember that up really means down
4) I'm missing a few LEDs and the RDY LED seems to be burned out (who doesn't order plenty of spare LEDs? Me, that's who)
5) The FAST clock is not working ... I think this one is a mis-wired inverter. I'm going to have some fun cutting a trace and running a jumper to fix this ... can't wait to see how that turns out!

Once I get this sorted out, I'll have a go at some firmware and see if I can get the VIA to work, and then maybe install the RAM and the UART. With some luck, I can get things going with the current PCB. I'll have to order a new one at some point, but I would sure like to fix all the issues at once.

In the meantime, here is a pic of my workspace with the specimen under observation ...