NTSC core for VBXE?

[+Stephen]

A good day this is!

[ijor]

10 hours ago, Piotr D. Kaczorowski said:

I keep trying to understand why Electron can't compile a version with the NTSC palette, without all that NTSC Artifacting.

 

I understand the reasons that they don't release an updated core are:

 

Electron has some personal issues.

The FX core takes almost all FPGA resources and that makes a PITA to compile.

The relation between the developers and the hardware manufacturer is not ideal, as we all know. This doesn't encourage much development if at all.

 

Please don't argue with me about this or ask more details.

 

Regarding Quartus, the compiler and tools for the FPGA. The FPGA used by the VBXE is quite old and is not supported by newer Quartus versions. Furthermore, not only that is not supported, there is no Quartus version old enough available from the official Intel/Altera web site. In the old Altera days you could download every single Quartus version from their FTP site. But Intel, in its infinite wisdom, removed most of the older Quartus versions some time ago.

 

This doesn't mean that it is impossible to get a suitable Quartus version. As you could imagine, it is available "online". And of course that as long as you keep the old version yourself, it should work. You might need to update the license, but Intel does still support license updates for those older Quartus versions.

 

And yes, there is no problem in running older Quartus versions under a VM. I do that all the time.

Edited August 27, 2023 by ijor

[Piotr D. Kaczorowski]

3 hours ago, ijor said:

Please don't argue with me about this or ask more details.

 

 

I won't argue on this matter, but if I may share my comment once...

 

I am here in Poland, specifically in Warsaw, so these stories are quite close to me. It's somewhat funny, and somewhat tragic. Looking at it entirely objectively, as someone relatively new to this community (my Atari history spans from 1986-1991 and now 2020-), I would say that a manufacturer is a business person and basic disputes usually revolve around publishing purchased projects, which contradicts the manufacturer's interests, delays in delivering commissioned projects, and not following through with support. On the creators' side, the main issue is usually finances and a lack of business acumen. However, the overarching theme should be that the project is not created for oneself or the manufacturer, but for the community. Unfortunately, these issues also apply to other projects like SIDE, Rapidus, or VBXE. Of course, these encompass both problems and opportunities for new projects to emerge.

 

Let me put it this way, in relation to designing a new turbo card that will replace Rapidus, I had to undergo an apprenticeship in familiarizing myself with clock-related issues and the instability of expansions interacting with each other. The result of my work (or perhaps more accurately, my passion) is a small circuit called O2/Fixer. It's so small and budget-friendly (it costs 29 PLN in Poland, which is 7 USD or 6.5 EUR) that I didn't even want compensation for it. I'm glad to have made a small contribution, something very simple in the final version. The manufacturer even included information about me in the manual and on the board, and when I ordered the first three units myself, they sent me a dozen more. At least SIDE3/3.1 started working in computers, and the Ultimate 1MB finally runs normally with BO2.

 

Either way.. One can do something for oneself, something for the community, and something for money. Currently, financing these projects looks like using crowdfunding services, and there are many people who are willing to contribute a donation monthly for the development of such projects. Based on my calculations, for example, in the case of a project like Rapidus, it's a few hundred times a few dollars a month, which adds up to quite substantial amounts over the course of a month or year. Perhaps even more than the amounts currently exchanged between the manufacturer and the creator. But... you have to be willing, not just demanding.. In the end, everyone loses.

 

 

3 hours ago, ijor said:

Regarding Quartus, the compiler and tools for the FPGA. The FPGA used by the VBXE is quite old and is not supported by newer Quartus versions. Furthermore, not only that is not supported, there is no Quartus version old enough available from the official Intel/Altera web site. In the old Altera days you could download every single Quartus version from their FTP site. But Intel, in its infinite wisdom, removed most of the older Quartus versions some time ago.

 

This doesn't mean that it is impossible to get a suitable Quartus version. As you could imagine, it is available "online". And of course that as long as you keep the old version yourself, it should work. You might need to update the license, but Intel does still support license updates for those older Quartus versions.

 

And yes, there is no problem in running older Quartus versions under a VM. I do that all the time.

 

In my opinion, in this whole situation, for example, the author(s) could independently value their willingness to compile the core with just the NTSC palette, regardless of the manufacturer. Otherwise, there will be individuals like me who will eventually create a mini board that can be inserted into the computer, which will work its magic. It will take control of the computer briefly after boot (similar to how U1MB does) and load that darn palette. Furthermore, such a board would cost just a few USD again and sell like SAVO hundreds of times, and... someone else will benefit from it, not the authors of VBXE. Where two are fighting, a third benefits.

 

[ijor]

5 hours ago, Piotr D. Kaczorowski said:

I won't argue on this matter, but if I may share my comment once...

 

You might be right, or you might be not. But please respect these developers that contributed so much to the Atari. I'm not sure if that was your intention, but I don't think it is correct to start a rant mixed with marketing for your own products.

Edited August 27, 2023 by ijor

[Piotr D. Kaczorowski]

16 minutes ago, ijor said:

 

I'm not sure if that was your intention, but I don't think it is correct to start a rant mixed with marketing for your own products.

It was just an example... In a moment, I'll have to type two asterisks in the middle so there are no suspicions

 

16 minutes ago, ijor said:

 

You might be right, or you might be not. But please respect these developers that contributed so much to the Atari.

 

In the last 24 hours, I wrote that I am impressed with the work that has been done over the years. I am full of admiration for the talent, but I am most impressed by people who can cooperate with each other, rather than argue. I hope such people are here as well.

 

 

 

[wildstar87]

I was hesitant to comment on this, as I was basically bullied that last time I dared criticize VBXE, and gave details on the drawbacks, to someone who was ASKING for details on VBXE, but I appreciate you bringing this issue up again Piotr.  I understand all the arguments about why these issues exist, I'm even accepting based on the development situation, that these are issues that are either not easily fixed, or can be fixed at this point.  My bone of contention, is that this NTSC palette issue was well known long before I bought it, but unless you happened to run across this information in the many VBXE threads, there is no information regarding this issue, with the main vendor who sells this in the details of the product page, to this day.  I had spent a large deal of time and money trying to "fix" this and other issues, without knowing that it was inherent to decisions of default palette.  I can be impressed by the new capabilities of a device, but I think it is disingenuous at this point, that genuine criticisms are swept under the rug, by those that don't really care, or are affected by this issue or others, and that these are still not detailed to those would would be trying to purchase this on the product page.  Note, at this point a lot of the issues could be avoided by the main vendor being upfront about these details, and let the customer make an informed decision, instead of having to discover these after the fact, after money and time has been spent.  Also, no where am I saying that this device does not work, and some of the features are very desirable, and still have no equivalent even today in the other competing devices, but after all of this, it has left a bad taste in my mouth to this product. 

[_The Doctor__]

There is a software based palette swap of some kind, but it is not persistant, takes load time and some memory etc etc etc. take a look through the threads. My thoughts were, if there is software to switch/load or adjust the palette, why wouldn't it be just as good to be able to program it in the vbxe itself. A no brainer thought that soon became an argument for no reason. It just makes sense to do it, but no.

[Piotr D. Kaczorowski]

33 minutes ago, wildstar87 said:

I was hesitant to comment on this, as I was basically bullied that last time I dared criticize VBXE, and gave details on the drawbacks, to someone who was ASKING for details on VBXE, but I appreciate you bringing this issue up again Piotr.  I understand all the arguments about why these issues exist, I'm even accepting based on the development situation, that these are issues that are either not easily fixed, or can be fixed at this point.  My bone of contention, is that this NTSC palette issue was well known long before I bought it, but unless you happened to run across this information in the many VBXE threads, there is no information regarding this issue, with the main vendor who sells this in the details of the product page, to this day.  I had spent a large deal of time and money trying to "fix" this and other issues, without knowing that it was inherent to decisions of default palette.  I can be impressed by the new capabilities of a device, but I think it is disingenuous at this point, that genuine criticisms are swept under the rug, by those that don't really care, or are affected by this issue or others, and that these are still not detailed to those would would be trying to purchase this on the product page.  Note, at this point a lot of the issues could be avoided by the main vendor being upfront about these details, and let the customer make an informed decision, instead of having to discover these after the fact, after money and time has been spent.  Also, no where am I saying that this device does not work, and some of the features are very desirable, and still have no equivalent even today in the other competing devices, but after all of this, it has left a bad taste in my mouth to this product. 

I rediscovered my love for Atari only in 2020 and have been rummaging through some things, sometimes finding beautiful apples, but with a worm inside.

 

In fact, I bought Atari because I saw that there were such great solutions as Ultimate 1MB or VBXE. There are probably many others to list. New solutions also change the situation from the 80s and 90s, making it possible to achieve most things internally without the need to drill into the casing. Before I installed my first VBXE, I asked at least four leading creators here in Poland for help with a Sega Saturn connector board project. To no avail. Later, I took the DipTrace program and made it myself. I decided to use the product name once every few days, as there are also people here who think that I am purposely promoting it (I don't have to... it's already sold very well). However, I am interested in popularizing VBXE, because I believe it's looking to the future. The product is great, but it has a few minor issues that can be easily resolved. The palette is an example. Yesterday I started searching and I have a whole set of software that allows you to change what is needed. I also offered Lothar that I can build him (free of charge) a VM machine that will already have the software installed. I haven't discussed whether he has the rights to it. Can it be done? Yes, it can.. There is a core with a different palette in Poland. It's clear that changing the palette purely in software is an incomplete solution. I don't know why the people responsible for the project haven't done this so far, but of course, it's not serious. Just... one can be a great engineer but still have a child's mentality - it happens

 

Either way, there are other methods, without special involvement from the authors, to address the issue. Of course, it would be easier with the authors.

[+Stephen]

I still don't understand how a maximum of 768 bytes has caused this many issues for over a decade.

[bfollowell]

54 minutes ago, _The Doctor__ said:

There is a software based palette swap of some kind, but it is not persistant, takes load time and some memory etc etc etc. take a look through the threads. My thoughts were, if there is software to switch/load or adjust the palette, why wouldn't it be just as good to be able to program it in the vbxe itself. A no brainer thought that soon became an argument for no reason. It just makes sense to do it, but no.

I agree. I don't recall the details, and maybe there's a good reason, but I don't see why we couldn't have an NTSC version and a PAL version, then each just has only the appropriate palette.

 

There's a plug-in for the U1MB that allows you to select an NTSC palette though, assuming you have both installed in the same machine, correct?

 

[Piotr D. Kaczorowski]

3 minutes ago, Stephen said:

I still don't understand how a maximum of 768 bytes has caused this many issues for over a decade.

https://madteam.atari8.info/index.php?prod=vbxe

https://madteam.atari8.info/vbxe/rocky_pal.7z

 

If there is a PAL (LAOO) palette and a PAL (ROCKY) palette and there is no NTSC palette, then it's probably not a technical obstacle. If someone doesn't have the software, it can be found. If one wants to be more legal, they can find a company that legally acquired it years ago and commission a recompilation.

 

 

[leech]

30 minutes ago, bfollowell said:

I agree. I don't recall the details, and maybe there's a good reason, but I don't see why we couldn't have an NTSC version and a PAL version, then each just has only the appropriate palette.

 

There's a plug-in for the U1MB that allows you to select an NTSC palette though, assuming you have both installed in the same machine, correct?

 

In my mind, you could feasibly have a U1MB without the VBXE, but a VBXE without a U1MB seems like an odd choice, no?

[bfollowell]

11 minutes ago, leech said:

In my mind, you could feasibly have a U1MB without the VBXE, but a VBXE without a U1MB seems like an odd choice, no?

I agree. I could easily see the U1MB without the VBXE, but not the other way around.

 

[Piotr D. Kaczorowski]

4 minutes ago, leech said:

In my mind, you could feasibly have a U1MB without the VBXE, but a VBXE without a U1MB seems like an odd choice, no?

The Ultimate 1MB paired with VBXE is obviously my first choice. What's more, by adding SRAM 64K under the processor, you can remove Freddie and activate 3.5Mhz directly on the board. At that time, Freddie doesn't manage memories, nor does it divide 14Mhz into 3.5Mhz. This is significant because those two rectangular signals in the Fourier series equate to an infinite number of sinusoids. At least that's the theory, and in practice, normally, rectangles don't go there, but something more characteristic of NMOS shape. Overlaying these frequencies creates a broad spectrum of noise. Additionally, Freddie occupies the BO2 line (Buffered Phase 2) as another chip. So once again, these are devices that work great together. For greater stability, you can use the O2/Fixer from Lotharek (a small advertisement, but I think it's okay since I don't benefit from it).

 

But... it's 2023 and some people read more and discuss more. So... Does VBXE/VBXL without Ultimate 1MB make sense?

 

Beside me is a 600XL board on which I'm currently mounting a VBXL without the Ultimate 1MB. Why? Because:

• you can activate a core in VBXE/VBXL that adds an additional 320KB of Rambo,
• alternately, you can also use the AVG Cart, which adds up to 1MB without an internal installation.

So... you can use it without U1MB. Sometimes, for financial reasons, people plan their subsequent installations.

[Peri Noid]

52 minutes ago, bfollowell said:

I agree. I could easily see the U1MB without the VBXE, but not the other way around.

Well, I have a machine with VBXE but without U1MB. Additional RAM can be provided by VBXE itself (256KB) but this machine also has a 1MB old-school SIMM expansion. 

[leech]

50 minutes ago, Piotr D. Kaczorowski said:

The Ultimate 1MB paired with VBXE is obviously my first choice. What's more, by adding SRAM 64K under the processor, you can remove Freddie and activate 3.5Mhz directly on the board. At that time, Freddie doesn't manage memories, nor does it divide 14Mhz into 3.5Mhz. This is significant because those two rectangular signals in the Fourier series equate to an infinite number of sinusoids. At least that's the theory, and in practice, normally, rectangles don't go there, but something more characteristic of NMOS shape. Overlaying these frequencies creates a broad spectrum of noise. Additionally, Freddie occupies the BO2 line (Buffered Phase 2) as another chip. So once again, these are devices that work great together. For greater stability, you can use the O2/Fixer from Lotharek (a small advertisement, but I think it's okay since I don't benefit from it).

 

But... it's 2023 and some people read more and discuss more. So... Does VBXE/VBXL without Ultimate 1MB make sense?

 

Beside me is a 600XL board on which I'm currently mounting a VBXL without the Ultimate 1MB. Why? Because:

• you can activate a core in VBXE/VBXL that adds an additional 320KB of Rambo,
• alternately, you can also use the AVG Cart, which adds up to 1MB without an internal installation.

So... you can use it without U1MB. Sometimes, for financial reasons, people plan their subsequent installations.

This is all true of course.  I need to play with my AVG Cart... it has been sitting in its box for far too long!  But the two systems I have with VBXE both have U1MB in it, and the 130XE also has the Rapidus / Stereo Pokey (and now Decent XE Keyboard too!)  Last I went to snag the SRAM for that one, I thi k Lotharek was out of stock, or wherever else I was trying to buy it (maybe it was Brewing Academy).  One of these days I will get it all set up again...

[wildstar87]

1 hour ago, Piotr D. Kaczorowski said:

If there is a PAL (LAOO) palette and a PAL (ROCKY) palette and there is no NTSC palette, then it's probably not a technical obstacle. If someone doesn't have the software, it can be found. If one wants to be more legal, they can find a company that legally acquired it years ago and commission a recompilation.

 

 

What is the ROCKY palette in any case, I haven't heard about this?  I know earlier in this thread, or another thread it was being discussed with Candle to use the NTSC palette that Altirra uses, which there seemed to be a consensus on, but nothing ever came of it.  At some point I had decided to live with the palette issue, but had tried both GBS-8200, and other possible 15Khz compatible monitors, that could be had for less than a ransom price.  I had some limited success, but nothing completely satisfactory, I recently got a Retrotink 5X-Pro, and will try one more time to get livable result with VBXE, but haven't yet thus far, as I have had other projects that I have been focusing on, as well as dreading another failure for time spent.  If it doesn't work for me, I think I'm done with VBXE.

[flashjazzcat]

1 hour ago, bfollowell said:

There's a plug-in for the U1MB that allows you to select an NTSC palette though, assuming you have both installed in the same machine, correct?

Correct, and this takes no measurable time to install and is functionally identical to having the NTSC palette built into the FX core.

 

I've spent ten minutes or so analysing a diff of the default FX core and the 'rocky' core, and although the differing bytes are spread throughout the binary in an apparently non-determinate manner, there's obviously some rationale behind it and I assume the simplest thing to do (in the absence of any cooperation from Electron) would be to figure that out and import the NTSC palette into the binary. I don't know what the story is behind the 'rocky palette' FX core or whether it was endorsed by the core developer. If it was endorsed, then that would presumably set a precedent that it would acceptable to create another spin-off core with a different palette, and if it isn't endorsed, the rocky palette core nevertheless exists, was built somehow, and would presumably be no more or less legitimate than the same core but with the NTSC palette.

 

All that said, I wouldn't wish to advocate the 'hacking' of a binary if the developer had already expressed disapproval of this approach, and given that U1MB and VBXE appear to be considered a match made in heaven (and I - likewise - feel there's something amiss about a system equipped with VBXE but not U1MB) and the solution I provided (a soft-loaded NTSC palette which installs in a matter of milliseconds before the OS even comes up at power-on and stays there until power-off), it's difficult to see whether the lack of a built-in NTSC palette is an actual real-world impediment, or something people are getting annoyed about purely because the developer won't provide it for whatever reason.

 

Don't forget that the U1MB solution allows the anyone capable of assembling the plugin to replace the NTSC palette with anything they like.

[bfollowell]

7 minutes ago, flashjazzcat said:

Correct, and this takes no measurable time to install and is functionally identical to having the NTSC palette built into the FX core.

 

I've spent ten minutes or so analysing a diff of the default FX core and the 'rocky' core, and although the differing bytes are spread throughout the binary in an apparently non-determinate manner, there's obviously some rationale behind it and I assume the simplest thing to do (in the absence of any cooperation from Electron) would be to figure that out and import the NTSC palette into the binary. I don't know what the story is behind the 'rocky palette' FX core or whether it was endorsed by the core developer. If it was endorsed, then that would presumably set a precedent that it would acceptable to create another spin-off core with a different palette, and if it isn't endorsed, the rocky palette core nevertheless exists, was built somehow, and would presumably be no more or less legitimate than the same core but with the NTSC palette.

 

All that said, I wouldn't wish to advocate the 'hacking' of a binary if the developer had already expressed disapproval of this approach, and given that U1MB and VBXE appear to be considered a match made in heaven (and I - likewise - feel there's something amiss about a system equipped with VBXE but not U1MB) and the solution I provided (a soft-loaded NTSC palette which installs in a matter of milliseconds before the OS even comes up at power-on and stays there until power-off), it's difficult to see whether the lack of a built-in NTSC palette is an actual real-world impediment, or something people are getting annoyed about purely because the developer won't provide it for whatever reason.

 

Don't forget that the U1MB solution allows the anyone capable of assembling the plugin to replace the NTSC palette with anything they like.

 

Agreed. Assuming a user has both devices installed in the same machine, which obviously some do not, but I'd say most do, then it's really something of a moot point.

 

[Piotr D. Kaczorowski]

19 minutes ago, wildstar87 said:

What is the ROCKY palette in any case, I haven't heard about this? 

 

In my opinion, this standard VBXE palette seems a bit faded, and I'm not particularly fond of it. Though there are voices saying that there used to be some special measurements and such... I've installed quite a few VBXE cards this year, and people often say that these standard colors are slightly different.

 

I only found out about the Rocky palette cores relatively recently. I was a bit skeptical at first, as you had to download software, install the core, switch it, etc. Generally, this always makes me wonder if everything will still work properly.

 

It turned out that the update is super easy, and the colors remind me of the standard saturated 600XL - well, maybe not that intense and a bit brighter than NTSC, but still pretty nice. I highly recommend it!

 

19 minutes ago, wildstar87 said:

If it doesn't work for me, I think I'm done with VBXE.

 

Don't worry. You're not alone in this. We'll get through it.

 

 

[+-^CrossBow^-]

Well, I'm in that camp of I have a VBXE and no U1MB because I only use my 130xe to play games and as it is NTSC there hasn't been anything I've been that interested in playing that needed more than the 128k it already had on it. So yeah... I got the VBXE because it was a means to provide RGB at a less cost than the Sophia and was available at the time unlike the other. I purchased mine from a US distro and they didn't state that the colors were PAL. Only an option on which position you wanted the jumper to come to you already set to. I understand that jumper is for the speed clocks, but still it wasn't made clear then that the colors on actual games would be off. Only those games made and using the VBXE look correct. Everything else, I'm essentially relegated back to using the s-video output.

 

So I've hoped for sometime that another FW update would be made for it that could offer NTSC but just assumed it would never come to be. So my VBXE is used for those games or programs that utilize it and it isn't for those that don't display correctly.

 

 

[Piotr D. Kaczorowski]

27 minutes ago, -^CrossBow^- said:

Well, I'm in that camp of I have a VBXE and no U1MB because I only use my 130xe to play games and as it is NTSC there hasn't been anything I've been that interested in playing that needed more than the 128k it already had on it. So yeah... I got the VBXE because it was a means to provide RGB at a less cost than the Sophia and was available at the time unlike the other. I purchased mine from a US distro and they didn't state that the colors were PAL. Only an option on which position you wanted the jumper to come to you already set to. I understand that jumper is for the speed clocks, but still it wasn't made clear then that the colors on actual games would be off. Only those games made and using the VBXE look correct. Everything else, I'm essentially relegated back to using the s-video output.

 

So I've hoped for sometime that another FW update would be made for it that could offer NTSC but just assumed it would never come to be. So my VBXE is used for those games or programs that utilize it and it isn't for those that don't display correctly.

 

 

If I can't get it done with the authors, I'll make a small board that I'll give away for free, which will take control during startup and set the palette immediately... Let's say it'll be 1/100000 of U1MB This should be doable. Of course, it would be best if one could compile the core. There will also be other solutions, but I'll mention that in the future.

[wildstar87]

1 hour ago, flashjazzcat said:

All that said, I wouldn't wish to advocate the 'hacking' of a binary if the developer had already expressed disapproval of this approach, and given that U1MB and VBXE appear to be considered a match made in heaven (and I - likewise - feel there's something amiss about a system equipped with VBXE but not U1MB) and the solution I provided (a soft-loaded NTSC palette which installs in a matter of milliseconds before the OS even comes up at power-on and stays there until power-off), it's difficult to see whether the lack of a built-in NTSC palette is an actual real-world impediment, or something people are getting annoyed about purely because the developer won't provide it for whatever reason.

 

Don't forget that the U1MB solution allows the anyone capable of assembling the plugin to replace the NTSC palette with anything they like.

I am not disparaging of your solution at all, you were the one that came up with viable solution to this problem, with the one drawback that you have to have a U1MB to implement it.  I have a U1MB for my 1088XEL, so have been able to test the solution, but don't have it in my other systems, and since I have Sophia2 in my 1088XEL now, I would rather put that into one of my other machines.  I'm also on principle a little miffed, that to solve a problem that IMO could have been solved earlier on, that you have to buy another not inexpensive device, from the same vendor that has been less than forthcoming about these issues, and hasn't in my estimation tried to clarify, or fix the issue for those of us in NTSC land, because they don't really care, because they have always been PAL.  I'm sure there is something lost in translation between language and culture, but based on the interactions that I have seen on AtariAge with said vendor, when issues are brought up, with products that they sell, you are either met with silence, or somewhat indifferent to rude responses, which has been my experience as well.  Seems happy to sell you anything, but caveat emptor is basically the policy if there are problems.

[flashjazzcat]

Perfectly reasonable criticisms, and the kind of intractibility you're talking about is hardly unprecedented. While the U1MB solution is at least 'clean' and almost what the developer once advocated (namely loading the palette from a FAT partition at boot-time, which would require not only Ultimate 1MB, but SIDE2/3 and much more copious PBI ROM/RAM than the developer had the foresight to provide), any other solution short of actually implementing the palette in the core seems to me a gargantuan bodge. From the moment the first user asked me about an NTSC VBXE core (something which hadn't even occurred to me until that point for reasons I can't even fathom), it was blindingly obvious that in the majority of cases, any user with VBXE in an NTSC Atari would want the NTSC palette, and once they'd installed it, they'd never touch it again. So certainly, the most obvious place for it is right in the core, and why this wasn't thought of fifteen years ago is completely beyond me.

 

The matter of NTSC artifacting and whether there's space to implement that on the FPGA has also been brought up, but I don't see that artifacting or the lack thereof is a make-or-break feature for NTSC users. Most users run the FX core 90 per cent of the time, and this doesn't even implement PAL blending. The GTIA core does, but doesn't implement any other artifacting properties.

Edited August 28, 2023 by flashjazzcat

[leech]

3 hours ago, flashjazzcat said:

The matter of NTSC artifacting and whether there's space to implement that on the FPGA has also been brought up, but I don't see that artifacting or the lack thereof is a make-or-break feature for NTSC users. Most users run the FX core 90 per cent of the time, and this doesn't even implement PAL blending. The GTIA core does, but doesn't implement any other artifacting properties.

Ha, this is why I have multiple machines, for different usecases... 

3 hours ago, wildstar87 said:

I'm sure there is something lost in translation between language and culture, but based on the interactions that I have seen on AtariAge with said vendor, when issues are brought up, with products that they sell, you are either met with silence, or somewhat indifferent to rude responses, which has been my experience as well.  Seems happy to sell you anything, but caveat emptor is basically the policy if there are problems.

I have had extremely great interactions with most of the vendors, sometimes I think it is just luck on what kind of crap they have been dealing with on a given day, or perhaps occasionally read through a request incorrectly,  or of course have been dealing with too many jerks in a short amount of time.

I just try to be patient and clear with what I need.

 

Dealing with FJC is always a delight though!

Edited August 29, 2023 by leech