STFM to DVI/HDMI project

Troubles with your machine? Just want to speak about the latest improvements? This is the place!

Moderators: Mug UK, Zorro 2, Greenious, spiny, Moderator Team

User avatar
Smonson
Atari freak
Atari freak
Posts: 74
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Tue Oct 17, 2017 5:47 am

I've got it on a DVI connector, which is way easier to hand solder... although still not what I'd call "easy".

Michael960
Atariator
Atariator
Posts: 26
Joined: Fri Feb 03, 2017 9:33 pm

Re: STFM to DVI/HDMI project

Postby Michael960 » Sun Oct 22, 2017 6:30 pm

In the past two months, I tried something similar with a Spartan3 FPGA: I grabbed the MONO, RGB, VSYNC, HSYNC, DE and CLK32 signals from the shifter/GLUE. For monochrome mode I just forwarded them to the DVI transmitter chip without any buffering or scan doubling as I thought the frequencies should already be high enough for HDMI and for color modes, I also used a double line buffer. But I had less success than you: none of my monitors liked the signal. They all complained about illegal timings. OK, in color mode, I might have messed up something in the VHDL code and can't really test it as I don't have a good oscilloscope, but in mono mode it's so trivial that I'm quite sure that I did the forwarding correctly. My hardware is working well as a test video sequence with VGA timings generated in my FPGA is displayed on all of my monitors, but if I change this sequence to ATARI timings, it is also not displayed.

So I was nearly ready to give up this project and now I wonder how you had success 8O

Have I understood you correctly: you REPLACED the shifter by your FPGA circuit?
Is your ST in PAL or NTSC mode? (Does this make I difference in monochrome mode?)
Did you already have some success in color mode?
What monitor did you use?

In case of interest, here's the timings my FPGA counted in PAL mode and gave out via UART:

Code: Select all

ATARI 1040 STF Mono
  Horizontal [Clocks] : FPORCH=$061 SYNC=$060 BPORCH=$03F VIDEO=$280 SUM=$380
              Dezimal :          97        96          63        640      896
  Vertical   [Lines]  : FPORCH=$040 SYNC=$001 BPORCH=$024 VIDEO=$190 SUM=$1F5
              Dezimal :          64         1          36        400      501

ATARI 1040 STF Low 50Hz
  Horizontal [Clocks] : FPORCH=$151 SYNC=$0A0 BPORCH=$10F VIDEO=$500 SUM=$000
              Dezimal :         337       160         271       1280        0*
  Vertical   [Lines]  : FPORCH=$02F SYNC=$003 BPORCH=$03F VIDEO=$0C8 SUM=$139
              Dezimal :          47         3          63        200      313

* Manually calculated sum is 2048, integer was only range 0 to 2047, so it's plausible to be an overrun.

All the timings were given out in HEX as this was easier to do in VHDL (and already difficult enough :)) and afterwards manually converted to decimal.

User avatar
Smonson
Atari freak
Atari freak
Posts: 74
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Sun Oct 22, 2017 10:50 pm

Hi Michael960,

Sorry to hear you weren't able to get that working, it sounds like you were well on the way to success there. I am indeed replacing the shifter, it simplifies a lot of things.

These are the timings I'm using for 50Hz:

Code: Select all

`define H_WIDTH 1024
`define H_ACTIVE 640
`define H_FRONT_PORCH 16
`define H_SYNC_TIME 96
`define LINES_PER_FRAME 626
`define LINES_ACTIVE 400
`define V_FRONT_PORCH 13
`define V_SYNC_TIME 2


This is double the rate of the real ST video lines, which has half as many lines, each 2048 clocks in length (32MHz).

Hopefully soon I'll have a successful test of a colour video mode to show. I've been concentrating on getting the boards out to the fab, because the Atari really doesn't like not being able to read the shifter registers, it screws the desktop up.

User avatar
Smonson
Atari freak
Atari freak
Posts: 74
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Mon Nov 06, 2017 12:08 pm

Update: this is running OK on my first set of properly-fabricated circuit boards. Screenshot of mono desktop (ignore the green colour):

Image

mpattonm
Captain Atari
Captain Atari
Posts: 173
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: STFM to DVI/HDMI project

Postby mpattonm » Mon Nov 06, 2017 4:50 pm

Impressive!

User avatar
Atarieterno
Atari Super Hero
Atari Super Hero
Posts: 626
Joined: Mon Jan 18, 2016 3:40 pm
Location: Spain

Re: STFM to DVI/HDMI project

Postby Atarieterno » Mon Nov 06, 2017 5:53 pm

Awesome !
ST/fm/e, STacy, Mega ST/e, TT, Falcon, C-Lab MKX... and more music tools.

User avatar
Atari030
Atari Super Hero
Atari Super Hero
Posts: 577
Joined: Mon Feb 27, 2012 6:14 am
Location: Melbourne, Australia

Re: STFM to DVI/HDMI project

Postby Atari030 » Tue Nov 07, 2017 10:34 pm

Ripper, mate.

User avatar
Smonson
Atari freak
Atari freak
Posts: 74
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Fri Nov 10, 2017 12:56 pm

Image

User avatar
Atarieterno
Atari Super Hero
Atari Super Hero
Posts: 626
Joined: Mon Jan 18, 2016 3:40 pm
Location: Spain

Re: STFM to DVI/HDMI project

Postby Atarieterno » Fri Nov 10, 2017 1:01 pm

Speak now or be quiet forever!! :mrgreen:
More info, please.
Great job ! :cheers:
ST/fm/e, STacy, Mega ST/e, TT, Falcon, C-Lab MKX... and more music tools.

User avatar
troed
Atari God
Atari God
Posts: 1350
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: STFM to DVI/HDMI project

Postby troed » Fri Nov 10, 2017 1:04 pm

Wow!

ijor
Hardware Guru
Hardware Guru
Posts: 3295
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: STFM to DVI/HDMI project

Postby ijor » Fri Nov 10, 2017 1:15 pm

Yeah, great job ... !

User avatar
Smonson
Atari freak
Atari freak
Posts: 74
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Fri Nov 10, 2017 10:15 pm

Atarieterno wrote:More info, please.
Great job ! :cheers:


Thanks Atarieterno!

I don't know what I can tell you that I haven't already said... this photo is just the latest progress update, now that I've got the colour modes working.

Next I need to wait for new PCBs to come from the fabricator, because I stuffed up some of the connections on the current one.

At some point in the future I can make these available to others who want to buy one, as long as you have a compatible STFM.

MM41
Atari maniac
Atari maniac
Posts: 96
Joined: Sun Jun 28, 2015 2:36 pm
Location: France

Re: STFM to DVI/HDMI project

Postby MM41 » Sat Nov 11, 2017 5:46 pm

:D Great news, well done Smonson :cheers:

User avatar
Atari030
Atari Super Hero
Atari Super Hero
Posts: 577
Joined: Mon Feb 27, 2012 6:14 am
Location: Melbourne, Australia

Re: STFM to DVI/HDMI project

Postby Atari030 » Sat Nov 11, 2017 8:58 pm

There will be people lining up for this. Great work.

alanh
Hardware Guru
Hardware Guru
Posts: 1381
Joined: Mon Jul 24, 2006 9:01 pm
Location: North Wales, UK

Re: STFM to DVI/HDMI project

Postby alanh » Tue Nov 14, 2017 5:23 pm

Yes, nice job. Be interesting to see how some of the overscan demos work with this.
Falcon CT60, Falcon CT63 x2, TT x3, MegaST x2, MegaSTE x2, STFM x2, STE x2, STacy, STBook, (Dead) Hades 060, Milan 060, T40.

vattari
Atari User
Atari User
Posts: 40
Joined: Mon Jan 12, 2015 7:57 pm
Location: Victoria, Australia

Re: STFM to DVI/HDMI project

Postby vattari » Wed Dec 27, 2017 7:35 am

A very interesting project - great work!
Do you have any photos with the board in place? How is this progressing, overall?
  • Mega STE/4, Monster board, 40GB IDE, CosmosEx
  • Mega ST4, Monster board, 8GB CF, Gotek
  • TT4/16, SCSI2SD
  • Falcon 14MB, 8GB CF, Falcon Speed, CosmosEx
  • Falcon 14MB, 8GB SD, Gotek
  • 130XE/myIDE2; 800XL/Supermon; XEGS/SIO2SD; 800XL/SIO2SD; 130XE/SIDE2
  • 1040STE/4MB, Monster board (8GB SD, RTC)
Work-in-progress: Mega ST4/Matrix M110 video; Mega ST2/Titan Reflex video; TT 2/16MB; 1200XL UAV; 400 UAV/Audio; 800

User avatar
viking272
Captain Atari
Captain Atari
Posts: 298
Joined: Mon Oct 13, 2008 12:50 pm
Location: west of London, UK

Re: STFM to DVI/HDMI project

Postby viking272 » Wed Dec 27, 2017 10:22 am

Great work, looks amazing progress

User avatar
1st1
Atari Super Hero
Atari Super Hero
Posts: 785
Joined: Mon May 07, 2012 11:48 am

Re: STFM to DVI/HDMI project

Postby 1st1 » Wed Dec 27, 2017 11:39 am

Your solution is very similar to "Shadow" chip in STacy, which controls the LCD panel. It's also parallel to the shifter and sniffing on Shifter's signals (but only b&w). It will be a challenge to support overscan tricks.
Power without the Price. It's not a bug. It's a feature. _/|\_ATARI

1040STFM in PC-Tower (PAK68/2, OvrScn, 4 MB, 1GB SCSI, CD-ROM...) * 2x Falcon 030 32GB/14MB+ScrnBlstrIII * 2x TT030 73GB/20MB+Nova * 520/1040STFM * 520/1040STE * 260/520ST/+ * some Mega ST * 2x Mega STE 500MB/4MB+M.CoCo * Stacy * STBook * SLM605 * SLM804 * SLM605 * SMM804 * SH 204/205 * Megafile 30/44/60 * SF314 * SF354 * 5x Pofo * PC3

User avatar
troed
Atari God
Atari God
Posts: 1350
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: STFM to DVI/HDMI project

Postby troed » Wed Dec 27, 2017 12:57 pm

1st1 wrote:Your solution is very similar to "Shadow" chip in STacy, which controls the LCD panel. It's also parallel to the shifter and sniffing on Shifter's signals (but only b&w). It will be a challenge to support overscan tricks.


Overscan/border removal is just GLUE, and not difficult to support. What will be difficult, when replacing the Shifter instead of just sniffing the output, will be to support Shifter specific things like Shifter wakestates, Spectrum 512 black pixels, 4 pixel sync scroll etc.

User avatar
Smonson
Atari freak
Atari freak
Posts: 74
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Wed Dec 27, 2017 2:06 pm

Hi guys, I ran out of time to continue working on it while trying to support overscan and sync scrolling. I'll get back to it in the coming year. If worst comes to worst, I'll forget about supporting those. The problem is these modes and techniques depend on completely internal implementation details of the shifter at a fine level of detail, which are unknown to me and virtually impossible to work out by observation of the shifter in situ.

ijor
Hardware Guru
Hardware Guru
Posts: 3295
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: STFM to DVI/HDMI project

Postby ijor » Wed Dec 27, 2017 3:42 pm

Smonson wrote:Hi guys, I ran out of time to continue working on it while trying to support overscan and sync scrolling. I'll get back to it in the coming year. If worst comes to worst, I'll forget about supporting those. The problem is these modes and techniques depend on completely internal implementation details of the shifter at a fine level of detail, which are unknown to me and virtually impossible to work out by observation of the shifter in situ.


Again, not at all. Both overscan and regular sync scrolling can work just fine with a very simple Shifter model. As Troed just said, they depend mostly on GLUE implementation, not on SHIFTER.

The only techniques that require a very accurate SHIFTER model are 4 pixel sync scroll (just a couple of demos), and the "unstabilizer" sync scrolling using by CLOSURE demo.

User avatar
Atarieterno
Atari Super Hero
Atari Super Hero
Posts: 626
Joined: Mon Jan 18, 2016 3:40 pm
Location: Spain

Re: STFM to DVI/HDMI project

Postby Atarieterno » Wed Dec 27, 2017 3:48 pm

Smonson wrote:Hi guys, I ran out of time to continue working on it while trying to support overscan and sync scrolling. I'll get back to it in the coming year. If worst comes to worst, I'll forget about supporting those. The problem is these modes and techniques depend on completely internal implementation details of the shifter at a fine level of detail, which are unknown to me and virtually impossible to work out by observation of the shifter in situ.


Do not give up, dear mate, I'm sure that some theoretical collaboration you can get from other gurus in this forum.
We need that video device.
Best regards.
:cheers:
ST/fm/e, STacy, Mega ST/e, TT, Falcon, C-Lab MKX... and more music tools.

User avatar
Smonson
Atari freak
Atari freak
Posts: 74
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Thu Dec 28, 2017 12:08 am

ijor wrote:Again, not at all. Both overscan and regular sync scrolling can work just fine with a very simple Shifter model. As Troed just said, they depend mostly on GLUE implementation, not on SHIFTER.

The only techniques that require a very accurate SHIFTER model are 4 pixel sync scroll (just a couple of demos), and the "unstabilizer" sync scrolling using by CLOSURE demo.


Didn't say it wasn't simple, I said it's unknown... I have yet to include the latest info you gave me, which is the implementation of the clocks generator. When I have time again, I'll look into it.

As you say it should be simple, so it probably is. The difficult part is knowing what is different from a real shifter when a piece of code is running and doing some unknown thing (without seeing the code), not knowing what that code is expecting to happen.

ijor
Hardware Guru
Hardware Guru
Posts: 3295
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: STFM to DVI/HDMI project

Postby ijor » Thu Dec 28, 2017 1:53 am

Smonson wrote:Didn't say it wasn't simple, I said it's unknown... I have yet to include the latest info you gave me, which is the implementation of the clocks generator. When I have time again, I'll look into it.

As you say it should be simple, so it probably is. The difficult part is knowing what is different from a real shifter when a piece of code is running and doing some unknown thing (without seeing the code), not knowing what that code is expecting to happen.


You are complicating yourself too much. For "classic" overscan and sync scrolling there is nothing to know. Forget about the original clock mux implementation. Forget about the complicated logic of the pixel counter. Your old, simple, shifter model that you said you implemented before, should work. There is nothing special at all about (classic) overscan or sync scroll regarding Shifter. The only thing is that you need to be ready to accept more loads per line and more active scan lines, that's all. You can also ignore changes to the resolution register outside the active area.

The problem seems to be that you started testing overscan with the Closure demo. As we are saying, that is a very special and unique case. Try other demos with your old, simple model.

User avatar
troed
Atari God
Atari God
Posts: 1350
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: STFM to DVI/HDMI project

Postby troed » Thu Dec 28, 2017 7:59 am

We might get into a "too many cooks" scenario here, but rest assured it's just because we really want to see this project succeed :)

1) The original design tried to create a complete video output from just Shifter signals alone, by detecting DE and generating not only video but also sync signals from it. This works, and Smonson got it working, for regular scanlines and frames.

2) To support regular fullscreens, it's _possible_, although see below, to do the same but detect that DE signalling will look a bit different (wider lines etc). I would advise against this. It will only support basic fullscreen scenarios and will likely be tricked to lose sync too easily.

3) In the ST both GLUE and Shifter together creates the complete video output with sync. While the original design would've been plug'n'play for those who have socketed Shifters, AFAIK that's not the most common scenario. I propose picking up HSYNC and VSYNC from GLUE and synchronizing the scanline and frame signalling to those. The new Shifter implementation then becomes really simple, it's just a question of detecting when DE goes high and react to each LOAD when it arrives. This will solve regular line, regular fullscreens _and_ sync scrolls and non-standard lines that many demos manage to do by accident. The reason for proposing this is that one of the 12 possible lines that a sync scroll can create is a 0-byte line where DE never goes high at all. Thus some other signal must be used for creating output HSYNC - and what can be better than HSYNC itself? ;)

4) After the above has been done, which will run 99.99% of all ST apps and demos, it might be interesting to start looking at a complete Shifter re-implementation which understands all Shifter weirdness (which is an area of still active research). This would be needed for 4-pixel sync scroll, {Closure} and possible some otherwise bitplane-shifted fullscreens etc.

/Troed


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 5 guests