tokafondo wrote:
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.
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/