Page 9 of 67

Re: Project: HDMI/DVI out for STFM

Posted: Mon Jan 08, 2018 9:45 am
by Smonson
troed wrote: Sun Jan 07, 2018 11:51 am Yeah you should display black when mono is set on an otherwise color line, and you can ignore what happens after the stabilizer has run. Actually, in detail, the stabilizer skips BLANK start and the line is then displayed for a few more pixels until HSYNC kicks in which again means nothing should be displayed from there until BLANK is deasserted on the next line ;)

(The stabilizer is not used to "open" the right border - that's done via a 60/50Hz switch at cycle 376 and is not visible to the Shifter at all)
Wow, that's quite surprising actually. So, let me get this straight, if it wasn't for the stabiliser then the total number of LOADs on the line wouldn't be a multiple of 4, and I guess the length added by the stabiliser is the shortest available one that satisfies that requirement?

It also switches to 71Hz near the beginning of the line, presumably for the same reason, but since there are no LOADs in the shifter already, it displays black by default.

It's really useful that you told me that the switch happens exactly at cycle 444, because I've been guessing where to align the physical screen with the Atari's scanline cycle number. Now I can get it exact :D

Re: Project: HDMI/DVI out for STFM

Posted: Mon Jan 08, 2018 11:14 am
by troed
Smonson wrote: Mon Jan 08, 2018 9:45 am Wow, that's quite surprising actually. So, let me get this straight, if it wasn't for the stabiliser then the total number of LOADs on the line wouldn't be a multiple of 4, and I guess the length added by the stabiliser is the shortest available one that satisfies that requirement?

It also switches to 71Hz near the beginning of the line, presumably for the same reason, but since there are no LOADs in the shifter already, it displays black by default.

It's really useful that you told me that the switch happens exactly at cycle 444, because I've been guessing where to align the physical screen with the Atari's scanline cycle number. Now I can get it exact :D
The "stabilizer" clears the extra words that would otherwise be left in the Shifter for next scanline, yes.

At the beginning of the scanline the switch to HI is done to make the GLUE start the line earlier than it would've otherwise :) That's how you "open" the left border.

For more information on the exact cycles, please see my "state machine" for the GLUE (ST, STE is slightly different):

Color:

Code: Select all

4    IF(71) H = TRUE
24    IF(60) BLANK = FALSE
28    IF(50) BLANK = FALSE
52    IF(60) H = TRUE
54    LINE = 508/512(/224)
56    IF(50) H = TRUE
164    IF(71) H = FALSE
184    IF(71) BLANK = TRUE
372    IF(60) H = FALSE
376    IF(50) H = FALSE
450    IF(!71) BLANK = TRUE
LINE-50    IF(!71) HSYNC = TRUE && H = FALSE
LINE-10    IF(!71) HSYNC = FALSE
Mono:

Code: Select all

4:        IF(71) H = TRUE
164:    IF(71) H = FALSE
184:    IF(71) BLANK = TRUE
188:    IF(71) HSYNC = TRUE
212:    IF(71) HSYNC = FALSE
In reality this is not how it's implemented in GLUE, but it's a simpler explanation on how to get to the accurate cycles. H is combined with V (separate vertical state machine) to form DE.

So, for the left border, even if the decision to start the line is taken at cycle 4, BLANK is still active and thus no graphics is displayed until cycle 24 or 28 depending on frequency.

Also, for the stabilizer, as you can see by going to 71 at cycle 444 and back at 456 it means the IF(!71) BLANK = TRUE doesn't happen. Additional pixels will thus be displayed until 512-50=462 (for a 50Hz line) when HSYNC kicks in which will enable BLANK and nothing should be displayed for the rest of the line.

I have much more on this written up on the Atari-Wiki but it's currently down and the only way to read it is through "view source" on the wiki pages ... http://www.atari-wiki.com/index.php?tit ... ction=edit

Re: Project: HDMI/DVI out for STFM

Posted: Thu Jan 11, 2018 2:13 am
by Smonson
troed wrote: Mon Jan 08, 2018 11:14 am The "stabilizer" clears the extra words that would otherwise be left in the Shifter for next scanline, yes.

At the beginning of the scanline the switch to HI is done to make the GLUE start the line earlier than it would've otherwise :) That's how you "open" the left border.

For more information on the exact cycles, please see my "state machine" for the GLUE (ST, STE is slightly different):
Thanks for that, you told me before about this info and I did check it, but I'm measuring the frame timing from VSYNC now, and I couldn't see precisely when that's generated from those tables.
I have much more on this written up on the Atari-Wiki but it's currently down and the only way to read it is through "view source" on the wiki pages ... http://www.atari-wiki.com/index.php?tit ... ction=edit
Maybe we need to move on from that wiki, it's been down for years. I've found quite a few text files and useful posts here and there, but when you need to know something it'd be good if there was a single location to check, rather than hundreds of pages of old forum posts. I often miss stuff while searching.

Re: Project: HDMI/DVI out for STFM

Posted: Thu Jan 11, 2018 8:57 am
by troed
Smonson wrote: Thu Jan 11, 2018 2:13 am Thanks for that, you told me before about this info and I did check it, but I'm measuring the frame timing from VSYNC now, and I couldn't see precisely when that's generated from those tables.
Yes I need to package the information better.

This is the vertical state machine. All these checks are at CPU/GLUE line cycle 502 (wakestate dependent):

Code: Select all

16: 60Hz BLANK = false; 
25: 50Hz BLANK = false;
34: !50Hz V = true (60Hz and mono screen start)
47/63: 50Hz V = true (short/regular top border GLUE)
234: 60Hz V = false
247/263: 50Hz V = false
260: 60Hz VSYNC = true
258: 60Hz BLANK = true
308: 50Hz BLANK = true
311: 50Hz VSYNC = true (happens at around cycle 30 or so, so very early)
434: 71Hz V = false;
500: mono VSYNC (not sure I verified this, calculated from VSYNC length being one scanline and total # of scanlines is 501)
The line where VSYNC happens is counted down to from when the frequency of the next frame was selected within VSYNC for the current. So a vsync cannot be "skipped" by changing frequency/resolution.

I uploaded a new LA trace for full frames at 32MHz resolution to A-F. You should be able to get most timings you need from that - just let me know what else you need :)

Re: Project: HDMI/DVI out for STFM

Posted: Wed Mar 21, 2018 12:48 am
by Smonson
No *new* news, but just so you know I'm still alive, I've done a new run of prototype boards with a connection for vsync, and that's working fine.

Re: Project: HDMI/DVI out for STFM

Posted: Wed Mar 21, 2018 2:29 am
by rpineau
Thanks for the update :)

Re: Project: HDMI/DVI out for STFM

Posted: Wed Mar 21, 2018 12:41 pm
by rubber_jonnie
Nice Job :)

Re: Project: HDMI/DVI out for STFM

Posted: Fri Jun 22, 2018 10:11 am
by Smonson
I'm not quite done with the unavoidable side-project that is keeping me from working on this (80% through it), but I had enough time recently to add static electricity protection for the DVI socket and get a run of prototypes made. Just tested that new board tonight and it works fine.

Re: Project: HDMI/DVI out for STFM

Posted: Sat Jun 23, 2018 9:57 am
by Smonson
New things today and yesterday:
  • Added ESD protection to the DVI port
  • Added connections for switches/jumpers to the PCB
  • Added selectable aspect ratio (switch 1) - toggles between 640x400 and 720x400 with 40-pixel left/right borders (for widescreen TV)
  • Added selectable borders on/off (switch 2) - changes to resolution 720x480 with 40-pixel border on all sides, or 800x480 with 80-pixel border on left/right and 40px on top/bottom (depending on aspect ratio setting)
Most things work including Spectrum 512 (except for some odd black pixels in the 512-colour palette) and most overscan/palette tricks, like in menu disks.

One thing that's bugging me is that the position of the screen randomly moves left or right by a couple of pixels between power-cycles. I suspect this is the "wake-up states" everyone's always talking about. Reset doesn't affect it. It's annoying because it makes it harder to implement the fullscreen no-borders mode at 640x400. I'm gonna have to make something that detects where the edge of the screen is and adjusts the position - but it won't work if there's some overscan on the left.

Re: Project: HDMI/DVI out for STFM

Posted: Sat Jun 23, 2018 10:32 am
by exxos
Great stuff! :cheers:

If the pixel shift only happens between power ups, does it matter really ? I think most would opt to put up with it rather than lose the left border totally.

There is still the option to tap into Vsync and Hsync on the system, if that would help ?