VBXE palettes are off on NTSC systems

[+-^CrossBow^-]

Installed the VBXE the other night into my 130xe and noticed pretty quickly that the palettes from it are off compared to the s-video output I get. I've read a bit that says this is normal, but it seems odd to me that it would be off by this much? I've attached an example of two title screens to games from the s-video and my VBXE. These are direct captures but jpg compression still rears its ugly head here.

 

 

The most obvious issue is of course the red in this game looking more purple. However, when I ran the Atari Control Picture test, that appears to be right. So I have to assume it just how some games have been programmed and their specific values being interpreted differently through VBXE vs the actual atari hardware?

[chevymad]

Do you have an U1MB?  FJC's firmware has an option to switch the vbxe to the ntsc color pallette. 

[+-^CrossBow^-]

15 minutes ago, chevymad said:

Do you have an U1MB?  FJC's firmware has an option to switch the vbxe to the ntsc color pallette. 

No. Aside from the UAV that is installed to drive the composite and s-video, and the VBXE it is stock otherwise.

 

[+DrVenkman]

Yep, we know. 

 

I finally just broke down and converted my VBXE machine to PAL since most of the best demos and stuff are PAL-only. Since that machine also has a U1MB in it, I have the option of using NTSC colors for BASIC or whatever when I feel like it. 

[+-^CrossBow^-]

39 minutes ago, DrVenkman said:

Yep, we know. 

 

I finally just broke down and converted my VBXE machine to PAL since most of the best demos and stuff are PAL-only. Since that machine also has a U1MB in it, I have the option of using NTSC colors for BASIC or whatever when I feel like it. 

Apologies, searches on google didn't turn up that thread but after having read through it. It seems pretty clear. The VBXE is excellent, but only if you have a PAL 8-bit Atari computer to use it with. My main gripe with all of this, is that even with the VBXE having been available for nearly a decade now, that none of the sites I visited to purchase the VBXE from make any mention of the palette issues on NTSC systems. I actually bought mine from Vintage Computer since they have it at $100 right now. But they don't mention the palette differences there either. Most strange was the my VBXE arrived with the jumper on PAL and not NTSC. It actually works on that jumper setting, but then I get even more glitches and missing colors and sprite data in some games with it set that way. So I've got it in the NTSC jumper position for now.

 

But ultimately, it would have been nice and only made sense for an NTSC version of the core to have been made, and then have it so that buyers choose which core they want setup on their VBXE at the time of purchase.

 

So am I to assume then that a PAL Atari computer shows the correct colors on these same games? Wouldn't similar issues still be apparent if you then try and load up NTSC games on a PAL Atari computer?

 

 

[+Stephen]

30 minutes ago, -^CrossBow^- said:

So am I to assume then that a PAL Atari computer shows the correct colors on these same games? Wouldn't similar issues still be apparent if you then try and load up NTSC games on a PAL Atari computer?

Yes - the two machines have always been different in the colours they show.  Some games do a test and adapt for this, but most older games do not.  I've ran exclusively PAL equipment (I am in NTSC land) for over 15 years now because of the better software availability, but I know this is not an option for many people.  We've begged for an NTSC only palette for perhaps a decade now and given the response, it's safe to say it will never happen.

[Mark2008]

I have an NTSC 130XE and VBXE, no U1MB.  

 

Of course it's covered in that thread, but it is 7 pages long, so just in case anyone misses it - one of the authors mentioned VBPAL.

 

So, I do use SpartaDos X, part of my boot sequence in Autoexec.bat is VBPAL NTSC.ACT

That loads the NTSC palette.

 

My screenshots look like yours, in the word RGB, with NTSC palette it's blue, without, it's more greenish.

 

 

With VBXE set to NTSC.ACT:

 

 

 

[chevymad]

5 hours ago, DrVenkman said:

Yep, we know. 

 

I finally just broke down and converted my VBXE machine to PAL since most of the best demos and stuff are PAL-only. Since that machine also has a U1MB in it, I have the option of using NTSC colors for BASIC or whatever when I feel like it. 

That's exactly what I did as well. It's actually my XEL that i've got set to PAL. My XLD didn't like the vbxe for some reason. 

[+DrVenkman]

7 minutes ago, chevymad said:

That's exactly what I did as well. It's actually my XEL that i've got set to PAL. My XLD didn't like the vbxe for some reason. 

Mine’s in my XLD. My XEL is still NTSC, as are the rest of my systems. I have the video running out to a GBS8220 scan doubler, then to a 17” Dell SVGA CRT monitor. 

[chevymad]

I had a very similar setup with my xld. But a Dell  2001 monitor instead. It just didn't always work or look like I thought it should. My XEL has alot fewer issues with the vbxe for some reason. I'm now using an OSSC instead of the gbs, and a vizio tv that will accept 50hz.  The XLD is back to just using Svideo to the dell monitor now.  Everythings NTSC except the one XEL. It is nice to have  at least one PAL machine.

[+-^CrossBow^-]

1 hour ago, Mark2008 said:

I have an NTSC 130XE and VBXE, no U1MB.  

 

Of course it's covered in that thread, but it is 7 pages long, so just in case anyone misses it - one of the authors mentioned VBPAL.

 

So, I do use SpartaDos X, part of my boot sequence in Autoexec.bat is VBPAL NTSC.ACT

That loads the NTSC palette.

 

I only use my Fujinet and as a result I have to press reset after each game I want to change. Therefore this isn't a solution I can use. I'm going to just have to live with it at this point or if it really sets me off too much on a particular game, I will just via s-video output. 

 

Another very annoying thing I've found with the VBXE is that every so often when powering on the 130xe or resetting out of a game to get back to the FujiNet menu, the graphics will actually get corrupted and I have to reset again. In some cases the colors go completely off and the only way to correct is to power cycle the 130xe. When this has happened, I've confirmed it appears the 130xe is apparently not initializing quick enough or something since it is obvious that some sort of corruption is occurring and that is why the video output was wonky. When it has happened I've sometimes plugged in the s-video output and found that the corruption isn't present on the s-video output. So it is coming from the VBXE. As an example, this is how the Fujinet menu screen will sometimes come up on a reset or power cycle of the 130xe. Usually just a reset will correct this:

 

This also seems to happen more often after trying out something that specifically uses the VBXE features. The screen above I believe is how the Fujinet menu came up after playing the VBXE version of Bomb Jack for instance.

 

 

[chevymad]

Mine occasionally does that as well. I'm actually kinda relieved to see that someone else has the same problem. 

 

Since my machine has U1MB, it's actually the u1mb menu's that come up that way for me. I have to completely power down.. wait a few seconds for the caps to discharge and then turn on again. If I turn it on too quickly it will be the same way. 

Edited November 12, 2022 by chevymad

[Mark2008]

On 11/11/2022 at 9:08 PM, -^CrossBow^- said:

I only use my Fujinet and as a result I have to press reset after each game I want to change. Therefore this isn't a solution I can use.

 

 

 

 

In the earlier thread it was reported that VBXE palettes survive a reset. is this not true with the fujinet?

 

I have a fujinet, but I have so far only used it for the json parser under sdx.

 

 I wonder if you could have a regular ATR disk that does nothing but set the palette.  So run that disk after turning on the Atari, after that you could use the system with correct palette, until the next power off.  

 

Of course, what FJC did for U1MB, that would be the ideal solution, update fujinet config for full vbxe palette support.    Frank Rachel and, of course, Thomas Cherry Holmes have done several videos on fujinet config development.

 

My thought here, is it could be possible to have the fujinet to load a VBXE palette, even after a cold start.  With the open source nature of the project and all the videos, this is well documented.  But the one missing piece,  which is I don't know that the source to VBPAL was published....  if that were found, I think it'd be an interesting task for a developer.

 

I'm not volunteering anyone, just musing about the idea, I've been doing some development work....but what would stop me, other than my employer who seems to have me work every weekend, lol....but other than that, I personally would find it helpful to have the VBPAL source, does anyone know if it is available?

[+-^CrossBow^-]

4 hours ago, Mark2008 said:

 

In the earlier thread it was reported that VBXE palettes survive a reset. is this not true with the fujinet?

The VBXE palette might survive a reset, but I honestly have to completely power cycle nearly as often as a full reset in order to get the Fujinet menu to come up properly sometimes as some games/programs seem to put the 130xe into some odd state were a reset will result a single block cursor against the blue or in the case of the VBXE teal background. So yeah, resets on the Fujinet and Atari aren't 100% and require some frequent power cycling of the computer as well.

 

[+Stephen]

5 hours ago, Mark2008 said:

I wonder if you could have a regular ATR disk that does nothing but set the palette.  So run that disk after turning on the Atari, after that you could use the system with correct palette, until the next power off. 

Here's a wild idea I just thought of.  What about a custom OS ROM that ditches the useless self test, and instead checks for VBXE and if found, loads the NTSC palette?  The palette is only 768 bytes, it takes a tiny amount of code to load the palette.  Plenty of space in the 2k self test.  Sad that this is necessary because we'll never get an NTSC core, but I figure if someone has gone through the work of adding a VBXE, what's the extra in using a different OS, I would imagine many VBXE users (myself included) also have U1MB installed.

[bfollowell]

7 minutes ago, Stephen said:

Here's a wild idea I just thought of.  What about a custom OS ROM that ditches the useless self test, and instead checks for VBXE and if found, loads the NTSC palette?  The palette is only 768 bytes, it takes a tiny amount of code to load the palette.  Plenty of space in the 2k self test.  Sad that this is necessary because we'll never get an NTSC core, but I figure if someone has gone through the work of adding a VBXE, what's the extra in using a different OS, I would imagine many VBXE users (myself included) also have U1MB installed.

 

That's a very good point. Some people would probably think, but I don't want to get rid of the self-test, I want to keep my system close to stock. But if that's the case, they wouldn't be installing an U1MB or a VBXE.

 

I think this is an excellent idea. I wish I had the skills to undertake it as a project.

 

[+Stephen]

9 minutes ago, bfollowell said:

That's a very good point. Some people would probably think, but I don't want to get rid of the self-test, I want to keep my system close to stock. But if that's the case, they wouldn't be installing an U1MB or a VBXE.

 

I think this is an excellent idea. I wish I had the skills to undertake it as a project.

I have working code (and there's open examples out there which is what I used) for detecting a VBXE at D600 or D700 and loading a palette.  I can take a look and see how small I can can make it, also noting that no self modifying code can be used (as in some examples) since this will be running in ROM.

 

I'll have to think how to make it execute.  I guess the OS hooks causing the self test code to execute would fire up the detection routine, then the init routine for this, resetting the VBXE, and loading the 768 byte palette.

[Mathy]

Hello guys

 

Wouldn't changing the VBXE core to NTSC be just as much work as kicking out the selftest and replacing it with VBXE-detecting code?

 

Sincerely

 

Mathy

 

[+Stephen]

1 hour ago, Mathy said:

Hello guys

 

Wouldn't changing the VBXE core to NTSC be just as much work as kicking out the selftest and replacing it with VBXE-detecting code?

 

Sincerely

 

Mathy

 

It would be way less I am sure.  But, some of us have been asking for literally TEN YEARS.  Talk about pissing in the wind.  If I had a kid the day I first asked, he would be half way to legal drinking age, and if female, she would be ovulating.  So I think at this point, a custom OS or the U1MB plug-in is the only way we will ever see this.

[Rybags]

There's no VBXE NTSC core.

I'm fairly sure the VBXE doesn't really care what video system is in use aside from knowing what offset from VSync it needs to start generating video.

Aside from that and the sync frequency differences the signal it's generating is exactly the same regardless of video system since it's only encoding RGB.  It doesn't even generate CSync, you pick that off elsewhere.

 

Getting rid of XL Self-Test, probably good idea.  Though I think there are some external dependencies that'd be needed to be taken care of.

An alternative could be - some spare bytes just below $CC00 then use the 2nd character set for the palette data and some code.

Another idea - see if the palette could be algorithmically generated.  Though at best it might just save a couple of hundred bytes but take away the flexibility of having your own default palette.

[candle]

the issue is that core booted too late, and gtia registers didn't get initialized - if you press reset again it will be all good

you can address this issue by changing time constant of reset circuit

 

[bfollowell]

12 hours ago, Stephen said:

So I think at this point, a custom OS or the U1MB plug-in is the only way we will ever see this.

Hasn't FJC already added a VBXE plug-in to the U1MB? I haven't updated firmware in a while, but it seems like I'd read of it somewhere.

 

[+DrVenkman]

2 minutes ago, bfollowell said:

Hasn't FJC already added a VBXE plug-in to the U1MB? I haven't updated firmware in a while, but it seems like I'd read of it somewhere.

 

He has. But the main issue with that is @-^CrossBow^- doesn’t have a U1MB in his system. 

[+-^CrossBow^-]

I appreciate all the input and the fact this has started the conversation again. I'm not opposed to many of these ideas, but it is just that I don't do anything more with my 130xe other than play some games on it from time to time and was just hoping that the VBXE was a good and available way to get RGB output without having to be on the wait list for the Sophia. Plus, in looking it over, I knew I could easily get it up and going with RGB via the methods I use in my RGB setups.

 

Had I known that it would only ever use a PAL specific palette, it would have either changed my mind in getting one or at least made me think about and be more prepared for the fact that the colors would be off and I would have at least known it was a known issue.

 

I blame myself for not searching and doing more research on it, but given the talk and mention of it I'd seen in some of the other threads like the Bomb Jack Gacek(sp?) thread I didn't see mention or missed anything about the VBXE really only being for PAL setups. I do find it interested that it only seems to affect the palette from software that is using the onboard video and not the VBXE since software for the VBXE seems to look correct and looks great! It surprises me that if the VBXE is emulating those signals back to the GTIA etc... that NTSC wasn't considered in regards to palette differences already? Especially given that there is a jumper for setting the crystal clock to match.

 

I hadn't planned on getting or installing a 1UMB because it doesn't seem like something I would need or use the features of very much. It still isn't really something I'm considering so at least for now I'm staying with the slightly off colors. I will state that I do see some vertical bars in the RGB output similar to what I've seen on my s-video. That said, the s-video output doesn't seem to exhibit this as much as it did prior since I removed the RF modulator from the system. Had I known that would clear up my jail bar issues on my 130xe prior to the VBXE, I likely wouldn't have purchased the VBXE now that my s-video has finally cleared up to a point I'm happy with.