Let's start at the very beginning...

[BigDumbDinosaur]

barnacle wrote:

The bus construct in Kicad doesn't really do anything - since the wires are named at each end anyway, they're automatically connected - but it does simplify tracing the general idea of where a group of signals goes...

Also, busing in that fashion tends to make the drawing less cluttered.  Lack of busing is one of the limitations of the ExpressPCB schematic editor that I use, but I manage to deal with all the lines running every which way.  A bunch of lines still beats a “schematic” that’s a bunch of boxes with netlist tags hanging off of them.

Quote:

grant.pdf

Personally, I like the default Kicad colours but some of our members have difficulty seeing some colours, so I post monochrome as a courtesy.

I’m one of those members, and as I get older, my color perception problem (tritanomaly) is worsening.  White and yellow almost look the same to me.    Pure blue is almost invisible.  At this point in my life, I can’t tell for sure the color of the sky. 

Interestingly, I’ve been staring at electrical schematics for more than sixty years and up until very recently, every one I’ve seen was black on white paper.  I have no idea who it was that suddenly thought color contributes anything to understanding how a circuit is supposed to function.

Back to your design... 

A suggestion...change U1 to a 74AC04 and insert a 120 ohm (or thereabouts) resistor (I use metal film) in series with the output of U1B to keep ringing down to a dull roar.  The reason for the suggestion is WDC specifies that the rise/fall time of the Ø2 clock should not exceed 5 nanoseconds.  74HC (and 74AHC) logic usually can’t meet that requirement.

While on the subject of clocking, WDC recommends that the Ø1 and Ø2 outputs on the 65C02 not be used in new designs.  Those outputs lag the clock input by an unspecified amount and that lag is not even tested in production.  Everything in your circuit that is clocked, e.g., the read/write logic, will be running behind the MPU.  Your clock generator will have more than enough drive to properly clock the entire circuit.

Don’t be dismayed if your reset circuit misbehaves...or if the contacts stick in the push button. 

[BigDumbDinosaur]

DRG wrote:

You're both aligned with my thinking...Consequently, I can confirm my next build is STILL pretty much what I set out in the first post other than (as a consequence of this thread and all the great input and contributions) it'll be a 48K RAM/16K ROM with the I/O at the top of RAM.

Perhaps you should post your new memory map in view of this decision.

Quote:

VIA x2: WDC65C22S6TPG-14

Be aware that the 65C22S has a totem-pole IRQ output.  The 65C22N, on the other hand, has the “traditional” open-collector IRQ output.  That will affect your IRQ circuit design.

Quote:

Glue Logic: 2 x ATF22V10C-10PU

Two?  What is the second one going to do?

Quote:

What I need to do now (I think) is write the new WinCUPL code for the 22V10C for the new memory map and draw the schematic.

I’d draw the schematic first to determine if that second GAL is really needed.

[barnacle]

BDD, I find the yellow shading on a component differentiates it (and the box around it) from both the background and the actual signal wires. It's an immediate signal that 'this is a component!'. But that's just me, perhaps; others' perceptions will obviously vary.

On meeting clock rise times: you will see on the grant.pdf I posted that there is nothing more enthusiastic than a 74hc04 in the clock generator circuit. It certainly doesn't meet the 5ns rise time, but to date I have had no complaints from the 65c02. It's just a counterexample of course, and not something I would do in production... but I wonder how insistent the 65c02 is on that rise time? Datasheets are usually conservative and worst case.

Neil

[BigDumbDinosaur]

barnacle wrote:

...but I wonder how insistent the 65c02 is on that rise time?  Datasheets are usually conservative and worst case.

I suspect that the rise/fall time spec is based upon the need for the MPU’s internal circuits to switch as quickly as possible to maintain published timing.  Since there is no Schmitt action on the clock input, it could be there is a stability issue if rise/fall time is too slow.  I’ve always used 74AC logic in my clock generation, so I don’t have any real-world experience on what happens with a “lazy” clock input.

[BigEd]

I think edges would have to be really slow for a Schmitt input to be of any value.

[barnacle]

Yeah, I'm not pushing the speed limits at 1.8MHz...

Neil

[DRG]

BigDumbDinosaur wrote:

Quote:

VIA x2: WDC65C22S6TPG-14

Be aware that the 65C22S has a totem-pole IRQ output.  The 65C22N, on the other hand, has the “traditional” open-collector IRQ output.  That will affect your IRQ circuit design.

I won't pretend I understand that completely... no, that's not true, actually, I don't understand what that means at all (or the consequences for me)!

BigDumbDinosaur wrote:

Quote:

Glue Logic: 2 x ATF22V10C-10PU

Two?  What is the second one going to do?

Ah, that's an artifact and should read 1 x ATF22V10C-10PU. Although, maybe I could use it to help with the IRQ circuit design!?

I'm thinking my memory map will be as follows...

Code: Select all

C000-FFFF ROM (16k)
DD00-DFFF I/O (0.75k)
0000-DCFF RAM (47.25k)

This should allow me to have A15-A7 fed into the GAL with 128 byte granularity giving a I/O address space of...

Code: Select all

DD00-DD7F IO_0
DD80-DDFF IO_1
DE00-DE7F IO_2
DE80-DEFF IO_3
DF00-DF7F IO_4
DF80-DFFF IO_5

I had A15-A4 previously so I can have more mapped I/O is my thinking since I have much more RAM to "sacrifice" for I/O.

[barnacle]

A totem pole output drives the signal through a pair of transistors: one to ground and one to the rail. At any time the output is active, either one or the other of the transistors is turned on, and is an effective short between the output pin and either Vcc or the ground.

Open collector outputs do away with the transistor between the output pin and the positive rail, and require an external resistor to the positive rail to allow the high output; the low output remains as a short between the pin and ground when it is driven.

In days of olde[tm] it was common to tie open collector outputs together from multiple interrupt sources, with a single resistor pulling the output high. When any of the interrupt outputs becomes active, it grounds the line and (usually) triggers an interrupt at the processor; thereafter, normal interrupt response to identify the source and clear its interrupt occurs.

With totem pole outputs, because of the short to the positive rail, if multiple outputs were tied together then when an output goes low, current would flow from the other outputs - effectively shorted to the positive supply - and into this output. Which is shorted to ground - so you have a short between the power rails... not good.

So if you have open collector outputs, you can use what's called a 'wired-or' connection by joining them all together at a pull-up resistor; if you have totem-pole outputs, you need to use a logic gate - usually an AND gate - to join them to a single input.

Neil

[GARTHWILSON]

...and to add to what Neil said:  You can also put a Schottky diode in series with the totem-pole IRQ\ output of the VIAs, with the anodes connected to the processor's IRQ\ input and a resistor from there to VDD, to avoid the use of an AND gate.

The change to totem-pole output wasn't just some dumb idea though.  The potential problem it solves is that if you're pushing the speed limits of modern parts and the RTI instruction is reached and executed too soon after the VIA's interrupt condition is cleared, the line with just a passive pull-up may not have had enough time to charge the parasitic capacitance and get up to a logic 1.  Obviously then the processor would take the IRQ vector again immediately and needlessly.  I was bit by that once, although in my case I think I could have avoided it with a heavier pull-up resistor load.

[BigDumbDinosaur]

DRG wrote:

I'm thinking my memory map will be as follows...

Code: Select all

C000-FFFF ROM (16k)
DD00-DFFF I/O (0.75k)
0000-DCFF RAM (47.25k)

This should allow me to have A15-A7 fed into the GAL with 128 byte granularity giving a I/O address space of...

Code: Select all

DD00-DD7F IO_0
DD80-DDFF IO_1
DE00-DE7F IO_2
DE80-DEFF IO_3
DF00-DF7F IO_4
DF80-DFFF IO_5

I had A15-A4 previously so I can have more mapped I/O is my thinking since I have much more RAM to "sacrifice" for I/O.

Hmm...

For inputs:

• Nine inputs for the address bus (A7-A15).
   
• An input for the Ø2 clock.
   
• An input for the MPU’s RWB signal.
   
• An input to pick up a data bus line to control ROM shadowing.

That’s 12 inputs.

Now, for outputs:

• An output for RAM chip select.
   
• An output for ROM chip select.
   
• An output for /RD.
   
• An output for /WD.
   
• If you plan to run this unit into double-digit Ø2 rates, you will need to implement wait-stating.  An output will be needed for /WSE.
   
• In order to implement shadowing, you will need to set up a latch to maintain internal state needed by your RAM and ROM select logic.  The 22V10 doesn’t have buried nodes that can act as a latch. Therefore, you have to use an output pin as a node.

The above requirements consume six of the 10 available outputs.  I think you can see the impending problem.

How are you going to hook up those six I/O devices in your memory map? 

[plasmo]

A nice design challenge. I think it is solvable.

[BigDumbDinosaur]

plasmo wrote:

A nice design challenge. I think it is solvable.

I agree.

That said, I don’t want to take away Dave’s opportunity to ponder this problem and come up with a workable arrangement.  However, I’ll leave a couple of thoughts to prime his metaphoric pump.

1. Back before there were CPLDs and FPGAs, designers made do with PALs, GALs and PEELs (remember those?).  As they were relatively costly parts at the time (and not trivial to program), they were only used in applications where logic complexity was introducing too much propagation delay, or where the PCB real estate consumption was excessive.  The “easy” stuff, meaning functions that could be readily implemented with two or three cascaded gates, continued to be handled with discrete logic.
    
2. The 22V10 has enough logic “fabric” to do this.  What it lacks is a lot of I/O—a limitation (among others) that CPLDs and FPGAs were developed to solve.  A clue to how to get around the paucity of I/O in this application is to be found in #1 above. 

[DRG]

Oh, you boys! You worry too much, Dave has it under control!!!

I have clipped the wings of my ambition in terms of speed and am now looking at a maximum of 8MHz. I have a selection of oscillators and will ramp it up in speed from 4MHz (achieved on my first build) until it no longer functions. Hence, wait-states and RAM/ROM shadowing are discarded until a future date when my skills and understanding are commensurate with such an undertaking as ROMless etc.
Consequently, for this build, the ATF22V10C will look something like this...

Code: Select all

       --------
CLK   |1     24| Vcc
RW    |2     23| /WE
A15   |3     22| /OE
A14   |4     21| /RAM_CS
A13   |5     20| /ROM_CS
A12   |6     19| /IO_0
A11   |7     18| /IO_1
A10   |8     17| /IO_2
A9    |9     16| /IO_3
A8    |10    15| /IO_4
A7    |11    14| /IO_5
Gnd   |12    13| --
       --------

At the risk of making myself look dumb (again!), could I have an input for VIA0_IRQB and an input for VIA1_IRQB and AND them together in the GAL to an output pin? However, that'd take up 3 pins and drop me to 4 I/O devices. With 2 x VIAs already, that's not leaving much room for expansion. A UART and I'm down to 1 I/O left! Maybe a discrete 74HCT08 is a better idea?
Oh, and in response to the question posed...

BigDumbDinosaur wrote:

The 22V10 has enough logic “fabric” to do this.  What it lacks is a lot of I/O—a limitation (among others) that CPLDs and FPGAs were developed to solve.  A clue to how to get around the paucity of I/O in this application is to be found in #1 above. 

Could one just have a pin for the whole I/O space and then forward that to something like a '138 3-8 decoder?

[BigDumbDinosaur]

DRG wrote:

At the risk of making myself look dumb (again!), could I have an input for VIA0_IRQB and an input for VIA1_IRQB and AND them together in the GAL to an output pin? However, that'd take up 3 pins and drop me to 4 I/O devices. With 2 x VIAs already, that's not leaving much room for expansion. A UART and I'm down to 1 I/O left! Maybe a discrete 74HCT08 is a better idea?

I’d use an AND gate to aggregate your IRQs and not waste GAL resources on something in which absolute timing requirements aren’t critical.  However, I’d use a 74HCT11, which is a triple input AND.  After hooking up your two VIAs’ IRQ outputs to it, you’d have a spare IRQ input to use with a UART, if desired.  Be sure to pull the spare input up to VCC to support wired-OR operation—a 3.3K resistor is suitable for that purpose.

Quote:

Oh, and in response to the question posed...Could one just have a pin for the whole I/O space and then forward that to something like a '138 3-8 decoder?

You could, if you don’t mind the cascaded prop delay of the GAL driving another piece of logic.  However, a better way to free up GAL outputs would be to move the read/write logic into a 74xx00, e.g.:

Qualified Read/Write

Although the circuit illustrates a 74AC00 (extremely fast, with aggressive edges), other CMOS logic types could be used.  These days, I’d use a 74AHC00. which has the performance of 74AC, but the less-aggressive edges of 74HC.  Putting your read/write logic into a discrete part frees up two outputs on your GAL.

Speaking of GAL outputs, be aware that they are TTL level, not CMOS.  Maximum guaranteed VOH is 2.4, which is well below the VCC × .7 level considered a valid CMOS logic 1.  Some measurements I’ve taken of GALs running in my GAL tester indicate that the unloaded output can be at or near 4 volts.  However, you can’t be sure this will be the norm in all cases.

[Michael]

Hey Dave. You might take advantage of the VIA active high chip select input to support both VIA's on a single I/O select strobe...

Happy Holidays. Mike