I've completed the strip buffer implementation, the block memory arbiter, and the video fetch engine, and mated it with the MPE. This provides the host processor the ability to manipulate the display memory and we can finally observe the effects on the screen!
After setting the video mode to 80x30 text display, placing the text display at address 0000H and the attributes at 0C00H, you can run this little program in BASIC on the RC2014 to look at the first half of the VDC's character set (glyphs 0 through 255).
1000 OUT 110,18:OUT 111,0 1010 OUT 110,19:OUT 111,0 1020 OUT 110,31:FOR I=0 TO 2399:OUT 111,(I AND 255):NEXT I 1030 OUT 110,18:OUT 111,12 1040 OUT 110,19:OUT 111,0 1050 OUT 110,31:FOR I=0 TO 2399:OUT 111,(I AND 15):NEXT I
BASIC is slow enough that you don't need to worry about waiting for the MPE to finish stores into video memory; if you write this code in machine language, however, you'll need to remember to wait on the VDC. In any event, it should produce something resembling the following (if attributes are turned on).
If you turn off the attributes and set the foreground and background colors to bright green and dark grey, you'll get a display which kinda sorta looks like a Commodore PET (or the Commodore 128 when it boots in 40-column mode).
Bitmapped graphics mode works as well. If you ran the previous code above, then try executing the following listing, you should see high resolution "garbage" on the screen, complete with color attributes applied. NOTE: the TinyFPGA BX is only big enough to contain 16KB of video RAM, as that's all the block RAM it has available. Thus, the 640x480 VGA display is going to have several repeated slices showing the same data. That's normal and expected.
OUT 110,25:OUT 111,INP(111) OR 128
Since the TinyFPGA BX only supports 16KB of RAM, there's no way to fit attributes in with a full-screen bitmap image. So, you'd typically turn off attributes to have a proper monochrome display. However, the VDC-II doesn't yet support scan-doubling, so it renders the screen at full resolution whether you like it or not.
OUT 110,25:OUT 111,INP(111) AND &HBF OUT 110,26:OUT 111,&H51
Interesting how you can see where the screen data resides, where the attribute data resides, and where the character set resides in VDC memory. :)
So, now that I've demonstrated that I have a workable, usable display, I figured it was time to try and write something that is "useful", in the sense that it is representative of a typical program most would consider to be useful. I decided to work on a simple clock application, and you can find the latest source code to it in the repository.
Here's what it looks like when it first starts up.
To unpause the clock, you tap the P key on the RC2014 terminal. It will then start counting up, in roughly 1 second intervals. Kinda sorta like this:
While working with the code, I ran into two hardware bugs. One of which I knew about from earlier development; however, a new bug has manifested. The bugs are:
- If polling the status register too fast, it will corrupt subsequent MPE operations. I've additionally discovered that this will even manifest when not using block-copy or block-write mode. It can also show up as corrupted VDC registers as well; it's not restricted to affecting video memory.
- And the latest bug I discovered was that, for some reason, reading the data register does not automatically update the update pointer. Thankfully, writes to this register does not cause issues.
In no particular order:
- Well, I'd like to finish the development of the clock; there are a few added niceties I'd like to throw in.
- I need to finish designing the printed circuit board for the VDC-II RC2014 card.
- Implement missing features, like hardware cursor, row address increment support, underline attribute support, etc.
- Fix known hardware bugs.
Still a ways to go before I can declare this project "done"; however, it's now certified to be in a usable state, which is quite exciting!