So Im looking through the 6522 Datasheet and I have a notion that something could be accomplished in terms of sequential memory reads and writes, though I do not quite think it will work.

If I have a Timer, and it is running sequentially, can I use that as 8 or 16 bits of memory addressing, so say, Port A can write lets say a bunch of data like a screen image to the LCD controller, or say copy a 'file'/memory chunk from one place to another?
Like, get address(based on count) in Timer1, and use Port A to write that given memory to a different memory address?

Will this work without any interaction from the CPU?
If it does require interaction from the CPU, how much to do 'this'?
(use 6522 timer/counter and port to send data largely by itself)

will the 6522 need 1 or more instructions from the 6502 for each byte/bit moved this way, and how many?

no alteration, no operations, just data transfer, how much can the 6522 do 'by itself' without being constantly operated by the 6502?

it does not seem like the 6522 can do very much by itself, to use a term, its more like a 'Port Expander' than a coprocessor.

what I am thinking is"

with one of the ports, you latch the upper byte on the bus, and use the other port as data lines
you set a counter for how big of a block to move, it counts down each move (I guess manual trigger count?)
the other counter holds the destination and counts down

since the 6502 is involved, it reads off the port, and then sets the direction to write, and sets the bus to the destinaton,



I think this might make 256 byte transfers more 'trivial', I had hoped the 6522 could automate much of this, due to the 6502 involvement there may be little gain from this, however, it seems like you can save 'several operation' on the 6502 here.


again, after reading the 6522 datasheet, its not a bad chip and takes the +6502 closer to being a CPU rather than an MPU
I think it really 'belongs with' the 6502 in any design that can make use of it.

Sounds like what you want is a DMA engine, along the lines of the Commodore REU.

That seems really difficult to implement with a 6522, not least because when a DMA engine is running you need to halt the CPU (using the RDY line on the 6502).

_________________
Curt J. Sampson - github.com/0cjs

The Commodore REU may be near-unobtanium these days (though they do pop-up on eBay sometimes, for hundreds of dollars), but there are still NMOS and CMOS DMA controller chips with 16 and 24 bit address spaces, with 8 and/or 16 bit data bus width, available from electronics surplus houses - and more from the likes of eBay. AM9517A, HD6844, HD68450, HD63450, INS8257, MC6844, MC68450, etc. can usually be had for small tens of dollars.

Motorola application note AN-824A (available at bitsavers.org) shows an example of how to use Motorola's older 8-bit data/16-bit address MC6844 with a 68000; I think the first few generations of IBM PC designs leveraged the Intel 8257 in a similar fashion.

not exactly, and DMA is kinda the thought, so yes the CPU would not be accessing 'the same' RAM (or any I guess)
its more about saving CPU cycles at this point and offloading 'some' of the work onto the 6522
why load or run a counter for copying data, if the 6522 has one
it can load and send a byte by flipping a Bit.
address load.
copy to port,
swap direction.
address change
write from port

the CPU is doing less here this way I think...

anyway, thank you!


on a slightly different tack, I am looking at a 4-bit microslice processor or "logic and latch" on some systems to extend the memory context and use the ISA buss, and provide 'context switching'

Maybe the 65816 would be useful:
* Block move instructions MVN & MVP.
* Bank address lines, bank registers, bank addressing modes.

ISA address space could be mapped into a set of banks:
* ISA memory addresses mapped to a contiguous set of banks: maybe 1MByte of space mapped to banks $c0 thru $cf.
* ISA I/O addresses mapped to another single bank. Maybe 64KByte of space mapped to bank $d0.

Well, given that you have to stop the CPU and have it sit there doing nothing while DMA is occurring, I don't see why you'd bother having an external device copy memory unless it could do it in fewer cycles than the CPU. (Unless of course you're just trying to show how clever you are—I mean really clever, like Dr. Jefyll-level clever—in which case go right ahead and everybody will be totally impressed! :-) That's serious, by the way; using a 6522 to run DMA might be totally useless, but I'd love to see the design of the circuit and software that does it.)

The standard 6502 copy loop using (zp),Y addressing is about 15 cycles/byte IIRC, a few cycles more on average if you're copying more than 255 bytes. So there's lots of room for savings there.

The 65816 MOVN and MOVP instructions are 7 cycles per byte, which is a huge improvement, but still nowhere near what a good DMA engine can do: 2 cycles per byte.

_________________
Curt J. Sampson - github.com/0cjs

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

Interesting. Can you tell me more about that?


Ah, I'd not thought about that: I was thinking of just doing moves between memory locations, REU-style. And of course on the systems I generally tend to have in mind, 1-2 MHz 6502s, typically I/O devices are too slow to bother with DMA unless (again as with the REU) your "I/O" device is RAM. But I guess that changes as you add faster I/O devices.

_________________
Curt J. Sampson - github.com/0cjs

why would you think the CPU sit Idle, it just shouldn't use memory.
if you have a CPU on a system that has a DMA or memory lockout, your CPU you do 'something else' if possible yeah?
it can do all sort of things on the registers if it doesnt touch memory without harm. i think the software would be tricky though

part of why I asked is to see why the 6522 isnt used more this way, it looks obvious, you save 3-4 operations doing what Im thinking (though Im not sure Im conveying it well )



could you go over those cycles so I can point out where Im talking about using the 6522?


yeah Im just sticking with the 6502 for this right now, the 65816 has a different set of problems...
having a fixed I/O simplifies what Im talking about doing with the 6522.
as for a "Custom Pretty Logic Doohickey", I am thinking of a 4-bit 'processor/latch' for some things, ISA bus, few other places
I am looking at maybe just using an 8bit latch, for 4-bits of chip select and 4-bits of extra memory addresses...
idk yet.

It is sounding like more and more, using a PIC18 or so is probably a lot better choice than the 6522 at this point. Its cheap, has DMA, has I/O lines, has ROM/RAM, has interrupts and can be programmed with very simple loops for stuff like this on its own. Also built in SPI etc for driving a screen...

the 6522 is a pretty cool chip, it has a lot and I think if it was better integrated to the 6502 itself, might have ended up more like a pic or avr. the 65134 just seems like it might be overkill here though. Ill look them over.

I still think the 6522 can offer some automation or assistance to data transfers using its counters and ports, and if my hunch is correct, save the 6502 some time or work.

https://media.tenor.com/RYvCCepol0gAAAAC/elmo-shrug.gif

If a 6502 can't use memory, it can't run, because it reads or writes memory on every clock cycle. (Starting with fetching the next opcode to execute and its following operands, if any. Even for single byte opcode it reads (and ignores) the next opcode during the next cycle while it's executing the opcode it just fetched, and then reads that next opcode again on the subsequent cycle.

It may help to read the MCS6500 Family Programming Manual (and perhaps the MCS6500 Family Hardware Manual) to better understand how the CPU works. In particular, "Appendix E: Summary of Addressing Modes" in the Programming Manual gives details of what the processor is doing every cycle during instruction execution. The example of a singe-byte opcode uses implied addressing, for which the clock cycles look like this:



Just write a simple data copy loop and then break it down cycle by cycle using the tables from Appendix E above and you'll have what you need for 6502. If you want to post that here, I'm sure you'll get plenty of us checking it over.

_________________
Curt J. Sampson - github.com/0cjs

you cannot do operations between registers without RAM access?
very different overall design than I might have done... if you have operations that take multiple clock cycles internally, why would you do anything externally?

there are probably ways around this using some logic and inverters or such... and probably something the little 4-bit msp or 8-bit latch might work... some CPLD...
again, it seems like 6522 is really just a 'port expander' with almost zero stand-alone capability. One more reason to use an MCU on certain designs where there are few devices and minimal I/O. I do not want my CPU doing things like sending video data... SPI on a 6522 is doable and many LCDs use this, however, it means really the CPU is doing the work. I guess if you serialize 8 bits at a time and get to the 6522 buffer fast enough... the 6522 just cannot do much on its own, though adding one to the 6502 increases its I/O uh 'exponentially'.

I will give that a read, I have 6502 ASM on my list of things to do, copying data in a 6502 is a pretty fundamental skill.
I still think the 6522 can help here, even if its just supplying an address.

i mean look at it like this:
how would you get the CPU to do work while avoiding memory accesses, if the instructions required to do anything are located in memory? how would you get them from memory into the CPU if not through a memory access?

that's the main problem with running a DMAC and CPU at the same time on the same bus.
one way around that is to seperate their busses (via a 74x245 for example) and give the CPU the ability to access the DMAC's bus, but not the other way around.
that way the DMAC can run while the CPU still has it's own private section of RAM/ROM and some IO to access, but would get blocked when trying to harass the active DMAC's section of the address space.
of course it's not an ideal solution as that means the DMAC cannot copy data from/to the private address section.
so another way is bus sharing, since the 6502 and 65C02 only use the second half of a clock cycle to actually access memory, you can use the first half for a DMAC. this allows both of them to run at the same time with no performance loss on either site, but of course it also requires much faster logic and memory (especially at higher speeds like +10MHz).

Correct. For a start, if you can't read the RAM, how do you read the opcode that tells you to do a register operation? Remember, these processors don't have any cache.

I suppose you could execute from ROM (or even a different RAM device) while DMA is reading and/or writing RAM, but then you'd need to have logic to split the data bus into two data buses, one between the CPU and the device it's reading/writing and another between the DMA and the device it's reading and writing. That would get complex really, really quickly.


Well, it's a good thing you weren't designing the 6502, then. :-)

I'm not a 6502 super-fan or anything like that, but it's truly an ingenious design for its time, and that's probably what made it so successful. They focused on making something not only fast, but small and cheap (i.e., having minimal circuitry). That's why they could sell it for $25 when the Motorola 6800 was selling for $175. (IIRC Motorola quickly dropped the price of the 6800 to around $75 after the 6502 came out, but that's still quite a bit more expensive.)

One of the things they did to reduce the amount of circuitry was to make the read-ahead simpler. The 6502 is a sort of piplined design. After reading an opcode on cycle 0, it then decodes it on the next cycle, cycle 1. But when cycle 1 starts, because the opcode has not yet been decoded, it has no idea if it needs to read an operand or not. It deals with this by reading the next byte from memory anyway, so that it's there for immediate use if it's needed. If not (because the opcode has no operand), it just throws it away, doesn't increment the program counter, and the next read after that will read the next opcode again. I suspect the savings in time and logic from doing this, rather than trying to decide whether you need to read an operand, are fairly obvious.


Yes, that's about right. It's not a CPU; if you want a CPU, buy a 6502.


Why not? You can engineer for aesthetics if you like, of course, but most engineers actually making products to be sold are tasked with doing things cheaply, not spending extra money to produce something aesthetically nicer internally that the customer will never know or care about.


I can't see how, off-hand, but it's certainly an interesting thought. Even if it doesn't help with this particular case, just working out how it can (or can't) do this might bring up other ideas about how it could be used in new and novel ways.

_________________
Curt J. Sampson - github.com/0cjs

The best I can come up with needs a 6526, as only one of the 6522's timers can take an external clock.

Map a 6526 into page zero somewhere. Connect the CNT input to R/W. Load the source and destination addresses into the timers, and set them to use CNT. Then LDA (timerA) STA (timerB) as many times as you need. You'll have to disable interrupts for this, of course.

You still have to keep track of the number of bytes copied. It's probably possible to abuse TOD for this: load the count into the alarm registers (in BCD!) and use an NMI to stop the copy. Or it could be used to copy zero-terminated strings, looping with BNE.

The 6522 can still be used if only one of the addresses needs to change - you can clear memory, or copy data to or from an IO device. The other timer can be used to generate an interrupt to stop the loop, but that will limit the maximum number of bytes.

You wouldn't actually want to do any of this, but it could be done.