Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

61 Excellent

About the_crayon_king

  • Rank

Recent Profile Visitors

5,586 profile views
  1. The GScartSW and other things that regenerate sync may have issues with this but it might be on a case by case basis. I don't know how Fred K did his board but LTO stability might come down to the 1XXX1 vs 1XX01 thing. I know many of you don't know what I am talking about but that is the only thing I can think of. We are using the same CPLD so it is interesting that compatibility with the LTO is different. That difference might be relevant to other Intellivision RGB kits as well. A solution might be to invert V2 and use a triple NAND so V5, V1, and inverted V2 (for non-programable kits) and to use the four (really three) sync bits inside of 1XX01 (10001 [this is not active], 10101, 11001, 11101) for programmable kits. The theory I have is that 1XX11 or 10001 is triggering on other kits when using the LTO menus. These combinations would normally be inactive but if the kit is only using V5 and V1 to trigger sync then then this is being seen as a sync pulse. I cannot guess further without actually having a LTO. Fixing compatibility on the OSSC is on the docket but it is probably not something I can do on these current PCBs. It would be better if the code for the OSSC was altered to account for whatever broken sync this console is putting out. I will eventually get an OSSC and tweak around with it till I get video. Thanks again for testing.
  2. If the retrotink can work and it is a line doubler and the OSSC cant and its a line doubler then the only conclusion I can draw would be that the OSSC needs to change its code. The changes where I reconstructed sync entirely would need a different board design not just code changes. Anyway, I would have to get a hold of an OSSC and see if it can't be done in a simpler way,. if it can be done in a simpler way then maybe that could fit and be flashed. I wouldn't buy one if I only had an OSSC or HD retrovision. It is doubtful that it will work. Of course I am still surprised that the Retrotink worked so who knows... Perhaps adjusting the PLL settings on the OSSC would be enough? I would feel more comfortable getting one and confirming things rather than sending them out with the onus that "maybe it will work on the OSSC". I would rather say that it does not work on the OSSC.
  3. I got my retrotink 2X today and can confirm the current code plays fine on real games via the Retrotink 2X. I have confirmed the XRGB, the HD scaler (just google HD SCART scaler), my CRTs and the Retrotink 2X work with the current revision of code. So now I just need a LTO, OSSC, and HD Retrovision. I will have to wait till you confirm if the new code works the same with the LTO. Thanks for testing this BTW. If it does I can figure out why maybe. I am assuming the LTO is doing something with sync during transitions. The difference might come down to 1XX01 (mine) VS 1XXX1 (others). Otherwise it would be the sync pulses I added into VSYNC but looking back at those pulses they shouldn't be helping things (which is why I removed them).
  4. I think what I have made in the past is compatible already given mattyv316's results. I just need to confirm the new code works as well on the retrotink. It's confusing because the oldest code has the same sync as the newest code; the stuff made sometime before the 11th had code that added 3 pulses (which does work with the retrotink); but looking at those 3 pulses it shouldn't be better than not having those 3 pulses. Which makes me think something else is going on in regards to the LTO and that both codes will probably work on the retrotink. It will be interesting to see in either case. I am doing more of 1XX01 instead of 1XXX1 (for sync) which should look exactly the same but if something else is triggering when using the LTO then that might be a better explanation of why sync drops out more on one mod kit vs the others. That would make far more sense than those 3 random pulses being useful but I cannot rule that out. TLDR I really need to get a LTO.
  5. I am getting the retrotink around the 1st. I just think it would be wise to wait till I have confirmed compatibility with the Retrotink with the new code (on my end) before sending out any more. So that all the boards past X date are all on the same code. I can't get a LTO so it seems worth it to send one to matty even if it ends up needing to be replaced. If you want one to replace the one you have earlier I can send it sooner I just can't guarantee it will function on the retrotink. If the new code remains the same compatibility wise with the LTO + retrotink that will actually be surprising. Since the newest code's sync should look exactly the same as all the other RGB mods that are out there. I don't want to guess about too much without some of this stuff in front of me.
  6. Somebody, somewhere had this working with an LTO through a Retrotink 2X. They were running the old version of code (which I lost). Since getting this news I have ordered a Retrotink 2X and if the current code doesn't run with that scaler I will remake that older code. (I know the gist of what I did it wasn't complex). That would mean so far these would work on CRTs (through YPbPr), Retrotink (tentative), that crappy HD scaler, and the XRGB. That would just leave the OSSC and maybe the HD Retrovision. If the Retrotink can work with this but not the OSSC then something should probably be done on the OSSC end. I think it has settings for PLL or something which might do something. TLDR I CAN make sync do whatever I want but if I can get the retrotink to work then I will probably leave it alone. There are about a dozen reasons I do not want to change the board design to implement that complete sync reconstruction. I just wanted to work out how it could be done. Just a note to be clear I was off on some tangent about trying to make this work on that crappy scaler again since it stopped at some point; but it only stopped because that scaler needs a 5V ref not because of the code changes. That whole ordeal might confuse people so this is just clarification. Just don't jumper those pads (like you would do on the colecovision RGB) on this board those resistors are pulldown resistors so you just need to remove them. If you bridge that connection you will not get video and probably fry the DAC. Is the line count just the hsync pulses? I am not sure I have a way to give a specific number. I had the Hsync pulses as: So my lines were between 261 and 250 which is quite a margin. I can't count the lines I have to use the distance between each vsync pulse and then the distance between each sync pulse.
  7. Remove the ones in red if you have a genesis cable that has internal 75ohms.
  8. Fred and I most likely have differences in our sync. I did a minor correction of sync that might possibly make things worse. It looked better on my oscilloscope but made no difference on the functionality of the devices I own. If Fred's works and mine doesn't then that will be very interesting. I was under the impression that none of these line doublers could be made to work with Intellivision RGB kits. Not because of sync but because of the resolution. Now I do not know what to think. At any rate, I spent a incredible amount of time making corrections to sync that can be flashed to these boards. I never ended up using it because all of my devices work with the code I currently use (and the correction would remove YPbPR and palette support). If this correction can make this work better on the LTO or retrotink etc. then I would consider implementing it.
  9. Found this on Ebay. You can find a non-OEM one for alot cheaper. So what 9VDC, center positive, 500ma ? If it hurts to go up to a higher ma that would be news to me.
  10. The thing I am using is just a CPLD no way to add black borders or really do anything fancy. It is crazy that I even have the room to retime sync.
  11. Well poking around made my RF stop working. Probably something to do with the connection to RF since I still see all the signals over composite. Composite looks noisy as heck. I am not sure what they are doing but it appears like the have the burst clock going all the time over blank, white, black, grey, sync etc. I am no expert but I am pretty sure there shouldn't be any chrominance/burst during any of those colors/conditions. Blank should have burst after sync and then the color besides the ones listed above should be clocked to that but I am seeing it constantly. I think the RF carrier wave is either already applied or something. That should be removed along with the audio to make composite. The repeating signal I am seeing is 48ns from one pulse to the next. So if I can poke around a little more and find a 48ns signal connected to the output then it is likely removing that would "fix" the video. So I will attempt to do that. This will just be something I use to look at video besides the RGB I am attempting to create so I can verify the colors. Anyway, I can't redraw the locations of things only delay them. That would be a limit to the CPLD I am using and my lack of knowledge of how to do such a thing. The only thing I can do is draw things from left to right top to bottom. I will work this delay thing and see what comes of it. Edit: So for composite you just need to solder to that spot and lift that pin. Then amp the signal 4x (12db gain). You can do this sending the signal through a 7314/7316 twice (which is what I did). The noise that I saw is probably just a case of breadboarditus. I will make a proper circuit for this at some point but I think you get the idea. As for S-video I am too afraid to keep poking around on this board directly but the same thing probably applies. The better way would be to use an op amp/transistor to amp by Y/C by 6db and then a FMS640X to get S-Video and Composite. The first op-amp/transistor being possibly useful for additional filtering. I will actually have to lift those areas and measure the voltage but I would wager that is the case. I can make a board for this if someone is willing to order/try it. I am just using the CV that I have made for bare bones stuff whilst I try to figure out RGB.
  12. Thanks, that has me back in business for now. As far as I can tell there are 4 inputs from the ram (to the PPU); 3 luma/sync outputs (from the PPU), and 2 Chroma outputs (useless). The truth table for those bits are: BS 00 --- SYNC 01 ---BLACK/BLANK/BLUE 10 ---RED / GREEN 11 ---GRAY/WHITE The last bit of the three only seems used during white/gray. It would make sense that bit being one would be the difference between white/gray but that doesn't really happen in practice. I still have the possibility of digging something out from the RAM as they have color information too (the blue in the below picture is from RAM). The problem is the RAM outputs are happening much sooner than the PPU outputs. If you could delay the RAM to match the PPU then I am certain you could use the combination of logic to get all of the colors. Otherwise all of the colors might be in RAM and I just haven't been able to write the code in a correct enough manner yet (this is likely). The code(s) that differentiate black and blue are not happening at the same time as the color codes from above. That's why you see black where blue should be. I didn't put in the code to differentiate green/red yet. This is what I have so far. :
  13. Well I am pretty sure I can make sync do whatever I want now. That has been true for some time. All my personal devices work with this. I would need something that should work with this but doesn't then I can test the various different syncs I have made. IMO there is no point in fixing sync if it already works because of the room the fix takes up. Once again AFAIK line doublers not supporting this is not an issue with the mod kit but an issue with linedoublers. It is just too low a resolution. If someone has information contrary to that then I have yet to hear it. I could eventually scale the output but that would be a whole 'nother project.
  14. I could only look at one color closer before my AC adapter stopped working. I don't believe it fried the console. The adapter burning up most likely did not have anything to do with my modding. Black is going from 0000 to 0110 to 1111 then back to 0000 I think there is probably a combination of latches going on here but since the adapter stopped working I cannot make anymore progress till I sort that out (most likely by powering the power regs directly). If the Fairchild model 2 uses unregulated power or negative power someplace then that is going to be a pain. I think 0000 is most likely black and 0110 and 1111 are the setup to that. So 7 more combinations like that and I will have video. I don't know why the codes for say black repeat and codes for green stay the same. There is probably a setup at the very start of green that I have yet to capture. BLACK
  15. Sync is NOT inside those bits nor blank. Unless I am missing something... That just means sync/blank has to be taken from another spot so it is not a big deal just good to know.
  • Create New...