Gbs 8200 Amiga

[Suanne Forte]

Whyis my example photo a picture of a TV? The OSSC is very different from the Framemeister; it uses a line buffer. A line buffer stores only a line at a time, and builds the output picture as it comes in. Generally this means doubling each line to convert a 15kHz signal to a 31kHz signal, as used in VGA and HDMI, but the OSSC can actually go even further than that. This means that the OSSC has, for all intents and purposes, the lowest lag possible.

But I was never really happy with the GBS-8200 for this purpose; I felt that it rounded the corners of pixels too much, and it treats all incoming signals as interlaced, which can result in artifacts around moving objects like a mouse cursor.

It only has a VGA output, but I have a number of VGA->HDMI converters. These can be lag-free, since VGA and HDMI signal timings are identical, so all you need to do is have a good analog-to-digital converter.

So, I was intending to upgrade my GBS-8200 to try out the new firmware as a soldering project. But, after burning my finger on the soldering iron, I got annoyed and decided to order a pre-assembled one. This wipes out the cost advantage, but does give me a pretty case. This pre-assembled model has an external clock generator added, which is supposed to help with the aforementioned screen tearing issue.

The OSSC and the Framemeister, despite the Framemeister having a frame buffer, time their output signals with the input. This means that when the mode of the game changes, the signal drops, and your television or monitor needs to resync with the upscaler after the upscaler resyncs with the source. This all means that switching between 240p and 480i can have some heavy delays.

I use an Acer monitor with the Framemeister these days, and it has some severe delays in locking on a signal. This is because whenever the HDMI input drops, it first looks for a VGA signal for whatever reason.

There are numerous forums posts that state to get the best out of this board you need a 5V high current, good quality, power supply and you should replace the electrolytic capacitors with higher quality ones. Being an Electronic Engineer with 16 years experience, I was dubious about this and set about investigating the board. A list of 21 items to test was created and depending on the results, I hoped to improve the basic video connections and obtain reliable, proper colour video images!

Whilst researching the devices on the board, I came across a thread the the SHMUPS (an abbreviation of Shoot-em-ups) board who has played with the software, =6&t=52172, this provided a link to the programming guide, which I did not have. I did have the TVIA-5725 datasheet. Playing with the software settings is for the next post on this topic, this one deals with the hardware.

There are two versions of the board available and two similar models. The GBS-8220 is a dual output board, the GBS-8200, which I have, has a single VGA output. The GBS-8220 is typically a V3 board, the GBS-8200 a V4 board. Easiest to show with some photos:

The highlighted areas show a crucial difference, the V4, GBS-8200 board, has a switchmode power converter, whereas the V3 board has a linear regulator on the the V4 GBS-8200 board only has 1 x VGA output! ? throughout this article, I will refer to the two boards collectively as the GBS-82XX.

I wanted to test something other than the Amiga, to see how well the GBS-82XX coped with another retro system. The Atari 7800 was nearby. My unit has been modified to output S-Video (Y/C). I then connected this to a RVA dev board, which converted the S-Video to YPbPr. The YPbPr video was fed into the GBS-8200 board. It sort of worked. I had trouble with the RVA board outputting black and white video from the Y/C source. I tried tweaking a few settings but this is a task for another time. Feeding in composite video, using a S-Video to composite lead from the Atari 7800 worked. Atari 7800 up-scaled to VGA:

For a 10 minute quick test, it showed the future potential of this board. There were some white speckles on the video though.

Though the RVA scan-doubler, when I get it working, may surpass it ?

The I2C port now has a pin header soldered onto it and I observed that it operates at 87.3 KHz and has regular traffic. A Pickit serial, will be used to inject I2C commands for testing, this is no simple task, decoding what to try but will be fun!

I amend my previous post. The 8200 v4 has vertical bands/ strips of noise and sparkles moving bottom to top. The 8220 v3 worked straight out of the box it two x VGA out.

I did use your video settings .

Are you buffering the video where it splits?

Something like this circuit, -distribution-amplifier.html will help.

The resistors R11 and R12 in that circuit are important to match the impedance of the driver to the transmission line, get this wrong and you will have reflections, which cause ghosted images.

You have the Amiga CSync going to the GBS yellow wire above. I believe it should be going to gray, as per the second part of your article. In fact I tried it both ways: yellow did not work but gray did.

Hi Ivan. I was only successful with 60Hz signal. I never managed to run Amiga video through GBS which your theory can explain as I suppose it runs at 50Hz in PAL mode by default. I can try interlaced modes and see if it confirms next week.

Hi!

i got myself a HD Video Converter Board HD9800/GBS8200 for my taito landing gear arcade game,but when connected it only shows parts of the graphics and nothing in 3D,only black spaces.do you have any idea why its doing this?

I have C28 and it gives me 0.1nF but I measured soldered. Anyway it gives the same value as other capacitors in that row so you may try by comparing or remove one.

But I had same problems with my board, impossible to sync to anything. Then I played a bit with the sync signals and were able to get it working. You may see my post here, maybe it helps: -to-vga-scaling-with-gbs-8220-board/

I believe I have found the cause of the occasional white speckles seen on the display. The default setting for the GBS-82XX board is to clock the 166 MHZ speed grade SDRAM at 162 MHz. It appears to be worse if the Hynix HY57V643220DT-6 is fitted compared to the EtronTech EM638325TS-6G device, which appears to be fine.

The simplest fix was to reduce the SDRAM clock speed to 129.6 MHz, with a single I2C write. This has fixed the issue. Halving the SDRAM speed to 81 MHz caused distortion on the video, the next speed increment of 108 MHz was sufficient for 1360768 pixel output. A proper fix would be to adjust the timing of the DQM strobes with regard to the data bus as on SDRAM the DQM strobes clock the data out of the SDRAM. If this is adjusted, you also need to consider the timing of the SDRAM clock to the control bus (RAS, CAS, CKE, CS, BS0/1 and WE) and the Data bus. This is not too difficult if you have the PCB artworks as you can measure the PCB track lengths and adjust the timing by 7ps/mm. With the GBS-82XX board, it would be tricky and fraught with false starts. We could of course measure it and adjust accordingly, or reduce the clock speed by 20% and have more timing margin (an extra nanosecond) on the clock.

Now that the speckling problem appears to be fixed, I am looking at some general video quality issues. When using a 50 Hz PAL screen-mode, scan-converted to 60 Hz, there are some noise bands, particularly noticeable on a grey Workbench background. It is hoped that some digital filtering/sampling will help alleviate this.

A number of people use the venerable LM1881 video sync separator, any device or circuit that uses this, should have the 680 ohm resistor added as shown above. The LM1881 outputs 4-5V sync levels that are not compatible with the GBS-82XX/TVIA-5725. Alternative devices are the EL1883 or the LMH1980 but they are not available in hobbyist friendly DIP packaging.

I have tested the LMH1980 with the Amiga, I used the composite video output of the A1200 to create LVTTL (3.3V) HSYNC, VSYNC and CSYNC. The GBS-8200 I have synchronised with the CSYNC perfectly, the same as using a resistor. It did not work reliably when I supplied separate HSYNC and VSYNC, I had a very wavy display.

A final note, the GBS-8200 did synchronise to the Composite video output of the A1200 but it is not recommended. The 2V (approx) video contains colour information that is not filtered out and would in all eventualities, cause problems at a later date.

I have been reading numerous web-forums on GBS-8200/GBS-8220 problems to look for common trends and solutions. One topic that crops up a lot is related to the power supplies. I have already proven, in part one, that a 5V 2A supply is not required.

During my testing, I noticed an occasional, high frequency, burst of noise, on the +3.3V supply. I traced it back through the circuit to the power input. Changing the timebase of the oscilloscope, I spotted something important, it happened at 20ms/50Hz intervals. In the UK and Europe, the AC mains operates at 50Hz so when you see a 50Hz noise pulse, you know where it came from. Currently my GBS-8200 is powered from my bench power supply, built 20 years ago, with 3 linear regulators and still on the original electrolytic capacitors.

Also connected to the +5V output was my 5V to 3.3V TTL buffer board. Two of the eight inputs were in use, the other six were floating. I made a mistake here. You should never leave TTL inputs unconnected, they will pick up noise and oscillate, in this instance, they picked up 50Hz mains noise. Quickly dis-connecting the buffer board, removed the noise. The 3.3V (switchmode) and 1.8V (linear) regulator supplies now have about 20-30mV of noise, perfectly acceptable.

You can see the buffer board in the top right of the photo. Whilst this ferrite was a little large, it did cut the noise out. If you are using the DC power jack (the black plug) either pick a PSU that has a ferrite fitted or measure the cable diameter and purchase a clip-on ferrite from a local supplier or ebay. I spent two hours trying to work out where the noise was coming from, reading datasheets and measuring the board.

3a8082e126