First build 65c816 based machine programming

[backspace119]

So I've got my mega based eeprom writer working, and I'm probably about 25-40% done with my assembler, but in the mean time, I'm going to work on a few small hand written programs to test out my new machine.

I've setup a NOP generator on my ROM that goes as so:

Start Vector: 00 C0 (my eeprom starts at C000 on my machine)

Program (only upper half of EEPROM is used so 4000 is my starting point):

4000:EA (NOP)
4001:4C (JMP #add (absolute))
4002:00 (low byte of JMP)
4003:C0 (high byte of JMP).

First off, does this NOP generator look correct? Secondly, I'm thinking about throwing in a bunch of NOPs, then invert the emulation mode bit, then loop back to the beginning, because I've got an LED on the emulation mode output that should toggle if I do this, verifying some machine functionality. Does all this sound pretty kosher? Any other ideas for verifying functionality before I get into a serial connection?

[BigEd]

(Thanks for the thread discipline!)

First a note on terminology: NOP generator usually means running a system with no RAM or ROM, and the databus tied to a constant value such as EA or A9. Then you can check the waveforms - or even just the frequency - on SYNC and the address bus. Each bit of the address bus should toggle at half the rate of the previous bit, as the CPU races through the whole of memory in sequence. A NOP will advance by one every two cycles, whereas A9 or similar will advance every cycle.

But you're beyond that: you are now running with a RAM, or a ROM, and aiming to write a very short program to gain confidence. Getting the reset vector to point to some code, and making that code a tight loop, is a good idea. If you can read off the SYNC frequency that will (probably) tell you if you landed in the loop, and almost all the address bits will be static so you can read off where it was you landed.

[backspace119]

BigEd wrote:

(Thanks for the thread discipline!)

First a note on terminology: NOP generator usually means running a system with no RAM or ROM, and the databus tied to a constant value such as EA or A9. Then you can check the waveforms - or even just the frequency - on SYNC and the address bus. Each bit of the address bus should toggle at half the rate of the previous bit, as the CPU races through the whole of memory in sequence. A NOP will advance by one every two cycles, whereas A9 or similar will advance every cycle.

But you're beyond that: you are now running with a RAM, or a ROM, and aiming to write a very short program to gain confidence. Getting the reset vector to point to some code, and making that code a tight loop, is a good idea. If you can read off the SYNC frequency that will (probably) tell you if you landed in the loop, and almost all the address bits will be static so you can read off where it was you landed.

I'll probably do this, just to prepare myself for toggling the emulation mode LED I added a write from-to function to my eeprom writer, and filled the whole thing (minus reset/IRQ vectors) with EA. I then set the reset vector to point to 4000, and put CLC then XCE, then at FFE1 I put JMP, and FFE2 is 02 and FFE3 is C0, so it should jump over the CLC XCE, (I still need to add XCE right before this, so it will swap C and E every time it hits the end). I did some math, and it should toggle about 62.5 times per second at 2Mhz, which is going to look like a dim LED, so I'll probably figure out something to count runs and only toggle it every 100 runs or so.

You are right though, I need to start with a tight loop, I'm getting ahead of myself with excitement now that I can write whatever I want to the eeprom. For this, I'll have it jump to 4000, and then put EA, 4C, 00, C0, which should make it a tight loop running EA, I probably don't even need EA in there honestly. For a second test, I could add CLC XCE in that loop, so I can see the emulation mode LED turn off.

As a note, you're talking about the SYNC pin, which I believe was replaced on the 65c816 with....VPA and VDA I think, right?

[BigEd]

Oh, sorry, yes, of course, you have VPA and VDA.

Putting in some nested loops or something to bring frequencies down to the audio, or to perceptible flicker, is a possibility. I can readily see and estimate flicker rate at 8Hz, but we're all different.

[backspace119]

So some good news and bad news.

Good news is, I turned it on with the eeprom with the tight loop in and the emulation mode light came on.

The bad news is the RTC got really hot, I had it plugged in backwards (very big uh-oh).

I've plugged it in the right way, and hopefully I didn't damage it (or at the very worst hopefully I only partially damaged the battery). It would be the most expensive chip on the board that I plug in backwards. I'm about to verify the clock and other signals right now

[backspace119]

Actually, I either probed the wrong pin or it's now outputting 0v on phi2. I checked continuity again and all pins of the chip are showing connected to where they're supposed to be.

Edit: for those who don't know, I'm using the LTC6900 variable oscillator. Currently I have it set with a 100k resistor to VCC.

Edit 2: here's the datasheet

[backspace119]

Instead of spending a lot of time trying to figure out why the LTC6900 isn't working, and since it's a chip I have no experience with, I green wired the clock signal from the uart can onto phi2, I'm getting a nice oscillation now with a little bit of ringing, but nothing major. The problem now is that something is holding RDY low. I know it should be holding RDY low briefly for accessing EEPROM, but it seems to be stuck low.

[backspace119]

Since the wait state generator was locking up and holding RDY low I removed the resistor that connected that mechanism to the CPU until I can investigate it further. Now, the emulation light still isn't turning off like I expected, but there is some interesting stuff happening.

1. The 65c816 is getting warm to the touch, bordering on hot, should I be worried?
2. I scoped a couple of the high address lines at the eeprom chip, and I'm seeing plenty of toggling, albeit in sort of random sequences.

It seems like the CPU is doing *something* I just don't know *what* yet. It will be a shame if the variable clock and/or wait states don't work on this machine, but if it comes down to it I'll leave them off to let it run.

[Dr Jefyll]

IMO your best next step is to get back to basics and try a NOP generator. That means inhibiting (or simply removing from their sockets) all memory & peripheral IC's, transceivers... anything that might try to drive the data bus. Using resistors, apply $EA or $A9 or similar to the data bus, and with the CPU running you *should* get highly regular "counting" behavior on the address lines.

-- Jeff

[backspace119]

Dr Jefyll wrote:

IMO your best next step is to get back to basics and try a NOP generator. That means inhibiting (or simply removing from their sockets) all memory & peripheral IC's, transceivers... anything that might try to drive the data bus. Using resistors, apply $EA or $A9 or similar to the data bus, and with the CPU running you *should* get highly regular "counting" behavior on the address lines.

-- Jeff

I'll do this, but first I'm checking some logic for address decoding just to make sure it's sound.I think the CPU may've been getting a bit warm because I think it jumped into RAM and started reading garbage. I say this because, I took the RAM chip out to use its socket as test pads for data and address lines, and when it was running without the SRAM it didn't seem to warm up, and the address lines seemed to toggle more stable than they were.

[backspace119]

So, before I started taking chips out of sockets I probed the data lines and address lines to see what they were doing, I also reset the machine a couple times to see if it worked. Reset works well, and the address and data lines are definitely in a loop (my analog scope holds good forms on some lines, with slight "ghosts" on other lines from regular changes to other values).

To my surprised, the emulation mode light turned off at one point after a reset, so it did read the code and executed it. It hasn't done it sense though, so I'm starting to get a forboding feeling that something with my design is messed up.

[Dr Jefyll]

backspace119 wrote:

the emulation mode light turned off at one point after a reset, so it did read the code and executed it.

Yes, somehow it executed an XCE instruction. But unfortunately there's a lot of room for doubt about whether it was the one you intended, or just some random byte the CPU ingested.

[backspace119]

After pulling a couple chips and turning it on it fairly reliably now turns the emulation bit off (although not 100% of the time).

I'm thinking it's running too fast for the eeprom since I've disconnected the wait states. The serial can is running at about 3.68Mhz, which comes out to 270ns period, if we have half the period to access EEPROM, that's 135ns before we even talk about the propogation delay. This is 150ns eeprom, so I think this may very well be the problem (unless I'm wrong about the half the period to access thing).

This means, it's time to figure out why wait states are staying consistently low, and never coming high.

[backspace119]

I've noticed on the scope when the light is off the waveforms for data are much smoother and much less noisy, I'll check and see if the same goes for addresses. Also, once the board has successfully exited emulation mode, any amount of restarts will not break it, it will work every time after that, but a power cycle may cause it to go unstable again, and stop working. I'm still sniffing out the problem with wait states, but getting the clock circuit working could fix this too, (although I'm not sure if I'll be able to get the LTC6900 working or not)

[backspace119]

So this is interesting, the EEPROM Enable at the beginning of the WSG is toggling like you'd expect, but the RDY output is flat...Both WS1 and WS2 inputs are showing flat high, I wonder why that is...