Yet another TTL 6502

[Ax2013]

Welcome to the club Arlet. And good luck with the project!

Axel.

TTL 6502 - yet another project
viewtopic.php?f=4&t=4627

[Arlet]

Ax2013 wrote:

TTL 6502 - yet another project
viewtopic.php?f=4&t=4627

LOL, I was just thinking this morning that it might be cool to have 10 pin header connectors on some signals, so you could plug in a little board with display, in addition to putting LEDs on the main board.

And then i just look through your thread and see this:

[Arlet]

More schematics! The registers A, X, Y, S and M, corresponding to top left corner of block diagram.

Not too exciting, I'm afraid. Still need to insert the blinkenlights inbetween the register and the buffer.

[Arlet]

And a bus routing density check looks good. The white line is 3 mm long. And the bus could easily run in inner layer underneath the ICs. Trace/clearance is 0.15 mm (about 6 mil)

[Arlet]

And here's the address incrementer (same pattern continues for 16 stages).

Still need to figure out best gate/pin swaps.

[Arlet]

Picture of Eurocard with all components so far on it. Half of the ALU on the left, registers and buffers in the middle, and incrementer on the right. Looks like datapath should fit comfortably on half the board.

[Arlet]

Idea for PLA implementation. Use a diode shape with a regular SMD pad, and a pad with a small via.

You can run vertical wires on one side, and horizontal on the other. Density is 0.75 mm/diode vertically, and about 1.8 mm horizontally based on 0402 diodes.

[BigEd]

Is there any hazard to having a pad coincident with a via?

[Arlet]

BigEd wrote:

Is there any hazard to having a pad coincident with a via?

Yes, the via can soak up the solder, or if the via is closed at one end, then the hot air can expand and create voids.

But nothing that can't be fixed with a hand iron.

[GARTHWILSON]

BigEd wrote:

Is there any hazard to having a pad coincident with a via?

If you assemble by hand, it's not a problem. I did that on my memory modules. The problem comes with automated assembly when they use a silkscreen to squeegee the solderpaste on, and a bunch of the solderpaste goes through the hole and makes a mess. Recently however, assembly houses who can afford the investment are going to a process that's more like inkjetting the solderpaste on, which avoids this problem, or at least minimizes it. (The main reason for the process is that it avoids having to make the screens, and I expect it is also more efficient in production in other ways too.) Another way around it is if you want to pay the extra, they can plug the hole after thru-plating it, and they plate over the plug so you can't even see there's a via under it, by there's a continuous smooth solderable pad there.

[Arlet]

When I get to the PLA design, I'll first work out how much lines I need. If necessary, I can use this technique. If I don't need the density, I could do the via-in-pad trick with 0603. I've done that before and it worked well.

[GaBuZoMeu]

Arlet wrote:

BigEd wrote:

Is there any hazard to having a pad coincident with a via?

Yes, the via can soak up the solder, or if the via is closed at one end, then the hot air can expand and create voids.

But nothing that can't be fixed with a hand iron.

0402 that close together is a challange for rework with a hand iron me think. Perhaps hot air might do.

The solder soaking could be limited (but not fully prevented) by using blind vias instead of regular ones.

[Arlet]

Quote:

0402 that close together is a challange for rework with a hand iron me think. Perhaps hot air might do.

Hot air tends to blow those things away. If the problem is only the one pad, it's not so hard because the component is held in place on the other side.

Another option is to fill up the vias myself. If they are all in a grid, I can just rub some paste in the holes without making a mess.

But we'll see. I don't think I have a very large amount of control signals. Also, most of the control signals can be slow, so I can perhaps make a clever solution with a smaller PLA, and some additional logic to combine various outputs. Or use a couple of smaller PLAs. Or use a different state encoding, perhaps with more bits, to make other things easier.

[Arlet]

I just updated Verilog code to mimic the block diagram for the ADL/ADH internal address buses. In the block diagram you can see that for instance ADL can be written by:

• ABI, the output of the address incrementer (only bits 7 through 0), for when we want to access same address again, or next one
• output from ALU, for branches, indexed address, or just using the M register as delay.
• DB, for zeropage access. This one is time critical, because it comes from external memory, and we would like to increase access time window.
• PCL (low byte of Program Counter), for when switching back from data processing to instruction fetch

In Verilog, it looks like this. There is a 'sel_adl' select signal that encodes the driver. The 'case' statement looks at that number, and picks the corresponding source signal to drive the internal ADL bus. In case there is no valid select, I write 55 to the bus which should help to catch any mistakes in the simulator.

Code: Select all

always @* 
    case( sel_adl ) 
        ADL_ABI :                       ADL = ABI[7:0]; 
        ADL_ALU :                       ADL = ALU; 
        ADL_DB  :                       ADL = DB; 
        ADL_PC  :                       ADL = PCL; 
        ADL_BRK :                       ADL = 8'hFE;                // fixme, other vectors  
        default:                        ADL = 8'h55;                // to catch mistakes  
    endcase

In the schematic, for each possible case, there will be a tri-state bus driver connecting each source to ADL bus. And then the 'sel_adl' will be decoded into individual output enable signals for each of the bus drivers. There are different options for driving the constant signals. I still need to decide on an implementation.

There is similar code for the ADH bus.

[Arlet]

Added support for IRQ. Here's a simulation of taking an IRQ. I have checked a few timing cases. Looks good so far, but I'll need to do more extensive testing with various combinations, especially when NMI is done. I want to implement feature where NMI can take over an IRQ in progress as long as vector hasn't been fetched yet.

Code: Select all

         16 DECODE AB:0410 DB:e8 DO:55 PC:0410 IR:e8 WE:1 M:e8 S:ff A:41 X:10 Y:03 AI:10 BI:00 CI:1 OP: 1 ALU:11 CO:0 IRQ:00 P:--B---- (0)
         17 DECODE AB:0411 DB:e8 DO:55 PC:0411 IR:e8 WE:1 M:e8 S:ff A:41 X:11 Y:03 AI:11 BI:00 CI:1 OP: 1 ALU:12 CO:0 IRQ:00 P:--B---- (0)
         18 DECODE AB:0412 DB:e8 DO:55 PC:0412 IR:e8 WE:1 M:e8 S:ff A:41 X:12 Y:03 AI:12 BI:00 CI:1 OP: 1 ALU:13 CO:0 IRQ:10 P:--B---- (0)
         19 DECODE AB:0413 DB:a1 DO:55 PC:0413 IR:e8 WE:1 M:e8 S:ff A:41 X:13 Y:03 AI:13 BI:00 CI:1 OP: 1 ALU:14 CO:0 IRQ:11 P:--B---- (0)
         20 DECODE AB:0413 DB:a1 DO:55 PC:0413 IR:00 WE:1 M:a1 S:ff A:41 X:14 Y:03 AI:ff BI:00 CI:0 OP: 0 ALU:ff CO:0 IRQ:11 P:------- (1)
         21   STK0 AB:01ff DB:04 DO:04 PC:0413 IR:00 WE:0 M:a1 S:ff A:41 X:14 Y:03 AI:ff BI:ff CI:0 OP: 1 ALU:fe CO:1 IRQ:11 P:------- (1)
         22   STK1 AB:01fe DB:13 DO:13 PC:0413 IR:00 WE:0 M:a1 S:fe A:41 X:14 Y:03 AI:fe BI:ff CI:0 OP: 1 ALU:fd CO:1 IRQ:11 P:------- (1)
         23   STK2 AB:01fd DB:20 DO:20 PC:0413 IR:00 WE:0 M:a1 S:fd A:41 X:14 Y:03 AI:fd BI:ff CI:0 OP: 1 ALU:fc CO:1 IRQ:11 P:------- (1)
         24   IND0 AB:fffe DB:20 DO:55 PC:0413 IR:00 WE:1 M:a1 S:fc A:41 X:14 Y:03 AI:55 BI:00 CI:0 OP: 1 ALU:55 CO:0 IRQ:10 P:----I-- (1)
         25   ABS0 AB:ffff DB:f0 DO:55 PC:ffff IR:00 WE:1 M:20 S:fc A:41 X:14 Y:03 AI:20 BI:00 CI:0 OP: 1 ALU:20 CO:0 IRQ:10 P:----I-- (1)
         26  FETCH AB:f020 DB:40 DO:55 PC:ffff IR:00 WE:1 M:f0 S:fc A:41 X:14 Y:03 AI:55 BI:00 CI:0 OP: 1 ALU:55 CO:0 IRQ:00 P:----I-- (1)
         27 DECODE AB:f021 DB:20 DO:55 PC:f021 IR:40 WE:1 M:00 S:fc A:41 X:14 Y:03 AI:fc BI:00 CI:1 OP: 1 ALU:fd CO:0 IRQ:00 P:--B-I-- (1)
         28   STK0 AB:01fd DB:20 DO:f0 PC:f022 IR:40 WE:1 M:20 S:fd A:41 X:14 Y:03 AI:fd BI:00 CI:1 OP: 1 ALU:fe CO:0 IRQ:00 P:--B-I-- (1)
         29   STK1 AB:01fe DB:13 DO:22 PC:f022 IR:40 WE:1 M:20 S:fe A:41 X:14 Y:03 AI:fe BI:00 CI:1 OP: 1 ALU:ff CO:0 IRQ:00 P:--B---- (1)
         30   STK2 AB:01ff DB:04 DO:30 PC:f022 IR:40 WE:1 M:13 S:ff A:41 X:14 Y:03 AI:13 BI:00 CI:0 OP: 1 ALU:13 CO:0 IRQ:00 P:--B---- (1)
         31  FETCH AB:0413 DB:a1 DO:55 PC:f022 IR:40 WE:1 M:04 S:ff A:41 X:14 Y:03 AI:55 BI:00 CI:0 OP: 1 ALU:55 CO:0 IRQ:00 P:--B---- (1)
         32 DECODE AB:0414 DB:10 DO:55 PC:0414 IR:a1 WE:1 M:00 S:ff A:41 X:14 Y:03 AI:55 BI:00 CI:0 OP: 1 ALU:55 CO:0 IRQ:00 P:--B---- (0)
         33    ZP0 AB:0010 DB:00 DO:55 PC:0415 IR:a1 WE:1 M:10 S:ff A:41 X:14 Y:03 AI:14 BI:10 CI:0 OP: 1 ALU:24 CO:0 IRQ:00 P:--B---- (0)
         34    ZP1 AB:0024 DB:00 DO:55 PC:0415 IR:a1 WE:1 M:10 S:ff A:41 X:14 Y:03 AI:14 BI:10 CI:1 OP: 1 ALU:25 CO:0 IRQ:00 P:--B---- (0)
         35   ABS0 AB:0025 DB:00 DO:55 PC:0415 IR:a1 WE:1 M:00 S:ff A:41 X:14 Y:03 AI:00 BI:00 CI:0 OP: 1 ALU:00 CO:0 IRQ:00 P:--B---- (0)
         36   DATA AB:0000 DB:00 DO:55 PC:0415 IR:a1 WE:1 M:00 S:ff A:41 X:14 Y:03 AI:55 BI:00 CI:0 OP: 1 ALU:55 CO:0 IRQ:00 P:--B---- (0)
         37  FETCH AB:0415 DB:00 DO:55 PC:0415 IR:a1 WE:1 M:00 S:ff A:41 X:14 Y:03 AI:00 BI:00 CI:0 OP: 0 ALU:00 CO:0 IRQ:00 P:--B---- (0)

The 2 digits after IRQ mean that IRQ is present/is taken. The B flag shows whether IRQ is in progress. Edit: also added reset. I'll do NMI some other time.