FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Author Topic: ft245 (232 or 2232 in 245 mode) interface to 68000 bus?  (Read 602 times)

mc68000

  • Newbie
  • *
  • Posts: 3
    • View Profile
ft245 (232 or 2232 in 245 mode) interface to 68000 bus?
« on: November 03, 2019, 12:45:38 PM »

Anyone have advice, or an example schematic connecting the 8 bit data bus end of an ft245 as an I/O device to a M68000? (or 6502 for that matter.)

I'm particularly interested in what buffering and what handshake signals, signalling DTACK and IRQ, would be needed, and using whatever modes would enable bi-directional buffering transfers rather than just bitbang and at the highest data rate possible.

This would be to allow me to connect a modern USB computer to an older 68k machine and be able transfer data back and forth.

I realize that on the 68k side I'd need some tri-state logic to detect the I/O address and enable the 68k data bus lines, as well as 5v<->3.3 conversion, but I'm less sure about the handshaking logic to the ft245 side. Ideally I'd like to be to write code on the 68k side to MOVEP bytes in a loop, one at a time, in or out and not potentially lose them. That is to use the internal buffer that the ft245 chips do, so on the modern PC side I could use the driver and read the same byte stream sent by the 68k or write a stream of bytes and have it delivered to the 68k side.

Thanks.
Logged

Jaholmes

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: ft245 (232 or 2232 in 245 mode) interface to 68000 bus?
« Reply #1 on: December 03, 2019, 04:13:26 PM »

Hey there, mc68000 - Fellow retro computer engineering hobbyist here. :)  I don't have any schematics to share, but I have a few comments:  First off, the FT245 is a 5V-capable device.  Supply 5V to VCC and VCCIO.  No level translation needed.  Regardless of interrupts, you'll still want a way to poll the FT245 for status, as sending a block of data with interrupts between every byte would be horrendous, performance-wise.  So, map the TXE# and RXF# using a tri-state buffer at some other memory location.  You may have other peripherals with similar needs, so you can probably find things to do with the remaining bits.  /DTACK is a larger topic, but if you're using all reasonably fast peripherals and memories you might get away with simply tying /DTACK to ground, as many others have done in simplistic designs.

If your memory map and selection of peripherals are complex, however, you might bite the bullet and throw a cheap PLD into the mix.  A little will go a long way.  I recently did a 6502 build and fit all the address decoding into a $1.50 22V10 chip.  They're still available from Digikey, and you earn extra 'retro' bonus points by programming them in the ancient CUPL language. ;)
Logged

mc68000

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: ft245 (232 or 2232 in 245 mode) interface to 68000 bus?
« Reply #2 on: December 14, 2019, 07:16:25 PM »

Hey there, mc68000 - Fellow retro computer engineering hobbyist here. :)  I don't have any schematics to share, but I have a few comments:  First off, the FT245 is a 5V-capable device.  Supply 5V to VCC and VCCIO.  No level translation needed.  Regardless of interrupts, you'll still want a way to poll the FT245 for status, as sending a block of data with interrupts between every byte would be horrendous, performance-wise.  So, map the TXE# and RXF# using a tri-state buffer at some other memory location.  You may have other peripherals with similar needs, so you can probably find things to do with the remaining bits.  /DTACK is a larger topic, but if you're using all reasonably fast peripherals and memories you might get away with simply tying /DTACK to ground, as many others have done in simplistic designs.

Right, I was thinking to start with an FT245 and then maybe try the 245 mode of the ft2232 - I think maybe the ft600 or ft601 would be overkill as I don't think I can get anywhere near USB3 speeds out of a 68000 at 8MHz, so that's why I mentioned 3.3V, though the 601 likely needs lower than 3.3V. :)

I was thinking maybe I can simplify things on the programming side by using one 8-bit parallel channel on the ft2232 for sending out of the 68k and the other for receiving, but maybe that's not needed if the 68k will be saturated with an ft245, but if not, I might spend a bit more and use an ft2232 because then I might be able to use both channels together to fill the 16 bit bus of the 68k, or use one channel for reading from the 68k and another for writing to the 68k.

I can totally attach the TXE#/RXF# to the bus at some other address, or if I wind up not using the high 8 bits of the data bus, I can wire them to two bits there and use the remaining 6 bits for something else. Or TXE# can go on one address and RXF# on yet another, so that way in software I don't need to use AND to filter them out.

The machine I want to interface with already has devices that use DTACK so I can't just ground it, so likely I'll need something to generate it once data is read or written. I'm looking at Clements' book for stuff like this (Microprocessor Systems Design, 68k HW, SW and interfacing). Probably just need a flop or two.

I do want to generate IRQs when data's available from the USB end so that the 68k handles it, but it's going to be on the order of 16 bytes to 32k transferred at a time, so once the ISR gets called, that IRQ will remained masked until it pulls all the data out of the 245 or 2232 and the PC side is done before clearing the IRQ. I could probably go overkill and implement a DMA, but want to keep it simple, so it's not going to be pure bitbang, and I do want some handshaking to deal with the data transfers, so I don't lose data, but otherwise want to build something simple and quick, but want to max the throughput I can get from the 68k. I suppose since SCSI chips like the NCR 53c90 and Ethernet chips have been attached to 68k's, I can probably get roughly 5MBPs, but maybe not with an ft245.

If I can get more than 1MBPS out of this setup, I'd be very happy. (I'm guessing that those SCSI cards and Ethernet controllers for say the Mac Plus, likely got nowhere near that much bandwidth, and likely they used DMA.)

If your memory map and selection of peripherals are complex, however, you might bite the bullet and throw a cheap PLD into the mix.  A little will go a long way.  I recently did a 6502 build and fit all the address decoding into a $1.50 22V10 chip.  They're still available from Digikey, and you earn extra 'retro' bonus points by programming them in the ancient CUPL language. ;)

Yes, that PLD does sound interesting actually, that might save me a bunch of work elsewhere, thanks for the tip!
I take it stuff like flops and tri-state buffers, address muxes can be built in that PLD, or if not maybe one with more pins?

I think I might be overthinking this and I just need to build it out on a breadboard and start playing with it to see how they behave together, and once I get something going with the 245 I can then try the 2232 in 2x FIFO mode and see how that does and if it gets any better or not.

Probably for testing I'll need a C program on the PC end to use the FTDI driver to send and receive as much data as possible in a tight loop and keep track of time so I can benchmark it, and something on the 68000 that does the same kind of thing in a loop, maybe one that just reads the bytes and discards them and another that just sends the contents of RAM or just increments a byte and sends that byte over and over, etc.

Thank you much for your suggestions @Jaholmes :-D
Logged

Jaholmes

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: ft245 (232 or 2232 in 245 mode) interface to 68000 bus?
« Reply #3 on: December 18, 2019, 05:39:54 AM »

If I can get more than 1MBPS out of this setup, I'd be very happy. (I'm guessing that those SCSI cards and Ethernet controllers for say the Mac Plus, likely got nowhere near that much bandwidth, and likely they used DMA.)
I don't know about DMA, but lowendmac.com says the Plus could do about 250kbytes/sec, which seems pretty darned good to me, actually.  Getting 1Mbyte/sec with just an 8MHz 68k plus an FT245 is going to be really difficult, I fear.  The minimum bus cycle on the 68k is 4 clocks, and you'll be burning a few of those just to fetch your write instruction.  So that 8MHz divides down really fast.  Especially if you're wanting to do more than just spam the FT245--which seems a foregone conclusion.

Using a dual-port device for 16-bit writes is interesting.  I like abuses like that in general, although I'd probably favor a wider single port out of sympathy for whoever or whatever is at the other end of the pipe.  And I'd still call 1Mbyte/sec a feat at 8MHz sans DMA.

But post your results!

Years ago, I mated a UM245 module to an 80MHz chipKit board and wrote byte as fast as I could.  At the other end, on Windows, I wrote a little D2XX app that implemented all the throughput tips from the FTDI app notes and just sucked down bytes as fast as it could.  (This was to see how fast I could stream samples from a sensor.)  IIRC, I was able to sustain about 990kbyte/sec.

Yes, that PLD does sound interesting actually, that might save me a bunch of work elsewhere, thanks for the tip!
I take it stuff like flops and tri-state buffers, address muxes can be built in that PLD, or if not maybe one with more pins?
Yeah.  This thing is a living fossil--one of the only remaining PLDs on the market where you can look at the logic diagram in the datasheet and actually grasp the capabilities of the device.  It does have (optionally) registered outputs with tristate buffers, but you might find it more useful for basic async combinational stuff like address decoding.  It's amazing how many elementary logic gate ICs you can replace with one of these.  Plus, again, they date from the early 80's (just with flash instead of OTP fuses), so you're not poisoning your retro build with too much stuff from a different millennium--in case that matters to you.  (When you download the CUPL tools from Microchip, you'll be amused to see that all the code samples are dated from the 80's too. :)))

You'll need a programmer for these devices.  If you don't already have a somewhat general-purpose programmer, there are some good cheapies around.  I like my XGecu TL866II Plus (~$60).  There's probably a newer version (or two) by now.
« Last Edit: December 18, 2019, 05:44:03 AM by Jaholmes »
Logged

mc68000

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: ft245 (232 or 2232 in 245 mode) interface to 68000 bus?
« Reply #4 on: December 25, 2019, 09:42:41 PM »

Quote
I don't know about DMA, but lowendmac.com says the Plus could do about 250kbytes/sec, which seems pretty darned good to me, actually.  Getting 1Mbyte/sec with just an 8MHz 68k plus an FT245 is going to be really difficult, I fear.  The minimum bus cycle on the 68k is 4 clocks, and you'll be burning a few of those just to fetch your write instruction.  So that 8MHz divides down really fast.  Especially if you're wanting to do more than just spam the FT245--which seems a foregone conclusion.

Hmmm, right you are, assuming it takes ~8 cycles for a read (and if the 68k Clements book isn't lying also 8 for a write), at 8MHz, that's 8,000,000/8 cycles is ~1MB/s without anything else going on.  Of course each of those reads should then be acted on and written back somewhere else in memory, so that's half that, so ~500KBps, and ofc the 68k has to execute code from other parts of RAM/ROM, so yeah, 250KBps seems like a reasonable value with all that going on, and certainly if wait states are inserted.

So that right there, I guess is the end of my trying to use a 232 or 2232. :( Oh well.  Even with DMA, the timing cycles would be roughly the same - not that I want to use DMA as that would complicate things and I don't know enough about it to try right now.

On the other hand, I no longer have to worry about level shifters as 3.3V is off the table now, so that keeps it much simpler :)

Doing both lower and upper byte simultaneously would help I suppose.
Does FTDI have by some chance a 16 bit wide chip similar to the 245 without going to the way overkill ft601?

I'd be ok with using 2x245 if I can distinguish between the two ports, but yeah, there could be synchronization issues between lower and upper bytes.  I suppose I could have the initial startup send two different values in the upper and lower ports, i.e. 0x12 to the low byte and 0x34 to the high byte or whatever and once read I know which is which, but ya, very kludgy. I suppose, I'd need to add a USB hub infront of the thing or just use two ports on the PC side.

Quote
You'll need a programmer for these devices.  If you don't already have a somewhat general-purpose programmer, there are some good cheapies around.  I like my XGecu TL866II Plus (~$60).  There's probably a newer version (or two) by now.

I have this guy: https://www.amazon.com/gp/product/B00K73TSLM/ - it might work with the 22v10. It's a "Signstek TL866PLUS Universal USB MiniPro EEPROM Flash BIOS Programmer AVR GAL PIC SPI Support 40 Pin" - seems to be (almost?) the same thing you point to, likely just another vendor selling it. Doesn't say it has the "II" in the model, but scrolling down it says it does have that chip.
Logged