wildstar87

Thanks much!

Can you tell me what settings you used in the special features?

Thanks Simius, what would be the proper settings for 15Khz RGB in the Special features? RGB, Sync mode norm or interlace? and I assume Sync out to Csync?

Unless I'm missing something, I thought RGB specifically referred to RGB 15Khz, otherwise I'm not sure what RGB standard we are talking about, because technically VGA is RGB, just at a specific frequency. YPBPr is component RGB, which again is also RGB (sorta) just based on a different standard from my understanding. https://thecablesland.com/ypbpr-vs-rgb/ If it doesn't support 15Khz RGB, to output to ST color monitors, or Commodore/Amiga monitors RGB, then that's a simple answer, but I just want to make sure that's the case.

Strange, I thought that was why there was a specific RGB mode with interlace, since there is a specific VGA mode. @Simius can you chime in here?

Yeah I'm using an DVI to VGA adapter that I had, I have a few others I can try, but I don't think this is the problem. It works in VGA mode, just not 15Khz RGB. It has the 5 pins for the analog section.

Tried different settings to get 15Khz RGB working. Trying to verify 2 different monitors for RGB. I have an Amiga 1080 CRT monitor, and a Dell U2410. I'm not getting any response out of either monitor with Sophia. U2410 seems to sort of work with VBXE (though having other issues), I am getting an image though. The 1080, I have switched over to RGB Analog, on the back, and RGB on the front. I'm not getting any picture at all. Tried settings in Sophia, to RGB, and both norm or interlaced settings, though I was able to get VGA out. Any ideas?

Thanks, that was it.

Trying to setup Sophia to output RGB 15Khz, running Sconf.exe I don't see a way to change the special features, cursor only rotates through resolutions. I'm missing something..

Thanks woj! That's good to know. Now I just have to get a Scart cable, and mod it. I'm crossing my fingers that this will finally work out!

I know, but I'm not telling..

Hmm, based on this, it sounds like I should just make a small sync stripper circuit to do it correctly. But for simplicity's sake, the voltage divider would be quicker. I'm assuming 2 resistors in series running from Csync(4050) to GND, with Csync (OUT) tapped in the middle. What resistors would you suggest? You mention 0.3v, but I've also seen 0.7v or 1v mentioned in the Csync discussions I've seen.

If you could check, that would be great, I just want to prep for success with this.

130XE Remake board

So on that note, does anyone have experience hooking VBXE up to a Retrotink 5X-Pro? It isn't as straightforward as I thought. I'm going to have the create a SCART cable, which isn't that big a deal, I'm mostly worried about the CSYNC. From the wiki it states: Sync The TINK-5x accepts sync on luma, sync on composite and c-sync RGB over SCART configurations. Check with your SCART cable manufacturer to ensure compatibility with the RetroTINK-5x Pro. Note that TTL-level sync is not supported by the TINK-5x and may damage your hardware. Note that RGsB (such as the PlayStation 2's RGB output for 480i/480p titles) is not supported. My memory is a bit fuzzy, but I seem to remember when putting together my 1088XEL, the Csync signal needed an inline resistor, so I'm guessing that the output of the 4050 Csync is TTL? I finally found the information in the RGB2VGA thread: The only signals required from the VBXE are R, G, B, Csync, and Gnd to P11 (RGBS in) on the GBS board. If you look at the RGB2VGA-XLD board's silkscreen on the board images I posted yesterday you'll see the position of these signals on that connector. Off the top of my head, I believe Csync is the gray wire on the P11 harness. Control would not be used for this application. Nor is separated sync (Vsync, Hsync) required. However, and this is important, a 470-680 ohm resistor should be connected in series on the Csync line from the Atari to the GBS. If you don't do this, the 5V Csync going directly to the GBS will eventually damage a chip on the GBS board. It can't take anything above 3.3V. I'm just wondering if this is all I need to do with the Retrotink, or should I look into building a sync stripper circuit from the LM1881, LMH1980, or ISL59885ISZ. The last thing I want to do is inadvertently fry the Retrotink, as it isn't cheap at all.

Thanks for getting this pushed through Piotr. It gives me a bit more motivation to trying to get it working.

Is it possible to "flash" the emulated VBXE to the recently release NTSC core, or is that something that you would have to change in the emulation?

I think you meant that XEGS Mode = Off should be when a stock keyboard IS installed in the system. 🙂

That was it, thanks! I was really close, it was specifically XEGS mode off, I was trying it on. I read through the manual, but for some reason, completely missed the note. Note: If the stock keyboard is to be used in parallel with the TK-II, then the XEGS Mode should be set to OFF. This feature is toggled by pressing CTRL+ALT+X, with the last setting retained in non-volatile memory.

I'm running into another problem. I've been using the TK-II on the 130XE Remake board, and it's been working fine with PS/2 Keyboard. I'm working on putting in a new mechanical keyboard into the 130XE from @ScreamingAtTheRadio, and I was having issues having the keyboard working at all. All the function keys other than Help seem to work, all other keys don't. It seems that if TK-II is installed, it blocks the inputs from the physical keyboard, but if I remove the PIC chip entirely, the keyboard does work. I hadn't been using the built-in keyboard, since I've been fiddling with upgrading it, so never used it along with TK-II, which is why I never saw this before. Doesn't seem to matter if the PS/2 keyboard is plugged in or not. I also tried using the plug-in board, in place of using the built-in, with the same results, both were using the the 2.7J firmware. I know you mentioned some issues using the built-in keyboard with TK-II in the past, but thought you had fixed those with later firmware. Just to make sure, I also did try with the stock 130XE keyboard, and got the same results. I did try the XEGS mode, though it didn't seem like the same issue. Any ideas?

I know that the Altirra NTSC palette was discussed a while back (and I thought decided on). I'm actually thinking this is the same one being used by the U1MB plug-in, but FJC would know for sure.

Well if I can get it working again, will look at Rocky. It might have gotten fried somehow before my last attempt, so if it is, I'm not going to be overly disappointed. IMO, the PCB quality on VBXE is worse than an XE motherboard. I had to change headers on it, and have lifted pads/traces so easily, using proper desoldering iron, unbelievably fragile in my experience. Tried seeing if I could get a replacement PCB, was met with utter silence.

Yeah, pretty much the same story with me, tried multiple GBS (Mytek, and GBS-Control), multiple monitors with supposedly 15Khz compatible, tried PAL and NTSC configs, seemed to sort of get it working, got sidetracked into "fixing" the color problem, before finding out about PAL palette, then for a number of reasons, all my A8 stuff sat apart for a few years, just getting back to it earlier this year, and have to install VBXE and try to get it working one more time, last time was not successful, it might be fried. Was also going to try VGA conversion after Candle posted details, still might, though Retrotink 5X Pro is supposed to do 15Khz, and one of the reasons I bought it, though mainly for a better S-Video/Composite upscaling. Lots and lots of money down the drain. 1088XEL build has been cheap in comparison to all the stuff I bought since then, going down the A8 Hardware rabbit hole.

Well, I can speak to why I bought it. I was having issues with monitor incompatibly with previous Sophia DVI, and was reluctant to buy a new monitor just for that, extremely short sighted of me but in my defense, I was literally just getting back into 8-bits and was building a 1088XEL as my only A8 computer, and wasn't a cheap solution, but was unbelievably cool, so was trying to save money. All the features that you mention there, made it sound like VBXE would be the better solution, and not knowing about the NTSC palette issue, as well as how difficult a 15Khz RGB compatible monitor/interface would actually be to find, I thought it would be a better solution with even more features, including the possible use of the Ram upgrade feature. In retrospect, it would have been an order of magnitude cheaper for me, to just buy a new monitor that worked with Sophia, but the issue was that I don't remember there being a list of compatible monitors, so it would have been a crapshoot finding one that worked, since there wasn't a way to figure out ahead of time if a DVI monitor would just work. Also, if I remember at the time, there were only two ways of getting high quality output to a monitor, 15Khz RGB w/Sophia or VBXE, or DVI with Sophia, at that point, at least in the VBXE manual, just as now, had indicated the VGA output core had been deprecated, and easily found instructions weren't available until recently on how to exactly do this. Sophia2 is MUCH better with DVI compatibility, and offers RGB and VGA output signals as well, so unlike the 2 previous solutions, at least for me, it has been ridiculously easy as a video upgrade, literally plug and play for the most part, and MUCH easier to install than VBXE. I think if Simius had offered the full VBXE feature set (higher res graphics, 80 column, etc.) and app compatibility on Sophia2, not only would it be even more popular than it is currently (chip shortage not withstanding), there would literally be no reason to buy a VBXE, as it would basically solve all the issues that have been talked/argued ad nauseum for over a decade, and that horse has been properly beaten not only to death, but into mush. I'm sure these long standing issues, and lack of real solutions to said issues, plays into why VBXE isn't more prevalent, and at least partially causes the catch 22 of developers not taking more advantage of VBXE, because not enough people have VBXE. Vice versa, people won't buy VBXE because of said issues, lack of solutions, and/or lack of software support. Otherwise, absolutely it would be a slam dunk with the features it had. It also just occurred to me, that if someone could somehow combine features of U1MB, VBXE (w/HDMI/DVI output), and maybe PokeyMax, into one board/upgrade, that truly would be the ultimate upgrade. Though I'm sure it would be a bit more $$, but might be less than all 3 together, and possibly be easier to install with just one board. I'm sure actually implementing this wouldn't be easy, but would be unbelievably cool nonetheless.

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.