Home-made Beeb-to-VGA interface

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
Post Reply
prophet36
Posts: 11
Joined: Tue Jan 10, 2012 1:51 pm
Contact:

Home-made Beeb-to-VGA interface

Post by prophet36 » Sat May 11, 2013 8:25 pm

I thought some of you might be interested in this little side-project I've been working on for a couple of days. I have long been dissatisfied by the display options for my BBC Micro, so I decided to try to make my own line-doubler to enable a VGA monitor to be used with the Beeb.

My approach was to take the raw digital signals for R, G, B, HS and VS from inside the BBC, along with the 16MHz clock with which they're all synchronous, and connect them to a cheap FPGA board via a little level-converter board I made a couple of years ago. The FPGA drives the monitor directly via some series resistors on R, G & B:

Image

Internally, the FPGA has two 1024x3-bit RAMs. Whilst pixel data from the BBC is being written into one buffer, the pixel data previously written to the other buffer is dumped out to the monitor twice, and then the buffers swapped: that is, for each 15.625kHz (64µs) Beeb scanline, I generate two identical 31.250kHz (32µs) scanlines for the monitor. The frame rate remains at exactly 50.000Hz, so it will not work with a few monitors.

Here's a pic for comparison:

Image

The top image is from my commercial RGB-to-VGA scaler; I bought it from Maplin back in 2009 for £160. The bottom image is the output of my much cheaper home-made scaler.

What this comparison does not show is the fact that with the commercial scaler there's a constant subliminal flicker around the text, making it extremely unpleasant to look at for any length of time. As for the home-made solution, the image is completely steady with no discernible flicker or blurriness. On the other hand, my solution depends on access to the raw pixel data on its way out of the Beeb's video processor, so you could say I'm cheating. Also, the commercial unit supports composite and S-Video, which mine does not.

It's still not quite usable, there are some bugs remaining, but it's getting there. As always, my VHDL is available on GitHub.

Right now it generates a 640x512@50Hz-ish signal, which is great for CRTs but for LCDs it will be better to generate a signal which exactly matches the LCD's native resolution to avoid invoking the LCD's shonky built-in scaler. I'll be sorting that out once I've ironed out the current bugs.

Is this something other people would be interested in, or is this just my OCD demanding clearer Beeb images? If it's popular I could have some PCBs made. Depending on how many boards I make, the total per-board component cost will probably be about £25. And the design will of course remain free (as in speech) - I tend to release VHDL and software with LGPL, and PCBs & schematics with CERN OHLv1.1.

Chris

User avatar
leenew
Posts: 3963
Joined: Wed Jul 04, 2012 3:27 pm
Location: Doncaster, Yorkshire
Contact:

Re: Home-made Beeb-to-VGA interface

Post by leenew » Sat May 11, 2013 8:29 pm

Interested 8)

User avatar
retroclinic
Posts: 3032
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: Home-made Beeb-to-VGA interface

Post by retroclinic » Sat May 11, 2013 9:17 pm

Hi.

I looked at this a little while ago, and you've done a good job, and got the point I did. The trick though, is to make it work with a sharp stable picture, without any internal connections to the Beeb, IE one that simply plugs into the RGB socket, and is powered from it. I could never get the code right so that the image was stable, it was always shimmering by 1 pixel left and right because of the clock differences.

I had another design which replaced the Video ULA, and emulated it, and at the same time scan doubled the signals to produce a VGA output, but I never finished the project, as I got stuck trying to get the cursor to work properly! You might want to look into going in that direction.

Mark.
Image

prophet36
Posts: 11
Joined: Tue Jan 10, 2012 1:51 pm
Contact:

Re: Home-made Beeb-to-VGA interface

Post by prophet36 » Sat May 11, 2013 9:39 pm

I never intended this to be a "fully external" solution. Having access to the 16MHz pixel clock is crucial to getting this to work with a stable image, so it was always going to be an internal mod.

Also, out of interest, why do you suggest I go for the much more complex solution of reverse-engineering the video ULA? I can imagine a solution where I make a board which plugs into the ULA socket and the original ULA plugs into my board connected pass-through, for easy access to the 16MHz clock and the R, G & B lines, leaving only two flying wires to connect to the 6845 for HS and VS, but why would I want to reimplement the ULA itself? My code is currently fewer than 150 lines of VHDL, and I've got a crystal-clear, rock-steady image on my VGA monitor. Plus, with a bit of work, this approach could be made to work with other machines like the C128 and Amiga.

Chris

User avatar
1024MAK
Posts: 9209
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Home-made Beeb-to-VGA interface

Post by 1024MAK » Sat May 11, 2013 9:46 pm

I was about to suggest a piggy back :!: :lol:

Sounds, or maybe that should be looks like you are having fun. Keep at it :D

Mark

User avatar
retroclinic
Posts: 3032
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: Home-made Beeb-to-VGA interface

Post by retroclinic » Sat May 11, 2013 9:52 pm

prophet36 wrote:....why do you suggest I go for the much more complex solution of reverse-engineering the video ULA?....
Because it's actually quite simple to do (apart from the cursor size that I got stuck on, but I'm sure that's not difficult, as others have RE'd the whole machine, so have worked it out), and if you're using a CPLD, even a small one will have plenty of capacity, so why not, for the sake of a few extra lines of code, have the facility to completely replace the Video ULA, and save having to put an original back in the socket?

Also, if you use the border blanking (Pin 26 DISEN) as a source, you can recreate the H and V sync so no need for any flying wires.

Thx, Mark.
Image

User avatar
hoglet
Posts: 8530
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Home-made Beeb-to-VGA interface

Post by hoglet » Sun May 12, 2013 9:45 am

As you have probably gathered from the Atom Colour Board thread, I've also got an interest in FPGA based VGA video adapters.

The current design uses only externally available signals, manages a pixel perfect mapping of the Atom video frame to VGA. To do this I had to:
- Use cascaded Xilinx DCMs to multiply/divide the 32MHz FPGA clock to an exact 8x multiple of the Atom 3.5759545MHz clock.
- Use quite of lot of digital signal conditioning to clean up this signals, because there is lots of crosstalk etc. on the atom video signals. The point at which Atom pixels are sampled is *very* carefully controlled.
- Use a full frame buffer, rather than just a single line. This fitted into the FPGA I was using, which is quite large.
- Use cascaded Xilinx DCMs to multiply/divide the 32MHz FPGA clock to something pretty close to the VGA clock.
fpgaBlockDiagram.png
fpgaBlockDiagram.png (30.08 KiB) Viewed 1141 times
The output VGA frame rate is nominally the same frequency as the Atom frame, but is not locked in any way, and every 30s or so a frame needs to be skipped to take up the slack. I expected this to be noticeable in scrolling games like Defender and Omega Mission, but it really isn't.

I would love to remove the need for the full frame buffer, which would mean needing to lock the VGA frame timing much more closely to the Atom frame timing. The conventional way to do this is with a VCO, which means more/complex hardware. I did some experiments with an alternative approach. It turns out the my VGA monitor (a lovely 4:3 HP LP2065) is quite happy with either 524 or 525 vertical lines, and in fact is tolerant of switching between either on a frame by frame basis without loosing lock. There is enough slack here to keep the VGA framing locked to the Atom framing, even though the VGA timing is generated off a free running clock. I never got as far as prototyping this, and I wasn't sure how widely applicable this would be to other LCD monitors.

I'm happy to post more details, share VHDL etc if anyone is interested.

More details here:
http://www.stardot.org.uk/forums/viewto ... =90#p58741

I'd also love to give this a go on the BBC as well, then I can get rid of my cheap GBS8200 adapter which doesn't work that well.

Dave

User avatar
jgharston
Posts: 3673
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Home-made Beeb-to-VGA interface

Post by jgharston » Sun May 12, 2013 10:26 am

retroclinic wrote:The trick though, is to make it work with a sharp stable picture, without any internal connections to the Beeb, IE one that simply plugs into the RGB socket, and is powered from it.
What I'd do is reuse the Video Out connector as a 16MHz connector, so the only internal modification is to disconnect the VidOut and replace it with a flying connection to 16MHz, then the video converter is purely an external plug-in device, plugging into the RGB socket and the 16MHz (formerly Video Out) socket.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

prophet36
Posts: 11
Joined: Tue Jan 10, 2012 1:51 pm
Contact:

Re: Home-made Beeb-to-VGA interface

Post by prophet36 » Sun May 12, 2013 10:30 am

hoglet wrote:I'm happy to...share VHDL etc if anyone is interested.
I think you can pretty much assume people will be interested. Why not just choose a licence and push your SCM repo to an online community like GitHub?

I like the idea of 8x oversampling the video signal and choosing the sample point. A bit like how USARTs work I guess, but syncing for a whole scanline rather than just one byte.

Chris

User avatar
hoglet
Posts: 8530
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Home-made Beeb-to-VGA interface

Post by hoglet » Sun May 12, 2013 11:00 am

prophet36 wrote:I think you can pretty much assume people will be interested. Why not just choose a licence and push your SCM repo to an online community like GitHub?
More than happy to do this. At the moment I'm pushing some of the tools for the AtomSoftwareArchive project to github, so I'm a bit buried. If I forget to do this in the next couple of day, feel free to nag.

Dave

prophet36
Posts: 11
Joined: Tue Jan 10, 2012 1:51 pm
Contact:

Re: Home-made Beeb-to-VGA interface

Post by prophet36 » Fri May 17, 2013 5:40 pm

So there were two remaining bugs in my converter.

The first was a constant flicker. On closer inspection it looked like every other frame was being shifted down by one row of pixels. Evidently there was some subtlety to the timing of HSYNC and VSYNC that was unclear to me. So I cobbled together a logic analyser capable of continuously sampling the levels of R, G, B, HS and VS inside the BBC Micro at 16MHz and streaming the data back to my PC. Then I wrote a little program to render the result as images (see below).

The result is rather interesting. I was assuming that VS would be asserted at more or less the same time as HS. But of course the Beeb was designed to be used with a regular PAL TV, which displayed 25 frames of 625 lines per second, but interlaced such that one frame required two raster traversals: drawing the even scanlines and then the odd scanlines. So VS asserts half-way through a line, and the position of the assert on the line tells you whether or not this is an "even lines" frame or an "odd lines" frame.

In the pics the HSYNC pulse is rendered in grey on the left-hand side, and the VSYNC pulse is rendered in red at the top. There are two images for each of the screen modes 0-6, even frames and odd frames.

Great, so I added a quick fix to the VHDL to honour the even/odd distinction, and now everything works perfectly.

The second, and more serious bug has to do with MODE 7. My converter's rendering of MODE 7 has always been a bit flaky - I've been concentrating on MODE 0 because I naively assumed that if I got the highest-resolution modes working, the lower-resolution modes would "just work".

But it turns out that the text-only MODE 7 is far more complex than you'd give it credit for. Whilst all the other modes display 640 pixels per line on a 16MHz pixel clock, MODE 7 effectively displays 480 pixels per line on a 12MHz pixel clock, but interlaced to display 500 lines. The SAA5050 chip responsible for MODE 7 actually only stores a 5x9 glyph for each character, but it renders them as 10x18 on the fly, using a kind of 1970s-vintage subpixel smoothing algorithm.

So the output from my converter in MODE7 is noisy and flickery and rather unpleasant. The noise problem could be readily fixed by switching to a 48MHz sampling clock, but the flicker would be more difficult to eliminate: the bottom line is that my simple "store each line and replay it twice" approach is just fundamentally broken in MODE 7 because unlike all the other modes, the actual data sent to the monitor during even frames differs from that sent during odd frames.

So right now I'm shelving this project. I would like to see if it works with other similar machines, like the C128, but for now I'm moving on to other things! The main purpose of this project has been the learning experience, and the converter does work beautifully in modes 0-6, so overall I'm happy with it. And the electronic archaeology involved in analysing the inner workings of a machine that was such an important part of my childhood has been fascinating.

If anyone's interested, all C & VHDL code and raw logic analyser data is available here: https://github.com/makestuff/rgb2vga

Mode 0, odd frame and even frame.
Mode 1, odd frame and even frame.
Mode 2, odd frame and even frame.
Mode 3, odd frame and even frame.
Mode 4, odd frame and even frame.
Mode 5, odd frame and even frame.
Mode 6, odd frame and even frame.

Chris

Post Reply