6502.org

'137 is a latching decoder - like a '138 but with a latching input. As I read the sheet, if I feed it with the address low bits, it gives a valid decoded output as long as RnW/~latch is low; when it goes high, it latches. It doesn't care whether it's a read or a write; it's not using the databus at all. But it will select the desired digit and key column depending on the address read. At the same time it can return the keycode value.

So the first write sets the LED pattern, then the key value is read at the same time as setting the column. Assuming I use the same decoded address for column and keycode, of course.

The other way around shares the pattern address with the keycode but requires a separate write and then read.

Neil

Ah, I'm looking at the wrong datasheet again. I now vaguely recall looking for one of those for something or other, but giving it over because I was looking for a faster propagation time.

But the output is LED's, so 17ns-24ns propagation delays are not an issue.

The question is whether valid data from the address bus is latched after LE rises, as opposed to address lines on the move.

Is the critical value there the An to /LE Hold time of 5ns?
[Edit: looking at a datasheet from a different maker seems to confirm that's the critical value.]

In any event, the active low selection signal to the '137 has to be qualified by PHI2, similar to the octal latch for the segment data.
Yes, that would be the idea.

Just like the segment data latch, it also seems like it must be qualified by PHI2.

The reason is the address decode is going to be rising because of the changing address lines, while the "data" being latched are also address lines, which will be arbitrarily changing due to the address of the next instruction to read.

So the desire is to have the /LE line rise during the 65C02 address hold time following the drop of Phi2.

And the select is propagating through several decoders, while the addresses being decode are effectively lag-free, so the likelihood of latching in the wrong address bus state without PHI2 qualification seems quite high.
In any event:

• Both the segment code latch and the latch side of the encoder are latches being integrated into a 65xx bus;
• so it would be prudent to qualify them with PHI2 with a single propagation delay to CLK or /LE.
• There is no functional advantage to separating them.

And two gates of a quad 2-input NAND gate would suffice, the first to invert the address select, the second to form !( !/led & PHI2).
However, having the two different latches on two different addresses (segment and column), means that two different active low selects must be qualified by PHI2=1.

I'm not seeing an advantage for having the circuit do A first and then B&C concurrently, just a need to duplicate effort on the need to qualify latches by PHI2.

Having the two latches share the select because of "sta led_addr,Y" style operation only uses two gates of a quad nand, or one dual input nand and some other inverter for the /led select.

And there is no conflict in having them on the same select.

Then the keys octal driver can be put on a second select.

When you originally wrote: ... I think you nailed it then. I don't see why you keep shying away from that, when it is the most hardware efficient approach.

Mostly because I have a brain full of squirrels It took me a while to realise I can write to an address range to do the two-things-in-one action.

I am convinced (finally) that a single address group that both loads the LED pattern and selects the column (based on the low bits of the address), and a second address to read the keys, is the way to go. And yes, it will need some ph0 qualification for the write - and probably read. So easiest to add it late in the decode process; I need to see if I have any spare enable inputs. Or AND gates.

Neil

You may not need to qualify on the read of the KEYS ... the driver has two active low inputs, so if one if R/W, then it will rise alongside the address hold ending, and the next bus cycle will be an instruction read, which is Phi2 qualified, so there shouldn't be any bus contention.

So just an address range active low select on one /OE and R/W on the other /OE of the octal driver reading the switch seems like it should be OK. That saves logic on that side of the circuit.

If you have a spare inverter, inverting !nleds = "leds" and then NAND(leds,PHI2) would be the best qualified write to both the clocked octal d latch and the transparent low latch in the decoder, since it puts the PHI2 transition just one logic delay from raising the low select line. Otherwise a second gate of the quad NAND to invert "nleds" ... at 1.8MHz "leds" a good long while, in ns-world, before clock phase 1 ends, and it will be PHI2 rising that will drive the common CLK & /LE line down and then up again when it falls.

While it feels profligate to use a 3-input NAND as one inverter, one two input NAND and one three input NAND, it would localize routing to keep it all consolidated in the LEDS/KEYS circuitry:

Triple 3NAND:
1A <= nleds
1B <= VCC
1C <= VCC
1Y => 2Y

2A <= 1Y
2B <= BUS_PHI2
2C <= VCC
2Y => nled_latches

3A <= Key_Row1
3B <= Key_Row2
3C <= Key_Row3
3Y => Key_Driver_D4 (D0-based, different datasheets number differently)

Now if feel like I'm kind of cheating to have morphed the "Neolithic" SPI version into having LEDS and KEYS on the same address, but I have another different latches and jumpers that can use qualified selects and are read-only or write-only, that I have taken a 3->8 decoder on the 128 byte $0200-$027F range and a 2OR gate on the top two address lines for:

DECODE2_G1 <= BUS_PHI2
/DECODE2_G2A <= /IO0 = /DECODE1_Y4
/DECODE2_G2B <= OR(BUS_A05,BUS_A06)
A <= R/W
B <= A03
C <= A04

So I would hypothetically have Read and Write pairs on $0200, $0208, $0210 and $0218, all of them as 1-8 register address ranges, and would be able to use writing to $0200-$0207 for leds and reading from $0200 for keys.

W65c02 suggests that ph2 is there only for compatibility, and ph0 should be used for timing. Qualifying with that is a little sooner than ph2, I think, which helps.

Neil

Apologies for being terse ... I am not talking about the CPU output pins at all.

Rather, I am talking about the bus line that is high during PHI2 (clock phase 2) and low during PHI1 (clock phase 1). That's what I am thinking about as Φ2 ... IOW, the PHI2 line in the master clock cycle diagram in the 65C02 datasheet, which goes into Pin37 of the DIP layout W65C02, labelled "PHI2" (what used to be called PHI0 in the original NMOS MOS6502 datasheets).

So where I only wrote PHI2 (now fixed), I was still referring to BUS_PHI2 from the master clock diagram into the CPU_PHI2 input pin, not CPU_PHI2Out from the CPU output pin 39, which becomes the much more useful VDA in the 65816 (being able to qualify my I/O Decoder on VDA=1 is a seductive argument for putting in a 65816 instead and just let it run in emulation mode).

I am not sure how many people were using the old CPU clock phase output pins in the late 80's, but in my hypothetical doodling later on, I wasn't thinking in those terms back then, I was all about a single source clock on the bus.

And, yes, given that the W65C02 CPU_PHI2Out has no spec sheet guarantee about its lag on the BUS_PHI2, and that the datasheet hold period is 10ns (both promised and required, at all voltages), using the CPU_PHI2Out or CPU_PHI1Out would leave it entirely up to things like staring at an oscilloscope and finding out how long a delay the CPU at hand actually tolerates.

I do need positive logic "Phi1" for some of the 2 shift register + counter SPI circuit (having SR Latch /Set and /Reset in different clock phases is one way to help avoid the indeterminate /S=/R=0 state), but given the datasheet warning -- and not having said oscilloscope -- I've been planning to go ahead and put BUS_PHI2 through one of my hex inverter gates rather than use the available CPU_PHI1O ... preferably a 74AHC04, which Mouser still has available in through hole (which comes in under 10ns, at VCC=+5V, +/-10%).

Aha! 74hc148 priority encoder for the keypad interface... I thought they disappeared years ago. So using this I can drop the inverters from the column address and lose the discrete encoding logic, saving two chips on the board. The output is three bits of binary saying which row has had a key pressed, and GS which goes high when a key is not pressed (or EO which does the opposite, but using GS as bit seven means that there is no need for an AND).

Modified circuit diagram to follow...

Neil

edit: using bits 7, 6, 5, 4...

That's a bit tidier than previous attempts... you'd almost think the '148 was made for the job. (Reads datasheet blurb: Oh, yeah, right...)

Two addresses: /column which writes the databus to the LED segment and the address to the column (hmm, maybe I should change that to /segment?), and /read_key which returns the key pressed, with bit 7 high if no key is pressed.

So we return to And writing the LED value and the column address in the same instruction should eliminate ghosting of the characters on display.

(Note: IC parts are generic, I haven't typed them yet, so they're whatever Kicad has in the library.)

Neil

... Oh, wait, I had my R/W line upside down for a period there ... oh well ...

One note:

You don't need additional gates to qualify "/keys" with R/W, because the gate is already inside the driver. If using /ramoe satisfies the 65C02 on the post-PHI2 hold for a read cycle from the RAM, it ought to do so for the driver, so /keys on one /OE and /ramoe on the other /OE ought to qualify it for a read.

IIUC, there ought not be any bus contention with a following instruction opcode read, since the SRAM is qualified with /ramoe.

And so adding /ramoe to the driver /OE plus your suggestion of qualifying /leds with R/W would allow them to share the same address select.

However ... qualifying the /leds latch selects (CLK and /LE) with R/W alone might come too late.

I don't know which of R/W or the Address lines rises first in physical silicon, but the datasheet gives their hold as identical, so R/W is not guaranteed to rise so that Address lines and Data lines are still valid after one gate delay.

Meanwhile, in the two gate circuit with PHI2 on the second gate, the first gate in the ladder settles well before Phi2 drops (at DROM speeds, it settles well before Phi2 rises), and all set-up times on the low select period are easily satisfied, so the Phi2 drop at the 2nd gate is the critical path. PHI2 falls with the datasheet promising 10ns additional valid Data and Address lines, which an AHC Quad 2NAND 74AHC00 will hit at both +5v and +3.3v under 15pF capacitance up through 85C, and which with +5v it will hit through 50pF capacitance and beyond 85C, per the TI datasheet.

That is why I had:

/led_segment_CLK <= NAND(PHI2,NAND(/led,VCC))

/led_row_LE <= <= NAND(PHI2,NAND(/led,VCC))

... not to use two gates where one would serve, but to qualify with the line that changes state at the start of the hold period in question for data / address line writes to latches ... the dashed oval in the master clock cycle, again: Qualifying /leds with R/W would have the select line rise sooner than /leds alone, but not necessarily soon enough. Maybe it works, but if it doesn't best to have PHI2 qualification up your sleeve.

If rather than having to add a quad NAND to serve, there is a spare 2NOR & spare 2NAND both available, that could also be qualified for doing a NOR of /leds and R/W:

/led_segment_CLK <= NAND(PHI2,NOR(/led,R/W))

/led_row_LE <= NAND(PHI2,NOR(/led,R/W))

... and then /keys could be on the same address range ... but I'm guessing you'd rather not add R/W at the cost of a gate or two, if the separate selector is available.

The address decode is undergoing alterations...

I did have one thought on the question of whether a NAND should be fast or slow.

I abbreviate the Schmitt-Trigger NAND that is contained in the reset debounce circuit in Garth's compilation NANDST, because being a Schmitt Trigger part, it will be touch slower. But if multiple NAND's are at hand, an HC process NANDST might be used to be deliberately slower to have a longer hold on /ramoe. There is no harm to the /Reset inversion in the debounce circuit to having a typical 18ns, as the debounce process should be in the ms range.

I spilled plenty of ink above about the first NAND in the qualified LED select ladder not being on the critical path, so that could also be an 'HC132 gate, so that would be 3 gates of the slower NANDST in use.

Under the revised Paleolithic keyboard, you don't need the gates to split the $9000 select between $9000 and $9001, that reduces the selection circuit to one OR at /romoe, which has an inverted line from ndromsel and a direct line from /ramoe.

Am I right that you can flip both inputs -- switch the ndromsel to a direct line and invert the /ramoe -- and that can be a NAND? I am assuming that the inverter shown is a NAND. Those should be fast NAND's, so that would make:

/romsel <= NAND(???,???) whatever it is already, I can't make head or tail of it as it seems to be fed by two input lines into two different decoders.

/romeo <= NAND(/DECODE8_Y7,NAND(/ramoe,Logic1))

Which I think would leave the fourth fast NAND gate available for the second stage of the /leds select line and eliminate the quad OR IC.

That leaves led_addr on $8000 and keys on $9000, so no need to qualify led_addr on R/W ... simply don't bother ever reading it.

/segment_latch_CLK <= NAND(PHI2,NANDST(/leds,Logic1))

/decode_rows_LE <= NAND(PHI2,NANDST(/leds,Logic1))

Put the savings from that OR IC into the debounce fund to get an LS19-P to debounce those five key switch lines. I don't know if they are available Q1 anywhere, but I saw a source that had them $2.89 Q10 (so probably $30+ with shipping) [Edit: and Digikey will source them from Logi Switch Q1 at $3.89 plus $5.25 flat rate shipping, 5wks order, so $20 shipped for an order of 4.]. It would save some space over debouncing all five key switch lines. Indeed, since it's a 6 circuit part and you have 5 key switch lines to debounce, the final one could debounce the reset button ... if replacing the simplest /Reset debounce Garth shows, I think it simplifies it down to a NAND to invert, and wiring the switch the other polarity would eliminate that gate entirely (since the Logi Switch debounce works in both directions).

My final note on the selection circuit is to ask whether /keyssel /6522sel and /uartsel are redundant. First, instead of qualifying /keys by R/W, it could be converted into a joint low/high select, compatible with sharing a space with CIA's, by inverting A05 and taking it into one of the /OE# of the bus driver. Then A06 and up high (individually) as VIA's and IC's with similar joint active low / active high selects, so:

I don't want to overcomplicate this thing; the intent is a single-board system (plus an optional DROM hanging off the back) that an absolute beginner can build and program with _no other programming tools_ so I'm looking at a Eurocard sized thing with

• 20 keys
• 8 seven-segment LEDs
• 32k RAM
• 16k EEPROM (writable in use)
• Single 68b50 UART @ 115200 baud
• Single W65C02
• Single W65C22
• 1.8MHz operation

(These components largely selected because I have them to hand. The UART, EEPROM, and RAM are all easily available on a well-known auction site, though not available new).

The DROM lets the thing boot to a hacky but usable memory edit and execute; I think the first program example would be to copy the DROM to the same locations in EEPROM, after which the DROM can be discarded unless it all goes toes-up. To do that, the EEPROM has to be writeable in all locations even if it isn't readable; the memory map looks like this (after another alteration of the decoding) Nothing fancy, everything in convenient chunks, and using common decoders for simplicity. The gates shown are logically correct but not finalised; for example, I have some spare gates to use up. That lone OR gate annoys me for some reason, but it's needed to route the DROM and ROM selects. The RAMOE and ROMOE signals are basically active whenever PH0 and RnW are high.

Neil

Ah, yes, swap the inverter to the NRAMOE link and use a NAND. Thank you Mr Boole.

Neil

I don't want to overcomplicate this thing; the intent is a single-board system (plus an optional DROM hanging off the back) that an absolute beginner can build and program with _no other programming tools_ so I'm looking at a Eurocard sized thing with

• 20 keys
• 8 seven-segment LEDs
• 32k RAM
• 16k EEPROM (writable in use)
• Single 68b50 UART @ 115200 baud
• Single W65C02
• Single W65C22
• 1.8MHz operation

(These components largely selected because I have them to hand. The UART, EEPROM, and RAM are all easily available on a well-known auction site, though not available new).

The DROM lets the thing boot to a hacky but usable memory edit and execute; I think the first program example would be to copy the DROM to the same locations in EEPROM, after which the DROM can be discarded unless it all goes toes-up. To do that, the EEPROM has to be writeable in all locations even if it isn't readable; the memory map looks like this (after another alteration of the decoding) Nothing fancy, everything in convenient chunks, and using common decoders for simplicity.

Also, I decided I didn't like the race between the address bus getting bored and the actual read happening, so rather than use the address directly (which would incidentally have required a lda keypad,y to make the column be included) I've added a couple of NAND gates to the LED/Key section to encode the columns into binary; they're already latched so the read can happen whenever.

No doubt I will find more errors when I complete the drawings...

Neil

So if the target is a closed I/O list, freeing up selectors isn't an issue. And if a beginner building the board can't get a 68b50 and needs another UART, best to keep the integration of the UART into the 65xx bus system as simple as possible ... one address zone low select, one PHI2 (CMOS 65C02 = NMOS "PH0") on a high select or address bus CLK pin.
Yes, this is why I was trying to squeeze in the RV function, since a lot of people are going to need to go through the edited memory to fix typos from the first pass.

The page-forward PF function is more in using it as an even hackier micro-monitor, so non-essential.
The SPI board would (hyp) be RAM+IO with no ROM when the mini-DROM is selected out. So it's been intended to switch out the mini-DROM on the fly as part of the 1-stage bootload from the serial FRAM, and in that operating mode it could own all memory reads regardless of location until it switches itself out.

If the mini-DROM is a half Eurocard sitting on top of the card on standoffs, accommodating the possibility of the Mega-DROM is making sure the block header has A00..6 rather than just A00..4.

So after this, I made the memory map $0000-$7FFF RAM/IO reads, $8000-$FFFF DROM reads when the DROM is switched in, at which point it could be used in the same way if the Mega-DROM is in place ... the first program could copy the DROM to the same locations in high RAM then turn it off, and then "JMP ($FFFC)" and if the micro-monitor thing is still working, Frankenstein's monster is alive.
I had not even got to the point of realizing that race was happening, and you've gone and eliminated it.

Note that the issue still exists of the "lda keypad,y" using the expiration of some bits on the address bus to generate a latch signal while one of the latches is trying to latch some other expiring address bus bits.

Of the four I/O selects on the board, the 6522 is designed for a 65xx bus, the 68x50 UART can take CMOS 65C02 PHI2 (= NMOS 6502 PH0) as one of its high chip selects for its address bus side, and /keys is read-only so it's not an issue for any of those.

So:

segments_CLK = /rowdecode_LE <= NAND( CMOS_PHI2, NOT( /leds ))

... to me still looks like it's needed.