FWIW, some judicious surgery will make a Molex easier to disconnect. Just cut away a bit of the plastic.

The connector on the PSU end has four concave structures which are engaged by four convex structures on the drive end. You can sabotage one end or the other, or both. Shave the convex structure to reduce its height (you don't need to eliminate it completely). And the concave structure can be widened to reduce the lip at the edge (marked with the arrows). A file is the safest tool to use for this job.

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

I read that they were supposed to latch if there was a 5W load on the 5V line. But if they don't latch at all I can just go ahead and get some Bergs. I have an old motherboard that doesn't work, so I can pull the ATX power connector off that.

EDIT: I didn't see that post properly... That's what I get for a 10PM post, I suppose. Anyway, knowing that, I can just appropriate the molex connector. I don't know why I didn't think of that; thanks for pointing it out.

Regarding cc65, I have a conumdrum.
I've gotten it to produce an EEPROM image(using the toolchain as intended is far easier than trying to belt it into submission), but it does not produce code that works. This code looks like it should work, even in the disassembly. I have code assembled using another tool that does work on the same hardware, and that is far more complex than what I am trying to get cc65 to produce.
It appeared to be messing up around the first subroutine call initially, so I probed around that area, and it turns out that it was ending up with a return address of zero, somehow. The stack pointer was in the right place, too. That explains why it went comatose. (I've got a write-up of a small battery of tests I conducted that I can produce if it's helpful).

I am now trying to explain why the stack appears to be getting fouled, and this is giving me something of a problem. I have used this code to test it:This should have resulted in $AA55 being displayed on LEDs that I have connected to the VIAs output ports(I have them arranged the other way around). Free-running it resulted in $0000 being displayed. Single-cycling revealed that the 65c02 was writing and reading the RAM correctly, but it was writing $0000 to the VIA. I'd reverse-volted the whole thing recently, and it was suggested that there could be subtler damage.
I suspected that A might have been broken, but that doesn't hold water, because the immediate loads work out completely fine, and when I run a program that does the same thing, but without clobbering the stack first, it works. I also tried the EEPROM version using Y instead of A, but it had the same result. I did not single-step that version, because it took quite a while to do the first one.

I've been using seperate EEPROMs for cc65 and the existing firmware, so I don't have to keep re-writing it. I don't have duplicates of any of the other silicon, though.

Does anyone have any ideas as to what could be causing this, and as to ways I could test things(the program, hardware, and/or toolchain) to see what's going wrong. Because I don't know what's going on with the stack there, or where the problem really lies.

Little unclear here.

Are you using the assembler in cc65, or C is cc65? (Which, of course, uses the assembler).

You said you have code that works on this hardware using another toolset. Have you assembled this listing on that toolchain and had it work? Or does this not work at all? Have you hand assembled this and "poked" the values in and see if it works, skipping (most of) the toolchain entirely?

Just not clear to me what part of the process is breaking down here.

Yep! I've been guilty of Molex connector abuse like that. I found my flush cutters are sharp enough to cut away the locking tabs. However, the switch to the Berg-style connector makes things easier, not to mention more compact.

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

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

If an interrupt came along then the stack would be used by that. If you make a bit of room on the stack first, say with
PHA
PHA
does the program then work OK?

Whartung: You are right. I have been unclear. That snippet is in the crt0.s file that gets assembled by ca65 and then put into the .lib file. It gets pulled out of there by the ld65 when it generates the final binary. crt0.s contains the very first code that is run, under the _init label.
I do have a C program in the mix(it's supposed to spew 'X' out on the serial port), but execution never reaches it. My question is aimed towards figuring out what is preventing this.
I can also probably punch that through SB-Assembler. That will probably work. If I'm clever about it, I can also diff it.

Garth: That's probably a good idea. I can go through the list file and the binary.

BigEd: This is initialization code, and the first instruction is a CLI. That said, it can't hurt to try it.

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

> Free-running it resulted in $0000 being displayed. Single-cycling revealed that the 65c02 was writing and reading the RAM correctly, but it was writing $0000 to the VIA.

Hmm, maybe you don't have a stack problem, but a RAM problem. Is it possible the timing is different for RAM access in the free-running case compared to the single-cycle case? Are any RAM accesses successful?

Maybe you could single-cycle some writes and then free-run the readbacks, or vice versa?

I don't see any inconsistency between the free-run and single-step results. Both result in $0000 on the display. The single-stepping just helps to isolate the problem.

Is there any change in behaviour if you switch to zero-page instead of the top of the stack page for your temporary variable? Or to $02xx addresses?

Garth: Enabling interrupts? Well, that needs to go. Thank you for pointing that out, that could cause me grief later, if it isn't the issue now.
It's perfectly fine not to read the whole thing again; it is 12 pages.
I might have been aware of it, but I'd forgotten if I was. I'll remove those instructions.
I'm writing to the PCR to light up CB2(I have an LED on that as well). That particular write has other effects, but none of them should be a concern. It's there as a not-dead indicator.

BigEd: When I went through and single-cycled it, I observed it writing to ram and reading it back correctly. The writes to the VIA were zeroes, but not the reads from the RAM, so I think the RAM is fine. I've also run it in my TL866 in ram-test mode, and it reported all was well.
My single-cycler is one of those ones that I control the clock, rather than a single-stepper, which runs one instruction and then stops. I cannot switch between single-cycle and freerun without removing the single-cycler.

Chromatix: That's a good idea(not saying anyone else's were bad). I will try that when I get the time.

Hmm, if the 6502 writes a zero, there's a chance it read a zero. So, although you saw non-zero data coming from the RAM, maybe there's some way the 6502 saw a zero? The details of how you do the chip selects and output enables might be important here: cycle-by-cycle is a good way to think of how things work, but sometimes you have to think nanosecond-by-nanosecond.

Or indeed, maybe the 6502 did read a non-zero value, but the glue logic dealing with the VIA isn't as it should be, so it sees a zero at the crucial time.

That's not impossible. I don't have the tools to see what happens on a nanosecond-by-nanosecond basis, but I can build a timing diagram, though, and see if I've messed up in theory.

I run most of the address bus(and nothing else besides power) into a 16v8, which generates the chip-selects. I do remember that I had to use a feedback path for something, because I ran into product term limitations. Probably the RAM, because the IO overlaps that.

What most likely matters here is whether the RAM holds its output longer than the CPU's minimum "hold time". The address bus should automatically remain stable during this time, so you should focus on the path from the clock edge to the RAM enables.