Not a problem -- just wanted to make sure, since we have the two threads already, that they stay relatively on topic. Otherwise, detangling the mess of threads gets horrifyingly confusing.

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

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

Hello again. Just poking in to contribute here, since this is more or less relevant to my FPGA activities right now. What isn't made clear here is what the DMA controller will be used for. Is this intended for use with a generic hardware interface of some kind, sort of like the DMA channels on the PC/XT and ISA buses? Or, will this entail a complete bus master implementation? The answer will determine how to go about building such a controller.

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

Just curious, has anybody done anymore work in this direction? Having a '816 as the main processor and a 'C02 as an I/O co-processor sounds interesting (and slightly mainframe-y).

Working separately, the OP and I both designed hardware that captures the opcode present on the data bus when SYNC is high. This (and a cycle counter and ROM) can yield info regarding what the CPU is doing on any given bus cycle.

Jorge wanted that information so he could identify 6502 dead bus cyles, and reallocate them for DMA. (An alternative approach is to use an '816 instead. '816 unused bus cycles are trivially easy to identify; just look for VPA and VDA simultaneously low.)

I wanted that information so I could build a microcoded exoskeleton that expands the 65C02 architecture with new instructions and registers. The misleadingly named "KimKlone" project was successfully completed, and is documented on my web site with a short summary as well as a detailed description. There's a 6502.org thread about the KimKlone here. And yes, a modern-day alternative is to use an '816 instead!

The link Jorge used in his lead post is now defunct, but what he showed was similar to the diagram above. Wanna try doing something like this yourself? There's a potential problem regarding interrupts. Surprisingly, perhaps, it's possible for an opcode to be fetched yet not executed. See the comment about the XOR gate in this post.

-- Jeff

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

Two scoops of 65xx goodness in one machine? Positively intoxicating!

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

Although a DMA controller to speed up SCSI transfers in my POC unit is not real high on my computing bucket list, I do continue think about it.

To recapitulate, one of the ideas I have mulled is that of using a 65C02 in that role, taking advantage of the SEI -- WAI method to elicit single-cycle response to a DREQ from the 53C94. DREQ (high true) would be connected through an inverter to IRQB on the 65C02. When the 'C94 was ready for data, it asserts DREQ, which would awaken the 65C02 in one clock cycle. The 'C02 would fetch the byte, store it and then toggle /DACK on the 'C94 to indicate that the byte had been read. Similarly, during a write cycle, DREQ would tell the 'C02 that the 'C94 is ready for data. The 'C02 would store a byte into the 'C94's FIFO and then toggle /DACK to tell the 'C94 about it.

I did a cycle count on this and determined that it would be roughly twice as fast as my current method of using the 65C816 as a pseudo-DMA controller. There's more to it than just shuffling bytes around. A counter has to be maintained in RAM and the code driving the 'C02 has to also set up and manage a zero page pointer for addressing purposes. Also, the 'C02's stack is hard-wired to page one RAM. There's not enough of a gain to justify working out the issues.

It could probably be done with a second 65C816 acting as a "DMA controller." Issues of memory management and addressing would be lessened, especially since 16 bit indexing could be done sans ZP pointers. However, the performance improvement isn't going to be much better than by using a 'C02.

The likely solution will come from programming a CPLD to act as a DMA controller. This gets into the design of state machines, since counters and memory load/store operations have to be implemented in a cyclic fashion. As a 65xx data bus is valid only during Ø2 high, it seems that such a device could copy a byte in two cycles. That would, in theory, produce a transfer rate of 10MB/sec with a 65C816 running at maximum clock speed. Compare that with the speed of MVN or MVP, either of which can move a byte in seven cycles, amounting to a theoretical transfer rate of 2.8MB/sec with a 20 MHz Ø2 clock.

I can do combinatorial and register logic in a CPLD, but have yet to work on doing a state machine. However, I do have a picture of the sequence of events that would have to occur.

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

May we be expecting a NUMA design featuring multiple '816s soon from Stratford, ON?

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

Actually, what's more likely is another coprocessor, but only remotely similar to the KK's, and applicable to '816 as well as 'c02. It'd offer some 6809-like address modes, and a partial hardware assist for floating-point calculations done in software.

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

If someone were to come up with floating point hardware that would be 65xx bus-compatible I'd go for it.

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

So in the end, we're talking about a whole separate little computer that handles these things (which really sounds like a mainframe)?

Reading up on an older entry about parallel processing (viewtopic.php?f=1&t=217) makes me wonder about using some shared RAM instead -- the '816 has enough address space, after all. It could put the data in a shared area and then send the "I/O Processor" (say, a '02) some sort of message to the point of "move those bytes to the hard drive and confirm it worked after you are done". It wouldn't really be faster in the sense of bits written per second, especially with the communication overhead, but the '816 could get on with more noble things in the meantime than dealing with the hard drive.

Of course, you'd basically be building two computers instead of one, so that's a lot of issues .

I don't think there's a need for this. Any NUMA architecture will give the illusion of shared memory anyway. And since the 65816 and 6502 are both so memory bound, launching a 6502 to operate on memory shared with the 65816 will, unless you limit yourself to just two processors and have a memory subsystem slow enough to exploit opposite clock phases, actually take longer than if the 65816 just did all the work itself.



This is how, in essence, the Commodore 80xx disk drives worked.

And when you think about it, Commodore's entire 8-bit line-up were really mainframe-y. The host computer would send a high-level instruction to the disk drive, which would interpret this command in a separate address space all-together and completely asynchronously to the host computer's operations. (It's rarely exploited, but it's entirely possible to do disk I/O and computation concurrently with the Commodore architecture.) And, in the case of PET's disk drives, you really did have two CPUs cooperating with each other on shared data structures in memory. The command-processor CPU would give low-level instructions to the drive controller CPU and exchange data via shared buffers.

This is, schematically, surprisingly close to channel I/O in IBM mainframes. The computer sends high-level I/O commands to a "controller," which then breaks those commands down to lower-level I/O functions for individual "units." I don't think this was an accident -- studying the capabilities of Commodore's 8-bit DOS, what with relative files and a flat namespace with long filenames, it's very clearly influenced by System/360 design principles.

I am not sure how much this DMA channel would bring on throughput. In my PET816 accelerator card I have the option to switch that DMA channel off - during valid accesses I run at the original 1MHz, but for an invalid access I speed up the CPU to 10MHz and squeeze the invalid cycle into Phi1. As long as the main machine accepts the address for the next valid access late enough this works (e.g. the Pet 8296 does, the non-CRTC Pet 3032 does not...)

http://www.6502.org/users/andre/adv65/pet816/index.html

On this gallery page I have a screenshot where I measured a loop with the "hiding of bogus cycles - hbogus" on and off. In this specific loop it "looks like" the machine is running with 1.7MHz in a 1MHz system.
http://www.6502.org/users/andre/adv65/p ... llery.html

For a "mainframe-like" system I would rather use Phi1/Phi2 interleave though.

Andre

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/