NTSC core for VBXE?

[leech]

4 minutes ago, Stephen said:

I still don't see why it's so damn hard to just let users burn their own core with their palette of choice.  Arguments done.

Yeah, I am not sure about that either.  It would be an even sweeter device if there were a key you could hold during start up that would pick a palette / region for you.

[candle]

Stephen: output format from design tool is propertiary, possibly compressed and contains checksums - if you want to alter this in any manner without knowing the format, you will fail. position of palette inside file is also non-deterministic, and it is not said it is continuous either

without heavy lifting of hardware design, such things as user-defined burn-in palette are simply not possible

either you'll agree on something, or it won't happend

 

[bfollowell]

Oh, I’m fairly certain that Stephen wasn’t suggesting anything other than us agreeing on a palette. He was merely making a comment that he didn’t understand why it wasn’t designed that way from the beginning, nothing more. I’m certain there were good reasons at the time. It’s always easier to look into a product and see what could have been done differently or better years down the road.

[+DrVenkman]

4 hours ago, candle said:

either you'll agree on something, or it won't happend

Candle, I think the few of us active lately who have VBXE in our NTSC machines have basically agreed on the Altirra NTSC Contemporary palette. See this post:

 

Is there anything else you need from us to produce a core we can test on our machines? 

 

[candle]

i'm not offended or something, just making a point why this is done as it is, and why it can't be done as some people would like it to do

the path of altering existing cores is at least very difficult if not impossible

recompilling the core with altered palette is quite straight-forward, except software used for this is now obsolete, as acex1k fpga are

 

DrVenkman: no, it should suffice

would you test that palette on real hardware using tools mentioned in the thread?

perhaps i'll convince Electron to make ntsc artifacting if someone could explain in tenchnical terms how it is done

mind that vbxe fpga is already at 100% of its resources, so it might not be possible, even though resources taken by pal artifacting could be reused

 

Edited July 18, 2020 by candle
add information

[leech]

4 hours ago, candle said:

i'm not offended or something, just making a point why this is done as it is, and why it can't be done as some people would like it to do

the path of altering existing cores is at least very difficult if not impossible

recompilling the core with altered palette is quite straight-forward, except software used for this is now obsolete, as acex1k fpga are

 

DrVenkman: no, it should suffice

would you test that palette on real hardware using tools mentioned in the thread?

perhaps i'll convince Electron to make ntsc artifacting if someone could explain in tenchnical terms how it is done

mind that vbxe fpga is already at 100% of its resources, so it might not be possible, even though resources taken by pal artifacting could be reused

 

I have tested it on real hardware.  I have a ton of output devices I can look at / compare to see how well it looks on all of them.  Won't go upload crazy, I promise.

If we can get ntsc artifacting, the only reason I would have to plug in a different machine would be for the keyboard!  That would be awesome!  (Also means I need to get on the ball and order parts for my 1200xl, which would make it my 'goto' machine.)

[+Stephen]

4 hours ago, bfollowell said:

Oh, I’m fairly certain that Stephen wasn’t suggesting anything other than us agreeing on a palette. He was merely making a comment that he didn’t understand why it wasn’t designed that way from the beginning, nothing more. I’m certain there were good reasons at the time. It’s always easier to look into a product and see what could have been done differently or better years down the road.

This.  I'm not a hardware guy and would never claim to be.  I do love the VBXE however and try to push people to use it whenever possible.

[+DrVenkman]

1 hour ago, leech said:

If we can get ntsc artifacting,

Personally, I don't want NTSC artifacting out of an RGB display card. Artifact colors a function of composite smear; it maybe exploited by certain Gr.8 software as a feature, but it's a bug of the RF encoding. It is literally an artifact of a flaw in the display technology when pushed to its limit to display "pixels" smaller than a color clock across a scanline. 

 

I put a VBXE into my machine for clean, sharp output including 80 column text. If fake artifacting is enabled, it must be done in such a way to keep the hardware text modes intact. 

[leech]

3 minutes ago, DrVenkman said:

Personally, I don't want NTSC artifacting out of an RGB display card. Artifact colors a function of composite smear; it maybe exploited by certain Gr.8 software as a feature, but it's a bug of the RF encoding. It is literally an artifact of a flaw in the display technology when pushed to its limit to display "pixels" smaller than a color clock across a scanline. 

 

I put a VBXE into my machine for clean, sharp output including 80 column text. If fake artifacting is enabled, it must be done in such a way to keep the hardware text modes intact. 

For sure.  But I don't know why it couldn't be done in a way to keep things clean still when not using the artifacting.  Sounds like PAL artifacting is already a thing for the vbxe?

[flashjazzcat]

8 minutes ago, leech said:

Sounds like PAL artifacting is already a thing for the vbxe?

Yes: in the GTIA emulation code (which sacrifices all the special 'FX Core' capabilities). It simply provides proper PAL blending so that modes like APAC look correct. Several (8 or 12? I forget) cores can be present on the EPROM at any one time and one may switch between them easily enough using the supplied utility. So you could flash both the standard NTSC FX core and NTSC GTIA emulation core and choose between them at will (once they exist).

 

I'm generally in agreement with Herb regarding artifacting properties in general: other than scan-line colour blending (which can be quite useful and may provide a happy default for some users), going full-beans with artifact-generated colour in hi-res mode, etc, may be a bit pointless when one always has recourse to the original video signal (providing one was wise enough to leave it in place) if that's the video output you actually want to look at.

 

Edited July 18, 2020 by flashjazzcat

[+DrVenkman]

6 hours ago, candle said:

DrVenkman: no, it should suffice

would you test that palette on real hardware using tools mentioned in the thread?

Hi @candle -

 

I've tested the NTSC palette on real hardware by running mono's VBPAL utility from the SpartaDOS X command line and loading the NTSC Contemporary .ACT file I uploaded above.  Using a GBS8220, I've got the VBXE output on two VGA screens at once - a 17" Dell CRT, and a 15"Dell LCD. Both look excellent to my eye with a variety of games and vintage application programs. 

Edited July 18, 2020 by DrVenkman
additional info

[phaeron]

NTSC artifacting is harder to emulate than PAL line blending. PAL line blending can be done with a 4bpp 1-H line buffer, two palette lookups per pixel, and a simple averaging circuit.

 

NTSC artifacting needs a shift register to capture a window of luma bits and a filter implementation done with either multiplier/adders and a lookup table. Problem is, this is going to take some core logic space, either for multiplier/adder circuits or lookup table logic. Cheapest implementation I can think of would be to take over the overlay DMA slots and use every other local cycle to fetch an artifacting index from VBXE RAM based on the luma difference between COLPF1 and COLPF2 and the last 8 ANTIC hires bits, then use that index to look up a signed color delta from palette 1 to add with the GTIA color from palette 0.

 

From what I hear, though, the VBXE core is already very full and I doubt this would fit, it'd have to be an alternate core with some existing implementation removed, and it would also require some software to preload the lookup table and palette 1. Which would be an interesting science project, but one that I suspect wouldn't be feasible without asking for the source to be opened for others to try to implement. So for now, I'd recommend just focusing on the alternate palette.

 

[candle]

GTIA only core is not, and if implemented, artifacting would be there, for FX core it would be counterproductive, because you would loose high-res clean output 

 

[leech]

18 minutes ago, candle said:

GTIA only core is not, and if implemented, artifacting would be there, for FX core it would be counterproductive, because you would loose high-res clean output 

 

Yeah, I would think if it were easy enough to flash / swap between the two, we'd get the best of both worlds.

[ijor]

On 7/18/2020 at 8:54 AM, candle said:

the path of altering existing cores is at least very difficult if not impossible

recompilling the core with altered palette is quite straight-forward, except software used for this is now obsolete, as acex1k fpga are

Hi Candle,

 

Isn't there enough demand to make a new version with a modern FPGA or CPLD? I know it would require voltage level shifters, but even then it would probably still be cheaper than using an ancient FPGA. Let alone that you would have lots of logic space available. Just a thought

Edited July 23, 2020 by ijor

[leech]

27 minutes ago, ijor said:

Hi Candle,

 

Isn't there enough demand to make a new version with a modern FPGA or CPLD? I know it would require voltage level shifters, but even then it would probably still be cheaper than using an ancient FPGA. Let alone that you would have lots of logic space available. Just a thought

I would upgrade to a VBXE 3.0 (i think the current version is 2.x?)

[+DrVenkman]

I'd be happy with an NTSC core for the current VBXE. ?

[bfollowell]

1 hour ago, DrVenkman said:

I'd be happy with an NTSC core for the current VBXE. ?

I agree 110%. Guys were trying too get viable NTSC course for our existing VBXEs. Please don't hijack our thread to try to convince candle to totally remake his device. If you interested in that, please start another thread for it, as it isn't related to what were trying to do.

 

Thanks.

 

[leech]

For now I just added

VBPAL NTSCCONT

To my AUTOEXEC.BAT for SpartaDOS X.  Then I can just reset into the SIDE Loader and play whatever.

[candle]

vbxe 3 was planned for few years now, but it was not easy to find the required time

i still have some outstanding projects in my queue, but things are progressing

hardware side is quite trivial, firmware takes most of the time

side3 for example took me and FJC over 2000 hours in total of our time to get to the production stage, and John is still continuing to work on side3 loader to make use of every feature hardware has

[wildstar87]

It sounds like it's been decided, is the updated core available?  On another note, I would like to try using the 256k memory part of VBXE as well, is all that's needed is the right core flash?

[+DrVenkman]

20 minutes ago, wildstar87 said:

It sounds like it's been decided, is the updated core available?  On another note, I would like to try using the 256k memory part of VBXE as well, is all that's needed is the right core flash?

Well, we sort of agreed on the best NTSC compromise but no core was ever provided. In the interim, I’ve since converted my VBXE equipped machine to PAL so I could run demos and such, so the concept is moot for me personally at this point. 

[wildstar87]

I'm still very much interested in getting this done.  I'd like to put this in a 600XL I have that doesn't have the memory upgraded, and definitely want the NTSC to be color correct.

[flashjazzcat]

I could probably implement a solution for U1MB users soon involving a soft loaded palette at boot time since the new U1MB firmware supports 2KB plugins. I guess there's enough room for 768 bytes of data there.

[leech]

The only thing that would then be missing is the (hated) NTSC Artifacting emulation.