First thought on an interface (to use Paleolithic DROM)

[BruceRMcF]

barnacle wrote:

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

Neil

For the DROM, in any event, it kind of needs to be living in $XXXX-$FFFF at /Reset time, if the /Reset vector is going to work.

[barnacle]

Yes, I had considered mapping it twice, at $0080 and $ff80, but I don't think it's worth the effort.

Neil

[BruceRMcF]

barnacle wrote:

Yes, I had considered mapping it twice, at $0080 and $ff80, but I don't think it's worth the effort.

Neil

Yeah, unless the two bytes were critical to making it fit, I couldn't see mapping it twice. If it came up just a little bit too long, I'd be more inclined to mapping a second much smaller DPROM with just the 16byte LED segment table into the I/O space, so it's still available if the main DPROM is switched out of the memory map.

I do believe the shifting the data byte digit in will always be smaller than "typing across", but I may keep juggling it to see how close it can get. At the very least it might make a test program to type in at $0200 with the DROM micro-monitor that can be entered in under a page of code.

For instance, it just dawned on me this morning that, given that NMI service is not going to be installed until after the DROM is turned off, there are two "free" hard-coded bytes at the top of they are of use.

It also occurred to me that, if just six display LCDs are selected, in addition to using the bottom one for the KEY read, and do the LCD digit / key row in base+1..6, the top select could be used to toggle the DROM off and the underlying access on, if a quad NAND is used for a /S /R latch and to generate the qualified /DIODE_RD and /MAIN_RD.

I think the loop target here may on a rare occasion cause a dropped key:

Code: Select all

loop_01:
   lda keys
   bpl loop_90      ; no key pressed... 

This goes to the loop that waits until the key is released ... and it goes into the loop with the key not pressed, so should pass through to the following code ... but if the first and second test were to occur just as the key line goes high, it will be treated as an already handled key that is waiting for release.

Actually, for a "Paleolithic" board, I do not mind that the LED's will glitch if you hold the key down ... it gives a side-effect form of hardware key press feedback.

The only opportunity I can see to make the base code directly smaller only saves two bytes, by cycle through the LEDs from right to left rather than left to right:

Code: Select all

...
	ldy #0			; not strictly required... will get there eventually
...
  ; 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:

Code: Select all

	ldy #5			; NB. might actually be required,
                                        ; IF using the other two selects for something else
...
  ; update the display count; we have eight leds but we only drive six
   ; to save code space (we don't need to clear them)
   dey
   bpl loop
   ldy #5
   bra loop
... 

[BruceRMcF]

OK, after a harder look, if the 16byte LED encoding table was not in the DROM, it is possible to get an ability to set an arbitrary address, but it is with the "slide the nybble into the data ram from the left" approach:

• RUN jumps to the current shown address (since the current shown address can be set)
• The data byte shown becomes a general input byte, so what is shown comes from a "data" value in the zero page.
• CR stores the current data into the current address, increments the current address, and fetches its value to data
• A hex value slides the current low nybble of the data byte to the high nybble, and takes the place of the low nybble
• "Hi" stores the current data into the High byte of the current address
• "Lo" stores the current data into the Low byte of the current address

I think this is 99 bytes for the main routine, 24 bytes for to_leds, and 4 bytes for the actual /Reset vector and faux /NMI vector, which would be 127 bytes.

I guess the first byte could be a main version number, from $0x to $Fx, and a minor version number, from $x0 to $xF, with a serial revision number in the faux NMI vector.

Also note that it is cheating egregiously, since with the LED segment table added it is 144 bytes of DROM ... due to taking a jumbo 128 byte DROM and adding a mini 2-section DROM selected somewhere in the I/O addresses.

[barnacle]

BruceRMcF wrote:

Also note that it is cheating egregiously, since with the LED segment table added it is 144 bytes of DROM ... due to taking a jumbo 128 byte DROM and adding a mini 2-section DROM selected somewhere in the I/O addresses.

Son of Drom!

You're right, it does feel like cheating. Although, I was considering, rather than a ROM, using diodes as a wired-or system to drive the LED patterns directly: four bits of hex in, seven bits of LED pattern out. It would mean that you could just write a four-bit value to an LED location and have it appear without translation, but would remove any possibility of other use - i.e. direct control of segments - for the LEDs.

I'm trying to test the code in Symon and it's looking hopeful but I think I need to play with the I/O addresses (temporarily) so it fits Symon's ideas. But as the final 'product' would have writable EEPROM across the top quarter of the memory, I can test it without having to solder five hundred diodes... the intent is that the DROM gets you started, then you put code into the EEPROM, and remove a link to disable the DROM and read EEPROM instead. If it all goes toes up, you start again.

Neil

[BruceRMcF]

barnacle wrote:

BruceRMcF wrote:

Also note that it is cheating egregiously, since with the LED segment table added it is 144 bytes of DROM ... due to taking a jumbo 128 byte DROM and adding a mini 2-section DROM selected somewhere in the I/O addresses.

Son of Drom!

You're right, it does feel like cheating.

Or MegaDROM and MiniDROM (reserving MicroDROM for an 8byte DROM board and MidiDROM for the 32byte one to hold a small 1st stage bootloader like my SPI boot code).

The excuse would be that the table is of general utility for the system that has the 7-segment display.

Quote:

Although, I was considering, rather than a ROM, using diodes as a wired-or system to drive the LED patterns directly: four bits of hex in, seven bits of LED pattern out. It would mean that you could just write a four-bit value to an LED location and have it appear without translation, but would remove any possibility of other use - i.e. direct control of segments - for the LEDs.

As long as the 5th bit is direct control of the decimal point for animating running dot patterns, I'd actually be fine with that. And that would not involve any additional address decoding for the hex to segment translation table, while still skipping having to enter those 16bytes into the program being entered.

Of course, with one or two 74x157 quad 2-input muxes, it might be possible to choose between the hard coded decoding and direct drive, but hard coded with a decimal point on the 5th bit seems more Paleolithic.

Quote:

I'm trying to test the code in Symon and it's looking hopeful but I think I need to play with the I/O addresses (temporarily) so it fits Symon's ideas. But as the final 'product' would have writable EEPROM across the top quarter of the memory, I can test it without having to solder five hundred diodes... the intent is that the DROM gets you started, then you put code into the EEPROM, and remove a link to disable the DROM and read EEPROM instead. If it all goes toes up, you start again.

Neil

For the hypothetical "Neolithic" SPI board, it would be the bootstrap option to enter code to write the 2nd stage bootloader and a bootstrap pseudo-rom into an SPI serial flash or FRAM, with the DROM plugged into the 32byte 1st stage bootloader block header via ribbon cable. I guess rather than sitting on top of the half of the main board on stand-offs, it would be sitting behind, because the block header for the LED/keypad board would be at the front of the main board.

What I like about the modified micromonitor loop is the ability to go back to the beginning of the entered code and toggle through it to check that each byte matches the planned byte. Because sure as anything, the odds I get all bytes entered correctly is going to be well under 50%.

[BruceRMcF]

BruceRMcF wrote:

... As long as the 5th bit is direct control of the decimal point for animating running dot patterns, I'd actually be fine with that. And that would not involve any additional address decoding for the hex to segment translation table, while still skipping having to enter those 16bytes into the program being entered. ...

I also noted that the hardwiring makes the to_led subroutine smaller, because it both skips the translation step and because there is no need to save and restore the Y register.

At 120 bytes, it also avoids having to solder one 8byte diode block.

Code: Select all

VERSION = $00	; alpha, $01 is first beta release
REVISION = $01	; 2025-06-07

   ; 120 bytes, pending bug fixes
   ; * Main: 99 
   ; * to_leds: 17
   ; * Reset Vectors: 4

; NB. For hardwired hex to 6digit, 7seg display
; Character bit5 -> decimal pointer
; so DNC Q7 of translation table

; The translation table is:
;LED_CODE	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
leds = $00
data = $07
W = $08

; Paleolithic
led_addr = $0B08	; guesstimate
keys = $0B00		; guesstimate

; Neolithic		; 6 digit 14pin LED block
; led_addr = $0880	; /Y0-/Y5 decode lines
; key = $0886		; /Y6 decode line

	code
	org $ff80

start:			; +2
   ldy #5  ; Will be required if other 2 selects have different uses.
loop:			; +5
   ; for each character...
   lda leds,y
   sta led_addr,y   ; display bit pattern

loop_01:		; +5
   lda keys
   bpl loop_99      ; no key pressed...
   ; do stuff to sort out the key value

			; +20
   ; if key value = return
   cmp #RETURN
   bne loop_2
   ;   increment memory address pointer
   lda data
   sta (W)
   inc W
   bne +
   inc W+1
+  lda (W)
   sta data
   bra loop_90
   ; endif

loop_2:			; +7
   ; if key value = go
   cmp #RUN
   bne loop_3
   ;   execute the program
   jmp (W)
   ; endif

loop_3:			; +10
   ; if key value = Hi
   cmp #Hi
   bne loop_4
   LDA data
   STA W+1
   bra loop_90
   ; endif

loop_4:			; +10
   ; if key value = Lo
   cmp #Lo
   bne loop_4
   LDA data
   STA W
   bra loop_90
   ; endif
			; +14
   ; else shuffle key value into (W)
   and #$0F
   asl data
   asl data
   asl data
   asl data
   ora data
   sta data  
			; +4
loop_90:
   ; wait for key to be released
   ; this will cause display glitch, but...
   lda keys
   bmi loop_90

loop_99:		; +17
   ; 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 data
   jsr to_leds

			; +5
   ; update the display count; we have eight leds but we only drive six
   ; to save code space (we don't need to clear them)
   dey
   bpl loop
   bra start

to_leds:		; +17
   ; unpack byte into two adjacent LED patterns
   ; x has character position
   pha
   and #$0f         ; low nibble
   sta leds+1,x      ; and output into the LED array
   pla
   lsr a
   lsr a
   lsr a
   lsr a            ; high nibble
   sta leds,x         ; this byte goes on the left
   inx
   inx
   rts      
   
   org $fffc		; +4
   dw start
   db VERSION,REVISION

[barnacle]

Rather annoyingly, there doesn't appear ever to have been a hex->seven segment decoder chip, only bcd-> seven seg...

Neil

[BruceRMcF]

barnacle wrote:

Rather annoyingly, there doesn't appear ever to have been a hex->seven segment decoder chip, only bcd-> seven seg...

Neil

Yes, the coded option on the SPI MAX7221 controller is 0-9, '-', 'E', 'H', 'L', 'P' and <space>, so using SPI to access a 6 segment block of 7seg LED's doesn't avoid the need for the table.

[L0uis.m]

Hi Neil and everyone else,

barnacle wrote:

Rather annoyingly, there doesn't appear ever to have been a hex->seven segment decoder chip, only bcd-> seven seg...

Oh,yes, there WAS
The DM9368N, produced by National and Fairchild, but I'm afraid you need a time machine to go back to the last century if you want to buy some of them.

Here's the data sheet:

DM9368N.PDF

(90.94 KiB) Downloaded 15 times

P.S.: I am in need of a few of them myself to repair an old Eprommer , so if anyone . . .

[barnacle]

Nice find, Louis, but as you say, the time machine is currently broken.

Neil

[L0uis.m]

A normal diode matrix for a hex-seven segment display takes seventy-eight diodes, at the moment I am working on a matrix that only needs thirty-three diodes

With some luck, I might one day be able to publish a design . . .

See my thread, link:viewtopic.php?f=4&t=8388&p=112946#p112946

[GARTHWILSON]

I started making one (a 7-segment hex LED display) to offer on my site a couple of years ago.  I was using a microcontroller.  I don't remember what the interruption was that stopped me before I finished.  I suppose I could get back to it now.

[barnacle]

Don't take the time for my benefit, Garth! (though of course, don't let me stop you )

I think I have a choice of solutions around the DROM limitations, including using either the DROM space as a location for the LED patterns, or a separate LED decoder. For preference, being able to handle each segment of each LED separately is the way I would like to go, rather than being restricted to hex characters only.

Here's the current plan: A single-board computer (100mm by 160mm ideally) with a 20-key pad and an eight digit LED display; 32k ram, 16k EEPROM, a 6850 UART, a 6522 (probably), and a link to enable an external DROM - mounted under the SBC. The DROM, if enabled, allows very basic entry and review of programs. The EEPROM shares _write_ space with the DROM but is not readable, at least in the top half-page, if the DROM is enabled. (Writing to the DROM achieves nothing, of course; writing to the EEPROM in those locations will have to rely on timeouts rather than asking it if it's finished yet.)

Still thinking about the decoding, but likely similar to Grant's minimalist system:

Code: Select all

$0000-$7FFFF    RAM
$8000-$8007    LEDs
$8800          Keyboard
$9000-$900F    6522
$A000-A001    6850 UART
$B000          Alternate keyboard? Might simplify things
$C000-FFFF    EEPROM
$FF80-FFFF    DROM (when enabled)

Neil

[barnacle]

L0uis.m wrote:

An normal diode matrix for a hex-seven segment display takes seventy-eight diodes, at the moment I am working on a matrix that only needs thirty-three diodes

With some luck, I might one day be able to publish a design . . .

You could consider charlieplexing... of course, just seven OR gates will do it, if they have up to sixteen inputs each

Neil