Electron graphics card

[Ramtop]

Hi all,

I waffled a bit about this on twitter, so now I’ve got to stop being lazy and write a post with some actual detail. Since about the middle of last year I’ve been working on and off on a new piece of hardware for my Electrons. Due to an abundance of lockdown enforced spare time I’ve gotten it somewhat functional now, so I thought I’d say a bit about it.

Firstly, to be clear, this design still only in prototype form. It is mostly a proof of concept built for my own use, and isn’t intended to be an actual product. Elements of the design will probably show up in something commercial at some point in the future, though.

With that said, here’s a look at the imaginatively named ElkVGA.

attached to a VGA CRT:

As the name suggests it is primarily a graphics card. It’s based on an Altera/Intel Max 10 FPGA, plugs into the Electron’s expansion connector and in the current hardware revision has:

- A fast SD card interface using a custom SPI controller and MMFS driver
- 512K of SRAM
- 64K of sideways ROM flash storage
- an SPI port capable of running up to 25MHz
- and a 15-pin socket for a VGA monitor

The main thing is the VGA output, of course. It provides a display that appears similar to the normal RGB output but is suitable to be fed directly into a VGA monitor (technically it is 800x600 60Hz with the Elk video in a 640x512 central area).

The VGA output is entirely separate from the ULA, it snoops the 6502 bus for writes to the screen memory and display registers. A duplicate of the Electron’s screen is held in the FPGA’s block RAM and scaled to fit in the 640x512 display area on the VGA output. The scaling is purely integer so no fuzziness is introduced. All seven screen modes are supported.

An obvious enhancement to do is 16 real colours in mode 2, so that ability is provided. The colour palette is increased to 12-bit / 4096 colours (chosen because that’s what the VideoNuLA uses). Up to 32 sixteen-colour palettes can be defined and each line of the display can be allocated one of them, giving a maximum of 512 colours on-screen. After the initial setup no CPU intervention is needed for this to work.

Here's a slightly fuzzy picture of 16 real colours combined with a palette split in mode 2:

and a palette split used to change the control panel in Thrust:

Because of the 800x600 resolution there is a visible border around the screen area, which can be (presently) set to any of 64 colours. The blank scan lines in modes 3 and 6 take the colour of the border. There’s also a scan-line emulation mode which blanks alternate lines in the 640x512 screen area, this actually makes a VGA CRT look much more like a 15KHz screen than I expected. It can be toggled via a keyboard short-cut.

Border colour and mode 6 blank lines changed to red:

The latest thing I’ve added is a screen-mode lock, as way of forcing the CPU to 1MHz when displaying slow screen modes. Because the VGA output doesn’t depend on the ULA it’s possible to put the system into a slow screen mode, like mode 2, lock the VGA output to that mode, and then poke the ULA directly to put it into a fast mode. That results in the ElkVGA running in mode 2, but with the ULA driving the CPU at 1MHz. I’ve only played with this briefly, there may be hidden gremlins here, but it seems to work quite nicely so far and the extra speed is easily apparent.

The advantages of bolting a on a new video system are obvious, but there is a fairly sizeable drawback though: compatibility. The ElkVGA is using completely different timings from the ULA so any games that play timing tricks, like changing the palette or screen mode mid-frame, are not going to work well if at all. From the testing I’ve done actually about 80% of games play fine, the ones that don’t are mainly ones changing palette mid-frame to hide data in screen memory (games like Joe Blade and Barbarian for example).

I’ll post more details later, if anyone’s interested.

(sorry for not having much in the way of cool demo pictures, I haven’t written anything to show off the hardware other than the rather basic mode 2 colour blocks thingy)

[egel]

Looks very nice, but why VGA and not HDMI? You probably have a good reason for it, but which?

[Ramtop]

Multiple reasons. For retro machines I think CRTs are impossible to beat as a display, but 15Khz RGB CRTs are getting rare now. Good quality VGA CRTs are still common, though, and all the CRTs I have personally are VGAs. So VGA output made sense. And almost all LCD screens still have a VGA input anyway.

There's a chance the VGA core of the ElkVGA will find its way into a commercial product, which rules out HDMI because I would have to pay the ridiculous licensing fees the HDMI association charges.

[davidb]

Looks good! Some of us have been discussing this kind of enhancement for a while, so it's good to see someone experimenting with a solution.

One enhancement that would be interesting is to define a palette for each scanline in the page just below the screen start. I used two pages of memory for my palette experiments, though maybe you wouldn't want to reuse the ULA's palette formats.

Anyway, keep it up! This looks like fun.

[0xC0DE]

As commented on Twitter, I am following this with great interest and hope one day it will find its way into a commercial product! Well done!

[davidb]

The latest thing I’ve added is a screen-mode lock, as way of forcing the CPU to 1MHz when displaying slow screen modes. Because the VGA output doesn’t depend on the ULA it’s possible to put the system into a slow screen mode, like mode 2, lock the VGA output to that mode, and then poke the ULA directly to put it into a fast mode. That results in the ElkVGA running in mode 2, but with the ULA driving the CPU at 1MHz. I’ve only played with this briefly, there may be hidden gremlins here, but it seems to work quite nicely so far and the extra speed is easily apparent.

You could try some BBC Micro games that run slowly on the Electron to see if they run closer to original speed. Some of the early Superior games, like Wallaby, for example.

[jgharston]

If you post the hardware I/O details to control the deep palette, it would be a useful addition to the PCHANGE palette selector program.

[Ramtop]

One enhancement that would be interesting is to define a palette for each scanline in the page just below the screen start. I used two pages of memory for my palette experiments, though maybe you wouldn't want to reuse the ULA's palette formats.

The big limitation I have to deal with is that VGA output requires constant access to palette information, and the electron has no DMA ability so the FPGA can't fetch data from main memory at will, all it can do is monitor accesses made by the 6502. The only real way I could see of storing palette data in the elk's memory would be to snoop the initial write of the data and keep a copy in block RAM for the VGA output to access. Which does seem a little like pointless duplication!

I did play with the idea of having a pseudo sideways-RAM bank dedicated to palette data, but that's difficult to manipulate from BASIC. May still do it in the future.

At present all palette and assignment data is stored in FPGA block RAM, accessed via five registers. Definitions for individual colours are done similarly to the VideoNuLA, first byte is [index:R] second is [G:B]. But I use two separate registers, rather than the VideoNuLA's double-write. Registers 3 and 4 are the palette split regs, the first takes a scan line number (0-255) and the second the palette number (0-31) to be used on that line. Final register selects the palette to be modified by the colour definition registers.

If you post the hardware I/O details to control the deep palette, it would be a useful addition to the PCHANGE palette selector program.

I'll post the details as soon as I stop messing about with stuff!

At present I'm not even sure the 12-bit palette will be retained in the next revision of the board. The similarity with the VideoNuLA is valuable, but I still think 12-bit is overkill and 8-bit would probably be fine and would free up some valuable I/O pins and block RAM.

[Ramtop]

I spent the morning porting over some of the images from the Bitshifter's VideoNuLA slideshow disk, which look pleasingly colourful.

[davidb]

The big limitation I have to deal with is that VGA output requires constant access to palette information, and the electron has no DMA ability so the FPGA can't fetch data from main memory at will, all it can do is monitor accesses made by the 6502. The only real way I could see of storing palette data in the elk's memory would be to snoop the initial write of the data and keep a copy in block RAM for the VGA output to access. Which does seem a little like pointless duplication!

That's what I thought you might have to do.

I did play with the idea of having a pseudo sideways-RAM bank dedicated to palette data, but that's difficult to manipulate from BASIC. May still do it in the future.

Well, if you provided palette registers somewhere up above &8000, probably above &FC00, then software could be written to manipulate these on each scanline, so it's not something the hardware would need to take care of.

Some other thoughts:

• Would it be possible to add MODE 7 support, perhaps by reimplementing the teletext display hardware of the BBC Micro in FPGA logic? This would require additional software support, of course.
• Could this be used to implement more fine-grained scrolling?
• Have you thought about implementing enhancements to the sound system, or providing other "virtual" peripherals?

I'm sure you have your own list of additions and improvements.

[Arcadian]

Goodness, what a wonderful project - count me in for one if they become available please!

Could you feature both VGA and HDMI outputs?

Btw, would you be up for popping into this Saturday's "Virtual" ABug conference on Zoom to give a demo and overview of how it works?
viewtopic.php?f=25&t=19156

[Ramtop]

Well, if you provided palette registers somewhere up above &8000, probably above &FC00, then software could be written to manipulate these on each scanline, so it's not something the hardware would need to take care of.

The current palette registers are located at &FCxx, so they can be fairly easily accessed. Nothing to stop manual CPU-driven palette swaps either, but the hardware does that so much better.

On the other things, I suppose I should clarify what possible features are likely to happen.

- Mode 7; unlikely, but I'm not ruling it out. Need to experiment a bit and see how much time it would take to implement.
- Hardware scrolling, quite possible. It's not hard to do.
- Sprites. Again, not hard to do but quite hungry for block RAM. They do also seem a bit 'un-Acorn' to me, I'm very keen for the ElkVGA to feel like an electron but as it would have been if the ULA wasn't so limited.
- Audio. I'd love to do this, but haven't even looked at it yet. An off the shelf audio CODEC on the SPI port sounds like a quick way to do it.
- Joystick port; likely if I can free up enough I/Os for it.
- Advanced screen modes; if I forget about things like sprites then there should be enough block RAM to do some kind of extended screen modes. Not sure of what form these would take, though.

The big problem is always lack of block RAM. The FPGA I'm using (Intel 10M08) only has 42K of it and costs £25 a pop. Bigger variants have more, but the cost escalates into silly money very quickly and they have a different pin-out so a board re-design would be necessary (thanks Intel! )

Could you feature both VGA and HDMI outputs?

Btw, would you be up for popping into this Saturday's "Virtual" ABug conference on Zoom to give a demo and overview of how it works?
viewtopic.php?f=25&t=19156

No go for HDMI, I'm afraid. The legal issues surrounding use of that standard are unpleasant. Put me down as a 'possible' for ABug, please. I'm scheduled for remote work stuff on Saturday, but that may still not happen. Either way, I'll try and post a video showing the ElkVGA and some no doubt scintillating commentary

[jgharston]

Well, if you provided palette registers somewhere up above &8000, probably above &FC00, then software could be written to manipulate these on each scanline, so it's not something the hardware would need to take care of.

Is your hardware able to "see" &FExx? If so, the simplest thing to do is replicate the vNuLA registers, ignoring low colour bits that you don't implement. If not, then best to replicate pre-existing registers in the &FCxx space.

[egel]

There's a chance the VGA core of the ElkVGA will find its way into a commercial product, which rules out HDMI because I would have to pay the ridiculous licensing fees the HDMI association charges.

Comes DVI also with ridiculous licensing fees? DVI-I would make it compatible with both VGA and HDMI. The market would probably be larger if it could also directly provide digital signal.

[Arcadian]

No go for HDMI, I'm afraid. The legal issues surrounding use of that standard are unpleasant. Put me down as a 'possible' for ABug, please. I'm scheduled for remote work stuff on Saturday, but that may still not happen. Either way, I'll try and post a video showing the ElkVGA and some no doubt scintillating commentary

Ah I see, ok no prob - I'm fine with VGA personally - have still got a few old Acorn CRTs with VGA.

Regarding the Zoom meeting on Sat, do you want to pop your name in the thread as a maybe, then sydney (Simon) will PM you the meeting logins once they're confirmed. viewtopic.php?f=25&t=19156

[Ramtop]

Comes DVI also with ridiculous licensing fees? DVI-I would make it compatible with both VGA and HDMI. The market would probably be larger if it could also directly provide digital signal.

DVI is free to use as I understand it. But there are two issues; generating both analogue and digital outputs at the same time add a major amount of complexity that I'm not sure I want to deal with. And second, there are no free I/O pins on the FPGA. I couldn't add DVI without removing VGA, and even then I'm not sure there would be enough pins.

[uniforix]

mind blown again, ramtop keeps on giving.

definitely be down for one of these if you get to selling!

keep up the awesome work

[Dan1975]

Wow this sounds awesome

[Lardo Boffin]

More amazing stuff! Count me in if they are ever for sale.