Saturn USB Mod

[Waterfuell]

Something curious is that the address space appears to be used to configure the behavior of CS2. It is even possible to configure wait cycles, which could be useful for increasing transfer speeds.

Post #3 in thread 'A-Bus CS2'

 

[Knight0fDragon]

so I got the 4MB cart working with the CS2 address lines and just grounding data pins. Just need to get the circuity to work.

Another question I have been asking myself is why not just place the FLAGs on the higher part of the data bus? Then I can eliminate the octal bus all together

Nevermind, the reason why I need the octal bus is because there is no other way to stop RXF and TXE from outputting on the dataline.

 

[Knight0fDragon]

so I am trying to test this using an Arduino UNO. Right now, the demux works fine, and the octal bus works fine but for some reason, the FT245BL fails (They are cheaper than FT245RL.) Is there some kind of difference between these two that is causing the circuit to fail?

 

[Knight0fDragon]

well I am able to read, but the writing is all off.

Looking at this diagram, my signal needs to stay low the moment before data pins are set. So using the decoder, it sets it to high when Saturn is not writing and low when writing.

Obviously, I tried using an inverter to correct this. When using the inverter, the data would always be sending. Then I decided to not bother using the inverter. Now the data only sends when I want, but the data pins are not properly set.

So I tried checking this on an UNO board.

Behavior was weird. I had to set the data pins prior to attempting to write, then I flipped it low, followed by high. Now things are sending on the arduino.

At this point, I am kind of stuck on what I should attempt next.

I included the UNO code in case anybody wants to see the behavior.

    digitalWrite(D0, out.rawdata.b0);
    digitalWrite(D1, out.rawdata.b1);
    digitalWrite(D2, out.rawdata.b2);
    digitalWrite(D3, out.rawdata.b3);
    digitalWrite(D4, out.rawdata.b4);
    digitalWrite(D5, out.rawdata.b5);
    digitalWrite(D6, out.rawdata.b6);
    digitalWrite(D7, out.rawdata.b7);
    
    WRVALUE = LOW;
    digitalWrite(WR,WRVALUE);
    asm volatile ( "nop":: );
    //Fetches the next byte; disables pin 9 of demux
    WRVALUE = HIGH;

 

[Waterfuell]

View attachment 11251

Doc says it writes to the transfer buffer when it goes from high to low.

Looking at the SRG320 timing diagrams, it appears that data is always set after the write signal and remains valid even after the write signal ends. This could explain the inconsistent data behavior when no inverter is used; the falling edge may occur before valid data is present.

If writes to the data buffer occur when the signal goes from high to low, and you are using an inverter, then it’s possible that unintended falling edges on the write signal are triggering writes; possibly due to noise introduced by the signal inversion.

You could try checking the connections, ensuring that the inverter IC shares a common ground with the rest of the circuit, and making sure all unused inputs of the NOT gates are in a known state; for example, by tying them to ground.

Another possibility is erratic behavior caused by Chinese clone chips. I've experienced issues before with Chinese FT232RL clones.


Edit: I've just reviewed your schematic; you're using a single NOT gate, but there are incompatible logic ICs; a 74LS output driving a 74HC input; which could also be a problem.

 

[Knight0fDragon]

ok, let me list my components here for now.

current test is with:

m74hc154b1: 4 to 16 demux
Sn74ls245n: octal bus
m74hc154b1: hex inverter

So the demux is going to the hex inverter, both of which are HC.

The octal bus should be in a disabled state when writing.


As an FYI. I also tried adding capacitors to the VCC pins, no luck.

Edit:

Ordered a 74HCT245 just in case.

Edit 2: just did m74hc154b1 to m74hc154b1 set to Y0. Worked fine. So issue may be the octal bus, or maybe enabling. Will continue testing.

Edit 3: Pin Y5 works.

edit 4: Switched octal bus over to MM74HC245AN, still same issues.

 

[Knight0fDragon]

ok redid the board, everything works correctly via uno. Will test on Saturn tmr.

Edit:

Saturn fails still. Going to have to do Saturn to UNO. Maybe there is some interference on the cart lines.