Project: HDMI/DVI out for STFM

General discussions or ideas about hardware.
troed
Software Moderator
Software Moderator
Posts: 471
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed » Sun Sep 16, 2018 12:11 pm

I'm not less confused.

Fatter GND and resistor on VSYNC made no difference. So just to rule out the possibility that the FPGA is fine and _both_ my doubleST and 520ST are weird I pulled up a non-recapped pure stock-as-stock-can-be 1040 STF and put it in there.

Booting without a disk in the drive, or with the floppy disconnected, first gave me a similar impression to the 520. Reset pretty soon after boot, and the the VSYNC LED on the FPGA starts flashing.

But if I insert an original disk (Closure, is what I had close by) there are no resets. The demo runs fine (bar the bitplane and pixel errors in the FPGA emulation that I think can be fixed easily).

If I boot without the drive connected and get to the desktop then that has pixel errors compared to on the 520 where it's perfect, so it's not the case of the 1040STF being "better" at running the FPGA. Now I'll get back to the 520 and connect a floppy drive to it ... haven't tested with that at all before.

(Closure gets rid of TOS directly after the boot sector has loaded the first screen - so this problem might be due to something TOS does ... ??)

troed
Software Moderator
Software Moderator
Posts: 471
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed » Sun Sep 16, 2018 12:25 pm

Wow.

It absolutely is. Connected up an HxC slim to my beautiful internal floppy header in the 520ST and booted ... Closure. No resets at all.

So previously I had looked at /MONOMON with my LA to see if it triggered - since one of the few ways an ST resets cleanly is when TOS detects a mono monitor having been plugged into the monitor port. There's no way I know of for the Shifter to induce that, but hey ...

And of course, a boot sector demo like Closure disables TOS /MONOMON check. So I guess I'll have to think hard about that theory again.

(Removing power from the HxC slim is enough for the 520ST to then start with the spurious resets on the next boot again)

User avatar
exxos
Site Admin
Site Admin
Posts: 5001
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Project: HDMI/DVI out for STFM

Post by exxos » Sun Sep 16, 2018 12:29 pm

odd.. maybe the FPGA is really sensitive to power rail spikes from the floppy drive or something ?

EDIT:
If you can do a boot sector which would keep the floppy motor turned on right from power up.. maybe that would give some clues ?
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
Smonson
Posts: 211
Joined: Sat Oct 28, 2017 10:21 am

Re: Project: HDMI/DVI out for STFM

Post by Smonson » Sun Sep 16, 2018 1:54 pm

troed wrote:
Sun Sep 16, 2018 12:25 pm
Wow.

It absolutely is. Connected up an HxC slim to my beautiful internal floppy header in the 520ST and booted ... Closure. No resets at all.

So previously I had looked at /MONOMON with my LA to see if it triggered - since one of the few ways an ST resets cleanly is when TOS detects a mono monitor having been plugged into the monitor port. There's no way I know of for the Shifter to induce that, but hey ...

And of course, a boot sector demo like Closure disables TOS /MONOMON check. So I guess I'll have to think hard about that theory again.

(Removing power from the HxC slim is enough for the 520ST to then start with the spurious resets on the next boot again)
Is it possible that the difference is that when running with the FPGA connected, there was no plug in the video out socket, while when you were running an original shifter you always had one plugged in? Perhaps the MONOMON pin could be floating.

User avatar
Smonson
Posts: 211
Joined: Sat Oct 28, 2017 10:21 am

Re: Project: HDMI/DVI out for STFM

Post by Smonson » Sun Sep 16, 2018 3:10 pm

Smonson wrote:
Sun Sep 16, 2018 1:54 pm
Is it possible that the difference is that when running with the FPGA connected, there was no plug in the video out socket, while when you were running an original shifter you always had one plugged in
Hmm, that doesn't make enough sense. I should have thought about it for longer. The plug only grounds the pin for mono, and you weren't using mono mode.

troed
Software Moderator
Software Moderator
Posts: 471
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed » Sun Sep 16, 2018 8:07 pm

Finally, this mystery has been solved. A clue was indeed in why sometimes after reset the videomode wasn't correct.

The resets were caused by TOS detecting a change to mono. A bootsector that immediately disables the TOS reset vector at $46e (resolution change vector) stops the 520ST (where I did the test just now) from resetting.

However, now I can see that if I boot to desktop (low) and then switch to medium I had an immediate "force resolution switch" back to low. That is, not a clean resolution switch by GEM but what you get if you poke at $ff8260 directly.

So, conclusion: The FPGA Shifter causes $ff8260 to respond with wrong values, or even, fluctuating values. At least the prototype I have :)

(... and this is where my own knowledge is a bit lacking, but I have seen this described as the Shifter "owning" that register, as in, holding its contents and being responsible for outputting that data when that memory address is accessed)

User avatar
exxos
Site Admin
Site Admin
Posts: 5001
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Project: HDMI/DVI out for STFM

Post by exxos » Sun Sep 16, 2018 9:40 pm

troed wrote:
Sun Sep 16, 2018 8:07 pm
(... and this is where my own knowledge is a bit lacking, but I have seen this described as the Shifter "owning" that register, as in, holding its contents and being responsible for outputting that data when that memory address is accessed)
I half recall it was a shadow register in the shifter ?, where the values is held in ram and the shifter ? I might be thinking of something in GLUE and shifter or something, can't exactly remember now .
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

troed
Software Moderator
Software Moderator
Posts: 471
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed » Sun Sep 16, 2018 10:03 pm

exxos wrote:
Sun Sep 16, 2018 9:40 pm
I half recall it was a shadow register in the shifter ?, where the values is held in ram and the shifter ? I might be thinking of something in GLUE and shifter or something, can't exactly remember now .
FF820A = GLUE
FF8260 = Shifter, shadowed by GLUE

At least that's what I have somewhere in my notes ... Ijor surely knows.

Also:
In fact, if you look at the video addresses (figure 10), you will notice that another register is also on bits 8 and 9: VIDEOMOD which makes it possible to indicate the resolution to the shifter, but also to the GLUE (GST MCU on STE). Thus at address FF8260 correspond two registers one in the shifter and one in the GLUE. The only video registers which are in the shifter of the STF are the COLORS and VIDEOMOD. Indeed, this shifter only has 5 bits of address.
http://info-coach.fr/atari/hardware/STE-HW.php

I haven't really thought about it, but I assume the FPGA-Shifter is already able to output the contents of the palette registers so hopefully there's nothing complicated about sorting out ff8260 as well. Or it works on yours and Smonson's and just not on mine :D

User avatar
Smonson
Posts: 211
Joined: Sat Oct 28, 2017 10:21 am

Re: Project: HDMI/DVI out for STFM

Post by Smonson » Mon Sep 17, 2018 1:26 am

Congratulations Troed on finding this valuable bit of evidence, it seems like we are narrowing down the problem quite a bit today!
troed wrote:
Sun Sep 16, 2018 10:03 pm
I assume the FPGA-Shifter is already able to output the contents of the palette registers
Yep, it's working fine here.

I discussed this stuff a bit with Troed earlier in a chat and we came up with two possibilities. Number one is a soldering flaw on his board that interferes with the operation of the bidirectional level shifting buffer. Evidence for that is that he sees some corrupt pixels on one of his machines, suggesting that data isn't being read by the FPGA from the data bus properly. In combination with the resetting issue which we now know is a shifter write/ST read, that implicates the buffer.

Possibility 2 is that it's a timing issue with respect to the direction pin of the same buffer, which is generated by the FPGA. That switches the buffer direction so it drives the shifter bus from the FPGA data lines instead of the other way around. Right now it's asserting that signal whenever CS and WR are true. But maybe it's letting go of the bus too soon, so that the ST fails to read from the resolution register sometimes. I never had any info on when the bus should be asserted, so I guessed (it's protected by current-limiting resistors, by the way).

User avatar
exxos
Site Admin
Site Admin
Posts: 5001
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Project: HDMI/DVI out for STFM

Post by exxos » Mon Sep 17, 2018 6:18 pm

Smonson wrote:
Mon Sep 17, 2018 1:26 am
Evidence for that is that he sees some corrupt pixels on one of his machines, suggesting that data isn't being read by the FPGA from the data bus properly. In combination with the resetting issue which we now know is a shifter write/ST read, that implicates the buffer.
Possible I guess...

I guess troed could flux the whole thing up and run the soldering iron over them to see if that helps with the issue or not... ?
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

Post Reply