Why mod.. when you can make?

User Tools

Site Tools


devblog

Older entries are here

Developer Blog

HDMI alpha notes

Quick post, so I ramble a bit :) So 2020 happened and we all got busy with a certain existential world crisis and many of my hobby projects just went on .. suddenly forgotten in changing priorities; mostly ended up 'wasting' my spare time instead of 'being useful' with it .. at least I turned nervous energy into cycling a lot, for fitness and give myself a focus. Anyway.

Some fine folks on Youtube have been posting comments <sorry, I didn't see them for awhile!> asking about some of the HDMI code. As I mentioned there, the better parts of the code are more closely intertwined with zikzak and in various states of <dis>repair. When you're rolling the whole machine from hardware to firmware and OS, and all the test cases for every single little bit (test main keyboard combinations, joystick, SD card, external clocks, video in various modes and colour test patterns, sound in various forms, the cart slot, flashing a cart, the OS debugger, the OS functions, etc etc..) .. you tend to have hundreds of tiny little snippets piling up. When building a video system, you're making a design on back of the envelope then implementing software drivers and some test code, then changing design and hardware spec and OS and test code and they all tend to tightly depend on each other … not like most sensible software systems where you have well defined contracts between components so each can be developed separately. As I'm just having fun learning I've been a little fast and loose with compartmentalization and leaky abstractions so things get tangled pretty quick - its not such a discrete 'heres a working simple video system' as 'heres some video stuff that doesn't do anything except when the other parts of the system bus are doing this, and that….'. Its a funny place in the zikzak where the entire machine could be done on a single chip but I'm very carefully going out of my way to try and make it more retro styled (cpu, gpu, IO all separate and not just done in the mcu or fpga.)

All that said, I've not packaged up any current code as 'current' is a shifting thing. Whats current when theres 30 directories of 'things' in motion? :)

But! Some of the earliest experiments are a little more standalone. I've got a moment so heres a few files .. If you need, I can try and make a 'hello world' Vivado project and zip it up but heres a first step in case it helps. Time is ever tight!

Credit: Much of this is swiped from fpga4fun - I stumbled across their site years ago and grabbed a few files, and found them extremely useful! Note that much of the HDMI spec is hidden behind paywalls in various working groups that only large companies are privvy to, so finding a few snippets here or there is all we hobbyists can really get.

I'm not sure if fpga4fun is clear for you - they know what they're doing more than I, but they're just hacking around having fun too - but his code works and is enough to bootstrap your own work. If you understand how analog VGA works it should be fairly easy to pick up how HDMI works .. despite being digital its not all that much different to VGA at a level of abstraction but in practice the timings are now super critical (hence good fodder for FPGA); doing VGA with sloppy timings generally works out well (get your vsync and hsync interupt calculations half right and everything else will render _something_) and you can pull it off on darned near any chip in some form or another, but HDMI requires rock solid timings or you just get 'nothing'. Also, those timings are high speed and LVDS so its much harder to inspect with budget lab equipment (your low end Rigol won't have the bandwidth to see anything, and DS requires a fancier scope to see at all)

That said, heres 3 files zipped up; they'll just show you the cribbed fpga4fun stuff, commented and mapped to my own board, in case it helps; this is very early alpha stuff, but again .. it works and renders a test pattern; I forget where in the lifcycle of dev this code is, but I think I had commented in there on how to do the test pattern and what the bits of code are for.

Not including the 'board constants' file since its extremely board specific (and no one has the board but me) but the key is to just set the appropriate pins to TMDS or LVDS etc depending on your IDE. set_property -dict { PACKAGE_PIN L17 IOSTANDARD TMDS_33 } [get_ports { JA1P }];

The actual HDMI files are here: zikzak-hdmi-experiment-alpha-vivado-stuff.zip

blinken - just sets up some clocks

HDMI_Emitter_TOP - this is the setup and top level for the HDMI module below; this takes the clocks in and multiplies up to the HDMI clock needed, maps board output GPIOs to the HDMI modules output signals, and blinks LEDs for fun

HDMI_video - this is the actual HDMI code, the only real piece you need (plus HDMI_Emitter to see the high speed clock generation); you could probably drop the two HDMI files into your own project and get them working pretty quick; if you only look at one file, this is the one!

- theres a test pattern generator in there a couple times I think, for you to fiddle with; ie: its essentially an 'if statement' block that says turn red or green or blue on when we're at this raster line or column, sort of thing; you can fiddle around to make basic images. –> in the later code, this is where its reading from a ram chip, or pulling off a bus; and I get goofy with pre-fetching off the bus into FPGA RAM and then rendering from that, and all kinds of experiments and messyness I never finalized, but you see the point

The rest of the first module just sets up the TMDS encoder sub module which does the 'unpublished HDMI magic' the working group doesn't want you to see.

Anyway, this is rambled enough and I need to get to work! Cheers folks!

2020/09/11 14:44 · Jeff Mitchell · 0 Comments

Whats coming next? Spartan-7, HDMI + VGA, homemade laptops/consoles?! ..

Another year or so passed, and I've gotten a bit of free time sorting out again!

This round, after encountering the limits of the Spartan-6 chip I had, I thought I'd look again at the Spartan-7 platform and find out what has changed. (And a lot of changes in the STM32 line as well, but leaving that aside..)

Spartan-7 chips have come down in price! Dev boards have become available, at good prices! (you can roll your own board fairly easily these days, but FPGAs take a bit more support chips, and often require BGA soldering which is tricky for new folks!) Verilog and VHDL books are a litlte more available and cheaper! Old textbooks are coming on the 'used' market as well!

So, Spartan-7 is back on the menu, boys! (to borrow a quote from The Two Towers…)

Also of note - Spartan-7 is also an older architecture but much much newer than Spartan-6, and is supported on the newer and much nicer toolchain .. Xilinx Vivado! Vivado is another of those 'unreachable expensive' toolchains, but you can get it free for a specific subset of the chips. (Why do these hardware companies hit you for the software, when its only useful for their hardware? Give it away free, sell more hardware……)

So moving to Spartan-7 _now_ is certainly an option - they're about as cheap as the Spartan-6 were a couple years ago, the tools are far superior and supported!

And it gets better – what features do the Spartan-7s have over the -6? Glad you asked! Theres a tonne of new and slick stuff in there, but the one that jumps immediately out at me is the much higher internal block ram counts you can get, depending on the chip model. To wit, for the lower end models that free Vivado supports, are some with _a couple hundred KB of block ram_. If we're aiming for 320×200 8bpp we need 64KB per screen, and having a couple of those (for page flipping or sprite storage say), so we can easily use a couple hundred KB up. Fantastic! We can get a chip that costs $30 (still a lot, but at least affordable) that doesn't need external RAM to do what we need it to do. Still needs an external flash chip to load its configuration from, and still needs BGA soldering, but ehh.

Good enough to have some fun with!

The chip I went with not only has enough internal RAM to let me have a couple screen buffers, it has far more logic units to grunt what we need and then some. We could run a whole virtual CPU in the thing if we wanted to (and just like the STM32 we used for GPU before, it could run the entire sbc on it without anything else. But thats not the point.. we want 6502, z80, 6809, 68000 or other fun old CPUs to drive the whole thing!) So we could run the whole console/computer on the FPGA without a problem, thats not why wer're here.. we're here to be stupid, learn things, have fun, be stupid!

So with this Spartan-7 much nicer toolchain and hardware, I was able to figure out some basic HDMI 640×80 video modes; some helpful websites online suggest we could probably even manage to drive higher resolutions, but I'm totally happy with 640×480 for now. Given the size of ram and framebuffer we want to drive, 320×200 is plenty!

We can run a CPM machine or custom OS with rendering 8/16 bit style text or graphics and be very happy. Very happy indeed.

So, what are we doing here, now? What is the goal? One should always have goals…

Zikzak - the laptop, perhaps?

The zikzak rev3 sbc with a case was not a bad little piece of kit. But to keep propelling, it occurred to me a few years back that wouldn't it be fun to roll a whole laptop?

- designing a keyboard from scratch is hard but you know .. you can buy nice Cherry MX keyboard key switches for mechanical keyboards; its very easy to design a pcb to have a small mechanical keyboard on, and use knock-oiff Cherry switches if you like!

- designing an lcd panel? no, not going to try! But we can get a panel for cheap, and this is what I use for testing on my bench. The 5“ panel I have takes VGA or HDMI in…

- zikzak before did VGA; well, the new FPGA can drive HDMI now that I've coded that up, and it can drive VGA _at the same time_; no timing issues, it all runs in hardware!

- we already had everything else we needed - storage via cart or SD or serial or etc, processing, serial, even wifi via an ESP32 module

So the immediate goal is..

- design the 'video card' requirements and code up the Verilog to support that

- design a basic pcb for the FPGA as a test board; ie: a FPGA + flash chip, supporting caps, ISP / usb jtag programmer port, and breakout pins for the busses

- test the dev board and VGA/HDMI out

- given that, work on integration with zikzak .. a new 'sbc2' or rev4 board that is ez80 + fpga for video? built in HDMI and VGA ports so no shield is needed? or keep shield, to keep pricing down for manuf? we'll see..

- design keyboard pcb and find a cheap source of 100-200 Cherry MX switches or knockoffs..

- once all thats going, design a crappy physicl case to house it all, to make a ghetto laptop; or maybe go steampunk with a nice wood box with lions feet brass corners?

What requirements do I forsee for the video system on the FPGA?

Well, from zikzak earlier I had a number of video modes that were all useful and fun..

- pure text mode - for simple 'get up and go' software from the eZ80 side; maybe an 8×8 font for big readable characters 40 across, and a small font like 4-5 pixels wide so we can get 80 character wide display? Great for text adventures, coding, or running CP/M in, etc

- pure bitmap mode - slow to render from a slow cpu, but we could offer some special abilities in the FPGA, such as 'blit' for copying regions around or filling an area, etc; still, good for rendering nice picture scenes or slow but detailed updates or plotting

- hybrid tile + sprite mode - tilemaps for the background layer, with a foreground sprite layer? Allow the cpu to upload small tiles and sprites, and then be able to do very fast grpaphic operations by updating the tile map or sprite location table, without sending the graphics every frame. Your common gaming coding mode, for high speed but nice graphics! Also support basic effects like tile-offsets for scrolling backgrounds and such?

So lots of Verilog FPGA coding and testing to do, but all very fun things.

Project is slow moving at times, but very much alive.

Thanks for reading!

2020/01/18 01:42 · Jeff Mitchell · 0 Comments

Is Zikzak project alive? Yes! Enter, the FPGA..

A couple of years have gone by since I've updated this developer blog; wherever do the years go? (well, I have small kids.. the years go fast!) So for awhile, real life did get the better of me, and I admit when I did get small tidbits of time I went to some low hanging yet very interesting fruits .. fiddling a bit with simple human shaped robots. Designed a simple chest, arm and leg robot, where definition of robot is.. chest had a couple of mini servos to make the arms and leg first segments move, while arms (and legs which were a variant of arm) had mini servos so they could bend in the middle. The arms were enough to be able to pick up small things when used as tongs, and the legs could stand it up and let it twist the hips or bend forward and back a bit. I stalled at getting walkingh and such to work, as that requires quite some kinetics and human bone structuring to work, and who has the time? …

Anyway, back to Zikzak, which was always about learning how to construct a computer from scratch, with varying degrees of scratch. (Does one go so far as to design their own cpu? their own LCD panel? where do you stop?); with zikzak sbc rev3 I got pretty happy with the results - it had the Z80 (eZ80) cpu, the ARM chip that pretended to be a GPU (to emit VGA), as well as being live programmable so it could take over other tasks, or even drive the clock on the eZ80, so the ARM could be used as a z80 debugger or to slow and speed the chip.. insane! We had a working cartridge port, and enough GPIO lines if we wanted to 'cheat' on the retro styled design and have SD cards or other peripherals. And it worked, more or less.

Video was a little wiggly, and the limits of having a high speed ARM chip triggering on interrupts while also working a lot of data on the bus via GPIO was showing limits. And writing it all in C rather than assembly, to keep life easier on the limited free time. The image was fairly sharp (see videos on youtube) but if you looked closely, especially under higher load operations, you could see some small wiggle .. the timing per pixel or per edge could get a little off and you'd see that in the video. Its amazing how well you can pick up the smallest timing misfire!

At the time I often considered FPGAs, but that technology stack seemed a bridge too far .. while learning a fair amount of the basics, but at least being a very good software developer, meant I could at least focus on those digital electronics basics. But FPGA, thats an entirely different kind of development - going to Verilog or VHDL, and essentially designing your own chips.

A year or two back I did pick up some basic FPGA stuff and experiment; I got into the Xilinx Spartan-6 line, because in general FPGAs were very expensive, with expensive toolchains, expensive dev boards, expensive programmers .. especially if you went with the branded stuff. But for Spartan-6 you suddenly were able to get some pretty inexpensive boards on ebay or Aliexpress, and knock-off ISP programmers and so on. FPGAs are where you essentially upload a chip design into _another_ chip, and when the FPGA powers on it pulls the config from that other location and starts running it a moment later. So not only do you need the FPGA, you need a flash chip or another micro or something to feed it, plus the supporting hardware for development. Yet with these little beay boards, you could get a low end Spartan-6 class dev board for $50-$150 depending what else you wanted on there (lcd? switches? GPIO pins? VGA outputs? etc). Nice!

The Spartan-6 platform, while extraordinarily flexible, is also fairly dated.. hence why the cost of the chips has gone down, and for some subset of those chips Xilinx will give away the old toolchain for free. But that toolchain (“ISE”) is pretty old and it shows, and is even relatively hard to install .. the typical runtime nowadays is a VM image that you can download and run in Virtualbox (say); and then you're runnin ginto client Linux to host Linux/Windows issues with USB, but it does work pretty well.

Documentation is intimidating and spread wide for Spartan-6 (15 or so PDFs if memory is right) but you can get sdtarted with some examples and walkthroughs pretty quick; the toolchain is deep and intimidating. The languages you generalyl use (Verilog or VHDL or both, depending on your preferences) are also not well documented out in the wild .. many books are very expensive textbooks or vendor books. Again, this is changing _fast_ .. 10 years ago, very expoensive and hard to find books and boards.. 2-3 years aog, boards showing up, books somewhat available but still not very present. And the Spartan-6 chips I could afford and that worked with toolchains (such as XC6SLX9 say) weren't super powerful .. a fair number of logic units to 'compile to', but not much block ram or the like internally on the die; you really needed offboard RAM modules and peripherals, which complicated the design .. especially for beginners.

That all said, its amazing how much work you can get done in an FPGA with very little code, once you get your head around it. ie: Some kinds of tasks ar super well suited to traditional processors or micros, but brutal to implement in an FPGA; other tasks are the reverse.. translate super cleanly to FPGA but a tonne of effort to get right in the traditional world. VGA is one of these tasks – it really only takes a couple pages of 'code' to express a VGA output (sync, display a colour), with crisp perfect timings. Amazing!

So, I did get a simple very basic 'video card' working in Spartan-6… and then timed passed, and real life hit again. Next up, Spartan-7…

2020/01/18 01:21 · Jeff Mitchell · 0 Comments

Shield actual board

The ZikShield r1 (that fits on Zikzak rev3) has arrived! As mentioned before, this is just a quick board . a 'debug' board as a babystep forward, to verify some of the newer circuits blend in okay (the audio amp, FTDI usb/serial handler, etc), and that all the physical jack schematics/connectors are designed and measured properly. As you can see in the image, I've only just received the pcbs and barely populated one, but its working a treat so far.

As of today, I've populated the shield with: - USB (for power, and serial I/O) - VGA display - PS/2 keyboard connector - joystick0

These are all working great .. can tap away on the keyboard and see the text echoed to the display.

Note that all of this stuff works on the Zikzak base pcb, but that's just pinheaders. What we're adding now, is the 'breakout board' that offers real jacks, not just pinheaders. (The original goal for ZZr3 was to put it into a case, and jumper from the pinheaders to jacks; this allowed me to iterate on the Zikzak base pcb design, without blocking myself picking, order, waiting for and drafting up all the parts… just get on with the good parts!) .. but turns out using jumpers to parts and mounting the jacks on a 3d printed case proves too fragile, and you still have a pile of little jumper wires around to manage, which just gets annoying.

So Zikshield r1 aims at being a debug/testing level board, but also with the goal of making ZZr3 into a standalone machine; you plug in a power source (such as USB), a video cable if you like, a joystick or keyboard if you like, and you're good to go.

In addition to all the already proven stuff, it also adds some items I'd thought about but never got around to before, such as SD slot (actually micro-SD), and another USB (OTG) port. Also included is the audio amp with volume knob and so on.

But for today, only populated a few parts on the shield; as time permits, I'll fill up the rest and build some test code to validate it. Also working on designing a simple case to 3dprint, and working on a little demo game cartridge so theres something to show.

….. and then the big decision of whether to design a Zikzak base pcb rev4, that does it all in one big board?

2016/05/27 00:51 · Jeff Mitchell · 3 Comments

Shield part placement

More brain-dump detail in the forum post on here but suffice to say .. progress is coming well on the shield approach, where the shield is a second board that could be stood on on top of the zikzak rev3 pcb. Decisions (about power supply) have been made and going to go with the general approach that USB power is the way to go, but still supporting power by barrel jack and pinheaders and various combinations thereof; going to go with USB for power, and optional z80 serial over that USB via FTDI chip, with a second USB jack to be supported (calling it 'data usb') hooked up to the USB controller on the GPU. This should let us do crazy stuff like have the z80 tell the gpu to go into USB mass storage mode or other crazyness, if we ever get the time to hack out the code for it :) Schematic has most of the parts on it, and half wired up, and the PCB is getting the placement about half right… so I think I know where the VGA jack will fit in, and where the joystick and keyboard and USB jacks will go.

The image to the left is very WIP (work in progress); its already changed since the picture an hour or two ago, but just to show you where the pads are that bridge down to the ZZ rev3 main pcb, and the difficulty in layout out the jacks. And theres more jacks on there now…

Its made complicated by the fact that the ZZ r3 pcb was meant to go into a 3d printed case itself, with jacks affixed to the case, and those jacks connected to the pcb via jumper wires. Turns out putting jacks (with their mechanical stress during plug/unplug cycles) is hard on the printed plastic, and all those jumper wires just get fiddly after awhile. At anyrate, ZZ r3 pcb was designed for this, so the pin headers are all around the periphery. When you're planning to now put another board on top (or below) this pcb, it in turn would really like the real physical jacks to be around its periphery.. but cannot, since those positions are going to be the pinheaders that bridge down to the ZZ r3 board. In a more ideal world if the intention is for another second board to be the port expander, you put all the pin headers in central elevator-shaft like organization, all in the middle or in convenient location, and then spread out the connectors on the other board. Live and learn :)

My mode of operation tends to be .. given real life is very busy, and I can't bite off too large a piece lest nothing ever get done, to bite off smaller pieces and place one foot in front of the next, with regular achievable milestones. So current goal is to design the shield pcb that goes onto rev 3; rev3 is a real working Zikzak pcb on my bench, now; to make a shield means drawing up all the CAD libary pieces for the jacks and new components (a lot of fiddly work), and the new circuitry for the USB and audio amp and so forth. Some of this has been proven in other little projects or on breadboards, but its a whole other story putting it into a schematic and hooking it all up, and having the schematic pins map to the correct real world pads, and so forth. So, getting a shield laid out, and have the boards made, affords some experience.. it get you to lay pieces out, and you'll prove they work or not. Best case, it all works; next best is it mostly works, and you can work around some minor flaws, but have saved yourself from screwing up on a rev4 very expensive and time consuming board. Or worst case is a glaring flaw you find in shield rev1 and have to make a rev2 of that.. but better to do that, and minimize overall cost (parts and time lost).

So making a shield for rev3 is still the right way to go, as a step to Zikzak rev4 if we go that way (where ZZr4 would be another all in one board like r3, but with the jacks right on board if we can fit it; alternatively, r4 could be a large single board, much like r3, but with all the headers done centrally in some fashion designed for actual second board expansion, and with a few minor corrections.)

So, we prove the shield design, as a revision or two; it'll be fun, and make some fun experiments for ZZ r3 possible. Once thats proven, can decide if going for a ZZ r4 and if its a single or double board solution. Either way, while r4 is in the pipe, can be working on a 3d printed case design for r3, and enjoying r3 more.

Zikzak rev3 will be much more fun, with jacks and the amp and power and all that on one board. As is now, it rather depends on hooking up external power regulation pcb or using a big power supply, and a FTDI external board to do serial communication to host PC, and fiddly external PS/2 keyboard connector and fiddly VGA connector, and a few other connections; which is fine on the bench, but not really convenient to go show someone else at work or on an upstairs TV etc. To make the shield, and put a simple printed case around it, would make it an actual console, plug and play; jack in the USB power, a joystick, and VGA to TV and good to go! Or a keyboard, and cart, and so on…

So, shield for rev3 is coming along very nicely. Then decide what ZZ rev4 will be…

2016/05/14 04:05 · Jeff Mitchell · 0 Comments
/home/skeezix/public_html/zikzak.ca/zikzak.ca/dokuwiki/__data/pages/devblog.txt · Last modified: 2017/11/11 02:58 (external edit)