Commodore 8568-inspired (and mostly compatible) video core for driving VGA-type displays.
To make the experience fit your profile, pick a username and tell us what interests you.
Early preview of VDC-II documentation for internal registers. Very alpha!! Do not rely on this for information for production-grade software.
Adobe Portable Document Format - 190.28 kB - 02/07/2021 at 02:45
Well, I got a full-time job for a major manufacturer of mass media storage, so that's been occupying most of my time.
Finally heard from Crowd Supply about a month ago that they're still waiting for parts to complete my order for TinyFPGA BX modules. Who knew the semiconductor shortage would take out the BX-Plorer project?
Still, I've not had two seconds to rub together to hack on the VDC-II HDL code. Which sucks, because I am itching to make some progress with it. I desperately want to finish it by end of this year, so I can move on to other things.
But, now that I'm starting to get into a routine at my day-gig job, I'm hoping to re-allocate some weekend time to get back to work on the Font Editor code for the VDC(-II), and subsequently to that, to actually finish the VDC-II itself. I would love to be able to get CP/M running natively on it using my RC2014.
Adulting is hard. Avoid becoming an adult if you can.
I ordered some VGA PMod adapters from Digilent last week, and I'm happy to say that they fit perfectly. The mechanical connection is very solid, far better than any card edge connector I've used. Near as I can tell, the electrical connection also seems to be good as well.
I haven't had the chance to reprogram the FPGA design to use this particular adapter yet. I will update with my results upon completing that.
The only thing which sticks out to me, besides the height of the connector, is ... the height of the connector. And, its orientation. But, if you can strain-relief the monitor's cable appropriately, it should not pose a problem for the BX-Plorer.
(Aside: my experience with how well this PMod fits into the sockets on the BX-Plorer has convinced me that the right way forward for the Kestrel-3's backplane should be 2x40-pin RC80-compatible connectors.)
Now that I have what I believe to be a functioning prototype of the BX-Plorer design, I have reached out to Crowd Supply to see if they think this project is worthy of crowd-funding and selling through their website. So far, after about a week of waiting, I have not heard anything back from them. Their website does not provide any indication of how long I should have to wait for an answer. I've opened a support ticket with C/S as well, but again, no response. If C/S doesn't respond within another week or so, I shall start looking into selling my kits elsewhere.
In the mean time, I have placed an order for three Digilent PMod VGA adapters. (Three, because these things are easy to lose!) Although these adapters support 4 bits per gun (and, thus, support 4096 colors maximum), I can only use 3 at the moment because of my previous wiring mistake. Still, it should work for the purposes of demonstration.
Another thing I'd really love to hear back from C/S about is my outstanding order for five more TinyFPGA BX modules. Back in December, they said that they expect a new shipping date some time in January. I sure hope they haven't forgotten about me. I'll give them until February before I contact them again about my order.
While waiting for all this stuff to work itself out, I've been making progress on the font editor demo. Here's the latest screenshot (taken off a Commodore 128 emulator), and is a good representation of what it should look like on an RC2014 with a VDC-II card as well. I still need to write the code to render all the characters inside the table cells, to scroll the glyph palette table up and down as appropriate (to allow selecting any of the 512 supported characters), and of course, the actual editor interface as well. Still, progress is progress.
Just before Christmas, I received the three prototype boards for revision 6A from OSH. The boards look great, but I wasn't able to construct one until yesterday evening.
Assembly went ... not quite as smoothly as I'd've liked for the first board I tried. It was a bit colder in the garage than I'd've liked, but the solder hated it more than I did. While attempting to drag-solder the 74LVC8T245PWR chips onto the board, no matter how much solder I used to flood the pins, it refused to make a clean solder joint. Wicking the solder just wasn't working well, so I tried to apply a bit more pressure. While that worked to get the solder hot enough to wick, it also bent the pins of the chips, and ... yeah. Lesson learned: do not drag-solder when your workspace is cold.
(note the red lines showing where the pins got crushed together.)
After refining my technique to use tack-soldering instead, and making sure to wick excess solder pulling away from the chip instead of trying to sop all the excess in one fell swoop by dragging the wick across the pins, construction went relatively smoothly. I completed the build of the 2nd prototype card in about six hours.
After fitting a TinyFPGA BX module to the card, I was able to use it as a proper VDC-II card by routing wires over to a breadboard with a resistive DAC on it.
I ran the old clock demo I'd written some time ago, and it runs perfectly. (A more advanced demonstration which puts the VDC-II into bitmapped graphics mode is still under development as I write this.)
Next steps include:
I have been thinking about how to reliably solder the surface-mount pin headers to the TinyFPGA BX module for some time now. I think I've come across a solution.
Here's a picture of a mock-up which demonstrates what the arrangement should look like after step 4, but before the completion of step 5.
It has occurred to me that my plans to complete VDC-Forth are essentially kaput; it is a user interface model for a Forth that I'd hoped would give me some unique insights and inspirations, and instead I have essentially coded myself into a corner with it. While I do intend on playing more with the code in the future, it's not clear to me that it will remain my "go-to" piece of software I can point someone to and say, "Look, here's code that works directly with the VDC-II core you can study."
One thing that I will need in the future, though, is a font editor for this module. So, I figured, why not write a font editor for it, using it? And, so, that's what I'm doing.
It's written to use 640x200 bitmapped mode, monochrome. I chose this because had I used text-mode, I couldn't easily alter the font heights. Remember that the VDC chip supports fonts as small as 1 pixel tall and as tall as 32 pixels. Since vertical sync timing is dependent on this height, every time I'd need to alter the font height, I'd need to recompute (dynamically) the CRTC settings. With this comes the risk of user-visible loss of monitor sync, which is annoying to say the least.
So, bitmapped mode it is. So far, I've implemented code to draw horizontal lines and draw filled rectangles using patterns. Although their APIs are quite primitive and low-level, they work.
Just ... not very fast. I predict the issue is caused by needing to read from and write to the VDC for every byte transferred. I could probably double performance by only read-modify-writing the left- and right-hand edges of the rectangles, and just blindly writing the interior bytes.
Even so, this software isn't intended to win any races, and certainly not to race the beam in any way. So, correctness is the most important aspect of the code. I might spend some time to optimize the code a bit, but I won't spend too much time on it.
Now that I can draw nice rectangles and horizontal lines, the obvious next step is vertical lines and, after that, text. Once that's done, I'll have the ability to render the complete user interface for the font editor. From there, actually implementing the editor proper should be relatively simple.
So, why did I make such an egregious error when designing revision 5B boards?
Because the TinyFPGA BX project has (or, at least at one time, had) poor revision control and misleading or missing documentation.
When I was building revision 5B, I was working off of this photograph, which is one of the only documented listings of the I/O pins accessible on the underside of the TinyFPGA BX module. (If you can find an official description of those connectors on the https://tinyfpga.com website, please send me the link!) Observe the bottom "belly connector" (what do you call those things anyway?) is a 2x7 surface mount connector, which lines up with what I've built the 5B to work with.
However, if you look at the current OSH Park PCB artwork, you'll see that there's a 2x8 surface mount connector in its place. This matches up with the actual hardware I tried using to build the latest prototypes with. As far as I can tell, it looks like the exact same pin-out as the 2x7 connection, but with an extra pair of ground pins.
Of course, looking at the schematic, I see that it describes the 2x8 connector; but, considering the Crowd Supply updates are newer than the schematic up on Github and showed the 2x7 connector, I didn't put much stock in trusting it.
Turns out, Crowd Supply's information is outdated. And, strangely, I can't even find reference to the 2x7 connector in Github's history, suggesting that the CS campaign started before the Github repo even existed.
So, yeah, I learned a lesson on this one: never trust the updates on Crowd Supply. Even if newer than repository documents, they may not reflect current reality.
OK, back to hacking on the next PCB revision.
Rev 5B boards have a critical design failure. The "belly connectors" of the TinyFPGA BX module has two parts: one is a 2x3 surface mount pin header, and the other is a 2x8 surface-mount pin header. You can use a 2x7 pin header for that connector; but it must be offset by 100mil in order to work.
Problem is, if you look at the PCB artwork, you'll see that the 2x8 belly connector has only 14 pins. And, it's not offset. Which means that the whole design is junk.
There are no work-arounds for this. I need to spin a new batch of PCBs with a proper 2x8 belly connector. Sigh.
Upon inspection of the rest of the PCBs, though, everything else looks nice. I'm particularly pleased with the host Pmod connector alignment. So, there is that, at least.
Dammit, I really am getting impatient with this project, though. I'm spending too much time waiting and burning through way too much cash.
I'm happy to report that I've completed work on yet another revision of the BX-Plorer PCB, and this one even includes a logo and more prominently placed revision and release date. Yay for professionalism!
Even more than that, I've managed to source the proper connectors to support honest to goodness Digilent-compatible Pmod host ports! This allows a wide variety of pre-existing Pmod-compatible attachments to be used with your RC2014.
Test cards have been ordered from OSH Park. They should arrive in a few weeks. I still need to place the orders for the rest of the components though. I should be doing that later this-coming week.
As this project evolves, I'm noticing a distinct yet synergistic compartmentalization in the roles and responsibilities of different project components. When I started this VDC-II project, I'd just been convinced by interested members of the community of the value of developing Kestrel-3 computer parts for the RC2014 backplane. I later observed that my RC2014 Zed's flash BIOS image could be built with Commodore VDC support, and after reading up on that chip's technical specs, I realized that it was a fairly close match to what I'd wanted to achieve with my own CGIA concept. So, rather than re-inventing the video support with the CGIA, I figured I'd just piggy-back what was already there, and decided to reimplement the VDC. This benefits both RC2014 and Kestrel-3 communities, since any Kestrel-specific enhancements I make to the design later on can benefit both communities, not just the one. So, I set out to just develop a (mostly but not completely compatible) clone of the Commodore 8563 VDC as used in the Commodore 128, using affordably priced, off the shelf FPGA development boards. That became the VDC-II project you're reading about now.
I've always intended to release this project as a kit of some kind, so that RC2014 owners can, in long-standing RC2014 community tradition, build their own video card. That means, as part of the kit, they'd receive the PCB, all the chips, a pre-programmed TinyFPGA BX module, and other miscellaneous parts needed to have a working video card.
However, I now realize that the very circuit I used to interface my TinyFPGA BX module to the RC2014 backplane is itself useful as a self-standing product in its own right. You could see a less developed realization of this, more or less explicitly, in previous log entries where I first mention breaking up the FPGA part of the circuit from a mezzanine card containing the analog VGA circuit.
Going forward, I've decided to formalize the separation of the FPGA project card from its applications. First, the FPGA project card now has an official name: BX-Plorer. It lets the consumer of the card explore FPGA designs using the TinyFPGA BX module.
Second, I've decided to factor the BX-Plorer out into a separate git repository. I'll update my Hackaday.io configuration accordingly shortly after making this post. This implies that, Coming Soon, there'll be a separate Git repository for the VDC-II design files and the software stack needed to drive it. I'll (re)post updated links in a separate log when everything is in place.
Related to the first two points above, for now, both BX-Plorer and VDC-II updates will happen in this Hackaday.io project. As I write this, I have no plans of factoring the two projects out here. These two projects have been co-developed from the get-go, and I don't see that changing any time soon.
Third, what of the VDC-II-based RC2014 "video card"? Is that now dead? As I'd originally conceived it, yes. With all the other video card projects that people are concurrently producing for the RC2014 (link 1, link 2, link 3), it's not clear to me how I can compete for mindshare. However, if there's enough feedback, I can see offering a BX-Plorer Cost Reduced/Fixed Function card as a dedicated video card. If this is something that is still desirable to readers, please do get in touch to let me know.
(Besides, you can always use a regular BX-Plorer with a pre-programmed TinyFPGA BX and analog VGA mezzanine still.)
Fourth, this does not affect the development of the VDC-II itself. I still need a video card, for both my RC2014 and for my own future homebrew computer design. The VDC-II project is not dead.
When, not if, you see these new terms being bandied about in my project updates, now you'll know why and where they come from. :) Until next time!
Become a member to follow this project and never miss any updates