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 1 of 13

First thought on an interface (to use Paleolithic DROM)

Posted: Wed Jun 04, 2025 5:54 am
by barnacle
6502_minimal-Display_keyboard.pdf
(240.89 KiB) Downloaded 98 times
Noodling ideas here; the basic requirement is a minimal interface which fits in 128 bytes (including the reset vector!). There's no decoding logic yet, but: the scan for the keypad and LED select occupies 8 sequential addresses with a further address to write the LED pattern and read the pressed key(s).

I suspect a main loop will read bit patterns directly from eight memory locations; reading the keys after each column. If a key is pressed it either executes code from the default address (go); increments the current address (return); or shifts the byte at the current address left and adds itself as the low byte (hex keys).

It's going to need sixteen bytes to store the LED patterns, which is a pain, and I don't think there's going to be space to select a start address - a default is likely $0200 to keep the zero page and stack free.

The remainder of the hardware will be a 65c02, 65256 ram, 24c256 eeprom (half only), 68b50 uart (because I've got some).

Thoughts?

Neil

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

Posted: Wed Jun 04, 2025 11:57 am
by BruceRMcF
[Edit] Wait, scratch that.

Not sure about the LEDs ... I'd be tempted to go Neolithic and use a 32x4 SPI text display, but perhaps the smallest a micro-monitor syntax would work with would be 6 7-segment displays, which would be 6 locations (one for each latch for the seven segments & decimal point) plus a 16byte table in the PDROM code for the value to display translation. Have all segments lit up as the cursor. Then a 6 digit clock LCD / LED could be used. The ":" between the fourth and fifth clock display digit could be wired on.

The "." would be the non-hex display, and while not very mnemonic, you could have . in the 5th digit and nothing in the 6th digit for goto to displayed address, equivalent to .0, and the option of additional actions (to room available) .1-.F ... but .1 for JSR to address would be an obvious one to include if it's just two.

Whether six or eight LED displays, simple input line storage supporting a "silent cursor" for a hex display is the lower four bits for a hex value, bits4..7=0, and bit 7 set for an exceptional situation. The two exceptional circumstances are location not entered, which is bit0..6=0, and ".", which is bit1=1, bit1..6 empty. Then the display shows all unfilled locations as all unlit.

And the point LCD is wired to bit0.

When a hex value or . is pressed, scan down to the first unfilled location, and store the hex value or $81 there.

When "-" is pressed, test if the 5th position is filled. If it is, blank digits 5 and 6. If it is blank, then blank positions 1 to 4. That allows seeing a byte at an address and then replacing it with a different byte at that address, or performing a jump to that address, and also allows entering an all new address.

When "+" is pressed, start at the 4th to 1st entry positions and replace all empty positions or '.' with $0 then increment the address in positions 1 to 4{*}, then use the routine below to show the byte at that location.

When <CR> is pressed, start at the X=3 position to the X=0 position and replace all empty positions or '.' with $0, then:
* If position 5 is empty, read the byte at the address in TIB and store it in input positions 5 and 6 (the same routine is used in "+")
* If position 5 has a ., perform the function indicated by position 6 (only bits0..3, so empty is function 0, jump to, and "." is function 1, jump subroutine.
* Otherwise, position 5 has a hex value, store the value represented by positions 5 and 6 at the address represented by positions 1 to 4, and do the "+" routine.

With that, to display the Xth value to display:

Code: Select all

    LDY TIB,X
    BMI NONHEX
    LDA HEX2DISP,Y
    BRA DISPLAY
NONHEX:
    TYA
    AND #1
DISPLAY:
    ...
_______
{* Increment displayed address:

Code: Select all

INCAD:
        JSR GETAD
        INC V
        BNE +
        INC V+1
+       JSR PUTAD
        RTS

GETAD:
        LDA %$80
        TRB TIB+1
        TRB TIB+3
        LDX #0
        JSR GETBYTE
        STA V+1
        JSR GETBYTE
        STA V+1
        RTS

GETBYTE: ; high position in X
        ; Returns Byte in A, X_1=X_0+2
        LDA TIB,X
        ASL
        ASL
        ASL
        ASL
        INX
        ORA TIB,X
        INX
        RTS

PUTAD:
        LDX #0
        LDA V+1
        JSR PUTBYTE
        LDA V
        JSR PUTBYTE
        RTS

PUTBYTE: ; high position in X, Byte in A, Uses Y
        ; Returns Byte in A, X_1=X_0+2
        TAY
        LSR
        LSR
        LSR
        LSR
        STA TIB,X
        INX
        TYA
        AND #$0F
        STA TIB,X
        INX
        RTS

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

Posted: Thu Jun 05, 2025 3:45 am
by Dr Jefyll
barnacle wrote:
Thoughts?
I think the 'AHC541 will function more satisfactorily if the inputs & outputs are swapped rather than being connected as shown. :wink:

But perhaps that '541 (which acts as an unlatched input port) could be eliminated. Instead, your '574 latched output port could be replaced by a single, bidirectional device which acts both as an (optionally latched) input port and a latched output port. Possible candidates include the 74HC(T)646 and '652; also the 74FCT543 or 74LVC543.

More casually, the same highly compact effect can be achieved by soldering a '245 on top of a '574. :mrgreen: The photos below show how on one side the 8 data pins bridge straight (more or less) from chip to chip, and on the other side they bridge with a 1-pin offset. For your application, the 245's DIR (pin 1) needs to be tied low (and not tied to the 574's pin 1).

-- Jeff
pins 1 to 10.jpg
pins 11 to 20.jpg

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

Posted: Thu Jun 05, 2025 5:39 am
by barnacle
Dr Jefyll wrote:
barnacle wrote:
Thoughts?
I think the 'AHC541 will function more satisfactorily if the inputs & outputs are swapped rather than being connected as shown. :wink:
Oops! :oops: Details, details...

It would be nice if the hardware more directly encoded the key press, though. At the moment, the bottom two bits of the read address have the low bits of the key; it would be handy to find a way to do something similar to the row values. At the moment it's necessary to shift and count... and while the 65c02 is a very nice instruction set it's not always very dense.

Code: Select all

                        	bss
0000 =                  	org 0
0000 =                  leds	ds 8	; led will display patterns stored here
0008 =                  mem_ptr	ds 2	; where are we writing?
                        
b000 =                  keys		equ $b000
b800 =                  led_addr	equ $b800
                        
                        	code
ff80 =                  	org $ff80
ff80 : 3f               LED_PATTERNS	db 0b00111111	;0
ff81 : 06               				db 0b00000110	;1
ff82 : 5b               				db 0b01011011	;2
ff83 : 4f               				db 0b01001111	;3
ff84 : 66               				db 0b01100110	;4
ff85 : 6d               				db 0b01101101	;5
ff86 : 7d               				db 0b01111101	;6
ff87 : 07               				db 0b00000111	;7
ff88 : 7f               				db 0b01111111	;8
ff89 : 6f               				db 0b01101111	;9
ff8a : 5f               				db 0b01011111	;a
ff8b : 3c               				db 0b00111100	;b
ff8c : 28               				db 0b00101000	;c
ff8d : 5e               				db 0b01011110	;d
ff8e : 7d               				db 0b01111101	;e
ff8f : 71               				db 0b01110001	;f
                        
ff90 :                  start:
ff90 : a902             	lda #2
ff92 : 8509             	sta mem_ptr+1
ff94 : 6408             	stz mem_ptr		; start address $200
ff96 :                  main:				
ff96 : b90000           	lda leds,y
ff99 : 9900b8           	sta led_addr,y
ff9c : ad00b0           	lda keys
                        	; do stuff to sort out the key value
                        	; if key value = return
                        	;	increment memory address pointer
                        	; endif
                        	; if key value = go
                        	;	jump to $200
                        	; endif
                        	; shuffle key value into (mem_ptr)
                        	; convert mem_ptr and (mem_ptr) into leds
ff9f : c8               	iny
ffa0 : c008             	cpy #8
ffa2 : d0f2             	bne main
ffa4 : a000             	ldy #0
ffa6 : 80ee             	bra main
                        	
fffc =                  	org $fffc
fffc : 90ff             	dw start
There's a big chunk of ??? in the middle there, and not a huge amount of memory left :mrgreen:

Neil

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

Posted: Thu Jun 05, 2025 1:11 pm
by barnacle
In theory, this should do away with any need to translate the keyboard code... note that there's still a lot of glue logic missing, along with little things like power, decoupling...
6502_minimal-Display_keyboard.pdf
(334.03 KiB) Downloaded 65 times
  • Output a character by reading a value, indexing into the LED symbol table, and writing to the same offset above the LED base
  • That latches the lower three bytes of the address into U12, which is decoded by U10 to drive the common cathode of the selected LED
  • The lower two bits of the LED count form the lower two bits of the keycode (note the changed key values); that is, the column
  • The next three bits are a binary coded value of the row with a key pressed
  • IC16A, 15C, and 14A set A7 high only when a key is pressed
It's still going to be subject to key bounce, but it means a single read both reads the keypress and tests its presence; if the value is negative, it's valid, and no need to do any translation.

Usually, of course, we trade silicon for software, not this way around...

U16 could be replaced with the remainder of U14, though the output would be ground when a key is pressed.

This approach gets messy when you add a sixth row of buttons, but could be done with 4-input NORs, if they're still available. And of course you can extend the columns to eight easily; you'd just need to drop Q2 as A2 and move everything else up one. But you'd need the keys to match 0-7 and 8-f across a column.

Don't forget to keep scanning to keep the display multiplexing!

Neil

p.s. we could save a few bytes if we arrange the display and rom addresses to be in zero page when the DROM is used.

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

Posted: Thu Jun 05, 2025 2:26 pm
by barnacle
That first point wasn't very clear... the display is addressed at eight sequential locations, with the leftmost at the lowest address. For each character, the bit pattern stored in LED_PATTERN is used to generate the digit, latched on writing. Next, the desired digit address is latched, and decoded to a low output which forms the common cathode. That is also latched so that the lower two bits of the character address appear on the input buffer (which is now the right way around). The decoded common cathode drive is inverted so that the corresponding column is high.

All the rows are pulled low, unless a switch is pressed to pull a row high. The active row is directly coded into the top three bits of the keycode, and an OR of all the rows indicates that a key has been pressed.

This would very easily expand into an 8 by 5 matrix - sadly not quite enough to get between letters, numbers, punctuation, and enter/backspace etc though that would be ok with an 8 by 6 matrix, I think. Might still be one or two short.

Neil

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

Posted: Fri Jun 06, 2025 2:14 am
by BruceRMcF
barnacle wrote:
... All the rows are pulled low, unless a switch is pressed to pull a row high. The active row is directly coded into the top three bits of the keycode, and an OR of all the rows indicates that a key has been pressed.

This would very easily expand into an 8 by 5 matrix - sadly not quite enough to get between letters, numbers, punctuation, and enter/backspace etc though that would be ok with an 8 by 6 matrix, I think. Might still be one or two short. ...
But there is also limited code space to cope with letters, numbers, punctuation, enter/backspace.

Hence the appeal of semantics based around four special keys ... ".", "-", "+", <CR>.

If the bit0..3 lines are the hex values as 0..3, 4..7, 8..B, C..F, and the final line are special keys, then the special key has the bottom two bits to specify which special key it is. So my original notion of reacting right away and using the current index to tell which special key it is can be abandoned for just going through a no-rollover LED light / Key read loop and storing a key if it is encountered.

Sketching with 6 7-segment LED's as the minimal display does break the symmetry, but it does free up two of the select lines, so one could be used for the LED latch...

Code: Select all

KEYQ:   LDX #6
        STZ KEY ; in zpage
        JSR DISPX
        JSR DISPX
DISPLP: JSR DISPX
        BPL NOKEY
        STA KEY
NOKEY: CPX #0
        BNE DISPLP
        ...

DISPX:  DEX
        LDA TIB,X
        TAY
        LDA LEDSYM,Y
        STA LED+$7
        LDA LED,X
        RTS
I don't know whether debouncing could involve running a certain number of LED display loops without checking for a key:

Code: Select all

DEBNCE: LDA #magic
        STA CNTDN ; zpage
DEBOLP: LDX #6
DEBILP: JSR DISPX
        CPX #0
        BNE DEBILP
        DEC CNTDN
        BNE DEBOLP
        ...

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

Posted: Fri Jun 06, 2025 5:20 am
by barnacle
Definitely no space to handle a keyboard using the DROM; that was just an idle thought as to how the method could be extended: a keyboard, without a keyboard controller.

As it is (if I drew it right) a single read of the input port address provides keys 0 to F as $00 to $0f, with 'run' and 'return' producing $10 and $11 respectively - providing that the columns are scanned by the LED driving code. In all cases, bit 7 is set only when a key is pressed. So it's necessary to read the key value after each digit has been displayed, to see if the key is pressed. I suspect there won't be any code space left to think about debounce; my initial code will (should!) run the display including the translation, but there are only a handful of bytes left for everything else.

I need to look at your code and work out what it's doing; it's a lot shorter than mine. Though given the evolution of NTB it's clear that there are people out there who are much better at writing short code than me :mrgreen: Certainly using fewer LED digits is a possibility; six is obvious, and since we're writing really only to five - $0200 onwards - we can ignore one more if we need to. We don't need to write the end two or three columns, so they'll never display garbage.

Unpacking the address and data bytes for display is what's slowing me down; getting them displayed is easy!

Neil

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

Posted: Fri Jun 06, 2025 7:10 am
by BruceRMcF
barnacle wrote:
Definitely no space to handle a keyboard using the DROM; that was just an idle thought as to how the method could be extended: a keyboard, without a keyboard controller.

As it is (if I drew it right) a single read of the input port address provides keys 0 to F as $00 to $0f, with 'run' and 'return' producing $10 and $11 respectively - providing that the columns are scanned by the LED driving code. In all cases, bit 7 is set only when a key is pressed. So it's necessary to read the key value after each digit has been displayed, to see if the key is pressed.
Oh, is the LED display and key access two different steps? I had thought that the display code is latched, and then when reading the key value that generates the /selector for the LED display. That certainly leads to less code.

I've realize that with my semantics, it's only necessary to store an address, a data byte, the number of digits to be display, and whether digit 5 is a period or a number ... where if it's a period, the high nybble of the data byte doesn't matter.

Indeed, with my semantics, "." can just trigger a separate dirty bit/byte, so there is no real need to store the "text" in the "text input buffer" ... the direct LED code can be stored there instead.

And the direct LED code could be generated a pair of LED's at a time, from a byte in A that the main routine is grabbing from the data byte or the address vector. Again, this assumes that the dot is wired to bit0 of the latch:

Code: Select all

HEXOUT: LDX #0
        LDA V+1
        JSR PUTLED
        LDA V
        JSR PUTLED
        LDA DATA
        JSR PUTLED
        BIT DOTQ ; DOT? is #$FF if there is, $0 is there isn't
        BPL +
        STZ LOB+4
        INC LOB+4
+       RTS

PUTLED: ; First digit position in X, Value in A
        ; X returns first digit position following the pair of display codes
        PHA
        LSR
        LSR
        LSR
        LSR
        TAY
        LDA CODE,Y
        STA LOB,X ; LED Output Buffer
        INX
        PLA
        AND #$0F
        TAY
        LDA CODE,Y
        STA LOB,X
        INX
        RTS
Then I just need to know how many digits to display, which is a single OUTLEN byte, to know when to stop using the code for the LED and to use 0 instead:

Code: Select all

SHINE:  LDX #0
SHINELP:
        LDA LOB,X
        CPX OUTLEN
        BMI SHOWIT
        LDA #0
SHOWIT: STA LEDLATCH
        LDA LED_KEY
        BPL NOKEY
        STA KEY
NOKEY:  INX
        CPX #6
        BMI SHINELP
        RTS
Now "-" as a two stage "rubout" saves most of its code, since it only sets the OUTLEN:

Code: Select all

RUBOUT: STZ DATA ; data byte is rubbed out in any event
        LDA #5
        CMP OUTLEN
        BMI RUBALL
        DEC
        STA OUTLEN
        BRA NEXTKEY
RUBALL: STZ V ; address vector is rubbed out as well
        STZ V+1
        STZ OUTLEN
        BRA NEXTKEY
        ...
"." just makes a "." appear in digit 5

Code: Select all

DODOT:  STZ DOTQ
        DEC DOTQ
        LDA #5
        STA OUTLEN
        BRA NEXTKEY
        ...
"+" increments V and sets display to 4 digits:

Code: Select all

DOPLUS: INC V
        BNE +
        INC V+1
+        LDA #4
        STA OUTLEN
        BRA NEXTKEY
        ...
And then <cr> does what it does based on OUTLEN and DOTQ.

Code: Select all

DORET:  LDA #5
        CMP OUTLEN
        BMI ACT
        LDA (V)
        STA DATA
        LDA #6
        STA OUTLEN
        BRA NEXTKEY
ACT:   BIT DOTQ
        BMI BRANCH
        LDA DATA
        STA (V)
        BRA DOPLUS
BRANCH: ; this only implements JUMP and JSR
        LDA #1
        BIT LOB+5 ; last digit
        BEQ GOTO
        JSR GOTO
        LDA #4
        STA OUTLEN
        STZ DATA
        BRA NEXTKEY
GOTO:   JMP (V)
Quote:
I suspect there won't be any code space left to think about debounce; my initial code will (should!) run the display including the translation, but there are only a handful of bytes left for everything else.
Yes, it's the main loop I don't have at present, as I don't know what approach to debouncing would work as well as being most parsimonious, where being parsimonious with hardware and code often conflict. There are six lines going into the keyboard read driver ... maybe a pair of hex Schmitt-Trigger inverters would clean up noise a bit, and I have a vague notion that there'd need to be caps on the lines before the code can start to think about assuming that the a non-keypress implies that the next keypress is a new key, but I wouldn't have a clue what size of caps and what else would be needed on those lines to debounce "well enough" in hardware.

If they were platonic ideal, bounce-free keys, it might be:

Code: Select all

FIRSTKEY:
        STZ PRESS
NEXTKEY:
        JSR HEXOUT
        JSR SHINE
        LDA KEY
        EOR PRESS
        BPL NEXTKEY
        BIT KEY
        BMI NEWKEY
        ; previous pressed key released
        STZ PRESS
        BRA NEXTKEY
NEWKEY:
        DEC PRESS ; don't auto-repeat
        LDA #$80
        TRB KEY
        LDA $%00010000 ; special key
        TRB KEY
        BNE SPECIALKEY
        LDA OUTLEN
        CMP #6
        BRA NEXTKEY ; waiting for special key
        INC OUTLEN
        LSR
        EOR #$FF ; = -index-1
        ; Old OUTLEN/2 = 0 -> V+1 -> V+2,[X=$FF]
        ; Old OUTLEN/2 = 1 -> V+1 -> V+2,[X=$FE]
        ; Old OUTLEN/2 = 2 -> V+1 -> V+2,[X=$FF]
        TAX
        LDA KEY
        BCS LOWNYBBLE
        ASL ; put high nybble in place
        ASL
        ASL
        ASL
        STA V+2,X
        BRA NEXTKEY
LOWBYTE:
        ORA V+2,X
        STA V+2,X
        BRA NEXTKEY
SPECIALKEY: ; Assuming: . + - <cr>
        AND #3
        BEQ DODOT
        DEC
        BEQ DOPLUS
        DEC
        BEQ RUBOUT
DORET: ...

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

Posted: Fri Jun 06, 2025 8:10 am
by barnacle
Here's my thought for a complete interface, which uses _all_ 128 bytes, except the vector at $fffe... I hope I haven't forgotten anything.

It displays six bytes only, four address starting with $0200 and two data. Pressing a hex key shifts it as the low byte of the currently pointed-to data; pressing 'run' executes 0x200; pressing 'return' advances the memory pointer. There's a wait for the key to be released which will stop the multiplex until you get your finger off the key.

Code: Select all

keys		equ $b000
led_addr	equ $b800
RUN			equ $10
RETURN		equ $11

	bss
	org 0
leds	ds 8	; led will display patterns stored here
mem_ptr	ds 2	; where are we writing?

	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

start:
	lda #2
	sta mem_ptr+1
	stz mem_ptr		; start address $200
	ldy #0			; not strictly required... will get there eventually
loop:			
	; for each character...
	lda leds,y
	sta led_addr,y	; display bit pattern
loop_01:
	lda keys
	bpl loop_90		; no key pressed...
	; do stuff to sort out the key value
	; if key value = return
	cmp #RETURN
	bne loop_2
	;	increment memory address pointer
	inc mem_ptr
	bne loop_90
	inc mem_ptr+1
	bra loop_90
	; endif
loop_2:
	; if key value = go
	cmp #RUN
	bne loop_3
	;	execute the program
	jmp $200
	; endif
loop_3:
	; else shuffle key value into (mem_ptr)
	pha
	lda (mem_ptr)
	asl a
	asl a
	asl a
	asl a
	sta (mem_ptr)
	pla 
	ora (mem_ptr)
	sta (mem_ptr)	

loop_90:
	; wait for key to be released
	; this will cause display glitch, but...
	lda keys
	bmi loop_90
	; put mem_ptr and (mem_ptr) into leds
	; [x][x][x][x][x][x][ ][ ]
	; (also provides a short delay for the LED multiplex)
	ldx #0
	lda mem_ptr+1
	jsr to_leds
	lda mem_ptr
	jsr to_leds
	lda (mem_ptr)
	jsr to_leds

	; update the display count; we have eight leds but we only drive six
	; to save code space (we don't need to clear them)
	iny
	cpy #6
	bne loop
	ldy #0
	bra loop
	
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
Debouncing in hardware has, I think, some challenges. The 47k pullup resistors will slowly discharge a capacitor to ground on each line when the key is released, but the driving inverter will charge them, um, enthusiastically.

Neil

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

Posted: Fri Jun 06, 2025 8:18 am
by barnacle
BruceRMcF wrote:
Oh, is the LED display and key access two different steps? I had thought that the display code is latched, and then when reading the key value that generates the /selector for the LED display. That certainly leads to less code.
To make an LED light up, the bit pattern is first latched, then the LED number 0-7, left to right, is written. That value is also latched and for the first four LEDs provides the active high column for the keypad. Reading the keypad is a single read which gets the column number as bits 0-1, and the encoded row number as bits 2-5.

So the keypad has to be read for every LED write, since the data is only available for that particular column.

Code: Select all

loop:         
   ; for each character...
   lda leds,y
   sta led_addr,y   ; display bit pattern
loop_01:
   lda keys
   bpl loop_90      ; no key pressed...
Neil

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

Posted: Fri Jun 06, 2025 8:21 am
by BruceRMcF
Well, that last from me surely blows out the code budget by a second double side DIODE board, so need to simplify those semantics to bring them under control.

The first simplification is to eliminate "8765:g" behavior, since the bootstrap premise means there is nowhere to jump to except what has already been put in, so one action marks and another action executes. This means one existing action has to go, which will be "+".

Code: Select all

DODOT:  LDA V
        STA W
        LDA V+1
        STA W+1
        BRA NEXTKEY
GOTO:   JMP (W)
Second, eliminate the semantics of seeing what is there, since there shouldn't be anything there that wasn't put there. That simplifies RUBOUT, which is only for setting the address, and since showing data is not longer a <CR> function, the data can be left whatever it was ... the user can resuse the current value for data if they can remember what it is:

Code: Select all

RUBOUT: STZ OUTLEN
        BRA NEXTKEY
        ...
There is no "+" function, you can either auto-increment on return or rubout the address and type in a new one, which in turn simplifies <CR>:

Code: Select all

DORET:  LDA #4
        STA OUTLEN
        LDA DATA
        STA (V)
        INC V
        BNE +
        INC V+1
+       BRA NEXTKEY
More ripping out the original overambitious guts to try to work toward 128 bytes anon. Spaghetti code deferred until/unless there is just a few bytes to squeeze out.

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

Posted: Fri Jun 06, 2025 8:34 am
by BruceRMcF
barnacle wrote:
BruceRMcF wrote:
Oh, is the LED display and key access two different steps? I had thought that the display code is latched, and then when reading the key value that generates the /selector for the LED display. That certainly leads to less code.
To make an LED light up, the bit pattern is first latched, then the LED number 0-7, left to right, is written. That value is also latched and for the first four LEDs provides the active high column for the keypad. Reading the keypad is a single read which gets the column number as bits 0-1, and the encoded row number as bits 2-5.
Aha, I was puzzling over how driving the segments for only the final clock cycle of the keypad read would be keeping them well lit. That's well worth an extra 2*-3 bytes.

{* Is the I/O in zp or in main RAM?}
Quote:

Code: Select all

loop:         
   ; for each character...
   lda leds,y
   sta led_addr,y   ; display bit pattern
loop_01:
   lda keys
   bpl loop_90      ; no key pressed...
Neil
Note with 6 LED's, /Y1..6 can be used, and the "keys" select could be /Y0, so, in effect, LED_ADDR = KEYS+1. With a 70 pin 6 digit clock-face LED, the second pair of ":" LEDs could just be wired on.

Code: Select all

HEXOUT: LDX #0
        LDA V+1
        JSR PUTLED
        LDA V
        JSR PUTLED
        LDA DATA
        JSR PUTLED
...
SHINE:  LDX #6
SHINELP:
        LDA LOB,X
        STA LED,X
        LDA RDKEY
        BPL NOKEY
        STA KEY
NOKEY:  DEX
        BPL SHINELP

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

Posted: Fri Jun 06, 2025 9:27 am
by barnacle
IO is in main ram, $b000 or thereabouts.

My entry method is strictly sequential, has no option for setting the start address, which is always $0200, but if I got things right, existing code can be displayed just using 'return'

Neil

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

Posted: Fri Jun 06, 2025 9:36 am
by barnacle
Moving the IO to zero page would save three bytes; mapping the DROM to (say) the top half of zero page would save two bytes.

Probably not worth the extra gates :mrgreen:

Neil
All times are UTC
Page 1 of 13

Powered by phpBB® Forum Software © phpBB Limited