phew finally found that thread again ;-)

I've made a new update to my web site.

You've probably read about the USB board I have developed as I've posted to another thread already - see http://www.6502.org/users/andre/csa/usb/index.html for a SL811HS based board with host and device drivers (i.e. the 6502 can be host as well as device)

But now I have published a "block transfer engine" - maybe you can call it a DMA engine. You program it with source and target addresses, offsets and length, then trigger the transfer and ... bang! done! :-) That's easily the board with the most ICs I have built (at least so far): >30 SMD ICs.
You can do interesting things with it - please see here http://www.6502.org/users/andre/csa/blitter/index.html for a detailled description.

Also I have updated the 65k project with some number of changes to the programming specs, in anticipation of implementation issues. Please see http://www.6502.org/users/andre/65k/index.html

Now that my hardware pipeline is almost empty, I can actually start thinking about "yet another FPGA board" ;-) for my 65k

André

First off, nice work on your USB interface!
I added the SL811HS IC to my 2010 8/16-bit Interface IC's thread right after you had posted your success, Thanks!...

On your block transfer engine, sounds like you're trying to add sprites to a video project?

Thanks!



No, that's not the reason. On one side people in this forum were talking about "hidden DMA" somewhere in the forum. Well, until we found out that it's not so easy to just watch the SYNC opcode fetch and derive unused cycles (you also need to take IRQ/NMI into account). I designed the first version of the blitter then (about 2007) only to find out that how I did it wouldn't work (see the web page)

When I thought more about CPU architectures I revisited the blitter board and thought it might be possible to do a new version similar to a CPU, with the different internal busses, a single "ALU" adder (and admittedly a separate cycle counter)... which resulted in the second version, which I now published.

In fact I still have benchmark against a simple copy routine for which number of bytes the effort to set up the blitter is actually worth while. Even if you have only 2 cycles per transferred byte, there _is_ some setup cost (as is with a zeropage-indirect-indexed copy-loop)

André

Just a small update on my web page.

I've added separate pages for 6502-based Ethernet and USB solutions ( http://www.6502.org/users/andre/hwinfo/ ... index.html resp. http://www.6502.org/users/andre/hwinfo/usb/index.html ) They are only a beginning, I'm sure you have more links to projects that I didn't dig up in my (admittedly shallow) search.

I've added my SPI65/B solution (which is inspired by Daryl's 65SPI. In fact using only four devices it is (almost) compatible (fully if you fix the initialization). It is a reimplementation in VHDL, not based on Daryl's code. It has support for only four devices, but also includes four interrupt inputs, and four separate MISO inputs which gives you more flexibility over the O.C. bus when you have to do voltage translation and stuff.
http://www.6502.org/users/andre/hwinfo/ ... index.html

Some update to the 65k programming specs: http://www.6502.org/users/andre/65k/specsprog.html

André

A nice thing about SPI is that there are no bi-directional lines, so voltage translators don't need to be open-collector as implied in the description. They should be high-impedance when it's not their turn to talk, but when it is, they can pull up as well as down. A 74xx126 does this kind of thing on the output. The IRQ\ is still a wire-or with a passive pull-up of course, but that doesn't need to get toggled millions of times per second.

Sorry, the O.C. is my mistake, they should be high-Z of course. But if you only have say a 'LVX245 as voltage translator from 3.3V to 5V, shared with other signals (so you cannot high-Z it) you can wire the signals together on the 3.3V side, but not on the 5V side anymore.

My specific problem was that and that I wanted my Ethernet/USB SPI parts separate from the SD-Card interface.

André