6502.org

Hi Guys .

I have some idea to make super I/O speed independent device .
After all the problems I had trying to use i2c , spi , rs232 and some sound subsystems (in my case swinsid)
I've got this idea . Why not to use double ported ram connected to 65xxx on port A and some micro on side B ? .
For example Using atmega128, we will get access to all features of that micro plus some extra things
like lcd controller , sd fat 16/32 file system controller and much more .

what do you think about this ?

Something like this?
http://www.parallax.com/tabid/708/Default.aspx

The Parallax Propeller was designed to provide this sort of functionality.

Those two are quite straightforward and very easy to bit-bang. You shouldn't have any problems. The other part however has been the subject of a few conversations here relating to using secondary processors or microcontrollers to relieve the main processor of the job of babysitting various interfaces. What can be a disadvantage sometimes is that having these interfaces another level removed from the main processor, you may incur unwanted delays in getting the data back and forth.

True but you also have delay if you do direct software calculate to prepare data or for dedicated IO chips if they are designed for other platforms.

My own thinking on pinball mind is an AVR to babysit the ethernet and USB ports....

Might be worth considering cjb's parallel-port comms system too.

My guess is that posting data through a dual-ported RAM will be a win provided you have a block-oriented protocol - for each data transfer, you need some handshaking to say that the write is done, and the reader has to signal that it's finished with the data. This is less overhead if you're moving many bytes at a time.

Maybe a simple FIFO is a solution if you have a unidirectional peripheral, like an audio out.

Just one (wait/start) register for each protocol . We can write 1 to it , that will be a signal for mpu to start transmission , after that the mpu will set it back to 0. For incoming data Irq can by use . currently I'm working on small prototype using this solution .

I was looking at some 40MIPS 3V3 PIC 33FJ128GP802 devices that have an enhanced parallel master port as possible I/O devices.

http://ww1.microchip.com/downloads/en/D ... 70292D.pdf
http://ww1.microchip.com/downloads/en/D ... 70299C.pdf

They can be programmed to appear as a 4 byte memory area in the hosts address map. Reads and writes to the chip trigger interrupts so you can update the contents.

The device supports software pin configuration so you can map a selection of the built in peripherals (USART/I2C/SPI/ECAN etc.) to the free pins. Ten pins should be free (8 if you want an external oscillator for the full 40MIPS instead of the internal 7.37 Mhz).

That's extremely interesting - a 40MIPS micro controller which can sit on a 6502 bus as a 4-address peripheral. Have you done this, or still in the research phase?

Its still a cunning plan. I bought some for another project but noticed that they looked like they could be useful as I/O processors for a 65xx system.

It's an appealing setup. A similar scheme was used in the 8741, a member of the 1970s Intel MCS-48 family (famous for the ubiquitous 8048 keyboard controller). The 8741 variant was aptly billed as a "Universal Peripheral Interface."

The 8741's host/slave shared memory region was only two bytes in size: a data register, and a command/status register. Despite the seemingly limited interface, a great deal becomes possible if you're willing to explore the envelope. For example, as Big Ed notes, "for each data transfer, you need some handshaking to say that the write is done, and the reader has to signal that it's finished with the data." But I think he'd agree that the "finished" signal from the reader can be eliminated -- turbocharging the transfer -- if reader timing can be guaranteed. That guarantee might not be difficult to achieve, given that you have an entire dedicated cpu at your disposal. (I'm envisioning a block transfer, with simplified handshaking on the innermost loop only.)
Yes. Another consideration is access to the code. Presumably your host system has some way to load new application software, but changes to the code in the slave cpu are likely to be comparatively inconvenient (and hopefully infrequent).

-- Jeff

I'm reminded of the C64 (and VIC-20) disk drives which have a 6502 in them, and the efforts to write faster load routines than the standard ones - and as it happens, Michael Steil recently posted about this - and indeed, one has to tackle code loading and use timing knowledge to minimise overhead. Recommended reading - includes sources!

Cheers
Ed