6502.org

BTW, regarding that mini-monitor, ... I've started looking at that, with a set of lightweight navigation actions, dispatched out of a jump vector, with one level of indirection ... if a vector in the ZP is set to zero, the original jump vector within the mini-monitor is the target for a "JMP (actions,X)", and if it is non-zero, the vector in zero page is used as the target (that is, the JMP (a,X) opcode is stuffed into the location preceding the vector and then is jumped to), so without having to patch the mini-monitor ... and without the mini-monitor having any explicit RAM vector location or process of setting it up ... the jump vector can be copied to any arbitrary location and replacement commands installed in place of the original.

Then having a proper "BRK" routine which stores registers and break return location in a known location in zero page, a command to swap between examining the area the break occurred and the register storage location and a command to perform a BRK return starts to make it more of a practical, if still extremely rudimentary, BRK point monitor.

Deferring the current key handler vector when a BRK occurs and having a built-in command to restore the key handler vector ensures that applications are free to use the command key framework to focus on the actual activity that the application is engaged in, without having to worry about interfering with the working of the mini-monitor.

Actually, that'd be pretty much it ... a set of 12 reasonably orthogonal navigation commands for next, home and previous 16byte row, page, 4K base address, and application program (high water mark for CR entry, $0200 "addr0", and $0000) in the 4-F keys in a 3 high by four across layout, and then F. 0-3 consisting of (in some order) a location toggling command that goes go to the BRK location if in the zero page, and goes to the register storage location if not in the zero page, a return from break command including restoring the pre-BRK keyboard handler, a jump to the currently displayed address and a jump subroutine to the currently displayed address.

It might fit inside the $FFxx page, including hex segment table, and if it does, I'd reckon it on target for a second stage rudimentary BRK mini-monitor before the stage of a full fledged background interrupt LED display driver and keyboard reader up and and key running in support of anything more full-fledged.

Also, after some tinkering, it turns out that editing and displaying a "data" byte stored in the zero page, and then deferring the storage of the data byte until CR is executed become the more parsimonious approach, once there are actions such as pasting the value displayed in the data byte into the high and low byte of the address.

Recall that the next stage monitor doesn't _need_ to use anything from the original Paleo monitor (except maybe the table of hex LED shapes, and that doesn't need to be in the same place). I expect that the first programming would be a short routine at $200 to copy the contents of DROM to EEPROM, which would require timeout programming since the EEPROM isn't readable if the DROM is enabled, though it can be written.

Given that there's a timer available in the 6522, I'd also expect an interrupt driven LED update routine, making it immune from disturbance when keys are pressed. And a further thought might be an improved keyboard debounce (i.e. any keyboard debounce ).

Neil

Yeah, that is more challenge than need ... perhaps someone would like to have a rudimentary mini-monitor that can be punched in faster than a more full fledged 0.75KB-1KB monitor, in which case "how quick can it be punched in" would be the selling point (and surely a case study in excellence of user interface would not be a selling point!) ... but a hope for user base is not the main inspiration.
Yes, that's as I had gathered ... a short routine to copy the contents of DROM to EEPROM, then power down the board, then pull the DROM jumper, then power it up and see if the digital memory punch routine comes up on /RESET.
This is not my lane, so I'll just nod.
I'm wondering whether keyboard debounce is the "hole in the bucket" problem ... if it needs to be boostrapped into a software debounce, then it isn't really the boot-strap it aims to be, and it seems like most hex values entered would be the sixteen doubled nibbles, $00, $11, ... $FF .... and CR could well see the memptr move 5-10 addresses per carriage return.

It seems like a LS19-P, with a 20ms delay after the noise on the line settles down, would fix it for any switches you could get a reasonably decent software debounce working for, but while getting hands on one is not impossible, it's not as easy as it once was. And I surely don't see where to put a 14pin DIP on the input side of U13. Nor do I see where to put in a DIP to even put the 4 LED side row lines through two gates of a 74HCS240, never mind the 4 caps, diodes, and pairs of resisters (supposing that the debounce is on the "4" side of the 4x5).

If there is a software debounce in the board's "future", post boot-strap, could it be possible to put the debounce circuit on a daughterboard with 4 100ms debounce circuits (pdf) on it plugging into 2x5 pin header (including VCC&GND), to be replaced by jumpers once the software debounce is available?

Come to that, a 2x5 pin header with VCC & GND means that the daughterboard could indeed host an LS19-P if the builder didn't want to build the 2xRresister, Diode, Cap & octal ST inverter circuit.

Indeed, running the DROM routine first without the debouncing and then with the debouncing could well be an instructive experience to hardware neophytes such as myself.

It occurs to me that I don't need a debounce on every switch line; just the ~keypressed bit. Because that's a logical value of all the row inputs to the '148, if a bounce happens on any of those, it will also happen on that output. And that output is the one we're actually looking at... I'll think about that. I have a bit of space available to the right of the '148, and a couple of spare inverters at the other end of the board. Unfortunately I can't change the '04 to a '14 Schmidt trigger, or the oscillator won't oscle

That said, debounce is not straight-forward. In the examples given in the pdf you mention, all are dealing with a switch which has an intermittent open state between being off and on; in the dual input versions, for example, there's a null state where neither input is active. The output of the '148 is either one or the other. Perhaps more pondering is in order.

I could also squeeeeze all the HC chips a little closer and drop another in on the end of the row, but given the number of interconnects I'd rather not.

Neil

I find both debouncing and multistage bootstrapping rather interesting!

No debounce will make the keyboard liable to doublepresses, which will be frustrating. A cheap (small) software debounce will have the effect of making the keypad sluggish. But the cheap and small debounce might be enough for an early stage: a later stage has more code space available and can do something more sophisticated.

Which is to say, perhaps no need for a single solution.

Yes, it needs something; I suspect if I can slow down the scan time and sample at the end of it, there will be a long enough gap between the samples to keep things happy. Not sure yet.

My earlier idea about just using the GS line won't work in basic form; it's not a level, but a pulse when the appropriate column is strobed _and_ a key is pressed. Maybe something as simple as small C on each column line, as suggested earlier? A 1uF cap on each line would have a time constant of around 50ms, depending where the input triggers. Easy to change if that's too much...

Neil

Yeah, I was chewing over that, but the debounce is a delay, so while that fixes the attack bounce, it doesn't fix the release bounce. In the DROM routine, it would work, because the key is not re-parsed, so even a number of false "$00" reads (because the "d7=0 Pressed" state is sustained) would not be a problem.

However, those false $00 reads might be a problem when shifting over to a software debounce, and the single debounce leans on the sustained LED column which glitches the LED, so getting away from a hold loop on the LED column could hit a problem if there are false $00 reads before the debounced Pressed state flips off again.

However, it might be possible to take the problem of release bounce out of the picture.
Sorry ... yes, tac switches are going to be single pole, single throw (SPST), and, to be clear, the first three debounces in that paper are for ideal (but more expensive) single pole, double throw switches, which allow debouncing without delay ... the circuit I was referring to was the 4th circuit for SPST (tac switches) on a 2.2pF cap to do a delay debounce.
In the boot-strap routine, the column strobing halts until the button is detected as released, hence the glitching of the LEDs. Won't it only start being a pulse when a steady LED rotation and a software debounce of the keys is done in an IRQ routine on a VIA timer?

A software debounce can store the value for Y when the key is detected and and compare whether a non-press happens on the same Y value, so the same time there is enough codespace to keep the LED's steady, there's enough codespace to synchronize the key test with the active strobe. The high bit of that can hold "nonpress" state, to be tested with a BIT read.

Though if the hardware debounce below works well enough, that might be a software debounce unecessary, allowing the simple "store if it's a key" approach where the BIOS read key resets to a no-key when the key is read.
That would still need hysteresis, or it would bounce on noise over the 0/1 and 1/0 transitions.

It seems like it can be reduced to two debounce circuits on the same steady keypress signal (external to the priority encoder) by using the priority encoder input enable line, if it is possible to set up a read "window" ... two debounced lines on "keypress" state alone, with either different sized caps or different size charge and discharge resisters, to make a "fast charging" Signal1 and a "slow charging" Signal2: So feed the slow debounce through a NAND ST once as an inverter, and then feed Signal_Fast and /Signal_Slow through the NAND ST again for the EI pulse. Two diodes to separate the two signals, two different size capacitors with the same size discharge resisters so the higher capacity capacitor must charge slower and discharge slower ... six diodes (four to wire or the "key-press closed" from the four column lines), two caps, two resisters and either one inverter and one NAND gate, or else two NAND gates, rather than (to do a full debounce for each of the four column lines) four diodes, four caps, eight resisters and eight ST inverter gates.

I don't know off the top of my head whether there are any spare NAND gates in the board as it stands, but that keeps the extra IC's for hysteresis on the debounce down to one more at most ... though how hard it is to squeeze that one in would be outside of my lane.

[Edit: below, I guess it might be U10 with the spare NAND gates, which could be used to try if a single debounce line approach works before worrying about trying a decode window approach.]

[Or, cheating, a SM single ST NAND gate and single ST driver, built onto the board from the maker would do it for the hysteresis on the debounces.]

There are currently two unused two-input NAND gates and two unused standard inverters not allocated on the board.

However, a CR debounce is simple, if basic, and easily added to the board with little layout change. You're quite right about the hysteresis issue, but I'm a firm believer in simple solutions; I think I'll try it and see how it works. With a full-sized BIOS then one could implement a more formal software debounce (e.g. only recognise a character or release when it remains constant for a number of cycles) and the CR option would not interfere with that.

I think 47ms is too long; using parts I have to hand, 100nF/47k is ~5ms; 1u/10k ~10ms. So there is scope to play[1].

I've added a hint on the back silk-screen: does this make sense to people? Neil
p.s. on a system where it is critical that switch signals are guaranteed, mechanisms exist to detect whether the switch is actually present, or whether connecting wires are open or short circuit. For example, forget digital signals and use resistors in the right places such that the four states are distinguishable through an analogue input: switch open, switch closed, circuit open, circuit short circuit. But that's two enthusiastic for a basic 6502 trainer!

Yeah, that depends heavily on the switch ... some switches have a shorter but noisier bounce period, for example, making the length of the delay less critical but having hysteresis on the line more critical.

Anyway, if you have two free NAND gates, there are almost certainly two NAND gates that do not have to have the shortest ACH gate delay and can be a CH Schmitt Trigger NAND without any issues, so the "read window" approach would just need the simple charging cap + discharge resister delay.

If the simple debounce works "most of the time", that makes "step back one" a lot more important. I think there's room in the tightened up DROM code to have GO, CR, and step back one (on "-"). I think going down to three functions and using the "self-executing BRK vector" trick leaves just enough space.

And, after all, "step back one" can be used as "review", you are just reviewing in reverse.

I would add that in my experience, the bounce period gets longer as the switch gets older and wears out.  I've had situations where my original de-bound routines were plenty adequate, but needed revision when the buttons gold older.  (I think I just chose to replace the switches instead.)

Well, one would hope that by the time the switches are older, the DROM will no longer be in use

Neil

I'll note that for "decent" denouncing, a 5ms to 10ms window might work, with hysteresis ... if a bounce occurs but the fast rising cap stays in the high zone, it just stretches the window until the slow rising cap is read as high.

But, yeah, is even if it seems to be working ok at the outset, wear on the switch contact coul make it bounce worse.

Still chewing on the single keypress line debounce. I've never written a software debounce, but the "false 0" on release bounce seems like it can be rejected in software by writing it to reject rollover.

So in unpress state, you see a key. Store it in a transient location. At the start of the next tick, check if it's still there. If it is go into pressed state, if not, stay on n that line for one more tick, and if it's not there, reject it as noise and let the LED cycle continue normally. In "wait", count ticks without press to maybe 16 (two full LED cycles) and one then accept a keypress as new and start over again. So spurious zeroes after a key has been recognized and before it is counted as fully released are ignored.

So, yeah, charge up a cap when the EO is high due to any key detected, put it through one spare NAND that can work as a ST, then it's high for unpress, low for press. The DROM code will release the key after it has been fully released, and false zeroes prior to that don't affect DROM key parsing. So as long as the software debounce isn't tricked by false zeroes when the /Press bit is still being pushed low by the inverted cap/resister circuit, it seems like it might work.

If switches get worn, it may become necessary to desolder the existing cap and solder in a bigger one, and the build instructions can include different capacity capacitors for different desired debounce periods.

Ah, but if that is their EEPROM programmer, they want an EEPROM that needs different contents while keeping by their existing one, and back to the DROM they go after they've used the previous one long enough to want a different bios setup... so their keyboard has been getting some use (the LED snake game, etc.)

Actually, if that is U10, with two NAND gates used in encoding bits 0 & 1 of the keycode ... there's a perfect candidate to be swapped for a NAND Schmitt Trigger to have a Schmitt Trigger inverter available to clean up noise in the rise of the cap when being driven by the EO of the priority encoder ... after all, the row starts to be driven multiple clock cycles before the key driver is read.

I've put the outer limit at a page and a half, for which there is plenty of space for an auxilliary segment table has G H i J L N n o P S u Y ° = - _.

Break does not distinguish BRK and IRQ ... the target is squarely for a more rudimentary system than a proper background cycling LED setup on a VIA clock tick interrupt, able to patch the smallest of routines into the function key system to play around with the hardware, including an extremely rudimentary breakpoint function.

So far it's the three commands of the DROM routine -- go, CR and step-back (one byte), plus the "+" key as a function command, which dispatches one of up to 16 functions from a vector table, based on the most recently entered nybble.

CR and step-back remember the original data byte, used by the three actions to restore the prior data byte because the byte that is displayed is used for something other than memory data: ADDHI, to put the showing data byte into the high address byte, ADDLO to do the same to the low data byte, and the "+" command itself, which uses the most recent nybble as the command index.

Executing a BRK fills in a set of addresses at the bottom of the zero page with register contents & the BRK return address, and points the memptr at the BRK return address, setting the BRK command mode flag, return from brk resets the BRK command mode flag, refills the registers and executes the return.

There are commands to point the memptr to the base of the zero page, the top of stack, the default routine execution address, the base of the current page, and to bump the memptr up and down a page.

Goto jumps to the currently display memptr and Gosub does a subroutine call to the currently displayed memptr.

There is a set of four cycling navigation functions which bump up to the next even 16-byte, 64-byte, 4KB and 16KB boundary (to quickly step over the I/O space to the ROM space), with the first two wrapping around inside the page and the second two wrapping around the memory space.

That's 15 commands, and so 16 is the one to copy the 32 byte function vector at the currently showing memptr to make it easy to replace which ever BRK monitor function is desired for setting up routines to perform desired functions with a minimum of code punching in required.

So far it comes in at around 100 bytes past a page ... just over 80 past a page without the auxilliary segment table.