I've gone and put together a computer, and I'm starting to write test programs for the various parts on it.
This VIA test program should count upwards on port A, but it isn't doing so.
This is the code I'm using(hand-assembled):

I have tested that the 'C02 works, by pulling everything else off the board, wiring the data bus to $EA, and then watching A15 using an LED.
I have also tested the connections on the board with a multimeter, and they trigger the continuity beeper, so that's not the problem either.

The way I see it, there's two options: I could have done something wrong with the program(the BNE springs to mind), or the VIA could be a dud.
Have I done anything wrong here?

The branch operands are relative to the first byte of the next instruction; so B__ 00 is a two- or three-cycle NOP depending on the flag you're using as the condition.

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

Oh. Well that'll do it. Thanks!
I can't try it now, but I will when I get home. I'll stick that gotcha on my opcode cheat sheet in the meantime.

Edit: I just realised that I infinite-looped it. I imagine it would have been crazier if I'd branched onto a data byte.

Edit to avoid double-posting:
I implemented that tweak, and did start getting results out of the VIA, but they're somewhat weird.
I changed the program to repeatedly write $FF to the port. Sometimes the lights don't come on, and sometimes they're dim, and often I can affect them(all at once, usually) by twiddling or pressing the wires under the board near the CPU.

It's is looking to me like a construction problem.
This is confusing and frustrating. This seems like a really simple little thing for it to be doing, and it's just not working. Maybe I should give up for now and try getting one of the ACIAs online instead.

It's nice of you to be concerned, but IMO it would not be a breach of etiquette for you to post again, especially since you have new information to report. We don't want that to get overlooked.

That sounds right. If you post some photos then maybe we can help out with some suggestions.

One way or the other it seems perhaps you need to hone your construction skills. Fixing the present problem might actually be a good learning opportunity.

cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I would recommend to get this working first, rather than to repeat your troubles with the ACIA.

I'll second that. Aside from the immense satisfaction you will get from solving the DOA problem, you will gain very valuable troubleshooting experience.

When I built my first POC unit, it didn't work. Instead of setting it aside and doing something else, I got the logic probe out, studied the schematic and tracked down the problem, which was nothing more than a missing connection. Later on, I ran into some hardware bugs that made the unit misbehave under certain conditions. I again studied my design, did some observation with the 'scope and figured it out. Some blue wire here and there, and I had a functioning, stable computer.

You can do the same.

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

I've probably gone and done a bit of a silly thing by not drawing up a circuit diagram. I should probably do one now, given that the design is not likely to change much.

Also, all I have in the way of equipment is a DMM. Unless you count an LED on a breadboard with a flying lead.

Anyway, I've attached some photos. They're only about half the board each, because the camera I'm using goes fuzzy if I try to get the whole thing in frame.

Judging by what happens when I press there(and the fact that it doesn't seem to happen anywhere else), I think that the fault is in the mass of wires pictured in 133_0613. I tried connecting my DMM(in the continuity range) to the legs of the chips in the sockets, and pressing wires and wiggling the board. The beeper stayed solid the whole time. This is the sort of test that I would expect to reveal such a fault, and it seems to deny the existence of said fault. That's why it's frustrating. I did catch one of the VIAs register select lines that had come unstuck, but I've since re-soldered that. I've also tried re-soldering several other wires that had suspect-looking joints(grasping at straws, I suspect).

Thanks for the photos! Looks nice.

With your LED, or your continuity tester, it might be worth walking around all the pins, checking for shorts on any two adjacent pins.

Having checked for shorts, the next step is to test for opens - visiting each bus and control line in turn and checking all the drop-off points are indeed connected.

Thank you! I did try to make it neat, but that's sorta bit me, because it's hard to get at a solder joint in the middle of it.

I think I tested for opens before... In any case, it won't hurt to do it again. But that test for shorts is a good idea. I didn't think of that.
I was using the LED as a logic probe, effectively. It was a more obvious(but maybe not better) indicator than the voltage readout on the DMM.

My cheapo DMM has an audible beeper for the continuity test, which is good as it frees the eyes and hands for the probing work. But an LED in your peripheral vision is probably almost as good. Or you could maybe rig up a buzzer!

My multimeter has a noisy continuity range as well. The LED is to test an already-running circuit for a high level.
I just tested for shorts, as you described, and it passed.
I have started on the circuit diagram, but it's not done yet. I'm holding off on the open test until that's done. And I'll probably not be able to do it this coming week, as I'll be going away, and I plan to leave Ittiara(that's what I'm calling it) at home.

A diagram is very important, and I encourage you to create one. If you're feeling a bit lazy you can omit some of the more obvious details, such as connections for the data bus. You still need to *check* those connections; I'm just saying that in the schematic they don't necessarily need to be drawn in painstaking detail.

The drawing helps us as well as you. We can guess how the data bus is connected because it's so predictable. But almost every other connection needs to be declared. This will help avoid questions such as the following:

What's the white object next to the oscillator -- a potentiometer? What is its function? Also, I don't notice any RC reset circuit for the CPU. Is it merely hidden, or has it been accidentally omitted? And have you tied off unused CPU inputs such as SOB etc? (Garth talks about the "mystery pins" here.)

The natural conclusion is to suppose something is loose, or being caused to bend. However, this behavior could also be caused by an input that's floating rather than being properly driven either high or low. The input impedance of MOS and CMOS chips is *very* high. That means the touch of your finger -- even though it has high resistance -- can conduct enough current to influence a floating input.

A floating input can result from a design error or a construction error. Either way, a wiring diagram will help you find the problem.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I recently fried a raspberry Pi with this kind of wiring. I had an optocoupler to isolate a port pin. One of the other port wires was laying above the input pin of the optocoupler. Underneath the insulation was cut by the sharp edges of the pin and a high voltage (~10V) destroyed all GPIO on the raspberry Pi.

You need to be extra carefull not to cause any shorts by damaging the insulation of these wires either by mechanical force or melting it with a soldering iron.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

I finished the schematic this morning . I'll attach a photo, if I can get it to come out clear enough.
I also did the check for opens, and the board passed it. So nether check yielded anything out of the ordinary. No shorts where there shouldn't be, and no opens where they shouldn't be.

The white thing is indeed a variable resistor. It's for the LCD I plan to connect once the rest is working. There is no RC reset because I'm using a DS1813 for it. It's not in the pictures, but it sits in that 3-pin header between the RAM and the button.

Checking the board, I've tied /SO and BE straight to +5v, pulled RDY and /NMI to +5v with seperate 3.3K resistors, and left PHI2O, PHI1O, /ML, /VP, SYNC and NC unconnected. Would the proximity(not contact) of my finger cause a response, do you think? Because I was trying not to make electrical contact. It would also happen when I pressed on the board from the top, so I don't think that it was interference from my fingers.

I did end up melting the insulation and causing a short at one point. I stuck a bit of cardboard between those wires, because I can't replace them at this point. But I am being more careful now as a result.

Thank you for all your help so far.

Also, a somewhat off-topic question: Does an assembled circuit have more resistance to ESD-induced damage than a loose IC?

Maybe it is time to build yourself some tools to better be able to diagnose your circuit.

A logic probe would be helpfull. You will find many circuit diagrams on the internet and they are cheap to build as they usually have only a few opamps, logic gates, LEDs and resistors. You would need one to detect high, low, high impedance (no driver) and pulsed signals down to 1/4 clock duration. At 1MHz for example you need to be able to detect a 250ns pulse.

Another helpfull tool would be a single step clock circuit. That way you can measure your bus and control lines in a static state. But that is only a second step if you fail to find the bug only with the logic probe.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5