Now that I have two expansion boards working successfully with Y Ddraig, a sound board based on the Yamaha YM2151 and a video board based on the Yamaha V9958 VDP, I’ve been considering the next step to take.
While the V9958 board seems to be working successfully in the limited amount of testing that has been performed so far, it still has the limitation of low resolutions and only capable of generating PAL or NTSC composite or RGB TV signal. There is the V9990 which does have a VGA mode, but it’s not supported for all modes and has mostly the same issues as the V9958.
The requirements I was looking for in a video solution was to have some higher resolution video modes for text and some lower resolution modes that can be used for games. With this in mind I did not find anything that fit my requirements. I was, in essence, looking for slightly updated version of the V9958 or V9990 that has VGA output so it can work with modern monitors.
These discussions lead me down the route of deciding to implement my own Video card using a Spartan-6 FPGA. Lawrence is working on a similar solution for his MAXI000. While we are using different FPGAs and have some slightly different goals in mind, we are looking at ways to share what we are working one between our designs to minimise duplication on some of the work.
The design I’m going with is based on the Spartan XC6SLX9 which is available in a QFP part. A few extra pins on the device would have been nicer but was a trade-off between using a BGA part and something that can be easily soldered by hand.
The plan is to have a VDP that works in a similar manner to how the V9958 works. Most of the control of the video will be done through control registers and will allow setting of the screen mode, palette data and some hardware accelerated drawing functions. The board will also allow direct access to the Video RAM by the CPU so that data in RAM can be updated quicker than pushing everything through the registers. Limitations in both the expansion bus and the available pins on the FPGA mean that RAM access with the CPU will have to be banked.
- The board has 2 Megabytes of SRAM available which will be used as the Video RAM.
- The VGA output has 4-bits per colour available giving a total of 4096 colours.
- The video resolution is going to be a “high-res” 640x480 mode and a “game” resolution of 320x240 which will be scaled internally to 640x480.
As far as firm specifications go that is, more or less, all that has been decided. From this point on the feature list are planned features and could change as development progresses. I want to be able to handle bitmap modes, pattern (tilemap) modes and text modes.
|Bitmap||640x480||4096||12||4095 direct colour mode|
|Bitmap||640x480||256||3-3-2||256 direct colour mode|
|Bitmap||640x480||256||8||256 colour palette mode|
|Bitmap||640x480||16||4||16 colour palette mode|
|Bitmap||320x240||4096||12||4095 direct colour mode|
|Bitmap||320x240||256||3-3-2||256 direct colour mode|
|Bitmap||320x240||256||8||256 colour palette mode|
|Bitmap||320x240||16||4||16 colour palette mode|
|Pattern||640x480||256||8||256 colour palette mode|
|Pattern||640x480||16||4||16 colour palette mode|
|Pattern||320x240||256||8||256 colour palette mode|
|Pattern||320x240||16||4||16 colour palette mode|
|Text||640x480||256||8||256 colour palette mode|
|Text||640x480||16||4||16 colour palette mode|
For all modes, maybe with the possible exception of text-based modes, I’m planning to have double buffering and allowed buffer sizes larger than the display area with hardware vertical and horizontal scrolling.
I would like to implement at least 1 hardware sprite in high-res mode but have more available in the game modes which again may only be in the game modes. It would be a nice option to have sprites with an independent palette to the display ,mode. Many of these features will depend on performance and my ability to implement the features so this list may change.
While my initial goal is just to be able to write a pixel from the CPU and have it displayed on the VGA output, there are some interesting ideas that could be experimented with once everything is up and running. Some of these could be along the lines of per-line palette changes, dual playfields and bit plane mode as on the Amiga.
Expansion Bus Changes
Something that I’ve been considering during the design of the video card is how the expansion bus is currently used.
There is currently an ID and DATA range for each expansion slot. The ID range is 256 bytes wide and the DATA range is 1 Megabyte. The main board has no restrictions on how this is used but on the expansion boards I’ve got currently the ID line is tied to the enable pin of an 74LS541 with a hard coded address to identify the board. When the CPU reads from anywhere in the entire 256 byte range, the ID is placed on the databus. The registers on the YM2151 and the V9958 are currently accessed from within the data range.
The plan moving forward is to change the ID range to be used as the register access and the board ID will be read from the FE-FF address. All other reads/writes to this memory range will be mapped to the device registers on the boards. For the existing sound and video boards this will require some changes to the design which I’ve already done. I could have probably modified the boards by hand but took the lazy route of getting new boards ordered.
On the FPGA card, the register access and the Data access will be separated between the two ranges. The DATA range will be for access to the SRAM. On the existing boards this data area will now be left unused. The bus design was always done as a proof of concept in the initial version, so changes were expected. I think going forward this will provide the most flexible solution.
New boards have been ordered and should be with me any day now. The next step will to be get the FPGA video board up and running with some basic VGA output before moving on to being able to write data from the CPU and display it on the VGA output. Updates will be coming soon…