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.
We found and based on your interests.
falvotechdatabook.pdfEarly 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 |
|
|
Besides working my buns off at my day-job, I've been slowly making progress on a font editor application for the VDC-II core. And, by slowly, I literally mean spending about two hours every month or so on it. Still, progress is being made, and I'd like to toot my own horn for a moment.
The screenshot below is a current image of what the program looks like. As indicated before, this program is written for the Z80 processor, and runs under CP/M 2.2 or compatible operating system. Right now, this software is optimized for the Commodore 128 and its VDC chip; however, it is quite easy to adjust it to run on the RC2014 with a VDC-II card.
As you can see, its user interface and overall functionality is coming along quite nicely.
As I type this, there are still some bugs to be worked out. While editing the fat-bits view of a character, the display gets corrupted for some reason. I'm still trying to work out why this is. However, it does not crash the software, and it legitimately does update the correct glyph bits, which you can confirm by dismissing the Glyph Editor and re-opening it.
Also missing is the ability to load or save data from/to a file. This will be coming soon enough. I'd like to get the basic program functionality working first.
Anyway, just a reminder that I'm not dismissing this project; my professional obligations have been taking more than a fair amount of my bandwidth. I can't wait to be able to run this software on real hardware though!!
What happened?
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.
I think.
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.
Create an account to leave a comment. Already have an account? Log In.
Become a member to follow this project and never miss any updates
Coming along nice, I'm eyeballing it thinking it would be a "known" display for playing in CP/M with for any progs that targeted 128s CP/M mode. Not that I'll have a full 128 for that, just some as yet undetermined z80 board. Thinking of growing it from Roy Searle's minimalist version.