wdc65C51's seem to have a different 'reset value' on the tx/rx data register as well. while all others nicely seem to report 00 in their $00 offset register wdc ones report 1F after initialisation but before they did anything. (but then again wdc ones are broken and clearly the txre register and parity generator isn't the only thing broken, so let's just forget about those until they are fixed

any suggestions for 'rohs compliant' solder that can be used in a solderbath, isn't lead, and is cheaper than gold (AuSn 40/60 should work about as well as pbsn but seems slightly more expensive than the entire unit's already quite overrated price lololol. funny how that whole rohs 'directive' crap is about 'disposable crap'. we how about making things that simply never break in the first place, also saves 'recycling'. lol. or shall we just say 'european customers can come to us and buy them from us on the spot' so they are neither 'importers' nor 'goods entering the market' as after all, they have no intention to sell them, ever lol.

not that i mind switching to gold but i guess the ECB would quite quickly start to complain about the entire worlds gold reserves being stuck in electronics lolol. definataly not switching to something -inferior- to pbsn in terms of mechanical and temperature aspects, if that means we cannot sell it through eu front operations, then screw eu front operations and 'their' market. simple as that our products are designed to -last-. we're not ****ing apple. (maybe we should just solder them with actual 100% gold. that'd make some headlines and piss off the eu

You might find that technical questions get better responses if you don't wrap them in political commentary. (Which is another way of saying: please stay on topic. Respect the time that your audience invests in reading your posts - try to be clear, to stay on point, to address yourself to knowledgeable peers and fellow hobbyists. Try to make it entirely irrelevant whether they might share any other interests, or values, or opinions. The end result is better for everyone.)

I just kept using a big reel of lead-based solder I bought before the millennium - until it went missing along with everything else. I was never going to throw away my work, so it was never likely to become an environmental hazard. Besides, I already had the reel - what should I do with it, throw it away whole?

I hope I can get another one.

@Chromatix: PbSn solder is still available in various diameters - no need to bunker

@cb3rob: "soldering" with gold won't last 'forever' - ask a chemists for the details; a flash of gold is fine for keeping pcbs solderable for years - that's all.

@BigEd: Mange tak!

I'll second that. Most of us have our political opinions and interests. However, they are seldom germane to the discussions that arise here.

Along with minimizing the political stuff, proper capitalization, punctuation, spelling and grammar in posts can do wonders for readability. Readability will attract more interest to your projects and as Ed pointed out, garner more responses to the technical aspects of your posts.

In that vein, you should also consider that 6502.org members have widely varying technical backgrounds and are from all parts of the world. Not all members are native speakers of English (although I daresay it's hard to tell in many cases). Hence it's helpful to non-native speakers if you write using good English so they can clearly understand what it is you are trying to say.


Leaded solders continue to be readily available from electronics suppliers. In my shop, I have 40/60, 60/40 and 63/37 in several sizes (diameters). Sources such as Digi-Key, Jameco and Mouser stock them.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

cb3rob, we all really are trying to help... but please try making this less difficult for us.

am i having some gigantic brain**** here or is bounce on the nmi line overflowing it's own return address or something
whenever i assert nmi it seems to be jumping/returning to random stuff. (and yes all the other stuff is there to make sure it never jumps into some irq/nmi routine before it has finished post.
anything 'shipped with the system' that should do irq will be handled by the system -before- checking for the eventual user program stuff

the flags register doesn't need to be preserved before all the conditional branches as it is my understanding that a monitor (should the user handler be a monitor) will always pull the last one of the stack and push it back rather than use the current one. after all the one you want to display in the status register line is the one from -before- the nmi or brk occured

and yes all of the conditional branches do seem to be needed after all the user could pull nmi during the initialisation shortly after powerup without the memory and i/o having been initialized yet, an irq or nmi could occur -while- the user code is writing his vector to 0202 or 0204 (that's what the extra byte with the 2 flags is for as well as bit 7 that should always be 0 so the whole situation of the 3 bytes containing that stuff 'randomly' during a powerup before memtest initializes the ram (our emulator nicely has zeroes all over the place upon power up but irl that looks different, as it's a cpu emulator and not a 'transistor level' emulator it does however not have an irq or nmi 'line' we can pull and/or cause bounce on and the periphials are initialzed are rather unlikely to happen) also it prevents it from executing -any- irq/nmi if the memory test failed for all the obvious reasons)

;--- USER IRQ HANDLER
; - REQUIRES MEMTEST TO HAVE PASSED
; - POINTER IN USER NMI HANDLER VECTOR $0202 (LSB) AND $0203 (MSB) NOT ZERO AND NOT IN ROM (>=$8000)
; - BIT 1 OF $0206 TO BE SET TO 1
; - BIT 7 of $0206 SHOULD ALWAYS BE 0
.IRQHANDLER
PHA ; WE'LL BE USING THE A-REGISTER HERE
LDA $0200 ; RAMTEST LSB DONE SHOULD BE $00 ?
BNE ~IRQNMIHANDLERDONE
LDA $0201 ; RAMTEST MSB DONE SHOULD BE $80 ?
CMP #$80
BNE ~IRQNMIHANDLERDONE
LDA $0206 ; USER NMI/IRQ ENABLE MASK BYTE
BMI ~IRQNMIHANDLERDONE ; BIT 7 SHOULD ALWAYS BE 0
AND #$01 ; CUSTOM IRQ HANDLER SET?
BEQ ~IRQNMIHANDLERDONE
LDA $0202 ; CUSTOM IRQ HANDLER LSB SHOULD NOT BE ZERO
BEQ ~IRQNMIHANDLERDONE
LDA $0203 ; CUSTOM IRQ HANDLER MSB SHOULD NOT BE ZERO
BEQ ~IRQNMIHANDLERDONE
BMI ~IRQNMIHANDLERDONE ; ALSO SHOULD NOT BE IN ROM (MSB >= $80)
PLA ; RESTORE A-REGISTER - FLAGS REGISTER DOESN'T MATTER AS NONE OF THIS IMPACTS BREAK/IRQ FLAGS
JMP ($0202) ; JUMP TO ADDRESS IN USER IRQ VECTOR

;--- USER NMI HANDLER
; - REQUIRES MEMTEST TO HAVE PASSED
; - POINTER IN USER NMI HANDLER VECTOR $0202 (LSB) AND $0203 (MSB) NOT ZERO AND NOT IN ROM (>=$8000)
; - BIT 2 OF $0206 TO BE SET TO 1
; - BIT 7 of $0206 SHOULD ALWAYS BE 0
.NMIHANDLER
PHA ; WE'LL BE USING THE A-REGISTER HERE
LDA $0200 ; RAMTEST LSB DONE SHOULD BE $00 ?
BNE ~IRQNMIHANDLERDONE
LDA $0201 ; RAMTEST MSB DONE SHOULD BE $80 ?
CMP #$80
BNE ~IRQNMIHANDLERDONE
LDA $0206 ; USER NMI/IRQ ENABLE MASK BYTE
BMI ~IRQNMIHANDLERDONE ; BIT 7 SHOULD ALWAYS BE 0
AND #$02 ; CUSTOM NMI HANDLER SET?
BEQ ~IRQNMIHANDLERDONE
LDA $0204 ; CUSTOM NMI HANDLER LSB SHOULD NOT BE ZERO
BEQ ~IRQNMIHANDLERDONE
LDA $0205 ; CUSTOM NMI HANDLER MSB SHOULD NOT BE ZERO
BEQ ~IRQNMIHANDLERDONE
BMI ~IRQNMIHANDLERDONE ; ALSO SHOULD NOT BE IN ROM (MSB >= $80)
PLA ; RESTORE A-REGISTER - FLAGS REGISTER DOESN'T MATTER AS NONE OF THIS IMPACTS BREAK/IRQ FLAGS
JMP ($0204) ; JUMP TO ADDRESS IN USER NMI VECTOR

;--- RETURN FUNCTION FOR USER NMI AND IRQ HANDLERS THAT DIDN'T MEET THE REQUIREMENTS
.IRQNMIHANDLERDONE
PLA ; RESTORE A-REGISTER - FLAGS REGISTER DOESN'T MATTER AS NONE OF THIS IMPACTS BREAK/IRQ FLAGS
RTI

SIZ $7FFA
;--- CPU VECTORS
.VECTORNMI
DWO !NMIHANDLER
.VECTORRST
DWO !COLDSTART
.VECTORIRQ
DWO !IRQHANDLER

Your "IRQNMIHANDLERDONE" doesn't do anything but exit; so you have all these many conditions which just exit without taking care of the interrupt. So what happens then is an IC (for example a 6522 VIA) pulls the IRQ\ line down, the ISR is entered and exited, but the IC that pulled the IRQ\ line down still has not been serviced, and it's still pulling that line down. So you exit the ISR, and guess what. You go right back in again and do it all again, again without taking care of the interrupt. The ISR needs to do something in the status of the IC that caused the interrupt. In some cases, merely reading the IC's status register will make the IC release its interrupt output. The data sheet will give the needed info.

If there are the various conditions under which you don't want interrupts, you can just do SEI (SEt Interrupt-disable flag) to make the processor ignore the IRQ\ line. If something is connected on NMI\, your software can tell those ICs not to interrupt until further notice. Note: The processor reset sequence automatically includes setting the interrupt-disable flag; so it won't be accepting IRQs until you tell it to with the CLI (CLear Interrupt-disable flag) instruction. The RST\ will also reset the I/O ICs so they won't produce interrupts until your software sets them up to.

You have in the comments, "FLAGS REGISTER DOESN'T MATTER AS NONE OF THIS IMPACTS BREAK/IRQ FLAGS" which is true, but it's missing an important point. The background program running, which gets interrupted at non-predetermined times, depends very much on various flags being kept intact. They must be preserved; but your LDAs, CMPs, and ANDs will alter them. However, the interrupt sequence automatically includes pushing the P (processor status) register, and the RTI pulls it again; so status is already taken care of.

A lesser "by-the-way" point is that there is no break flag in the processor. The B bit is just a bit position indicating a BRK in the status record that gets pushed onto the stack during the interrupt sequence. The ISR cannot test it in the status register itself by doing PHP, PLA, AND #00010000B, BEQ/BNE, because the B bit does not physically exist in the processor-status register P. Trying this will always make it appear to be set. From inside the ISR, you might do PLA PHA (to take the status byte record that was stacked during the interrupt sequence, and copy it into the accumulator), followed by AND #00010000B and BEQ/BNE. So again—the test would have to be preceded by PLA, PHA, not PHP, PLA. The latter will not work, since it will always show bit 4 set.

See my 6502 interrupts primer for more. Yeah, I'm the interrupts junkie around here.

_________________
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?

this is the code for the board itself, with all of the irq generating by the onboard periphials turned off (as i already noticed that leaving it on caused the thing not to even get to the point where it would do anything

so what remains is 1 routine that calls a user 'nmi vector' and 1 routine that calls a user 'irq/brk' vector.

as for the pla/pha back to get the status register in A (the one from -before- which should indicate wether it's a brk or an irq that caused it) i think i already picked up on that.

now the thing is, that the NMI one, when asserting NMI manually through the jumper, seems to bounce that many times that it actually returns to 'some random address' <-- that's the issue here. how the hell can it cause that much bounce that it overflows a 256 byte stack (or something else is wrong with the code itself

yes. the PLA PHA thing is what i expect monitors to do (as most user-inserted nmi routines probably would be a monitor program, the same goes for user inserted BRK handlers, whcih most likely will want to print the STATUS: line above each prompt with the status it had -before- the brk (so the one that is pushed on the stack).

when the user inserts a routine either for nmi or for irq/brk he has to 1: load the address of it at 202-203/204-205
2: AFTER ! doing that (as that involves loading -2- bytes there could be an irq in between byte 1 and byte 2 calling the wrong address) he must set it's flag at 206 to 1 and make sure bit 7 o 206 remains 0. also the system must have passed it's memory test (otherwise the user can't run his program anyway but the system should be done doing that anyway, as by that time also all chips have been initialized to the proper settings and all). that's what all the additional 'bail out' conditions are for going to the PLA; RTI; (the user code must have it's own RTI at the end but before calling user code the A is restored to what it was)

anyway, every time i try to make it do some nmi (with or without some user code) the bounce by itself seems to overload the stack to a point that the instruction pointer ends up somewhere random. is that normal? or something wrong with the code somewhere. (as in do it multiple times and it either restarts from scratch or ends up in various places in the built in 'semi-monitor' or ipl code or memory test or suddenly reinitializes all chips , so it's pretty random (or it just hangs can't see what's going on inside the -real- cpu, can only see that on the emulated system, but there i cannot pull irq or nmi as it has no irq or nmi and if it had, being an emulator, it would not bounce.

and yes basically what it does is run through a whole list of excuses -not- to execute the user routine pointed to by the vector in 202/204, if it finds any of those reasons not to, it RTI's (memory broken or not present? don't execute any irqs, didn't fully boot up yet? don't handle any irqs, user didn't completely enter the vectors yet and confirmed that by setting the appropriate flag? don't handle any irqs (user programs should set the vector and the 'ok' flag -first- and -then- enable the actual chips to do irqs, else, indeed, endless irq loop)

(actual system stuff such as handling the first via (which will be reserved for controlling the system itself, provide timers for the system itself, be hardwired to some parts of the system, and that sorta stuff) or the console will go in system/rom routines placed -before that- everything else (the other 3 acias and 2 vias, as well as probably an 8 bit isa slot on the final version) is left free to the user's program

but anyway every time i short nmi to ground the whole thing seems to crash on me. i would not expect it to bounce that much that it would do so enough times to crash the system and cause random behaviour every single time. will it execute an nmi while another nmi is still in progress? is nmi better left completely ignored and only pulled up?

maybe an extra ds1813 on nmi will solve it after all it does provide a 150ms 'debounce' for 'reset pushbutton'. and holds 'reset' low for 150ms. hmm guess it would do the same thing for nmi. during brown out and powerup that would however pull both reset and nmi as they also do -that-. causing a bit of a random gamble between teh thing resetting or it first executing the user nmi routine if the plug is pulled.

they do sell some nifty toys for nintendo nes systems that plug between (their version of) the 6502 and the board and allow to single step the thing from a computer on a real board. hmm. maybe build an adapter for those (different pinouts) and see what the hell is going on.

normally a non-debounced key or shorting some jumper (such as in this case) would result in the same key showing up 2 or 3 times, not 256/4=64 times (php, ip (2 bytes), a register pushed by routine)) which is what it would take to overflow the stack to the point that the RTI starts to return to random places. it's a bit hypersensitive, i guess, or i made some gigantic screwup in the code i could not find so far