3
\$\begingroup\$

I'm building a homebrew computer. I want some way to get video out, preferably along the lines of 80x25 text. I'm not interested in framebuffer graphics.

Does such a thing exist as a single-chip text generation system, complete with clock, internal character generator ROM and video memory? Preferably speaking something like I2C...

Back in the old days there was the SAA5243 Teletext video generator, which did almost all of this. It would surprise me a lot if there wasn't something similar (but better) available today. I have found things like the MAX7456, but that's really intended for OSD use and only does 30x16, which is a bit small. Is there any kind of modern equivalent?

Of course, I'm aware that any reasonably fast microcontroller can bit-bang composite video in software, but then I'd have to write it myself and I'd kinda like something which works.

(Incidentally, and this is not part of the question, but if anyone knows where I can get hold of an HD44780-style character LCD larger than about 80x16 I would be delighted.)

Update: Of course, anything that emits VGA is fine too. I basically want some form of video that's cheap and easy to display.

\$\endgroup\$
  • \$\begingroup\$ TBH, for composite video the MAX7456 is about the best thing you'll find for sensible money/effort. There are other OSD chips out there for VGA rather than composite if you could live with that. \$\endgroup\$ – John U Feb 25 '13 at 15:10
  • \$\begingroup\$ Probably --- I automatically said 'composite' because that's what I think of when I think of cheap/easy video, but of course that's probably not true any more. VGA's fine. \$\endgroup\$ – David Given Feb 25 '13 at 16:30
  • \$\begingroup\$ In that case just google for OSD chips, you'll find 'em. That said - generating VGA by bit-bang is even easier than composite, so it could be an option. \$\endgroup\$ – John U Feb 26 '13 at 9:14
1
\$\begingroup\$

What sort of processor and memory system are you using? Many home computers in the 1980's had the video system that takes data directly from the processor's memory. Depending upon the processor, it may be possible to have the video system receive data from memory when the processor isn't using it (this was done on e.g. the Apple ][ series); even if that's not possible, having the video receive data directly from the CPU will often allow nicer screen updates than would be possible if the data had to be fed to another chip; one can vary the complexity of the hardware based upon the level of CPU loading that would be considered "acceptable". Note that if your processor/microcontroller has a spare DMA channel, the level of hardware required may be very slight--especially for a bitmap display--and the CPU may only need to be interrupted once per frame [depending upon the DMA controller, you might not even need that].

It would be possible to use a CPLD along with either a parallel or serial RAM to create a video subsystem which could run mostly or totally autonomously but would allow the main CPU to perform some display updates during the time when the display was blanked (depending upon how much logic you want to put in the CPLD, the main CPU may have to make sure it reset the address on the SPI RAM in time for video to resume clocking). You could also use a CPLD along with a parallel RAM to emulate a serial RAM; if you were planning on interfacing a serial RAM with your CPU anyway, that might be the best approach. Since the main CPU and the video would each only need to access two million bytes per second maximum (assuming one-bit video), there should be no problem interleaving the parallel memory cycles. I would guess that a CPLD with 64 or 72 macrocells could do the job "barely", or one with 128 or 144 macrocells could do the job "comfortably". I'd be inclined to go with the latter, since it could probably include a variety of features that would greatly expedite display updates (e.g. the ability to automatically bit-shift or mask incoming data).

\$\endgroup\$
  • \$\begingroup\$ I'm using a microcontroller with no external RAM interface, so unfortunately that approach isn't viable... \$\endgroup\$ – David Given Feb 25 '13 at 18:09
  • \$\begingroup\$ @DavidGiven: How much RAM do you have, and is there a DMA controller? \$\endgroup\$ – supercat Feb 25 '13 at 18:16
  • \$\begingroup\$ Not enough for a graphical framebuffer! However... you did give me an Evil Idea: I do have an external SPI RAM chip, and from looking at the datasheet it may be possible to persuade it to generate the pixel data: at the beginning of each scanline I'd prepare it for a read transfer, then output the CPU clock to the RAM's clock pin. That would mean a 16MHz pixel clock, which turns into 665x230 with PAL. (In order to write to video RAM I'd need to stop video refresh, however.) Did you have any cunning tricks in mind to avoid an interrupt every scanline? \$\endgroup\$ – David Given Feb 26 '13 at 14:27
1
\$\begingroup\$

You could use a Parallax Propeller chip as a peripheral, and use either a parallel or serial (SPI/I2C) bus to communicate with it. The chip costs $8 in single quantities and is available either in DIP or SMD packages (whereas the MAX7456 costs more than twice as much and is only available as a SMD).

The Propeller has special timing circuits to generate both composite and VGA video under software control. Although you mentioned the need for only text, it can do graphics too -- here is a demo. As far as text goes, check out the VGA text demo at around 2:05 into the video which has a format close to what you are looking for.

There are plenty of libraries existing for sending text to the display so you don't have to write your own from scratch. The default font is contained in a bit-mapped table included in the same ROM that contains the bootloader and interpreter used for the Spin language (the high-level language Parallax supplies for programming the Propeller; C and assembly can also be used).

\$\endgroup\$
0
\$\begingroup\$

If color is not important you can take a look at cheap Tellymate for AVR and XMEGA. There is also a device which works on both composite video and VGA.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.