Jump to content
IGNORED

Video Overscan Showing on LCD Monitor?


mytek

Recommended Posts

This is pretty cool. One thing that always bothered me about Atari video is that the border shares one of your playfield colors and can't be blanked. It would have been nice to have a blackout bit.

Back in the olden days of using a standard definition TV or a low resolution monitor I never saw the stuff that you see now with more modern and/or better quality monitors. Joust is rather interesting (and very distracting), with little white sparkling activity on the right side of my HDTV screen. Yes a blackout bit would have been nice, but when these systems were introduced there was no need.

 

Anyway hopefully this little board will be the solution to that problem.

 

- Michael

  • Like 3
Link to comment
Share on other sites

This is extremely good news!!!! Oh man how great!

 

Let me know when I can order!

 

Only thing we need still is a good finescroll solution for lcd screens (which is way more better on tube televisions)

 

 

Its looking very good indeed, mytek strikes again...Well done that man...

 

I also love when people show their dev version with croc clips on legs and a wiry mess, you always wonder just how it works in the first place and how there not a zillion times rf interference :)

 

As for the fine scroll, isn't that to do with the transistor switching times per the screen, hence the blurry mess it can look like depending on the quality / speed of the display.

 

All way too expensive for me hence I keep a bulky but smooth scrolling crt monitor, just a shame its 60 / 75Hz only... :( Good for NTSC, not so for pal..

  • Like 2
Link to comment
Share on other sites

Would the board work with PAL and NTSC Systems?

 

I will have to look at the PAL system to be sure, but I suspect even if this particular version doesn't work that there may still be a way to accommodate it.

 

 

This is extremely good news!!!! Oh man how great!

 

Let me know when I can order!

 

Only thing we need still is a good finescroll solution for lcd screens (which is way more better on tube televisions)

 

First things first... I need to route traces, then do an initial test PCB. If all goes well, then I will put the board up on OSH Park for DIY. So if you can solder, or know someone that does, it should be a fairly simple board to put together.

 

So what exactly is the problem with fine scroll on an LCD vs. a CRT? And is this applicable to all LCD's (i.e, HDTV's)?

 

 

I also love when people show their dev version with croc clips on legs and a wiry mess, you always wonder just how it works in the first place and how there not a zillion times rf interference :)

Funny you should bring that up, because initially I was having quite a few noise issues which as you pointed out isn't surprising for my rats nest prototype :)

 

 

- Michael

Link to comment
Share on other sites

 

I will have to look at the PAL system to be sure, but I suspect even if this particular version doesn't work that there may still be a way to accommodate it.

 

 

 

First things first... I need to route traces, then do an initial test PCB. If all goes well, then I will put the board up on OSH Park for DIY. So if you can solder, or know someone that does, it should be a fairly simple board to put together.

 

So what exactly is the problem with fine scroll on an LCD vs. a CRT? And is this applicable to all LCD's (i.e, HDTV's)?

 

 

Funny you should bring that up, because initially I was having quite a few noise issues which as you pointed out isn't surprising for my rats nest prototype :)

 

 

- Michael

 

Well the problem is that fine scrolling uses a real physical vertical blank interrupt, which isn't there on LCD/TFT. I haven't seen any decent finescrolling so far on any TFT screen. Perhaps I do not have the right equipment, and perhaps my screens are too cheap to do it right, but nothing is as smooth as my old fashion tube CRT. So I was wishing for a solution for TFT/LCD screens...

  • Like 2
Link to comment
Share on other sites

 

Well the problem is that fine scrolling uses a real physical vertical blank interrupt, which isn't there on LCD/TFT. I haven't seen any decent finescrolling so far on any TFT screen. Perhaps I do not have the right equipment, and perhaps my screens are too cheap to do it right, but nothing is as smooth as my old fashion tube CRT. So I was wishing for a solution for TFT/LCD screens...

The way scrolling/animation looks is a side effect of the display technology. The VBI happens inside the Atari which doesn't know/care what kind of monitor is connected. What you're seeing is the lack of phosphor persistence and possible frame blending going on in the LCD TV.

  • Like 1
Link to comment
Share on other sites

The way scrolling/animation looks is a side effect of the display technology. The VBI happens inside the Atari which doesn't know/care what kind of monitor is connected. What you're seeing is the lack of phosphor persistence and possible frame blending going on in the LCD TV.

 

What you describe is true, but for me it is the other way around. The Atari works this way, because back then the only screens available had these physical properties. So the Atari is designed for the use on a tube. So I would love to see a workaround to see the same effect on TFT as on CRT, but I'm afraid that will never happen...

Link to comment
Share on other sites

I agree that you need a CRT to get an authentic retro experience. Getting the same effect with an LCD is going to be difficult. I suppose if you had enough DSP horsepower to throw at the problem you could actually emulate some of the analog nature of CRT phosphor on a decent PC monitor by using a fast refresh rate.

  • Like 2
Link to comment
Share on other sites

I've been playing around with the layout for the V-Gate board and due to signal locations being more accessible from the right side of the GTIA chip, I relocated the accessory support header on the right side as well. This does make for a tight fit between the board edge and the 4050 chip on the XEGS which could create a problem with the UAV board if present (I still need to confirm this on real hardware).

 

Simulation of V-Gate board installed in an XEGS

 

2IuLHxU.jpg

 

And having the trim pots and other misc componets on an overhang above GTIA maybe problematic with the cartridge connector in a 65XE, but I'll also need to confirm this as well. However for all other models including a 400/800 it looks like a good fit. BTW could someone that has a 400/800 confirm that this would indeed work and clear any card guides involved.

 

Simulation of V-Gate board installed in a 400/800 (CPU/Video Board)

 

9Gx9y2r.jpg

 

 

I've been looking at PAL video timing vs. NTSC and so far it looks like the same solution will work in both cases.

 

- Michael

Edited by mytekcontrols
  • Like 3
Link to comment
Share on other sites

OK I got out the hammer, and squeezed it in a vice, but I think I finally got this down to a size that will work in ALL Atari 8-Bit computers. However a sacrifice had to be made, and that was the identifying labels on the Accessory Support Header (the text would have been too small to clearly read). This was unfortunate, but certainly not a deal breaker by any means (it just means you'll have to consult the schematic to figure out which pin goes where). By leaving out the labels and pushing the header closer to the GTIA chip, I was able to get it to play friendly with Bryan's first generation UAV board sitting in the 4050 socket to the right of the GTIA in a XEGS. Hopefully Bryan hasn't encroached on this space any farther on the next generation boards (Hint...Hint ;) ).

 

This will still be a very tight fit in a 65XE, but so far it looks doable without modifying anything (with the possible exception of the RF shield).

 

Silk Screen and Pads (shown larger than reality)

FXX8laJ.png

 

Top Traces

Hhu2UmK.png

 

Bottom Traces

rEag1J9.png

 

I'll be ordering 3 of these tomorrow from OSH Park. And after I have finished evaluating them, I'll post a revised schematic and provide a public link for others to order the boards.

 

- Michael

Edited by mytekcontrols
  • Like 3
Link to comment
Share on other sites

I'll be ordering 3 of these tomorrow from OSH Park. And after I have finished evaluating them, I'll post a revised schematic and provide a public link for others to order the boards.

 

- Michael

 

Great work!

 

Have I understood that correctly, that i have to order directly from OSH Park? How expensive is it?

Check you still whether the board also works with PAL-Systems?

 

Olix

Link to comment
Share on other sites

Great work!

 

Have I understood that correctly, that i have to order directly from OSH Park? How expensive is it?

Check you still whether the board also works with PAL-Systems?

 

Olix

Hi Olix,

 

Yes unless someone else steps in and manufactures these, the unassembled boards can be ordered from OSH Park for $4 each (minimum order 3 pieces). This price includes free shipping here in the US... not sure what the situation would be shipping overseas (note: just checked, and it appears international first class shipping is also free).

 

I do not have the means to test on a PAL system, but perhaps I can find someone that can. However since the over scan adjustment timing is triggered on the rising edge of CSYNC, it stands to reason that it should work with PAL or NTSC. There is enough adjustment available in the OFFSET and WIDTH controls to likely compensate for any minor differences in scan line length.

 

- Michael

Edited by mytekcontrols
Link to comment
Share on other sites

This will still be a very tight fit in a 65XE, but so far it looks doable without modifying anything (with the possible exception of the RF shield).

:rolling::rolling::rolling: I really need to get stronger glasses! I mistakenly thought the CPU (Atari P/N C014806) was the GTIA chip (Atari P/N C014805). Notice that the '6' on the SALLY part number almost looks like a '5' instead. Anyway long story short, thinking that the SALLY was the GTIA chip caused me all kinds of work to reduce the overhang on the V-Gate board in order to make it fit in the space available below the cartridge port and the plastic case (not shown). Once I figured out that the GTIA chip was 2 chips lower than I originally thought, suddenly I have all kinds of room ;-)

 

 

uv9dMHN.jpg

 

 

- Michael

  • Like 5
Link to comment
Share on other sites

Hello Michael

 

Mistaking the CPU for the GTIA is something that could happen to anybody. But squeezing a hammer using a vice... that's a different story. :D

 

Sincerely

 

Mathy

 

Hi Mathy,

 

Yep you are absolutely right about that being a different story :) Of course what I meant to say was (and left out) was that after getting out the hammer, I tapped on the board, and then placed the board into the vise for a final squeeze to compress it down to a suitable size. And this all happened in the virtual workshop in my mind ;) .

 

- Michael

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...

New Design in the Works

 

The first production prototype failed to meet expectations. Basically there were still some noise and repeat-ability issues to work out, and then I just had to admit to myself that this approach was not a good one. So basically what I did is toss out the whole idea of using analog RC delays to do the video gating, and popped in a PIC MCU chip to be the timing generator. The great thing about taking this new approach is that the design now requires absolutely no calibration what-so-ever. It just works right out of the box.

 

The good thing about having a small run of boards made (3 from OSH Park), is that I was able to use one as a nice break-out board for developing my new design. I only stuffed this board with the high-speed quad AND gate (74HCT08) which is used as my Luma switch, and then ran the control line off board to be able to use an MCU to control it.

 

aVECJOx.jpg

 

And here I am prototyping the MCU circuit, which also has a high-speed analog switch (74HCT4066) to do the Chroma switching. Presently I am just using a PIC16F1847 chip (same as TK-II) for my development, but in the final design I'll be using a much smaller chip for both the MCU and the analog switch.

 

6RTO9Iz.jpg

 

New schematic.

 

9i5O3pA.png

 

And what this thing looks like on a scope when it's doing its thing. Upper Trace = Composite Video, Lower Trace = VGATE signal.

 

Pp435Qe.jpg

 

So in this new way of doing things, the MCU is using GTIA's 3.58 Mhz (NTSC) OSC signal, multiplying that x4 with an internal PLL, and then executing an interrupt timing routine for every time CSYNC goes from low to high. In this routine, delays are being used that are derived from the 14.318 Mhz PLL clock. So for instance, one NOP instruction = approximately 280 nano seconds to execute. So I created a little delay loop routine that takes just a little over 1 uSec for each pass, with the number of passes determined by the value of a variable that is preset before calling the delay routine. So this gives me a gross delay, which I can then further refine with a few NOP's tossed in. These calculated delays are then used to 'turn ON' or 'turn OFF' the gating signal that enables or disables video. Basically the same as what I was doing with RC delays before, but now much more precise, and locked into the Atari's master clock. Essentially you could say that the MCU is 'gen-locked' to the Atari.

 

Here is an example of the interrupt code (it is called every time CSYNC goes low-to-high)...

	org 0x004		; processor interrupt vector

	bsf PORTB,VGATE		; turn on video (start of color burst)
	movlw 01H
	movwf dlyloop
	call dly_1us
	btfsc PORTB,EN		; Leave video ON if Enable pin grounded
	bcf PORTB,VGATE		; turn off video (end of color burst)

	movlw 01H		; short delay before active field
	movwf dlyloop
	call dly_1us
	nop
	nop			; each 'nop' = 280 nSec
	
	bsf PORTB,VGATE		; turn on video (start of active video data)
	movlw 29H
	movwf dlyloop
	call dly_1us
	btfsc PORTB,EN		; Leave video ON if Enable pin grounded
	bcf PORTB,VGATE		; turn off video (end of active video data)

	banksel	INTCON		; clear interrupt flag
	bcf	INTCON,INTF
	retfie			; leave interrupt

And as can be seen, there is also facility for enabling or disabling what the V-Gate board is doing to the A8's video, through the use of an enable pin on the MCU. Essentially if it is disabled (enable line = low), then no turn offs of the gating signal is allowed, so the entire video field is passed through. Since there is a pull-up resistor on this pin, the board defaults to video gating enabled.

 

Here is Joust on an HDTV showing a rather annoying sparkling line on the right side (V-Gate Disabled).

 

OZSlebY.jpg

 

Here is what it looks like with the V-Gate enabled.

 

pLBYjKD.jpg

 

 

Switching modes is glitch free.

 

 

Anyway now I'm just waiting for the new PIC chips and analog switch to arrive. If all checks out well, then its on to laying out a 2nd board.

 

- Michael

Edited by mytekcontrols
  • Like 1
Link to comment
Share on other sites

This is so far over my head, it's like trying to teach a dog to play chess. I still like following along though.

Hey don't feel bad. The original reason I took the RC delay route, was because it had been so long since I had done low level assembly on a PIC Chip that I knew it would be like starting from new (which I wasn't looking forward to). The other thing that made the process even more tedious was that I needed to setup all of the required tools like MPLAB-X IDE and get it talking to my programmer as well (this turned into a day all by itself, since the PICkit 3 borked itself). I also had to refamilirize myself with the RISC based instructions which as you can see are a bit more cryptic than 6502. But I had to do it in assembly, since the small 8-pin PICS can only go so fast, and every instruction takes 4 clock cycles, unlike a 6502 that can do it in one cycle. So to give you a feel for execution time, if you look at the scope, you'll see there is a space between the end of the A8's video sync and the VGATE signal switching on. My intention was to have it instantly turn on, but that's as fast as it can be done with a 14.318 MHz clock in the PIC. If I had try to do this in Basic, FlowCode, or even C it would not have been quick enough to even work at all.

 

So sadly I couldn't use any of my higher level languages for this application, and I had to cook my brain to figure it out in assembly (I don't use it enough to stay fluent). Then the other problem is trying to figure out what all of the chip configuration fuses need to be set to to do what you want (that's another brain teaser).

 

Anyway I'm now on the downhill stretch, and things are looking good.

 

- Michael

Edited by mytekcontrols
  • Like 1
Link to comment
Share on other sites

Rev 1.5 Update

Just a final tweak to the schematic (locked in the PIC model #, fixed the LED orientation, and generally just cleaned up a few things).

j2mTk7a.png
Download: PIC12F1571 Datasheet
Vendors and Pricing

And here's a peek of what I'm leaning towards with the new PCB layout.

fcSiYYr.png

I'll probably start routing traces this weekend, and possibly do another small board run sometime next week.

And for those that are wondering... Yes the MCU will be programmable with the JOY2PIC and a V-Gate Flashing ATR.

- Michael

Edited by mytekcontrols
  • Like 3
Link to comment
Share on other sites

New Boards Are On The Way for the 'No Adjustment' Rev 1.5 version of V-Gate

Board Top Placement and Silk Screen
3T7xAem.png

Top Layer Traces
idxlHV5.png

Bottom Layer Traces

JoGUQJm.png


Final tweak to schematic
32yvY17.png

I have two simultaneous orders underway. One with OSH Park and the other with ALLPCB. OSH Park will take at least 2 weeks before they ship, so I thought I would also give these other guys a try as well, since they said they would ship via DHL in 4 days. I'll also be getting 10 boards for about $2.90 a piece (that price includes shipping), vs. 3 boards at nearly $4.00 a piece (also includes shipping) from OSH Park. It'll be interesting to see what the quality looks like from ALLPCB.

My plans are still to have the boards hosted at OSH Park, but I'll also have the Gerbers available from my website for those that want to farm it out elsewhere.

Since I am still using Rev 1.5 as I did for the last two schematic updates, and to avoid any confusion that this may cause, the previous two posted schematics will be taken down shortly. And yes that is an SMD part being used for the analog chroma switch. unfortunately I could not get a PDIP version, but at least this one only has 5 leads that need to be soldered.

 

OPERATION

 

Basically assuming the PIC chip has been programmed with the V-Gate firmware, plugging it into the GTIA socket and then inserting the GTIA chip into it, is all that is minimally required to have this board do it's thing. And by 'doing it's thing', I am referring to automatic deletion of video that extends into the over-scan area of the screen. The two headers have the optional V-Gate enable and LED connections, and the various GTIA logic signals for connection to other popular A8 upgrades. But these are 'optional' connections, and not required in order for V-Gate to work.

- Michael

Edited by mytekcontrols
  • Like 2
Link to comment
Share on other sites

I got the new 8-pin PIC chips in today (PIC12F1571), made a quick device change to my source code, and then programmed the chip. I'm happy to say it worked on the very first attempt :-D . Luckily this chip is very similar to the PIC16F1847 I was previously using for code development, just with less I/O and less memory, so not much needed to be changed in order to make the transition. And it turned out to be a perfect fit for what I needed, having just enough I/O to do the job (with one I/O pin left over).

 

medium-PIC12F1571-PDIP-8.pngGcI99mz.png

Check out the: PIC Assembly Source Code

;****************************************************************
;*  Name    : V-Gate1571.asm                                    *
;*  Author  : Michael St. Pierre                                *
;*  Notice  : Copyright (c) 2016 Mytek Controls                 *
;*          : All Rights Reserved                               *
;*  Date    : 11/02/2016                                        *
;*  Version : 1.0                                               *
;*  Notes   : Over-Scan Timing Generator (V-Gate Chip)          *
;*          : Based on Microchip PIC12F1571                     *
;*          : Assembled in MPLAB-X v3.35                        *
;*          :                                                   *
;*          : Firmware for Atari V-Gate Over-Scan Delete Board  *
;*          : Rev 1.5                                           *
;****************************************************************

    list p=12F1571	      ;Define Processor
    #include <p12f1571.inc>

; Set configuration register for:
; Code protection off
; Brown-out detect off
; MCLR disabled (I/O Pin)
; Watch Dog timer disabled
; Power on reset delay enabled
; Enable External Clock Input (3.58 Mhz GTIA OSC)
; 4x PLL enabled (14.318 Mhz)

;PIC12F1571 Config Settings
    __CONFIG _CONFIG1, _FOSC_ECM & _WDTE_OFF & _PWRTE_ON & _MCLRE_OFF & _CP_OFF & _BOREN_OFF & _CLKOUTEN_OFF
    __CONFIG _CONFIG2, _WRT_OFF & _PLLEN_ON & _LVP_OFF 

;**********************************************************************
;Variables and Equates
;**********************************************************************             
    cblock 0x20
	
dlyloop

    endc

#DEFINE CSYNC   PORTA,2    
#DEFINE VGATE   PORTA,4    
#DEFINE LED     PORTA,1
#DEFINE ENABLE  PORTA,0

;**********************************************************************
;Start
;**********************************************************************

    org     0x000	      ; Processor reset vector
    goto    SetUp	      ; Set up Port I/O, IRQ, ect.

;----------------------------------------------------------------------
	
    org     0x004	      ; Processor interrupt vector

    bsf     VGATE	      ; Turn on video (start of color burst)
    movlw   01H
    call    dly_1us
    btfsc   ENABLE	      ; Leave video ON if Enable pin grounded
    bcf     VGATE	      ; Turn off video (end of color burst)

    movlw   01H
    call    dly_1us
    nop
    
    bsf     VGATE	      ; Turn on video (start of active video data)
    movlw   37H
    call    dly_1us
    nop
    nop	                      ; Each 'nop' = 279 nSec
    btfsc   ENABLE	      ; Leave video ON if Enable pin grounded
    bcf     VGATE	      ; Turn off video (end of active video data)

    banksel INTCON	      ; Clear interrupt flag
    bcf     INTCON,INTF
    retfie	              ; Leave interrupt


;**********************************************************************
;Setup
;**********************************************************************

SetUp	
	
; configure Ports

    banksel TRISA
    movlw   B'11101101'	      ; RA1 & RA4 Outputs, all others input
    movwf   TRISA
    banksel WPUA		
    movwf   WPUA	      ; Enable individual pull-ups for PORTA inputs
    banksel ANSELA
    clrf    ANSELA	      ; Switch PORTA from analog to digital inputs
	
; configure interrupts
	
    banksel OPTION_REG
    bsf     OPTION_REG,INTEDG   ; 1 = interrupt on CSYNC rising edge
    bcf     OPTION_REG,7	; Global enable weak pull-ups

    banksel INTCON
    bsf     INTCON,INTE	        ; 1 = enables the GPIO port change interrupt
    bsf     INTCON,GIE	        ; 1 = enables all unmasked interrupts	
    goto    Main


;**********************************************************************
;Subroutines
;**********************************************************************

dly_1us
    movwf   dlyloop
dly decfsz  dlyloop,1
    goto    dly
    retlw   0


;**********************************************************************
;Main
;**********************************************************************

Main
    btfsc   ENABLE
    bsf     LED	      ; Turn on LED if V-Gate enabled
    btfss   ENABLE
    bcf     LED	      ; Turn off LED if V-Gate disabled
    goto    Main

    end

- Michael

  • Like 2
Link to comment
Share on other sites

to be clear then, software that purposely uses overscan or underscan will not be cut short or reveal a mess as this now auto adjusts?

 

The amount of overscan that gets deleted, is well outside of what old CRT Monitor's and older TV's were able to actually show. I opted to let as much of the video as possible to come through, while eliminating what was obviously never intended by the game or application's creator to be seen. Now I can't speak for newer software that intentionally takes advantage of HDTV's and better monitors, but in those situations you can simply turn the video gating off and reveal all of what is there to be seen. This can either be done with a toggle switch or a software switch (i.e. U1MB's additional control lines). Also keep in mind that the video gating in no way interferes or is seen by the software running on the A8. And this is a 'fixed' not dynamic (auto adjusting) video gating process based on exact timing genlocked to the GTIA's OSC input (3.58 Mhz for NTSC).

 

- Michael

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...