HomeForumsWhat's newResources 
 
 
USB dev cart project
antime - Mar 24, 2012

 1  2  3  ...  8  Next> 

  antime Mar 24, 2012
Here's... the first draft schematic for a flash cart with a built-in USB port. It's got 256K of flash and an FT245R USB FIFO. One thing I'm a bit wary of is that the FIFO status lines are connected directly to the bus buffer. Would it be better if they were latched somehow, or routed via a Schmitt trigger buffer or something? The design also assumes ideal circuits with no switching delays etc.

Unfortunately the design requires a modchip to bootstrap the flash memory, but there is a jumper for reflashing the cart in case you write a bad firmware to it. Comments welcome, the bus control line logic probably has some errors in it.

EDIT:
Quick link to the cartridge page: http://www.iki.fi/~antime/sega/usbcart/usbcart.html
Quick link to the project files on github: https://github.com/andersm/usbcart

 ExCyber Mar 24, 2012
I've only skimmed it so far, but a few things do confuse me a little:

Why are U11 and U13 are necessary (it looks like they're supposed to inhibit read/write signals to deselected chips, which should ignore those signals anyway)?

How is DATA0_CE supposed to work? (it seems like you want FLASH_CE AND FIFO_CE, not FLASH_CE OR FIFO_CE)

edit: upon further reflection, I'm not sure you actually need to decode the '245 enables at all. Would there be any harm in just using /CE0 to enable them?

Why not use a '138 for address decoding instead of basically rolling your own decoder out of inverters + triple-input OR gates?

 Chilly Willy Mar 24, 2012
You might consider the option of 4MB of ram on the cart so that you can use it like a ram cart as well as a flash cart. That would mean less swapping carts, which is vital on the Saturn since the cart connectors seem to be so flakey. Also, being able to load the 4MB of ram from the USB would be interesting from a homebrew point of view as well.

 antime Mar 24, 2012

Chilly Willy said:
You might consider the option of 4MB of ram on the cart so that you can use it like a ram cart as well as a flash cart.


That comes later, let's first see if we can make working carts at all. Adding RAM makes the whole project a lot more complex, including just sourcing the components. Plain old DRAM is a bit of a niche product these days and eg. Digi-Key lists all of two suppliers (one if you want 5V compatible parts). The DRAM interface of the Saturn is also completely undocumented, the tech note for the RAM expansion cart just says to write a value to an address located in otherwise "empty" memory to turn on the refresh.

With a readily available high-speed port the extra RAM also is a lot less interesting, as you can just stream in more data as needed. Supporting interrupts for the FIFO would be a lot more interesting, but will need some degree of hacking (the SCU documentation states it will read 16 bits in its acknowledge cycle after an interrupt has been triggered, but I have no idea how it is signalled on the bus and so on).

Since a more complex cart will require more complex logic, I had the idea of using a CPLD combined with an FT2232. One of the FT2232's interfaces would be connected to the CPLD's JTAG for programming, and with a special "first stage" bitstream you could then program the flash over the other interface. This would eliminate the need for both modchips and external device programmers, making it easier to get started. But it's still a pipe dream at this stage.

 ExCyber Mar 24, 2012
Come to think of it, having those '245 chips at all seems to be redundant (isn't everybody speaking 5V CMOS?), but I might be missing something.

As for RAM, that would probably about double the complexity of the cartridge (IIRC about half the chips in the AR4M+ are for implementing the RAM cart function), SRAM is expensive, and DRAM is a pain in the ass.

 antime Mar 24, 2012

ExCyber said:
Why not use a '138 for address decoding instead of basically rolling your own decoder out of inverters + triple-input OR gates?


Mainly because I forgot they existed, despite having used them a lot recently. I was also inspired by the Netlink modem which just uses basic gates for its interface.


  
	
	

		
		

			Come to think of it, having those '245 chips at all seems to be redundant (isn't everybody speaking 5V CMOS?), but I might be missing something.


Buffering is good for signal integrity. You could probably get away without them (except U12, the FIFO status lines are always driving), but they're cheap and shouldn't hurt.

edit: It's also groundwork for a 3.3v design, which is almost inevitable if we want to add more features later.

Rev 2.... Use an '138 for address decoding, put U12 behind U4, simpler /CS, /RD, /WR logic for buffers and flash. To play it safe, we could use just /WR0 for both halves of the bus like the Action Replay carts do. It doesn't really make the software interface any more or less complex, and we know it works.

 ExCyber Mar 24, 2012
3.3V interfacing crossed my mind, but at that point I start to lean toward plugging everything into a XC9500XL. And then I usually get carried away with the possibilities opened up by that (e.g. turning A-Bus transactions into bursts on faster 8-bit memories).

 antime Mar 25, 2012
Rev 3.... Removed all nonessential buffers, use a single write strobe for both halves of the bus.

 antime Apr 2, 2012
Rev 4... of the schematics and the PCB.... The only change to the schematics is that the operation of the jumper was reversed (bridge to disable). I tried to keep the PCB within the design rules for cheap prototype manufacturers like Seeed etc. The next step will be to send off for a few boards and parts, and if all goes well I'll package up the whole project (KiCad design files plus manufacturing documents) and put them somewhere public.

 antime Jun 2, 2012
I finally soldered up a prototype board with mixed success. While I can access both the flash and the FT245R, it seems each read will produce two A-bus accesses, possibly due to SCU errata 32 which states that all A- and B-bus reads are performed as 32-bit reads regardless of the actual CPU operation width. The effect is that only every other byte sent to the Saturn will actually be received. This can be worked around in software by sending every byte twice, but it's pretty ugly. I'm not really sure on the best way to fix this, maybe by ORing FIFO_RD# and A1? (There's an unused OR gate on the board, which would make this a relatively cheap fix.)

The other bad news is that I only get upload speeds of around 400K/s, which is much less than I hoped for (and effectively only half of that when working around the FIFO double read bug). I'll have to try and see where the bottleneck is, but some of Sega's documentation hints that the A-bus is pretty slow.

 antime Jun 3, 2012
ORing the FIFO read strobe with A0 (the bus is shifted one bit) fixed the double read issue, but the USB transfer speeds halved (since the amount of data transferred was also halved, the effective speed remained the same). Setting the SCU ASR0 register to zero doubled the transfer speed, probably by removing bus wait states configured by the ROM. Disabling A-bus refresh by setting the AREF register to zero gained 20KB/s or so, and tweaking the Saturn-side transfer code added a further 20KB/s, so I'm currently getting around 480KB/s PC->Saturn RAM transfer speeds. This is still disappointing, but it does look like it's the SH2<->A-bus interface that is the limiting factor. I have also not yet tested how the A-bus register changes affects handling the flash.

In theory the double read bug could be exploited to nearly double the transfer rate, by making sure the PC always sends an even number of bytes. With all the other changes this would be close to what you can practically achieve with full-speed USB, but I'm not really sure if it's worth the hassle.

 Chilly Willy Jun 4, 2012
None of those old console cart ports are as fast as people think they are. Even the N64 is ridiculously slow - we crank the speed of the bus to maximum for transfers from the SD card in the N64 Myth and still only get 600 to 700 KB/sec. That's not bad for reading a nibble at a time, but you'd think the N64 would have a MUCH faster cart bus. The default rate for the N64 is slllllooooooooooooowwwwwwwwww - we got maybe 50 KB/sec before we started messing with the bus timing register.

So, my point is that you're doing really well with the rates you're getting.

 cafe-alpha Jun 6, 2012
Wow, it's good to read news about your project !

When I was using SD card via second pad connector, I was proud to reach around 40KB/s transfer speed, so it would be fascinating to use a SD card on your dev cart

Here is an attempt to use a SD card instead of the USB module in your USB dev cart : usbcart-4_sdcard_v1.png...

Can you have a look at the schematics and see if it is correct or not ?

(I only have few knowledge on electronics, and never used CAD software, sorry)

Also, do you have a spare USB dev cart plain PCB for selling ?

I know it is possible to order PCB on internet, but I don't know how to produce gerber file for ordering it.

 antime Jun 6, 2012
Given how slow the cartridge port seems to be, there's probably more preferable solutions than bit-banging the data and clock lines. If you want to use discrete logic one alternative is using shift registers with parallel input/outputs, eg. a SN74ALS299 combined with some counters and latches for the control lines. However I'd probably put all the logic into a small CPLD, which would also make the board layout much simpler. The downsides of using programmable logic is figuring out which of the port pins carry suitable clock pins, and requiring a device programmer, which is the big reason I didn't use one yet (any basic FT2232 JTAG dongle should do, so it's not a huge deal).

I didn't look all that closely at your design, but using eg. the ALS logic family instead of HC should let you interface with 3.3v logic directly.

I have extra boards of the current version, but it doesn't include the double-read fix described above. Once I add the fix I'll upload both the CAD files and production documents somewhere. Ordering from Seeed Studio cost about $35 for 10 boards including shipping, and took about three weeks to delivery.

 mrkotfw Jun 8, 2012

cafe-alpha said:
Wow, it's good to read news about your project !

When I was using SD card via second pad connector, I was proud to reach around 40KB/s transfer speed, so it would be fascinating to use a SD card on your dev cart

Here is an attempt to use a SD card instead of the USB module in your USB dev cart : usbcart-4_sdcard_v1.png...

Can you have a look at the schematics and see if it is correct or not ?

(I only have few knowledge on electronics, and never used CAD software, sorry)

Also, do you have a spare USB dev cart plain PCB for selling ?

I know it is possible to order PCB on internet, but I don't know how to produce gerber file for ordering it.


Is it not working?

 mrkotfw Jun 8, 2012

antime said:
Given how slow the cartridge port seems to be, there's probably more preferable solutions than bit-banging the data and clock lines. If you want to use discrete logic one alternative is using shift registers with parallel input/outputs, eg. a SN74ALS299 combined with some counters and latches for the control lines. However I'd probably put all the logic into a small CPLD, which would also make the board layout much simpler. The downsides of using programmable logic is figuring out which of the port pins carry suitable clock pins, and requiring a device programmer, which is the big reason I didn't use one yet (any basic FT2232 JTAG dongle should do, so it's not a huge deal).

I didn't look all that closely at your design, but using eg. the ALS logic family instead of HC should let you interface with 3.3v logic directly.

I have extra boards of the current version, but it doesn't include the double-read fix described above. Once I add the fix I'll upload both the CAD files and production documents somewhere. Ordering from Seeed Studio cost about $35 for 10 boards including shipping, and took about three weeks to delivery.


How far are we from actually getting my grubby hands on one of these?

 cafe-alpha Jun 9, 2012

antime said:
Given how slow the cartridge port seems to be, there's probably more preferable solutions than bit-banging the data and clock lines. If you want to use discrete logic one alternative is using shift registers with parallel input/outputs, eg. a SN74ALS299 combined with some counters and latches for the control lines. However I'd probably put all the logic into a small CPLD, which would also make the board layout much simpler. The downsides of using programmable logic is figuring out which of the port pins carry suitable clock pins, and requiring a device programmer, which is the big reason I didn't use one yet (any basic FT2232 JTAG dongle should do, so it's not a huge deal).

I didn't look all that closely at your design, but using eg. the ALS logic family instead of HC should let you interface with 3.3v logic directly.


As re-using ICs from a past project and randomly connect wires between them is the extent of my skills in electronics, using CPLD would be too much difficult for me.

I first want to test SD card on Saturn, then, if initial project works, it is OK will try to make something better


antime said:
I have extra boards of the current version, but it doesn't include the double-read fix described above. Once I add the fix I'll upload both the CAD files and production documents somewhere. Ordering from Seeed Studio cost about $35 for 10 boards including shipping, and took about three weeks to delivery.


If possible, I would like to buy you 3 prototype boards (without double-read fix) for $15+shipping.

The reason I am interested in theses boards is that I need cart to connect to Saturn cartridge port in order to perform testing.

(It is possible to sacrifice my spare Action Replay cart, but I prefer not)

Also, since it is only for test purposes, I don't mind to cut/modify wires on your PCB in order to fix double-read problem.

If it is OK to sell PCB, please contact me by PM for payment details, etc.


mrkotfw said:
Is it not working?


I didn't tested at all : I prefer to ask to electronics experts here before damaging my Saturn

Also, I need a PCB that fits the Saturn cartridge port in order to perform any testing.

 antime Jun 10, 2012
The files are up here.... The flash tools are still missing, but they'll be up soon.

 mrkotfw Jun 10, 2012

antime said:
The files are up here.... The flash tools are still missing, but they'll be up soon.


Thanks for the link. Looks like they require a minimum of 10.

What if there is a group order?

 cafe-alpha Jun 10, 2012

antime said:
The files are up here.... The flash tools are still missing, but they'll be up soon.


Thank you very much


mrkotfw said:
Thanks for the link. Looks like they require a minimum of 10.

What if there is a group order?


I plan to order PCB and ICs, so it is possible to provide you parts for building one dev cart.

Also, I can solder ICs if you want, so please let me know if you are interested.

 1  2  3  ...  8  Next>