6502.org

More than two processors on the same bus is always going to have to compromise somewhere. But just two processors? Or one processor and one dumb address generator, e.g. a video lookup.

As long as the memory can keep up with the clock speed, they ought to be able to run code full speed on alternate phases.

Neil

Z80 version of coprocessor using dual port RAM is very similar to 6502 version, so I was entertaining the idea of different processors for main processor and coprocessor. CPLD can accommodate different processor's control signals. Running CP/M with Z80 coprocessor for 6502 may be interesting. I think Apple II had Z80 coprocessor for that reason.

I come back to dual port RAM as a more general and flexible approach to coprocessor interface.
Bill

UTSource site often -- that is, usually -- list an incorrect description of a device and -- even worse -- provide a datasheet for a completely different chip! So I'm always wondering whether I'll receive the chip I know it to be or what UTSource's page says it is.

FWIW: The Cerberus 2080 system has a 6502, a Z80 and 2 small (2KB IIRC) blocks of dual-port RAM. However the RAM is for video and font data so the CPU can read/write to it which the CPLD doing the video generation goes its thing - the CPUs are mutually exclusive though you run either the 6502 or the Z80 but not both on the same memory system at the same time.

-Gordon

Just fo reference. Two 6502 with opposite clocks, albeit with 1MHz only, was already on the old Commodore disk drives.
http://zimmers.net/anonftp/pub/cbm/sche ... 250438.pdf

The clock was generated with just an inverter

Interesting that that worked Andre. I would be concerned about letting something else drive the data bus immediately at the end of PHI2, violating the hold time requirement for the 6502. That's why I suggested shortening the PHI2 high phases, to create some gaps.

In my video circuits I have recently only bothered with write operations, so didn't need to worry about that read data hold time. My most recent one divided the input clock by 4, e.g. to 6 MHz, and this formed phi2; then write enable was constrained to the second half of phi2. This is a bit short for slow 55ns RAM, but for a coprocessor system you don't need as much RAM as I do for video, and 15ns 32K modules are still available in PDIP. Or you can use a lower clock frequency than I did as you're free to choose that.

I want to do a few real world applications to find out how well this dual-port-RAM coprocessor concept works. Well, there are lots of room for improvement. In the pictures are the 2nd board I built because the first board doesn't quite fit mechanically. There are more problems than mechanical; I'll describe them later in this post.

The first application is a bit-bang I2C display. It seems to make sense for the coprocessor to handle serial protocols like I2C, SPI, NeoPixel, audio, etc. I have two I2C displays, the left is 0.96" 128x64 that needs 1K of data to fill the screen; the right is 1.5" 128x128 4-bit grey scale display that needs 8K of data to fill the screen. Both displays are persistent so they don't need to be refresh constantly. They both use I2C protocol, but annoyingly the pin definitions are not the same--the power and ground are switched. So I have two headers for these two displays. I want to start off with Game of Life, then BadApple.

Back of the board shows lots more rework than I've thought for such a simple I2C interface. I have plenty of logic in CPLD, but I'm pin-limited so there are cuts and jumpers to free up some pins. I discovered to my chagrin that I only designed in one clock input. I really should've separate clock for two sides of the dual port RAM so the coprocessor can run at different clock. Right now the coprocessor is running the same 14.7MHz clock as the main processor.

CRC65 is the main processor but memory map of existing CRC65 is a bit of mess. I'm using $E000-$EFFF for dual port RAM on the main processor side. I can write program to $E000-$E7FF and I can read/write data to $E800-$EFFF. Unfortunately $E800-$EFFF is also the CF interface with partial decode, so that block of memory is riddled with blocks reserved for CF interface. <- reminder to self: do a better job of decoding next time.

I've modified coprocessor mapping so the same 4K RAM maps to $0-$FFF, $E000-$EFFF, $F000-$FFFF on the coprocessor's memory map. $0-$FFF is for stack and zero page; $F000-$FFFF is for reset/interrupt vectors; and $E000-$EFFF is so I don't have to write position independent code or fiddle with phase/dephase.

I've written a small test program to load into coprocessor memory, set coprocessor reset vector, and release coprocessor reset to run. It all seems to work.

To be continued.

Bill

This is a small program running in 6502 coprocessor that bit-bang the I2C to display an image on 128x64 OLED display. The coprocessor is hosted by CRC65. I load the program to CRC65's $E000-$E700 which is also accessible by the coprocessor side at the same addresses. Coprocessor is initially held in reset until CRC65 wrote the reset vectors and interrupt vectors to $EFFC-$EFFF. There are 2K region, $E800-$EFFF that CRC65 and coprocessor can communicate with each other, but I'm not using them in this program.
Bill

Yes, I am guessing even to integrate the top half of the Z80 I/O page onto a 6502 bus through wait states needs the Z80 to be running at least two T-cycles per 6502 PHI2, to have one complete T-cycle live on the bus (Phi2 of T3 and Phi1 of the following T1) during the 6502 bus Phi1 stage, and even that is tricky since you'd need to switch out at about 3/4 through the 6502 bus Phi1 so you are not trampling the 6502 bus control signals for memory mapped 6502 I/O that needs the select and control lines valid on rising Phi2.

By contrast, if you have multiple 128 byte mailbox slots in a dual port RAM, putting a latch into the bottom half of the Z80 I/O page for dual-port RAM address lines above A6 and accessing the dual port RAM in the top half of the Z80 I/O page makes for much simpler integration: M1 and A7 high, /IOREQ low, you are accessing the Z80 side of the dual-port RAM.

The differences in Z80/6502 control signals can be reconcile with different CPLD equations. Instead of using Z80's I/O space, I'm thinking of mapping 4K of Z80's memory to the dual port RAM. I can use Z80's extended I/O addressing which has 64K I/O space, but unfortunately the upper/lower address bytes are swapped.
Bill

If the Z80 is the co-processor, one idea would be to have a memory control bit somewhere on the Z80 side which /RESETs to 0, and when it is Reset the dual-port RAM is mirrored in the bottom 32KB of the address space ... it is started up with Z80 code written to the dual-port RAM that executes from 0x0000 that copies a block of code to the high end of RAM and then calls that code, which among its other cold boot tasks, sets the memory status bit to 1 before it executes the HALT to wait for it's first command token from the 6502.