New devcart

For hardware talk only (please avoid ROM dumper stuff)
antime
Interested
Posts: 22
Joined: Sun Feb 06, 2011 9:18 pm
Contact:

Post by antime » Sun Feb 06, 2011 9:35 pm

HardWareMan wrote:I plan to make cards without the ROM. Concept: RAM, CPLD and supervisor with a memory card or PC link. The procedure is the following: when powerup the supervisor fills the primary firmware into RAM and makes nMRES. At rest of time, it handles requests from M68K (memory card or PC link access). Thus, the replacement driver will be simply feed new code via PC link or replace file on memory card. It is possible, I know (and almost done this before). What do you think? I don't like programming that slow FLASHes anymore. :3
This is exactly the idea I've been toying with for a while. A CPLD (likely a Xilinx XC9500XL for the 5V compatibility), a FT245R and some SRAM. I was also planning to map the FT245R FIFO into the top bytes for communications (one byte for the FIFO, another for the FIFO flags). This may not be compatible with all games, but the point was to make a development cart.

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Mon Feb 07, 2011 9:38 pm

This is exactly the idea I've been toying with for a while. A CPLD (likely a Xilinx XC9500XL for the 5V compatibility), a FT245R
A word of warning: The 245R doesn't have the 'send' pin like the 245BM and 2232 do, meaning sending small amounts of data to the host takes much longer than expected as you have to wait for a timeout to cause the chip to flush data. You can change the timeout to some degree but it's never as fast as manually flushing data.

When uploading data it's not a problem, but I was printf'ing from the target system to the host in another project and it was much slower it could have been. It's still a good chip but the performance isn't the same without the send feature.

antime
Interested
Posts: 22
Joined: Sun Feb 06, 2011 9:18 pm
Contact:

Post by antime » Tue Feb 08, 2011 12:37 pm

That is true, but I like the chip due to the reduced part count. I do wonder why they removed the flush pin though.

The FT2232D's CPU FIFO mode is interesting too, as it would simplify the logic for the comms interface. The other interface could be used in 245 mode for loading data.

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Tue Feb 08, 2011 5:51 pm

antime wrote:The FT2232D's CPU FIFO mode is interesting too, as it would simplify the logic for the comms interface. The other interface could be used in 245 mode for loading data.
Just wondering, have you tried the CPU FIFO mode?

They've documented such a mode in multiple products for years and then remove it and say it never worked in later datasheets. I can't find any projects on the internet where anyone used the CPU FIFO mode of the 2232 either.

For all I know it's a real feature and works just fine, but it has such a convoluted history that I'm not yet convinced. :)

antime
Interested
Posts: 22
Joined: Sun Feb 06, 2011 9:18 pm
Contact:

Post by antime » Wed Feb 09, 2011 7:03 pm

No I haven't, thanks for the heads up. I'll keep it in mind if this thing ever proceeds beyond the paper-plan stage.

Post Reply