HomeForumsWhat's newResources 
 
 
Saturn USB Mod
Knight0fDragon - Jun 13, 2025

 1  2  Next> 

  Knight0fDragon Jun 13, 2025
I am in the process of revamping antime's USB Cart to not be tied to the CS0 line as well as not being tied to any cart in particular. The purpose of this is to allow us to have something more useful than the serial connector.

My current goal for it is to allow us to play Netlink games as well as having access to extended RAM. (I already have Netlink play working with the current USB cart.)

When all is said and done, this mod should be able to be done right on the Saturn's MB, so any cart can be added. This will be especially useful for my SF3 online project as access to the memory card means more saves, and access to 4MB RAM means more online data being stored instead of having to retransfer.

Currently it is planned to work off of the CS2 line using the area that Netlink uses to do its transfers.

Current line of thinking is this:

4 to 16 Demux
A12 must be low.
If A12 is high, then all pins are high, disabling both chips ability to write.

CS2 must be low.
If CS2 is high, then all pins are high, disabling both chips ability to write.

If Write is low, then FT245RL(FIFO) is the only path.

If Read is low and A12 is high, then 74HCT245 (Flags) is the only path
If Read is low and A13 is high, then FT245RL (FIFO) is the only path.
Else both chips ability to read are disabled.

0x25802XXX is used for Flags
0x25803XXX is invalid.
0x25804XXX is used for FIFO
There is mirroring as only A13 and A14 are checked, so as long as one of those is high, you will get results.
Should be safe with Netlink as pin 12 is required to be high.
Should be safe from CS2 as it falls within the allowed range like Netlink does






Now I am not a hardware guy, so I am sure there may be things I am overlooking.


Added a new pic mapping the 4MB cart pins since I am going to use this for now.



  Solitario Jun 13, 2025
It will be wonderful to be able to play Saturn Bomberman online and other games, unfortunately my country has communist policies and prevented the entry of the components that were missing from USB Dev Cart, I ended up without the components, they are really difficult to find.

 Knight0fDragon Jun 13, 2025

Solitario said:

What chips are not allowed? You do not need the parts that deal with the game storage, you just need the parts that handle the USB

 Solitario Jun 13, 2025

Knight0fDragon said:

So I only need this components U8, 74LS154, 74HCT245 ?

 Knight0fDragon Jun 13, 2025
I am not sure, what I posted are just notes until the parts come in.

From what I can tell, only the two 74hct245, the 74hct138, and the ft245RL are the only major components needed. The 74HCT32 and the SST39SF010A might not be. So if you can't get the components, you may be able to make USB carts that have no menu on them.

 Knight0fDragon Jun 27, 2025
Finally got all the parts needed for this, next step is to assemble.

 Waterfuell Jun 28, 2025
Good job.


Knight0fDragon said:


F245RL Write input is active High, so you should invert 74LS154 output.

For full compatibility with all cartridges, consider examining the function pins FC0 and FC1. These are used for IRQ acknowledgment in the Netlink and for RAM refresh in the RAM cartridge. As I recall, they share the data and address bus when their respective functions are active.

 Knight0fDragon Jun 28, 2025

Waterfuell said:

Doc says it writes to the transfer buffer when it goes from high to low. Wouldn't that mean I need to make it low to send the data.

Not sure if I need to worry about the IRQ lines as I do not want the USB to be affected by it, and the address should disable it.

Netlink's XBand library does not use the IRQ, only the dialup portion does.

 Waterfuell Jun 29, 2025

Knight0fDragon said:


Maybe it means the data is not written to the buffer until the write line goes low, or on the falling edge of the write signal. But to start the write cycle, you need to set the signal high first. Try to look for a timing diagram in the documentation.


Knight0fDragon said:


Maybe you're right , you are controlling the CS, WR, and RD signals, which are good indicators to determine whether the bus is being used in read or write mode.

 antime Jun 29, 2025
Are you sure the decoding is correct? This is what you have:
FIFO write50101
FIFO read91001
Flags read101010
This is what I think they should be:
FIFO write101010
FIFO read91001
Flags read50101

Placing PWREN on bit 7 is a small wart - because of the automatic sign extension it means you can't do MOV.B R0, .../TST #PWREN, R0, you have to add an EXTU.B R0, R0 in between. It really doesn't matter, but it still annoys me that I didn't think of it at the time.

 antime Jun 29, 2025

Waterfuell said:

The decoder has inverted outputs, i.e. they idle high.

 antime Jun 29, 2025
Oh, don't forget the quirk that the SCU always does a 32-bit read, regardless of the access size (it is documented, but I forget in which manual). That's why I had to add the OR with A0 for the FIFO read to prevent it from being read twice for each actual read instruction.

 Knight0fDragon Jun 30, 2025

antime said:



I think I read this table backwards. so for now I can flip the order of the pins while I test this out, and update the drawing later.








antime said:

Good call, so I should move it to bit 6.

 Knight0fDragon Jun 30, 2025

antime said:

so what you are saying is 2 reads are always done



When you say A0, did you mean A1? I notice on your KiCAD files your address lines does not match the service docs, and the actual A0 is missing. Should I OR A1 and A12 together before it goes to E1?

Edit:
I should OR A1 and RD together.

 antime Jun 30, 2025

Knight0fDragon said:

It's been a while since I looked at this, but the A-bus is a 16-bit bus and the addresses are word addresses so you have to mentally shift SH-2 addresses to map them into the A-bus space. When writing to the bus, the /AWR0 and /AWR1 lines select which bytes of the word should be written. There's only one read signal, because the reader can select the bytes itself.

I guess only using /AWR0 is another buglet in my design - when writing to the flash you must write in word units, you can't separately program the halves.

 Knight0fDragon Jun 30, 2025

antime said:

The flash portion is one I am actually not interested in, so I am guessing I am good on this part as the FT245RL is only written in bytes.

I am guessing A0 then in this case (the service manual schematic) is always going to be low because of how the SCU is reading and writing.

 antime Jun 30, 2025

Knight0fDragon said:

Because SCU is reading two consecutive words, AA0 (A-bus address line zero) will be low and high. I don't know if it reading a 32-bit aligned long word, or just ADDR and ADDR+1.

 Knight0fDragon Jun 30, 2025

antime said:

I am pretty sure what you are calling AA0 is AA1

Your pinout:



vs Sega Service Manual.



In this case, AA0 is always low as it is always 16bit reads and writes, and AA1 is what flip flops from 0 and 1 because of it being 32 bit reads.

So I need to disable reading when AA1 is high to prevent the second 16bit reading. Also, no mental shifting is necessary as the address lines should line up.

 Waterfuell Jun 30, 2025

Knight0fDragon said:



Knight0fDragon said:


Seeing that all my assumptions have been wrong, I don’t really dare to give an opinion XD. Still, you should take a look at the following post from srg320

A-Bus CS2...

It seems that with A19 you can define a memory range where the double read doesn’t occur, or at least that’s what I think I understood.

 Knight0fDragon Jun 30, 2025

Waterfuell said:

This explains why the AA19 pin is not on Netlink or XBAND modems, but AA19 is used! So I should be able to avoid said OR.

 1  2  Next>