FPGA VGA Controller for 8-bit computer

[asmi]

Having checked the datasheet in more detail, you're quite right, it does appear to be out of spec, especially as the voltage coming out is actually slightly higher than the 1.3V required in the design.

Overclocking 101 - before you overclock anything you always establish that device you're about to run out of spec works in spec. As going out of spec is always a lottery. There is a reason the specs are what they are, if Antel would be certain that their devices will have higher performance than they are at 1.3 V, they would certainly market this a a feature. For example, on Xilinx side there are certain FPGAs which are individually tested in production and have embedded VID code telling which voltage they can be ran at to get the most out of them.

Likewise, I can't see how 1.3V instead of 1.2V on Vccint is going to stop the IO at the DAC side from working, when everything else seems fine.

Once you're out of spec, you're in terra incognita, and anything can happen. For all we know, FPGA might be now half brain-dead and outputting a mains voltage on its pins just for the hell of it.

[nockieboy]

Likewise, I can't see how 1.3V instead of 1.2V on Vccint is going to stop the IO at the DAC side from working, when everything else seems fine.

Once you're out of spec, you're in terra incognita, and anything can happen. For all we know, FPGA might be now half brain-dead and outputting a mains voltage on its pins just for the hell of it.

Fair point, I guess I'll have to set the 1.3V output to 1.2V then before I do anything else.

[BrianHG]

1.2v is fine for your design.  The overclock is way too small to need any boosting.  I mentioned it as a last result.
The way I designed the core, errors from overclocking would only represent glitches in the core memory, however, since you confirmed that the Z80 reads and writes to the core memory with the RS232 Debugger, this isn't where your problem lies.
(Only the core dualport ram is running at 250MHz (Of the 240MHz limit reported by Quartus) with an AB-mux switch.  And only around 8 signals are out of slack by less than 0.1ns. Everything else runs at 125MHz and report all in the green by a good margin.)

Did you check that the syncs are coming out of the right pins of the VGA connector?

Are you sending +5V to pin 9 on the VGA connector so that the monitor +Vsense pin knows it is being connected to a turned on video card? Never mind, your old development board doesn't have it.
Also, pins 5,6,7,8 and 10 should be grounded.

Can I see the latest schematic and pcb prints, the white PCB you showed me doesn't match what is posted on here on the forum.  Some Vias don't line up or are missing.

That darn white soldermask doesn't allow you to see anything.

Did your scope show a proper HS and VS coming out of the VGA connector, when connected to a monitor?  This should at least turn on the monitor.

What was the frequency of the CLK output to the DAC?

Can I have a copy of your latest Quartus project?  Your GitHub has only single files and I will not download all the files individually 1 by one.

[nockieboy]

1.2v is fine for your design.  The overclock is way too small to need any boosting.  I mentioned it as a last result.
The way I designed the core, errors from overclocking would only represent glitches in the core memory, however, since you confirmed that the Z80 reads and writes to the core memory with the RS232 Debugger, this isn't where your problem lies.
(Only the core dualport ram is running at 250MHz (Of the 240MHz limit reported by Quartus) with an AB-mux switch.  And only around 8 signals are out of slack by less than 0.1ns. Everything else runs at 125MHz and report all in the green by a good margin.)

Okay, no problem, I'll either replace the ADJ with a 1.2V regulator or adjust the resistors to drop the voltage to 1.2V.  Have updated the schematic as well (though not the copy I'm attaching in this post).

Did you check that the syncs are coming out of the right pins of the VGA connector?

I've checked with my logic analyser, which picked up no signals whatsoever.  I've yet to get the oscilloscope set up - unfortunately I haven't had the time or space to dig it out and get it set up, have been too busy with work, but will try to do some testing with it and get some results soon.

Are you sending +5V to pin 9 on the VGA connector so that the monitor +Vsense pin knows it is being connected to a turned on video card? Never mind, your old development board doesn't have it.
Also, pins 5,6,7,8 and 10 should be grounded.

No, but I've added that into the schematic for the next iteration of the board.  I note that a couple of pins in the VGA standard are for an I2C connection to a ROM in the monitor?  Presumably to identify the monitor and get resolutions etc?  My uCOM has I2C, so I'm wondering if it would be worth connecting it up to the VGA port as well.  Might be something to look at later.

Did your scope show a proper HS and VS coming out of the VGA connector, when connected to a monitor?  This should at least turn on the monitor.

No, there's nothing coming out of the VGA connector at all as far as I can tell - with the caveat that I haven't yet got the oscilloscope on it.  I've checked these signals back to the FPGA and there's nothing coming out of the FPGA, so it's not (necessarily) the DAC or hs/vs driver (U6).

What was the frequency of the CLK output to the DAC?

I have no test equipment that can measure a 50MHz signal.  My scope is only 20MHz and it's as old as the hills. The best I can do is jury-rig a couple of FFs and divide the clock by 8 or 16 to measure it on my logic analyser or oscilloscope, with all the associated extra wiring and bad connections that brings with it.  I'm actually waiting on some PCBs and parts to make up a proper clock divider.

Can I have a copy of your latest Quartus project?  Your GitHub has only single files and I will not download all the files individually 1 by one.

All attached below. 

[BrianHG]

Unless the board is held in reset by the reset input, a sync must come out as that sync generator section is hard wired logic.

As for the clock, it is 25Mhz, and a 20MHz analog scope should see it as a sine wave.  If we have it at 50MHz, it would be a shriveled sine wave.

You have a few more questionable soldering GNDIO and VCCIO and VCCINT around the sync lines and the port on the photo you provided which was true-white / bottom left side.

Your meter may still read these as connections since there are multiple VCC & GND connection inside the FPGA, but don't let that fool you, with a small 144pin package, every VCC/GND still needs a physical good connection otherwise funny things happen as seen on other homemade PCB FPGA threads here at EEVblog.

[obiwanjacobi]

Not read the 40 pages preceding this - but it might be an idea to make the simplest 'hello world' code and start testing the basics and work up from there. Sounds like you need to establish what is working and what is not at a basic level.

[BrianHG]

Not read the 40 pages preceding this - but it might be an idea to make the simplest 'hello world' code and start testing the basics and work up from there. Sounds like you need to establish what is working and what is not at a basic level.

The code is good.  nockieboy got it fully functional on a dev board with a good CycloneIV on it.  He has poor soldering joints on his home made board and bought his CycloneIV from a questionable source, as he already discovered that it has 1 confirmed dead IO pin.  Other than a voltmeter, his old analog scopes hasn't been able to tell him much other than all the IO feeding the DAC are dead.

[nockieboy]

Yeah, nothing further to add - the oscilloscope is showing all the IO are dead for the RGB and HS/VS outputs.  I'm just waiting on some low temp solder, an IR temperature gun and I'll order a good FPGA from a reputable source before trying again.

[BrianHG]

I would still 'drag' solder all the pins on the sides I mentioned.
In fact, with normal leaded solder, I would blob solder the pins, then, using solder wick, wick us the excess.

You have nothing to loose at this point.

[asmi]

I would still 'drag' solder all the pins on the sides I mentioned.
In fact, with normal leaded solder, I would blob solder the pins, then, using solder wick, wick us the excess.

You have nothing to loose at this point.

Or add a crap ton of tacky gel flux, and then go with a molten solder "ball" across all pins. Flux will prevent bridges, while excess solder will ensure good wetting.

[BrianHG]

What the results of drag soldering should look like with normal solder: 



Take a look at 4:15.  This is what your soldering should look like.

[obiwanjacobi]

I remember that when I first tried soldering SMD, I found it easier to get good (enough) results with simply using a small soldering tip and carefully touching up on each pin individually. My point: you don't have to drag-solder.

You DO need lots of flux and use very little solder.
Also be careful with using wick - better to prevent that by using very little solder.

[2c]

[SiliconWizard]

Gel flux helps a lot.

I for one usually don't "drag solder". I usually rather solder a few pins at a time with either a bevel or chisel tip (depending on pitch and accessibility), essentially "dragging" along the pins being soldered rather than dragging along the side of the package. Takes maybe a little more time, but it's still fast and tends to make fewer bridges. YMMV.

[nockieboy]

I had been using a wedge tip with a tiny blob of solder on the end and lots of waxy flux.  Had got it so that I could do a whole side of the 144-pin FPGA with no bridges, or a couple if I was unlucky.  I did try drag soldering, but found it just seemed to bridge the entire set of pins, no matter how much flux I used.

As soon as the IR thermometer arrives, I'll try another of the cheap FPGAs (I have two left) and see how they go.  I'm probably completely wrong, but I feel that I may have been overheating the chips when I was hot-air soldering the central exposed ground pad on the last couple of attempts.  I do that first, then I go round the FPGA soldering its pins using the methods above.

[nockieboy]

Okay, so I might have found out why the RGB and HS/VS outputs of the FPGA are 'dead'... 



I hadn't included an inverter on the Z80's RESET input to the FPGA.  RESET on the Z80 is active low, this is obviously in opposition to the workings of the FPGA's positive logic, meaning the video circuit was constantly in a state of reset and not outputting ANY colour signals or video sync signals.  I've added the inverter as shown above in the red circle, and I can now get good, clear HS and VS signals from my latest board.  (I say latest, it's the third board I've built so far - the first being the only other working one, but with the bad IO on the data buffer.)  So I'll get the rest of the video circuit built on this latest card and give it a test.

Still, it's been good practice soldering these TQFP-144s.  This latest board is looking much neater. 

[nockieboy]

Have just uploaded the new HDL to the first board I'd made (the one with the alternate GPIO used for the data direction on the Z80 interface to bypass the bad IO pin) and it's working perfectly.  Image is stable, all the colours are there, everything seems to be working fine. 





The second board I made seems to be dropping bit 0 on the data bus, so there's probably a bad IO on pin 142 for that board.  I haven't got around to building the DAC and VGA output part of that board yet.

The third board (version 2 PCB with AS/JTAG connectors spaced further apart, spare IO pins exposed as pads on the PCB and another spare GPIO wired to an LED) is working just fine so far, but I've yet to solder the DAC onto the PCB.  It's outputting HS and VS fine, though.



So I'd call that a successful project! 

I've thanked you previously, but I'll do it again - thanks for your help BrianHG and everyone else who has chipped in with info and suggestions.  It's all very much appreciated. 

Once I'm happy with my HDL code additions (for the LED and audio output for testing), I'll update the github repo with the latest version of the project.

I'm waiting on some PS2 keyboard connectors - when they arrive, I can start on working on keyboard integration into the project.  That'll make my computer fully stand-alone, so it's a major milestone for me.  After that/while I'm waiting on the post, I'm starting to look into integrating an AY-3-8910 or YM2149 (old 80's sound chips) into the FPGA, somehow.  I have spare IO to drive a stereo output, it's just a case of adapting what little I can find out there to work on my EP4CE10.  I'm also giving some thought to how I'm going to give the Z80 access to an SD card via the FPGA too.

Oh, and of course continue working on the software side for the video output.  I'm tempted to start investigating the graphics modes on the FPGA/MAGGIEs and develop some graphics functions (PLOT, LINE, CIRCLE etc) in software - but I'm wondering if they could be done in hardware somehow, too?

[asmi]

Congratulations!

I'm waiting on some PS2 keyboard connectors - when they arrive, I can start on working on keyboard integration into the project.  That'll make my computer fully stand-alone, so it's a major milestone for me.  After that/while I'm waiting on the post, I'm starting to look into integrating an AY-3-8910 or YM2149 (old 80's sound chips) into the FPGA, somehow.  I have spare IO to drive a stereo output, it's just a case of adapting what little I can find out there to work on my EP4CE10.  I'm also giving some thought to how I'm going to give the Z80 access to an SD card via the FPGA too.

If you have documentation describing how it works, I would just implement it inside FPGA too (sound chips of that era were very simple - just a bunch of various waveform generators and a mixer to mix them together), and add an I2S DAC to actually output sound. This will also open a possibility of outputting high-quality audio too (like waveform players, which present in some audio chips of that era or maybe a bit more recent), as all I2S DACs support at least 44.1 kHz/16bit format (this used to be called "CD quality" as that's the format used on audio CDs, of course they support lower bitrates too). I2S bus is also extremely pin-efficient, requiring only 3 pins (bit clock, left/right signal and a serial data line), and it doesn't require particularly high frequencies too (unless you want to output audiophool-grade signals at insane bitrates, even though most people would never hear the difference).

Also - have you considered placing it all on a single PCB once you ensure your prototype works?

[nockieboy]

Congratulations!

Thanks asmi! 

If you have documentation describing how it works, I would just implement it inside FPGA too

Yes, that's the idea.  Currently I'm using less than 50% of the logic and RAM in the EP4CE10, although I'll increase the number of MAGGIEs and RAM exposed to the host system shortly, I'm intending on keeping some spare space for the PS2 keyboard interface and whatever I can implement to make some noise.  Ideally, I'd like to emulate the AY-3-8910 (or YM2149 - same thing, basically) so that I won't have to change any of the chiptune software I have in CP/M (aside from port numbers in the 'driver').

(sound chips of that era were very simple - just a bunch of various waveform generators and a mixer to mix them together), and add an I2S DAC to actually output sound. This will also open a possibility of outputting high-quality audio too (like waveform players, which present in some audio chips of that era or maybe a bit more recent), as all I2S DACs support at least 44.1 kHz/16bit format (this used to be called "CD quality" as that's the format used on audio CDs, of course they support lower bitrates too). I2S bus is also extremely pin-efficient, requiring only 3 pins (bit clock, left/right signal and a serial data line), and it doesn't require particularly high frequencies too (unless you want to output audiophool-grade signals at insane bitrates, even though most people would never hear the difference).

I'm definitely no audiophool - in fact I'm pretty much tone deaf.   Whilst the idea of CD-quality output is nice, it's not essential - I'm working with an 8-bit processor and am looking to recreate audio capabilities of its era, generally (though any improvement would be great; I'm obviously not too concerned about being period-accurate, otherwise I wouldn't be using an FPGA in the first place!) 

Also - have you considered placing it all on a single PCB once you ensure your prototype works?

It'd be an expensive PCB and besides, I've made it to be as modular as possible.  What you see in the previous post is a stack of five cards, from bottom to top:

• Power/Serial/I²C card (red)
• Z80 CPU card (black)
• Memory card (2 MB) (blue)
• CF storage card (green)
• Graphics card (white)

You can add another memory card to up the memory to 4 MB, add other interface/IO cards etc, but as a bare minimum you just need the power, cpu and memory card to have a working system and can expand it as you see fit.  In future I'll likely be adding more cards to the mix - different CPU's, for example - with a Motorola 68010 being a clear destination on my mental roadmap. 

[BrianHG]

Congratulations!

Too bad that over a few months gone to waste on an inverted reset input signal. 

At least the RS232 debugger wasn't tied into a reset and still functioned, otherwise with nothing working at all, who knows what you would have done with what would have been almost a totally dead FPGA...

[asmi]

I'm definitely no audiophool - in fact I'm pretty much tone deaf.   Whilst the idea of CD-quality output is nice, it's not essential - I'm working with an 8-bit processor and am looking to recreate audio capabilities of its era, generally (though any improvement would be great; I'm obviously not too concerned about being period-accurate, otherwise I wouldn't be using an FPGA in the first place!) 

That's fine - you can work with 8 bit data internally, and upconvert data to 16 bits (or even to 24 bits) right before sending it off to DAC - basically you left-align the data by adding 0x00 to the right (equivalent to logical left-shift by 8 ). Since the I2S is a serial bus, it doesn't cost you any more pins and no FPGA resources because I2S protocol itself requires sending quite a bit of "nothingness" for padding purposes.

Come of think of it, I also wonder when (historically) DMA became a thing in computers, because playing waveforms off storage it real time is going to consume quite a bit of CPU time. My memory is rather fuzzy on that I was born in 84, so most of pre-IBM PC stuff went before I got into computers

It'd be an expensive PCB and besides, I've made it to be as modular as possible.  What you see in the previous post is a stack of five cards, from bottom to top:

I just think that having a single board (or more sensible modularity a-la computer motherboard with main board and extensions as opposed to "sandwitch-style") looks better, but it may be just me

[nockieboy]

Congratulations!

Too bad that over a few months gone to waste on an inverted reset input signal. 

Thanks!  Yep, well, at least I'm not working to any kind of deadline.  It's just something I'm doing to pass the time, and it's certainly doing that!    Funny how I instantly doubted my soldering and the hardware before checking the software more thoroughly.  Can't even remember why I was looking at the reset circuit and noticed the problem with the Z80's reset line. 

At least the RS232 debugger wasn't tied into a reset and still functioned, otherwise with nothing working at all, who knows what you would have done with what would have been almost a totally dead FPGA...

Well, I was able to operate the speaker via IO port writes from the Z80, and read/write the GPU RAM, so I knew the FPGA wasn't totally dead, but I'd have ordered more FPGAs (from expensive but reputable sources), doubted my soldering skills even more and eventually given up, probably. 

[nockieboy]

Come of think of it, I also wonder when (historically) DMA became a thing in computers, because playing waveforms off storage it real time is going to consume quite a bit of CPU time. My memory is rather fuzzy on that I was born in 84, so most of pre-IBM PC stuff went before I got into computers

Oooh I won't be playing waveforms or anything like that - at least not in the way you're thinking.  Before DMA and IBM-style sound cards, in the realm of 8-bit computers in the early 80's, a dedicated sound chip was used and data sent to it on a byte-by-byte basis with instructions on volume, pitch, duration etc.  It was still CPU-intensive and I think the commands/data to the sound chip were usually updated during the blanking interval at the end of each frame (I'm no expert though, so don't quote me).

I just think that having a single board (or more sensible modularity a-la computer motherboard with main board and extensions as opposed to "sandwitch-style") looks better, but it may be just me

The decision to go the route I've gone with the stacking headers boiled down to some VERY early (and uninformed) decisions I made when moving from breadboard to PCB a year or two back.  When I started, I knew next to nothing about electronics, PCBs and all the essential skills you need to design and build this kind of project.  Stacking headers seemed the most cost-effective and easy way to get the project working, given my skills and knowledge with electronics at the time.  Now, however, being more experienced in everything from electronics to soldering to PCB design, I'll likely change the format completely when I move on to a 16-bit system for my next project, but that's still a long way off yet.

[NorthGuy]

Congratulations! I haven't participated in the thread, but I have followed. Great job!!!

[BrianHG]

@nockieboy, how's the DAC's quality?

     There was one thing about the data and clock feeding the DAC's digital inputs which I didn't consider when setting the output pins because of the slow 25MHz speed.

     If you see any pixel glitches, or, when you finally create a 'grey' ramp test pattern with each shade of grey being at least 4 pixels wide, if there are any fine vertical stripes between any 2 grey shade bars, inverting the DAC's CLK output pin will solve the problem.

     (This is due to driving the data lines and the CLK output both from D-flipflops outputs and we may be violating the setup&hold time for the DAC's digital inputs as all the transitions are right at the same time as the rising edge of the clock.)

[BrianHG]

Oh, and of course continue working on the software side for the video output.  I'm tempted to start investigating the graphics modes on the FPGA/MAGGIEs and develop some graphics functions (PLOT, LINE, CIRCLE etc) in software - but I'm wondering if they could be done in hardware somehow, too?

Yes.  You would create a command port address where the Z80 can feed a small FIFO input which would have something like a 16-64 commands x 64 bits (16-64 commands x 8 word x 8bits each).  Something like a 8bit function, pen FG/BG color & fill color, start x,y, end x,y coordinates + a third set of x/y coordinates if you want to make a triangle filling engine.

On the other side of the command FIFO, you would have your sequencer which would read a 64 bit command from the fifo whenever it is not empty, you will loop the start and end coordinates in the drawing pattern & write to a free memory port since you have 15 read/write ports running at 25MHz.  This would sacrifice 1 maggie channel as it would become a hardware accelerated pixel plotting channel.

1 more memory channels will be needed if you want to accelerate copy & paste graphics memory.  Something like a software sprite, or accelerated graphical paintbrush or fonts.

Those 15 ports gives you some cool capabilities, not to mention that you can use this engine to feed the main Z80 port as well allowing a drawing engine which can fill up to 125 million pixels a second instead of 25 million pixels a second.