𝞵GPU FPGA Project

[theworldbuilder]

Howdy folks,

I'm just opening up a thread for my 𝞵GPU FPGA project.
This project is focused around designing and building a HDMI output "𝞵GPU" for my 8-bit computer project.
(Which is being documented in this thread: Link to the computer project.)

Some details:
The FPGA I'm using is the lattice iCE40UP5k. The devboard is the icebreaker FPGA board: https://www.crowdsupply.com/1bitsquared/icebreaker-fpga

The graphics display modes I'd like to support: a character mode, a sprite mode, and a raster graphics mode.

The output resolution at the minute is 800x600.

I've currently managed to get a character mode pipeline up and working and it's displaying at 50x36 characters. This mode is using an internal resolution of 400x300 just being up-scaled to the 800x600 output resolution.

End goal
The end goal of this is to produce a graphics module that I can use with my 8-bit computer and plug in to a modern HDMI TV.
I'm also thinking that I could use this module with other 8-bit microcomputers to give HDMI compatibility to them, the major issue with this is software support.


Ideas, questions, comments are all welcome!

[theworldbuilder]

Here's an initial update with the current state of the character mode pipeline.

I've got it working!                ... at least on the output end of things.

Currently there is no way to actually write into the Character RAM, instead it's just pre-loaded with a test pattern which displays the full ascii character set.

Speaking of character set, to actually make the character set so it could be edited, saved, loaded, and preloaded into the RAM on FPGA initialisation I made myself a little app using Electron JS. Here's how the apps looking now:

 The image attachment has gone wonky so I removed the inline image

This tool allows me to edit each pixel of each 8x8 character. I can save the set of 256 character, load this file, and also export the files to a set of formatted .mem files to initialise the Character ROM within the FPGA.

Here's the current output from the 𝞵GPU:

 The image attachment has gone wonky so I removed the inline image

The garish colour choice is actually intentional. I was having an issue with just getting a black square displayed so I decided to change the internal palette colours to the horrible red, green and blue you can see so I could see what exactly was going on with the output.

The red will simply be black bars, while the green and blue of each character will be swapped out to whatever colours the character has selected for it.
Each character has it's own associated colour byte which is used to select the background and foreground colour from the background and foreground colour palettes. Each of these palettes contain 16 12-bit colours which the user will be able to set on the fly.

The next step for the character pipeline will be building the read/write control State Machine to deal with reading and writing to the Character RAM, the Colour RAM and the Colour palettes. 

[mariush]

I'd suggest forcing 1280x720 , for highest compatibilty with all devices and minimal if no scaling issues.
The output will work on "hd ready" tvs (native 1366x768) and will scale nicely to 1080p native displays.  720p is also bluray/hd resolution so most tvs will accept a wide range of refresh rates, so you could have 24fps, 25fps, 50 fps, 60fps and maybe could trade refresh rate for resolution at some point.
You can have 1280x720 or you could double every pixel so you'd have 640x360 resolution. You could do 960x720 (with black bars, still output 1280x720)  for 4:3 and have black bars on the sides, and that that resolution gives you 120x90 characters if you do 8x8 characters.

Most TVs should also accept YCbCr 4:0:0  (grayscale) and you can use YV12 (YCbCr 4:2:0) to push fewer bits per frame if that's a concern.


Also maybe inspire yourself from how NES gameboy and others used sprite, it's well documented.

[theworldbuilder]

Thanks for the reply!

Yeah I was thinking that might be true. I was actually eyeing up 1280x720 but with the way my current HDMI generation is set up I'm not so sure it would be possible, although there may be light at the end of this tunnel.

Basically I'm using a VGA core internally (nice and easy to setup and get going in verilog) to generate the timings and then a VGA to DVI/HDMI converter chip to convert the signals for HDMI ouput. This part is all good.
The problem I'm seeing is that the internal PLL withing the iCE40UP5K can allegedly only be cranked up to 48MHz, from my reading of the datasheet and PLL usage guide, which is far below the 73.25MHz you need for VGA to reach 720P.

I say it can only allegedly be run at 48MHz because somebody has already created a 720P output using the icebreaker FPGA board, which can be seen as a demo on their crowdsupply page: Link
So it looks like I've more reading and testing to do!


As for borrowing the NES' way of doing sprites I think that's good idea. It's actually what I'm currently drawing inspiration from. I'm trying to think of nice ways to pimp it out a little without making things more complex for the user. Although that said I'm still very much interested in other systems for handling sprites.

[theworldbuilder]

Just an update with some progress I've made.

I've upgraded the output resolution to 1280x720p! The internal resolution being used is 640x360.

So continuing from my last post the first thing I needed to sort out was the PLL frequency so I started doing some reading of the PLL usage guide from lattice.
As it turns out 48MHz had nothing to to with the PLL. It is actually the frequency of one of the internal oscillators 

So with this in mind I got my PLL configured to output as close to the 720p pixel clock frequency (which is 74.25MHz). This turned out to be 74MHz on the button, close enough

With some tinkering in my VGA timing generator and stage one of my graphics pipeline I got this:


Not quite right.
Some more fiddling in the innards of the uGPU, a few more bugs found and squashed and hey presto! This is what I got:


An 80x25 character display.

I had a sneaking suspicion that 80x25 wouldn't look too great with an 8x8 character size and... well... it's alright I guess.

As I can't change the character size from 8x8 without a crazy amount of rework for little reward I was thinking of changing the output resolution to 50x40.
I'd also like to keep the total number of characters below 2048 (This isn't essential in the slightest, I'm just lazy )


What do people think? Is 50x40 too square? Should I just go for the full monty and take up the full screen? (which would be an 80x45 character display)

Any other suggestions for character resolutions? Just keep in mind the internal resolution is 640x360 so that's the max amount of space for 8x8 characters there is to work with.

[mariush]

Awesome!

You can get loads of fonts from : https://www.dafont.com  - they have public domain, or free for non commercial use, or shareware fonts and you can select bitmap fonts and get fonts easy to convert to sprites

Some examples :

Modern DOS : https://www.dafont.com/modern-dos.font?l[]=10
Pixel Operator : https://www.dafont.com/pixel-operator.font?l[]=10
Minitel : https://www.dafont.com/minitel.font?l[]=10


25 rows is a bit small. I'd consider making it at least 32 (because it's a 5 bit number, 0..31 )  and width maybe at least 64 (6 bits)  ... and 64 would also work because it would be 512 pixels, doubled it's 1024, so you'd be able to use 1024x768 resolution
Though 7 bits for each may make more sense (and use the 8bit as a flag of some sort, like 16pixel wide / tall characters if 8th bit is set)


,,, and hey... 64x32=2048

[Renate]

I've upgraded the output resolution to 1280x720p! The internal resolution being used is 640x360.

Aw seriously? Going through all this trouble and ending up with blocky chars?
Don't upscale, it looks cruddy.

I've got 1280 x 1024 going on my desk (Xilinx Artix 7, 108 MHz pixel clock).
Ok, I've got no chars (yet) but it is pixel resolution.

[theworldbuilder]

You can get loads of fonts from : https://www.dafont.com  - they have public domain, or free for non commercial use, or shareware fonts and you can select bitmap fonts and get fonts easy to convert to sprites

Some examples :

Modern DOS : https://www.dafont.com/modern-dos.font?l[]=10
Pixel Operator : https://www.dafont.com/pixel-operator.font?l[]=10
Minitel : https://www.dafont.com/minitel.font?l[]=10


25 rows is a bit small. I'd consider making it at least 32 (because it's a 5 bit number, 0..31 )  and width maybe at least 64 (6 bits)  ... and 64 would also work because it would be 512 pixels, doubled it's 1024, so you'd be able to use 1024x768 resolution
Though 7 bits for each may make more sense (and use the 8bit as a flag of some sort, like 16pixel wide / tall characters if 8th bit is set)


,,, and hey... 64x32=2048

Wow thank you so much for this!
That website is actually a great resource! And your examples too that you linked.
I was actually thinking of trying out some new font sets, petscii is nice and all but I would like to try out something else.


I think 64x32 is definitely worth trying out and hopefully the next time I post I'll have something to show!
Eventually I will upgrade this to a much larger size but this will come when I start reworking the innards of how the uGPU works.


Thanks again for all this stuff!

[theworldbuilder]

Aw seriously? Going through all this trouble and ending up with blocky chars?
Don't upscale, it looks cruddy.

I've got 1280 x 1024 going on my desk (Xilinx Artix 7, 108 MHz pixel clock).
Ok, I've got no chars (yet) but it is pixel resolution.

Yeah this is a fair observation. I actually was thinking of using 16x16 characters and I probably will once the character graphics pipline is more complete.
But there's a few reasons why I'm sticking with 8x8 for now at least.

Aesthetics:
I actually kinda like the retro looking blocky characters...    Anyone else?

Simplicity:
-The initial upgrade to 720p isn't actually for more output quality, but for more compatibility with HDMI TV's and monitors.
-The simplicity of editing an 8x8 character set, with the little character set editing tool I made myself I have to toggle each pixel in each character. At 8x8 it took me over an hour of work to put together the basic ascii set you can see. And it is very likely I will go back and change this character set a multiple times either partially or completely.
-To get really nice looking character you would want to add some kind of alpha value to pixels to enable a sort of sub-pixel blurring to give characters a nicer look. This would be a rather brutal to implement into my character graphics pipeline, not impossible, just very tough and at the moment it just isn't worth it to me.

--TL;DR--
I'll probably eventually upgrade to 16x16 characters at some point in the future when I'm happy with the character set I want to use. This will look a little better but I don't think I'll escape the blocky look completely.

[Striker]

The blocky characters are okay but the previously suggest fonts may be a bit cleaner at that size (and still blocky at that scale). Do you have any way of directly loading fonts/converting fonts for your use? You mentioned the electron app but is that just if you want to customize an existing font or for making entirely new ones?

[mariush]

I was a bit bored and wrote a super basic font to picture converter in php .. takes a font or list of fonts and makes a png picture for each font.

The code makes it 2048x10, the extra 2 lines are for debugging, to see if the font actually crosses the 8th pixel line (for example Minitel does, it's 10 pixels for some characters and _ char is on the 9th line, but with minor editing to fix some chars it can be used)

ms paint is great for it, you can enable gridlines and zoom to the max

Pro Motion NG is also awesome at sprites and pixel art and all that, and can also export to various raw formats.

You can add your fonts, edit the php file and then simply type in command line php.exe convert.php and it goes through the fonts and dumps png images for each font.
May have to edit font size for some fonts... it's not always 8.


If you don't want to download zips, this is the whole code

Code: [Select]

<?php
$fonts = [];
$fonts[0] = array('size'=>12, 'offset'=>7, 'filename'=> __DIR__ . '/ModernDOS8x8.ttf');
$fonts[1] = array('size'=>6, 'offset'=>7, 'filename'=> __DIR__ . '/PixelOperator8.ttf');
$fonts[2] = array('size'=>6, 'offset'=>7, 'filename'=> __DIR__ . '/Minitel.ttf');

for ($counter=0;$counter<count($fonts);$counter++) {
        // use imagecreatetruecolor if you want.
        // imagecreate creates pallette based pics, and this means restriction:
        // - first call to imagecolorallocate will be background color 
        $img = imagecreate(2048,10);
        $bg = imagecolorallocate($img,0,0,0);
        $fg = imagecolorallocate($img,255,255,255);
        $extras = imagecolorallocate($img,0,128,128);
        // draw a line for debugging purposes to see if font is taller than 8 pixels
        imageline($img,0,8,2047,8,$extras);
        for ($i=0;$i<256;$i++) {
            // debug : add a dot on 10th line where each char starts
            imagesetpixel($img,$i*8,9,$extras);
            // imagettftext wants valid utf-8 sequence and in theory fails on invalid character
            // too lazy to do it properly - 
            // the commented line should give proper utf-8 but you'd have to enable mbstring extension in php
            // and it seems to work without it, so i'd rather have this script working without configuration
            //$char = mb_convert_encoding(chr($i),'UTF-8','ASCII');
            $char = chr($i);
            imagettftext($img,$fonts[$counter]['size'], 0, $i*8, $fonts[$counter]['offset'], -$fg, $fonts[$counter]['filename'], $char); 
            // you can play with the offsets to make the characters tiled vertically.
        }
        imagepng($img,__DIR__.'/out_font'.$counter.'.png');
        
        // kill the image resource
        imagedestroy($img);
}
?>

[lintweaker]

Hi,
What GPU features are you planning? (i.e. things like fill, line draw etc)

[theworldbuilder]

The blocky characters are okay but the previously suggest fonts may be a bit cleaner at that size (and still blocky at that scale). Do you have any way of directly loading fonts/converting fonts for your use? You mentioned the electron app but is that just if you want to customize an existing font or for making entirely new ones?

At the moment, no I don't have any way to import fonts. So basically this app lets me create, edit, save, and export fonts. It shows an 8x8 grid which represents each pixel in the character. You can click on each pixel to toggle it between black and white (1 and 0). It also select what character you're currently editing in a range from 0 to 255. Once I've finished with a character set I can then export the font to a .mem file format which is used by the FPGA to pre-configure the BRAM.


Although having seen this:

I was a bit bored and wrote a super basic font to picture converter in php .. takes a font or list of fonts and makes a png picture for each font.

The code makes it 2048x10, the extra 2 lines are for debugging, to see if the font actually crosses the 8th pixel line (for example Minitel does, it's 10 pixels for some characters and _ char is on the 9th line, but with minor editing to fix some chars it can be used)

ms paint is great for it, you can enable gridlines and zoom to the max

Pro Motion NG is also awesome at sprites and pixel art and all that, and can also export to various raw formats.

You can add your fonts, edit the php file and then simply type in command line php.exe convert.php and it goes through the fonts and dumps png images for each font.
May have to edit font size for some fonts... it's not always 8.

It inspired me to check is something is similar in javascript and use it to add an import functionality to the app.
After a bit of reading I discovered that it is indeed very possible! So the next feature I will be adding to the app, once I'm done building the read write interface on the uGPU, will be an import feature very much inspired by this code!

Thanks again @mariush! Even though I might not be using the code I really appreciate the inspiration!

[theworldbuilder]

Hi,
What GPU features are you planning? (i.e. things like fill, line draw etc)

So I'm planning to support three graphics rendering modes: Character mode, Sprite Mode, and Raster Mode.
Each of these modes will have there own set of features.

Character mode:
- A 64x32 character display with support for 256 different characters.
- Each character can have it's own custom foreground and background colour selected from a 16 colour palette. 
- I'm also considering adding the ability to allow the user to modify the character set as they wish. This would allow for the programmatic loading of a custom character set.

Sprite Mode:
-This is for all intents and purposes going to be an enhanced NES style sprite system.

Raster Mode:
-This is the mode that I have the least ideas about and will probably be the last mode I get to.
-640x360 graphics (230,400 pixels! )
-Off the top of my head, perhaps a 16 colour palette for each pixel to chose from?
-I do hope to add advanced raster graphics features like shape drawing, fill, etc but these are right on the edge of feature creep territory so they will probably be the vary last thing I do.

Honestly with an advanced character mode and sprite mode I don't see a huge appeal for a raster graphics mode but I'll be including it nevertheless.

[theworldbuilder]

Another little update on how things are going with the project:

I've changed the character resolution one last time (for the next while anyway) to 64x32 and this is how it looks:


I love that old CRT orange colour,

Here's it in "Hacker green" as my friend calls it:



Any other cool colour ideas anyone can think of? I was going to try the ZX spectrum black text on a white screen but I'm in no rush to burn my eyes out.


I've also done a little bit of work on the module itself as I tossed together a sample layout in KiCad to see how small I could get the module and here's what I got to:



It's 25mm x 50mm so kinda like an over-sized wide DIP-40. This is all the IC's on the board, the remaining components would all be 0603 passives.
For a scale reference J1 is a standard HDMI connector footprint.

Next step is to actually do the circuit up, route it and see where I am at that point. I'm definitely expecting the board to grow a few mm but if it doesn't that's even better!

[theworldbuilder]

Howdy folks,

Just another mini update:

I've been slowly working through the layout of the board and this is what I've got at the moment:


Almost all of the components are down on the board and some of the basic routing has been done.
I've been finding KiCad quite reasonable to work with, despite what I heard from others who have tried it. It probably helps that I'm in no huge rush to get this done. I have time to learn all of KiCads quirks.

Even though I've managed to place all the components within the 25mm x 50mm board size routing is going to be a challenge as board space is so tight. This being a 2 layer board with all components on one side doesn't help! (4 layers and components both sides would be heaven  . Maybe some day?)
Even if I do manage to route everything without having grow the board, I probably will grow it anyway just to give components a comfortable amount of room. Better safe than sorry!

As always questions, thoughts, etc are welcome!

[theworldbuilder]

Alright so I think over a month is long enough to go without an update,

I've finished the board layout. Here's how it's looking:


In terms of what I had to do between my last post and now, I had to rework the positioning of a number of components, namely the EEPROM, and the two level shifters. This was because the routing of the traces was impossible with the last arrangement. So a little bit of moving around and whaddya know, it fits pretty nicely!

It has been mostly finished for quite a few weeks now, I was just slowly working through the last few pieces of routing that needed to be done. I'm quite happy with how it has turned out; no ridiculous trace lengths or wasted space.

The next steps will be finishing the BOM and getting a Quote from PCBWay. Let's hope its not too pricey!
I don't think it will be too long until I have the first version of the uGPU up and running (Hopefully!). Ain't that exciting?

[c64]

No OpenGL? 

[wizard69]

Very interesting project!!!

For modern high resolution displays you really need larger fonts.   That for old eyes, the cleaner the font the better.   

This brings up an interesting idea, for text mode why is it that hardware doesn't insert a blank row or two of pixels between lines of text?   Seem like an easy way to make plain text on a high resolution display more paper like.

[c64]

Awesome!

You can get loads of fonts from : https://www.dafont.com  - they have public domain, or free for non commercial use, or shareware fonts and you can select bitmap fonts and get fonts easy to convert to sprites

Nice website. I didn't find any raster fonts, do they have any? I'm sure this is what theworldbuilder needs

[theworldbuilder]

No OpenGL? 

 

I'll be lucky if I even get a general set of Assembly routines together interface to this thing 

[theworldbuilder]

Very interesting project!!!

For modern high resolution displays you really need larger fonts.   That for old eyes, the cleaner the font the better.   

This brings up an interesting idea, for text mode why is it that hardware doesn't insert a blank row or two of pixels between lines of text?   Seem like an easy way to make plain text on a high resolution display more paper like.

Yeah I hear ya on font size, its a good point.

Why I haven't inserted blank rows is actually because I want the "text mode" to be usable in different ways. Say someone comes up with their own custom tiles to use they could create a really basic "GUI" using the text mode to tile it all together.

Although that said I may just scratch that idea for text mode and leave it up to sprite mode to provide such functionality.

In which case I would probably add some kind of line blanking for spacing and clarity.

[theworldbuilder]

Alright another little update on the project!

I've finally gotten around to ordering the boards. I went with PCBway as my previous experience with JLCPCB on through hole parts was that they were great value and great for through-hole but their soldermask alignment wasn't great. With this board basically being entirely composed of fin pitch parts (0402, QFN, etc.) I didn't want to chance it with any kind of alignment problems etc.

Total components cost for a single board is ~€18. The FPGA and HDMI converter chip are together over half the cost 

For actually assembling the boards I'm going to take my chances with the "Reflow Skillet" technique. With a laser hand thermometer, a skillet, and some luck I should be able to get the boards together up to at least a hobbyist level of quality.

Hopefully my next post will be with a working board!   

[catmacey]

I'm enjoying reading this thread.

Regarding fonts, have you seen tools like https://www.mikroe.com/glcd-font-creator it's very good for working with fonts for embeded systems.  You can event generate font sets from "real" fonts you have installed on your system.
Another is https://github.com/pavius/the-dot-factory which can produce proportional font data.

Thanks.

[Updated to add correct URL for gld-font-creator and added dot factory link]

[theworldbuilder]

How about an update on the current status of the project?

TL;DR:
The boards didn't work, but I think I've tracked down the issue and have already started work on redesigning the boards.
----------------

So, the "re-flow skillet" technique actually worked and I successfully re-flowed the boards!
The most (physically) painful part was placing the 60-ish SMD components  (~40 of which were 0402 size. Yikes!)

Once the boards were actually re-flowed there were some solder bridges in need of fixing, but between using some solder wick, flux, and a clean iron tip most of these were dealt with fairly easily!

Unfortunately nothing is ever quiet as simple as it seems, and upon powering up the boards and attempting to program the EEPROM I noticed that I couldn't interact with the EEPROM at all.
Strange, perhaps I missed a shorted pin? One more go over with a multimeter put that theory to bed. Maybe there was an issue with the supply voltage?
Checking the 3.3V input I saw it was way up at 3.7V! Not good!

After an excessive amount of debugging and great help from people on a thread I opened. (Link: https://www.eevblog.com/forum/projects/help-with-a-misbehaving-ldo/)
I finally came to realise that the auto-direction level shifters I was using were the root of the problem.
The level shifters were trying to sink current into the 3.3V rail which is what was causing it to be pulled up to 3.7V

So what now? Well I'm going to be replacing these auto level shifters with a selectable Bi-directional level shifter and a uni-directional level shifter.
These won't be too hard to design into the circuit, the main problem is going to be the size of these devices.
The auto level shifters were pretty small and that's part of the reason why I decided to use them.
Any suitable Bi-directional and uni-directional level shifters I have found are, while still tiny, quite a bit bigger than the auto level shifters I was using.
There might be more significant rework of the boards layout if I can't just manage to just squeeze these level shifters in! 
If anyone wants to help me look the parts basically need to be in a QFN kind of package or similarly sized (no BGA stuff pls).

Anyway, for the time being development of the uGPU is going to basically slow quite a bit unfortunately.
It probably wont be until a while into the new year before I get my hands on new boards and get them assembled and tested!
For now I will work on finding appropriate level shifters and altering the design to fit them.

I'm also thinking of working on the digital logic I'm going to use inside the uGPU again.
There is some core functionality that needs to be added to get the tileset graphics actually usable.
It will be hard to test and debug without a physical board but some progress is better than nothing!

Until next time  Stay safe!


If anyone is interested I have attached photos of the populated uGPU board to this post:

[Renate]

Can you just throw a load resistor on the 3.3V rail?
I mean, you've got a bunch of boards, can't you use them for further development for now?

[DiTBho]

is it opensource/hardware?

[theworldbuilder]

Can you just throw a load resistor on the 3.3V rail?
I mean, you've got a bunch of boards, can't you use them for further development for now?

So, there's a little bit more to the problem that I didn't add to save space on what was already a long post.

I did try a load resistor on the 3.3V rail, but for a different reason, I originally thought maybe the LDO wasn't being loaded enough to be regulating properly, this made no sense but it was worth a try.
So I tried loading the line with different resistances. I started from 200K and worked the whole way down to 1K and the shift in output regulation was a move from 3.7V to ~3.5V if I remember right.
Still out of spec

How this ties back in with what I think is the issue is that when I got my hands on the full suite of Ti docs on the part I was using I noticed that every example circuit had a 200K in series with the 5V input.
My circuit design does not. Why? I was working from the example circuit from the Nexperia datasheet. There is no sign of a 200K in series with the 5V input.
Well boy howdy have I learned my lesson not to trust Nexperia datasheets and instead do much more reading with more reputable sources.


As for making use of the boards I have, I'm not sure what to do to be honest.
I can't use the board I have already made up as I accidentally blasted 5V onto the 3.3V line. This surely killed something.
I will use this board to test my theory about the level shifters being the issue if I can isolate the level shifters on the board. I will probably bodge ground to the enable pin / cut traces.

I could make another board but I kinda don't want to waste the €15 worth of parts.



For developing the digital logic I have been doing some digging and found this gem:
https://github.com/hneemann/Digital

For anyone following along with this thread interested in developing digital logic and converting it to verilog for use on an FPGA this is a nice little visual circuit tool.
I will certainly be making use of it to put together and test blocks of logic for the uGPU.

[theworldbuilder]

is it opensource/hardware?

Short answer
Right now?
No

Long answer
Probably in the future I will make the hardware open source.
I would much rather release it in a much more polished and ready to use state.

What's mostly driving me to do this is actually the fact I gained a lot of insight into how to design this circuit from studying the circuits of the icebreaker FPGA board. (link: https://www.crowdsupply.com/1bitsquared/icebreaker-fpga)
I was only able to do it because it is open source hardware. Although I couldn't directly use most of their circuitry it was really great to learn from.

Having purchased and used an icebreaker FPGA board I can say from experience they are great little boards for the price.

As for the HDL stuff on the uGPU, I'm not so sure. I think I would prefer to keep this closed source.

[theworldbuilder]

Here's a micro update:

So the redesigned boards have arrived fresh from JLCPCB.
Parts should be arriving tomorrow so I should be able to get a board built and tested over the weekend. Wew!

I'll post again soon with the (hopefully good) results.

For now here's a pic of the new board:

[theworldbuilder]

Time for some great news!

The uGPU boards work!  I haven't been this excited by one of my projects in a long while!

~6 months after I began this project I now how a working uGPU circuit board!

BUT the project is nowhere near being completed.
The Verilog needs a whole horde of work to even begin to turn this into the funtional uGPU I'm aiming to complete.
But having working hardware to develop on makes this job possible.

The next uGPU related thing I will be doing is working on a uGPU card for my card based 8-bit computer project.
In the mean time I will begin development of the I/O system for the uGPU so that I can begin to get data into and out of the device.

Hopefully a few posts from now I will have some kind of text terminal implemented with the 8-bit computer project that I will be able to show off!


As for the hardware itself, this will most likely not be the last revision of the board.
There are a few things I've already spotted that I would like to change around. This would probably involve making the board longer (and perhaps thinner?)
But we will have to see when this happens, it will probably be some time before I make these changes as they're not necessary right now.


This will hopefully be the beginning of some more interesting posts of the uGPU actually working in circuit!
Slowly but surely. 

Here are some images attached of the board actually working:

[theworldbuilder]

It's back! And in 16 bit!

To sum up the long absence of any posts:
Burnout, burnout, burnout.
After my last post I began to work on upgrading the uGPU RTL and uncovered the Everest sized mountain of work it was going to take to get any of what I wanted completed.
Basically everything was going to have to be thrown out and reworked, and I had no idea where to even begin. This, on top of general burnout from work and life, completely demotivated me for the last ~6 months.
I didn't work on any projects at all, let alone the uGPU.

But recently I began to work on stuff again, spending some time in familiar territory, building analog circuits for guitar distortion pedals and I supposed I was ready for the uGPU again.

The new:
So my first step was to essentially throw all of my designs and notions out the window. This meant, sprite mode and raster mode were out as well as my old pipelined design.

I decided to come from the angle of building a central state machine that would essentially handle memory transfers between VRAM, IO, and the Renderer.
This would make for a much more extendable and modifiable setup.

I also decided set more achievable goals for the uGPU:

• Text mode
• 16 x 16 pixel characters
• 78 x 43 max characters on screen

With these set out I got to work and I'm glad to say that I have gotten the uGPU working with this new design!
I'm currently having some issues where verilog seems to be synthesizing weirdly for me, i.e. minor changes that should have no effect are causing the whole video output to go from working to completely borked.
So I need to get to the bottom of these, they are a sign/symptom of not so good things going on in my code. It also means my sims are basically useless as the sims are showing the exact desired behavior.
The I/O block has also not been implemented, nor the relevant states in the state machine to handle transfers from the IO block to VRAM so this will also need to be taken care of before I can actually use the uGPU.
But I would say that it is closer than ever to a valid usable implementation which is exciting!

I'm currently adding a POR circuit to set and synchronize everything into a known state on powerup; I'm sure this will also cause my synthesis to go haywire so I can wait to debug this one.

I've attached some photos of the current output. Please excuse my crayola grade characters; the important thing is that it demonstrates the functionality of the entire flow from VRAM, through the FSM, and into the renderer.

I'll update here again when I have the I/O implemented and working with my 8-bit computer.
Until then, stay safe!

[theworldbuilder]

At last, I've succeeded.

Thrice I descended into FPGA hell. Twice I was rebuffed; turned away in defeat.

But this time, I've cracked it  All it took was another entire overhaul 

The new++ uGPU design:
This time the uGPU is built around a rudimentary 16bit RISC style processor I created specifically for this application.
The processor is a Harvard architecture, this easily allows it to be a single cycle processor.

The core pillar of the system is that the processor is put into a HALT state where all internal registers are reset until an IRQ comes in.
These IRQs will prompt the processor to do something, like load the next character data into the renderer, or transfer data from the I/O into memory.

The implementation
This being my third redesign, I designed the processor over Christmas (the 'rona made a few near passes on me, I had some spare time while I was avoiding it) and then gave myself 3 weeks to get it all implemented.
If it wasn't done by this Friday just passed I was going to can the whole thing and switch over to using an RPI zero as my video out.

So the deadline was set, and off I went. I ran into many of the same old FPGA hell speedbumps (sims working, FPGA not), and caught many of the same silly mistakes I had learned from already (using combinational logic where I really shouldn't have been).
This time it was make or break. I had to get this working. Tuesday/Wednesday I had glimmers of hope. The internal systems were behaving themselves; the processors IO routine was responding to the IRQ and transferring hardcoded data across to the video memory.
Come Thursday I implemented my first version of the IO block. A mix of messy logic combining combinational and clocked in all the worst ways; but it kind of works. Data is bouncing around not being always written to the write location, but no corruption which is good.
For the first time since I started this project I have data being written into the uGPU (a z80 got that grace) and updating characters on the screen. That felt really good!
By Friday I have made no more progress. In work I scribble out a schematic and simulate it here: http://digitaljs.tilk.eu/ (very helpful online Verilog visualizer, synthesis using yosys).
The logic seems nice and clean but I won't get to implement it until Sunday, as I'm traveling over the weekend. I know it's beyond my Friday deadline, but it was technically designed on Friday and I couldn't give up when I was so close.

So I get in on Sunday and implement and test it in hardware. Now the IO is completely stable no characters being written to the wrong location. But some of the characters just don't seem to be getting written.
With some more serious head scratching I realize that I have set my IO IRQ to clear any time the processors RD signal goes high. That means the processor could be doing something completely unrelated and accidentally clear the IRQ interrupt.
One quick processorRD AND'ed with the IO_CS line later and I have a working uGPU, with no missed character writes.

Success.



... what next?
Relax for a while. But not too long. Just the right amount. Then come back and see what functionality I can extend and add to the uGPU. I now have a processor that I can easily write any sort of program for.
Add cursor functionality? Sure. Add fancy commands like screen clearing? Absolutely. See what I can do about adding hardware scrolling to the renderer and some kind of sprite support? I'll put that on the long finger for now but it is in the pipeline.
I also had to drop the video output resolution back down to 800x600 to minimize timing issues while implementing the design, so one thing I want to try is bumping it back up to 720p.

If people have an interest in the source code, uGPU board design, or whatever let me know. I will put together documentation for myself, but if there's interest in this project I will tidy it up and make it releasable.
No promise on when I would get around to this, I want to write up an assembler and do a few other items for the uGPU's processor for the sake of my own sanity, but I will do it if it's wanted.


I've attached an image I captured of the Z80 writing characters the the uGPU.
I'll upload a video of it to YouTube and link it here when I get a chance.

[dmendesf]

Congratulations, nice work!

[theworldbuilder]

A micro update:

Put together a small Z80 assembly program that let me modify the first 256 characters using a keyboard! The rest of the screen content is just whatever RAM felt like initializing to.
My RPI is sending the characters over via UART to the 68B50 and the Z80 is taking these characters, doing a little bit of checking and then writing them to the uGPU.
I've attached some pics to this post.

When I do dive back into the uGPU I think I will add a screen blank command, set character by XY location command, and some kind of screen scroll command? Oh and try out 720p when I remember!

I think I'll try and get the uGPU working with a 6502 and 6309 soon, should just be a matter of writing some assembly!