BB816 Computer YouTube Series

[GARTHWILSON]

akohlbecker wrote:

How much should I trust these measurements? Probably not much based on the bandwidth of my oscilloscope and the fact that this is on the breadboard?

It will be difficult to know what the IC is really capable of when it's on a solderless breadboard like this. You are, correctly, putting the probe and its ground pretty close to the IC; but pulling up requires the IC to have a good VDD connection, which it does not, because of all the inductance there from long connections. At a minimum, there should be a power-supply bypass capacitor across the IC (and no, putting it out at the red and blued rails is not close enough), and there should be power and ground jumpers across the rows, between the ends, so a signal's power/ground return current doesn't have to go out to the rail, down to the end, and up another strip, and over to another IC being interfaced to. 74AC(T)'s transition times are quite a lot faster than 74HC(T)'s, making them less friendly to solderless breadboards and other point-to-point wiring. Also, if multiple outputs have to change at once, in the same direction (like all going up, or all going down), it will make the problem worse.

[BigDumbDinosaur]

akohlbecker wrote:

...My oscilloscope might not be good enough for this measurement (100MHz bandwidth)...How much should I trust these measurements? Probably not much based on the bandwidth of my oscilloscope and the fact that this is on the breadboard?

You can take my word for it when I say output transition times seen with 74AC logic are well down in the single digit nanosecond range. My 275 MHz scope, when it was healthy, indicated a 74AC04 could switch its outputs from one state to the other at a rate the scope was unable to display—testing being done with a compensated probe and the scope being triggered by the AC04's input signal. 275 MHz is a cycle time of 3.6ns. Given that your scope is 100 MHz, I feel safe in saying you are not seeing what is actually occurring.

The type of series resistor you use on your outputs has an effect over and above its resistance. Some fabrication methods cause the resistor to insert small but potentially troublesome amounts of inductance in series with the load. A 10K resistor might look like 10K at audio frequencies, but might appear to be 10-20 percent higher in the MHz range (incidentally, this is one of the reasons why I keep mentioning that using 10K for pullups is not good). Also, the resistor's leads add inductance, which is one of the reasons chip resistors are used on commercially-produced computer PCB assemblies.

As Garth notes, a breadboard is a dubious environment in which to try to achieve what you want. You can't control the propagation times through the board itself, which will get in the way. As Garth says, you are dealing with quite a bit of inductance with all those wires and such. What is coming out the far end is not what is going in the near end. Adding to the mayhem is the poor power distribution typical of breadboards.

Ultimately, you are going to have to commit to use of a PCB if you want to achieve reliable, high-speed performance.

[akohlbecker]

GARTHWILSON wrote:

akohlbecker wrote:

How much should I trust these measurements? Probably not much based on the bandwidth of my oscilloscope and the fact that this is on the breadboard?

It will be difficult to know what the IC is really capable of when it's on a solderless breadboard like this. You are, correctly, putting the probe and its ground pretty close to the IC; but pulling up requires the IC to have a good VDD connection, which it does not, because of all the inductance there from long connections. At a minimum, there should be a power-supply bypass capacitor across the IC (and no, putting it out at the red and blued rails is not close enough), and there should be power and ground jumpers across the rows, between the ends, so a signal's power/ground return current doesn't have to go out to the rail, down to the end, and up another strip, and over to another IC being interfaced to. 74AC(T)'s transition times are quite a lot faster than 74HC(T)'s, making them less friendly to solderless breadboards and other point-to-point wiring. Also, if multiple outputs have to change at once, in the same direction (like all going up, or all going down), it will make the problem worse.

BigDumbDinosaur wrote:

akohlbecker wrote:

...My oscilloscope might not be good enough for this measurement (100MHz bandwidth)...How much should I trust these measurements? Probably not much based on the bandwidth of my oscilloscope and the fact that this is on the breadboard?

You can take my word for it when I say output transition times seen with 74AC logic are well down in the single digit nanosecond range. My 275 MHz scope, when it was healthy, indicated a 74AC04 could switch its outputs from one state to the other at a rate the scope was unable to display—testing being done with a compensated probe and the scope being triggered by the AC04's input signal. 275 MHz is a cycle time of 3.6ns. Given that your scope is 100 MHz, I feel safe in saying you are not seeing what is actually occurring.

The type of series resistor you use on your outputs has an effect over and above its resistance. Some fabrication methods cause the resistor to insert small but potentially troublesome amounts of inductance in series with the load. A 10K resistor might look like 10K at audio frequencies, but might appear to be 10-20 percent higher in the MHz range (incidentally, this is one of the reasons why I keep mentioning that using 10K for pullups is not good). Also, the resistor's leads add inductance, which is one of the reasons chip resistors are used on commercially-produced computer PCB assemblies.

As Garth notes, a breadboard is a dubious environment in which to try to achieve what you want. You can't control the propagation times through the board itself, which will get in the way. As Garth says, you are dealing with quite a bit of inductance with all those wires and such. What is coming out the far end is not what is going in the near end. Adding to the mayhem is the poor power distribution typical of breadboards.

Ultimately, you are going to have to commit to use of a PCB if you want to achieve reliable, high-speed performance.

Thank you both for the tips and for sharing your experience. It is much appreciated.

To be clear, I don't disagree with your statements/experience. I'm trying to find something more scientific I could show the viewers of the series to say ok this is why I'm switching families and why you should too. Unfortunately, literature on this is scarce, and I can't just say because BigDumbDinosaur said so So this is why I'm trying to measure it somehow. Maybe it is a fool's errand I could build a PCB for this measurement, but then I need to get my hands on a better scope

[Dr Jefyll]

BigDumbDinosaur wrote:

As Garth notes, a breadboard is a dubious environment in which to try to achieve what you want. [...] Ultimately, you are going to have to commit to use of a PCB if you want to achieve reliable, high-speed performance.

I think that's overstating the matter. I agree that many of the worst project implementations we've seen use a breadboard, and many of the best implementations use a PCB. But that's by no means a rule. On this forum we've also seen breadboard projects that perform remarkably well, as well as the odd PCB that was done poorly.

Also, let's not forget wire wrap and point-to-point techniques, both of which can be very effective. For example my KK Computer is wire wrapped, and its clock generation and video sections run reliably at 80 MHz.

Where high-speed performance is concerned, a great deal depends on the builder's attention to detail regarding return paths and supply bypassing, as well as the properties of the chips that are chosen. IMO these factors carry more weight than the wiring method used.

akohlbecker, I see you've posted as I was writing this, but I don't think there's anything I need to add or change.

-- Jeff

[AndrewP]

I just thought I'd pop in and mention I noticed Episode 12 is out. Still really enjoying them, thanks

And just whilst I'm here a quick question with probably not a quick answer. Pull resistors... What pull resistors are you using on which pins? I seem to need a pull down resistor on both VPA and VDA and a pull up resistor on VPB. I also seem to need a set of pull down resistors on the address pins A0...15 but I'd like to know what values you use. And also if you have any pull resistors on the BA/D pins? Ta muchly!

[BigDumbDinosaur]

AndrewP wrote:

I seem to need a pull down resistor on both VPA and VDA and a pull up resistor on VPB. I also seem to need a set of pull down resistors on the address pins A0...15 but I'd like to know what values you use.

You don't need resistors on any of those signals, as they are driven at all times by the 65C816. CMOS inputs almost always require being driven to ground or VCC to avoid bad things that might happen due to noise.

[akohlbecker]

Episode 13 is out!

In this episode, I design the memory map of the CPU, and I simulate a first version of address decoding circuit in Digital. Based on the propagation delays in this circuit, I now have a max frequency! In the next episode, coming end of the week, I'll be adding some ROM.

Right now the address decoding uses an obsolete 74HC4078. I'm working on a design without this chip that will come in a later episode.
As always, let me know if you have any questions

[akohlbecker]

AndrewP wrote:

I just thought I'd pop in and mention I noticed Episode 12 is out. Still really enjoying them, thanks

And just whilst I'm here a quick question with probably not a quick answer. Pull resistors... What pull resistors are you using on which pins? I seem to need a pull down resistor on both VPA and VDA and a pull up resistor on VPB. I also seem to need a set of pull down resistors on the address pins A0...15 but I'd like to know what values you use. And also if you have any pull resistors on the BA/D pins? Ta muchly!

Thank you!

I have pull-ups on BE, RDY, IRQB, NMIB, ABORTB. You might not need any of them if you don't plan on using these pins, you can just tie them to VCC. Except for RDY which can be an output, this one you want to pull up with a resistor even if you're not using it. I also have a pull-up on RDY because it can be tri-stated by BE, but you can skip if you don't plan on using BE.
I also have pull-ups on the address pins, only because I plan to use BE to tri-state them. You can most likely leave them out.
Finally, I have pull-downs on the data bus, because it is only driven during half of the clock cycle. You might not need that if you run fast enough due to bus capacitance. If you plan on stopping the clock though, they're useful.

As for values, I personally use 10K for now, but switching to 3.3K has been recommended to me.

[BigDumbDinosaur]

akohlbecker wrote:

In this episode, I design the memory map of the CPU, and I simulate a first version of address decoding circuit in Digital. Based on the propagation delays in this circuit, I now have a max frequency! In the next episode, coming end of the week, I'll be adding some ROM.

Why the big gap in the extended memory map? Glue logic would be less complex (and faster) if extended memory starts right at $010000.

Also, I'd make the I/O window larger. A small I/O window will cost you in cascaded logic and long prop delays.

Quote:

Right now the address decoding uses an obsolete 74HC4078. I'm working on a design without this chip that will come in a later episode.

Take a look at a 74ACT11030, which is much faster. You can use it place of that 74HC30 as well, which is also a slow device. See attached data sheet.

74act11030_nand_8input.pdf

74ACT11030 8-Input NAND

(387.73 KiB) Downloaded 82 times

[akohlbecker]

BigDumbDinosaur wrote:

Why the big gap in the extended memory map? Glue logic would be less complex (and faster) if extended memory starts right at $010000.

Designed it this way so I can just look for 00001 as a prefix. Curious how would you do it with $010000? Match 00000 and ignore the first bank?

BigDumbDinosaur wrote:

Also, I'd make the I/O window larger. A small I/O window will cost you in cascaded logic and long prop delays.

At this point, the limiting factor in prop delays is the latching and bank0 detection so I have some margin in the lower address bits handling to implement a smaller I/O range.

BigDumbDinosaur wrote:

Quote:

Right now the address decoding uses an obsolete 74HC4078. I'm working on a design without this chip that will come in a later episode.

Take a look at a 74ACT11030, which is much faster. You can use it place of that 74HC30 as well, which is also a slow device. See attached data sheet.

74act11030_nand_8input.pdf

Thanks for the tip, I did mention this chip in the video, and would probably use it if I needed the speed (though it is expensive at 3€ a pop ), but my goal right now is to run at 4MHz so I have some leeway!

[GARTHWILSON]

akohlbecker wrote:

Finally, I have pull-downs on the data bus, because it is only driven during half of the clock cycle. You might not need that if you run fast enough due to bus capacitance. If you plan on stopping the clock though, they're useful.

If you actually stop the clock, then yes, it could be useful, but a very high resistance will do the job for that, even 100K, if everything is CMOS. (If there's non-CMOS though, even 3.3K may not be enough to pull it down. Unconnected TTL input lines pull up.) As long as you don't stop the clock though, note that With CMOS circuits, when you disable the outputs and nothing else is driving those lines from another source, the capacitance in the board, sockets, etc. will hold the last value for a long time, even milliseconds (not just microseconds or nanoseconds), according to something I observed by accident when I was developing the test for my 10ns 5V 4Mx8 SRAM modules. (This is why you don't have to worry about violating the 65c02's hold times on a read operation after phase 2 falls. The data will be held until something else drives the bus.) I did not try to see how much longer I could go. It was just an interesting observation that was not really related to what I was working on.

[akohlbecker]

Good point on making it a weak pull-up, helps power consumption!

[AndrewP]

akohlbecker wrote:

As for values, I personally use 10K for now, but switching to 3.3K has been recommended to me.

GARTHWILSON wrote:

... even 100K, if everything is CMOS. (If there's non-CMOS though, even 3.3K may not be enough to pull it down. Unconnected TTL input lines pull up

Thanks for the info and suggestions!

[akohlbecker]

Episode 14 is out!

In this episode, I connect my EEPROM and program it with a first program (blinking the Emulation LED). I settled on the ACME assembler, for now. It seems like it has most of what I need including support for the CPU. According to the timing diagram of the ROM, my choice of 4MHz was the right one, as the margin is only a few nanoseconds to be in spec.

As always, let me know if you have any questions!

[akohlbecker]

Episode 15 is out!

In this episode, I discuss the timing of the SRAM, update the glue logic to generate the write pulse, and install the new 32K RAM. I then write a program to test the memory by writing to and reading from all locations. First time writing a 16 bits program