First thought on an interface (to use Paleolithic DROM)

For discussing the 65xx hardware itself or electronics projects.
User avatar
BigEd
Posts: 11463
Joined: 11 Dec 2008
Location: England
Contact:

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

Post by BigEd »

I would think you can get away with a lot less than 50Hz, but it's true that if you go too low it will be a bit disturbing.
barnacle
Posts: 1831
Joined: 19 Jan 2004
Location: Potsdam, DE
Contact:

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

Post by barnacle »

Although the fact that we have to stop and wait until the key is released before we can progress to the next column is going to cause a certain amount of disturbance anyway :)

Back of the envelope calculation regarding segment current:
- max current through the '541 is 80mA; choose 56 for some headroom and convenience; ignore the DP.
- that's 8mA per segment; limit on most of those 0.56" displays is ~20mA.
- with eight LEDs, that's 1mA average per segment, so should be ok for brightness.
- Red LED drops ~2v, so 3v across the resistor. R = V/I = 3/0.008 = 375 ohms; call it 330 or 390 as nearest E12 values.
- Green LED drops a few tenths more, but is brighter on the eye, so perhaps choose green LED?
- Power dissipation in the resistor = IV = 0.008 * 3 = 24mW, so OK with standard 0603 1/16thW.

I'd guessed initially 220 ohms (because I had some) then 1000 ohms (because I had some of those too) but it looks like 330 would be a better choice.

BUT this has an implication on the power supply; I was going to drive this through an FTDI serial-TTL cable, but there's a current limit there of about 75mA. I think a secondary power connection might be a good idea...

Resistor and capacitor prices are crazy; they're dominated by the manual handling. From LCSC, FRC0603J331 TS from Fojan:
- 100 (minimum order) is 8 cents
- 1000 is 70 cents
- 5000 is 3 dollars

Which is why I tend to buy at least a thousand of any passive :mrgreen:

Neil
User avatar
BigEd
Posts: 11463
Joined: 11 Dec 2008
Location: England
Contact:

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

Post by BigEd »

(Just to double check my opinion about refresh rates, I checked the patent on TI's DataMath II calculator - turns out to refresh at 200Hz. I'd be interested to check the same of the KIM-1, but can't find the info.)
BruceRMcF
Posts: 388
Joined: 21 Aug 2019

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

Post by BruceRMcF »

barnacle wrote:
I'd suspect you'd want a faster refresh rate than that; you'd want to see each LED refreshed fifty or sixty times a second minimum, so around four hundred ticks a second from an IRQ. ...
Gotcha. OK, then keeping it powers of two, ~512 ticks per second is roughly 2ms/tick, on a 16:1 press/unpress ratio and 5ms steady state to the cap in complete key press state, then the read key coming first in the IRQ sequence before bumping the LED column would get it read on the second full tick after it is pressed, delayed by one or two if a bounce hits right in the middle of the read key strobe.

And of course skip the key read part if current LED is 5-8.

The second full key read in would be 9-16 ticks after first substantial attack, so ~18ms-32ms. A long enough bounce in the third full key read to cross the hysteresis starts to be multiple standard deviations out in the stochastic process, but one might say key / unpressed / same key should not count as a release, since the two key reads would be 32ms apart, and these are tac switches, so UIAM, an actual double press isn't going to complete so fast.

Once released, if it's 80ms for the cap to be in full release state, and hysteresis delays the rise of the NoPress signal on data7 until around 45ms-50ms into the release, two consecutive release reads on the previously detected column or a release read, the previous key, and another release seems like it ought to get pretty good bounce rejection, which is also key / unpressed / same key doesn't count as a release.

So there'd be four states ... multiple releases have been read, the last read was an initial key read, the last read was a release following a key read, and the last read was a repeated key that follows a single release.

Four states is nice because the state can be stored in bits 7 and 6 and read with BIT. It can be stored in a single byte with the "previous key" by having the "no key pressed" value as bit5:
bit0-bit5: bottom six bits of last key registered if key pressed
bit0-bi5: %xx100000 if last key registered is unpressed
bit6-bit7: debounce state 0-3.

With cap + hysteresis debounce on all rows, it might be OK to treat it as a low noise environment and a key with d7 in Press state that different from the most recent key read is treated as a new key, so goes straight into first read of a key following release state.

~~~~~~~~~~
{Side points:

1. Do you have a preference for the break point monitor to use as a reference for the proper kernel? The IRQ routine will disentangle BRK's from IRQ's so it will want some code to jump to if it is actually a BRK. It can still be a minimalist one, as it can be written to use a vector in the system space in the zp instead if the vector is non-zero.

2. Also, caps and suspenders, a routine to write the DROM code into the EEPROM as the first test is not strictly limited to 128 bytes anymore, so it could be written to write a proper decrement address routine just below $FF80 and patch the DROM routine for the backspace function to the proper decrement address routine ... with the symbol table moved to the top of the DROM, between the to_leds subroutine and the symbol table taking over 32 bytes, small patches in the $FF60-$FF7F range are guaranteed to be able to reach the loop_90 code with a branch.}
Last edited by BruceRMcF on Mon Jun 23, 2025 5:01 pm, edited 2 times in total.
barnacle
Posts: 1831
Joined: 19 Jan 2004
Location: Potsdam, DE
Contact:

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

Post by barnacle »

And meanwhile, there does not seem to be a 62256 RAM available in DIP any more, apart from informal auction sites...

Neil
User avatar
GARTHWILSON
Forum Moderator
Posts: 8773
Joined: 30 Aug 2002
Location: Southern California
Contact:

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

Post by GARTHWILSON »

barnacle wrote:
And meanwhile, there does not seem to be a 62256 RAM available in DIP any more, apart from informal auction sites.
I went to Jameco's site first, and got two results in stock, 70ns and 150ns:
https://www.jameco.com/shop/KeywordSear ... Text=62256

Mouser has these two in stock, both 55ns:
https://www.mouser.com/c/semiconductors ... &instock=y

Digi-Key has these two in stock, both 55ns:
https://www.digikey.com/en/products/fil ... EpVYsGlV1A
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
BruceRMcF
Posts: 388
Joined: 21 Aug 2019

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

Post by BruceRMcF »

barnacle wrote:
And meanwhile, there does not seem to be a 62256 RAM available in DIP any more, apart from informal auction sites...

Neil
Which side of the pond are you? Digikey seems to have Alliance 32KB SRAM AS6C62256 DIP in stock. The datasheets for Cyrus and Alliance give different address values to different pins, but other than that seem the same pinout.

Edit: Ooh, Garth beat me to it, while I was fixing a typo, and much more thoroughly to boot, but yes, the 55ns 0C-70C Industrial temperature range Alliance "PCN" is the version where Digikey has 1,000+ in stock.
barnacle
Posts: 1831
Joined: 19 Jan 2004
Location: Potsdam, DE
Contact:

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

Post by barnacle »

Yeah, I found not two but _three_ on mouser.de - as mouser is the only supplier for w6502 and friends, it seemed sensible to get everything at the same shop, if only to save postage. (I wonder if WDC would like to wholesale LCSC?)

The Mouser website was playing hide and seek with me, perhaps, it's done it before. Here's the current list of DIP28 32k ram, all in stock in various quantities.
  • 913-AS7C256C-15PCN @ 7.08€
  • 913-AS6C62256-55PCN @ 4.28€
  • 913-AS6C62256-55PIN @ 5.55€
But in an excess of enthusiasm, I have squeezed a SOIC-28 footprint inside the DIP space, so there are other possibilities (checked only for size and 5v working). Again, in stock as of today.
  • 870-IS65C256AL25ULA3 @ 3.34€
  • 870-IS62C256AL-45ULI @ 1.15€
  • 870-IS62C256AL45ULITR @ 1.12€
  • 913-AS6C6225655SCNTR @ 3.18€
  • 913-CY62256NLL55SNXI @ 2.98€
  • 913-C62256NLL55SNXIT @ 2.44€
  • 870-62C256AL-25ULI @ 1.40€
  • 870-62C256AL-25ULIT @ 1.40€
  • 870-IS62LV256AL45ULI @ 1.15€
  • 913-AS6C62256-55SCN @ 2.75€
Which is an encouraging list of fast 5v parts - 25ns to 55ns - and the ISSI parts are refreshingly inexpensive!

Also there are a bunch of SOJ parts which _look_ as if they should be mountable on an SOIC footprint, with a steady hand and a fine-tip soldering iron.
6502_minimal.png
Messy, but will work. It's easier to centre the two footprints, but there were too many traces going across to manage that, so it's a bit busy on the other side.

Neil
BruceRMcF
Posts: 388
Joined: 21 Aug 2019

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

Post by BruceRMcF »

I've got the "rush to play with hardware" micro-monitor / micro-kernel with the keyboard functions set up like this:

Code: Select all

;	C			D			E			F
;	putcommands
;				showreg	showstk	showapp							
;
;	8			9			A			B
;	nextrow	nextqtr	next_4K	next_16K			
;
;	4			5			6			7
;	brkrtn	prevpg		homepg	nextpg
;
;	1			2			3			+
;	gosub	ad_hi		ad_hi	function
;
;	GO			0			CR			-
;	exec		goto		  CR		bspace

FCOMMAND:		; +16
	dw goto		; "0+", "exec memptr"
	dw gosub	; "1+", "gosub at memptr & return"
	dw ad_hi	; "2+", "put byte in hi address"
	dw ad_lo	; "3+", "put byte in lo address"
	dw brkrtn	; "4+", "return from BRK"
	dw prevpg	; "5+", "decrement addr high byte"
	dw homepg	; "6+", "zero addr low byte"
	dw nextpg	; "7+"	"increment addr high byte"
	dw nextrow	; "8+", "next 16byte boundary"
	dw nextqtr	; "9+", "next 64byte boundary"
			; * nextrow & nextqutr wrap on page
	dw next_4K	; "A+", "next 4KB boundary"
	dw next_16K	; "B+", "next 16KB boundary"
	dw putcommands	; "C+", "install commands at memptr"
	dw showreg	; "D+", "show reg storage"
			; * nextrow & nextqtr leverages this into
			;  general inspection of the zero page
	dw showstk	; "E+", "show top of stack"
			; * nextrow & nextqtr leverages this into
			;  general inspection of the stack page
	dw showapp	; "F+", "show addr0" 
The key subroutine for the function dispatch, "ad_hi" and "ad_lo" is restoring the previous value of the data byte being shown, so the current data byte can be used as general data entry for setting an address or specifying one of 16 functions to call:

Code: Select all

; When entered byte is function data
; restore original byte
; Used by FN, ADLO & ADHI
getbyte:	; +8
	lda (memptr)
	tax
	lda data
	sta (memptr)
	rts 
barnacle
Posts: 1831
Joined: 19 Jan 2004
Location: Potsdam, DE
Contact:

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

Post by barnacle »

Bruce, where are you? UK, Europe? When I get the boards I may be able to send you a couple :mrgreen:

Neil
BruceRMcF
Posts: 388
Joined: 21 Aug 2019

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

Post by BruceRMcF »

I'm in Knoxville, Tennessee (though teaching Economics in South Carolina during the school year), but I'd put a hold on any boards, I'll be playing around with an SPI circuit on bread boards this coming fall.

When I am in South Carolina is when I can play around with hardware, so summer is coding time ... and at the same time, I am on the University laptop, so cannot install software until I get back to my mini PC in Sumter.

For the micro-monitor, I'm not trying to squeeze things down across the board, but am still taking space shortcuts. The biggest space shortcut is the "horses for courses" decision that BRK does not try to distinguish between BRK and IRQ, but is rather assuming if someone wants to work with one or more IRQ sources going, they also probably ought to be working with more than a binary page and a half of code as their underlying kernel in EEPROM.

So some of the functions are there as required for the micro-break-monitor function, like being able to set any address directly, storing the register values on BRK and having a function to set memptr to that location, a function to set memptr to the top of stack, a function to set the memptr to the base of the main routine, and functions to execute or call to the current memptr location. And, of course, a backspace key does not wrap at the page boundary!

But others are more to fill out the set of 16 functions without using up too much space per function, such as the four "boundary" functions which net out to about 8bytes per function. Their core action is:

Code: Select all

nextboundary:
	; index into memptr:memptr+1 in x
	; bit mask in a, %11000000 or %11110000
	; inverse of bitmask +1 is increment
	sta dispatch 	; dispatch is transient
	eor #$ff
	sec
	adc memptr,x
	and dispatch
	sta memptr,x
	bra loop_90 
So there are two entry points that fall into "nextboundary":

Code: Select all

next_4K:		; +31
	ldx #1
	bra nr1

next_row:
	ldx #0
nr1:	lda #$F0
	; fall through 
... and two entry points past nextboundary that branch back to it:

Code: Select all

next_qtr:
	ldx #0
nq1:	lda #$C0
	bra nextboundary

next_16K:
	ldx #1
	bra nq1 
Part of their anticipated role is to take up the space in the BRK mode command vector, while being clear candidates for over-writing for application specific functions if borrowing the same key parsing mechanism for an application that has been punched in.
User avatar
BigDumbDinosaur
Posts: 9425
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

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

Post by BigDumbDinosaur »

barnacle wrote:
Also there are a bunch of SOJ parts which _look_ as if they should be mountable on an SOIC footprint, with a steady hand and a fine-tip soldering iron.

Since you are hand-soldering these thingies, maybe you can put them on the other side of the PCB.

BTW, before I lost central vision in my left eye, I had no trouble soldering SOJ parts to SOJ footprints using my trusty 40W Weller iron and a small chisel tip.  50-mil pin spacing is relatively easy—the finer pitches, not so much.  Some liquid flux applied to the pads before placing the part will help to keep it from wandering as you solder the first pins.  The extra flux will also help in getting the solder to flow under the pins.  Have some desoldering wick handy to clean up any bridges, and some isopropanol to deflux.

Here’s a good U-Toobe video on manually soldering SMT parts.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
barnacle
Posts: 1831
Joined: 19 Jan 2004
Location: Potsdam, DE
Contact:

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

Post by barnacle »

Yeah, I have no difficulties soldering 1.27mm soic; 0.65mm QFP gets a bit tricky, and 0.5mm and smaller really require lots of flux, flood with a hot air gun, and solder wick afterwards. SOJ is not a package I'm particularly fond of, though I can solder it without issue. It just feels, um, clumsy, somehow.

SOIC eeproms are cheaper and more plentiful than DIP packages too (though there are loads of 'new' (but actually used board pulls) on the Bay from China in DIP); I think I might have a rethink about the layout of the ram and eeprom and make them both SOIC and DIP.

Though for a neophyte, soldering a DIP socket is the easiest and safest option.

Neil
barnacle
Posts: 1831
Joined: 19 Jan 2004
Location: Potsdam, DE
Contact:

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

Post by barnacle »

6502_minimal2.png
So here's a version with some a few more changes, though I think we're about there now:
  • added shared footprints for eeprom and ram
  • added voltage regulator for external DC supply of six volts or so (and a connector that can't go the wrong way!)
  • changed SOD123 footprint to increase size of solder pads - 0.6mm by 0.4mm is a bit titchy
  • changed some R and C footprints to 'handsolder' variants; slightly larger.
Now to make the same changes on the DROM board.

Neil
BruceRMcF
Posts: 388
Joined: 21 Aug 2019

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

Post by BruceRMcF »

While working putting the Micro-Monitor on a diet, I found two bytes to take out of the hex key routine in the DROM code:

Code: Select all

loop_hex:		; +14
	; else shuffle key value into (memptr)
	; In this version, d7=/Press
	; d7 clear if hex key
	pha
	lda (memptr)
	asl a
	asl a
	asl a
	asl a
	sta (memptr)
	pla 
	ora (memptr)
	sta (memptr)
If instead of using the stack, A is put into a temp zero page location, that costs the same space as pha/pla, but shortens the logic combining the two nibbles:

Code: Select all

loop_hex:		; +12
	; else shuffle key value into (memptr)
	; In this version, d7=/Press
	; d7 clear if hex key
	sta temp
	lda (memptr)
	asl a
	asl a
	asl a
	asl a
	ora temp
	sta (memptr)
With gives the space to have the "- backspaces until page boundary, + backspaces at page boundary" command keys.

So now there's an Alpha V8.
Attachments
MESOLITHIC_DROM_alpha_v8.asm
(3.59 KiB) Downloaded 10 times
Post Reply