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

[Huge]

But that needs a custom cable, while rca -> jack is pretty damn common.

[HardWareMan]

How about to use video for dumping? For example, every 2 frames build something like QR code with tiles 8x8 (or even 4x4 - it is easy to implement), and set the computer just to record video via the TV tuner. Then we need just extract data from the video frames. Speed ​​will be incredible, and the implementation cheap! What you think about it?
In the H40 mode we have 40x24 symbols. This gives us 40 * 24 = 960 bits of information. In 60Hz NTSC mode we have 30 fields per second and in 50 Hz PAL - 25 fields per second. This means that we will get stream of 960 * 30 = 28 800 bits per second with NTSC and 24 000 bits per second with PAL. If we use each half field, the speed is doubled, but the TV tuner like to do some deinterlacing. But we can use 4x4 tiles, and the rate will increase by four, becoming 115200 and 96 000 bits per second. Not bad, eh?
We can try to write the code and see how it would work.

[tristanseifert]

How about to use video for dumping? For example, every 2 frames build something like QR code with tiles 8x8 (or even 4x4 - it is easy to implement), and set the computer just to record video via the TV tuner. Then we need just extract data from the video frames. Speed ​​will be incredible, and the implementation cheap! What you think about it?
In the H40 mode we have 40x24 symbols. This gives us 40 * 24 = 960 bits of information. In 60Hz NTSC mode we have 30 fields per second and in 50 Hz PAL - 25 fields per second. This means that we will get stream of 960 * 30 = 28 800 bits per second with NTSC and 24 000 bits per second with PAL. If we use each half field, the speed is doubled, but the TV tuner like to do some deinterlacing. But we can use 4x4 tiles, and the rate will increase by four, becoming 115200 and 96 000 bits per second. Not bad, eh?
We can try to write the code and see how it would work.

Well, then you have the issue of needing to have a TV tuner that's pretty damn accurate (probably needs to use RGB or Composite) and that can do 50/60 fps. Not everyone has a TV tuner either.

The CPU time needed to do this would probably quite insane, and I doubt that most capture cards are going to be able to not 'blur' the pixels together. I'm sure with some crazy algorithms we could make something work, but I still think that if we somehow abused the serial UART things to use one to send the upper and the other to send the lower byte, we'd get a nice reliable 4800bps of speed.

Then again, you could probably just as easily implement something to dump a cart using an FPGA to USB in seconds.

[Charles MacDonald]

Get three RS-232 (TTL) to USB adapters, and output data on all three joystick ports at the same time (or two if you have a Gen 2/3) to your PC.

Don't forget to lift the VCLK pin from the I/O chip and connect it to the 53 MHz oscillator instead, for super turbo triple serial communication.

[tristanseifert]

Get three RS-232 (TTL) to USB adapters, and output data on all three joystick ports at the same time (or two if you have a Gen 2/3) to your PC.

Don't forget to lift the VCLK pin from the I/O chip and connect it to the 53 MHz oscillator instead, for super turbo triple serial communication.

Now that's blast processing! =P

How many baud would one be able to get with this? I assume all the timing for the serial ports on the MD is done in software, since there probably isn't a FIFO on hardware level.

I'm assuming that the MD would use +5V for a 1, and GND for 0 on the serial data lines, correct?

[Charles MacDonald]

How many baud would one be able to get with this? I assume all the timing for the serial ports on the MD is done in software, since there probably isn't a FIFO on hardware level.

I wasn't really serious.

The Genesis does have hardware support for serial communications, you have three independent channels but there's only four speeds and 4800 bps is the fastest. Nothing used it except for the modem peripheral.

You could use all three at once though. There is no TX or RX FIFO, so you have to read data quickly enough so that new data doesn't overwrite the old byte. But at such a slow speed it is likely not a problem.

I'm assuming that the MD would use +5V for a 1, and GND for 0 on the serial data lines, correct?

Yeah. If you want to interface it to a regular PC serial port, you need a level shifter like the MAX-232. It's pretty easy to use. There are also USB to serial converters that accept TTL level inputs that would work here.

You can also use the serial connection to link multiple consoles together. I made a null modem cable to connect port A to port B with RXD and TXD swapped, so the Genesis could talk to itself -- this was a handy way to verify how the serial functions worked.

EDIT:

Since the I/O chip is programmable you could "bit bang" the serial data yourself. This would take a lot of CPU time and I don't know what kind of maximum transfer rates you could get.

I doubt you could go substantially faster than the hardware serial speeds and the CPU wouldn't be available to do anything else. But that's an option.

[Chilly Willy]

The video out to a frame grabber looks interesting, but as mentioned, not everyone has a frame grabber. I guess that's why they went with audio out - as Huge mentioned, audio cables are cheap and common, and virtually every PC out has at least one audio input. Use FSK for the data and you'll get slow data transfers to almost any PC cheap.

[tristanseifert]

How many baud would one be able to get with this? I assume all the timing for the serial ports on the MD is done in software, since there probably isn't a FIFO on hardware level.

I wasn't really serious.

The Genesis does have hardware support for serial communications, you have three independent channels but there's only four speeds and 4800 bps is the fastest. Nothing used it except for the modem peripheral.

You could use all three at once though. There is no TX or RX FIFO, so you have to read data quickly enough so that new data doesn't overwrite the old byte. But at such a slow speed it is likely not a problem.

Is all the timing for this done in software or is there a special register one sets in the IO chip to set the baud rate one wants? I haven't been able to see much docs on it beyond the address where to write/read the data from.

Edit: I'm a complete idiot. Somehow, I managed to read the pages before the information about baud rate, but ignore the pages I needed. What is wrong with me..

I'm assuming that the MD would use +5V for a 1, and GND for 0 on the serial data lines, correct?

Yeah. If you want to interface it to a regular PC serial port, you need a level shifter like the MAX-232. It's pretty easy to use. There are also USB to serial converters that accept TTL level inputs that would work here.

Seeing as the FT232 (a UART<->USB converter) is a 5V part, would I be able to slap that into a little male DB-9 connector's plastic box enclosure thing and somehow power it off of the MD? I don't have a pinout handy right now, but I'm pretty sure I can get +5V on the controller port somewhere.

You can also use the serial connection to link multiple consoles together. I made a null modem cable to connect port A to port B with RXD and TXD swapped, so the Genesis could talk to itself -- this was a handy way to verify how the serial functions worked.

EDIT:

Since the I/O chip is programmable you could "bit bang" the serial data yourself. This would take a lot of CPU time and I don't know what kind of maximum transfer rates you could get.

I doubt you could go substantially faster than the hardware serial speeds and the CPU wouldn't be available to do anything else. But that's an option.

Hmm, never read anything about the IO chip being programmable. By programmable do you mean I can 'load code' into it to make it do different things than what Sega intended it to?

[Charles MacDonald]

Yeah the S-Ctrl registers have the speed setting bits in them.

Seeing as the FT232 (a UART<->USB converter) is a 5V part, would I be able to slap that into a little male DB-9 connector's plastic box enclosure thing and somehow power it off of the MD? I don't have a pinout handy right now, but I'm pretty sure I can get +5V on the controller port somewhere.

Yes, that's totally doable. Just hook up +5V, ground, and the TXD and RXD pins and you are good to go. You don't need to worry about the other modem-centric signals the FT232 has.

I actually have a FT2232 (dual channel FT232) handy, so I could test how feasible this is. But I can't see why it wouldn't work.

Hmm, never read anything about the IO chip being programmable.

I mean you can freely set the pin's output level and direction for each pin for each port using the Data and Ctrl registers. So in software you could emulate a serial protocol or whatever other scheme that was desired. It's very flexible in that regard.

[TmEE co.(TM)]

4bit parallel controller port arrangement would give at least 250000baud speeds

[tristanseifert]

Yeah the S-Ctrl registers have the speed setting bits in them.

Seeing as the FT232 (a UART<->USB converter) is a 5V part, would I be able to slap that into a little male DB-9 connector's plastic box enclosure thing and somehow power it off of the MD? I don't have a pinout handy right now, but I'm pretty sure I can get +5V on the controller port somewhere.

Yes, that's totally doable. Just hook up +5V, ground, and the TXD and RXD pins and you are good to go. You don't need to worry about the other modem-centric signals the FT232 has.

I actually have a FT2232 (dual channel FT232) handy, so I could test how feasible this is. But I can't see why it wouldn't work.

Hmm, never read anything about the IO chip being programmable.

I mean you can freely set the pin's output level and direction for each pin for each port using the Data and Ctrl registers. So in software you could emulate a serial protocol or whatever other scheme that was desired. It's very flexible in that regard.

Ah, yeah. I've read over the document over a little more careful and I'm whipping up a little schematic to do this, but I'm sorta stuck. The document says that both RxD and TxD are on TL, and I have no idea what pin that is. I'm guessing that image goes in the pinout order, and since pin 5 is power (directly after right) I'm assuming that's the pin for button 1. Other things however don't make as much sense on that diagram - It'd be awesome if you could clear that up a little for me.

4bit parallel controller port arrangement would give at least 250000baud speeds

The idea of a parallel bus is a good idea - but then you'd need some adapter that'd convert that parallel into something a PC can use (USB, etc) but converting to USB shouldn't be an issue with some logic chip and a FT232. You could use the parallel port, but they're basically dead.

Also, is that figure of yours just one if the MD isn't doing anything else, such as reading from a cartridge or something?

Another random idea popped into my mind - what if one used the Sega CD link cable and just loaded code to do this into the Mega Drive's RAM?

[Charles MacDonald]

Ah, yeah. I've read over the document over a little more careful and I'm whipping up a little schematic to do this, but I'm sorta stuck. The document says that both RxD and TxD are on TL, and I have no idea what pin that is.

The image has an error, it's correct in the S-Ctrl register description on the next page. Cross-referenced with the schematics:

Serial output (TXD) is on TL (pin 6 of the DB9 connector)
Serial input (RXD) is on TR (pin 9 of the DB9 connector)

This leaves TH, D3-D0 free for whatever you'd like.

I'm guessing that image goes in the pinout order, and since pin 5 is power (directly after right) I'm assuming that's the pin for button 1. Other things however don't make as much sense on that diagram - It'd be awesome if you could clear that up a little for me.

I'd just go by the schematics, they are accurate:

http://cgfm2.emuviews.com/img/mega1.gif
http://cgfm2.emuviews.com/img/mega2.gif

[tristanseifert]

Ah, yeah. I've read over the document over a little more careful and I'm whipping up a little schematic to do this, but I'm sorta stuck. The document says that both RxD and TxD are on TL, and I have no idea what pin that is.

The image has an error, it's correct in the S-Ctrl register description on the next page. Cross-referenced with the schematics:

Serial output (TXD) is on TL (pin 6 of the DB9 connector)
Serial input (RXD) is on TR (pin 9 of the DB9 connector)

This leaves TH, D3-D0 free for whatever you'd like.

I'm guessing that image goes in the pinout order, and since pin 5 is power (directly after right) I'm assuming that's the pin for button 1. Other things however don't make as much sense on that diagram - It'd be awesome if you could clear that up a little for me.

I'd just go by the schematics, they are accurate:

http://cgfm2.emuviews.com/img/mega1.gif
http://cgfm2.emuviews.com/img/mega2.gif

Thanks for clearing that up for me. From what I've read, I would get an interrupt whenever a byte is available in the receive register. Would this be a level 2 interrupt as triggered by external interrupts, like on a light gun?

How many cycles could the 68k interrupt for that possibly take up and still be able to receive a steady stream of bytes at 4800 baud? (That'd be 600 bytes/interrupts per second..)

edit:I drew up a quick little schematic and which is hopefully correct - anyone see any screwups I may have made?

[Charles MacDonald]

interrupt whenever a byte is available in the receive register. Would this be a level 2 interrupt as triggered by external interrupts, like on a light gun?

Right, so you couldn't use light guns and serial I/O at the same time without some care. But you don't have to use interrupts and can just poll the status flags directly to free up the interrupt. I guess you should do whatever works best for your application.

How many cycles could the 68k interrupt for that possibly take up and still be able to receive a steady stream of bytes at 4800 baud? (That'd be 600 bytes/interrupts per second..)

Not much, you are just reading the incoming data register and storing it to RAM using a pointer, maybe into a ring buffer or something.

edit:I drew up a quick little schematic and which is hopefully correct - anyone see any screwups I may have made?

Are you connecting the USB +5V line to the Genesis +5V using D1?

I wouldn't, because this will power the Genesis through the +5V pin and possibly damage the 7805 as well as defeating the reset circuit.

Isolate the the two +5V sources and either power everything from the USB connector or from the Genesis only. The grounds should be common between both though.

Also you actually want to cross up the TXD and RXD lines; the TXD output of the Genesis goes into the RXD input of the FT232, and the RXD input of the Genesis comes from the TXD output of the FT232.

To see this, check out the FT232 datasheet. TXD is an output, and TXD on the Genesis is an output, so they can't match up -- likewise for RXD. Just one of those funky quirks of serial stuff.

Since you have those spare outputs on the FT232, you could always connect them to the remaining I/O pins (TH, D3-D0) through some series resistor. Not sure what for, but more functionality can't hurt and you may invent some complex protocol that needs the extra I/O.

[tristanseifert]

interrupt whenever a byte is available in the receive register. Would this be a level 2 interrupt as triggered by external interrupts, like on a light gun?

Right, so you couldn't use light guns and serial I/O at the same time without some care. But you don't have to use interrupts and can just poll the status flags directly to free up the interrupt. I guess you should do whatever works best for your application.

How many cycles could the 68k interrupt for that possibly take up and still be able to receive a steady stream of bytes at 4800 baud? (That'd be 600 bytes/interrupts per second..)

Not much, you are just reading the incoming data register and storing it to RAM using a pointer, maybe into a ring buffer or something.

edit:I drew up a quick little schematic and which is hopefully correct - anyone see any screwups I may have made?

Are you connecting the USB +5V line to the Genesis +5V using D1?

I wouldn't, because this will power the Genesis through the +5V pin and possibly damage the 7805 as well as defeating the reset circuit.

Isolate the the two +5V sources and either power everything from the USB connector or from the Genesis only. The grounds should be common between both though.

Also you actually want to cross up the TXD and RXD lines; the TXD output of the Genesis goes into the RXD input of the FT232, and the RXD input of the Genesis comes from the TXD output of the FT232.

To see this, check out the FT232 datasheet. TXD is an output, and TXD on the Genesis is an output, so they can't match up -- likewise for RXD. Just one of those funky quirks of serial stuff.

Since you have those spare outputs on the FT232, you could always connect them to the remaining I/O pins (TH, D3-D0) through some series resistor. Not sure what for, but more functionality can't hurt and you may invent some complex protocol that needs the extra I/O.

My updated schematic is right here. 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've also gotten rid of the diode - hopefully it's all correct. I should probably stop being all anal about this and leave this thread alone to 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.