Hi everyone — new to the forum, and inclined to hack first and ask questions later, so am probably doing a lot wrong — be gentle.

I have dedicated this past week to building a breadboard 6502 around the W65C02S CPU and I have a mostly satisfactory set up with in-circuit reprogramming of the ROM, three clock generation options, and a debug monitor that shows bus activity and disassembly as I step cycle-by-cycle through the program (see attached image of the monitor).

So the things I need to complete the project are a video display and keyboard, and I plan to do the video display card next on an RP2040 embedded in the Raspberry Pi Pico dev board. This will either speak VGA or MDA to a connected monitor (I hope to get MDA working but have an example of working VGA which may distract me into that path first). The video card will provide a simple text mode - perhaps 80x60 lines or similar - and it needs to read the characters that are going to be rendered into the frame buffer by DMA from the RAM of the 6502 system.

I've built the basic system so that when the clock is low it is possible to bring BE low and then enable the RAM chip, and read RAM in the monitor in this state. The plan is to use this same method from the video card pico, but the RDY pin documentation in the datasheet says "A negative transition to the low state prior to the falling edge of PHI2 will halt the microprocessor with the output address lines reflecting the current address being fetched. This assumes the processor setup time is met. This condition will remain through a subsequent PHI2 in which the ready signal is low. This feature allows microprocessor interfacing with low-speed memory as well as direct memory access (DMA)." (Jan 2022 version) It doesn't seem to specify the state of the address bus if RDY is disabled when the clock is already low.

I seriously don't understand what they're trying to tell me. How does the processor asserting the address bus help me with DMA? The behaviour I'd want is for the bus to be in high impedance mode so that the video card can be the bus master(*). The mystery pins page on Garth's site didn't enlighten me either.

My tentative plan is to use Φ1's rising transition to disable BE and RDY, control the bus for as long as I need to (but ideally be done before the rising edge of the Φ2 clock), and then restore BE and RDY, doing the video RAM DMA entirely during the low phase of Φ2. Worst case scenario I miss this target and the CPU misses a cycle, a situation I can catch in the video card and log in some way so that I fix it.

The question is: is this approach workable, or if not, what's wrong with it? Alternately, even if workable, is there a simpler approach that I'm overlooking?

Thanks in advance for any pointers.
———
(*) What is the PC term for this? I realize "master" is no longer acceptable but I'm not aware of the current terminology to describe the bus relationships.

RDY and BE are separate features. RDY controls the internal state, and has no effect on the external signals. BE controls the external signals, and has no effect on the internal state. To do DMA, you want to use both: pull RDY low to halt the processor, and BE low to remove it from the bus. (Why are they separate? RDY is also used to pause the processor to give slower memories a chance to respond. You want the bus to be driven during that)

RDY can be a tricky signal to use. When they say "A negative transition to the low state prior to the falling edge of PHI2", they're telling you how to use it. Pull it low at the right point in the cycle, and the processor will halt. Pull it low at the wrong point, and anything could happen. So don't do that.

And on the 65C02, it's also an output. The WAI instruction can pull it low regardless of what your external hardware is doing, and it's probably safest to use an open-drain output with a pull-up resistor. Even if you don't intend to use WAI, if there's a bug in your code it might run away and hit one anyway.

Controller / Peripheral seems a popular alternative.

It sounds like what I might want is to just pull BE low and be sure that I am done with the bus before the next rising edge of the clock - if I pull BE low when Φ1 goes high, and restore it before the next clock pulse, that should enable DMA during that window?

I don't really want to halt the processor, I'd like it running at full bore while the display gets the frame buffer between cycles.

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

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

In that case, yes, only BE is fine. The 6502 only needs the bus during half of the cycle, and you can do what you like with it in the other half. This was very common for doing video in the home computers of the 1980s.

One more thing to watch for: BE also tristates RWB. You'll have to pull it high while you've got the bus, or your video might end up scribbling all over memory.

Thanks to both of you for pointing out the RWB risks, I did exactly that when prototyping it with my debug pico, but failed to mention that RWB would need to be pulled up. As the video card doesn't need to write RAM at all, I don't think I have to control the signal. The debug pico does control it in order to be able to program the EPROM but that module is designed to be removable from the system/the core system doesn't (yet) need to write during DMA. This looked cool but a bit more complicated than I am hoping for, and for text mode at least I think there's plenty of time/bandwidth in the low clock time.

Acorn's BBC Micro (and other 6502 computers) used the clock-low period to allow the video system to read RAM, and the clock-high period to allow the 6502 to do what it needs to do. This is pretty straightforward. The penalty is that RAM only gets a half-cycle to perform an access, so a 2MHz 6502 system needs, in effect, 4MHz-class RAM. In your case, perhaps everything would have only a half-cycle. But that might be fine.

If you want to just access memory during phi2 low, you can just use BE to tell the CPU to relinquish the bus and you can control it. In earlier CPU variants without BE this was done with address bus multiplexers.

What you need to make sure is that one the address lines become active - on either switchover - select logic needs some time to get valid, and you need to make sure you don't get any spurious accesses. I think that has been mentioned above.

One way to do this is to create a phi2d that is delayed at least as much as the longest delay in the select logic. Then allow accesses only when both phi2 and phi2d are high. This has been done for connectingba VIA6522 to the C64, as the C64 shares the bus between phi2 low = video and phi2 high = CPU - but the VIA requires valid addresses at risongg phi2 already.

Delaying phi2 can be done with various methods, e.g. shift register clocked with a higher clock.

A similar approch I did for controlling dRAM where I delayed a 1MHz phi2 by a few 8MHz clock ticks and xor'd this with the original phi2 to create the /RAS signal required by dRAM. But I disgress.

Anyway, hope that helps and welcome to the forum!
André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Yes, I’m using 55ns SRAM and plan to run the system at 1Mhz, so the RAM is about 20x faster than it needs to be. I ought to be able to get something like 9 read cycles in each half cycle and have time to spare, and I plan to read only one byte each half cycle anyway…perhaps fast parts run at slow speeds is too much cheating, but I’m not familiar with timing issues and am confident that debugging them is not the path to enjoying this project, at least not yet…

Thanks for the welcome! I was thinking I could use Phi1 as the delayed signal and bring down BE when Phi1 rises. I haven’t measured the delay between the falling edge of Phi2 and the leading edge of Phi1, but I was (foolishly?) assuming that the chip provides Phi1 for just purposes such as mine.

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

Probably two issues here: I spoke with imprecision and I keep changing my mind about what I “want”.

But re: full bore, what I meant was that I don’t really want to halt the processor and miss a cycle, which seemed to be where one of the other alternatives was headed - especially because it seems needless at these speeds.

Re: what I “want”: I’m trying to build the first computer I have ever built, for fun, and have something in the end that is approximately the same capability as the Apple II clone that I owned as a teenager. I do not (yet) have sufficient interest to understand the magic of analog and AC circuits, which involve a *lot* of concepts I don’t understand at all … so I think trying to stick to slow clock speeds will help me not get into trouble.

Of course my thoughts are bound to change over time, but right now I think I’ll be happy if I can build a computer with a keyboard for input, an old school mono monitor for output, and a text mode basic. Once that’s working on breadboards, I might decide I’m done or I might decide to draw up a schematic and order circuit boards. If I get really ambitious I might design the circuit boards with stacking headers so that the system is “modular” and each layer in the stack adds a discrete piece of functionality (so far I have a debug monitor module, a CPU module, a 2-line text display module, and a ROM/RAM combo module which possibly should be split apart; and I want to add the mono display module and perhaps a VGA module).

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

As I’m only about one week in and will need to take a break for a few weeks, it’s a good time to reconsider goals. Here’s what I currently have working:

Hardware: CPU module, RP2040 based monitor (we’ve seen the dumps in other threads, showing cycle by cycle execution of the CPU along with a disassembly of instructions), VIA with 2-line LCD display attached that can display “Hello, world!”, and a combination ROM/RAM module.
Software: So far I’m using vasm to assemble handwritten assembly code; this can then be loaded into the debug monitor at the MicroPython prompt. I have to manually drive BE low (I plug a wire into the breadboard for this) when the clock is stopped, and I can then run programROM(code) at the MicroPython command prompt and the signalling is in place in the design to enable the monitor to program the ROM. Then restore BE, hold the reset switch, and set the clock running and the assembly runs. I can control the clock in software if need be but also have a hardware single step which is the main way that I single step the clock.

I was thinking that the next natural steps were to either built the keyboard module or the mono display module. I had started building the mono display module and attached it, but in the process of doing that I bumped D7 out of its spot on the debug monitor board and mistakenly plugged it into the “RUN” pin out on the pico board, which was right next to the GPIO it was meant to be plugged into. This cost me a day because I failed to debug it properly and wound up removing the module from the system completely before figuring out that the new module was not the source of my spurious resets.

So I was going to go back to that next, but since you suggest simpler goals what do you think is the appropriate reduced scope/next step from where I am? One alternative that occurs to me is that I could build a serial monitor first - either an old school RS232 serial interface or a USB interface for the console - and get basic up and running on that, before building the keyboard and video modules.

Thanks in advance! I will really value your insight!