A simple 6502 computer (doesn't work though)

[jgroth]

GARTHWILSON wrote:

One step to try might be to pare it down further, if you're comfortable with that. You have a lot there that's not necessary. For example, the data sheet says, "The reset input clears all internal registers to logic 0 (except T1 and T2 latches and counters and the shift register). This places all peripheral interface lines in the input state, disables the timers, shift register, etc. and disables interrupt from the chip." So the only setup you need it to make port B (PB) all outputs, by writing FF to DDRB. Then decrementing PB, regardless of where it started from, will cycle all the bits, bit 7 being slowest, cycling about every 2/3 second at 1MHz, 1/3 second @ 2MHz, etc., plenty easy to see with a flashing LED.

With the risk of sounding like Jane Austin, Mr Wilson you are the man. With your code the logic probe goes from high to low to high to low... So the NAND-computer works just fine now, nothing wrong with the decoding circuit, RAM, ROM or VIA. Clock and reset work as expected.
So why didn't the NAND-computer work when I had a table to initialise the VIA? I suspect that I either read the table the wrong way around or the data is wrong. But why have the table at all? The code Garth just posted works just fine. I think I'll remove the table to make the code more basic and less error prone.

[GARTHWILSON]

Good news!

[Dr Jefyll]

jgroth wrote:

So why didn't the NAND-computer work when I had a table to initialise the VIA?

It sounds as if you've encountered a peculiarity of the 65C02 (the CMOS version of the 6502). The CMOS chip fixes some bugs that the NMOS version had, but there's still at least one wrinkle you need to look out for. Indexed stores such as the one you used...

Code: Select all

      sta via1base,x

... will sometimes have a spurious read of the intended address before writing to it. If the indexing causes a page crossing the spurious read is absent. It's when there's not any page crossing that the spurious read occurs.

This post spills the beans. (The thread starts here if you're interested the entire dialog of another person's experience with this.)

-- Jeff
Edit: to be clear, the NMOS and CMOS chips both have wrinkles, and, depending on the details of your system, you may find the NMOS chips works but the CMOS doesn't. (Unlike the CMOS chip, with NMOS the spurious read is NOT from the intended address; instead it touches $100 below. And, the boo-boo applies when there is a page crossing.)

[floobydust]

Hmmm, I remember that thread quite well... nice that it can become useful for someone else

[LIV2]

I understand how spurious reads can cause a problem with devices like the SCC28L92 which has an indexed register that increments on read, but why would it cause problems writing to the 65C22?

[Dr Jefyll]

LIV2 wrote:

I understand how spurious reads can cause a problem with devices like the SCC28L92 which has an indexed register that increments on read, but why would it cause problems writing to the 65C22?

Hmmm. It's a good question, LIV2. (And I admit my suggestion about the 'C02 bug was fairly hasty. Until now I've only been skimming this thread.)

jgroth, are you willing to indulge our curiosity? We have a mystery on our hands! It certainly seems strange that your original code *did* work properly on the other machine -- the "reference" computer. Will you tell us, please, does it, too, use a CMOS cpu (65C02), or does it use an NMOS cpu? Would it be feasible to swap in a CMOS cpu to see what happens? ( And/or, could you swap an NMOS cpu into the new computer?)

I can think of other issues that might be at play, but firstly I'd want to confirm or rule out this business about the 'C02 and its spurious read-before-write when using STA Absolute Indexed mode.

cheers
Jeff

[APL]

LIV2 wrote:

but why would [spurious reads] cause problems writing to the 65C22?

Here's a stab in the dark.

In the 65c22 a read or write to certain registers clears the interrupt flag for that register. A scenario where you're checking for the flag condition but it's been inadvertently cleared will give you a frustrating time.

[Dr Jefyll]

APL wrote:

In the 65c22 a read or write to certain registers clears the interrupt flag for that register. A scenario where you're checking for the flag condition but it's been inadvertently cleared will give you a frustrating time.

Quite true. (And it's not uncommon for I/O chips to have read-sensitive registers.) But I'm still puzzled. As I understand it, the code in question executes the questionable operations (indexed STA's) almost immediately after reset -- a time when I would expect all the 6522 flag registers to already be clear anyway. (Furthermore, we still have the question of why the code *did* work properly with the 6522 on the other machine.)

[jgroth]

Dr Jefyll wrote:

LIV2 wrote:

I understand how spurious reads can cause a problem with devices like the SCC28L92 which has an indexed register that increments on read, but why would it cause problems writing to the 65C22?

Hmmm. It's a good question, LIV2. (And I admit my suggestion about the 'C02 bug was fairly hasty. Until now I've only been skimming this thread.)

I can run both programs again and double check that the via base address is correct (both in the code and on the EEPROM) for both boards.

Dr Jefyll wrote:

jgroth, are you willing to indulge our curiosity? We have a mystery on our hands! It certainly seems strange that your original code *did* work properly on the other machine -- the "reference" computer. Will you tell us, please, does it, too, use a CMOS cpu (65C02), or does it use an NMOS cpu? Would it be feasible to swap in a CMOS cpu to see what happens? ( And/or, could you swap an NMOS cpu into the new computer?)

Yep it is certainly a mystery. I only got access to CMOS cpus from WDC I'm afraid so that is what both boards are using.

[Dr Jefyll]

jgroth wrote:

I only got access to CMOS cpus from WDC I'm afraid so that is what both boards are using.

No worries! -- that's still useful information. One board works and the other doesn't, despite the fact they both have CMOS cpu's. That's a strong indication that (as LIV2 suggested) the C02's version of the spurious read-before-write is not the cause of the difficulty with the table-driven VIA init routine.

I'm going to take a stab in the dark (to borrow APL's phrase ) and suggest a slight wiring change. As an experiment, are you willing to try this, jgroth? Given that it's a breadboard, this should be pretty easy to do (and later easy to undo, if you like).

As shown in the diagram below, delete your original connection to /OE (pin 22) on the EEPROM. Instead, make a connection between EEPROM pin 22 and /Q (pin 6) of the 'HC74. All the other connections, on the EEPROM and elsewhere, remain as is.

If you're up for this, please give it a try (using the table-driven VIA init routine, of course). I'll explain my hunch later. The change may or may not have any effect on the problem, but it won't do any harm.

cheers
Jeff

[jgroth]

Dr Jefyll wrote:

jgroth wrote:

I only got access to CMOS cpus from WDC I'm afraid so that is what both boards are using.

No worries! -- that's still useful information. One board works and the other doesn't, despite the fact they both have CMOS cpu's. That's a strong indication that (as LIV2 suggested) the C02's version of the spurious read-before-write is not the cause of the difficulty with the table-driven VIA init routine.

I'm going to take a stab in the dark (to borrow APL's phrase ) and suggest a slight wiring change. As an experiment, are you willing to try this, jgroth? Given that it's a breadboard, this should be pretty easy to do (and later easy to undo, if you like).

As shown in the diagram below, delete your original connection to /OE (pin 22) on the EEPROM. Instead, make a connection between EEPROM pin 22 and /Q (pin 6) of the 'HC74. All the other connections, on the EEPROM and elsewhere, remain as is.

If you're up for this, please give it a try (using the table-driven VIA init routine, of course). I'll explain my hunch later. The change may or may not have any effect on the problem, but it won't do any harm.

cheers
Jeff

So /OE will go low a bit before /CS goes low as /Q will be shifted 180 degrees compared to the clock. Timing problems perhaps. I will definitely try that this evening (UK time).

/Johan

[Dr Jefyll]

Well, 6500 (and 6800) series processors use the Phi2-low time to prepare for a data transfer and the Phi2-high time to actually perform the transfer. Preparing for the transfer entails the propagation of a new address onto the address bus... and it also entails a potential change of "ownership" of the data bus. During write cycles the data bus is driven by the CPU, and during read cycles any of several other devices (RAM, ROM, I/O) may take their turn.

Getting the devices to start and stop driving the bus is a somewhat inexact science. One of the reasons is, the devices don't instantly respond to changes on their /CE and /OE inputs -- and, the delay can only be predicted approximately (the margin of error could easily be 10 or 20 ns -- or more). This implies a threat of short-lasting bus collisions (bus contention). For example, in a handover from Device A to Device B, there's a risk Device B may begin driving the bus before Device A has stopped -- and for 10 or 20 ns the computer's Gnd and Vcc network gets blasted with a large current spike.

It's not unusual to see designs which ignore this issue (the collision is brief, and arguably may be considered tolerable). But the solution is simple. Just arrange your glue logic so no device drives the data bus during the Phi2-low time. This guarantees a big, fat 500 ns timing "cushion" -- enough to soak up any variability and ensure that every bus handover is courteous and gentle.

( I can't specifically explain how a large current spike might produce the symptom we're seeing here, and that's why my concern is only a hunch. But clearly we have a computer that's acting "funny" -- it seemingly executes some code correctly, and other code not. And "funny" behavior is often the result of noise issues such as those caused -- especially on breadboards -- by current spikes. )

I'll be interested to learn the result of the experiment!

-- Jeff

[John West]

I'd work on the software to start with, before speculating about hardware problems. You have two very similar programs, one working and one not. But there are still quite a few differences between them. Take the working one, and make small incremental changes to turn it into the not-working one. At some point it will stop working, and the last thing you changed will be a big clue to what's going on.

Other things to check: are you absolutely certain that the address and data lines go where you think they do? Check them again. Swapping two address lines on the ROM can easily make a small program work and a big program fail. Put an RTI on IRQ. At the moment any interrupt will reset. I can't see anything in there that would cause an interrupt, but you never know.

[Dr Jefyll]

John West wrote:

I'd work on the software to start with, before speculating about hardware problems. You have two very similar programs, one working and one not.

As mentioned upthread, the "not working" program does work when a different computer is used. Perhaps you overlooked this.

Quote:

Other things to check: are you absolutely certain that the address and data lines go where you think they do? Check them again. Swapping two address lines on the ROM can easily make a small program work and a big program fail.

Yes, an excellent point. That too could explain what we're seeing.

[John West]

Dr Jefyll wrote:

John West wrote:

I'd work on the software to start with, before speculating about hardware problems. You have two very similar programs, one working and one not.

As mentioned upthread, the "not working" program does work when a different computer is used. Perhaps you overlooked this.

No, I didn't overlook that. I'm just using "working" and "not working" as names to identify the two programs.

It's the board that it doesn't work on that needs trouble-shooting. That fact that it works on a different board rules out a problem with the program itself, so whatever is causing it to fail is a problem with this board. Or rather, an interaction between this program and this board. That's an excellent start. If you can narrow the differences further, then you've got somewhere specific to look, rather than hunting a problem that could be anywhere.

It might be easier to start with the not-working program and gradually NOP out the bits that don't exist in the working one. If it's still not working, start deleting the NOPs.