Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Graphics Hardware Hacking Upgrades Hardware Build Games

TMS9918A Retro Video Chip Reimplemented In FPGA, With VGA Out 126

acadiel writes "Matthew H from the TI-99/4A forum has finalized a design of a TMS 9918A replacement (with VGA out) for classic computer systems such as the ColecoVision, TI-99/4A, SpectraVision, MSX1, SpectraVision 128, and Tomy Tutor Home computers. This hardware project replaces the native video controller on these classic systems and enables them to have VGA output for the first time." (It's just under $100 to order one.)
This discussion has been archived. No new comments can be posted.

TMS9918A Retro Video Chip Reimplemented In FPGA, With VGA Out

Comments Filter:
  • by JoeCommodore ( 567479 ) <> on Saturday February 11, 2012 @04:56PM (#39007069) Homepage

    Of all the chips that one on the Commodore 128/128D is a pain to convert to anything modern as it uses the old CGA/RGBI interface. All the CGA adapters ive found dont handle the intensity signal, they are more RGBA compatible.

  • by 0123456 ( 636235 ) on Saturday February 11, 2012 @04:56PM (#39007071)

    he'd better do an HDMI version quick as VGA seems to be on the way out as a connector :-P

    Except HDMI is a closed standard and buying HDMI chips requires signing over your first-born to Satan.

  • by cb88 ( 1410145 ) on Saturday February 11, 2012 @05:05PM (#39007133)
    then just implement DVI-D over HDMI ... so you don't have to bother with the DRM. Check out the wikipedia article I imagine there are some kinks but HDMI is mostly backwards compatible with DVI-D And I have real world evidence as well.. Pandaboard does DVI-D for the very reasons you mentioned and it works just fine with a couple TV's I have tried that said it was picky one one monitor I tried though it seemed to be a kernel issue as one kernel would boot up on HDMI the other on DVI so had nothing to do with the hardware itself working correctly.
  • Re:Um.... (Score:2, Informative)

    by Grieviant ( 1598761 ) * on Saturday February 11, 2012 @05:15PM (#39007229)

    Except when you can get a composite to VGA converter for 30% of the price of this chip. []

  • Re:Um.... (Score:5, Informative)

    by Anonymous Coward on Saturday February 11, 2012 @05:33PM (#39007329)

    Except that you're still upconverting a signal from 240p to 480p. By going directly to VGA you're at least getting a crisp 480p image (ie: 640x480). And no, doing this after the signal has been produced at the composite outputs is not going to be as pretty.

  • Artifact colors (Score:5, Informative)

    by tepples ( 727027 ) <{tepples} {at} {}> on Saturday February 11, 2012 @05:53PM (#39007463) Homepage Journal

    And no, doing this after the signal has been produced at the composite outputs is not going to be as pretty.

    Unless you're using a program that relies on the artifacts in a particular video chip's composite output. The NES PPU's architecture was heavily inspired by the TMS9918, and I know a lot of NES games rely on interactions between luma and chroma to give the backgrounds more texture.

  • by Anonymous Coward on Saturday February 11, 2012 @06:01PM (#39007527)

    But this is not a big problem -- there's dead-simple passive analog circuits (e.g. []) to do a passable conversion, and if you want to fix the dark-yellow/brown issue, that's not hard either.

    RGBI signals in CGA are TTL, so converting to analog RGB is as simple as connecting them to the address lines of a suitable 8-bit PROM (or SRAM, in which case you'll want a battery to retain memory) programmed with appropriate RGB values, and three 2-bit ADCs on the output (0=0v, 3=0.7v for VGA).

    You want to program the ROM/RAM as follows, assuming I as MSB (note color 6, brown, deviates from the expected 220):
    N | RGB | xxRRGGBB
    0 | 000 | 00000000
    1 | 002 | 00000010
    2 | 020 | 00001000
    3 | 022 | 00001010
    4 | 200 | 00100000
    5 | 202 | 00100010
    6 | 210 | 00100110
    7 | 222 | 00101010
    8 | 111 | 00010101
    9 | 113 | 00010111
    A | 131 | 00011101
    B | 133 | 00011111
    C | 311 | 00110101
    D | 313 | 00110111
    E | 331 | 00111101
    F | 333 | 00111111

    Or use a 16-bit ROM and wider DACs, and you could customize each color to exactly match your old 1902.

    Seems a PCB with a preprogrammed ROM, DACs (could be as simple as R-2R ladder), and a scan doubler IC, should be much cheaper than a $100 replacement video chip.

  • Re:Um.... (Score:5, Informative)

    by kermidge ( 2221646 ) on Saturday February 11, 2012 @06:13PM (#39007629) Journal

    Better, perhaps, to ask "for whom?"

    Please consider that just thirty-odd years ago, one could own a computer that wasn't the university's or corporation's. Whether one came fresh to it or from mainframe milieu, there was an immediacy, a power, a whole new realm of discovery. One no longer had to submit their deck of cards to an acolyte to the high priests of a Burroughs or CDC Behemoth only to get back a core dump due to an errant comma. Some, even now, for reasons of nostalgia or fun, continue their interest and enthusiasm - vibrant 8-bit micro communities are but a search away.

    The TI-99/4A offered, amongst other things, 16 sprites with built-in collision detection. At the time this was nigh magical. Sprites were effectively independent of screen - they were a 'floating' layer above it and allowed for some interesting game and simulation possibilities. SCREEN itself was a defined device; one could PEEK and POKE 'most anywhere, and PUT and GET to any device. An entire screen could be represented with a string in memory, its contents readily changed on the fly. One could read data for a string from a DATA statement in program code or from (eventually) floppy; with several strings screen-swapping, almost animation, could be done. Graphics could accompany text adventures. Add sprites? Oh, my. And now with VGA?

    You may have to ask "what for?" - others will not.

  • That is cool.

    I believe I saw one that did that and did not have the brown problem but it used a gal chip which most likely did the value change before being sent to a DAC. It was way more expensive than the solution listed which has more features as it was such a niche device. This was 1998-99 and was 350

    It's a composite to RGBI to VGA converter. ;) []
    This is pretty nifty and they have a workaround for the intensity problem. Price is now higher for the parts mentioned about 190. One of the companies listed has a dead website, dns problem maybe.

    Here's another solution using and RGB to VGA and a resistor network to feed to the I input so that it's an RGBI to VGA converter. I think there's something wrong here but it works so it's not wrong. []

  • Re:Um.... (Score:4, Informative)

    by Mr Z ( 6791 ) on Saturday February 11, 2012 @10:25PM (#39008941) Homepage Journal

    Probably the biggest problem is going to be all the old school electrolytic capacitors. I know my TI-99/4A is a bit flaky, and I suspect that's why. The VDP was running at the edge of process technology in those days (5.37MHz!) and it wants nice, clean clocks and nice clean supply rails. The rest of the machine runs a fair bit slower, with possible exception of the 256 byte SRAM that the TMS9900 CPU stores its "registers" in.

    Thankfully, those big old electrolytic cans are easy to spot and easy to solder in replacements for.

  • Re:Um.... (Score:4, Informative)

    by rdebath ( 884132 ) on Sunday February 12, 2012 @04:37AM (#39009931)

    Actually, VDP RAM isn't memory mapped on any platform that I know of. But other systems have CPU-addressable memory that you could store a shadow copy of data in at least. The paltry 256 bytes on the TI-99/4A, though, are far from enough in many cases.

    On the contrary, many 8-bits had memory mapped video. Commodore (VIC/64/Amiga), Sinclair (Spectrum, zx81, zx80, dist by Timex in the US) Atari, VT100 ... etc etc. Not that there weren't machines with distinct video RAM, the Commodore PET had specific video memory, though it was still mapped into the address space like a modern PC video card. Having the video RAM in a inaccessible (I/O bus) location was rare.

    The reason was simple, at that point in time only a relatively small amount of RAM was needed for the machines and it ended up being faster than the CPU. So much so that you could assign 50% of the RAM bandwidth to the video subsystem without impacting the speed of the processor at all.

    The ZX81, however, was a bit of a foreshadowing of things to come. It was built really, really, cheaply and they used really cheap DRAM. This cheap RAM wasn't fast enough to feed both the CPU and the video at the same time so the CPU was basically turned off when the video was being displayed (In fact it was physically used as a counter chip by the ultra cheap video controller).

    Nowadays people want astronomical quantities of RAM so it basically has to be the cheapest design possible; this type of RAM can't keep up with just one CPU, let alone multiple CPUs and a video controller. So the video controller has to reduce the performance of the main CPUs by stealing cycles, or it gets it's own RAM.

    Note: There are several Intel video controllers for PC clones that use main memory as the video RAM, they get added as a cheap motherboard video controller. Because of the fact that they're using slow RAM and stealing cycles from the CPU these are rightfully seen as very low performance.

    On the other side, a common mistake for designs with distinct video RAM is that the CPU only ever needs to write to this RAM, unfortunately the problem is frequently only recognised in production.

The only possible interpretation of any research whatever in the `social sciences' is: some do, some don't. -- Ernest Rutherford