Jump to content
IGNORED

VBXE vertical alignment


Recommended Posts

Could I ask some folks with VideoBoard XE to run a couple of tests to check for a vertical alignment issue?

 

A couple of us are trying to figure out why some VBXE systems are showing a one scanline offset between the ANTIC DL and VBXE XDL while others don't, even though the documentation says that the XDL should be aligned to the DL. The current theory is that NTSC/PAL may make a difference.

 

The first program is a test program that shows two squares side-by-side, one rendered through ANTIC display list and the other through the XDL. It should look like this:

 

image.thumb.png.abeb61d67545f6bccd7e51995923d912.png

 

The second program is Rybags' Quadrillion port from the VBXE examples package. Both should render vertically aligned according to the spec, but at least the latter seems to render the attribute list a scanline up on some NTSC systems. I'd like to try to narrow down whether this is related to NTSC/PAL or a specific core version, so this can be taken into account in emulation and when writing VBXE programs.

 

quadrillion.zip vbxealign.xex

Link to comment
Share on other sites

You know my results for Quadrillion, so I will spare these. For your calibration program, PAL is fine (the first picture), NTSC has this one line shift (second picture). Both are taken on the same LCD TV. Apart from one being PAL (130XE) the other (converted) NTSC (800XL), both my systems are practically identical: U1MB driving the VBXE D6/D7 line, Sophia2 on board, stereo Pokey, VBXE 2.1 with 1.26a core (on the NTSC system I tried both the "NTSC" new core and the classic one, no difference). I do not have the stuff to test the NTSC system with the real GTIA, unfortunately. Hope this helps.

vbxe_pal.jpg

vbxe_ntsc.jpg

Link to comment
Share on other sites

35 minutes ago, electron said:

VBXE was developed using only PAL machine. Quite a late discovery indeed...

Anyways, I will be rewritting FX/GTIA core probably from the scratch. Someday. Maybe.

Are you able to confirm for us this is a consistent bug for all NTSC installations and conditions, or are there any "exceptions"?

Link to comment
Share on other sites

2 hours ago, woj said:

Are you able to confirm for us this is a consistent bug for all NTSC installations and conditions, or are there any "exceptions"?

Do not have NTSC machine with VBXE...

17 hours ago, phaeron said:

Could I ask some folks with VideoBoard XE to run a couple of tests to check for a vertical alignment issue?

I'm interested too.

Link to comment
Share on other sites

13 minutes ago, woj said:

This one would be really good to test 😉

Cool, will see if I can find some time today or tmrw eve. 

Great work on Popeye VBXE BTW. (For what it's worth I'd love to see a full colour VBXE Lemmings version on the A8. Big fan of Brundles and Tommings/Tommingi. Mr fish did a nice job the other year colorising the latter. The animation with Tommingi is spot on. I still think VBXE could bring a wonderfully colorful and equally well animated Lemmings to the A8. (Mouse controlled as well as Joystick of course). 

Anyways, I digress. ;)

 

Will report back on the VBXE testing. 

Link to comment
Share on other sites

4 hours ago, woj said:

@Beeblebrox @flashjazzcat you both have a collection of different kinds of machines, don't you?

In fact I have a VBXE-equipped customer NTSC 800XL on the desk right now, and I eagerly downloaded Avery's test program yesterday morning with the intention of trying it out. Unfortunately all it demonstrated was that the customer machine (which also has Rapidus/Adaptus, AKI USB, U1MB and PokeyMAX) immediately crashed when I attempted to run any software on it, thus opening a horrifying can of worms which infested my entire working day. :)

 

I'll try it again later today (editing video at the moment). Hopefully it'll work now, and I'll post results here. It certainly seems that NTSC testing is unfortunately all too often a bit of an afterthought, though.

Edited by flashjazzcat
Link to comment
Share on other sites

I'm guessing VBXE determines system type on startup by counting HSync commands in between two VSync commands - from there the display start offset should be constant and unchanging for both systems.

That said though, I can't say I ever experienced any weirdness when playing about with 480i interlace with it - the behaviour was as expected from legacy video.

 

* and note, older VBXEs don't have a hard NTSC/PAL switch, AFAIK that is only on newer ones to decide which crystal is used.

 

My one and only VBXE intall is 800XL PAL - though I do have a 1200XL here so in theory might be capable of doing NTSC by putting it's Antic in.

Edited by Rybags
Link to comment
Share on other sites

44 minutes ago, Rybags said:

That said though, I can't say I ever experienced any weirdness when playing about with 480i interlace with it

About that - have you ever tested your interlace hack (either native or VBXE, no matter) on an actual NTSC computer? Reason for asking is that, even though I do not own any CRT screen that is tolerant towards the hack and working with it, now having an NTSC machine I noticed that my RetroTink5 shows considerably different behaviours for both systems: PAL native (MemoPad 480i) works sort of (interlace fields swapped), PAL VBXE (falcon demo) crashes RetroTink output, for NTSC, both native and VBXE outputs work in the flckery mode on RTK (to me meaning any hacked interlaced mode is not in effect). Just curious..., but I gently suspect that your carefully developed PAL timings on DMA on/off operations are off on the NTSC machines?

Link to comment
Share on other sites

I don't think I have - the 1200XL Bob sent me years ago is the only NTSC Atari I have and I've not used it a lot.

 

In the early days I put up sample programs and relied on feedback from other people testing, at the time I probably had 4 or 5 CRTs I was able to test on but also wanted NTSC and LCD displays checked out.

That aside - the timings inside a scanline are the same for PAL/NTSC - we have 114 cycles per line regardless where some systems such as C64 have different cycles per line (in fact 3 variations since an early revision was different again)

 

For devices that process/convert video - it's a mixed bag.  Some will just assume the default signal is interlaced and some will behave in other ways.  My old HDD recorder when working properly didn't like old computer signals and would just present a rolling screen.

 

For incorrecly swapped fields - on many of the 480i titles I did, I put in hotkeys to allow such things as field swap, so you could try that.

Link to comment
Share on other sites

8 hours ago, woj said:

About that - have you ever tested your interlace hack (either native or VBXE, no matter) on an actual NTSC computer? Reason for asking is that, even though I do not own any CRT screen that is tolerant towards the hack and working with it, now having an NTSC machine I noticed that my RetroTink5 shows considerably different behaviours for both systems: PAL native (MemoPad 480i) works sort of (interlace fields swapped), PAL VBXE (falcon demo) crashes RetroTink output, for NTSC, both native and VBXE outputs work in the flckery mode on RTK (to me meaning any hacked interlaced mode is not in effect). Just curious..., but I gently suspect that your carefully developed PAL timings on DMA on/off operations are off on the NTSC machines?

I was able to use his non-vbxe interlace programs on my NTSC machines without issue.  However, my Sony PVMs will take just about any signal you give them and display them nicely so this may not be an accurate test.

Link to comment
Share on other sites

  • 3 weeks later...

Just to bump this up, no additional direct results from your alignment test, but (a) one more person in the game thread indicated that it ran OK on an NTSC machine, which means that person also has the alignment issue on their machine (because the game corrects for it by default), and (b) Jon indicated in the comments discussion with me under his recent YT video that he has seen this problem before on NTSC machines, and also thought this is a consistent feature. 

Edited by woj
Link to comment
Share on other sites

6 minutes ago, woj said:

Jon indicated in the comments discussion with me under his recent YT video that he has seen this problem before on NTSC machines, and also thought this is a consistent feature. 

Sorry - I must have severely bungled the wording when I responded. I just meant to infer that having read about the issue, I assumed it to be determinate. I still need to run the test program on the machine featured in the videos (the only NTSC machine with VBXE I have to hand at the moment) to confirm the result.

Edited by flashjazzcat
Link to comment
Share on other sites

Tests run:

VBXEalignmenttest.thumb.jpg.8c1ecd9c9ab35d10cf7f921a16146547.jpg

Quadrillion.thumb.jpg.a33118b8f1be0c738a78e6fbd938beeb.jpg

Popeye RC1 from Feb 17 after loading:

Popeyeafterloading.thumb.jpg.25042ec501007db5f37b31f9a129e0c3.jpg

And after pressing 'V':

PopeyeafterVpressed.thumb.jpg.6b528864a6498109c8615ea02d9be1ac.jpg

I wasn't sure that the RC release corrected alignment by default, so I was a little surprised not to see the issue crop up UNTIL I pressed 'V'.

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

29 minutes ago, flashjazzcat said:

I wasn't sure that the RC release corrected alignment by default, so I was a little surprised not to see the issue crop up UNTIL I pressed 'V'.

As I said above, under the assumption that this is a consistent feature, the game corrects this upfront leaving the V key to be used in Altirra which is not (yet) correcting it. 

Link to comment
Share on other sites

5 minutes ago, woj said:

As I said above, under the assumption that this is a consistent feature, the game corrects this upfront leaving the V key to be used in Altirra which is not (yet) correcting it. 

Right you are. I wasn't sure whether the RC build was the latest or whether it followed this methodology. I downloaded it here:

Quote

If the NTSC version happens to have screen glitches (including on Altirra), press V at any time to rectify (this is due to recently discovered "feature" on NTSC VBXE installations). Once the consistency of this feature is confirmed, the support for the V key will be removed.

This seemed to infer that the fix wasn't activated by default, but no matter: if everything's as expected, all's good.

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...