MiSTer PCXT

[spark2k06]

I understand your point, yes, I knew the reason why ao486 has that combination. Maybe I will consider the idea of changing the functions by some option and as user decision... let me think the most suitable way and as soon as I can I will check it.

You have been able to live for years with this configuration, a little more is fine

[akeley]

You have been able to live for years with this configuration, a little more is fine

Hah, totally right It's not a real problem of course, just a little QoL request. I just came back to this core and started using it more frequently over the last week or so, hence this post.

Thanks again for considering this.

[spark2k06]

I'm really sorry, but I think I'll leave it as it is. I've been looking into it, and it has significant implications. On one hand, it requires modifying MiSTer Main, since that's where the activation of the OSD menu happens for all cores, and where it's currently specified that Win+F12 works for ao486 and PCXT.

On the other hand, keyboard control in the PCXT core is handled by the KFPS2KB.sv module, where the block in charge of event handling for the core was not originally designed to respond to a key combo. If we add the need to manage both options (to accommodate users who are already used to the current behavior), the solution gets even more complicated

In short, it would be way too convoluted for the little benefit it brings.

F12.png

[akeley]

No worries, thanks for checking anyway

[spark2k06]

PCXT:

• Fine adjustment of CRT vertical and horizontal offsets

In addition, the selected CGA mode (hres_mode) is taken into account internally so that the offset values do not have to be readjusted according to the mode displayed on the screen.

I have made an improvement in the image adjustment in the CRTs, now it is a finer adjustment and also allows the same configuration to adapt to different video modes... this would be an example in my CRT:

CRT tuning.png

[thorr]

• Fine adjustment of CRT vertical and horizontal offsets
  In addition, the selected CGA mode (hres_mode) is taken into account internally so that the offset values do not have to be readjusted according to the mode displayed on the screen.
  I have made an improvement in the image adjustment in the CRTs, now it is a finer adjustment and also allows the same configuration to adapt to different video modes... this would be an example in my CRT:

Thank you very much for you continued support of this awesome core, especially in the recent CRT development. Do you have a way to provide a fine tuning adjustment to the overall timing of the signal itself? Some cores allow for a vertical frequency adjustment for example. The reason I am asking is my Toshiba TV has a section of the screen that is unstable. It can almost sync, but it is not quite there. My Panasonic TV in my arcade cabinet looks beautiful. Thanks!

[spark2k06]

Thank you very much for you continued support of this awesome core, especially in the recent CRT development. Do you have a way to provide a fine tuning adjustment to the overall timing of the signal itself? Some cores allow for a vertical frequency adjustment for example. The reason I am asking is my Toshiba TV has a section of the screen that is unstable. It can almost sync, but it is not quite there. My Panasonic TV in my arcade cabinet looks beautiful. Thanks!

Which core for example? To see how they do it. Anyway, I do not guarantee anything, because this core is very special with the precision in the frequency of the CGA, I doubt very much that it can be changed. I imagine that you could always make a last layer of image processing more customized by another module, but I guess that complicates things even more and possibly has other drawbacks such as the introduction of delays, provided that finally the available resources allow it, which I think are not so many. Despite what it may seem, with all the features it has, they are currently very well used.

[thorr]

Which core for example? To see how they do it. Anyway, I do not guarantee anything, because this core is very special with the precision in the frequency of the CGA, I doubt very much that it can be changed. I imagine that you could always make a last layer of image processing more customized by another module, but I guess that complicates things even more and possibly has other drawbacks such as the introduction of delays, provided that finally the available resources allow it, which I think are not so many. Despite what it may seem, with all the features it has, they are currently very well used.

I tried it with both Tandy 1000 and IBM PCXT with CGA. I think I understand all of your other points. I think a last layer of image processing would be very close to the same as using the scaler, which I can do now, but I was hoping to avoid having to use the scaler, and adding a layer of image processing would potentially give the same feeling (a band-aid on top of the real thing that could introduce video artifacts like tearing, delays, etc.). I was hoping that there is a clock frequency somewhere within the CGA card that could be tweaked without affecting the rest of the system, or adjust the whole system together so it still works, only very slightly slower or faster so it hits the screen at a tweaked rate. Thanks!

[spark2k06]

I tried it with both Tandy 1000 and IBM PCXT with CGA. I think I understand all of your other points. I think a last layer of image processing would be very close to the same as using the scaler, which I can do now, but I was hoping to avoid having to use the scaler, and adding a layer of image processing would potentially give the same feeling (a band-aid on top of the real thing that could introduce video artifacts like tearing, delays, etc.). I was hoping that there is a clock frequency somewhere within the CGA card that could be tweaked without affecting the rest of the system, or adjust the whole system together so it still works, only very slightly slower or faster so it hits the screen at a tweaked rate. Thanks!

The CGA module currently corresponds to tubetime's magnificent Graphics Gremlin. It would be great if you or someone else could confirm this issue with one of these cards and your monitor:

The point here is to understand very well why it happens, and what to touch so as not to break something else.

[thorr]

The CGA module currently corresponds to tubetime's magnificent Graphics Gremlin. It would be great if you or someone else could confirm this issue with one of these cards and your monitor:

The point here is to understand very well why it happens, and what to touch so as not to break something else.

Unfortunately, testing that with my TV would be quite the undertaking because I would need to find/buy an XT and that card.

What I can tell you with my own experience in general, is that different TV's respond differently to different video signals, and what looks great on one TV will have issues or not be able to sync at all on another. For example, for whatever reason, the Panasonic in my arcade cabinet will not sync well to the SNES video timings even though the timings are well within my TV's frequency capabilities. I previously searched about this and found others with Panasonic TV's having the same exact issue with SNES timings. I think this is related to the jungle chip used in the TV. Most likely the jungle chip in my Toshiba TV is struggling with PCXT's video timings.

To help find what to adjust, you could put up a test pattern, or even just use the splash screen and memorize what it looks like or take a picture. If you find the right thing to adjust, the picture will either go out of sync or move or resize slightly, etc. If you find that, then make a menu option to adjust that frequency. It should work at several frequencies, and eventually go out of sync.

Thanks again!

[thorr]

The point here is to understand very well why it happens, and what to touch so as not to break something else.

I just looked at the Graphics Gremlin Github page and it states this:
R11 should not be stuffed. By default this means that the 14.318MHz clock is generated on board. If you move R25 to R11, then the 14.318MHz clock comes from the ISA bus. The motherboard's 14.318MHz oscillator isn't always accurate enough for CGA color composite video.

That 14.318 MHz oscillator is quite possibly the thing that needs adjustment. Looking at parts, they come at 14.31818 MHz.

[spark2k06]

To help find what to adjust, you could put up a test pattern, or even just use the splash screen and memorize what it looks like or take a picture. If you find the right thing to adjust, the picture will either go out of sync or move or resize slightly, etc. If you find that, then make a menu option to adjust that frequency. It should work at several frequencies, and eventually go out of sync.

Thanks again!

I will think about it in case I come up with a solution.

[spark2k06]

The point here is to understand very well why it happens, and what to touch so as not to break something else.

I just looked at the Graphics Gremlin Github page and it states this:
R11 should not be stuffed. By default this means that the 14.318MHz clock is generated on board. If you move R25 to R11, then the 14.318MHz clock comes from the ISA bus. The motherboard's 14.318MHz oscillator isn't always accurate enough for CGA color composite video.

That 14.318MHz oscillator is quite possibly the thing that needs adjustment.

Yes, this oscillator is important to generate all necessary frequencies, including video. I don't remember now, but I think in MiSTer I couldn't set it accurately with more PLLs, as it had to adjust to other frequencies used in the core.

[thorr]

Yes, this oscillator is important to generate all necessary frequencies, including video. I don't remember now, but I think in MiSTer I couldn't set it accurately with more PLLs, as it had to adjust to other frequencies used in the core.

It sounds like you might be using the computer's oscillator. Can you isolate it with a separate oscillator from the rest of the core, like the Graphics Gremlin card does as I quoted above? Also, you might have missed it because I edited it later, but I think it is supposed to be 14.31818 MHz. Thanks again!

[spark2k06]

It sounds like you might be using the computer's oscillator. Can you isolate it with a separate oscillator from the rest of the core, like the Graphics Gremlin card does as I quoted above? Also, you might have missed it because I edited it later, but I think it is supposed to be 14.31818 MHz. Thanks again!

I have seen it. I have to check everything well and test, I have moved relatively well to move the project forward, but as for the environment and peculiarities of FPGAs there is much to learn.

[thorr]

I have seen it. I have to check everything well and test, I have moved relatively well to move the project forward, but as for the environment and peculiarities of FPGAs there is much to learn.

Thanks so much for all of your efforts! You are way beyond where I am when it comes to this stuff obviously.

[thorr]

Yes, this oscillator is important to generate all necessary frequencies, including video. I don't remember now, but I think in MiSTer I couldn't set it accurately with more PLLs, as it had to adjust to other frequencies used in the core.

Not sure if it is the right spot, but looking at the code here: https://github.com/spark2k06/PCXT_MiSTe ... pll_0002.v

I see this line:
.output_clock_frequency3("14.814814 MHz"),
and several others near it that looks like to be divided or multiplied versions of that frequency. Perhaps this can be adjusted to 14.3181818 and multiples.

Also, here: https://github.com/spark2k06/PCXT_MiSTe ... /rtl/pll.v

// Retrieval info: <generic name="gui_output_clock_frequency3" value="14.7456" />
// Retrieval info: <generic name="gui_divide_factor_c3" value="1" />
// Retrieval info: <generic name="gui_actual_output_clock_frequency3" value="14.814814 MHz" />

Not really sure if I am in the right area of the code, and where else in the code these numbers may need to be adjusted if they are even the right ones. These would be global adjustments without writing any new code to isolate the CGA card, and may or may not break it.

[spark2k06]

Not sure if it is the right spot, but looking at the code here: https://github.com/spark2k06/PCXT_MiSTe ... pll_0002.v

I see this line:
.output_clock_frequency3("14.814814 MHz"),
and several others near it that looks like to be divided or multiplied versions of that frequency. Perhaps this can be adjusted to 14.3181818 and multiples.

Also, here: https://github.com/spark2k06/PCXT_MiSTe ... /rtl/pll.v

// Retrieval info: <generic name="gui_output_clock_frequency3" value="14.7456" />
// Retrieval info: <generic name="gui_divide_factor_c3" value="1" />
// Retrieval info: <generic name="gui_actual_output_clock_frequency3" value="14.814814 MHz" />

Not really sure if I am in the right area of the code, and where else in the code these numbers may need to be adjusted if they are even the right ones. These would be global adjustments without writing any new code to isolate the CGA card, and may or may not break it.

I am afraid that these values cannot be modified directly. The changes in the clocks are carried out from Quartus, and the precision in one of them automatically affects the others, which is what is reflected in the file you show us.

Although the modifications are usually small, at some points it is critical that they are accurate. That's why we can't so easily adjust that particular clock without significantly affecting other modules.

In short, it is necessary to study it and understand it very well.

[akeley]

I guess your problem, thorr, is just one of the quirks that results from the crossover of both FPGA and CRT tech...

I think I recall seeing similar "instability" that your Toshiba has on one of my Sony conumer sets. And when I use this core on a PVM I do have a strange
"fading out" disappearing image effect when I start a game (it's fine in DOS/Norton and during boot). When I use modelines, this in turn works fine! So, yeah...weird science time

Still, thanks to spark2k06 for further improving the CRT controls...much appreciated!

[thorr]

I guess your problem, thorr, is just one of the quirks that results from the crossover of both FPGA and CRT tech...

I think I recall seeing similar "instability" that your Toshiba has on one of my Sony conumer sets. And when I use this core on a PVM I do have a strange
"fading out" disappearing image effect when I start a game (it's fine in DOS/Norton and during boot). When I use modelines, this in turn works fine! So, yeah...weird science time

Still, thanks to spark2k06 for further improving the CRT controls...much appreciated!

Possibly, but if the CGA card isn't using the expected frequency, that is definitely a place to look to try to fix. My Toshiba works well with almost everything else as far as I recall so I am inclined to think it might be possible to fix in this case. The only other place I can think of where my TV has issues is when using GroovyMiSTer with a few specific arcade games and I expect that because they use strange video modes sometimes. In PCXT's case, the 40 column mode doesn't sync well at all and has a rolling picture, so multiple modes are affected, not just one.

[thorr]

I am afraid that these values cannot be modified directly. The changes in the clocks are carried out from Quartus, and the precision in one of them automatically affects the others, which is what is reflected in the file you show us.

Although the modifications are usually small, at some points it is critical that they are accurate. That's why we can't so easily adjust that particular clock without significantly affecting other modules.

In short, it is necessary to study it and understand it very well.

That makes sense. It is interesting that in the automatic output, that the frequency is higher than expected (if I am looking in the right place) so there is hope that someday it could be addressed and have it make the difference. Regardless, thanks again for your attention to my concern.