6502.org

I have read the 65816 data sheet several times and searched here and the across the web, and I am still fuzzy on the usage of the BE pin on the 65816. The datasheet says (I think) it allows an input to enable/disable the "address and data buffers" . I'm not sure what this means. What happens to execution on the processor when BE is disabled? Do internal operations (not needing the bus) stop until it is enabled? the DS does not say, as far as I can tell.

Let me add some disclosure: I am trying (like others I see) to integrate a Propeller/65816 hybrid. My goal is to run the '816 asynchronously and let the Prop/'816 communicate only through RAM, save a few control signals (BE?). I need to be able to deconflict the bus. I was hoping BE would let me do that. I have a feeling it's not so simple. Is there a better way to do this?

I have the Prop talking to the 512k SRAM nicely but I can see it's relatively slow so I don't want to completely shut down the processor when the Prop is on the bus. After loading the ROM, the Prop will only be used for serial, SD, keyboard, and maybe mouse. I have other plans for video, but initial output will be serial terminal through the Prop.

I can use the Prop to generate an IRQ signal - I was thinking about an interrupt based scheme to accomplish the above.

I realize I am committing the newbie sin of too much complexity here. But I have built the plain jane 6502 projects and really want to make this system work.

Thanks,
George

We were discussing BE just a couple of days ago! Check out the last half-dozen posts in this thread.

Sounds like an interesting project -- keep us posted, please.

BE, which means "bus enable," affects D0-D7 (data bus), A0-A15 (address bus) and RWB. When BE is deasserted (high), the 65C816 is able to drive the address and data buses, and RWB. When BE is asserted (low), the 65C816 places the buses and RWB into the high impedance state, which means a device other than the 65C816 can drive the buses and the RWB line without interference.

Asserting BE does not actually stop the 65C816. To do that, one must assert RDY. When RDY is deasserted (high), the 65C816 executes instructions. When RDY is asserted, the 65C816 will stop when Ø2 goes high and remain stopped until RDY is deasserted. When RDY is deasserted, the 65C816 will resume the next time Ø2 goes high.

So to temporarily stop the 65C816 so another device can become the bus master you would assert RDY and BE. To restart the 65C816 you would deassert BE and RDY.

An alternative method of stopping the 65C816 is to stop the Ø2 clock, permissible because the '816 is a static design. My preference is to use RDY for that purpose, as stopping the clock may affect other devices that depend on Ø2 for proper operation (e.g., the 65C22).

Yes! That discussion was just what I needed. Of course have not searched since then.

Thanks BDD also. Clear info as usual.

I will update as things move along. I am very much a novice obviously.

Thanks,
George

I have the '816 sort of running on the breadboard. The traces above from bottom to top are:

Clock, 1 Mhz (blue)
/CE (pink)
/WE (Yellow)
/OE (Cyan)

Using an Alliance 512k SRAM, only wired to the first 64k. The read/write logic is from BDD's diagram on POC V1 using a 74HC00 and '04. (qualified by PH2)
The chip select logic, and this may be totally off, is using !(VPA|VDA). I'm doing that because I don't have any other devices on the bus other than the SRAM. I'm not in love with this method, it just seemed like it would work for /CE.

The program is:
org = $0000

LDA #$FF
STA $D000
JMP $0000

It kind of works. I first load the program, and fill the rest of the first 64k with $EA. After the program runs, I suspend it by holding reset, and look at $D000, and it is $FF, so I know it ran at least once.

But the memory is then overwritten near $0000 with random values, so for sure the program is corrupted.
I'm sort of at a sticking point here, just looking for some insight to bust it loose

Thanks, George.

Hi George,

/OE on the RAM must only go low when PHI2 is high! (During the PHI2-low time an '816 puts the bank address on the data bus, so the RAM output mustn't enable then!) Are you sure the 74HC00 and '04 cause /OE to be qualified by PH2? The waveform says otherwise (the top waveform shows /OE on the RAM, right?) This needs to be fixed before anything sensible can happen.

The waveforms in the photo don't match the program you listed -- for example the three cycles during which /WR goes low. Three writes in a row means an interrupt or BRK being processed -- PC and P (three bytes total) get pushed to stack. Are the /IRQ and /NMI pins on the CPU held high (as they need to be when unused)? BRK is a form of interrupt.

/CE on the RAM can be grounded, since it's the only device on the bus. Besides, VDA is used for protecting IO devices -- RAM doesn't require protection. BTW you didn't mention how /RESET is handled -- the pin, and the vector.

A simpler program is to just fill the entire memory with $EA, or with $A9A9. $EA is a 1-byte, 2-cycle instruction, and should cause the address bus to increment once every 2 cycles. $A9A9 is a 2-byte, 2-cycle instruction, and should cause the address bus to increment once every cycle. You can scope A0 to confirm this behavior.

Don't forget to suspect your interface with the Propeller. That's how you set up RAM and read it afterwards, correct? Always keep it in the back of your mind that your observations may be incorrect -- it's something that can potentially occur with ALL test instruments!

BTW you don't need to use a third-party site to host photos. It's better to attach them to your post, right here on the forum.

cheers,
Jeff

Thanks for the reply Jeff -

I realize that I am not doing a good job of documenting this - I don't have a schematic drawn yet, just the scribbles in my notebook. I will step through the R/W logic again and double check what's happening there. That's why I posted like this - my eyes were crossing and nothing was making sense.

I have IRQ and NMI tied to vdd with pullups so nothing should be happening there. I'll double check it though. The three writes are confusing me too.

You are correct about the Propeller. I was able to write a little monitor/control program that lets me load, view, and write bytes to memory. I also can control the '816 reset line and hold it low or cycle it. I also have it connected to RDY and BE.

The Prop is separated from the bus (and control lines mentioned) by means of 3 74HC245 transceivers and a 74HC373 latch. I am multiplexing the data lines on the high 8 bits of the address bus. Saves me several Prop pins. Therefore the Prop is wired to the SRAM using 16 pins.

R/W from the Prop to the SRAM is working fine. It wasn't, until I learned the true value of decoupling caps. Now every IC on the board has one.

When the '816 is running, I first bring the transceivers/latch offline (high-z) and then release the '816 reset. This should be isolating the Prop, but, I had my suspicions and your question has cued me to check those connections more carefully.

BTW as the Prop loads the memory it writes $00 at $FFFC and $FFFD to setup the reset vector. Having the Prop connected this way really opens a window into memory and what's happening. It's really helpful to me as I can see what is going on in RAM. Otherwise I'd be sitting there staring at a brick.

I hope I didn't sound critical, because it sounds like a fine setup -- very convenient. I questioned it only because in a troubleshooting scenario one mustn't focus entirely on the Device Under Test. Sometimes when your eyes are crossing and nothing is making sense it's because your instrumentation, or the way it's set up, is faulty.

No, I didn't take it that way at all Jeff. I realize that the setup introduces all kinds of uncertainty into the circuit. I'm contemplating moving the '816 onto its own breadboard, getting it working, and then merging the two. At least that way I'll be moving from a known quantity.

Wouldn't you then lose the convenience we just mentioned? It sounds to me as if maybe what you mainly need is to just get your diagrams in order and then check to see that the wiring matches. Drastic alterations don't seem like a solution for that. Then run the simplest possible test, like filling memory with EA or A9, and running that. (BTW it's OK to fill the reset vector too. We have no objection to commencing execution at EAEA or A9A9 -- it doesn't matter where we start; it's all the same!)

Jeff's advice about disconnecting the SRAM's /CE input from the glue logic and continuously grounding it during testing is good. Doing so eliminates that part of the glue logic as a potential problem-causer and frees up on of your 'scope inputs to be used to monitor a different signal.

If your circuit is working right and the MPU is executing LDA #$FF, you should see the SRAM's /OE input go low during the first Ø2 high cycle, and at the same time, both VDA and VPA should be high, indicating an opcode fetch. On the next Ø2 high, you should observe /OE going low again as the MPU fetches the operand ($FF). At that time, VDA should be low and VPA should be high, indicating an operand fetch.

On the STA $DF00 instruction, which executes in four cycles if the m bit in SR is set, you should see the previous sequence for the opcode and operand LSB fetch, followed by the operand MSB fetch. /OE would go low for each cycle when Ø2 is high. Only on the fourth cycle, when $FF is written to $DF00 should you see /WE go low. At the same time, VDA should be high and VPA low, indicating a data access is in progress.

It would be helpful if you could publish a schematic, so we can see if there is a circuit anomaly that you overlooked. Also, make sure that the following inputs on the MPU are pulled up to Vcc:

• ABORT - pin 3
• IRQB - pin 4
• NMIB - pin 6

If any of those are open, noise can cause state changes for which your minimal code has no support.

Also, BE must be actively driven in both directions and RDY should have a pull-up on it as well—it should not be actively driven high.