the_crayon_king Posted January 22, 2018 Author Share Posted January 22, 2018 Still can't get the quad and 6994-2 to accomplish anything useful. I just ordered the 6994-1 and the 6993-1 just now from digikey. I'll see if I'll have any luck with that. I'll keep you posted. Ill be waiting with baited breath. Good luck. I would test this myself but I am not sure when I will be moving. Once I get a date I can make the decision to order the parts here or when I get where I am going. Im not an EE or anything but I have some hope here. Quote Link to comment Share on other sites More sharing options...
citrus3000psi Posted January 22, 2018 Share Posted January 22, 2018 Ill be waiting with baited breath. Good luck. I would test this myself but I am not sure when I will be moving. Once I get a date I can make the decision to order the parts here or when I get where I am going. Im not an EE or anything but I have some hope here. I messed with this for a little bit last night. It works, but with major horizontal scrolling issues. R4 (HSync width) should be ~15k and R3 should be ~400K. These values wraps the image back around the the full 62u. But there is just horizontal roll waves present. Maybe its because I'm bread boarding the design. Quote Link to comment Share on other sites More sharing options...
the_crayon_king Posted January 22, 2018 Author Share Posted January 22, 2018 (edited) I messed with this for a little bit last night. It works, but with major horizontal scrolling issues. R4 (HSync width) should be ~15k and R3 should be ~400K. These values wraps the image back around the the full 62u. But there is just horizontal roll waves present. Maybe its because I'm bread boarding the design. Are you able with a pot to adjust left and right ? Also are you summing H and V to C sync ? You should be able to compare the normal Hsync against the delayed h sync. They should be able to overlay on top of each other and match both width and timing. Or maybe a better way to say that since we a using scopes is to say the distance between the two H sync pulses should be the same. They should also be the same width. Id suspect if it were off even a little it could cause issues. That's why I wanted to use resistors instead of pots because of the potential for error there. If your TV supports separate H and V sync we should test that before adding in any summing circuitry. The only other alternative I could think of would be to delay all the other lines to match H sync. That would require a different circuit altogether. Or maybe you would just have to delay V sync. Altogether I am not sure how RGB/V/H all add up to video exactly. Edited January 22, 2018 by the_crayon_king Quote Link to comment Share on other sites More sharing options...
bbuchholtz Posted January 27, 2018 Share Posted January 27, 2018 (edited) Hey Guys! I thought I'd join-in on your party I'm looking to try using the BT9107KPJ. Thank you Taijigamer for suggesting this idea! I've already ordered a couple of CD-i 210/40. They should be here any day... CD-i Fan was kind enough to provide me a service manual for the CD-i 210. This should help reverse engineer the video encoder. I plan to use the NCS2553 for RGB amplification. And probably some sort of circuit based around the 74HCT86 for sync combining. In order to make installation simple, I like something such as the W9327-ZC158. I have a good start on my PCB. Hoping it attached ok. Does anyone know if the BT9107KPJ has an internal VREF? Or do I have to supply an external VREF? I'm guessing this would be +2V. -Brian Edited January 27, 2018 by bbuchholtz Quote Link to comment Share on other sites More sharing options...
Taijigamer Posted January 27, 2018 Share Posted January 27, 2018 Hi @bbuchholtz, welcome to the party. That's really cool that u are looking into swapping encoders on the CDi. I would be really interested in what the CDi service manual says about the BT9106 as I have hit a snag with the BT9107 on the 3DO. I desoldered the BT9103 and replaced with a BT9107 but I get no output. I spoke to superg on assembler games who says he found the pin behaviour between the BT9106 and BT9107 similar except for the lack of RGB on the BT9106. There is no datasheet for the BT9107 so I am working from the BT856 datasheet http://pdf1.alldatasheet.com/datasheet-pdf/view/96758/ETC/BT856/+7W759UCRC/1wuzYz+/datasheet.pdfwhich states that Vref can be provided by the encoder or externally. I don't think u will need an amplifier with this chip. Quote Link to comment Share on other sites More sharing options...
bbuchholtz Posted January 28, 2018 Share Posted January 28, 2018 I have the Japanese FZ-1, with the VP536 encoder. So, I'm hoping that I can successfully build an adapter board for the BT9106 or BT9107. Are there any notable pinout differences between the BT9106 or BT9107? I know that you had some success with the BT9106... I know that you found an RGB selector on pin 13. Are you pulling pin 10 high or low? Also, did you end up pulling pin 14 low, or leave it floating? Also, are you pulling sync from pins 45/46 or 54/55? Or were you able to find a CSYNC from something like pin 8? Lastly, does pulling pins 58/59/60 low/high change video mode (i.e.: PAL/NTSC)? Sorry for all of my questions! -Brian Quote Link to comment Share on other sites More sharing options...
Taijigamer Posted January 28, 2018 Share Posted January 28, 2018 No worries. Thank you again for the info on the CDi 220. Here is a close up of the BT9106, 07 & 08 (they all share the same pinout but slightly different requirements). As you can see it is different to the BT856 that was originally used for reference, which is why nobody had any luck getting RGB on their BT9106 CDi. I tried to install a BT9107 on my 3DO but the BT9103 follows more closely to the BT856 so I was unsuccessful. I misquoted the encoder pinout in my message, for BT9106/7, pin 14 selects RGB on/off. Pin 13 should be left as it is. Pin 10 is for I2C communication (on BT9106/7) and should be left as is. Using Hsync (Pin 45) and Vsync (Pin 46) is better than stripping Csync from CVBS as the time delay can be managed. This thread is focusing on correcting the possible Hsync shift using extra circuitry. In my 3DO mod https://assemblergames.com/threads/3do-rgb-mod-3do-adventures-part-3.67513/I used a LM1881 sync stripper to get Csync from Luma. As for video modes, unfortunately the CDi service manual doesn't detail which pins if any on the BT9106/7 correspond to PAL, Interlace etc. In summary to your questions - for people with a CDi with the BT9106/7/8 encoders, just lift and tie pin 14 high which will enable RGB, and obtain sync from either Pin 45/46 or CVBS (Pin 2). No further modding required. - for people looking to mod their 3DO, either use the mod detailed in this thread, my mod on assemblergames or use the BT856 encoder as we have access to the full datasheet. Hope that helps. Any questions please feel free to PM me. 1 Quote Link to comment Share on other sites More sharing options...
bbuchholtz Posted January 29, 2018 Share Posted January 29, 2018 Thank you! This was very helpful -Brian Quote Link to comment Share on other sites More sharing options...
bbuchholtz Posted January 29, 2018 Share Posted January 29, 2018 Regarding sync combining and horizontal timing, what are your thoughts on using a PIC microcontroller? I have some experience in working with PICs. May offer a little more flexibility... -Brian Quote Link to comment Share on other sites More sharing options...
Taijigamer Posted January 30, 2018 Share Posted January 30, 2018 The problem with the Hsync delay is that it varies from setup to setup. Some are worse than others. This may be why Otaku's mod had the adjustable potentiometer. The problem with potentiometers is they are noisy and better used for test and design rather than final build. Using a fixed solution may not suit all setups but an average setting could be used to suit most setups. Ive been looking for an IC that allows Hsync adjustment but I can't seem to find one. Would a Pic be able to adjust sync signals? Quote Link to comment Share on other sites More sharing options...
bbuchholtz Posted January 30, 2018 Share Posted January 30, 2018 I don't see any reason why hsync delay couldn't be adjustable, using the PIC method. I could dedicate some of the I/O pins to a "user interface". It could be something like up/down push buttons, or set using jumpers. Although the jumper method would allow for fewer settings, it would persist after a power cycle. I'd rather not add the complexity of some sort of battery backup or an external NVRAM implementation. Unless there are PICs that now have some sort of NVRAM built-in. I'd have to check... I'm not a super expert at RGBHV. I may need a little help interpreting the signals... -Brian 1 Quote Link to comment Share on other sites More sharing options...
bbuchholtz Posted January 31, 2018 Share Posted January 31, 2018 (edited) I've been poking around on Microchip's website. So far, the PIC16F1619 doesn't look bad: http://www.microchip.com/wwwproducts/en/PIC16F1619 Highlights: - 17 I/O + 1I (20-pin) - 125 ns minimum instruction cycle - Interrupt Capability - One 8-Bit Timer - Four 16-bit Timers - 10-Bit Analog-to-Digital Converter (12 channels) - 8-Bit Digital-to-Analog Converter - Fixed Voltage Reference (FVR): 1.024V, 2.048V and 4.096V output levels - Complementary Waveform Generator - Two Comparators - Zero-Cross Detect - Internal or External Oscillator I'm thinking I could use a crude jumper-based ( 8 ) binary selector ( 256 ) values. That number of steps should be plenty of granularity for hsync delay. We could probably get down to a resolution of 1 or even 0.5us. Does this seem to be headed in the right direction? -Brian Edited January 31, 2018 by bbuchholtz Quote Link to comment Share on other sites More sharing options...
bbuchholtz Posted January 31, 2018 Share Posted January 31, 2018 I apologize in advance, for my basic question. I'm trying to put csync into terms I can understand. Are the following true: If vsync is low, then csync equals hsync. If vsync is high, then csync is the inverse of hsync. -Brian Quote Link to comment Share on other sites More sharing options...
the_crayon_king Posted February 3, 2018 Author Share Posted February 3, 2018 I apologize in advance, for my basic question. I'm trying to put csync into terms I can understand. Are the following true: If vsync is low, then csync equals hsync. If vsync is high, then csync is the inverse of hsync. -Brian No one has reponded but that is how I understood it as well. The book "Video Demystified" seems to be the bible for these type of things. Quote Link to comment Share on other sites More sharing options...
bbuchholtz Posted February 3, 2018 Share Posted February 3, 2018 (edited) Hey Guys, I've started on my PIC programming. Full disclosure: I'm not a great programmer; I'm learning as I go. But, I'm feeling good about the progress I've made thus far It's turning out, the sync summing aspect of this project is the easy part. Microchip XC8 supports bitwise. So, I can XOR with one statement. Combining hsync and vsync is as simple as: CSYNC = HSYNC ^ VSYNC; The hsync delay is the more challenging part. But, I have an idea! Remember those old portable CD players? It used to be that if you bumped them, the laser would lose focus and the song would skip. Eventually, an "anti-skip" feature was introduced. Instead of directly outputting the audio, the bitstream would first be deferred to a buffer. Why not do the same thing with hsync? Obviously, we don't care about anti-skip. But, maybe we could use this as a method for creating a "delay". I already have a routine for reading pins and bit-shifting the values. This is what I plan to use for reading the jumper settings: unsigned int Read_Jumpers(void) { // Read jumper settings unsigned int Jumper_Settings = 0b00000000; // Initialize input buffer Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_0; // Store DEF_JUMPER_0 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_1; // Store DEF_JUMPER_1 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_2; // Store DEF_JUMPER_2 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_3; // Store DEF_JUMPER_3 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_4; // Store DEF_JUMPER_4 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_5; // Store DEF_JUMPER_5 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_6; // Store DEF_JUMPER_6 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_7; // Store DEF_JUMPER_7 into Jumper_Settings return(Jumper_Settings); } The above code as be used for reading and storing hsync states. Only difference would be reading from the same pin, multiple times. Much like sequentially storing eggs in an egg carton. Each "egg" would represent the hsync state, at that moment in time. However, my "egg carton" isn't big enough. As far as I can tell, I'm limited to 8 bits (states). I've been banging my head against the wall, trying to get around this limitation. Then it struck me... why not simply use multiple egg cartons? I can use the same methods for reading/writing a single byte, as I would for multiple linked bytes. Since I will be repeating this code, I plan to create a set of macros, for manipulating bits. Perhaps this will be a good excuse for me to learn structures and unions I'll keep you posted on my progress! -Brian Edited February 3, 2018 by bbuchholtz 1 Quote Link to comment Share on other sites More sharing options...
the_crayon_king Posted February 19, 2018 Author Share Posted February 19, 2018 So from what I can gather the CH7025/CH7026 may be the answer to our woes. From the datasheet: "The CH7025/CH7026 has the capability of vertical and horizontal output picture position adjustment. It canautomatically put the picture in the display center, and the vertical or horizontal position is also programmablethrough user input. And also it can provide brightness, contrast, hue, saturation adjustment and text enhancementfunctions. (For analog RGB output, only brightness and contrast adjustment are available)." Working on making a schematic: https://easyeda.com/normal/3DO_thing-943551f0c50b43749357748f6276be58 Quote Link to comment Share on other sites More sharing options...
grifter Posted April 5, 2018 Share Posted April 5, 2018 long time lurker :-) I have a BT9101 and would love to RGB mod it. I see you guys are having picture alignment problems.. Would something like this help? http://www.otakus-store.net/en/accueil/21-118-shift-corrector-for-video-rgb-console-circuit-board-arcade-image-horizontal-centering.html#/34-version-assembled/37-shift_corrector-axe_pot Quote Link to comment Share on other sites More sharing options...
Taijigamer Posted April 7, 2018 Share Posted April 7, 2018 The horizontal shift fixer by Otakus-store is based on Tim's design which crayon_king looked at earlier in this thread. It is a solution but does have its own issues. The IC mentioned above might be promising as it processes RGB and fixes the sync shift. The BT9101 is just as moddable for RGB as the BT9103 and VP536. U can use any 3 channel 24bit RGB digital analogue converter or Otakus-store's mod despite them stating it is only or VP536. Check my thread on the different encoders https://assemblergames.com/threads/240p-output-on-3do-with-bt9103-encoder.66295/or on a different mod for RGB https://assemblergames.com/threads/3do-rgb-mod-3do-adventures-part-3.67513/#post-955780 here. If u want install instructions for your BT9101 feel free to PM me. Quote Link to comment Share on other sites More sharing options...
the_crayon_king Posted April 15, 2018 Author Share Posted April 15, 2018 (edited) The horizontal shift fixer by Otakus-store is based on Tim's design which crayon_king looked at earlier in this thread. It is a solution but does have its own issues. The IC mentioned above might be promising as it processes RGB and fixes the sync shift. The BT9101 is just as moddable for RGB as the BT9103 and VP536. U can use any 3 channel 24bit RGB digital analogue converter or Otakus-store's mod despite them stating it is only or VP536. Check my thread on the different encoders https://assemblergames.com/threads/240p-output-on-3do-with-bt9103-encoder.66295/or on a different mod for RGB https://assemblergames.com/threads/3do-rgb-mod-3do-adventures-part-3.67513/#post-955780 here. If u want install instructions for your BT9101 feel free to PM me. Sorry for the lapse. I had eye surgery. Uhh so far the problem with the other IC is the amount of space needed for all the components. I always start with maximum stuff and then cut down whatever I think I can get away with. Spacing issues aside I meant to post this : https://easyeda.com/hotdog6394/3DO_CH7026B-b6b455c9d41742a29f3481b7ca36fc0d It's just the schematic info already in the PDFs by chrontel. The links to all the info one would need to complete the design are all in the schematic posted in the link above. I flipped what color goes where as a means to save space (also shown on the schematic) I don't think this will cause issues. As it were right now I could make something to test that board but it wont fit well enough to "float". If someone could point out some gaps I have in the design that would be great. I took a break and forgot where I left off. Edited April 15, 2018 by the_crayon_king Quote Link to comment Share on other sites More sharing options...
the_crayon_king Posted April 15, 2018 Author Share Posted April 15, 2018 (edited) So all i need to know is the logic high voltage out of the 3DO for the following: CLK121 (input 3V min) HSYNC (output VAA(5v) -1 min) VSYNC (output VAA (5v) -1 min) DIgital RGB (inputs 3V min) The reason I mention it is that we should not exceed 3.3v for any of those. And if they do we need a way to buffer the high (which I suspect is 5v across the board) to 3.3v max if else find a different IC entirely. Edited April 15, 2018 by the_crayon_king Quote Link to comment Share on other sites More sharing options...
Taijigamer Posted April 16, 2018 Share Posted April 16, 2018 Hey man, welcome back. Hope the surgery went ok. When I measured H, V, CLK, D23:0, I had values of 1.4V, 1.4V, 2.4V and 20mV respectively. These were DMM values but the true oscilloscope values shouldn't be far off. H and V are outputs on the original encoders which feed back to the CLIO so using them as inputs may be out of sync with the D23:0 info, but they can be set as outputs on the CH7025. Csync can be set to either XOR, AND, OR. At least the horizontsl shift will be sorted. Looking at the output standards it looks like the CH7025 doesn't output 240p. It outputs 480i but also 480p, 720p etc, I wonder if it can upscale the 3DO D23:0 information? I'm the same when prototyping, include everything then downsize. U could probably remove a lot of the filter discretes and just use a 75 Ohm termination resistor and 220u cap on the RGB lines. No need for H, V out, just Csync. The challenge will be cleverly designing the psu section due to space. Maybe an IC devoted to 1.8V, 2.5V and 3.3V generation. Quote Link to comment Share on other sites More sharing options...
the_crayon_king Posted April 16, 2018 Author Share Posted April 16, 2018 (edited) Hey man, welcome back. Hope the surgery went ok. When I measured H, V, CLK, D23:0, I had values of 1.4V, 1.4V, 2.4V and 20mV respectively. These were DMM values but the true oscilloscope values shouldn't be far off. H and V are outputs on the original encoders which feed back to the CLIO so using them as inputs may be out of sync with the D23:0 info, but they can be set as outputs on the CH7025. Csync can be set to either XOR, AND, OR. At least the horizontsl shift will be sorted. Looking at the output standards it looks like the CH7025 doesn't output 240p. It outputs 480i but also 480p, 720p etc, I wonder if it can upscale the 3DO D23:0 information? I'm the same when prototyping, include everything then downsize. U could probably remove a lot of the filter discretes and just use a 75 Ohm termination resistor and 220u cap on the RGB lines. No need for H, V out, just Csync. The challenge will be cleverly designing the psu section due to space. Maybe an IC devoted to 1.8V, 2.5V and 3.3V generation. Well my vision can get better or worse from this point time will tell. Should start stabilizing though which was the point of the thing. So the CH7025 datasheet says: "The device is able to encode the video signals and generate synchronization signals SDTV format for NTSC and PAL standards and HDTV format for 480p,576p,720p and 1080i" AND "Support for flexible input resolution is up to 800x800 and1024x680. 320x240, 640x480, 960x720 are support(ed)" AND "CH7025/CH7026 also supports analog RGB output through video DACs. Typically used resolution are 800x600,856x480, 800x480 or 640x480. Vertical sync and horizontal sync signal are provided." From http://users.polytech.unice.fr/~buffa/videogames/3do_faq2.4.html : "The resolution displayed on screen is 640x480. However, the 3DO has an internal resolution of 320x240 or 320x480," So it doesn't outright say that it doesn't support 320x240 or 320x480 output. However I didn't see it say where to set said resolution either... At any rate it does say it has a scaling engine embedded, id figure just try it and see what resolution is outputted (that doesn't look like a real word). There are alot more options set by registers but I was never able to find a "key" for programing it. I realize that the video inputs will be out of time with sync (as they are for every version of a 3DO mod). I am hoping that the auto centering takes care of that. If else the datasheet does mention that it is programmable for both H and V sync. There are other ICs meant for HDMI/DVI output that would also work as scalers. This console could be modded for HDMI/DVI but I don't know the possible downsides of embedded scalers versus something purpose built like the XRGB. If you know of an IC that can generate all three of those voltages that would be nice my googlefu is a little rusty and I couldn't find one. I had in my notes that H and V were 5V but I may have been referring to a different console (I am referencing the VPA). I think I will test on my own end to confirm. I already looked into possible solutions like the 74LVC4245APW (8 bit level shifter) If we have to set an output resolution above 320x240 or 320x480 then it would make sense to use 640x480 assuming that is a programmable option. Edited April 16, 2018 by the_crayon_king Quote Link to comment Share on other sites More sharing options...
the_crayon_king Posted April 19, 2018 Author Share Posted April 19, 2018 So update; my Goldstar 3DO measurements are: H/V Sync out 5V (high)/the datasheet only mentions VAA-1V [4V] being the minimum Digital color lines 5V (high)/the datasheet mentions 3V minimum here. CLK12I 3.3V So that means if the CH7025 is used we would logic level translation (5V to 3V) for 26 lines. The only input not needing changed is the clock. I already made a design with the above info in mind but dang it surely not going to "float" anymore. Quote Link to comment Share on other sites More sharing options...
Taijigamer Posted April 19, 2018 Share Posted April 19, 2018 A google search turned up this 3 output LDO regulator which may solve your 1.8V, 2.5V, 3.3V issues. http://www.farnell.com/datasheets/2254556.pdf The official documentation for 3DO states the graphics resolution as 320x240 which is then output at 480i by the native encoder. The CH7025 outputs 480i SD and 480p ED etc. It will be interesting to see how the encoder handles the resolution. Programming of the chip seems to be done over I2C serial programming. I found some files here http://en.pudn.com/Download/item/id/2626071.htmlWhich may help with programming the chip. HDMI? Now that sounds interesting. Maybe look at how OSSC works or speak to @citrus3000psi on his work. Quote Link to comment Share on other sites More sharing options...
trapexit Posted April 20, 2018 Share Posted April 20, 2018 The internal framebuffer is 320x240 and then there is an interpolation step. https://patents.google.com/patent/US5481275A/en Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.