Good you replicated my issue!
Problem with waveforms, they vary at random, you have to assume "what you see" can actually be 50% worse (as it usually is)
Project: HDMI/DVI out for STFM
Re: Project: HDMI/DVI out for STFM
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Re: Project: HDMI/DVI out for STFM
So, the solution was the same capacitor you originally used to fix it, Exxos. I actually decided that the series resistors were working to prevent ringing based on my tests, so I left the capacitor off the final board design.
Fortunately it's easy to add a ceramic underneath the board. I used 20pF. This is on the 3.3v input side of the clock buffer, the 0-ohm resistor on the output side was not involved after all.
Fortunately it's easy to add a ceramic underneath the board. I used 20pF. This is on the 3.3v input side of the clock buffer, the 0-ohm resistor on the output side was not involved after all.
Re: Project: HDMI/DVI out for STFM
That "solution" wasn't a good fix.. it caused really bad ringing without a resistor..
Something must be over sensitive to the clock line. resistors will cure ringing and some noise, but on my STE booster, I had a 100R resistor in series with the schmitt buffer, but I also have 22pF on its input.. this is running around 40Mhz, for some reason it doesn't work without the 22pf. I think its just noise which causes glitches in the clock despite a schmitt buffer.. I did try without a schmitt buffer and I don't think I could get the STE to even boot.
That's the problem when you get into MHz ranges. slight capacitance or inductance in the wrong place and you can make or break a circuit. Think I did like 5 revisions of my STE booster before I got it all right
Something must be over sensitive to the clock line. resistors will cure ringing and some noise, but on my STE booster, I had a 100R resistor in series with the schmitt buffer, but I also have 22pF on its input.. this is running around 40Mhz, for some reason it doesn't work without the 22pf. I think its just noise which causes glitches in the clock despite a schmitt buffer.. I did try without a schmitt buffer and I don't think I could get the STE to even boot.
That's the problem when you get into MHz ranges. slight capacitance or inductance in the wrong place and you can make or break a circuit. Think I did like 5 revisions of my STE booster before I got it all right
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Re: Project: HDMI/DVI out for STFM
It's actually an interesting problem as I get constant resetting when using the board but have been working with Smonson this morning on running a test program that disables the vblank vector and reads the shifter's resolution registerer over and over and displays the values if they change.
After numerous resetting to get there I finally got the ST to run the program. I must say its the first time the ST has stayed solid for a while using the board for me. I had the program running for around an hour with no resets before turning it off.
This got me thinking as there must be programs that may not use vblank vector (I could be wrong) so I thought I would try out a few random programs from boot. Once I managed to get them through initial resetting that happens just after power on etc. I managed to get Goldrunner and Magic Pockets to load and they have been stable all morning and I have been quietly enjoying the clear graphics and playing the games
After numerous resetting to get there I finally got the ST to run the program. I must say its the first time the ST has stayed solid for a while using the board for me. I had the program running for around an hour with no resets before turning it off.
This got me thinking as there must be programs that may not use vblank vector (I could be wrong) so I thought I would try out a few random programs from boot. Once I managed to get them through initial resetting that happens just after power on etc. I managed to get Goldrunner and Magic Pockets to load and they have been stable all morning and I have been quietly enjoying the clear graphics and playing the games
Re: Project: HDMI/DVI out for STFM
Awesome, it's great to see someone actually able to use this thing for its intended purpose for a change
Icky, you motivated me to write a quick status update here. So, after Troed's discovery that the resetting behaviour comes from the vblank vector, when TOS reads the shifter's resolution register once per frame and checks if it's changed, I started looking for possible reasons why the value could be wrong.
That led me to notice that the 1.5K bus series resistors (on the shifter socket adapter board) may be slowing down the rise and fall times of the bus signals - I tried replacing those resistors with 0-ohm links and that seemed to square up the signals quite a bit, so I asked Troed if he would do the same modification. Unfortunately, no improvement resulted. Nevertheless, those resistors will be reduced to 100 ohms for future boards now that I'm confident that there's no bus contention.
I wrote the test program that Icky mentioned earlier today because I wanted to find out what kind of "different value" TOS is seeing from the shifter's register - and as seen from the video, it's not just a stray bit flip, it's a totally wrong value on certain reads - up to 11 bits are wrong. That seems to point away from bad signal driving behaviour and strongly towards incorrect bus timing. So I'll be investigating in that area now.
What I intend to do is put the real shifter into a test circuit that will do some register reads and measure how long it drives the data bus for.
Icky, you motivated me to write a quick status update here. So, after Troed's discovery that the resetting behaviour comes from the vblank vector, when TOS reads the shifter's resolution register once per frame and checks if it's changed, I started looking for possible reasons why the value could be wrong.
That led me to notice that the 1.5K bus series resistors (on the shifter socket adapter board) may be slowing down the rise and fall times of the bus signals - I tried replacing those resistors with 0-ohm links and that seemed to square up the signals quite a bit, so I asked Troed if he would do the same modification. Unfortunately, no improvement resulted. Nevertheless, those resistors will be reduced to 100 ohms for future boards now that I'm confident that there's no bus contention.
I wrote the test program that Icky mentioned earlier today because I wanted to find out what kind of "different value" TOS is seeing from the shifter's register - and as seen from the video, it's not just a stray bit flip, it's a totally wrong value on certain reads - up to 11 bits are wrong. That seems to point away from bad signal driving behaviour and strongly towards incorrect bus timing. So I'll be investigating in that area now.
What I intend to do is put the real shifter into a test circuit that will do some register reads and measure how long it drives the data bus for.
Re: Project: HDMI/DVI out for STFM
My board is still hooked up to my STFM on the floor if it helps... Not done anything much with it as been to busy with other things
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Re: Project: HDMI/DVI out for STFM
Well, it's obvious that the real shifter drives the data bus only for the duration of CS, which is what I originally thought.
(CS at the top, D1 at the bottom with a pulldown resistor - shifter is running at 1MHz instead of 32)
(CS at the top, D1 at the bottom with a pulldown resistor - shifter is running at 1MHz instead of 32)
Re: Project: HDMI/DVI out for STFM
Icky has generously donated his time to investigate the weird register reading behaviour with his oscilloscope. This image collects the most important signals into one graphic. I cannot, for the life of me, see where the problem is coming from or how it's possible. If anyone has any theories I'd love to hear them.
For each scope screen, the top trace is /CS, and is the common factor keeping all these screenshots synchronised with each other.
The test program from a few posts above is running, and it just sits in a loop reading register 0xFF8260 (with vblank vector disabled so that TOS doesn't interfere). So each time CS is low, that's the program reading the shifter's resolution register. The value actually being output on the bus by the shifter is all zeroes.
My (unconfirmed) understanding of how the register is read is this:
My observations:
For each scope screen, the top trace is /CS, and is the common factor keeping all these screenshots synchronised with each other.
The test program from a few posts above is running, and it just sits in a loop reading register 0xFF8260 (with vblank vector disabled so that TOS doesn't interfere). So each time CS is low, that's the program reading the shifter's resolution register. The value actually being output on the bus by the shifter is all zeroes.
My (unconfirmed) understanding of how the register is read is this:
- The MMU asserts /CS to get the shifter to drive the data bus
- The MMU then raises, then lowers LATCH which allows the 74LS373 latch ICs to latch the values that it sees on D0-D15. Setup and hold time for the '373s is 20ns, which is satisfied.
- At some point later, the MMU asserts RDAT, (which is /OE for the '373s, output enable) to drive the same signals onto the 68000 bus to be read.
My observations:
- The latching behaviour is only level-sensitive, so high-frequency noise around the transitions shouldn't cause glitches
- The values that are being read seem very non-random, in the sense that either reads the whole word perfectly, or else it reads it with 8-12 wrong bits. It never reads just one wrong bit here and there. The pattern of bits is also very uniform, e.g. 0xb479 comes up a lot (see video and screenshot posted by Icky above)
- The reason I don't think it's clock related is that both Icky and Troed have the same behaviour, and Troed is using a totally different clock.
Re: Project: HDMI/DVI out for STFM
Where's the test program ?
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.