6502.org

The 6502 Microprocessor Resource
http://forum.6502.org/

First thought on an interface (to use Paleolithic DROM)

http://forum.6502.org/viewtopic.php?t=8383

Page 3 of 13

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Sun Jun 08, 2025 8:10 am
by barnacle
Logisim's attempt at a gated solution requires:
- four inverters
- twenty-two two input AND
- twelve three-input AND
- one four-input OR
- five five-input OR
- one six-input OR

I don't think I'll bother...

Neil

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Sun Jun 08, 2025 4:51 pm
by L0uis.m
barnacle wrote:
You could consider charlieplexing... of course, just seven OR gates will do it, if they have up to sixteen inputs each :mrgreen:
I moved my reply to "Hex 7-Segment Decoding with 33 Diodes (Concept)", as I think the topic deserves its own thread (link below).
viewtopic.php?f=4&t=8388&p=112946#p112946

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Sun Jun 08, 2025 6:17 pm
by BruceRMcF
Aha, a non-cheating version.

Critical design change:
The special key row does not go to d4, but rather to d6, for detection by BIT key

[Edit: except scroll down, I was totally wrong about this being needed for this approach to work. :D It works just fine with "non-key" reading out as $00, "hex keys" reading out as $8x, and "special keys" reading out as $90-$93 -- albeit having "non-keys" read as $80, hex as their hex value, $0x, and "special keys" read out as $10-$13 would save two bytes.]

Non-critical design change:
"no-key" sets d7, "key" resets d7, so the d7 bit doesn't have to be cleaned up when a hex value as the new low nybble is being "or"ed with the new high nybble (not doing this leaves the requirement for an "AND #$7F" in place.

Design specification: this can work with various allocations of special keys, but I put the review key, "<-" in column 0, the go key, "->", in column 1, and the CR key in column 3.

Instead of trying to make it possible to set an address, this version accepts that there is a single starting address and GO will jump to that address ... and uses restarting the whole thing, including the original setting of the address, to go back for the review run.

The key to making the <- function fit in was the realization that it doesn't have to be prevented from auto-repeating ... because multiple repeated executions of setting W:W+1 to $00:$02 for a single press of the <- (or "review") key gives the same result as a single "<-" keypress. So just going to the start where the base address is originally set should work.

Putting the tac switch (or whatever button) for that on the 0 column is partly so that the review key, at least, shouldn't glitch the LED display ... if still pressed, it will run through one full column cycle of unpressed keys until hitting the 0 column and redo the restart at that point. But it is also an aesthetic choice, since if the ReView key is a silkscreened as a left "<-" arrow, then the GO switch next to it can be silkscreened as a right "->" arrow if desired. 8)

Or a more mundane, though likely more mnemonic, "RV" (for review or reverse, take your pick), "GO" and "CR". (Also noting that "GB" for Go Back and "GA" for "Go Ahead" would be both mundane and also excessively obscure.)

Rather than comparing to each command key, this one distinguishes between hex keys and command keys (which involves a slight hardware change), and then a comparison with the index state for the middle (GO) key distinguishes between that key (BEQ), the one to it's left (BMI), and then by implication the one to its right.

Code: Select all

VERSION = $00 ; alpha
REVISION = $01 ; first revision

; 125  total
; main: 80
; to_leds: 25
; vectors: 4
; table: 16

; Note:
; the special key row goes to d6
; d7 is !(row0 # row1 # row2 # row3 # row4)
; so no need to clean up hex key before "or" op.
; For branching to work, need to know where keys are:
; Column 0 = "<-", Reverse key (restart)
; Column 1 = "->", Go key (execute routine)
; Column 3 = "CR", CR key, next address

; Paleolithic
led_addr	= ????
keys 		= ????
addr0		= $0200

; Neolithic
;led_addr	= $0880
;keys 		= $0886
;addr0		= $1000

W		= $00 
leds 		= $02

KEY_RV 		= %11000000
RV_INDEX	= 0

KEY_GO		= %11000001
GO_INDEX	= 1

KEY_CR		= %11000011
CR_INDEX	= 3

	code
	org $ff80
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

exec:	jmp addr0	; +3

			; +6
start:	; Set base address, this is also "review"
	lda #>addr0
	sta W+1
	stz W		; start address addr0, page aligned
loop_main:		; +2
	; Initialize the display count
	; we have eight leds but we only drive six (5..0)
	; to save code space (we don't need to clear them)
	ldy #5
	
loop_digit:		; +17
	; current state to leds
	; put W and (W) into leds
	; [x][x][x][x][x][x][ ][ ]
	; (also provides a short delay for the LED multiplex)

	ldx #0
	lda W+1
	jsr to_leds
	lda W
	jsr to_leds
	lda (W)
	jsr to_leds

			; +10
	; for each LED digit (right to left)...
	lda leds,y
	sta led_addr,y	; display bit pattern
	bit keys
	bmi loop_99	; no key pressed


			; +8
	; do stuff to sort out which key	
	; a hex key if V clear (bit6=0)
	bvc loop_hex	; enter hex value

	; sort out the command key by index	
	cpy #GO_INDEX
	beq exec	; execute on Go key
	bmi start	; return addr0 to review

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

loop_hex:		; +17
	; else shuffle key value into (W)
	lda keys
	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
	
to_leds:
	; unpack byte into two adjacent LED patterns
	; x has character position
	phy
	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
	ply
	rts		
	
	org $fffc
	dw start
	db VERSION,REVISION

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Sun Jun 08, 2025 10:04 pm
by BruceRMcF
BruceRMcF wrote:
... Non-critical design change:
"no-key" sets d7, "key" resets d7, so the d7 bit doesn't have to be cleaned up when a hex value as the new low nybble is being "or"ed with the new high nybble (not doing this leaves the requirement for an "AND #$7F" in place.
I will note that I recognize the elegance of using 2/3's of a triple, 3 input OR for:

1A <= row0
1B <= row1
1C <= row2
1Y => 2A

2A <= 1Y
2B <= row3
2C <= row4
2Y => driver_input7

... and unless there is a bug in the below (which is, of course, always possible) which requires too many bytes to fix, it would still work to take this:

Code: Select all

 ...
	bit keys
	bmi loop_99	; no key pressed
...
loop_hex:		; +17
	; else shuffle key value into (W)
	lda keys
	pha
	lda (W)
	asl a
	asl a
	asl a
	asl a
	sta (W)
	pla 
	ora (W)
	sta (W)
...
... and add the AND missing from the original routine, required to clean up the marker bit, which would have left all Hex input in the range of $80-$FF (as it's the highest bit which would have been or-ed in):

Code: Select all

 ...
	bit keys
	bpl loop_99	; no key pressed
...
loop_hex:		; +19
	; else shuffle key value into (W)
	lda keys
	and #$7F
	pha
	lda (W)
	asl a
	asl a
	asl a
	asl a
	sta (W)
	pla 
	ora (W)
	sta (W)
...

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Mon Jun 09, 2025 5:28 am
by barnacle
Oh rats... I thought about that AND and forgot it...

But I can remove the original clearing of the Y register - eventually the count will get to 5 and it will then reset to zero - and use the space for the AND, I think. Hmm.

Neil

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Mon Jun 09, 2025 10:30 am
by BruceRMcF
barnacle wrote:
Oh rats... I thought about that AND and forgot it...

But I can remove the original clearing of the Y register - eventually the count will get to 5 and it will then reset to zero - and use the space for the AND, I think. Hmm.

Neil
Having the setting of the count shared between the start and the iterations by where you set your loop target (refer to the two loop targets in my code above when Y is decremented), it no longer costs an extra two bytes ...

... and starting the count at 5 and counting down to 0 buys two more bytes, because you don't need to do a compare to know whether or not you have reached the end of the iterations ... when it underflows from positive to negative, you are at the end of one digit cycle and know that you can loop back to where the Y value was originally set to restart the digit cycle.

So you were never in a bind about the AND.

Where my code squeezes in the ability to test for three command keys instead of two is in having the "command key row" being connected to the input that drives D6 on the data bus, so that a BIT of KEYS tests for the key marker and whether it is a hex key in one check. Since there would be exactly three command keys, once it's divided between special keys and hex keys, the special keys only need one compare in the middle to infer work out which one of the command keys it is ... so long as you know their order on the keyboard.
[Edit: No, that wasn't it, it was just splitting between hex and command keys up front that did it, it can be done with a CMP to the smallest command key value, so it's not necessary to rewire that at all.]

I compare to the Y index value rather than to the Key value because my code doesn't do a LOAD KEY untll hitting the hex keys, but with the original marker, but the command key on Bit6 of the character, it would be equivalent to do :

Code: Select all

        LDA KEYS
        BPL loop_99
        BIT KEYS
        BVC loop_hex
        CMP #GO_KEY
        BEQ exec
        BMI start
        ; ... (CR code here)
... that is just squeezing the toothpaste around in the tube.

Huhn, I just now realized that there's no need to move the command key line around ... on loading KEYS, then instead of BIT, you can do a compare to the lowest command key:

Code: Select all

        LDA KEYS
        BPL loop_99
        CMP #RV_KEY
        BMI loop_hex
        BEQ start
        CMP #GO_KEY
        BEQ exec
        ; ... (CR code here)
So scratch everything I wrote about moving that command row line around being "critical" ... it is, instead, instead, entirely unnecessary, and more sound practice (given the a hardware debounce with hysteretic Schmitt Triggers) to just sample KEYS once.

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Mon Jun 09, 2025 11:02 am
by BruceRMcF
SO I guess that makes Revision 2, but still, 16byte segment table, Go, Review and CR functions, and it all fits with a byte or two to spare.

I just realized that if you want to view the state of things within the $0200+ domain when code isn't working as intended (it won't work to look at the stack or the zero page), you can actually set the IRQ/BRK vector to "start" as well ... that won't work if the code that is punched in starts up interrupts, but it seems like that is a "don't do until the EEEPROM takes over from the DROM" thing in any event, but in the second stage of the bootstrap, it would support BRK points.

I'm going to do a recount of the size when it's not so early in the day, to verify whether there is space in my revision of your code for the "post-Paleolithic nicety" of Version/Revision bytes.

EDIT: I did that recount, and the two bytes could be used to implement the fourth Action key, "Page Forward" (increment the page byte of the address). With one compare to the lowest key detecting both the hex keys and also the "Review" key, leaving only three possible keys, one compare of the 3rd key, "PF" (">>") support BMI for the GO key and BEQ for the PF key, leaving CR as the remaining action by elimination.

Code: Select all

VERSION = $00
REVISION = $03 ; 2025-06-09

; 128  total
; main: 83
; to_leds: 25
; vectors: 4
; table: 16

; Note:
; the special key row goes to d6
; d7 is !(row0 # row1 # row2 # row3 # row4)
; so no need to clean up hex key before "or" op.
; For branching to work, need to know where keys are:
; Column 0 = "<-", Reverse key (restart)
; Column 1 = "->", Go key (execute routine)
; Column 3 = "CR", CR key, next address

; Paleolithic
led_addr	= ????
keys 		= ????
addr0		= $0200

; Neolithic
;led_addr	= $0880
;keys 		= $0886
;addr0		= $1000

W		= $00 
leds 		= $02

KEY_RV 		= $90 ; %10010000
KEY_GO		= $91 ; %10010001
KEY_PF		= $92 ; %10010010
KEY_CR		= $93 ; %10010011

	code
	org $ff80
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

exec:	jmp addr0	; +3

			; +6
start:	; Set base address, this is also "review"
	lda #>addr0
	sta W+1
	stz W		; start address addr0, page aligned
loop_main:		; +2
	; Initialize the display count
	; we have eight leds but we only drive six (5..0)
	; to save code space (we don't need to clear them)
	ldy #5
	
loop_digit:		; +17
	; current state to leds
	; put W and (W) into leds
	; [x][x][x][x][x][x][ ][ ]
	; (also provides a short delay for the LED multiplex)

	ldx #0
	lda W+1
	jsr to_leds
	lda W
	jsr to_leds
	lda (W)
	jsr to_leds

			; +10
	; for each LED digit (right to left)...
	lda leds,y
	sta led_addr,y	; display bit pattern
	lda keys
	bpl loop_99	; no key pressed

			; +12
	; do stuff to sort out the key value	
	; a hex key if V clear (bit6=0)
	cmp #KEY_RV
	bmi loop_hex	; enter hex value
	beq start	; return addr0 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
	; else shuffle key value into (W)
	and #$7F
	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
	
to_leds:		; +25
	; unpack byte into two adjacent LED patterns
	; x has character position
	phy
	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
	ply
	rts		

	org $fffc	; +4
	dw start
	dw start	; support BRK in code

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Mon Jun 09, 2025 3:40 pm
by BruceRMcF
SO, tl:dr:
  • Fits in 128byte DROM
  • Includes hex to 7segment translation table
  • Shift new hex digits into data byte from the lower digit toward the upper digit
  • Accept value at current address and move to next by hitting CR (either one)
  • Jump a binary page forward by hitting PF (or ">>")
  • Execute code at built-in base address by hitting GO (or "->")
  • Review the code that has been entered by hitting RV (or "<-")
  • Use as a micro-monitor for entered code by inserting BRK points
While the micro-monitor itself is has sharp limits on what it can view (no stack, on zero page, no flag register display, etc.), if the code at "addr0" starts with something like "CLC : BCC start_main", it can jump over a stretch of code to do things after a BRK like pull the flag byte pushed at the break and store it, pull the return code for the BRK to know which one was hit (if more than one) and store it, copy information from the ZP or Stack you want to see, whatever ... ending with a break at the end of that short snippet of debugging code.

Then after the BRK is triggered, the micromonitor comes up at the base address, edit the CLC to SEC and hit GO, and the first BRK that brings the micromonitor back up will be the end of the routine the put the desired debugging information where you can go look at it.

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Mon Jun 09, 2025 7:06 pm
by barnacle
So I think our versions are both very similar, but depend on the exact keyboard decoding code.

Therefore I will think about hardware again for a while.

Neil

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Mon Jun 09, 2025 7:22 pm
by BruceRMcF
barnacle wrote:
So I think our versions are both very similar, but depend on the exact keyboard decoding code.

Therefore I will think about hardware again for a while.

Neil
Yes, the reason they are very similar is that all I've done after all is some modest rearrangements to your original code, to make it work with the hardware you described. bit7 set on key pressed, the special keys with bit5 set and the key column in the bottom two bits ...

... wish-listing alternative hardware that would make the programming easy was just wandering around false paths in the forest until an actual path appeared.

Squeezing a couple of bytes out through judicious use of loop targets and picking actions that can executed by jumping to code that already exists was enough to fit all four functions into 128 bytes.

It's (1) the order that the key parsing is executed, (2) pinning down exact values for which command key is where and (3) having the CR key in the fourth column (since it is RV, PF and GO that are best done with branches), which reduces the number of bytes needed to 4.

Code: Select all

     CMP #ThisThing
     BNE check_that_action
     ; do ThisAction
     ; ...
check_that_action:
     CMP #ThatThing
     BNE do_that_other_thing
     ; do ThatAction
     ; ...
do_that_other_thing
     ; It must be TheOtherThing
     ; do it
...
... is really handy for letting the value of "ThisThing" and "ThatThing" be arbitrary, but two bytes are saved if you know that there are only three possibilities, and you know what order they are in:

Code: Select all

     CMP #TheMiddleThing
     BMI TheLowerAction
     BEQ TheMiddleAction
     ; It must be TheHigherAction
...
So with the order of keys values (from lowest to highest):
  • All hex values
  • Review Key
  • Go Key
  • Page Forward Key
  • Carriage Return
It's just two comparisons that are needed ... compare to the review key finds the hex keys and the review key, compare to the Page Forward key finds the Go Key, the Page Forward Key, and by elimination the CR.

Since the two new actions (Review and Page Forward) could be implemented by just branching to the right location, only four bytes were needed to add the two branches for the two new actions.

Those four bytes were available after tightening up the looping code by reversing the digit scan to scanning from high to low, and making the initial setting of Y into the outer loop loop target, so it's not necessary to include the code to set the Y index twice in the same loop. That is:

Code: Select all

        LDY #0
loop:
        ...
        INY
        CPY #6
        BMI loop
        LDY #0
        BRA loop
... into ...

Code: Select all

loop_main:
        LDY #5
loop_digit:
        ...
        DEY
        BPL loop_digit
        BRA loop_main
Those are the four bytes saved that make room for the four bytes to add the two additional command keys.

Like I said, I do think that setting the key pressed bit with two 3-input OR gates is nifty, I wouldn't want to have to add a gate to invert it if bytes can be found elsewhere.

The key hardware challenge is avoiding double-pressing CR or PF due to bounce. Without an ability to head back one line, having to go all the way through the code to get back where you were because of a key bounce would be maddening.

Especially if the code put into the base address gives feedback, a missed press is much less trouble than a bounced press ... because RV, PF, CR and a hex key all give very immediate feedback, missing a keystroke is not as much of an issue.

And giving feedback that the code that has been painstakingly assembled byte by byte has started to run is pretty easy, because the lack of use of the decimal point in the DROM code means that one decimal point in the first digit when the code starts going makes it clear that "we aren't in DROM anymore":

Code: Select all

     LDA #$80
     STA ledaddr
aka A9 80 8D B0* 00 {*if ledaddr happens to be at the base of the $B000 page.}

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Tue Jun 10, 2025 4:45 am
by BruceRMcF
BTW, this guy likes to debounce with a 555 timer at the end of an RRC circuit ...

https://www.youtube.com/watch?v=Y-c7lf7mGok

... though I am unsure how this compares to a Schmitt-Trigger, since it seems like what he is doing is using the 555 as a Schmitt-Trigger inverter. Does it perhap give a laggier threshold crossing, where the lag itself helps improve the quality of the debounce?

I wonder if one is using switches that don't normally tend to bounce very long (to use precise statistical terminology), whether one could consider putting the full RC / series of Schmitt-Trigger inverters circuit on the command key line and just use a "pretty good" debounce for the hex key lines ... since with this micro-monitor, if the hex key input is only rarely flaky, it can be fixed up immediately.

I think possibly the simplest to fit into the circuit board for a reasonably fast closing/opening switch would be a LogiSwitch LS19-P, which gives 6 circuits with what seems like pretty good hardware debounce of a 20ms delay before a transition is triggered.

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Tue Jun 10, 2025 4:56 am
by barnacle
I'm still contemplating whether making the key array eight by three would help things. Certainly it needs fewer gates to encode the keys, and the command keys remain on a line of their own (and could live at any convenient position therein).

Neil

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Tue Jun 10, 2025 1:27 pm
by BruceRMcF
barnacle wrote:
I'm still contemplating whether making the key array eight by three would help things. Certainly it needs fewer gates to encode the keys, and the command keys remain on a line of their own (and could live at any convenient position therein).

Neil
With my four command key parsing revision of your code, there's no room to zero out the top two digits. They'd just light at whatever state the top two bytes of the led table happened to be in.

With my revision cut back to two command keys, there's six additional bytes (only one comparison and two branches needs to parse, rather than two comparisons and four branches), so there's room to add "LDA #0 : JSR to_leds" at the end of the current leds output.

(Of course, with my 4 command revision, a short routine could always be keyed in to zero out the high bytes of the led vector, terminated by a break. If "leds" is at $00F8, Key in:

Code: Select all

6 4 F E 6 4 F F 0 0 GO
That would be really paleo.)

But with the four command key code, laying out the switches as:

Code: Select all

8   9   A   B   C   D   E   F  :  Row %xxx01xxx

0   1   2   3   4   5   6   7  :  Row %xxx00xxx

RV      GO          PF      CR :  Row %xxx10xxx
... would be perfectly fine, it's just changing the equate for the PF key.

Indeed, with that layout, you could have 8 command switches for potential use by the code being punched in, while still only parsing four switches for the DROM micromonitor, which under my four command parsing revision of your code would by interpreted as:

Code: Select all

8   9   A   B   C   D   E   F

0   1   2   3   4   5   6   7

RV  GO  GO  GO  GO  PF  CR  CR
Then in the 65C02, when code in the EEPROM is interacting with the key switches, with more room available than is available in the DROM, "JMP (addr,X)" can finish the parsing:

Code: Select all

        ; keycode in A
        CMP #KEY_CMD0
        BPL hexkey
        AND #$0F
        ASL
        TAX
        JMP (command,X)
hexkey: JMP (do_hex)
... and, indeed, "do_hex" can be a vector in RAM and "command" a vector table, written on startup to hold default vectors calling into ROM for the monitor or mini-monitor.

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Tue Jun 10, 2025 4:31 pm
by Dr Jefyll
barnacle wrote:
Certainly it needs fewer gates to encode the keys, and the command keys remain on a line of their own
Lately I've not been following this topic closely, so I have no opinion about the command keys remaining on a line of their own. But it does strike me as odd that you're using actual gates to encode the keys. Can't that encoding be accomplished with a suitable array of diodes instead? For this project in particular, I think such a choice would be satisfyingly appropriate!

-- Jeff

Re: First thought on an interface (to use Paleolithic DROM)

Posted: Tue Jun 10, 2025 4:42 pm
by barnacle
/me Starts thinking...
All times are UTC
Page 3 of 13

Powered by phpBB® Forum Software © phpBB Limited