BB816 Computer YouTube Series

[BigDumbDinosaur]

akohlbecker wrote:

I'm curious to hear what the problems are with using RDY for wait states?

The two linked topics go into considerable detail but in a nutshell, anything in a 65C816 system slaved to Ø2 will not behave as expected when RDY is driven low. While the MPU's internal clock will stop in the high (data) phase, that has no effect beyond the MPU. Other devices that are gated with Ø2 or its inversion, or controlled by logic that includes Ø2 as a qualifier, will synchronously oscillate between states. This is particularly a problem with the bank bits latch, but that is not the only possible area of trouble. The first of the two topics I linked describes three different scenarios, two of which are not unique to the 65C816.

[akohlbecker]

Thank you for the details! Making sure the latch and the buffer are in the correct state while asserting RDY was the subject of the last few episodes, you can see how I handled it in the circuit I posted above.

I haven't talked yet about my plans for chip selects and read/write pulses but they work with RDY as well (chip selects being statically mapped to addresses and pulses being gated with RDY).

I agree that some care needs to be taken especially around timings but it is not that bad.

[BigDumbDinosaur]

akohlbecker wrote:

Thank you for the details! Making sure the latch and the buffer are in the correct state while asserting RDY was the subject of the last few episodes, you can see how I handled it in the circuit I posted above.

I haven't talked yet about my plans for chip selects and read/write pulses but they work with RDY as well (chip selects being statically mapped to addresses and pulses being gated with RDY).

I agree that some care needs to be taken especially around timings but it is not that bad.

In the 65C816, I generally view RDY as an artifact that was included to support 65C02 emulation mode (RDY is close to useless on the NMOS processors—the MPU won't stop during a write cycle). There are several aspects of the 816's hardware that exist due to Apple have a lot of say-so in the MPU's design. For example, the 816's bus behavior is that of the NMOS 6502, a "feature" that was demanded by Apple so the 816 would work with their idiosyncratic disk drive controller (which was not one of Wozniak's shining examples of electronics design, in my opinion). Bill Mensch thoughtfully include VDA and VPA so designers who weren't relying on NMOS-style dummy bus accesses had a way to prevent them from affecting the hardware.

As an output, RDY could be useful, since it gets driven low while the 816 is executing WAI. In a preemptive, multitasking kernel driving a system with the right sort of glue logic, a process could relinquish its time quantum by executing WAI, which would then cause the glue logic to immediately trigger an IRQ to bring about a context switch.

I used clock-stretching in my POC V1.2, 1.3 and 2.0 units. RDY is unused in all of them.

[AndrewP]

BigDumbDinosaur wrote:

...before you go off on a tangent with a FIFO and use a battleship to sink a rowboat.

But what if I want to use a battleship to sink rowboats, that's normal right. Right?

Although I don't want to hi-jack Adrien's thread too much but I did misunderstand what you meant by extended memory. I thought you meant meant an SD card or slow ROM or even a UART or something. My actual address decoding is so ridiculously ridiculous that I need to test real timings before I post anything to this forum. (my still unplanned plan with the FIFO is to use it for keyboards, mouses, game-controllers etc...).

[BigDumbDinosaur]

AndrewP wrote:

BigDumbDinosaur wrote:

...before you go off on a tangent with a FIFO and use a battleship to sink a rowboat.

But what if I want to use a battleship to sink rowboats, that's normal right. Right?

Well, I was in the Navy and most of the time, we'd use the right-sized weapon for the job. But, once in a while, a certain amount of overkill got into the picture.

BTW, the muzzle blast from just one of a battleship's 16 inch guns is so powerful it would literally blow a small boat out of the water without the projectile having to hit anything.

Quote:

Although I don't want to hi-jack Adrien's thread too much but I did misunderstand what you meant by extended memory. I thought you meant meant an SD card or slow ROM or even a UART or something. My actual address decoding is so ridiculously ridiculous that I need to test real timings before I post anything to this forum. (my still unplanned plan with the FIFO is to use it for keyboards, mouses, game-controllers etc...).

For clarity in my 65C816 designs, I use the term "basic RAM" to refer to bank $00 RAM below the I/O block, "high RAM" to refer to any bank $00 RAM that is above the I/O block, and "extended RAM" to refer to RAM that is not in bank $00. If a 65C816 system has extended RAM it is implied that bank latching hardware is present and so are the foibles associated with using RDY to wait-state the MPU.

[akohlbecker]

Episode 8 is online!

In this episode, I start building the clock module. I have bigger goals for this module than just running my 65C816 as I plan to re-use this design elsewhere, so you could say this will be a mini-series within the series:

• 3 clocks: fast, slow, pulse
  • Fast: from ~1MHz to 14MHz via DIP switch (progressively ramp up the speed and reach 14Mhz)
  • Slow: from 0.5Hz to 500Hz via potentiometer (for blinking lights!)
  • Pulse: one clock pulse per button press (for single stepping)
• 2 selection buttons: mode (free running / pulse), speed (fast / slow)
• Clean clock switching (no switching in the middle of a cycle)
• HALT line (stops the clock until RESET)
• BRK line (switches to pulse mode)
• Power up behaviour configurable via DIP switch (=which mode and speed on power up)
• Output stage is a flip flop
  • Clean 50/50 duty cycle
  • Synchronised ~CLK

In this episode I also discuss logic family choice (between HC, AC, AHC as a clock driver specifically), and talk a bit about hardware switch de-bouncing.

As always, hopeful that you find this interesting!

[BigEd]

Clean clock switching is a good thing to have mastered!

[akohlbecker]

BigEd wrote:

Clean clock switching is a good thing to have mastered!

Thanks! I think I have a pretty good design, coming in episode 11.

In the meantime, I released Episode 9 last week, which goes further into the clock module. I added a multiplexer to select between the clocks (not in a clean way yet), and implemented the fast clock divider. Had some issues with the fast clock when trying to go to 14MHz (and running my counter at 28MHz, which was a bit too high), so I'll need to go back to the drawing board and I stayed at 10Mhz for now.

This is what the clock looks like now

[BigDumbDinosaur]

akohlbecker wrote:

This is what the clock looks like now

WDC specifies that the rise/fall time for the Ø2 clock should not exceed 5ns. That's generally not achievable with 74HC logic.

[akohlbecker]

BigDumbDinosaur wrote:

akohlbecker wrote:

This is what the clock looks like now

WDC specifies that the rise/fall time for the Ø2 clock should not exceed 5ns. That's generally not achievable with 74HC logic.

Interesting, I was investigating this number and found this AHC/AHCT Designer’s Guide from TI that shows the slew rates of HC, AC and AHC gates:

Based on these numbers and assuming a 10% to 90% rise I'm getting the following rise/fall times, which shows HC being ≤ 5ns.

Do you have another source I could look at that point to the contrary?

[GARTHWILSON]

They seem to be tunnel-visioned on the '244 and '245. If you look at their data sheet for the 74HC74 (which you're using in your clock circuit), table 6.6, you'll see a max transition time of 13ns @ 6V and 25°C, up to 22ns @ 4.5V and -55°C to 125°C, both with a load capacitance of 50pF which is probably in the ballpark for what you'll be driving with it. It might work, but it's definitely not guaranteed to.

[BigDumbDinosaur]

akohlbecker wrote:

Based on these numbers and assuming a 10% to 90% rise I'm getting the following rise/fall times, which shows HC being ≤ 5ns.

As Garth said, TI used a single piece of logic (the '244) as an (atypical) example. The slew rates they tabulate in that graphic don't agree with the curves and in the case of 74HC, I know from observation and experience that a slew rate of ~5ns rail-to-rail not attainable in a practical application.

Although I mostly recommend the use of 74AHC logic with new builds—the prop times are comparable to 74AC, but slew rates are less aggressive, the clock generator flip-flop is an exception—74AC continues to be my choice there. Some series resistance between the flop's outputs and the rest of the circuit can mitigate ringing, which may be a significant problem on a breadboard. I've found 100-120 ohms is usually sufficient. A pair of fast Schottky diodes on the outputs may also help suppress ringing, although resorting to that technique usually isn't necessary on a well-designed PCB.

[akohlbecker]

GARTHWILSON wrote:

They seem to be tunnel-visioned on the '244 and '245. If you look at their data sheet for the 74HC74 (which you're using in your clock circuit), table 6.6, you'll see a max transition time of 13ns @ 6V and 25°C, up to 22ns @ 4.5V and -55°C to 125°C, both with a load capacitance of 50pF which is probably in the ballpark for what you'll be driving with it. It might work, but it's definitely not guaranteed to.

Do you think different gates in the same family can have varying output characteristics? I was assuming they didn't.
Interesting point about that transition time. I've since then switched to a 74HC151 as output driver but the figure is comparable. I might have to go to a 74AC151 then, even though that one doesn't have a published transition time figure...

BigDumbDinosaur wrote:

akohlbecker wrote:

Based on these numbers and assuming a 10% to 90% rise I'm getting the following rise/fall times, which shows HC being ≤ 5ns.

As Garth said, TI used a single piece of logic (the '244) as an (atypical) example. The slew rates they tabulate in that graphic don't agree with the curves and in the case of 74HC, I know from observation and experience that a slew rate of ~5ns rail-to-rail not attainable in a practical application.

Although I mostly recommend the use of 74AHC logic with new builds—the prop times are comparable to 74AC, but slew rates are less aggressive, the clock generator flip-flop is an exception—74AC continues to be my choice there. Some series resistance between the flop's outputs and the rest of the circuit can mitigate ringing, which may be a significant problem on a breadboard. I've found 100-120 ohms is usually sufficient. A pair of fast Schottky diodes on the outputs may also help suppress ringing, although resorting to that technique usually isn't necessary on a well-designed PCB.

Good suggestion to add series termination

[akohlbecker]

Ok, I need to be more diligent about posting updates here as I publish my videos, I'm two episodes behind.

In Episode 10 - Power-up Reset I build a power-up circuit using a MAX705. Even though I used a DS1813 in my 6502 build, I like the MAX705 here for its watchdog, and separate manual reset input.
I also had to make sure that reset pulses would be registered by the CPU even if I'm running with a slow or manual clock. For that I chained the reset through 3 flip flops, to ensure it stays low for at least 2 full clock cycles.

Here is the final reset circuit:

Next, in Episode 11 - Clock Module #3, I went back to the clock circuit and added glitch-free clock switching. By relying on the property that my clocks have vastly different frequencies, I'm able to ensure I always switch when a low-cycle of the destination clock begins and overlaps with a low cycle of the active clock. For that, I used a chain of negative edge triggered JK flip flops. I also had to change my output stage to a 74HC151 multiplexer, which is nice because it keeps the inverted output I had on the 74HC74

I also added a dip switch to select which clock mode and speed the circuit boots in on power up, so I can change it based on what I'm doing (hardware, software...)

Here is the current clock circuit

Next episode will be about starting up the CPU (finally, yay!) using a NOP generator.

[akohlbecker]

I have done some measurements on rise times, to compare a 74HCT151, 74AC151 and 74AC151 + 100 ohms series termination. My oscilloscope might not be good enough for this measurement (100MHz bandwidth), so take this with a grain of salt:

74HCT151

74AC151

74AC151 + 100 ohms termination

Looks like switching to AC reduces the rise time a bit (14ns->10ns) but then adding termination increases it (10ns->20ns).
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?