Hyper Speed SIO loader

[ijor]

On 3/3/2021 at 3:53 PM, tschak909 said:

I hope we can fold this into FujiNet, could definitely use some help

Sure. I didn't know the FujiNet connects the SIO clock signals already. Nice!

 

Make sure the SIO clock signals are connected to the MCU hardware compare/capture timer. You also need to be able to drive the SIO actively, not with open drain. I don't see any voltage level shifter in the schematics? Anyway, feel free to contact me by PM.

[ijor]

5 minutes ago, ijor said:

Sure. I didn't know the FujiNet connects the SIO clock signals already. Nice!

 

Make sure the SIO clock signals are connected to the MCU hardware compare/capture timer. You also need to be able to drive the SIO actively, not with open drain. I don't see any voltage level shifter in the schematics? Anyway, feel free to contact me by PM.

 

I was looking at an old schematics. I see now that you are using 74LS07 buffers. That won't work. You need a bidirectional buffer for the clock signal, and you need buffers that are not permanently open drain.

 

[tschak909]

1 hour ago, ijor said:

 

I was looking at an old schematics. I see now that you are using 74LS07 buffers. That won't work. You need a bidirectional buffer for the clock signal, and you need buffers that are not permanently open drain.

 

@mozzwald ^^

[+mytek]

13 hours ago, ijor said:

You need a bidirectional buffer for the clock signal, and you need buffers that are not permanently open drain.

How would that work? I was under the impression that all SIO signals are uni-directional. And what signal would be used to switch the direction of that buffer?

[ijor]

3 hours ago, mytek said:

How would that work? I was under the impression that all SIO signals are uni-directional. And what signal would be used to switch the direction of that buffer?

 

The SIO Clock In signal is bidirectional. That's why the Pokey pin is named "BCLK". There is no hardware handshake. It is an output in async mode, and it is an input when you configure Pokey in synchronous mode.

 

Normally there is no conflict because the signal is, or is supposed to be, open drain. But yes, we must drive it actively at the higher frequencies because the resistor pull up is far too weak. So you should be careful just in case there is a software malfunction.

 

The firmware at the drive side checks that the signal is not being driven before enabling the output, and puts it back to open drain when it is not needed. A current limiting resistor might be recommended as well. Or if using a CPLD, it is possible to drive it high actively for a couple of cycles only. And then when the signal should be already high, tristate it and let the pull up maintain the voltage. It is even possible to perform the same procedure by software with those MCUs that have a separate programmable I/O processor.

Edited March 8, 2021 by ijor

[+mytek]

Thanks @ijor for the very complete explanation. Didn't realize the line could reverse direction, pretty cool stuff.

[mozzwald]

18 hours ago, ijor said:

Sure. I didn't know the FujiNet connects the SIO clock signals already. Nice!

 

Make sure the SIO clock signals are connected to the MCU hardware compare/capture timer. You also need to be able to drive the SIO actively, not with open drain. I don't see any voltage level shifter in the schematics? Anyway, feel free to contact me by PM.

 

18 hours ago, ijor said:

I was looking at an old schematics. I see now that you are using 74LS07 buffers. That won't work. You need a bidirectional buffer for the clock signal, and you need buffers that are not permanently open drain.

FujiNet 1.0 has no buffer or level shifter and only series resistors connecting SIO to the esp32. Both clock lines are connected to IO pins that can be used with the esp32 ADC. Is that sufficient to get this working on 1.0 hardware?

[ijor]

1 hour ago, mozzwald said:

 

FujiNet 1.0 has no buffer or level shifter and only series resistors connecting SIO to the esp32. Both clock lines are connected to IO pins that can be used with the esp32 ADC. Is that sufficient to get this working on 1.0 hardware?

Hi,

 

I'm not very familiar with the Fujinet hardware, neither with the ESP32, but yes, seems it should work. I understand that ESP32 has a full GPIO matrix, so that you can drive any pin with the PWM compare timers, right? Because you need to drive SIO signals accurately, and you can't use an UART. The PWM should allow you to generate arbitrary waveforms, which I understand it does.

 

The only problem I see is the 5V tolerant issue. I understand that the ESP32 is not 5V tolerant. But I guess you have already been using it like that, directly without level shifter, and the chip didn't blew up. But note that here is a bit more problematic. Since we are driving these signals actively, not open drain, you are actually injecting back power from the 5V pullups on the computer to the ESP32 (3V) power. The pullups are rather weak, so the current should be low. But can't say if it is ok or not for the ESP32. Or you always used push pull drivers?

[mozzwald]

2 minutes ago, ijor said:

I understand that the ESP32 is not 5V tolerant.

Actually, the esp32 IS 5V tolerant for IO but must be powered by 3v3 (per the Espressif CEO). I tried to go the 'cheap' route with fujinet 1.0 and skip using a level shifter or buffers until we had problems with other devices on the bus.

 

10 minutes ago, ijor said:

I understand that ESP32 has a full GPIO matrix, so that you can drive any pin with the PWM compare timers, right?

Not all the pins can be used for every function, but most are muxable. We already use PWM for CLOCKIN to set the MIDI baud rate for networked MIDIMaze. I checked and the pin we use for CLOCKOUT can be setup for PWM also.

 

 

[tmp]

13 minutes ago, mozzwald said:

Actually, the esp32 IS 5V tolerant for IO but must be powered by 3v3 (per the Espressif CEO).

i remember him saying that about esp8266, does it apply to esp32 as well?

[tschak909]

1 minute ago, tmp said:

i remember him saying that about esp8266, does it apply to esp32 as well?

Yes.

-Thom

[mozzwald]

2 minutes ago, tmp said:

i remember him saying that about esp8266, does it apply to esp32 as well?

Yes. In the same facebook post someone had asked if it applied to esp32 and he confirmed it does

 

[ijor]

20 minutes ago, mozzwald said:

Actually, the esp32 IS 5V tolerant for IO but must be powered by 3v3 (per the Espressif CEO)

Good to know. But again, note that even if it's 5V tolerant, it might not tolerate back current. These are two different things because it needs protection at the output pads, and not just at the inputs.

 

Quote

Not all the pins can be used for every function, but most are muxable. We already use PWM for CLOCKIN to set the MIDI baud rate for networked MIDIMaze. I checked and the pin we use for CLOCKOUT can be setup for PWM also.

 

You need to drive the output data signal (SIO DATA IN) as well. It can't be driven by a simple UART.

 

Last thing I forgot. In some cases the computer outputs are very glitchy. That could be a problem for measuring the clock phases. In my case the MCU I used has digital glitch filters that solved the issue.

[BillC]

On 3/8/2021 at 1:44 PM, ijor said:

The SIO Clock In signal is bidirectional

If the SIO CLOCK IN signal is bi-directional why does the SIO pinout also list a CLOCK OUT signal on pin 2?

 

CLOCK IN is on pin 26 and CLOCK OUT is on pin 27 of POKEY.

Edited March 11, 2021 by BillC

[Rybags]

I'd say likely in the Synchronous mode the input clock is used to determine Pokey's transmission rate but the output clock state change is used by the external device as reference to when to sample the output, so they'd be out of phase somewhat.

[ijor]

5 hours ago, BillC said:

If the SIO CLOCK IN signal is bi-directional why does the SIO pinout also list a CLOCK OUT signal on pin 2?

CLOCK IN is on pin 26 and CLOCK OUT is on pin 27 of POKEY.

 

CLOCK IN is bidirectional and the clock frequency can be used for receive data (to the computer) or to transmit data (from the computer). CLOCK OUT always outputs the transmit clock.

 

You might argue that this is a bit of over engineering. But this allows a simultaneous full duplex communication with different receive and transmit bitrates. Guess this feature was never used, until now I'm actually using this feature although not exactly for that purpose, but for determining the phase alignment of the clocks.

[mr-atari]

Warp 6, nice ?

I didn't came faster then 444 kb/s

That is with A/C/E and with checksum.

No block mode though.

 

Grtz!

[ijor]

2 hours ago, mr-atari said:

Warp 6, nice ?

I didn't came faster then 444 kb/s

 

There is no fundamental difference between PHI2/4 (~447 KHz) and PHI2/3 (~596 KHz) except that at PHI2/3 is much harder to reliably phase align the clock with pure software (see the technical thread for details).