First thought on an interface (to use Paleolithic DROM)

[barnacle]

One thought later: eleven diodes and three transistors, and probably some resistors.

The row which has a key pressed goes high; there are two 3-input NOR gates to encode the value and (effectively) one 5-input NOR to flag that a key is pressed. The latter could do without the transistor for a sign change in the key detect code; the others need to invert the output properly to encode the binary value of the selected row.

Neil

Edit: since a 6502 can be replaced by a big enough rom and a couple of latches, one _could_ build the whole thing out of diodes... this is left as an exercise for the student.

[BruceRMcF]

barnacle wrote:

One thought later: eleven diodes and three transistors, and probably some resistors.

The row which has a key pressed goes high; there are two 3-input NOR gates to encode the value and (effectively) one 5-input NOR to flag that a key is pressed. The latter could do without the transistor for a sign change in the key detect code; the others need to invert the output properly to encode the binary value of the selected row.

Neil

Edit: since a 6502 can be replaced by a big enough rom and a couple of latches, one _could_ build the whole thing out of diodes... this is left as an exercise for the student.

So with three rows, that becomes individual lines to driver inputs 3 and 4, and one three input NOR ... or at the cost of having to "AND#$0F" in the routine to rotate of hex value into memory, a three input OR.

But the 3-input OR might be worth it anyway. If the board decoding has a /IO line, a /xx line for the address range that the led/keys are located at, and Phi2 qualified /Qual_RD and /Qual_WR lines, then:

/Select1 <= /IO1 # /xx
DECODE_G1 <= A4
/DECODE_G2a = /Select1
/DECODE_G2b = /Qual_WR

/Select2 <= /Select1 # A4
DRIVER_OE <= /Qual_RD
DRIVER_OE2 <= /Select2

So a triple 3-input OR might provide the KEY_PRESS flag bit and also the final decode selects of the led 3-8 decoder and key octal driver.

[barnacle]

With three rows, as you pointed out, you need to clear two LED positions.

It would take the lower three bits, rather than two, from the '138 decoder, and two bits from the diodes/nor gate encoder, final bit 7 could be diodes.

Neil

[barnacle]

In theory, this ought to provide decoding and output enable for:
- ram 0-7fff
- led character 8000-8fff
- led/key column 9000
- read keys 9001
- 6522 at a000
- uart at b000
- rom at c000-ffff
- if nusedrom is low, drom f000-ffff, but rom can still be written; nromoe is inhibited in the top 4k so it can't be read.

Unless I got something upside down. Sadly, it's four chips instead of the original '00 to do all the decoding.

Neil

[BruceRMcF]

barnacle wrote:

In theory, this ought to provide decoding and output enable for:
- ram 0-7fff
- led character 8000-8fff
- led/key column 9000
- read keys 9001
- 6522 at a000
- uart at b000
- rom at c000-ffff
- if nusedrom is low, drom f000-ffff, but rom can still be written; nromoe is inhibited in the top 4k so it can't be read. ...

Sadly, it's four chips instead of the original '00 to do all the decoding.

Well, not a salty tears level of sadness ... the more IO decoding done, the more chips needed, but 3 decoders in two of the four chips there helps keep the glue logic count in check.

Which process are the 138 and 139? [H/A][C/CT]? Or truly paleolithic LS?

[barnacle]

Just generic 74 at this point, but most likely HC or AHC, depending what's in stock. The DROM will work at 3.3 to 5v, and I calculate at maybe three megahertz - I won't know for certain until I build one - so I'm looking at a 1.8MHz system to keep the UART simple.

Worst case through the decode with AHC is under 15ns, I think.

Neil

[BruceRMcF]

barnacle wrote:

Just generic 74 at this point, but most likely HC or AHC, depending what's in stock. The DROM will work at 3.3 to 5v, and I calculate at maybe three megahertz - I won't know for certain until I build one - so I'm looking at a 1.8MHz system to keep the UART simple.

Worst case through the decode with AHC is under 15ns, I think. ...

Ah, I was looking at the 74HC138 datasheet. Digikey has through hole 74AHC138 in active status. Yes, at 3.3V the AHC is worst case 15ns on the high select under 15pF load capacitance, 13.5ns on the low selects and 13ns on the addresses ... faster at 5v, under 12ns even under 50pF load capacitance.

barnacle wrote:

With three rows, as you pointed out, you need to clear two LED positions.

At least, someone with an eight digit LED panel would do ... someone with a six digit LED panel would be fine.

Three bytes can be saved by using the self-executing vector trick ... which, since it involves the BRK vector can almost never actually be employed. In this context, it means giving up the use of a BRK instruction for the micro-monitor for the code punched in before the FlashROM has been brought up:

Code: Select all

...
        BMI exec   ; the GO function has been parsed
...
        org fffc
        dw start
exec:   dw $0200 

... where the first byte of the vector is a BRK opcode, and it is sitting in the IRQ/BRK location, so the BRK jumps to $0200. So no "JMP $0200" code is required, saving three bytes. Having bit7 be "/Press" rather "Press" would save another two bytes. Since the raw code is stored in leds, "STZ leds+6 : STZ leds+7" would suffice.

If this trick is used, I guess an explicit JMP ($FFFC) would become the "micromonitor break point", edited into three NOPs to move onto the next.

Quote:

It would take the lower three bits, rather than two, from the '138 decoder, and two bits from the diodes/nor gate encoder, final bit 7 could be diodes.

Neil

I wouldn't know, but I'd be guessing wiring the OR with diodes is not as bad in this case due to the speed and the fact that only one line will be high?

A 3-nor encoder which makes the d7 high flag "/Pressed" does save two bytes in the code, but OTOH doing the key encoding with diodes seems more Paleolithic.

In a system that runs faster out of DROM mode, it seems that with non-keypresses encoded as a high bit set, a single triple 3-input NOR could do all of the key encoding, with d3 encoded from NOR(row1,row3), d4 encoded from NOR(row1,row2), and d7 encoded from NOR(row1,row2,row3).

All in all, the general utility of having 8 command keys available when running in FlashROM mode would incline me toward the 8col x 3row layout, but having the encodings available from either five diodes or one '37 is also a strong argument (though not the same encoding, so that is a pre-DROM soldering choice to make -- "I've got to edit a BPL to a BMI, time to do some desoldering").

Perhaps a Schmitt-Trigger NOR would also be a useful in debouncing the keyboard ... but browsing makes those look mostly like automotive parts, which are SMD. Anyway, three lines means debouncing could be done with the eight pin LS18-P debounce chip.

[BruceRMcF]

barnacle wrote:

With three rows, as you pointed out, you need to clear two LED positions.

It would take the lower three bits, rather than two, from the '138 decoder, and two bits from the diodes/nor gate encoder, final bit 7 could be diodes. ...

Yes, using the $0200 address in the break/irq vector ... $00 $02 ... and jumping to the BRK/IRK vector to execute a BRK to $0200 ... allows:

• Three command keys (Review, Go, CR) with positive diode logic on d7="Press"
• Four command keys (Review, Page Forward, Go, CR) with inverse NOR logic on d7="/Press"

... while resetting the display codes for the top two leds to 0. Of course, it means that the PC and Flags register have been pushed to the uninitialized Stack, but if the code jumped to sets up the stack, that is cleaned up as a side effect.

I translate "can be done with three commands" as "can be done", so the LED clearing "can be done" with either positive diode key decoding or inverse NAND key decoding. After all, Page Forward is a "nice to have", but with the approximately zero odds of me punching in, say, 300 bytes of code without needing to fix a typo, Review is more of a "have to have".

~~~~~~~~~~~~~~~

A side thing I had to look at for the SPI board, which isn't an issue for the Paleolithic board, is that the notion there is a 32byte DROM for the "normal" two stage bootloader, and the mega DROM for doing a "new fancy modern gear" boostrap of punching in the routine to allow storing the 2nd stage bootloader and the first "soft-ROM" in an empty SPI non-volatile FRAM so the mini-DROM "get it by SPI from /SS0" has an "it" to work with.

/BUS_Reset resets an /S /R latch which directs reads to go to the mini-DROM while loading JUMP0 at the end of the 1st stage bootloader sets it, to direct reads to SRAM0, $0000-$01FF, and $0400-$FFFF. Since what has been loading has been the $FFxx page, that page can have code "underneath" the mini-DROM to pick up execution when the /MAIN_RD takes over.

(That's not an issue for a "bootstrap a FlashROM" board, where simply jumpering between DROM and FlashROM avoids the overhead of the switchover on the fly.)

But the Paleolithic Bootstrap mega-DROM (1) is loading code to work with, in low RAM, not the 2nd stage of a bootloader process, in the $FFxx page, so it cannot trigger the switch to SRAM while still running in $FF80-$FFFF, and (2) has no room to read JUMP0 anyway.

So a second Main/Diode latch Set condition is required. What I hope might work is VPA=1 and A15=0, so that as soon as the board tries to execute any code below $8000, the DROM vanished from the memory space. That uses three gates ... an OR, a NOT and a NAND ... but the SPI circuit itself is so profligate in its use of glue logic, they might all be available on ICs already required (SR latches from one side of a quad NAND abbreviated SRL, since there are also several SR's on the hypothetical board):

/DROM_SRL_SET <= /SEL_JUMP0 # !(!A15 & VPA)

[BruceRMcF]

barnacle wrote:

In theory, this ought to provide decoding and output enable for:
- ram 0-7fff
- led character 8000-8fff
- led/key column 9000
- read keys 9001
- 6522 at a000
- uart at b000
- rom at c000-ffff
- if nusedrom is low, drom f000-ffff, but rom can still be written; nromoe is inhibited in the top 4k so it can't be read. ...

Note that an led/key column latch addressed at 9000 and an led character latched at 8000-8fff doesn't match up with your code as written, which was:

Code: Select all

...
ff99 : 9900b8              sta led_addr,y
ff9c : ad00b0              lda keys
...

... which is written for two latches on the same select, one capturing D0-D7 and the other capturing A0-A2. Then the values captured by the second latch would be the inputs to the 3-8 decoder to have one LED segment selected on its output value until the next takes over.

The code for three distinct selects would be:

Code: Select all

        sta led_addr
        sty led_column
        lda keys 

... which would require finding another 3 bytes, but with two latches required in any event (unless the LED is to be flashed for merely part of a single clock cycle), selecting both latches on the same memory mapped I/O range saves both code space and the gates to distinguish between $9000 and $9001.

To concisely allow the 3-8 decoder behind the address capture latch to be turned off, that latch might also capture R/W, to be tied to /G2a, with G1 tied high and /G2b tied low, so that "lda led_addr" brings all LED column selects high.

Anway, assuming that the hardware works with the code you wrote above, rearranging the order of a few things, including the parsing sequence, assuming that KEY_RV, KEY_GO, KEY_PF and KEY_CR are in that order as keycodes (which specific switch they are on is more arbitrary), assuming the positive diode logic on the keypress detect, and using the opportunity to do one trick where said opportunities are as rare as hen's teeth, it fits, with one byte to spare.

Three bytes to spare if using inverse logic on /KeyPress, allowing a conventional "jmp $0200" for GO and allowing your Mega-DROM to serve as a crude BRK point monitor for debugging the code you punch in (though along the way I realized that this was not an option for my hypothetical SPI board).

One thing, in particular. Placing the writing of the leds array inside the inner loop, to give the LED more time with its share of the segment driving costs two bytes, because the process uses both the X and Y index, and placing the process inside the digit loop means that the Y index must be preserved. Placing it to operate in the main loop, before Y is initialized, saves those two bytes.

Code: Select all

	code
	org $ff80	; +16
LED_PATTERNS:
	db 0b00111111	;0
	db 0b00000110	;1
	db 0b01011011	;2
	db 0b01001111	;3
	db 0b01100110	;4
	db 0b01101101	;5
	db 0b01111101	;6
	db 0b00000111	;7
	db 0b01111111	;8
	db 0b01101111	;9
	db 0b01011111	;a
	db 0b00111100	;b
	db 0b00101000	;c
	db 0b01011110	;d
	db 0b01111101	;e
	db 0b01110001	;f


start:		; +4
	stz leds+6	
	stz leds+7
restart:		; +6
	; Set base address, this is also "review"
	lda #>addr0
	sta W+1
	stz W		; start address addr0, page aligned

loop_main:		; +19
	; Set up the current value for leds
	; current state to leds
	; put W and (W) into leds
	; [x][x][x][x][x][x][ ][ ]
	;
	ldx #0
	lda W+1
	jsr to_leds
	lda W
	jsr to_leds
	lda (W)
	jsr to_leds

	; Initialize the display count
	; Need to drive eight leds for 8x3 "keyboard"
	; Top two leds defined as clear at start
	ldy #7
	
loop_digit:		; +10
	; for each LED digit (right to left)...
	; 		(y=7, y=6 will be storing 0)
	lda leds,y
	sta led_addr,y	; display bit pattern
	lda keys
		; d7 = (row1 # row2 # row3)
	bpl loop_99	; no key pressed

			; +12
	; do stuff to sort out the key value	
	; a hex key if below KEY_RV
	cmp #KEY_RV
	bmi loop_hex	; enter hex value
	beq restart	; addr0->W to review
	cmp #KEY_PF
	bmi exec	; execute on Go key
	beq loop_pf

			; +8
	; remaining special key is return
	inc W
	bne loop_90
loop_pf:
	inc W+1
	bra loop_90

loop_hex:		; +16
	; shuffle key value into (W)
	; In this version, d7=Press
	; d7 set if hex key
	and #$0f  ; clear out KeyPress bit
	pha
	lda (W)
	asl a
	asl a
	asl a
	asl a
	sta (W)
	pla 
	ora (W)
	sta (W)	

loop_90:		; +4
	; wait for key to be released
	; this will cause display glitch, but...
	lda keys
	bmi loop_90

loop_99:		; +5
	dey
	bpl loop_digit
	bra loop_main
; main END

to_leds:		; +23
	; unpack byte into two adjacent LED patterns
	; x has character position
	pha
	and #$0f		; low nibble
	tay
	lda LED_PATTERNS,y	; index into the patterns
	sta leds+1,x		; and output into the LED array
	pla
	lsr a
	lsr a
	lsr a
	lsr a			; high nibble
	tay
	lda LED_PATTERNS,y
	sta leds,x		; this byte goes on the left
	inx
	inx
	rts		

	org $fffc	; +4
	dw start
exec:	dw addr0	; addr0 must be page aligned
			; first byte executes BRK 

[barnacle]

Yeah, the hardware is not yet carved in stone and I'm trying to reduce chipcount there, too, so it might fit on a board the same size as the DROM. So addresses may change. I _think_ I can share an address for the column write and the row read, but I'm not sure I've thought through all the implications.

And things like paragliding _will_ insist on getting in the way; had a couple of fun flights yesterday instead of thinking about this

Neil

[BruceRMcF]

barnacle wrote:

Yeah, the hardware is not yet carved in stone and I'm trying to reduce chipcount there, too, so it might fit on a board the same size as the DROM. So addresses may change. I _think_ I can share an address for the column write and the row read, but I'm not sure I've thought through all the implications.

The other way around ... share an address for both latches to be written, the segment data write and the column write, since the segment data to be latched is on the data lines, and if indexed addressing is used, the column count to be latched is on the lower address lines, A0, A1 and A2:

Code: Select all

- led character / led/key column:  8000-8fff
- read keys 9000

That allows the code:

Code: Select all

        sta led_addr,y ; i.e. STA $8000,Y
        lda keys       ; i.e. STA $9000

... as in your draft code above.

So long as latch select is qualified on the R/W signal, the 65C02 better supports that kind of indexed address to provide additional information for latching, as (unlike the NMOS 6502) R/W is high during any cycle with an invalid address on the bus.

Contrast the code that is required if the column write is on a different select from the segment data, as the register addressing indicated:

Code: Select all

; led character 8000-8fff
; led/key column 9000
; read keys 9001
        sta led_addr  ; i.e. STA $8000
        sty led_col   ; i.e. STY $9000
        lda keys      ; i.e. LDA $9001

Quote:

And things like paragliding _will_ insist on getting in the way; had a couple of fun flights yesterday instead of thinking about this

I'm happy that, if you were to be falling out of the sky, it was on purpose and was fast enough to be fun without being so fast that you are unable to type afterwards.

I'll make do with the thrill of squeezing five bytes out of the code I thought might have no more bytes to yield up.

[barnacle]

Looking at the circuit diagram, there's one address to write/hold the segment value, eight addresses to write the row address (which latches and decodes the _address_ low bits to both drive the cathodes of the LEDs and drive the keyboard columns high) ignoring the actual data, and one address to _read_ the encoded key value.

So it looks sensible to use the segment write and key value read at the same address. It still needs a more careful address/chip enable decoding logic design.

Neil

[BruceRMcF]

barnacle wrote:

Looking at the circuit diagram, there's one address to write/hold the segment value, eight addresses to write the row address (which latches and decodes the _address_ low bits to both drive the cathodes of the LEDs and drive the keyboard columns high) ignoring the actual data, ...

If there is one address that generates a signal to write/hold the segment value, and a different partial address (so it covers a range of addresses) to generate the signal to write the row address, latching the address low bits for the columns ... then:

Code: Select all

      sta led_address,Y

... doesn't suffice to latch the segment information and also the column information. If "led address" is the column information, then the information on the data lines doesn't go anywhere.

Call the signal /LED_ADDRESS and suppose it goes to the clock line of clocked octal D-latches:

Code: Select all

74x574 TI datasheet
Pin01: /OE	Pin20: VCC
Pin02: 1D	Pin19: 1Q
Pin03: 2D	Pin18: 2Q
Pin04: 3D	Pin17: 3Q
Pin05: 4D	Pin16: 4Q
Pin06: 5D	Pin15: 5Q
Pin07: 6D	Pin14: 6Q
Pin08: 7D	Pin13: 7Q
Pin09: 8D	Pin12: 8Q
Pin10: GND	Pin11: CLK 

Latch_SEGMENT:
Pin01 <= tied high
Pin02..09 <= d0..7
Pin11 <= /LED_ADDRESS
Pin19..12 => LED_SEG0..7

Latch_COLUMN:
Pin01 <= tied high
Pin02..04 <= A00..A02
[Pin05 <= A03 optional]
[else Pin05 <= tied low]
Pin06..09 <= tied low
Pin11 <= /LED_ADDRESS
Pin19..17 => DECODE_A..C

DECODE:
A <= Latch2_Pin19 = 1Q
B <= Latch2_Pin18 = 2Q
C <= Latch2_Pin17 = 3Q
[/G2A <= Latch2_Pin16 = 4Q optional]
[else /G2A <= tied low]
/G2B <= tied low
G1 <= tied high
/Y0..7 => Led/Key_Column0..7

then the segment data is taken from the A register and the column data is taken from the bottom three bits of the Y register with "sta led_addr,y".

Quote:

So it looks sensible to use the segment write and key value read at the same address. It still needs a more careful address/chip enable decoding logic design. ...

They could be at the same address, but the latches and the driver wouldn't use the same signal, as the d-latch CLK should qualify the address with R/W, otherwise the latches would latch the key data being read out.

Taking /SEL_LED_KEY as generated asynchronously by the address [where the !(R/W) could well be qualified by PHI2 as !(R/W & PHI2)]:

/Key_Driver_OE1 <= /SEL_LED_KEY
/Key_Driver_OE2 <= R/W

Latch_SEGMENT <= /LED_ADDRESS <= /SEL_LED_KEY # !(R/W)
Latch_COLUMN <= /LED_ADDRESS <= /SEL_LED_KEY # !(R/W)

Then in code:

Code: Select all

led_addr = $8000
keys = led_addr
...
        sta led_addr,y
        lda keys 

... would work.

The optional capture of A3 by the column latch would allow the 3-8 decoder behind the column latch to be turned off by storing to address $8008, and would turn back on by any of the normal stores to any address $8000-$8007. That would take the Q4 output of the clocked D-latch to a decoder active low select, say /2GA select, tying the decoder /2GB select low and G1 high.

[barnacle]

Yeah, the thought was to write the LED pattern to $x000, write _anything_ to the column addresses at $y000-$y007, read the decoded key at $x001... but if I do a _read_ of the column address, then that will still latch the address and provide the keycode as the read value.

So ignoring everything else:

Code: Select all

   db LED_PATTERN $blah, blah, blah

loop:   ; assuming display byte is in x, column is in y
   lda LED_PATTERN,x
   sta SEGMENT
   lda KEY,y
   ; more stuff
   dey
   bpl loop

Um, on later thinking, maybe not: the column won't latch until RnW rises; need to read datasheets and see if the HC137 is transparent.

Neil

[BruceRMcF]

barnacle wrote:

Yeah, the thought was to write the LED pattern to $x000, write _anything_ to the column addresses at $y000-$y007, read the decoded key at $x001... but if I do a _read_ of the column address, then that will still latch the address and provide the keycode as the read value.

But there is no need to have separate writes to the latches when a single write can generate the signals needed by both latches ... and both latches work perfectly fine with the same ↑CLK latch select.

And the synchronous D-latch ↑CLK should be qualified to happen when the 2nd phase ends, with PHI2, so may as well qualify a single rising clock select for both latches, so save an OR gate.

The driver selects on the OR of two active low selects, so "nleds" on it's own is fine for the driver, with R/W on the other active low select ... that guarantees the hold time after PHI2 rises.
~~~~~~~~~~~~~~

Just with the signals not specified on the general decode circuit and the 2nd Key/Led circuit:

/LED_ADDR <= nleds # nramoe "nramoe is a Phi2 qualified /RD"

U9:
Pin2..9 = D0..7 <= BUS_D0..7
Pin11 = CLK <= /LED_ADDR

U12:
Pin2..5 = D0..3 <= A00..3
Pin11 = CLK <= /LED_ADDR
Pin16 => U10_Pin4

U10:
Pin4 = /G2A <= U12_Pin16
Pin5 = /G2B <= GND
PIN6 = G1 <= VCC

U11:
Pin18..11 = Y0..7 => BUS_D0..7
Pin1 = /G1 <= BUS_R/W
Pin19 <= nleds

Quote:

So ignoring everything else:

Code: Select all

   db LED_PATTERN $blah, blah, blah

loop:   ; assuming display byte is in x, column is in y
   lda LED_PATTERN,x
   sta SEGMENT
   lda KEY,y
   ; more stuff
   dey
   bpl loop

I'm sure it's imperceptible so long as sta SEGMENT and lda KEY,y are consecutive cycles ... but it might get a little glitchy if they aren't ... with a VIA onboard, I assume there will be the possibility to throw interrupts.

What you wrote previously in your code makes more sense to me: latch the setting of the segments and latch the input into the LED column decoder in the same clock cycle ... indeed at the exact same same rise of the /LED_ADDR select signal when PHI2 drops.

Quote:

Um, on later thinking, maybe not: the column won't latch until RnW rises; need to read datasheets and see if the HC137 is transparent. ...

The HC137 isn't a latch, it's a decoder, I think you are thinking of the '573 series ... but changing where the column is written avoids inverting the select line into a transparent mode active high select ... and you still have to qualify the LE with PHI2=1, since the address lines being captured have the same hold as the address lines generating the address zone select.

Latching the column with the same instruction that is storing the segment data also means that the column will already be selected when the key row is read, so no need to fiddle with asynchronous latches nor worry about the state of the bus in the first phase of the clock cycle.

Also, if an application (once the FlashROM is up and running) uses the LED display but not the keys, the first approach above allows just using "sta addr_leds,y" without having to do a read at all.

Generically, using two different selects from the latch writes and for the key matrix read would permit keys to be a different address, so the segment latch and column latch would only have to be qualified by PHI2 and not necessarily by /RD (which avoids write-back of the key code to the segment latch) ... but in your specific case, you already have a Phi2 qualified /RD line in "nramoe", so that is just using more I/O address space without saving any gates.