I'm bouncing ideas around in my head for a future computer build, which would involve a rehash of Acorn's 6502A microcomputer card as used in their System range (schematics here), but with additional RAM on board, etc. This card had the feature of allowing the user to select the clock speed from 1MHz to 3MHz via a set of jumper links, as all the clocks were generated from a master 24MHz clock.

I'm minded to use a 65C02 for this build. The 6502A topped out at 3MHz rated speed, but subsequent versions of the 65C02 go much higher. So I got thinking: why not connect the CPU to a different subdivision of the 24MHz clock and go faster?

The main sticking point is with peripherals. I can sort out faster RAM and ROM, and the 65C22 should keep pace with the faster clock speed, but Acorn's System used a 6845-based video card, and a 6854-based networking (Econet) interface. Disregarding the networking for a moment, let's concentrate on the video interface. From what I've been able to work out, the 6845 and third-party compatibles (such as the HD46505) all topped out at a bus speed of 2MHz. (The CRT display timing may go to 3MHz or 3.7MHz, for higher resolutions, but the bus speed was still 2MHz.) So unless someone can tell me otherwise, I wouldn't be able to get the CRTC running at the same speed as my speedy CPU.

Dealing with access to the video RAM would be straight-forward: a few kilobytes of dual-port RAM is easily affordable, and would let either side read and write in the appropriate phases of their own clock cycles. But I'd still need to address how the CPU will access the 6845's registers. A few ideas present themselves:

• Interrupt the clock circuitry while the 6845 is accessed - the 6502A card has a Memory Ready (MR) signal for this purpose, but no guidance on how to trigger it from other peripherals. (It's designed for the NMOS 6502, so leaves the Phi0 signal high.) Could I decide that any access of the expansion bus' I/O space will automatically trigger a low MR signal for the equivalent of a 2MHz clock cycle?
  
• Use the READY pin on the CPU to halt execution for a few clock cycles when it accesses the 6845 - the 6502A card has a Bus Request feature of this design, intended for DMA use. I'm not sure whether this would be a better or worse approach than the one above
  
• Copy the BBC Micro - The Beeb ran at 2MHz but had a lot of 1MHz peripharals on-board (and a 1MHz expansion bus), so it included a clock-stretching circuit that would run the CPU at 1MHz instead of 2MHz when accessing the slower peripherals
  
• Use a 65C22 as a buffer - I could look at using a fast 65C22 to buffer writes to slow I/O, but reads would still be problematic.

Would any wise heads be able to offer any advise on the above, or perhaps suggest an alternative approach that hasn't occurred to me yet?

Using RDY on the 65C02 to generate wait-states can become problematic when there is a major chasm between the MPU's speed (officially 14 MHz, but capable of 20+ MHz) and the peripheral, the 6845 in this case. Your wait-state would need to have at least a seven clock duration (assuming a 2 MHz 6845), which is not a problem for the 'C02. The kink is in the need to qualify writes with Ø2 so as to avoid spurious accesses that can cause the peripheral to misbehave. This aspect of 65C02 circuit design has been well-hashed around here, so I won't go into any detail.

Succinctly, if the 'C02 is halted with RDY, steps must be taken to prevent the /WD (write data) signal to the peripheral from synchronously oscillating with the Ø2 transitions. I struggled a bit trying to handle that in a CPLD and then, in a rare fit of lucidity, conjured a relatively simple wait-state method that stops Ø2 in the high state, with no logic needed to deal with the oscillating /WD matter. The linked topic describes the theory and presents a circuit design that has been tested.

Something to consider.

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

This is my approach in my Ruby system. I run the "motherboard" at 16Mhz and the 65C22 acts as a "slow bus" interface (in Beeb terms) to talk to peripherals - like VDU, Joysticks, and so on. I wanted to keep my high speed stuff all on on small motherboard so I'd not have issues with extending a CPU bus over a backplane.

Look at the port handshake modes on the 6522 - data/strobe/ack and an 8-bit bus can be bi-directional. What you can't easily do is high speed "poke pixels" but you can send high level commands like draw-line, plot sprite, scroll and so on - my idea is more like the "motherboard" being an Acorn style Tube 6502 (65816) 2nd processor to some sort of "host", or multiple hosts. The bus can even be thought of working similar to SCSI and I can get close to 1MB/sec over it which puts it close to the 1Mhz bus.

I've not got this fully running yet but I'm able to talk to devices like an ATmega and a small $5 SBC via level shifters to do stuff like video (although I also do video via serial line which is very effective)

-Gordon
(Moor bakes on Facebook if you've see me there)

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Looking at Acorn's later machines, although they did use clock-stretching in the Beeb, subsequent offerings using a CMOS CPU used RDY - which I take as an endorsement of the RDY approach.

As BDD notes, depending on the rest of your system either approach might need some care.

For low-bandwidth slow peripherals, a 'slow bus' on the far side of a VIA is a good solution - this is also seen in the Beeb.

Video memory is an interesting one and a tricky one. It can be in the main memory map, or not. It can be paged in and out, or not. It can be made easy to write to but hard to read. And so on.

I have a lot of links to video interfaces in the last half of the displays page of the 6502 primer.

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

Thanks for all the replies. Responding in no particular order:

BigEd, I hadn't looked in detail at what Acorn did with their 65C02 in the Master range. I wonder if they switched to using the RDY signal because they no longer had the NMOS limitation of RDY only kicking in during read operations?

As for video memory, I'd plan to put it on the same expansion card as the 6845, so it'd be off on the expansion bus. The 32K SRAM chip I have planned the lower half of the memory map (located on the main board) will need some holes for I/O space, so I can add holes for off-board video RAM easily. I'll leave paging for when I eventually make my own design from scratch. I'm undecided whether to operate dual-port video RAM at the CPU clock speed (and only have the 6845's registers accessed at 2MHz like the rest of the expansion bus) or to slow down all video writes to 2MHz.

Garth, your primer pages are, as ever, a good read. My current 6502 machine uses a calculator LED display, and I'm currently working on wiring up a teletext-based VDU for it (following the Acorn System replica theme). At some point in the future, when I design a full 6502 machine from scratch, I'll probably be opting for an LCD-based approach. But for the time being I'm sticking to tweaking and updating a historical design.

drogon, a reservation I have with the 6522 approach is how I'd deal with the handshaking. At the moment I'm planning on using the existing System OS largely as-is, but the handshaking would presumably need some software modifications.

BDD, the approach you describe appears similar to the method Acorn used on this 6502A board, using their /MemoryReady input. Here's an extract of the diagram and a description:

A 24MHz crystal is seen at the bottom of the diagram, and three 74S163 counters divide this to create the various clock signals sent to the backplane on the right. LK1-3 selects one of the 1-3MHz clock signals to feed the circuit at the left of the diagram. The selected clock signal is used to clock the /MemoryReady signal through a 74ls74. The output of this 74ls74 is normally low (when the /MemoryReady signal is inactive high), and is updated only at clock transitions. It is ORed with the clock signal (74ls32), and its output is used as the Phi 0 input to the 6502A CPU.

The net result is that the presence of the active low /MemoryReady signal causes the output of the OR gate to remain high, and thus halts CPU execution until /MemoryReady returns high. (As it is an NMOS CPU, it has to be halted in the high-phase of the clock cycle.)

Going with this approach would need two further steps that I can see: identifying when the expansion bus is accessed (already done by the gate logic for the buffer for the data bus on the expansion bus) and determining how long the /MemoryReady signal should be held low.

I've since stumbled across Dr Jeffyll's design for a 74xx163 clock-stretching circuit, which definitely warrants more thought. At first I was thinking I could use it to generate the /MemoryReady input (with its stretched PHI2 output), but then it occurred to me that it could replace the original clock latching circuit (74ls74 and 74ls32) as well!

I have no knowledge how the BBC is using the 6845 in detail so perhaps this is silly: could a second 65C02 running at 1 or 2 MHz with the 6845 being part of his memory do the job? The two processors could communicate via a dual port RAM or s.th. else.