NTSC core for VBXE?

[Joey Z]

Well, I finally got around to installing my VBXE. As far as I know, there is no VBXE core that has NTSC colors for the palette by default. I imagine it's not too hard to update the core to contain a different palette, if one had the source.

 

Anyway, I believe Electron was the designer for the VBXE, and still retains rights to the core. Anybody know if he can be contacted to ask for an NTSC core? I don't even know if he speaks English....

 

I suppose you can load a new palette with software, but that won't be persistent between boots of course. I know we just went through this with the Sophia, does anyone remember what palette ended up being used there? Otherwise I have to look through the whole thread again....

[Rybags]

Lotharek makes and sells the VBXE now but I believe candle is probably more involved in development since it went to V2 back around 2009.

 

VBXE uses a modified LAOO.ACT palette which is biased more towards PAL than NTSC.

I've looked at the flashable core file and can't see any embedded data which looks like a palette. It's a fairly easy scan since the core files seem to have lots of grouped zeros and palette files don't.

My guess would be one of these:

- palette not contained within normally flashed core area?

- the palette is compressed or stored out of normal RGBRGB sequence?

- the palette is derived procedurally?

 

The palette is 768 bytes so you may as well assume a 7-8 sector boot program to do your own every time if you go that route.

An alternative if you have a flashable multi-OS upgrade could be to do a modified OS. Would probably be easiest to use the second character set to store the palette and initilization code which would only need to run on coldstart.

[Joey Z]

Lotharek makes and sells the VBXE now but I believe candle is probably more involved in development since it went to V2 back around 2009.

And candle is pretty busy these days it seems, between children and work. The main issue being that it's going to be hard to get in contact and hold his attention, I think. Once he gets the chance to do it, I imagine it's not difficult to compile the HDL with a new palette.

 

VBXE uses a modified LAOO.ACT palette which is biased more towards PAL than NTSC.

I've looked at the flashable core file and can't see any embedded data which looks like a palette. It's a fairly easy scan since the core files seem to have lots of grouped zeros and palette files don't.

My guess would be one of these:

- palette not contained within normally flashed core area?

- the palette is compressed or stored out of normal RGBRGB sequence?

- the palette is derived procedurally?

Most likely option C, the palette is stored in memory within the FPGA, and the memory initialization section of the FPGA core is compressed. Also, since VBXE only has 21 bit color IIRC, the bits may be packed weirdly. Not to mention the synthesis tool can really reorder the bits any way it wants in order to simplify routing within the FPGA. On top of that, modifying in place would be problematic as the Altera bitstream format apparently includes checksums. I actually did look into this, but it seems like an unreasonable amount of work to do.

 

 

The palette is 768 bytes so you may as well assume a 7-8 sector boot program to do your own every time if you go that route.

An alternative if you have a flashable multi-OS upgrade could be to do a modified OS. Would probably be easiest to use the second character set to store the palette and initilization code which would only need to run on coldstart.

I had thought of disk boot for the fix, but this doesn't work so well with my cartridges (which probably mostly have DOS boot disabled I imagine). I had thought of using a modified OS already, I suppose that is possible. My other thought (more involved) was to make a dummy PBI device that performed this function (but that's way more involved, as I said).

 

It just seems to me the cleanest solution (the right way, if I may call it that) is to just make a different core with a proper NTSC palette, especially considering VBXE allows easy flashing of cores (via FC.COM).

[wildstar87]

Did anything ever become of this?  It seems the issues I'm having with VBXE, are looking more and more like this is the solution.

[+Stephen]

Not that I am aware.  I can probably prepare a palette loader if that sounds useful.  I have finally started doing some VBXE coding.

[bfollowell]

I was considering putting a VBXE in my 1088XEL build. This makes me wonder if I really want to though. If the colors aren't true to what I remember on my old 800 and 800XL, I wouldn't want to use it. Is there no way to get a NTSC color palette with a VBXE?

 

[+Stephen]

Guys - trust me.  the VBXE is the coolest upgrade for the A8 I have seen this decade.  Palette is changeable with the 1.26 core.  It adds so much, it's worth it.  I cannot believe the hate this device gets.

[wildstar87]

Definitely would love an NTSC palette if possible.  No clue how to change it though.

[Rybags]

I'm not sure if I looked further into this.  In theory the palette should be in the flashable firmware so you could just put your own one in there and flash into a vacant slot and try it out.

Possibly the palette is compressed in some way or procedurally generated which could make things a bit trickier.

[candle]

for SDX there are tools for palette manipulation

in fact, you can have YUV palette for GTIA and thus use cheap (like $5?) Nintendo Wii HDMI adapter and enjoy HDMI output

you will be limited to GTIA though, since every other piece of software will modify this palette anyways

 

for u1mb users another way would be to persuade FJC to add this as an option for u1mb bios

 

i'm really looking forward for this to happend - it would be very convinient if done properly

i would see it as custom palette or palettes on fat32 side of cf/sd card and u1mb bios fetching it from there

if there are any technical obstacles, or one would like another way (not having side cart or whatever suitable medium there is there) we might discuss it here

 

[flashjazzcat]

There are obstacles. Let's discuss hard coding s new palette in the core.

[candle]

it would be hard to touch, it uses legacy software that might not run on novadays pc, but if i get a palette that everyone (majority) agrees on, then i can try

what kind of obstacles?

[flashjazzcat]

2 hours ago, candle said:

what kind of obstacles?

Off the top of my head:

• User who wishes to use alternative palette may not have U1MB installed in the machine
• New U1MB firmware has been in development for almost five years and the requirement for the main BIOS to access a file system at boot time has come a little late, especially when there are only a few bytes free and 1K available for plugin code

In addition, NTSC users - once an agreeable palette is decided upon - will probably be happy to flash it once and then never touch it again. Continually loading a palette from disk every time the machine is turned on seems like a waste of effort and a waste of code space.

 

[candle]

all code for file manipulation you already have, and i know that some individuals prefer to have their own palettes - especially gfx artists

so if we speak about ntsc users - it might be so, but if you make more general case of it - not anymore

and i don't know there is a single person that has vbxe, but not u1mb (ok, drac030 has, since he uses rapidus)

 

[flashjazzcat]

15 minutes ago, candle said:

all code for file manipulation you already have

Yes: I wrote it and it's in the loader, not the main BIOS.

20 minutes ago, candle said:

some individuals prefer to have their own palettes - especially gfx artists

Nothing stopping them loading palettes using the methods you already outlined (SDX drivers, etc).

21 minutes ago, candle said:

i don't know there is a single person that has vbxe, but not u1mb

I know a few and have installed a few. 'R' core is sufficient as a RAM upgrade for a few users, and (believe it or not... gasp!) not everyone has signed up to the U1MB ecosystem.

21 minutes ago, candle said:

drac030 has, since he uses rapidus

Yep: either U1MB or Rapidus probably had to go.

 

[wildstar87]

I may be talking out my ass here, and no offense to people like GFX artists who want their own palettes, but I think the majority of people would just like the experience that they are familiar with (NTSC or PAL).  I know there are extended features in VBXE, which I have yet to explore, but the main thing I'm using it for, is to connect to more modern LCDs.  I would indeed just want to set it once, and forget it.  Having an NTSC "core" would be most preferable, and when I bought it, I was not aware that this was even an issue, but I've spent a lot of time trying to solve a problem, that looks like it wasn't really a problem per se. 

 

It might even help more VBXE adoption, as during my research to find out what the "problem" I was seeing was, I saw it mentioned here and there, that were it not for the PAL only palette, they would have bought one. 

[+Stephen]

I guess I never paid much attention to it.  Used NTSC machines all my life, until 10 years ago, when I switched to PAL and never used NTSC since.  I got tired of never being able to view the latest greatest demos, games, etc. 

 

That being said, I cannot play Star Raiders with green shields and operate under a "purple alert"

[+mytek]

I didn't realize this was a PAL specific device when it comes to the palette. I just assumed that there were either 2 different cores or a switch to change between PAL and NTSC standards. Sophia doesn't seem to have this problem, but that's probably related to the fact that it's a GTIA device versus an Antic one like VBXE. So I'm presuming that the GTIA has to be totally emulated in the core, and because of the extra video resolution and color, so does the Antic? Where does the palette come from in a stock machine?

 

I agree with Stephen, even though I live in NTSCville I usually run my systems as PAL, so the lack of an NTSC core would not be an issue for me either.

 

[Rybags]

Antic isn't emulated - VBXE gets its socket as that's the obvious way to give the bus access it needs as well a the AN signaling which is for GTIA PF graphics generation.

The core doesn't need to be system specific (aside from the palette differences) since it can sense PAL by the number of scanlines between VSync commands.  

[+Stephen]

Should be an easy update to a new core.  We went from a fixed single palette in earlier revisions, to 4 palettes, all of which are user definable in the current 1.26.  Caveat being, the initial palette only gets reset when the VBXE device cold boots.  If the user changes this one, they have to restore it via code, or cold boot the machine.  It is this that would need to be definable (conditionally loaded on boot).  Is there a spare 768 bytes?

[wildstar87]

Wouldn't it just be easier to detect of the NTSC/PAL jumper to set the palette as well?

[Rybags]

Additional - AFAIK the core is at capacity as I requested bug fixes & extra features... but can't be done.

[gpounce]

i am on ntsc, with a vbxe on an 800xl.  no other mods or interest in additional devices or loading software to reconfig it, but would prefer  the correct palette.  otoh the pal colors are sufficient but not preferred.

 

there is already a ntsc/pal jumper on the device, why not select the correct pallete on that basis?

[Rybags]

I didn't realise the newer version had the select jumper.

But from what I can determine, it has onboard clock crystals to cover both systems which is what the jumper is for.

 

Now the thing I wonder is, you could probably run a PAL machine at NTSC speed for a handy little overclock and the VBXE video signal should still be perfectly valid.

[gpounce]

beg pardon for a possibly stupid question, but is there an atr or similar containing vbxe control/config programs suitable for stock machines?  i've found the vbxe games but not utility programs...  if the vbxe can be configured via an autorun.sys that would be fine for me...   thx!