New idea for a cart dumper, would it be useful?

[Charles MacDonald]

I swapped the RX/TX lines (for great justice) and also wired 2 of the I/O pins to the 2 left-over inputs I had on the chip that would allow bit-banging. The other two lines on the connector I tied together so that software would be able to detect if the dongle thing is plugged in or not. (And also if a controller is plugged in - if the input line there goes high without the output being set to high, someone is screwing around.)

I wouldn't connect the I/O pins directly together like that (pins 1,2, and then RI to pin 7) because if the pins get programmed as an output you'll get a conflict and there's a risk for damage. I'd put series resistors in there, like 4.7K for example (one between 1,2 and one between RI and 7). It's pretty cheap insurance.

That way no matter how the I/O port is set up, nothing is harmed. Otherwise it looks good!

What it's supposed to be, a nice little dumper. Then again, I am working on a little cart that lets you load code into it through that dongle.. might as well add some code that runs from RAM that dumps the cart.

Ah, you are making a cart too -- on my devcart I mapped a FT245 chip to memory to get higher throughput, you can use /TIME for that. But what you came up with is a cool application of the FT232 as well.

What kind of features are planned for the cart?

[tristanseifert]

I swapped the RX/TX lines (for great justice) and also wired 2 of the I/O pins to the 2 left-over inputs I had on the chip that would allow bit-banging. The other two lines on the connector I tied together so that software would be able to detect if the dongle thing is plugged in or not. (And also if a controller is plugged in - if the input line there goes high without the output being set to high, someone is screwing around.)

I wouldn't connect the I/O pins directly together like that (pins 1,2, and then RI to pin 7) because if the pins get programmed as an output you'll get a conflict and there's a risk for damage. I'd put series resistors in there, like 4.7K for example (one between 1,2 and one between RI and 7). It's pretty cheap insurance.

That way no matter how the I/O port is set up, nothing is harmed. Otherwise it looks good!

What it's supposed to be, a nice little dumper. Then again, I am working on a little cart that lets you load code into it through that dongle.. might as well add some code that runs from RAM that dumps the cart.

Ah, you are making a cart too -- on my devcart I mapped a FT245 chip to memory to get higher throughput, you can use /TIME for that. But what you came up with is a cool application of the FT232 as well.

What kind of features are planned for the cart?

The cart isn't exactly a devcart as-is: it's a 512KByte Sega CD Backup cart with a 512-KByte flash memory to run some diagnostics on the MD. That flash will also hold a little utility to read out and manage the SCD Backup memory (yay for code executing in RAM) which will let you read that backup SRAM to your computer. That's why I'm using a dongle on the second controller port. After that, I'm going to build a 64-Megabit devcart.

My main idea for making the FT232 as a sort of dongle is mainly so it's not software and hardware specific - meaning other homebrew ROMs can also use the added capabilities of Mega Drive UART.

Right now it's designed to use a switch to choose between SCD SRAM and diagnostics mode, but I'd like to get rid of that so the code itself can switch to the SRAM access without requiring the user to throw a switch.

I still need to find some way that would allow me to map my Sega CD SRAM in at the same time as my flash so I don't need to execute code from RAM and not have background music, among other things. A sound driver just doesn't really fit into RAM, and the Z80 can't do banked reading from 68k RAM anyways, if I remember correctly.