Opinions on schematic

[cbmeeks]

I'm basically designing the SB2.5 in Kicad (learning Kicad as I go).

I will be adding on to the design with an audio chip, etc.

But for now, I have the CPU, RAM/ROM, glue, etc.

I would welcome any opinions on the design. Again, this isn't really my design at the moment but it will evolve into something a little more to my needs.

I will include the VIA's, serial, etc. at a later date.

Any opinions greatly appreciated!

[BigDumbDinosaur]

cbmeeks wrote:

I'm basically designing the SB2.5 in Kicad (learning Kicad as I go)...Any opinions greatly appreciated!

1. Your CLK2 signal is being derived from the PHI2out pin of the 65C02. I suggest that SYSCLK (aka Ø2) and CLK2 be one and the same. WDC does not recommend use of either of the MPU's clock outputs in new designs and in fact, obscure timing problems may arise in some cases due to PHI2out lagging the MPU clock input by an unspecified amount. Those clock outputs were meant only for retrofitting the 65C02 to an older system using an NMOS 6502.
2. I see a 74LS138 specified for a decoder. That should be a 74AC138 (first choice) or 74HC138. 74LS logic should not be used with new designs, especially with CMOS parts. You may run into issues with weak fanout, and the inability of 74LS devices to, in some cases, drive CMOS inputs high enough to produce a valid logic one condition.
3. Similarly, U3 is specified as a 7400. I suggest a 74AC00 or 74HC00.
4. Pin 2 of U3 (shown on U3A) should be connected to SYSCLK, as should pin 10 (U3C), in line with suggestion number 1, above. The change to U3A will qualify the /MRD signal with Ø2, which means a device that has been selected during a read cycle will not emit anything on the data bus until Ø2 has gone high.
   
   A little more explanation: devices that have separate /OE inputs, e.g., your ROM, are usually a little "quicker on the draw" if /CS is asserted before /OE (read the timing specs to see what I mean). Also, as presently designed, your circuit will cause a device to start driving D0-D7 while Ø2 is still low and while the address bus may still be settling down. With the change I suggested, selection will come as soon as the 'C02 drives the proper address onto the address bus, which happens while Ø2 is still low, but /OE will not be asserted until Ø2 goes high.
5. Lacking a memory map, I can't be certain if your decoding scheme makes sense. Use of that slow 7430 NAND gate is something to be avoided. Please post a memory map so we can make some suggestions.
6. Although not essential, your Ø2 clock is best derived from a flip-flop that is driven by the clock oscillator. It's not uncommon for a can oscillator's output to exhibit some deviation from a 50 percent duty cycle. At lower Ø2 rates, such deviation is usually unimportant, but at higher clock rates, may lead to an inadvertent timing violation. A flop will eliminate that variable from your timing picture and also produce a "squarer" signal. A 74AC74 flop is recommended. Naturally, the oscillator frequency will have to be twice that of the desired Ø2 frequency.

[floobydust]

The circuit shown is pretty much identical to Daryl's SBC2.5 CPU/Memory/Decode section, so it would work. I did a similar design back in the late 80's using the same chip combo but 74HCT logic at the time. I use page $FE00 for the I/O. My current version retains this but uses 74HC logic and has run at 8MHz without issue using all WDC chips.

This said, I would agree with BDD's comments on the clock source, chip selection, etc. The "implied" memory map is pretty simple, ROM is from $8000 - $FFFF. Ram is from $0000 - $7EFF and the I/O decode from the 7430 is page $7F00. However, the 74138 chip won't be active as you have the enable lines configured incorrectly. E3 needs to be active high or no I/O selects will occur. In short, you should swap E1 and E3 and you'll have the same I/O decodes as Daryl's SBC 2.5.

http://sbc.rictor.org/sch2.html

[BigDumbDinosaur]

floobydust wrote:

In short, you should swap E1 and E3 and you'll have the same I/O decodes as Daryl's SBC 2.5.

Hmm...didn't see that for some reason. Good catch.

[floobydust]

BigDumbDinosaur wrote:

floobydust wrote:

In short, you should swap E1 and E3 and you'll have the same I/O decodes as Daryl's SBC 2.5.

Hmm...didn't see that for some reason. Good catch.

I probably stared at it longer... plus it's pretty close to my own CPU board

[cbmeeks]

Everyone, thanks for the suggestions! You guys are great.

I have updated the PDF file on the original post.

I believe I have addressed most of the issues mentioned. First, the LS parts were just a foobar on my end. I always meant to use faster components.

I have upgraded the components to reflect that.

One that I was unsure of was the 8 input NAND. The fastest one I could find that wasn't near end-of-life was the 74F30. I believe it's a 5.5ns part and was reasonably cheap at Mouser. Not sure about the "F" part though.

Another recommendation that BDD mentioned was the counter/clock circuit. I've actually been thinking about doing that anyway. Perhaps putting a 4040 counter in there clocked pretty high and putting jumpers from the outputs to the CLK. That way, the user can jumper different speeds to the CPU and other fan-outs. I will work on that part next.

Oh, I think I fixed the memory decoding too. I had simply wired it wrong. I'm glad you guys caught that!

Finally, there is a memory map on there too. But it's Daryl's design so:

Code: Select all

$0000 - $7FFF RAM
$7F00 - $7FFF I/O
$8000 - $FFFF ROM

Any other suggestions are greatly appreciated.

Thanks!!!

[floobydust]

I would make a few other changes:

1- Clock rate: pick one... the main reason to change clock rates is the memory and I/O device limitations.
- a counter would give you multiple clock rates accessible, but you can also swap out the clock oscillator.
- a flip-flop (like BDD uses) will give you a true 50/50 duty-cycle clock, which is a plus.
2- I would change the I/O addressing so the selects are 32-bytes wide instead of 16-bytes wide. More options on I/O devices.
- you can use a pair of 65C22 VIAs with a single I/O select and a single inverter gate.
- you can use larger I/O devices, like a quad UART (again, a BDD approach).
3- Perhaps a NMI trigger (with another DS1813) so you can use it as a panic routine.
4- Add a RW-RO jumper for the EEPROM so you can write code to it insitu.
- I have this option on my CPU board and my monitor support supports it, nice to have.

Okay more than a few... but overall, will give you a more flexible CPU board.

[Aslak3]

Some of this aseptic. I'm not sure if you are after that kind of comment, but here you go anyway.

I miss busses. The CPU, ROM and RAM could easily be "bussed together". I personally feel this is clearer then lots and lots of labels, which run the risk of reducing the schematic to a netlist.

You have big AND gates.

My own preference is to draw the decouplers in their own "block" and put the pullups with the associated part.

floobydust wrote:

I would make a few other changes:
- you can use larger I/O devices, like a quad UART (again, a BDD approach).

These can be a lot of work though, with PLCC parts etc. Alternatively there are some nice DUARTs available, and if you hunt around you will find some in DIP.

Quote:

4- Add a RW-RO jumper for the EEPROM so you can write code to it insitu.
- I have this option on my CPU board and my monitor support supports it, nice to have.

Definitely strongly recommended. I can even work on my own ROM remotely, which is handy.

[cbmeeks]

Minor update. I hope to finish much more this weekend.

I've updated the original PDF.

This update has a 74AC74 flip-flop tied to the OSC and O2. I pulled the circuit from Daryl's clock primer. Hope I did it right.

I also added a jumper block for WE on the ROM. I hope I did that right. But how would I program in-circuit? Is there a tutorial out there for that? I have one of those chip programmers that I use. So I'm not sure how I would do that. Unless the point is to have the 65C02 update ROM.

Aslak3 wrote:

I miss busses. The CPU, ROM and RAM could easily be "bussed together". I personally feel this is clearer then lots and lots of labels, which run the risk of reducing the schematic to a netlist.

I need to learn how to properly do buses in KiCad. I think the lines going out to the thick bar looks pretty good. I don't think it's hard to do...I just haven't even tried. But I will look into that and see what I can do.

Aslak3 wrote:

You have big AND gates.

LOL. Yeah, I thought so too. But, those came straight out of the KiCad library. I haven't bothered to redo them. Then again, I have poor eyesight.

Aslak3 wrote:

My own preference is to draw the decouplers in their own "block" and put the pullups with the associated part.

I don't like the way I represent the pull-ups. I actually like the caps near the component because in my head, it makes it easier to know they're there.


Suggestions always welcomed.

Thanks again!!

[Aslak3]

Quote:

I also added a jumper block for WE on the ROM. I hope I did that right. But how would I program in-circuit? Is there a tutorial out there for that? I have one of those chip programmers that I use. So I'm not sure how I would do that. Unless the point is to have the 65C02 update ROM.

Yeap, the CPU would do it. You have to be careful, obviously. Timing rules need to be honoured, and you cannot (generally) rewrite the same space your are running the reprogramming routine from. On my micro I copy the reprogramming routine to RAM, then run it from there. The schematic looks good.

Quote:

I need to learn how to properly do buses in KiCad. I think the lines going out to the thick bar looks pretty good. I don't think it's hard to do...I just haven't even tried. But I will look into that and see what I can do.

Busses are just "graphical niceness" in KiCAD. The wire has the netlist name, instead of a label.

Quote:

...Then again, I have poor eyesight.

Me too.

Quote:

I don't like the way I represent the pull-ups. I actually like the caps near the component because in my head, it makes it easier to know they're there.

Yes, that's a very good reason to place them nearby in the schematic. Being lazy, I just add a whole bunch to the schematic and then when it comes time to lay out the board, just drag any old cap footprint to the right place to make sure each IC has one.

[floobydust]

Writing to the EEPROM insitu is fairly simple. You should reference the datasheet for the device you're using. I've been using the Atmel 28C256 EEPROM. It supports a byte write and a page write mode. In my monitor (which is posted out here) I use byte write mode and use the toggle bit for sensing which ensures the write has completed.

Note however, that the code that writes to the EEPROM can NOT be located in the EEPROM, as you don't have access while the chip completes the write cycle (which can be upwards of 10ms). You also need to turn interrupts off during the write sequence as well. My code sets up the variables, copies the byte write routine from ROM to RAM and makes JSR calls to write each byte, which also verifies the write. In short, I'm copying data from RAM to EEPROM.

[jgroth]

floobydust wrote:

2- I would change the I/O addressing so the selects are 32-bytes wide instead of 16-bytes wide. More options on I/O devices.
- you can use a pair of 65C22 VIAs with a single I/O select and a single inverter gate.
- you can use larger I/O devices, like a quad UART (again, a BDD approach).

How would you modify Daryl's SBC 2.5 decoding logic to do that?
Is it enough to remove the A4 line from the 138 and move the rest of the lines up one pin on the 138, if that makes any sense and then ground /E2?