That's a nice little insight. Though it might make sense just to use some up/down counters (e.g., 74LS191) instead. With a bit of clever address decoding you could map one counter (actually, four '191s cascaded for a 16-bit counter) to $80-83, where reading from $80-81 increments it after the read and $82-83 decrements it after the read, and a second 16-bit counter to $84-87 doing the same. This would give you an easy way of doing stacks in arbitrary memory locations as well.

Then add a 16-bit comparator hooked up to the S.O. line and you can use BVC to loop, with the comparator setting the overflow flag when you've reached your end address.

Sadly, there are no huge speed gains here. It's 13 cycles per byte so for small (≤256 byte) copies it saves only a couple of cycles per byte for a DEX (and maybe one more during the entire copy if it crosses a page boundry), and not exactly a huge amount more if you're doing larger copies. That's far from even the 7 cycles per byte of a 65816, much less the 2 cycles per byte of a DMA engine.

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

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

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

Ah, I see. Thanks for the explanation.


Yeah, maybe I should have mentioned that in the late-'70s/early-'80s style systems I usually use, I'm also using contemporary peripherals, or am fine with running at the speed of contemporary peripherals.

In that world, 660 KB/second isn't bad at all: that is easily more than most late-'70s and early-'80s microcomputer hard drives. Really serious users in 1981 might buy the newly released 470 MB Fujitsu Eagle, which could do 1.8 MB/sec on an SMD interface, but it was typically only minicomputer owners who had $10,000 (about $35,000 today) to spend on it.

But for me, a floppy drive (or even a fast—by which I mean 19,200 or even 9,600 bps—serial port) is a brilliant upgrade from cassette tape.

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

Im still thinking Harvard arch... to me, the Program Counter should be completely removed from memory access.
getting the next operation, should not be something that changes data addresses, however, this can complicate design by requiring two separate data and program busses. Opcodes should mostly come out of ROM, and Data should mostly be in RAM... to me at least
I have not worked at this low of level much and the old thrill of exploring a frontier again. some of this stuff is 'old hat' from everything else Ive done in computers and electronics, some of it truly mind-boggling to what they were thinking at the time. I understand von-neuman architecture and why it is used, it is just not easy to think in without a little adjustment to my process.
given the stack and zero page are 'low addresses' and vectors for reset and interrupts are on the 'high addresses', I may do some separation via RAM/ROM...

I see a good reason to separate the stack and/or zero page then. using it as local or "L1" cache.
in short only the 6502 should be able to access the zero page under most circumstances.
your mention of a DMAC and|or the '245 further makes me want to explore a little 4-bit micro slice processor and maybe some buss line latches... reading the 6522 makes me want an 8-bit latch or similar to control its Chip Select Lines and the 4-bit needed to cover 20-bit ISA/pc104/PCMCIA addressing. so 'down the line' this looks like a CPLD in some fashion, akin to what I see several people here developing for their SBCs and projects.

ultimately a DMAC is available in many forms, from dedicated chips to logic to CPLDs or as part of an MCU.
what I am after here is interoperability between the 6502 and 6522 to make working with RO/AM (because everything to a 6502 is just a memory address).


so to get back to interoperability between the 6502 and 6522 for moving bytes around quickly...

not exactly like Im thinking, and Im not sure I can get one of those chips...




this is basically what I want to use the 6522 to do

I am seeing that as well, and "PHI1 DMA" might be a better choice overall



noted, you have done a lot of amazing things and your 'CF94 chips is certainly one of the Custom Pretty Little Doohickeys that makes me want to build my own custom specific chip... for the moment, Im just focusing on the 6522/6502 as the 65816 is not going to have a lot of these problems. still it is good to know how you solve problems and what arises.



read it, and I see the similarity, however, I am not so much trying to do that, as just automate as much as I can with a 6522.
I will post more later today in my next post, I need to run an errand right quick and I wanted to cover the responses here before they got too many.

"PHI1 DMA" might be a good option, and this is not really DMA (Ill probavly use a PIC as a DMA as you yourself suggest in places), Im just trying to reduce operations used by utilizing the 6522 to its potential, which I see a thing that might work yet... Im just not certain it saves any trouble.



speed is certainly a concern, mostly just getting a screen updated without tearing sans gpu...

I will post more on my design goals in a bit, I need to run an errand.

Well, I think of it as address spaces: while Harvard architecture machines typically use ROM or EEPROM in the instruction space and RAM in the data space, there's no reason you can't put either in either space.

But the 6502 itself is not that well suited to systems that turn it in to a Harvard architecture since it's not at all unusual to want to use self-modifying code in it, and the neither are home computers in general, where you usually want to be able to load programs from I/O devices and run them, and save programs back as well.


Well, it's definitely not cache since the 6502 always sees it as main memory. Designing a system where some devices can access it and others can't is a pseudo-Harvard architecture (implemented in the bus design rather than the CPU).


If you're looking for speed and parallelism, yes. That's the usual way of doing it and an enormous number of systems do this.

The Apple II was one of the first: the video subsystem (done entirely with 7400-series parts) reads the frame buffers using this technique, so that might be worth study. (The schematics and a description of how it works are in the technical reference manuals for every member of the Apple II series.) The video system in the Apple II also did DRAM refresh as a side effect of the scanning, which explains the funny frame buffer layout. The VIC-20 and C64 also did this, though all the logic for that is packed inside a custom chip. (And the C64 couldn't get quite enough bandwidth on ϕ1 cycles alone, so it also stole a few ϕ2 cycles from the CPU.)

There were also systems that had a complete second CPU running the ϕ1. The first one I'm aware of is the Commodore 2040 floppy diskette system, which is really more of an embedded device. The Fujitsu FM-8, and it's more famous follow-up the FM-7, had two 6809s: as well as the "main" CPU running on ϕ2 with 64K RAM and 32K ROM, there was a "sub CPU" for handing graphics and the keyboard with its own 48K RAM for the frame buffer (640×200×8), a bit more for work area, and its own ROM. 256 bytes of shared memory was used for communication between the CPUs, so the main CPU would send commands such as "draw this character at this size here" or "draw this line there" and the sub-CPU would actually figure out what bits should go where in the frame buffer and write them. There's more detail and schematics in my retroabandon/fm7re repo, if you're interested in seeing how that's done. (And if you're really concerned about graphics performance, using a "GPU" like this might be the way to go.)


I don't see how it's "not really DMA." It's a (non-CPU) device directly accessing memory without the assistance of the CPU (except to set up the transfer), which seems to me (and Wikipedia) the definition of "DMA."

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

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

even with the harvard architecture you still read instructions from memory. sure it's not using the same external bus as for data, but it's still accessing memory. (side note, RAM and ROM are both types of "Memory")
plus in such a harvard system, you'd still want the DMAC to be able to access the CPU's Instruction memory as well as Data memory. so you can copy from data memory to instruction memory or vise versa.


eh not really, you also want the ability for your CPU to execute from RAM. so you can load programs at runtime without having to reprogram a ROM. which is overall just a very very useful ability to have (just look at any 8-bit home computer that runs software/games without cartridges).

on a side note, couldn't you create a "pseudo-harvard 6502" using a 65816 (VDA/VPA) and some logic?

main benefit is that you technically double your address space. but downside is that you require a DMAC or similar to be able to load programs into instruction memory as the CPU cannot do that on it's own.

...damn, why am i so easily distracted by new ideas like this?

anyways, on the note of a CPLD for a DMAC, if it's for the 65816 you'd likely need full 24-bit address registers to be able to copy between banks, though the counter could stay 16-bits wide, which would limit the DMAC to only being able to copy <64kB of data at once, which i think is more than enough. also, do you really need a full 8 bit control register? i think for a very basic DMAC you'd need only 3 bits in total.
1 bit to start the operation. (which also acts as a status bit, so as long as it's 1 the DMAC is still running)
and 2 bits to select if the counter should be added to the source/destination registers when reading/writing. (basically this allows the DMAC to copy from/to a single non-advancing address which is useful for filling areas of memory with 1 value, or when copying from/to/between IO devices)

i think ideas for such devices deserve their own topic over in Programmable Logic though.

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