Monster Decoding Logic

[Alarm Siren]

Dr Jefyll wrote:

Alarm Siren wrote:

Its down to three chips and three inverters [... ] I doubt we can make it much simpler.....

Not much simpler, no. At first I thought we could dispense with that inverter on the input of the '138, but that turns out to be a dead end (despite a '138's otherwise versatile complement of active-high and active-low enable inputs).

Yea, it is most irritating.

Dr Jefyll wrote:

However, the 4-input AND can be deleted. Instead, /CE for the EEPROM can be generated by a 3-input NAND fed by A15-13. A single 14-pin DIP holds three 3-input NAND's, so there are two left over... which can function as inverters. So, we're down to down to three chips and one inverter. Maybe you'd like to eliminate that last inverter by just using a transistor to complemet Reset?

Yea, I was going to use the second quad AND gate as an inverter but, well, I had a senior moment and forgot that of course an AND gate can't invert... The NAND works better anyway, less prop delay and we get two inverters out of it instead of just one.

So, the final count is a 74x138, a 74x139, a 74x10 and a 74x1G00.

GaBuZoMeu wrote:

You are using PHI0 - sure?

I don't use WDC's notation for the PHI pins as I find it unecessarily confusing. I call their PHI2 as PHI0 and their PHI2O as PHI2.

GARTHWILSON wrote:

Dr Jefyll wrote:

As for the '816, I'll note in passing that it doesn't force you to jump into the deep end of the pool; it has mode bits which turn off its 816-ness by default. Later you can progressively enable those bits one by one and wade into the pool at your own pace.

Yep, and it will be easier both in hardware and in software.

Its not the software side of the '816 that concerns me; I'm fully aware that you need only use as much of its extra features as you want to. Its the hardware that concerns me, particularly that multiplexed data bus.

[GARTHWILSON]

Alarm Siren wrote:

GARTHWILSON wrote:

Dr Jefyll wrote:

As for the '816, I'll note in passing that it doesn't force you to jump into the deep end of the pool; it has mode bits which turn off its 816-ness by default. Later you can progressively enable those bits one by one and wade into the pool at your own pace.

Yep, and it will be easier both in hardware and in software.

Its not the software side of the '816 that concerns me; I'm fully aware that you need only use as much of its extra features as you want to. Its the hardware that concerns me, particularly that multiplexed data bus.

From the data sheet:

Pretty simple.

[whartung]

Alarm Siren wrote:

Its not the software side of the '816 that concerns me; I'm fully aware that you need only use as much of its extra features as you want to. Its the hardware that concerns me, particularly that multiplexed data bus.

The W65C265S exposes all 24 bits of the address bus.

Probably a bit overkill to save the wiring and two chips in order to decode the bank register (there's a suggested circuit in the '816 data sheet to decode the bank/data bus), but it's there. Also need to jump through a couple hoops to just use it as a raw CPU (notably disabling ports and what not). It's also slower (8Mhz v 14Mhz) and more expensive (~$24 vs ~$9).

You can also look at the schematic of the W65C816SXB to see it in action. BD's POC v1 schematic I'm sure has that logic laid out as well.

[Alarm Siren]

My understanding was that you needed to use VPA/VDA as well to qualify otherwise you get accesses to garbage addresses?

[GARTHWILSON]

Alarm Siren wrote:

My understanding was that you needed to use VPA/VDA as well to qualify otherwise you get accesses to garbage addresses?

It's a good idea to use those particularly for non-65-family ICs that mess up if you access them two clocks in a row, like BDD experienced with the NXP UARTs. VDA and VPA are an added functionality that you don't have on the '02. If you have a scheme that would work on the '02, it will also work on the '816 without using VDA and VPA. It was the NMOS '02 that did reads from invalid (but predictable) addresses in some situations. That was fixed in the CMOS '02. VDA and VPA were added to the '816 design for use with cache and DMA, things I don't think you're interested in implementing. Am I forgetting anything?

[Alarm Siren]

And now I discover that the screen has a minimum cycle time of 1.2ms; given I intend to dangle it off the CPU bus and my target CPU speed is 4MHz/250ns.... yea, I'm going to have to put in wait-states for that. Lovely .

Though having said that, I'm not 100% certain that it really does require such a cycle time. I'll get the relevant datasheet and discuss my thoughts on the matter tomorrow.

[DerTrueForce]

An idea might be to put in a pulse-stretcher and a latch.
By which I mean, put latches between the bus and the screen, and have a timer, triggered by the inactive edge of the enable signal, that holds all the signals in a valid state for long enough that the screen can respond. Then when the timer runs out, it deasserts the enable signal that the LCD sees.
The only problems I see with this are that that's a fair amount of hardware, and you'd have to wait between accesses.

[GARTHWILSON]

Alarm Siren wrote:

And now I discover that the screen has a minimum cycle time of 1.2ms; given I intend to dangle it off the CPU bus and my target CPU speed is 4MHz/250ns.... yea, I'm going to have to put in wait-states for that. Lovely .

Though having said that, I'm not 100% certain that it really does require such a cycle time. I'll get the relevant datasheet and discuss my thoughts on the matter tomorrow.

I suspect that's how long it takes to handle an entire screen update or something like that. Or maybe it takes 1.2µs (a thousand times as fast as 1.2ms)? The common character LCDs however are not fast enough to put directly on the bus if you're running at 4MHz, which is why my workbench computer (at 5MHz) handles the LCD (plus five other things) through the first VIA. If you'll still write to it faster than it can process the data or instructions, the next thing is to check its busy bit before writing to it again. If putting it in a thumb-twiddling wait loop is not acceptable, you can set up a VIA timer to interrupt when it should be done, so the computer can do other useful things while waiting for the display to be ready for more data or instructions.

[Dr Jefyll]

GARTHWILSON wrote:

Alarm Siren wrote:

My understanding was that you needed to use VPA/VDA as well to qualify otherwise you get accesses to garbage addresses?

It's a good idea to use those particularly for non-65-family ICs

Yes, a good idea, and "those" typically means just VDA (not VPA). Simply fix things so your I/O devices (or at least the sensitive I/O devices) can't get a chip-select unless VDA is high. No similar requirement applies to VPA (ie: I/O needn't become enabled when VPA is high) unless you plan to fetch code from the I/O device. That's utterly unusual except regarding EEPROM memories, some of which are in effect also I/O devices if in-system programming is used.

The 6522/65C22 VIA is a device that's potentialy sensitive to unexpected access, but protecting it using VDA often requires no extra gates. If the active-high chip-select is unused you can simply connect that to VDA.

GARTHWILSON wrote:

If you have a scheme that would work on the '02, it will also work on the '816 without using VDA and VPA.

Yes. In both cases there's potential for

• a double access to I/O when it should be a single access, or
• appearance of an invalid address that creates an I/O access when there should be none

... but evidently not all the necessary circumstances apply. Ie, if you got away with it on (NMOS) '02 then you'll also get away with it on '816 without VDA.

GARTHWILSON wrote:

It was the NMOS '02 that did reads from invalid (but predictable) addresses in some situations. That was fixed in the CMOS '02.

Yes. Then with the '816 they removed some or all of the 'C02 fix (thus re-introducing invalid addresses) and gave us VDA as a means of protection instead. Two different solutions to the same potential issue. (The 'C02 substitutes an extra read at PC for accesses which would, on an '02, read from an invalid but predictable address.

[Alarm Siren]

GARTHWILSON wrote:

Or maybe it takes 1.2µs (a thousand times as fast as 1.2ms)?

Yes, 1.2µs. Sorry it's given in ns in the datasheet and I got my SI-prefixes mixed up on converting.

GARTHWILSON wrote:

(at 5MHz) handles the LCD (plus five other things) through the first VIA

I only have one VIA and there isn't enough pins left on it to drive the LCD screen. I would very much rather not add a second VIA to the system if I can avoid it as VIAs are not cheap components, and they take up a lot of space (relatively speaking compared to a couple of logic gates). Also this is as much a learning experience for me as it is an attempt to make an efficient system. I've never done wait states before (more on that below), so its an opportunity to learn.

GARTHWILSON wrote:

the next thing is to check its busy bit before writing to it again.

I know about the busy bit, but it won't help for this issue. With the LCD directly on the CPU bus at 4MHz, the read/write timing specification is violated so I won't even be able to read the busy bit, let alone read or write anything else.

---

Link to LCD Screen Datasheet
Link to LCD Controller Datasheet

If you look at the timing diagram on page 30 of the controller datasheet and the AC Characteristics table on page 32, one can see that the two critical timings for this purpose are Tc and Tpw. Tc is the total time between rising edges of E, minimum 1200ns; Tpw is the minimum width between the rising edge and the falling edge, minimum 480ns.

Overall I don't think that Tc is an issue because (with the possible exception of RMW instructions) I don't think its possible for the 65C02 to access the same memory I/O device quicker than once every four cycles... e.g. STA $C002 takes four cycles to execute, only the last one of which is an actual write to the I/O device. So, for the purposes of Tc, one could argue that the access rate has dropped from a potential 4MHz to a potential 1MHz. Yes, technically 1MHz is still too fast for Tc, but it certainly a lot better.

Tpw is a bigger problem though. E would be high for only 125ns on a 4MHz system (ignoring prop delays) and there really is no way around that. Not to mention Tdsw requiring a data setup time of 80ns before E's falling edge, so with prop times it'd be cutting it close. So, I think that for accesses to the screen I would need to stretch the access over three cycles. 125ns + 2*250ns = 625ns > 480ns. This has the additional bonus of increasing the total length of the cycle for the purposes of Tc and should therefore keep that in spec too, taking into account the stuff I've already stated.

Two options for stretching the screen accesses: 1. stop / disconnect PHI0 for a specified period. 2. Use RDY. I prefer the latter option, gating the clock seems like a bad idea. That brings me to André Fachat's RDY Generator Mini Project, which looks like it will do what I want, but I'll be honest, despite staring at it for hours I have no idea how it works, and I am uncomfortable using glue logic that I don't understand. Also there might be a simpler way to implement wait states that you lot have hidden up your sleeves; this one appears to require a minimum of three extra chips.

I'm going to do some thinking and experimenting in the mean time, but I shall await your collective wisdom with anticipation.

[Michael]

Was your original mapping with a single 128K RAM chip something like the diagram below, and now you're simply adding an additional 32K RAM chip and mapping it into address space at $0000-$7FFF unconditionally for each map?

Mike

[Alarm Siren]

Yes Michael, that is an exact representation of the original map. I'm pretty happy with the new map though, it significantly simplifies the glue logic and gives me an extra 32K to boot.

[Alarm Siren]

So, here's my attempt at adapting André Fachat's Circuit to my immediate needs, the new parts being the '164 in the middle and the logic connected to it. I have also attached a timing diagram showing how I believe this circuit will work with respect to the relevant signals for the wait stating. In particular the E Period between cycles 1.5 and 3.5 should be roughly 500ns, which would meet the Tpw requirements of the LCD. Provided my timing diagram is an accurate representation of what will occur, I believe that this would allow it to work in a 4MHz system.

[BigEd]

(You might already have this covered but note that the LCD can be driven either as an 8 bit or a 4 bit peripheral. That means you can use fewer pins and perhaps squeeze it into the VIAs ports. You may be able to share some pins if you keep a careful eye on device selects.)

[Alarm Siren]

Thanks Ed, yes I was aware that it can be used in 4-bit mode. I still wouldn't have enough pins on the VIA without multiplexing at least one pin and, probably, sacrificing all my remaining GPIO. I would rather avoid needing to split commands into nybbles, multiplexing pins and sacrificing what little GPIO I have left. I had always planned on attaching the screen direct to the bus, I just didn't realise how slow the LCD screen's interface is....