First thought on an interface (to use Paleolithic DROM)
Re: First thought on an interface (to use Paleolithic DROM)
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.
Re: First thought on an interface (to use Paleolithic DROM)
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
Neil
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
Neil
Re: First thought on an interface (to use Paleolithic DROM)
(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.)
Re: First thought on an interface (to use Paleolithic DROM)
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. ...
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.
Re: First thought on an interface (to use Paleolithic DROM)
And meanwhile, there does not seem to be a 62256 RAM available in DIP any more, apart from informal auction sites...
Neil
Neil
- GARTHWILSON
- Forum Moderator
- Posts: 8773
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Re: First thought on an interface (to use Paleolithic DROM)
barnacle wrote:
And meanwhile, there does not seem to be a 62256 RAM available in DIP any more, apart from informal auction sites.
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?
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Re: First thought on an interface (to use Paleolithic DROM)
barnacle wrote:
And meanwhile, there does not seem to be a 62256 RAM available in DIP any more, apart from informal auction sites...
Neil
Neil
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.
Re: First thought on an interface (to use Paleolithic DROM)
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.
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. 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
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€
- 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€
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. 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
Re: First thought on an interface (to use Paleolithic DROM)
I've got the "rush to play with hardware" micro-monitor / micro-kernel with the keyboard functions set up like this:
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
; 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" 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 Re: First thought on an interface (to use Paleolithic DROM)
Bruce, where are you? UK, Europe? When I get the boards I may be able to send you a couple 
Neil
Neil
Re: First thought on an interface (to use Paleolithic DROM)
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:
So there are two entry points that fall into "nextboundary":
... and two entry points past nextboundary that branch back to it:
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.
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 Code: Select all
next_4K: ; +31
ldx #1
bra nr1
next_row:
ldx #0
nr1: lda #$F0
; fall through Code: Select all
next_qtr:
ldx #0
nq1: lda #$C0
bra nextboundary
next_16K:
ldx #1
bra nq1 - 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)
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!
Re: First thought on an interface (to use Paleolithic DROM)
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
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
Re: First thought on an interface (to use Paleolithic DROM)
So here's a version with some a few more changes, though I think we're about there now:
Neil
- 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.
Neil
Re: First thought on an interface (to use Paleolithic DROM)
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:
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:
With gives the space to have the "- backspaces until page boundary, + backspaces at page boundary" command keys.
So now there's an Alpha V8.
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)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)So now there's an Alpha V8.
- Attachments
-
- MESOLITHIC_DROM_alpha_v8.asm
- (3.59 KiB) Downloaded 11 times