6502.org

Hello all,

I'm hoping to finally spend a bit more time working on my 6502 system this weekend and over the beginning of next week (my last chance before November), but my current system is basically at the point of free-run, and my ability to program a ROM is somewhat embryonic at the moment, so I was figuring to proceed as follows:

1. Work out and hand-assemble a small program that will switch between different chunks of ROM address space at a "slow" rate, maybe four transitions per second or thereabouts, easy to pick out if I slap an LED plus resistor on a couple of address lines... And also do RMW operations (maybe a simple INC?) on a few RAM locations. Burn this to ROM using my embryonic programmer setup.

2. Wire up just the ROM chip with the program installed to the CPU. No RAM, no I/O. Monitor the chosen address lines to make sure that the program is "working".

3. Attach a RAM chip to the system.

4. Try to fire up my logic analyzer (an HP 1630D, bought used for $60, supposedly working, but I haven't even plugged it in yet), and see if I can use it to show that the RAM is working in the system.

Now, on the whole this seems to me to be a reasonable plan, but... I know that leaving unused inputs on 74xx CMOS chips "floating" can cause problems, and doing an RMW operation against unpopulated (not decoded) address space means that the CPU will be spending a cycle or two reading from a floating bus. Is this a safe thing to do at this stage? Am I running any real chance at destroying hardware (this seems somehow unlikely), causing the CPU to behave erratically (thus giving me a false negative on running the program with no RAM), or otherwise screwing things up?

Thanks in advance for any advice.

CMOS inputs (and outputs that are turned off) theoretically and ideally have no leakage, and the unavoidable capacitance on the bus will hold the last driven state much longer than you might think. When I was writing the program for the tester for my 4Mx8 5V 10ns SRAM module and testing it at intermediate points, I found that the last driven state would remain for at least a millisecond (ie, a million nanoseconds). I did not take time to find out how long I could draw it out, whether 100ms or what. So in your case, even if there's no RAM plugged in, the last state from ROM would remain on the data bus for quite a while. (I don't know about four transitions per second though! If you have the logic analyzer, you can go at least at many kHz, right?)

If you don't have RAM though, you don't even have a stack for subroutine returns or any ZP operations; so I'm not sure what you plan to do. If you have checked the connections with a DMM, I think it would be safe to go ahead and power the system up with the RAM in it; but as always, watch the current and be ready to shut it down in a second if it looks out of line.

Don't worry. The problem with floating inputs in CMOS is that you can get more current consumption, but that only happens when you keep the voltage in the intermediate level. And the current usually isn't excessive as long as you don't put multiple pins in that state for prolonged periods of time. As Garth says, when the voltage is well defined, and you let it float, it's going to stay at that level for a while.

In any case, when tinkering with electronics, I recommend getting a power supply with adjustable current limit, so you can set the maximum current at a safe level. If you can't afford one, pick a supply with a low current, like an old phone charger or wall wart rather than an old PC PSU.

Having an LED blink was my second step toward a complete system. It worked out of the box without any problems. The pictures shows the blinking LED.
I also calculated the number of cycles and the time that each outer loop should take. I could then proof that my calculation was correct, measuring the time with my oscilloscope.
Exactly the calculated 461ms (460547 cycles at 1MHz) showing up for the high- or low period of the two loops.

I had no unconnected addresslines, because A15 to A13 are connected to an 3-to-8 decoder and A0 to A12 are connected to the address lines of the ROM. all data lines were also completely connected between CPU and ROM. /OE on the ROM was connected to the highest output of the 74hc138 causing my 8k ROM appear at $e000. R/W on the ROM was pulled HIGH to make sure that only a READ is performed.

Writing Code for a RAMles system is a bit annoying, because you have to write code without using stack or memory, so you have to write multiple blocks of the same code instead of jumping to subroutine with JSR.

Here's my code for bliniking an LED:
There is also an article about that: "http://www.ichbinzustaendig.de/2013/09/ ... ritte.html", but you may need to translate it, because it's in german.

Mario.

Be aware that a logic analyzer works in binary, and can only be trusted if you know that the signals really are well defined. For instance, if you have two devices on the bus both talking at the same time, you may get some intermediate voltage. On the logic analyzer, you'll just get ones and zeroes.

Similar things can happen if you have loose connections, or shorts. On the logic analyzer it may look fine, even though the signal is bad. I always call them "lossy analyzers" because so much information is lost.

For debugging low level problems, an oscilloscope is often a better diagnostic tool.

osci_1.jpg

First known photo of The Ghost in the Machine

My thought was four transitions per second on A14 and A13, with the phi2 clock running at 3.579545 MHz, meaning a lot of code spent in a dead loop. But the point about the logic analyzer raised a possibility too convenient to ignore (which I will comment on below).
Okay, so floating for a single cycle at a time won't be a problem. I know that it's been done to good effect on NMOS 6502 systems (such as the Apple ][) to monitor things like DMA processes stealing the bus for a cycle every so often, or the video data stream on a timeshared bus, but wasn't sure how safe it was especially when dealing with CMOS parts.
My current power supply is two AA batteries in a holder with a 5v converter affixed to the underside. That might allow drawing enough current to do damage, but nowhere near what an old ATX supply can put out.
This is something that I should have already known just from background knowledge, but hadn't put together yet. Thank you for the warning.

Based in part on everybody's input thus far, I decided to revise my plan:

I set up my oscilloscope and my free-run board and made sure that the free-run was still working.

I next set up my logic analyzer, hooking it up to phi2, and the address bus, and got that working. This means that I know that my test equipment functions, and that I have some idea as to how to use it... And obviates the LED test for validating that reading from ROM works. Too convenient a possibility to ignore, as I mentioned above.

Next, I added a line from the logic analyzer to the RESB pin on the 'c02, and worked out how to get a trace starting from the cycle before RESB goes back high. I can see the reset sequence run, from finishing executing the previous instruction, to saving the state on the stack, to loading the RESET vector, to starting execution at $EAEA (because I have the data bus configured as a NOP generator).

I seem to have just enough probe connectors / grabbers to cover the address and data busses, plus a clock line, plus maybe three other signals (phi2, RESB, and R/~W, probably). I expect that it would be more cost-effective to buy another of the same type of analyzer (maybe the G model this time) from eBay than to source the probe connectors individually. Given a logic analyzer and a ROM programmer, I can't imagine needing a single-step circuit in my design.

I still need to work out my small test program, but now it can be as simple as INC $00 / INC A / PHA / PHA / INC $01 / PLA / JMP back to the beginning. That would show that the ROM works. It would show that the RAM at least partly works once there's RAM in the system, is trivial to hand-assemble, and so on.

Thank you, all, for your help and input.

For those of us without a logic analyzer, the first steps of a free run (without ROM) will work with an Arduino. Based on Coronax' example (http://coronax.wordpress.com/2012/11/11 ... n-circles/), I set up a 65c02 with the A15-A08 address lines leading to digital input pins of the Arduino. An output pin provides the clock.
The output is a bit basic -- just the high byte of the address -- but, meine Güte, it's alive!
I'm not sure if the Arduino is fast enough for a 1 MHz clock can, will try to find out in the coming days. The little thing is really cool. Just should have bought the Mega for the extra I/O.

Are you talking about this, or perhaps this? Oh, I see ... never mind!

Mike

I know you want to go cautiously, but the only problems I've ever had with a home-made computer not working on first power-up were when I didn't realize the VIA's RS, R/W\ and CS lines have to be valid and stable before phase 2 rises, and on the ACIA, when I did not have the capacitors at the crystal. I mention these in the 6502 primer, so if you're paying attention there, you can capitalize on my experience and not have to repeat my errors. Outside of that, my 6502 computer designs have always worked on first try, without NOP generators (BTW, I would prefer LDA#$A9 because then it's one cycle per byte instead of two) or logic analyzers or anything fancy. If the power-supply current is reasonable, it's quite unlikely you'll damage anything by jumping in, even if something does not work right.

And this is what it looks like from the other side of the screen:

I can now state that the Arduino method of signal detection works with a 1 MHz system clock (comment out the delay instruction). I'll be rewriting the sketch for more general use when I find the time, though blinking lights are more dramatic, I must admit.

Garth, what can I say, I'm an incremental kind of guy, that's why I have a Civilization problem -- more seriously, I find lots of small successes more fun than a few big ones, and this fits better with the little time I can bring to bear on the project in one sitting. So last night, I added the clock can (after figuring just out in time that the cheap Chinese data sheet had pins 1 and 14 switched, argh) and the first ROM chip, which might just be it for the week the way things are going. Both worked, so this way, I have two happy moments.

Wait, this is turning out to be addictive. Why wasn't I warned?

Too late, you passed the PNR long ago.

So, I didn't get much further. I managed to program a ROM with the short test program that I devised, but then I ran both Vdd and Vss from the ROM to +5v without having realized it, so when I powered it up the oscillator didn't even start. And while tearing the changes back down I found the problem, but by that point I'd already disconnected the logic analyzer (which was a pain to set up in the first place), meaning that even if I did power it up I wouldn't be able to tell if it worked or not without attaching the analyzer... So I gave up for now.

My next opportunity to do anything with actual hardware is at the beginning of November. At this point I'm thinking that I'm going to order a few more bits and pieces (such as a 65816 and appropriate latches, either for this system or the next) and try to construct a wire-wrap system, as I'm clearly at the limits of my patience and complexity tolerance with breadboard construction.

Thank you again, all, for your help and advice.

I had a single step circuit on my machine originally but once I got IO working I found it wasn't needed. Now I make do with sending stuff to the screen or outputting status codes to an 8 bit latch with LEDs on it.

Simon