Hi all.

The subject title is about interfacing chips that would do things alongside the 65xx CPUs.

Take for example the VIC-II video chip. The 65xx writes things on memory and the VIC-II renders video from that. But it doesn't need the 65xx to be able to do it. It does it on its own. You could even write a ROM and the VIC-II (with the registers set as needed) would render an image from it, no 65xx needed.

The SID audio chip doesn't work like that: the 65xx chip must write data in the registers (mapped in the memory address but registers after all) and the chip makes sound from that.

The I/O chips also work that way (please correct me): they don't read RAM on their own to operate, but it's the 65xx chip who writes to registers.

So... what are other chips that would work with the 65xx CPU family, that would read from RAM what the CPU puts there and writes on RAM what the CPU needs to process?

I'm thinking for example a math coprocessor that would make calculations that the 65xx normally does slowly. Or a fast memory processor that would copy data between banks of memory with no CPU intervention at all. Those are just illustrative examples.

Thanks all.

It's uncommon for chips to generate addresses and access memory on their own. And I'm not aware of any math coprocessors that do this.

Most DMA controllers are capable of this. There's no DMAC in the 65xx product line, but I think the 68xx family includes a DMAC (and probably the 68xxx family as well).

68xx family chips use the same bus interface as 65xx, so they're very easy to include on a 65xx system. But a 6800 chip would only "know" about 16-bit addresses. It wouldn't be able to copy data between banks.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Video engine needs to run continuously to keep the screen refreshed. The other component I can think of is DRAM refresh logic.
Bill

Offhand I don't know any off-the-shelf chips that work like that, however most 65xx video systems were effectively DMA and ran autonomously taking data from the RAM on the other side of the clock, so the CPU never noticed anything. However most systems that had different video modes/colours/etc. did need some programming by the CPU writing data into it's registers as a one-time operation (which from the CPUs point of view is identical to writing to RAM). The Apple II and PET graphics were essentially 'fixed' although you did have to write to a few different memory locations in the Apple II to select which video system to use (text or graphics) and which page to use (2 separate text and 2 separate graphics screens), and a funny mode where you could have 4 lines of text under a slightly shorter graphics screen.

On the fast memory processor - well, the blitter chips used on the Amigas might be the start of that - something not impossible to develop today (e.g. FPGA) for a 65xx system, however to start them you need to create some parameters in RAM or in the chip somehow - like registers memory mapped as most other peripherals would, but after that, a memory to memory copy of 2 cycles per byte is feasible in a CPU transparent manner with an interrupt or some pollable flag to say 'done'. You could write to RAM and have the blitter chip periodically read RAM but that's probably less efficient. This may be worthwhile as even the block-move instructions in the '816 are 7 cycles per byte, so implementing it in an FPGA is possible, but worthwhile?

Maths co-processors - well they did exist in the day (as it were), but poke values into registers, read results back some cycles later (or via an interrupt). My Ruby system treats the ATmega like that, but the 65xx side is stalled while the ATmega is doing its thing - the 65xx writes data into a block of RAM, 'calls' the ATmega to do work, which then reads the commands & parameters out of RAM, does its thing, writes results back, then signals to the 65xx to carry-on.

Today, this is done almost transparently in the Foenix 816 system. You write the numbers into a fixed area of RAM, an FPGA does the calculation and the very next cycle you read the result back. It looks like RAM to the CPU, but it's really finely grained memory mapped registers.

Beyond that? Well, vector operation is possible using the same technique as video - you might build up an array or 2 in RAM, but like a blitter, you'd probably have to write a few control registers with e.g. start address of the arrays, destination address and the operation to do, and again take an interrupt on completion or whatever.

Part of the issue might be finding something for the 6502 to do while a blitter or math or vector processor does its thing... My Ruby system just stalls and waits for the co-processor to finish - well, most of the time, there are some operations where the co-processor can 'release' the 65xx immediately - like serial output, although if the 65xx fills the serial output buffer then it is stalled...

-Gordon

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

I've read that many times the chips that interface with the 65xx family access the memory when the CPU is in the opposite half part of a cycle.

The VIC-II works that way: it reads the very same memory the 6510 uses, but taking turns to access it. The 6510 also writes to that memory, so everything runs fine, sharing the bus. But then, periodically, the video chip needs extra access to the memory so it halts the CPU, does its things and then release it so it can continue CPU'ing its things.

Those proposed chips (and others) could work that way, sharing the access to the memory, but software wise, the code should be aware that certain things are being done in the memory, and not interfere with it.

Things a math coprocessor could do is to apply certain math, bit manipulation, or logical operations to the contents of a range of memory addresses, with no CPU intervention at all, that could be doing something else in the turn where it has access to the memory.

One of these, then?

A modern FPGA can calculate a 32-bit multiplication or division faster than a 65xx CPU can read the next instruction. I do suggest looking at the Foenix 816 at some point. You copy 2 x 32-bit numbers into 2 x 32-bit 'registers', tell it to multiply then without any delay read the 32-bit result from another register.

-Gordon

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

I was thinking about something like "take all the values of the address range XXXX-YYYY and...

- ...OR them by 10000000", or
- ...shift their bits to the right two times", or
- ...multiply them by two"

Things like that.

Sure. 2 cycles per byte for the read/modify/write cycle. It's very do-able with an FPGA. What do you envisage the CPU doing during that time?

-Gordon

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

Can't actually tell because I have no a concrete idea in mind.

Well, an FPGA could certainly be coaxed to do those things. But another approach would be to add another CPU!

What I'd consider is having both CPUs running from one memory system which they access on alternate phases of the clock. But for this to be worthwhile you need extremely fast memory -- to the point where it's more than fast enough to support a single CPU running at the maximum clock rate (... because if you're not running your CPU at the maximum clock rate then you're overlooking the simplest way to boost throughput).

So, running two CPUs from one memory system is hard to justify nowadays. But I had some fun with the concept back in the early 1980s when I was still pretty much of a newb. If you're curious, check out my Single Board Computer using dual 6809's.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

The VIC-II halts the CPU for 40 cycles to fetch the 40 characters to display on one C64 text row. So 25 times for each vertical scan. This has to be taken into account when the CPU is occupied with I/O operations, for example to the serial bus. However in bitmap modes the VIC-II never halts the CPU.

The ram expansion units that Commodore offered as an add-on peripheral had a DMA chip that could transfer data to and from C64 main memory at one byte per clock cycle (two clocks if you wanted to swap memory). However it was necessary for the CPU to set up the DMA registers and then wait for the operation to finish after triggering it.