wildstar87

It can be used on NTSC or PAL systems, just don't expect the color palette to reflect NTSC standards. For people in Europe that grew up with PAL, it would be fine, for people that grew up in US/Canada, the NTSC palette is very different. I didn't even know there was a difference in the default colors until I ran into this issue. I spent a lot of time trying to figure out if it was the scaler, or something I didn't configure right, and after all that, come to find out it is because of the default palette. I feel this should be disclosed on the sale page, because I either wouldn't have purchased, or I would have gotten it, knowing there were some differences. This had been going on for YEARS before I bought it, and finally it looked like Candle was going to put in the NTSC palette from Alterra in a core that could be flashed, even said when the decision was made, he would do it, but he never did, and at least for me, I have been roundly ignored when asking, politely when this fix would be available. This among my other difficulties, is why I wanted you to know ALL the facts (that I know of anyway) so you can make an informed decision.

I'm am not talking about design specifics, I'm just telling my experience, he wanted to know if it's worth getting, and I felt I had to speak up, especially since unless you are willing to go through extensive threads on message boards, this information is NOT disclosed on the Lotharek website, and Candle's webpage is no longer there. Someone may be expecting to get the stock video experience PLUS the extra functionality, where it actually may not even offer what you expect a stock Atari video to do. As I said, if you had very little issues setting it up, then great, but the problem becomes when you do have issues, and basically there is no support. If had known about this all ahead of time, I probably wouldn't have bothered. Personally I think it's a disservice to not only the customers, but also to the adoption of an enhanced video standard. I saw some complaining about why VBXE has very little products supporting the enhanced modes, well sales are directly impacted by customer experience so I can see why. I'm talking about utilities that are part of Spartados, not something outside of that. I know you are part of the development team, and the Atari community has obviously benefited from the continued development of Spartados, but as with all software development, you have to pick and choose which things have priority. I'm not even necessarily complaining about the fact that these things don't work, it is just the expectation when people say, "yeah Spartados supports it.." That stuff should just work if it's part of the OS, and when it doesn't, that's just one more thing to detract from the product. I always want as much information, when making a decision. Finding out only after you have made the purchase, is not a recipe for satisfaction. Putting this stuff in the sales information just makes sense, so your customer know what to expect, and if they can live with whatever the feature set, or lack thereof is.

Probably, I just like to have all the information before starting on something, because inevitably I run into something that could have been anticipated beforehand. Thanks!

My experience with VBXE has been less than satisfactory, so to provide some perspective. If you are used to NTSC, the color palette will not be familiar, as the one loaded by default is PAL. There are workarounds, but none that allow for a cartridge to be used with an NTSC palette. There was supposed to be a customized firmware to load an NTSC palette instead (it's one or the other due to memory constraints), but never materialized, the developer promised one, but has thus far not provided one, and questions have not been answered. No where is this mentioned on Lotharek's website. RGB 15Khz output is the only output that will be available, again some rumors of a VGA output cropped up, but officially it's definitely not supported. You will have to either get an RGB analog monitor that can do 15Khz refresh, or use a scaler. I went the scaler route and was using a GBS-8200 with mods, and the results for me have been inconsistent, and recently had to get a replacement that isn't working out. I also tried to get a monitor that was 15Khz compatible, and while the monitor I got did display, it was definitely outside of it's normal range, and the picture had a lot of artifacts. NTSC Artifacting does not work on VBXE (or Sophia), so some games like Flight Sim that use this to display color, will not render colors, and be essentially B&W. Support seems to be non-existent, or at the leisure of the developer/seller. Lotharek is happy to sell it to you (and isn't fully disclosing issues), but any issues like this, will need to be handled by Candle, and if he decides not to, then there is no recourse, and no one else can try to come up with a solution, since it's all closed source. Yes, the 80 column is nice, but limited to software with drivers, even in Spartados, not all things are supported, different add-ins, or utils do not work in 80 columns. Don't count on the memory upgrade, there are limitations, and according to what I've read, no protected area, so if you get a situation where you are using it for Ram, and the video portion needs that ram, there is no prevention from it just using it. It may work (I haven't tried it), but you could have issues, that won't be fixed. I'm still trying to get it to work satisfactory for me, but Sophia2 has been a slam dunk for me. It plugs in, offers output to DVI/VGA, for me it essentially just worked. I've spent a lot of money and time trying to get VBXE working, and I'm about ready to be done with it. I originally went to VBXE because my LCD monitor didn't work with the original Sophia DVI, and was interested in some of the other features. I should have just spent the money on a monitor that worked with Sophia, would have saved myself a lot of headache, time, and money. Sophia2 seems to be more forgiving on DVI, and offering the VGA output as well offers another output option. Even if a monitor doesn't work, it's still cheaper to just find a used monitor that will work. I completely regret my purchase of VBXE, since it's one of those products that if you don't have issues, everything is glorious, but if you do have issues, then you are quite screwed. The only reason I'm still trying to make it work, is because Sophia2 is not available due to component availability, and that I'm too stubborn to let it go, since as you see in the posts before this one, it should work just fine. As with most things YMMV..

What value capacitor would normally be used to terminate? When you say Din end, are you referring to the Din 5 (Atari side), or an S-Video Din on the monitor side. I assume that this would apply to RCA jacks as well. What I'm thinking you mean is on the Din 5 side, tie the shields together, and connect to GND pin, and of course signals to their correct pins. On the RCA/S-Video side, only attach the signal lines to the equivalent pins, leaving the shields unattached. One thing I'm a bit unclear on, is when using a coax cable, the shield seems to double as the GND return as well, so how does that work in say a case like the S-Video connector where the 2 of the 4 pins are specifically for GND?

Thanks much Mytek!! I actually have a couple of FMS6400 ICs laying around here somewhere, they were actually for the old Longhorn Engineer video circuit, which is another reason I was interested in this. On another note, I'm going to be using a VGA to BNC cable as the basis for an S-Video/Composite cable. The individual leads are all shielded, but I wasn't sure about grounding. I know you have said that it is the cross-talk between Luma and Chroma that cause a lot of the problems. Would this still happen if the individual shields were attached to a common ground point? I know it is common to ground the shield at one, but not the other, however I also build cables for my job in an aviation electronics company for our engineering lab. We definitely have cables that have the shield tied to backshell at both ends. So it seems that there are reasons for both, so since I figured you probably know best about this, how should the cable be built? All shields tied at the DIN end to ground, and leave them open at RCA end, or vice versa, or some other configuration? I also have seen mention of a diode, or resistor in line, on one of the S-video lines, any merit to that? Thanks again for the help

Was what I circled (with the exclusion of the Csync buffer) what would be considered the whole video circuit?

Mytek, had a question on the s-video/composite circuit for the 576NUC, if I wanted to implement this on a standard XL, other than the Vgate and Chroma switch, is everything else just on the output on the HCT08, and Csync? Can I just take the output from the 4050, or would putting the HCT08 be better instead? I just read through the entire thread, and saw the notes about the Csync buffer being needed to not kill GTIAs, glad I saw that. I was going to experiment first with this on my 1088XEL, replacing UAV with the NUC circuit. I would assume I should put the Csync buffer in, including the diode, res, etc.. Basically what I've outlined in red is what I think consisting of this circuit. Oops, cut out the buffer section, but the rest is there. Please correct me if I'm wrong. I know there were some changes that you did with the color adjustment, but wasn't sure if that would make a huge difference in image quality. I can't find the post where you suggested this circuit as an alternative to other solutions on the market, I seem to remember a phrase, "toss this into the ring" or something to that effect. Thought there might be some more information there.

You might be thinking of the 130XE remake board, I don't think @reifsnyderb got permission AFAIK. UAV footprint measurements could still be useful.

Yes it needs custom firmware, but it's readily available, can be flashed easily using a Pickit2, or Joy2Pic (another Mytek innovation).

My thinking is that you wouldn't need to have UAV if you used the NUC circuit, but to allow UAV to plug in, would just have to have a header exposed, like on 1088XEL that the UAV plugs into. For that matter, you could make the NUC circuit the same form factor, and have them be interchangeable on the board. PIC12F1571 is for the VGATE, which already has firmware, and technically isn't needed, however would be nice to have since it cuts off the garbage visible on overscan in some cases. Just checking a few places, looks like DIP and SOIC versions are readily available. Also the 1572 version can be used as a substitute, the only difference on the datasheet is memory, which the 1572 has 256bytes vs 1571 has 128bytes

I think most people that are using Sophia2 are probably hooking to the digital portion of DVI, not the VGA analog signals, not sure how many signal lines there are in that. Don't have the documentation handy though.

I'd have to go look, but I don't think it's the same, 1088XEL needs UAV for video output, but I think he did create a circuit for 1088XLD, and improved it for 576 NUC.

Santosp got permission to include UAV on 130XE remake, perhaps the same could be done here? I'd also look at Mytek's video circuit for 576 NUC, it's supposed to be UAV level as well. If the 600XL video mod is the one I'm thinking of, when I looked at it, it seemed like a take on the old Longhorn video circuit, while decent, there are better solutions available. I have not personally tried it though, so can't comment. Footprint measurements for U1MB could be found on the 1088XEL gerbers.

The DIN8 specified in the 130XE remake was the CUI 490-SDF-80J, which is compatible with the standard DIN5 connector. I also found a really nice, heavy metal DIN8 connector, Switchcraft 15BL8MX, a bit pricey though. Sophia2 is just using the standard DVI connector, I believe there are some docs that list exactly which pins he is using, also that takes into account the analog VGA as well, so depending on use, pinout might be different. The video connector headers block in the 130XE Remake could use this idea for this purpose, people can just connect the signals they want to whichever headers that lead to the connector pin.

Since getting some actual 1050 drives, I was wondering is there a trick to being able to use these, along with XEL-CF? Even if I leave drive letters/numbers open in the loader, and have the physical drives configured to those, I can't seem to see them in Spartados, it seems that XEL-CF is masking them. Only when turning it off completely in the bios, can I work with the physical drives again.

I understand, but I have a lot of these values in ceramic caps already, not saying I will replace all with ceramic, since some values aren't even available. Cost wise it's saving me money, but that wasn't the primary question, functionally I can't see a reason not to do this, but if someone knows a reason why not, would like to know why? I'm also looking at some of the values in the service manual, and I can't find equivalents for the values/voltages AND tolerance specified, and the cap packs from console5 and others don't list to tolerances of the caps they use. I suspect where -10%/+30% is specified, they might be using 20%, as 10% is not really available for some values, in electrolytic. Also, the service manual doesn't seem to actually list all the electrolytic that are on the board, the list seems incomplete, but the list on console5 wiki has a lot of caps listed that don't have a corresponding value in the service manual, other than trying to track down each value in the schematic. Yes, I realize that I'm probably making this more difficult than it needs to be, however that doesn't stop my mind from asking the questions, and as the answers don't seem readily available, thought someone else might have them.

Got around to pulling this all apart today. Was going to start ordering caps, but have a question. Any reason to not use ceramic caps to replace electrolytic caps, if value, and voltage ratings are equivalent? I'm thinking they will last much longer, and have more stability. It seems that most signs say yes, but low ESR of MLCCs might cause issues, but not sure if this in this case would be any concern. I also may already have them on hand. Anyone done this?

I didn't realize you and I are actually close to each other, assuming your location is accurate. I'd be willing to work with you on this, if you could help adapt something?

Yeah, here it is, I might be able to do something similar, not sure yet if they would work with the box switches. Stupid small screws holding the back panel strip way too easily.. Also another question, did you just clip off the support posts on the Start/Select keys? It looks like the plate might have a hole for one of them.

FYI, I just took a look at my keycaps on my 130XE, they aren't the same as the ones for this project, so there is at least 2 different types of keycaps for the XE keyboards, I wouldn't be surprised if there were a few more, dammit. I can still use the PCB and Plate. If anyone is interested in the replacement keystems, I have a set on the way that I can't use.

I'm doing repair to my 1702, would be interested in modding it for RGB, do you have a good idea how to do this, or could point me to any links? I did search on RGB mods for 1702, but came up short, it seems that people say that it can't be done, or isn't worth trying.

I used to work as a production test tech at Fluke, so I was able to get a 289 and an 87 for cheap. Oddly enough though, is the higher quality DMMs I've noticed, don't have transistor test modes, though the real cheap harbor freight ones do. I could only hazard a guess as to why..

So, I've been working on this, on and off. Having some issues with implementation, but one thing that would help, is if I had test vectors for the 576 NUC EMMU, so I can verify that the GAL is correctly functioning. It seems that the A14-A18 lines are connected differently, than in the original Hias design. I'm definitely curious why the difference in connections, but also how to modify the test vectors from the Hias, to the 576 NUC implementation.

xefsm.pdfThis is a version of the FSM that someone updated to modern standards, pretty nice. There is a troubleshooting guide at the end, it does list possible components, including the RF modulator.